3.4 提高测试效率的有力武器：测试流程之设计

测试流程并非一些数字或文字的简单排列。合理可控的测试流程，犹如一条两边带有防护网的钢索桥，大家走在上面，既安全又可靠。即使是新加入测试团队的成员，也可以很安稳地度过一关又一关，把每一环节的测试工作顺利地贯穿起来，形成一个可见、可控、有序的测试系统链。

下面通过两个案例“让大家一起忙起来”和“软件运行得犹如蜗牛在爬行”介绍如何把工作中出现的问题，通过改进测试流程的方式来解决。这种流程的改进正是一种适合公司业务发展的流程设计。

3.4.1 认识测试流程

当在工作中出现问题后，常会听到一些测试人员说“是不是测试流程有问题？”那么这个测试流程到底是指什么呢？

从狭义上讲，测试流程是指完成某项测试任务时，对如何完成任务做的先后安排，如先有测试计划，然后是设计测试方案及测试用例，接着是执行测试活动，最后输出测试报告，一件测试任务到此结束。然而，在实际工作中，测试的依据是需求，测试的对象主要是软件，不可能与其他团队成员没有联系，测试流程中需要考虑这些因素对测试各环节输入/输出的影响。

从广义上讲，测试流程是所有关于测试事务的抽象统一体，流程有静态性，同时也有动态发展的特点。从静态来看，主要指已有的测试流程规范，包括测试工作指南、测试计划、测试方案、测试用例设计模板等，这些属于测试流程体系中的文档输出指导范畴。还有属于测试管理流程范畴的内容，包括测试新员工入职指引、项目测试手册、测试配置管理手册、测试知识经验库、培训库等。还有如功能测试方法库、系统测试方法集、经典Bug分析集，灰盒测试、白盒测试指南等一系列技术性的流程、规范或指南。这些流程体系、知识库的积累，并不是一朝而就，是一个测试团队成长的重要标志。也正因为如此，流程体系有动态发展的一面，随着公司内外环境的变化，固有的流程体系有些可能过时，有些仍可继续使用，需要根据不断变化的需求做合适的调整。

测试并非空中来客，也非外星人那样另类、独立。需求、开发、测试在软件产品的整个开发链中，三者之间的关系特别紧密，犹如一个三足鼎立的主体，如图3-9所示。它们之间的工作方式可以是串行式，也可以是迭代式，当然也可以是并行式工作，这取决于研发团队采用什么样的开发模式。项目的研发是公司的生命线及核心竞争力，对公司的发展承担着重要角色。同样地，一个项目的开发模式，对测试流程体系的建设与发展变化有着重要意义。通常情况下，意味着对原流程体系的局部保留与改进，但也可能需另立一套全新的流程予以支持。总之，对待测试流程不能仅是看静的一面，静只是暂时的，它犹如行程中的流水，需适时适地顺势而变化，方能流得更长更远。

测试流程的实质是一种资源平台，且是核心资源，但与其他资源，如人力、物力资源相比，它具有一定的独特性，多数情况下流程看不见、摸不着，甚至说不清、道不明。然而测试的流程又确实存在于测试组织运作的方方面面，直接影响着所有测试人员的绩效，这就是流程隐含着的魅力。测试流程虽是一种资源，但不具有独立性，若是脱离了人这个主体，流程是无法创造价值的，几乎不名一文。

通过前面的流程内容介绍可看到，所有的流程规范都是设计出来的，是设计的结果。实际上正是透过各测试环节任务的安排，将测试的资源（流程规范）以适当的活动转化成了为测试所提供的服务。

3.4.2 让大家一起忙起来

本节的案例“让大家一起忙起来”是测试流程改进设计的一个典型案例，通过案例的分享，希望能帮助读者理解测试流程对提高整体测试效率的重要性。

【案例】让大家一起忙起来

问题背景：在产品的研发阶段，出现开发在提交内部版本给测试后，由于暂时没有新需求要实现，也没有Bug需要解决，开发人员处于闲置状态。

问题分析：测试在接到新版本后，首先是回归已解决的Bug。特别是，当前有比较多的Bug需要回归时，新提交的功能得不到及时的测试，而往往新提交的功能是存在新Bug的。但在这种工作流程模式下，新Bug不能在提交版本后的前期发现，造成了前期测试紧张而开发暂闲的状态。而在版本测试的后期，由于开发人员需解决不少的Bug，且要进行版本联调，在后期的任务显得很紧张。而此时测试反过来是处于相对闲的状态，出现等候开发提交新版本来测试的现状。如图3-10所示为原开发—测试合作流程图。

解决措施：针对此开发与测试的工作模式在流程上的问题，提出测试执行人员先不回归Bug，拿到新版本后，先测试新的功能，提交Bug让开发人员改，改变开发人员普遍性的闲置状态。当开发在改Bug时，测试再回归已解决的Bug。这样一来，开发与测试同步忙起来，流程上顺畅多了，项目进度得到了保证。这是一个典型的流程控制方面的测试设计。如图3-11所示为改进后的开发—测试合作流程图。

3.4.3 软件运行得犹如蜗牛在爬行

测试设计不只是测试设计工程师的事，需要团队中每一个成员的共同努力，哪怕是主动地反映遇到的问题，下面介绍一个真实的典型案例。

【案例】软件运行得犹如蜗牛在爬行

一个平常的工作日，将近下班时间了，刚参加完关于内存泄漏测试方案评审会的测试设计工程师赵函，习惯性地每天这个时候进入公司的缺陷跟踪系统，跟踪执行人员提交的Bug。其中一个Bug立刻吸引住了赵函的眼球，Bug描述是这样的：“仪器测量完成后，测量结果显示在界面的过程如蜗牛在爬行，响应缓慢（刷新完毕约1分钟）”。赵函马上找到提交Bug的工程师了解详细情况，并查看这个蜗牛爬行的显示过程到底是怎样一种现象（蜗牛爬行的平均速度是每秒钟0.5厘米，如图3-12所示）。不看不知道，此问题不仅仅发生在测量结果显示的处理上，切换到其他任何一个界面同样异常缓慢，这不是明显影响测试的效率吗？于是马上找相关开发工程师一起分析、定位问题，并要求重发版本给测试。后来开发查明是因为某个开发工程师提交版本时忘了关后台的调试信息打印开关。

此Bug是下午2点钟提交的，也就是说测试执行人员在这样的版本上忍受了近4个小时的测试，竟然没人提出要终止这样的版本测试。问及执行的测试工程师时，回答各执一词：“我不用老是切换界面，没有多大影响！”“我已提了Bug，软件慢我也没办法呀！”“开发已知道了，下一版会改的。”

“我们的测试同胞都是逆来顺受的？还是哪个流程环节上出了问题？”赵函这样想着，找来了开发与测试经理，商讨避免这种问题的对策。据调查，负责版本发布的开发人员在版本发布前是有按流程进行冒烟测试的，但遗憾的是，这是在测试环境上确认的功能，不是在真实环境下的用户场景中确认的。而测试工程师也没有流程来支持，遇到这种情况如何处理？

最后商讨的决策是改进开发与测试版本传递的流程定义，明确具体的细节。

要求负责版本发布的开发人员，在版本正式提交给测试前，必须在真实的用户场景环境下运行软件，确认实现的新功能或更改的正确性，并做确认记录，此记录随同测试传递表，以及软件版本一起提交。

增加测试接收版本的约束：增加版本接收确认环节，时间不超过2小时，如出现严重或致命Bug，影响测试工作的开展，通知测试经理，停止当前测试。