Docs

Appearance

第20讲：没有ATDD，就没有用户故事的可测试性 ​

从这一讲开始，我们就进入了第 4 部分的学习：测试左移更体现敏捷测试的价值 。因为敏捷更提倡团队对质量负责、预防缺陷胜于发现缺陷，这两点就意味着我们要构建出高质量的产品，把质量构建推向源头------需求，把测试活动左移到需求阶段，持续地对需求和设计进行评审、及时发现需求和设计的问题。


测试左移的目的是及时发现研发前期的错误，避免将错误带到代码阶段、测试阶段，TDD/ATDD（测试驱动开发/验收测试驱动开发）是更为彻底的测试左移，一次把事情做对，即零缺陷质量管理思想在软件研发中的实践，从而帮助企业节省研发成本并缩短开发时间。测试左移还包括测试计划和设计尽早开始，所有这些就构成了第 4 部分要讨论的内容。


测试左移还包括让开发人员做更多的测试、加强单元测试、持续集成等，在敏捷开发里这些都是核心实践，持续集成已经在第 12 讲讲过了，单元测试的内容将在第 42 讲中介绍。


在第 7 讲介绍敏捷团队中的专职测试人员时，提到过测试人员的责任之一是对软件的可测试性进行把关，可测试性是测试的基础或前提，没有可测试性，谈何测试？这一讲，我就来讲解什么是可测试性、可测试性的不同层次，以及如何提高用户故事的可测试性。

可测试性概念 ​

软件的可测试性，从字面上的意思来说是指一个系统能不能进行测试。从理论上讲，可测试性基本上是由可观察性和可控制性构成的，还可以包括可预见性。

  • 可观察性（Observability）是指在有限的时间内使用输出描述系统当前状态的能力。系统具有可观察性意味着一定要有输出，没有输出就不能了解系统当前处于什么状态，也就不能确定系统行为表现是否正确。

  • 可控制性（Controllability）是指在特定的合理操作情况下，整个配置空间操作或改变系统的能力，包括状态控制和输出控制。系统具有可控制性表明一定要有输入，只有通过输入才能控制系统。


理解了前面两个，那可预见性（Predictability）也就好理解了，就是在一定的输入条件下，输出的结果是可以预测的，这样我们就可以给出系统的预期行为或预期结果，常常用于测试用例设计中。


图1 可控制性和可观察性的示意图


在此基础上，你可以重新理解一下可测试性：通过被测系统提供的接口对系统进行操作，然后，能够通过输出的结果了解到系统的状态是否符合预期。


如果一个系统缺乏可控制性和可观察性，如图 1 所示，可以通过增加接口的方式，使之可以控制它或产生输出。在敏捷测试中，没有自动化测试万万不行，而自动化测试对可测试性提出更高的要求，因为自动化测试更需要明确的输入和输出，所以要求系统能够提供可以调用的接口，通过接口调用来驱动程序运行并验证返回的结果。接口可以是 UI 界面或 UI 下面那一层面向业务的 API， 也可以是微服务模块暴露给其他模块的 API。


AI 软件的可测试性就是一个挑战，因为缺乏可预见性，不太容易事先定义好 Test Oracle 来验证输出结果是否符合预期。比如，Google 在 2018 年公布了用于 NLP（Natural Language Processing，自然语言处理）技术的 BERT（Bidirectional Encoder Representations from Transformers）模型，这个模型通过超过 3 亿个参数提供了强大的语句预测能力。但是，模型处理的结果需要人类去综合判断分析是否正确，并且需要理解参数微调带来的变化。不过，目前人们也在探索如何解决这些问题，第 44 讲会讨论 AI 软件的测试设计与执行。

需求、设计和代码等不同层次的可测试性 ​

对可测试性的需求不仅仅是能够进行自动化测试和手工测试，既然我们要测试左移，那可测试性应该包括三个方面：需求的可测试性、设计的可测试性和代码的可测试性 。

  • 需求的可测试性，包括所定义的功能正确性是否能够被判断？输入、输出的数据是否有清楚的定义从而能验证其精准性？系统的性能、可靠性等是否有验证的标准和方法？

  • 设计的可测试性，是指通过设计来确保系统的特性具有可控制性、可观察性。另外，需要通过设计确保系统的简单性。从测试角度来说，设计越复杂，系统各组件之间的耦合度越高，对单个组件的测试难度就越大。

  • 代码的可测试性，一方面要保证需求和设计的可测试性得到实现，比如各项功能需求得到了满足，并且按照设计实现了系统的松散耦合、模块之间的接口定义。

用户故事的可测试性和 ATDD ​

敏捷开发提倡"可工作的软件胜于完备的文档"，强调开发团队成员之间通过沟通来澄清需求，这就造成文档质量不高、需求描述不清楚。敏捷采用用户故事的形式对需求进行描述，一个用户故事（User Story）通常按照下列的格式（模板）来表述：

As a who（谁？），I want to what（什么行为？）so that why（为何？）。

（作为一个用户角色，我需要做某事，这样就能达到某个目的）


用户故事示例：

作为这家购物网站的买家，我要通过商品名称查询历史订单，这样我就能查看某个订单的详细信息了。


用户故事是以业务语言来描述的，而不是使用技术语言，比如，我要实现微服务 A 的一个 API 供微服务 B 调用，这就不是一个好的用户故事。同时，用户故事必须是可测试的，要不然怎么验证用户故事的实现是不是符合预期？


