《自动化测试最佳实践》讲座总结

2016年11月26日 - 27日，参加了为期两天的自动化测试最佳实践。讲师是业界大牛陆宏杰。他在微软工作了5年，后来又在Photoshop工作了5年。

自动化测试是软件工程中非常重要的一部分，所以这次课程涉及了很多项目管理中其它内容。在此我针对部分内容做了总结。

0. 为什么要做测试自动化（Why）

测试自动化是为了做持续集成。而持续集成则是为了更早地发现并解决软件缺陷，同时生成项目数据报表（Dashboard）。这些都是为了更好地管理项目。

1. 自动化测试能做什么（What）

1.1 自动化测试能做什么

自动化测试是为了预防缺陷。

# 为什么不是用自动化测试“发现”bug ?

因为bug有个属性——“版本号”（如：2.1.0）。而自动化测试主要是在提交代码前检查是否有缺陷，这时候还没有生成版本。

（各位想一下自己平时在使用缺陷管理系统（如：Bugzilla）创建bug记录时，是否有个版本号之类的属性）

1.2 自动化测试在系统测试中的应用

系统测试是复杂耗时的组织行为。它有几个特点：

a. 它需要大量的准备工作，如测试环境的搭建（要尽可能地模仿真实的用户环境）

b. 它需要项目组全体成员参与，扮演真实环境中的各种角色

c. 因为代价高昂，为了更充分地利用这些投入成本，一般会安排饱和的测试任务（稍稍溢出最大工作量，肯定无法全部完成）

而自动化测试目的决定了它应该适合简短快速的测试用例，不适合漫长复杂的场景。所以自动化测试不适合大规模地应用于系统测试。一般在系统测试中，可以将自动化技术用于测试环境和测试数据的准备工作，以及为重复耗时的工作开发小工具等。系统测试的主要流程还是由人工把控。

1.3 人工测试与自动化测试的关系

人工测试是自动化测试的需求来源，对自动化测试提出新的需求。同时自动化测试会替代简单重复性的劳动，推动人工测试朝综合性的以价值为导向的方向发展。

2. 如何开展自动化测试

2.1 如何实现测试自动化

没有银弹。任何一款工具，无论是商业的还是开源的，都不能满足具体项目的需求。因为只有充分控制工具本身，才能去控制被测程序。所有自动化工具都要自己写。

# 如何操控被测系统？

测试程序与被测程序运行在同一进程中，直接控制被测程序的行为。

模拟鼠标键盘操作的自动化成本太高，难以维护，不可持续发展。

2.2 如何保证代码级控制模式的正确性

# 测试人员，即测试代码编写者，如何知道调用哪些开发代码以及如何调用？

由开发人员提供相应信息。

# 如何保证这种调用方式和真实键鼠操作的触发效果一致？

由开发人员做好设计，来保证效果一致。

# 如何做好项目组中不同角色之间的合作？

靠良好的流程制度（做好需求与设计）。

2.3 项目的典型流程

一般，一个项目会分成多个迭代版本；每一个迭代中又会涉及多个模块；每个模块都会有业务人员、测试人员和开发人员参与。这个划分不一定会所有项目完全吻合，但下面针对需求和设计的做法是绝大多数项目值得借鉴的。

需求文档、开发设计文档和测试设计文档是项目得以正常进行的重要保障；如果没有通过评审，后续工作无法开展；一旦通过评审，原则上不再更改。

# 强调文档是否违背了敏捷开发的理念？

敏捷并不是纯粹的快速响应需求作出代码变更。敏捷要求“同一件事，做一遍就通过”，减少因需求质量差导致的频繁返工。所以敏捷非常需要良好的需求和设计。这需要强制的流程管理来实现。

3. 如何衡量缺陷预防工作的有效性

比对迭代之间bug数量和自动化测试用例数量之间的差别。

根据发现阶段的不同将bug分为：

a. 开发期间发现的bug

b. 开发完成后发现的bug（即测试人员发现的bug）

c. 测试完成后发现的bug（即production环境中用户发现的bug）。

根据完成阶段的不同将自动化测试用例分为：

a. 开发代码完成时实现的case

b. 测试代码完成时实现的case。

下图是讲师提供的一个示例。根据之前的流程，在需求和设计上加大投入后，在production环境中出现的bug明显减少，绝大部分自动化用例在开发代码完成时已就绪。

4. 其它

4.1 我对代码级白盒自动化测试的理解

我对讲师提到的代码级白盒自动化测试的理解就是“用单元测试的技术去做集成测试”，即需要被测程序的架构对测试友好，同时借助Mocking技术做到关注点分离，提高测试效率。

4.1 性能测试如何做

目标：找到性能瓶颈

方法：确定性能敏感点，对存在敏感点的模块逐个做性能测试

点评：

我对该方法的评价：该方法适合具有良好代码级白盒自动化测试的项目，重在预防性能问题。其优点是执行速度快，可以对其它服务或网络解耦。

讲师的点评：对于缺乏此基础又需要在短时间内解决性能问题的系统，建议使用类似LoadRunner之类的工具。当然其它可以统计代码级运行时间的性能测试工具也可以，方法不唯一，只要能找到性能瓶颈就行。

