Xing Binbin(测试工程师）

    有道云笔记团队采用敏捷的开发模式已有近两年的时间，为了更好的协作完成产品迭代，笔记测试团队也逐渐积攒了一些敏捷实践的经验。然而敏捷测试的转换和实施并不容易，和资源、环境等诸多因素有关系。如何实现从传统瀑布模型到敏捷模型的转化？本文将会结合笔记测试团队一些良好的实践来进行介绍。

    前不久ChinaTest大会上Martin Pol的演讲，阐述了测试从产生到现阶段的演变过程。如图1所示：

图1 evolution of testing

    简单的说，测试先是一个逐步规范化、文档化、结构化的过程，但随之而来的则是越来越不灵活，整个测试周期也随之拉长，这也正是传统瀑布模型的利弊所在。而后有了敏捷的概念，此时对于测试的期望也就变成了在正确衡量产品质量的前提下尽可能提高测试效率。

    结合云笔记项目中的测试实践，先说一下自己对敏捷的认知：敏捷是一种轻文档、重沟通、重质量、快速迭代、关注过程、目标清晰的团队协作模式。而具体到云笔记测试中，大体可以总结为以下几点：

    1、结构化测试思维，理解产品功能。

    对于产品功能，如果从理解就出现了问题，或是理解的不充分，那么后续的测试覆盖必然会受到影响。使用思维导图可以很好的完成这部分事情，一方面需要测试人员真正理解产品功能并且结构化对功能的用例设计，另一方面在测试用例评审的时候也更能清晰的传达测试思路，方便团队成员提出和改进设计缺陷。

    2、测试介入尽可能早，传达风险意识。

    测试介入提前的好处众所周知，而这里还有一个很重要的原因就是通过提前来向团队传达对质量、对风险的认识。比如需求评审，参与的过程中尽可能提出需求设计缺陷，在下个sprint会议之前，产品同事们就会做更详尽的设计。又比如测试用例评审，在开发理解测试内容的同时也会考虑开发过程要关注的一些风险点。这样持续迭代下去，一个良性循环就诞生了，产品在提测前就会避免很多问题的产生。

    3、效率至上，自动化与精准测试。

    敏捷迭代过程中，我们期望将更多的时间用于寻找产品缺陷，而不是花在吃力又不讨好的回归测试中。对于回归测试，一方面通过自动化，持续集成来提升效率；另一方面我们需要对产品功能、代码逻辑的理解程度加深，做到更精准的回归。

    4、关注产品开发过程。

    在一个sprint周期内，产品或者开发总会有或多或少的内容变更。关注开发过程，一方面可以加深对功能逻辑的理解，另一方面也能针对变更来预估风险，做更有针对的测试。

    5、团队协作，同为一个目标。

    对于一个敏捷团队而言，团队协作无疑非常重要，测试人员有必要站在产品、开发的角度来理解问题。在传统的瀑布模型中，会有一些诸如准入测试的标准来要求开发提升提测质量，而在敏捷模型中，则是尽可能通过协作而非阻塞的方式来完成产品的迭代。当然非阻塞需要有一个大的前提，就是每个人都是为了让产品质量越来越高、迭代速度越来越快、做的越来越好。

    6、持续改进。

    敏捷测试是一个不断优化的过程，很少有公司说自己的敏捷测试做的很成熟。包括前面提到的思维导图，尽管有不少优点，也有不便于整合和维护的缺点。图2是Jeroen Mengerink介绍的关于做好敏捷测试的几个要素，每个要素都做到performing并不容易，这也是我们持续改进的目标。

图2 assessment model

    以上是在敏捷模型中测试的一些思想。在笔记实际测试中，大体可以分为以下几步：

    1、需求评审

    在sprint会议上，首先就会进行需求的讲解。在这个阶段对于测试而言无疑是非常重要的，需要尽可能的去思考和发现需求中存在的问题。前期避免掉一些需求导致的问题，待到测试阶段沟通和返工成本都会降低， 这是提升测试效率很关键的一步。

    2、测试用例设计及评审

    在清楚当前sprint需求之后，及时的开始设计测试用例，设计结束后尽早的开始用例评审。敏捷中团队协作有一点就是要站在其他成员的角度思考问题，而要想让他人站在测试的角度思考，测试思维的传达必不可少。需求评审相当于产品向团队展示他们的思维，而测试用例评审则是测试传达测试思维很好的时机。

    附图3是笔记阅读密码功能测试用例的思维导图展示，具体的测试内容大可不必了解，从图上可以清晰的看出整个测试逻辑的组织。思维导图在这里的作用就很明显：弱文档性、传递信息的有效性。

图3 云笔记阅读密码测试用例

    3、测试时间计划

    在测试之前，有必要制定一份具体的测试时间计划，预估测试周期和可上线时间点。这样一个简单的计划，一方面可以宏观的把控测试进度，另一方面又可以评估测试执行效率。当计划与实际时间有很大出入的时候，也能够方便找出测试阶段哪个环节出现了问题以便后续改进。

    4、新功能迭代

    我们将具体的测试时间分为两个阶段，第一阶段就是对sprint新增内容的测试。在这个阶段我们关注测试覆盖度，尽可能的发现问题。这是一个迭代的过程，需要开发及时的对发现的问题进行响应和修复，测试也需要针对开发修复的问题进行发散，有针对性的进行探索性测试。

    5、回归测试

    在新功能基本没有问题之后，就到了冗长而又无趣的回归测试阶段。这个阶段我们关注核心功能的使用，关注如何来提升测试效率。由于目前的自动化覆盖率有限，所以这个阶段不可避免的要有手工回归。对于云笔记而言，功能模块多，逻辑复杂，如果全部回归无疑耗时长，且发现的问题很少。对于质量和效率我们采取了折中的办法，基于风险来进行测试，将回归用例分级：核心功能、数据等模块优先级最高；各个功能的正常使用次之；各功能的临界使用最低，三轮回归测试会逐步加大用例执行的颗粒度。

    对于回归测试，这里并不是最优的解决方案。我们最终的目标还是希望通过自动化来做到持续回归，同时寻找精准测试的方法，来缩短甚至消除这个阶段。

    6、风险分析及测试报告

    在完成测试之后，我们需要评估和分析当前版本的风险和质量状况，整理一份突出产品风险的测试报告。

    7、新功能用例整合

    最后我们需要将之前的新功能用例整合到回归用例中，并区分优先级，以便后续回归测试和自动化用例的增加和维护。

    另外，在整个测试周期内，我们已有的自动化、monkey、性能数据收集也会持续进行，协助我们发现一些产品缺陷。

    目前笔记的测试流程还是有不少瀑布模型的影子，我们也会持续的改进。什么样的测试模型才是最优的？理论和实践总会有差别，真正合适团队的、能够带着敏捷的思想去持续改进才是最重要的。