当测试用例进入了执行这个环节以后，项目组里头最让人悬心的状况，往往就集中在两点上：第一点是任务虽然已经分派下去了，但到底哪些人还没有真正动手去做，完全没人能说得清楚；第二点则是跑出来的各种测试结果散落在不同的地方，有的记在电子表格里，有的留在聊天记录里，还有的夹杂在一大堆截图后面，等到版本评审需要汇总数据的时候，只能临时去到处拼凑，既费功夫又特别容易出错。

　　一、怎么用ALM跟踪测试执行

　　做执行跟踪的时候，不能光去统计已经完成了多少条用例，还要多往深了看几层：任务是不是真的分配到了具体的人头上，失败的原因有没有被清楚地记录下来，那些导致测试卡住的阻塞问题背后，是不是已经有专人在负责跟进。在每一轮测试正式开始以前，最好先把手头的测试范围固定下来，不要一边测一边又往里补新东西，不然范围越扩越大，到最后谁也弄不清到底哪些测了哪些没测。

　　1、先按版本建立测试集合

　　这一步，是按照版本、迭代或者业务模块来建立测试集。我们可以在ALM的菜单里进到【Testing】→【Test Lab】这个位置，再根据版本号、迭代的周期或者不同的功能模块来创建对应的目录结构，接着把这一轮计划要执行的用例挪进对应的目录下面去。有一点需要留心，不要把多个历史版本的旧用例长期堆在同一个测试集里头，不然在执行的时候，各种状态就会很自然地混在一起，想看清楚当前版本的真实进展就变得很困难了。

　　2、给每条用例分配责任人

　　接下去，要在执行列表里面把每一条用例对应的测试执行人、计划完成的日期、优先级的等级和准备用到的测试环境都补充进去。像冒烟测试、主流程的回归、异常场景的验证和兼容性的检查这些不同类型的测试任务，最好是拆开来安排给不同的人，不要一股脑全部压在一个人身上。这样安排之后，再去查看整体进度的时候，就不会只看见一排“未执行”的状态，却完全搞不清楚任务到底是卡在了哪一个环节或者哪一个人的手里。

　　3、持续更新执行状态

　　在执行的整个过程里，要养成一边跑一边顺手维护结果的习惯。用例是通过了、失败了、被阻塞住了还是根本就没有开始执行，这些都需要及时在ALM里把状态改到对应的选项上。通常这类工具会在执行网格那种界面上，把每条用例的最后运行结果直接亮出来，并且最近一次运行的详细报告不但能告诉我们整体是成是败，还能一层层点进去，去查看每一个测试步骤的具体状态、每一步跑了多长时间，还有附带的日志信息，这对于后面复现问题是很有用的。

　　4、让失败的用例关联上缺陷

　　一旦发现了问题，可不能只是在备注栏里丢一句“跑不过”就不管了，而是应该认认真真去建一条缺陷记录，并且把这条缺陷跟出问题的测试用例、当次执行的具体记录，最好还能精确到失败的那一个步骤，三者紧紧地关联起来。不少ALM系统都支持这样的操作，在测试运行的详情页面里就可以去查看、添加或者移除跟缺陷之间的关联关系，这样一来，后面追溯问题的时候，脉络就会变得非常清晰。

　　二、测试执行结果该怎么汇总

　　到了汇总执行结果这个阶段，要紧的是盯住当前这一个版本去整理，不要只从系统里胡乱导出一份长长的表格就交差了。参加评审的那些同事真正需要看到的，是这一次测试执行整体的完成程度、不同类别的通过比率、失败都集中在哪些功能模块上、导致阻塞的根本原因到底是什么，还有跟失败相关联的那些缺陷目前走到了哪一步处理状态。

　　1、先按版本和测试集做过筛选

