敏捷思想在软件测试领域的应用和实践

文/屈晓光 胡玉露

当前的测试工作属于软件开发周期中的一个环节，测试人员主要负责产品的需求分析，写出相应的测试用例，在版本发布之后，由项目经理安排测试任务，测试人员参照测试用例完成测试任务。

这样的测试流程比较简单，执行起来通常也比较“顺畅”，但实际上长久以来对测试工作的过程监控、结果度量，以及测试人员素质的提升都是一个比较棘手的问题，传统的管理手段在应用在测试方面显得捉襟见肘，而测试人员基本上都是在很被动地接受工作、完成工作，测试的整体效率不够高。

敏捷思想作为一个强调价值观、强调自组织团队的开发方式，能够较好的解决当前遇到的问题。

1 传统工作模式遇到的问题

传统的工作模式和管理手段在测试活动中通常会体现出如下这些问题：

（1）目前测试人员采用的系统执行用例，在完成一个用例之后，把用例状态改成“Pass”即可，这就存在输出结果过于简单，完全无法衡量测试人员的测试质量，也就是说测试的结果完全取决于测试人员的责任心，而责任心恰恰是最无法保证的。

（2）测试任务的分配存在很大的不合理性，由于项目经理对测试用例的执行时间很难有一个较为清晰的把握，所以在下达任务的时候存在任务工作量严重不合理的现象，而又由于缺乏及时的监控和调整，所以任务的不断延期基本上是家常便饭。

（3）另一方面，即便任务没有延期，由于计划的不合理性，后期的测试用例的执行质量和前期的质量也是无法相比的，整体来讲测试质量处于不可控的状态。

（4）团队力量无法发挥，测试重点的安排、任务的安排，基本上都是有个别人决定，测试人员只是被动地接受任务。

（5）团队之间缺乏交流，测试方法、系统知识的传承比较随意，导致测试人员的素质参差不齐，成就感普遍不高。

2 敏捷思想简介

众所周知，敏捷（Agile）是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法，而Scrum方法则是敏捷思想中应用较广的一种过程管理方法，Scrum 一词来自英式橄榄球（Rugby）比赛。敏捷实践团队就好比一支橄榄球队：他们有明确的最高目标，而且每时每刻都朝着目标努力；他们熟悉最佳实践，高度自我管理，高度协作，高度灵活地面对各种挑战。大量的调查统计表明，敏捷开发确实大大提高了软件开发效率和软件质量，帮助软件企业提高了效益，并更利于个人的成长。因为敏捷的核心就是“以人为本”，人的问题上升到了企业管理、企业价值观和文化的层面，敏捷决不是一个简单的软件过程。如图1所示。

3 Scrum方法简介

3.1 Scrum方法的主要流程

前面已经简单提到了Scrum方法，下面主要介绍Scrum方法的主要应用。Scrum之所以是应用最广的敏捷开发思想，是因为它有一套比较完善而且行之有效的方法为支撑，这种方法不但适用于开发领域，而且在测试、文档开发等领域都有着很好的应用。它引入“可视化”管理的思想，通过“看板”的方式，把项目任务、进度、困难等实时显示出来，对任务的跟踪，及时调整很有帮助。图2是Scrum的开发模型，里面的很多方法可以直接应用于测试领域。

这里对上图进行简要的介绍，以及在测试领域的可能的应用方式：

（1）Product Backlog：是指产品的需求列表，在系统测试领域可以是指待测试的条目、规程；

（2）Sprint Backlog：是指一个迭代中需要完成的需求，在测试领域同样可以指根据优先级、重点程度、工作量等安排的一个测试周期；

（3）Daily Meetings：是指每日例会，这个可以直接应用到我们测试领域中，用来实时跟踪每个人的测试情况和遇到的困难；

（4）Sprint Burn Down：即燃尽图，可以跟踪全任务（Scrum）也可以跟踪一个Sprint周期内的任务执行情况，对于测试而言，可以直接应用到我们的一个版本测试周期中，也可以结合我们的压力平台，定期公布和跟踪；

图1：敏捷方法占比图

图2：Scrum方法流程图

（5）Sprint Review Meeting：即评审会，在每个Sprint结束之后，对这个Sprint的执行情况进行简单的一个回顾和评估，对于没有完成的任务进行分析，同时安排到下一个迭代周期中去，这个也可以直接应用到版本测试中。

图3是一个迭代周期内的流程，其中评审会，每日立会上面已经介绍过了，一个全Sprint生命周期一般包括：计划会、评审会、回顾会和产品（Sprint）发布，以及每日的站立会议。

3.2 Scrum方法的主要角色

