因为随着微服务、移动互联网、物联网、大数据分析系统、AI系统等的出现，要测试一个包含各种技术，外部依赖，或者独立子系统的复杂系统，并不是简单的根据测试策略在不同层面上做不同的测试就可以了，而是要理清各种测试之间的相互联系和制约，然后思考怎么有效的将各个维度上的测试联系起来，以软件系统架构的思维去思考整个测试体系。

　　请注意这里不是说要去设计一套全自动化的测试系统来完成整个系统的所有测试，而是通个各种有效的方式（无论手动还是自动）把各种测试合理且有效的联系起来，形成一个拥有完整架构的测试体系，这样才能使整个系统的各种测试更加可视化和更易于理解，使整个系统的各种测试更加有效，避免重复测试，节约成本。

　　举例来说，一个前后端分离的Web业务系统不仅有前端UI和大量的JavaScirpt代码，还有后端的API和第三方依赖系统以及数据库系统，如何将各层测试有效的联系起来就是测试架构需要解决的问题。

　　首先，前端、后端API、第三方依赖系统和数据库系统有各自的单元测试、集成测试等，然后可以使用契约测试来测试统一前端和后端API，再使用Stub加入对于第三方依赖系统的契约测试或者监控测试，还需要使用测试数据生成系统参数，将各种测试数据存入数据库系统用于支持契约测试等。

　　对于不同软件系统，其架构一般都是根据业务需求、技术能力等各种条件来设计的。与软件架构一样，测试策略和测试架构在不同的项目里面，需要根据其软件系统的架构、技术栈、业务需求、人员的技能等因素来定制和设计。

　　再谈测试策略

　　现在业界流行的测试金字塔和测试象限只是两种高度抽象和简化的测试策略模型，不具备实际可操作性，只具备高层次的指导性和参考性。直接根据这两个模型来工作是低效的，直播，甚至可能带来负面效果。所以对于测试金字塔和测试象限不能盲目的使用，而是需要根据项目的实际情况来生成适合自己项目的测试策略和测试架构，并在此基础上执行真实的测试工作。