　　所以，我们要做的头一件事就是把统计的范围先圈精准，进到【Testing】→【Test Runs】或者对应的执行结果页面里，用版本号、测试集、执行的日期区间以及负责测试的人员这几个条件交叉筛选，把想要统计的那一批数据先过滤出来。假如不经过这一步，不同时期不同版本的数据全都搅和在一堆，那最后算出来的数字就彻底失去了参照的意义。

　　2、再把执行状态汇总起来

　　范围固定好以后，就要把执行的状态实实在在地归纳起来，至少也得知道这几项：用例的总数、已经跑完了多少条、里头通过和失败的各是多少、被阻塞的有多少，还有连动都还没有动的有多少。写测试总结报告的时候，一定要把还没有开始执行的，和被阻塞住跑不下去的用例单独列出来，不能只抛出一个简单的通过率就不说了。有些版本表面看去通过率的数字挺好看，可实际上还有大把的用例根本没来得及跑完，要是只看个通过率，里头藏着的风险就完全给遮住了。

　　3、导出执行记录时注意格式

　　如果项目要求提交一份书面形式的测试执行表格，那我们可以在Test Runs里面把全部或者选中的部分记录勾上，再顺着【Edit】→【Export】这一条路径，选择把选好的记录导出成Excel、Word、HTML或者纯文本这类文件。这样形成的执行报告，既能展现整个测试集的总体状态，也可以把每一条测试运行的详情附在后头，方便不同角色的人各取所需。

　　三、怎么把执行数据用到版本评审里

　　结果汇总这件事，可不是把几个数字填进周报的模板就算画了句号，一个版本到底能不能继续朝着发布的方向推进，关键还要看那些已经暴露出来的阻塞问题有没有被真正疏通，失败的用例有没有被放回到修复的链条上，以及与其相关的缺陷是不是已经形成了处理闭环，而不是挂着一个“处理中”的状态就再没有下文了。

　　1、重点看一看被阻塞的用例

　　所以在这一个环节，目光应当优先放到阻塞住的用例上头。因为这种状态一出现，往往意味着测试环境已经不可用了，需要依赖的外部接口还没有交付，测试数据还缺着很大一块，或者是挡在前面的那个前置缺陷一直没有被修好。不少ALM工具的健康报告都会特意把Blocked Tests和那些失败了却没有关联任何缺陷的Failed Tests without Defects单独突显出来，目的就是帮项目组能快一点识别出眼下最要命的执行卡点。

　　2、把实际进度和计划放在一起比一比

　　还有一点，测试刚启动的时候就应该在工具里设好一个计划上的完成时间，等执行真的跑起来以后，再把实际的进度跟当初的计划摆到一张图表上去做对比。在ALM的报告功能里，通常能找到类似Test Execution Planned vs.Actual这样的对比视图，用它可以连续观察测试的执行工作是不是已经明显滞后于最初的时间安排。

　　3、保留住每个版本的基线

　　另外，每一次快要踏入版本评审那道关口之前，还应该把这一轮测试的覆盖范围、当前最新的执行结果，还有整张缺陷列表的状态，一起存成一个版本的基线。这样做的好处很直接：后面万一发现统计数据不大对劲，或者某些数字突然起了奇怪的变化，就可以拿着保存好的基线往回翻，去判断究竟是因为新加了用例、把之前跳过的部分补跑了一遍、某些缺陷被陆续关闭了，还是统计本身的口径被人手误改过。

　　总结

　　概括起来看，用ALM来跟踪测试的执行，它的关键无非就是按照版本建立好清晰的测试集，把每一项任务都分配到具体的人，全程持续不断地把最新的执行状态维护住，并且在失败出现的头一个时间点把失败的步骤和冒出来的缺陷紧紧关联在一起。而到汇总执行结果的阶段，重点则是先要钉死统计的范围，再把通过、失败、阻塞、未执行以及缺陷这几大块数据有条理地梳理出来。只要能把每一次的执行记录、缺陷的修复进度和版本发布的关键节点穿成一条线来分析，测试结果才能真正帮上版本发布的决策，不至于永远只停留在一张临时赶出来的统计表的层次上。