PO、SA、DEV、BA、SM、QA。

3.3 Scrum常用方法介绍

Scrum中常用的几个管理方法是管理实践的重中之重，是改变传统工作方法的关键，这里再详细描述一下。

3.3.1 每日立会（Daily Standup）

（1）时间控制在10～15分钟，初期人数最好能控制在5人左右，否则时间上很难把握；

（2）迟到将受惩罚，以保证大家对待敏捷开发的严肃性；

（3）自问自答三个问题：

1.昨天做了什么（I complete…）;

2.今天要做什么（I will complete…）;

3.遇到了什么问题；

（4）更新燃尽图（burn down chart）。

3.3.2 计划会议

3.3.3 回顾会议

（1）时间在1-3个小时

（2）找最舒适的地方（要有回顾看板）

（3）开始的时候轮流发言，而不是主动发言

（4）记录问题，总结，并讨论改进的方法，放在回顾看板上

（5）大家用纸条写出自己的改进意见，然后投票选出若干最重要的2-3个改进点（测试项目），成为下一个迭代周期的测试内容；

（6）大家对测试内容进行认领，并建立团队改进卡；

（7）一般推荐用海星图来做绘图（见图4）。

4 敏捷思想在测试工作中的推进

敏捷的思想和传统的工作方式有着很大的不同，所以推进起来也不可能一蹴而就，下面就根据我们的具体情况，分阶段进行推广。

4.1 敏捷推进过程——起步阶段

起步阶段可以安排在一到两个月的时间内完成，主要是给大家一个预热和心理准备过程，可以细分为如下几个步骤：

现状分析—→敏捷导入培训—→初步试点—→问题反馈—→效果检验

（1）现状分析：在这个阶段需要对我们当前测试工作进行分析，找出效率低下或者流程不畅的地方，从上面第一节的分析中可以看到，在现实的测试过程中还是存在很多问题的；

（2）敏捷导入培训：对敏捷开发思想，以及敏捷如何解决当前测试过程中的各种问题进行简要的介绍，让大家由“预热”进入“备战”状态，完成心理上的过渡过程；

（3）初步试点：为了避免对现有工作进度的影响，敏捷开发的推广可以在次要项目上推广试点，毕竟因为敏捷实施的初期，效率是下降的，所以不适合对时间要求毕竟严格的项目；目前部门在自动化工具的开发上引入敏捷流程，是一个不错的选择。另外，对于每日站会、回顾会也可以先引入到版本测试中来，让更多的人参与进来，感受到敏捷开发的好处；

（4）问题反馈：实施一段时间后，可以收集参与者的意见或者建议，对于实施不畅或者大家意见较大的部分进行裁剪和修改；

（5）效果检验：也即对这两个月实施敏捷过程以来的工作进行一个回顾，并和以往非敏捷的工作进行一个对比，强化大家实施敏捷的信心。

4.2 敏捷推进过程——成长阶段

一旦大家适应了敏捷开发的过程，我们就可以开始选取典型项目进行Scrum方法的推广和实战。根据以往的经验，第一阶段的推行的敏捷方法（例如在自动化测试上）总是会有延期或者执行不到位的地方，所以在我们的“成长阶段”对之前的自动化测试进行回顾和总结，再重新执行一次严格的Scrum方法，同时绘制burn down图，跟踪任务执行情况，这次不仅仅是scrum方法的重新执行，而且还需要重新增加新的功能，优化已经完成开发的任务，让大家对scrum过程有新的体会和认识。

在版本测试（或者测试设计）上也引入敏捷开发的流程，通过跟踪和记录执行过程中的各项KPI数据（故障发现率、测试用例执行率等），同非敏捷开发时的相关数据做一个对比，来检验敏捷过程的执行效率。

敏捷开发可能不一定会让效率会得到很大的提升，但对测试人员综合素质的提升是非常有效的，所以对测试人员工作技能、深层次故障的发现，也可以作为我们评估的参考因素。

4.3 敏捷推进过程——成熟阶段

进入成熟阶段的标准是，大家已经自觉养成了敏捷开发的习惯，之前的试点项目基本上能够按照scrum方法进行。鉴于敏捷开发是一个持续完善的过程，所以这里仍旧需要对前一阶段的执行工作进行一个Retro，有针对性的改进。