在实际工作中，也许你经常会碰到这些情况：某个用户故事的描述太简单，每个看到用户故事的人，其理解都不一样，但产品负责人（PO）可能和开发人员有过面对面的沟通，开发人员基本知道做什么，但测试人员还是不清楚，测试就追着开发问这个用户故事究竟要实现到什么程度？开发会说：别急，等过两天，我做好了给你和 PO demo 一下，就清楚了，如果你们觉得不行，我再改。看似态度很好，但测试人员能做什么吗？根本无法设计测试用例或写自动化脚本。


功能性的用户故事还好，非功能性的用户故事不可测问题更大。 例如，用户故事描述是这样的：作为一个注册用户，我希望能够快速地登录到系统内。那么，你会问，究竟多快算快？1 秒钟还是 3 秒钟？


为了保证用户故事是可测试的，需要对用户的实际需求有一个明确的说明，这就是用户故事的验收标准（Acceptance Criteria，AC）。比如，你阅读上面那个用户故事示例，会有很多疑问：

  • 查询历史订单，能够查询多长时间的历史订单？最近一年的，还是没有时间限制？

  • 支持不支持模糊查询？

  • 如果查到多个，如何显示？

  • 如果没有查到，给出什么提示？

  • 查看订单的详细信息，究竟包含哪些项？


有这么多问题不明白，验收标准就是要让这些问题明白，因此为这个用户故事示例增加相关的AC：

  • 缺省是查询过去一年的历史订单;

  • 如果没查到，问用户是否选择一个查询的时段；

  • 支持模糊查询;

  • 按匹配度来排序，而不是按时间排序;

  • 每页最多显示十个记录;

  • 查到后只显示订单号、商品名称、价格和日期;

  • 如果想继续看，再点击订单查看;

  • ......


这样，所要实现的用户故事就清楚了，也可以验证了。如果没有明确的验收标准，就没有用户故事的可测试性。用户故事的验收标准不仅让测试有据可依，而且由于列出了各种条件，开发人员在实现用户故事时就不容易犯错误，代码质量也会高得多。也正因为用户故事的验收标准澄清了需求，避免了开发和测试的争吵，有利于开发和测试的协作，而且减少了沟通成本，可以提高开发效率。


验收测试驱动开发（Acceptance Test Driven Development，ATDD）就是在开发设计、写代码之前，先明确（定义）每个用户故事的验收标准，然后再基于用户故事的验收标准进行开发。这样有利于我们之前强调的"质量是构建出来的"、"预防缺陷比发现缺陷更有价值"。

ATDD 与 TDD（UTDD）的关系 ​

测试驱动开发（Test Driven Development，TDD）是指测试先行的理念，即测试在前、开发在后，提倡在编程之前，先写测试脚本或设计测试用例。TDD 在敏捷开发模式中被称为"测试优先的编程（Test-First Programming）"。


TDD 中测试先行的理念是为了给开发人员对编写的代码有足够的信心，代码的错误可以通过测试来验证。敏捷开发往往是快速迭代，程序设计不足，所以经常需要不断重构代码，而重构的前提是测试就绪，这样重构的质量就可以通过运行已有的测试得到快速的反馈。所以，有了 TDD，程序员就有了勇气进行设计或代码的快速重构，有利于快速迭代和持续交付。


重构是指在不改变代码外在行为的前提下，对代码做出修改。------《重构：改善既有代码的设计》


ATDD 和 UTDD（Unit Test Driven Development，单元测试驱动开发）都属于 TDD 思想指导下的优秀实践，可以看作是 TDD 具体实施过程的两个层次：

  • ATDD 发生在业务层次，在设计、写代码前就明确需求（用户故事）的验收标准。

  • UTDD 发生在代码层次，在编码之前写单元测试脚本，然后编写代码直到单元测试通过，这里的 UTDD 相当于传统概念（如极限编程）的 TDD。



在开发实践中，UTDD 在备受推崇的同时，也受到了广泛且持久的争议。 David H.Hansson 是著名的 Web 开发框架 Ruby On Rails 的开发者，他在 2014 年写了一篇文章对 TDD 提出了公开的质疑和否定，该文章是"TDD is dead. Long live testing"（TDD 已死，测试永生）。这篇文章一出来就引起了广泛的讨论，赞成者认为说出了自己的心声，当然也趁机表达了自己的意见，比如，工期紧、时间短根本来不及写单元测试；TDD 对开发人员的要求过高，推行的最大问题在于很多开发人员不会写测试用例，也不会重构代码。


反对者认为 David 对 TDD 的理解是片面的、不正确的，认为 TDD 就是 UTDD，而忽略了 TDD 还包括 ATDD。这里暂时不对 UTDD 进行详细讨论，但就目前的情况来看，UTDD 虽然没有死，但推行的也不好。我在今年年初公布的 2019 年软件测试调查结果中显示，只有 21% 的团队在做静态代码分析、单元测试，更别提更加高大上的 UTDD 了。


而相比 UTDD，面向业务层面的 ATDD 推行起来就比较容易，而且是必须的。因为需求模糊、需求不具有可测试性，你能接受吗？模糊的需求往往意味着返工和浪费，没有可测试性也就意味着无法开展测试。 所以，团队按照验收标准来实现用户故事，是不是理所当然？


到这里，这一讲的内容就讲完了，我简单总结一下：

  • 系统的可测试性包括可观察性、可控制性和可预见性；

  • 明确用户故事的验收标准是让用户故事具备可测试性的关键，也是必要的；

  • 把 TDD 看成是"测试先行"的理念，这样 ATDD 和 UTDD 则是其两个不同层次上的落地实践；

  • 相比 UTDD 引起的争议和推行的困难，ATDD 更容易在实践中落地。


最后出一个思考题：你所在的公司里是在推行 UTDD、还是 ATDD 呢？有哪些挑战和优秀的经验可以分享？欢迎留言讨论。