开发转测试七年，我从测试策略到测试架构

程序员之间流传着这样一句顺口溜：有人喜欢创造世界，他们作了开发者；有的人喜欢开发者，他们作了测试员。什么是软件测试？软件测试就是一场本该在用户面前发生的灾难提早在本身面前发生了，这会让他们生出一种救世主的感受，拯救了用户，也就拯救者这个软件，避免了他们被卸载的命运。

今年是我作软件测试的第7个年头了，当年我从软件开发转作软件测试的时候，没有想过我能在这个领域作这么久。在这7年里面，我在软件测试领域摸爬滚打，从自动测试起步，逐步接触到软件测试的各个领域：各类测试方法（等价类，全配对等）、测试技术（单元测试，功能测试，性能测试，探索性测试等）、自动化测试工具（JUnit，Selenium，Gatling，ZAP等）、测试流程（传统测试流程，敏捷测试流程等）以及测试策略（测试象限和测试金字塔等）。

其中“测试策略”在测试业界是讨论的比较少的，由于大多数人的工做重点是设计测试用例，执行测试或者开发和维护自动化测试，而只有少部分人才会涉及到测试策略的工做，从而致使不少测试人员其实并无系统的了解测试策略。

因此我准备将我这几年对于测试策略的经验、总结以及思考以系列文章的形式写出来，但愿能稍微帮助一下你们去理解测试策略，从而作到更好的测试，减小缺陷，提升质量。

测试策略

测试策略（Test Strategy）的第一目标就是“减小缺陷的出现和发布”。其中“减小缺陷的出现”能够经过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；而“减小缺陷发布”可使用各类测试方法、技术来验证和测试编码完成的功能（这两点在从此的文章里面会经过不一样的例子进行更详细的阐述）。

因而可知，“测试策略”并非只由测试人员定制的，它是由一个团队的各个角色一块儿来制定和创建的，目的是保证软件的质量，减小缺陷。

而“测试计划”是用于实施测试策略的。只有充分理解测试策略目的和实施方式，才能充分理解测试策略，为何要作测试策略，什么样的测试策略才更有意义、更好，怎样实施才能更有效等问题。

测试计划

制定测试计划是保证测试策略能被有效执行的一种方式。它告诉了团队在什么阶段，什么样的角色应该执行测试策略中什么样测试技术和测试方法。它主要由测试人员编写，可是应该由整个团队进行评审，由于开发人员、产品经理、业务分析人员甚至用户均可能参与到测试计划的执行中。

测试计划是能够根据项目的实际进展状况进行调整的，因此它并非一成不变的。

测试架构

在上个世纪六七十年代软件系统还处于小规模的时候，软件开发并无谈什么架构，软件测试也不存在什么策略可言。可是随着软件规模的极速增大，复杂性也成指数级增长，专业的软件架构应运而生。

为了有效的在规定时间内完成复杂软件系统的测试，必须有一个指导性的策略来帮助团队理解、选择和组织大量的测试，所以软件测试策略就出现了。而测试策略每每是高层次的指导，对于一些中小型项目也许已经足够了，可是却不足以应付现代愈来愈复杂的软件系统。

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

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

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

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

若是对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能够273462828，群内会有不按期的发放免费的资料连接，这些资料都是从各个技术网站搜集、整理出来的，若是你有好的学习资料能够私聊发我，我会注明出处以后分享给你们。

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

再谈测试策略

如今业界流行的测试金字塔和测试象限只是两种高度抽象和简化的测试策略模型，不具有实际可操做性，只具有高层次的指导性和参考性。直接根据这两个模型来工做是低效的，甚至可能带来负面效果。因此对于测试金字塔和测试象限不能盲目的使用，而是须要根据项目的实际状况来生成适合本身项目的测试策略和测试架构（项目不须要测试架构），并在此基础上执行真实的测试工做。