4.2 用更少的case覆盖更多的场景

找到模块拓扑中的关键节点，以小部分集成替代完整集成。（据说该方法的有效性经过数学原理上的证明，我没有深究）

例如，在下图中模块B是关键节点，A类模块和C类模块的集成必须经过模块B。

如果用完全集成，需要9个case，即“A1_B_C1”，“A1_B_C2”，“A1_B_C3”，“A2_B_C1”，“A2_B_C2”，“A2_B_C3”，“A3_B_C1”，“A3_B_C2”，“A3_B_C3”。

如果用部分集成，则只需6个case，即“A1_B”，“A2_B”，“A3_B”，“B_C1”，“B_C2”，“B_C3”。

4.3 代码覆盖率

代码覆盖率针对代码块和代码分支的覆盖率，不是针对代码行。代码经编译后会形成多个块与分支。计算代码覆盖率就是通过在编译时标记这些代码块与分支（插旗），并在执行时搜集执行路径上遇到的这些标记（取旗），从而得到覆盖率。

4.4 处理带有破坏性的测试

有些测试活动可能会破坏环境，一旦case fail可能导致无法执行后续的case。例如安装测试一般会与操作系统产生直接联系，需要检查环境、删除及拷贝文件、读写注册表等。有些软件删除不彻底会导致无法进行下一次安装。而且有些安装测试需要不断监测大量的环境状态，非常耗时。对于这类测试，需要一个沙盒程序（sandbox）伪装成操作系统，来接管被测程序与操作系统之间的通信。（还是Mocking ^-^）

4.5 系统发布标准

首先代码得写完，Code Complete。在此基础上测试通过率，Pass Rate，得达标。但如果有关键的case没测或有严重的bug，即使case通过率达标也不行。所以还得满足Case Level和Bug Level的标准。在这基础上还要进行全民找bug活动，Zero Bug Bounce，已获得较稳定的版本（很有微软特色）。此外这些测试活动还得达到一定的代码覆盖率，Code Coverage。

4.6 单元测试谁来写

谁来写对项目进展有利，就让谁来写。讲师在微软工作时，项目组开发与测试人员的比例为1:1，单元测试由测试人员完成，开发人员只需负责功能开发。他们奉行的一个项目管理原则是“累死一小部分，造福绝大多数”。

4.7 自动化测试初创

很多项目在初创时并未对系统的可测性给予应有的重视，导致代码累积一段时间后很难直接从单元测试自底向上地开展自动化。对于这种情况，讲师建议先让测试环境和测试数据的准备工作自动化。

我的经验见解是，让开发人员完全背负质量问题的责任，尽量不要往人工测试上追加投入，迫使开发组设计出易于测试的系统。

4.8 版本控制

讲师建议版本控制应当“只有一个主干”，尽量避免在分支中开发。分支合并的代价很高，现实中真正需要分支开发的项目也很少见。

4.9 管理（分配）任务的原则：DACI

每个任务一般会包含4种角色：

a. Driver：任务的推动者。这是任务的Owner，任务成败由其负责，有且只有一个。

b. Approver：任务的批准者，赋予Driver权力，不参与任务的执行细节。

c. Contributor：任务的执行者，但不对任务的成败负责。

d. Informer：提供对任务的指导或其它相关信息（真的只是帮帮忙的角色）。

我的体会：

我们都讲责、权、利三者要统一。所以任务的发起人，即批准者，要对任务有一个比较内行的了解，才能找对Driver，赋予Driver合适的权力。有些东西再努力也没用。例：如果测试人员没有权力去强制开发人员设计易于测试的系统，开发人员又没有完全背负质量问题的责任，那么测试人员费再大劲也不可能创建一个良好的自动化测试体系。

每个任务中，所有这4种人（DACI）都要对自己的角色定位和他人的角色定位非常清楚，绝不能模糊，否则大家都会成为Informer：“我只是好心，来帮帮忙的”。

4.10 计划四要素：Owner、时间节点、预期结果、执行方法

4.11 微软的高层也要每天看bug，对项目非常负责，非常了解

讲师说有一次他在测印度团队写的程序时，发现对方在代码设计上做得不够好，没有做到应有的继承抽象，导致自动化测试代码也不得不写得很丑，于是提了一个Testability Bug。结果第二天美国那边的高层就在bug管理系统里发现了这个bug，马上就发信质问印度团队。印度团队回了封催人泪下的邮件，表明自己有多么努力多么不容易。美国高层对此的反应非常简洁，大意是：

a. 你们有没有按照流程先做设计再编码？（有没有做）

b. 如果你们遵循了流程，是不是做得足够严肃认真？（做的态度）

c. 是不是你们严格遵守了流程，但还是写出了这么烂的代码？（能力）

d. 如果以上回答都是Yes，You can be fired!

于是印度同事老老实实回去重新设计。

4.11 职业化

讲师对职业化的定义：一个模块对其它模块负责，一个人对其它成员负责。

4.11 价值微笑曲线

（老生常谈了）对一个项目要Fully Own，把需求也抓在自己手里，不要只做执行者。