质量保障（二）

"工欲善其事，必先利其器。居是邦也，事其大夫之贤者，友其士之仁者。" ------ 《论语·卫灵公》

古代优秀的思想家们早就给我们指明了前进的方向，即如果想让一件事情做好、做优，那么要有充足的准备，以及正确的价值观。但我们也应该清楚，器欲尽其用，必先得其法。只有这样，我们才能形成一套行之有效的方式方法，在个人、团队中推广和论证。那么我们有没有这些方面的经验和方法去给我们借鉴呢？很高兴，在我们这个互联网蓬勃发展的时代，答案肯定是有的。

TDD：Test Driven Development，即测试驱动开发。它是一种测试先于编写代码的思想用于指导软件开发。测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
ATDD：Acceptance Test Driven Development，即验收测试驱动开发。在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。
BDD：Behavior Driven Development，即行为驱动开发。它是一种敏捷软件开发的技术，鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作，来共同设计产品验收场景。
DDD：Domain Drive Design，即领域驱动开发，它关注Service层的设计，着重于业务的实现，将分析和设计结合起来，不再使他们处于分裂的状态，这可以使我们正确完整的实现客户需求，以及建立一个具有业务伸缩性的模型。

但，问题来了，有这么多优秀的测试方法论，我们该怎么选择？哪些适合我们？我们又需要具备什么样的能力？单元测试、集成测试、系统测试、验收测试、性能测试、安全测试......，每当一个项目开始时，这些事情就随之而来，我们又该如何取舍？

我们来拿TDD和BDD来进行一些简单的对比。

	TDD	BDD
目的	以发现软件中的Bug	以验证软件系统是否满足需求
侧重点	侧重于测试	侧重于从用户需求角度考虑问题
核心价值	测试驱动开发进行	正确的对系统进行行为设计
使用方法	通常侧重于代码的测试工具	非常有辩识力度的场景设计
参与成员	多为开发和测试	开发、测试、PM、产品经理、客户等
所在位置	单元测试、接口测试	功能、系统、验收等环节
解决什么问题	研发和测试割裂；开发到测试周期长；自动化程度低	需求和开发脱节；用户想要的功能没有开发；开发的功能非用户所需

我们再来看看BDD的基本流程。

通过这些对比，我们明显的可以发现，我们应该使用BDD这套测试理论，它是从用户需求的角度来考虑整个产品的验收，它希望当我们完成测试之后，我们开发的产品贴合真实用户的需求，这样就更容易被客户所接受，同时还有一个更容易被测试人员所接受的事实，那就是对人员专业技术能力的要求变得很低很低了，而这恰恰符合目前整个测试从业人员的现状。

好的，测试理论有了，我们可以理直气壮的去找PM进行PK了，PM在这轮PK中完败下来，正当我们沾沾自喜的时候，新的问题又来了，PM又来找你了，项目进度实在是太紧张了，等你按部就班的测试完成，我们黄花菜都凉了（现实的情况就是，研发进度会延后，但项目进度不能延期），提效的事情又摆在了测试人员的面前，我们怎么办？这时候聪明的人肯定会说，如果我们解决了效率的事情，会不会又出现新的问题？何时是个头？是的，新问题肯定会出现，而且会一直跟随，但这也是我们存在的意义，我们要去解决它。

如何解决？我个人认为，只要能坚持从下面四个方向出发，在我们的工作不断的实践和总结，不断的提取出符合实际情况的精华，那么就可以快速、持续的改进我们的软件质量。

质量建设的四个方面

• 场景设计
  场景设计，是整个质量建设的核心，它要解决用户需求的覆盖率、业务场景的符合度、业务场景的正确率、业务场景的可测试性，它的好坏，将直接影响最终的交付质量，测试人员应根据BDD测试理论，在需求阶段就要完全接入，将PM、产品经理、研发都积极的调动起来，从不同的角度来考虑需求、分析需求，将场景设计这个阶段做好。

• 效能提升
  效能提升，是解决整个项目测试实施过程中效率问题，同时也解决整个测试团队的技术天花板的问题，它的好坏，将直接影响最终的交付效率。

• 质量度量
  质量度量，是解决在整个项目测试过程中可能产生的各种问题，通过数据量化的方式，快速的暴露问题、解决问题，它的好坏，将影响最终的交付质量。

• 标准规范
  标准规范，是解决质量保障可延续的问题，铁打的算盘、流水的兵，只有标准化的建设，才能解决交付的一致性和质量。

围绕着场景设计，我们对效率、度量、规范进行合理、有效的建设，持续不断的完善和改进，形成符合实际情况的标准规范。这其实就是我们测试人员 "一个中心，三个基本点" 的核心思想，我们终将客服一切困难，迎来属于我们的胜利果实。

场景设计

• 需求分析
  需求分析，核心关键词有两个，覆盖率和业务场景。

  覆盖率，在整个项目，从接收到用户需求开始，到研发进行代码开发，会有两个需求阶段出现：
  第一个阶段： 用户需求 --》 业务需求
  第二个阶段： 业务需求 --》 功能需求、非功能性需求（性能、稳定性、安全性、稳定性等等）
  所以在进行分析时，要保证 业务需求能够100%覆盖用户需求、功能需求和非功能需求要100%覆盖业务需求，同时要梳理出不同需求的优先级、重要性。

  业务场景，在BDD中，强调测试案例要根据用户的行为进行设计，即在分析业务需求时，要勾画出用户期望的一个个用户使用场景，并就用户使用场景的合理性、完整性与PM、产品经理、用户进行沟通确认，就可测试性与研发人员进行沟通确认，规避测试风险。

  这是第一阶段的业务场景分析，能够对后续测试阶段提供测试范围的完整性和测试场景的可测试性提供有效保障，为测试人员设计具体的测试场景提供事实依据。

• 架构分析
  架构分析，核心关键词有两个，规则和数据。

  规则，实际开发完成的产品，服务都会很多，接口、Web UI都会很多很多，测试不能对通过穷举的方式去测试，既不省事、也不省时。所以我们要根据业务场景，去寻找规则，针对规则进行测试设计，而恰恰研发人员在进行开发时，会有很多各式各样的规则，这些一般很少体现在文档中，只有及时、准确的梳理清楚，才能少测但不遗漏。

  数据，数据是场景测试中非常重要的前置条件，如果没有合理、有效的测试数据，我们的测试毫无意义。只有将业务的输入数据、数据在业务场景中的真实流转分析清楚，才能提前准备合理的测试数据（用户提供的数据，通过工具生产的数据）。

  这是第二阶段的业务场景分析，是对第一阶段场景设计落地过程中的有效的补充，只有通过第二阶段的分析，测试人员设计的测试场景才具备可操作性。

• 技术特性分析
  技术特性分析，核心关键词有两个，特性和配置。

  配置，在每个产品中都会有各种基础服务的依赖，比如中间件（比如Tomcat，比如Nginx），有些软件，会集中去管理配置，比如Apollo，但依然有很多软件不会这么干，这很正常，取决于项目的实际情况。这样服务就会有很多很多的配置项可进行配置，根据不同的应用场景，其对应的配置项内容也会不一样，需要对我们关心的重要配置项梳理清楚，为测试场景的细分范围和步骤提供必要的支持。

  特性，每种技术，都有其自身的特点，比如Mysql，比如Docker，只有了解这些技术的特性，才能针对性的设计场景、设计测试数据，为测试场景的细分范围和步骤提供必要的支持。

  这是第三阶段的业务场景分析，是对第二阶段场景设计落地过程种的有效的补充，但这部分并不建议一开始就做，而是在改进和提升测试质量时进行。