XP编程中的一些思想在这一阶段可以应用进来，比如Pair Coding（结对编程）、CI（持续集成）、TDD（测试驱动研发），当然这些方法目前仅仅是对软件开发而言，对于系统测试领域，还没有合适的方法。不过我们可以借鉴这些思想，比如我们可以Pair Testing（结对测试），也可以仿照开发同事的Code Review，进行Bug Review或者测试方法的Review，TDD是一个很好的改进开发质量的方法，这里我们也可以试点测试设计驱动测试执行（Design Drive Testing，可以简写为：DDT）。这些方法的推广是很有利于提升测试人员的综合素质的，而测试人员素质的提升则是我们提升测试质量的保证。

5 敏捷思想在测试工作中的推进

5.1 测试方法上的改进

关于测试方法的改进上面简要提及，下面分别作以介绍：

如图5所示，仿照XP（eXtreme Programming）的命名方法，我们可以将我们的测试方法称之为XT（eXtreme Testing），也即极限测试。对于Pair Testing和Pair Design来说，主要应用于新增需求的测试执行和重大的（综合性质）的需求的测试设计，这样就能够保证测试执行和测试设计的效率，但需要注意下面两点：

（1）不是所有的需求都需要Pair Testing和Pair Testing的，在做pair之前，需要对待结对的需求进行评审和初步分析，确实有必要再进行结对设计和测试；

（2）结对需要经常更新，并跟踪结对过程中出现的各种问题；

图3：迭代周期流程图

图4：海星图

图5：极限测试命名方法

对于故障Review或者测试方法的Review之前我们一直都在做，这里是把它固化起来，作为培训的一部分存在，有利于经验的传承。而DDT则是套用原有的思想，即在测试设计开始之前，就确定如何测试，也即对研发的每一个改动点都能够对应一个测试项目，既要确保研发的实现能够满足需求，也要保证该实现不会对现有功能造成影响。

5.2 管理方法上的改进

5.2.1 看板设计

“看板”（Story Wall）是“可视化”管理的核心，所以设计一个合理的“看板”非常关键。图6是一个典型的看板所包含的内容：

在具体应用中，我们可以重新设计为图7的样子，这样更加合理和清晰：

图6：看板图1

图7：看板图2

图8：技能雷达图

通过上述“看板”我们能够很清晰的看到本次迭代中要完成的所有任务的当前状态、遇到的问题、非预期的新增任务或问题，可以帮助我们理解当前做的如何，以及下一步骤要做什么，令团队能够自我指导。不同颜色可以用来代表不同的任务类型，如测设执行、测试设计、文档等，状态则有“TO DO”、“DOING”和“DONE”三个区域来表示，基本能够满足需求。

右上角的Sprint Goal和Burn Down Chart，展示当前Sprint任务总体完成情况及趋势图，接下来的ISSUE版块则用来跟踪当前遇到的问题，而UNEXPECTED则用来记录该迭代过程中的新增任务。

上面是项目的“看板”设计，科室团队建设我们也可以采用看板的形式，在会议室可以专门给各个科室划出一片“自留地”，由各个科室去开发和使用，主要用来活跃气氛和增进科室团队成员之间的了解。

5.2.2 培训工作

目前部门也采取了很多手段进行培训工作的改进，这里我们也借鉴敏捷的方式，建设团队所需的知识雷达图（如图8所示），以每天session（会议，可以定在每天下班前的半小时，以防止不能收敛）的方式来开展。

对于雷达图的简要说明如下：

（1）上图是一个敏捷开发团队三个月内需要掌握的技能，经过1个月或者3个月的学习，对于列出来的知识点需要达到“胜任”的状态，也即能够满足工作需要；

（2）技能是有团队成员提出，经投票选出哪些应该放到1个月内学习（1M）、哪些放到3个月（3M）内学习；

（3）每三个月对这个技能雷达图进行一次评估，决定哪些应该更新，哪些应该撤掉；

（4）对于这些列出来的技术需要满足两点：一是团队所必须的知识点、二是必须是团队能够达成的知识点；

（5）雷达图和知识卡片是对应的，要求每人每天写一个雷达图上所列技能的知识点，在午休起来后大家围坐起来给其他人分享；

（6）雷达图推荐四个象限，但不局限于四个象限，可以视需要而定。

（7）雷达图对知识点的掌握程度没有一个标准，只是通过每天的知识卡片进行分享和积累，相对来说有点零散而缺乏系统性，只有长期坚持才能取得理想的效果。

6 结束语

敏捷的实践是一个长期的、逐步改进的过程，尤其是敏捷的一些管理思想和方法，在应用到我们日常的工作中效果都很好，但XP的一些方法在应用的时候需要循序渐进，毕竟该方法对人员素质、开发方式要求都很高，在初期应用过程中会必然的造成效率的下降。应用时，还应根据个人情况而适当裁剪，不能一股脑的把敏捷的各种方法都堆上去，这样很有可能适得其反。