执行与错误跟踪

　   测试计划、测试用例、测试工具、测试体系结构、测试覆盖度量，以及相对稳定的测试系统，有了这些内容，作为测试经理或测试项目负责人仍然不能放松。你需要收集执行数据，调整优先级，适应项目变化。由于数据和变化太多，需要一定的方法进行跟踪测试结果和各种变化。

　　1、错误跟踪系统

　　描述错误会花费很多时间，但描述不清楚或不做描述，将使测试可能带来的质量完善无效。因此使用错误跟踪系统使交流变得容易。

　　1）编写良好的、标准化的错误报告，比形式随意的邮件、对话等效果好。

　　2）如果使用数据库错误跟踪系统，可以方便地进行统计和分析。

　　3）可以排定优先级来决定修改顺序，相关部门和人员参与决定这一问题。

　　4）在软件生存周期内跟踪错误修改情况，防止遗漏。

　　5）可以分析错误发展趋势。

　　6）把未解决的问题及早通知技术支持人员，便于他们开展工作。

　　2、故障描述

　　故障描述一般包括三部分，概要陈述、再现步骤和隔离尝试。

　　概要陈述：简洁陈述、切中要害，能够吸引读者。使用一两句话来描述错误，给客户或系统用户留下深刻印象。之所以称作陈述是因为说明的事项不应包含猜测。

　　再现步骤：对于如何再现故障提供准确描述。再现步骤要求简明但完全，不含糊且准确。该信息作为开发人员调试的第一步，再现问题。如果错误是经多步才可能出现，就有不出现的可能性，改变环境可能使问题不复现。例如从测试实验室转到开发实验室。一般认为，验错需要重复以上步骤3～4次，并至少有2次观察到错误发生，这样进行描述的错误报告才比较可靠。包含了不出现的情况，说明问题的层次深，对程序的逻辑结构、系统环境影响等尚不能完全确定。

　　隔离尝试：说明为了影响程序行为，测试人员尝试了哪些改变。系统表现如何。此处可以解释做某种隔离尝试的理由，可以包含猜测。一般来说这一步是开发测试与最终验收确认测试或第三方验收确认测试的差别。最终验收确认测试或第三方验收确认测试一般只关注测试结论：与用户需求规格说明等是否相符、差别程度如何？不关注错误原因及缺陷细节：需求分析错误、设计错误还是编程错误？错在哪里？

　　1）错误报告描述风格

　　错误应当时记录，如果熟悉错误报告的风格，就不会漏掉应该记录的细节；如果事后再回想再现步骤，可能难以清楚表述；如果再重新测试，可能执行环境和前提条件已经发生了变化。这样等于浪费时间。如果错误发生了变化，说明原来的测试覆盖不完整。

　　好的错误报告告诉读者测试人员发现了什么，而不是测试人员做了什么。

　　防止过于简单，含糊不完整；也要防止概要陈述散乱，步骤冗余，缺乏隔离。

　　2）编写错误报告的十个步骤

　　（1）测试方式：无论你做探索性或依据描述性用例的、手工的或自动的测试，都要认真仔细地测试。

　　（2）再现：一般再现三次，说明测试几次再现了三次。

　　（3）隔离：确定可能影响再现的变量，例如配置变化、工作流、数据集，说明它们如何改变错误的特征。

　　（4）推广：确定系统其他部分是否可能出现这种错误，与隔离结合确定是否存在更严重的问题，注意错误集中现象是否存在，及同一个开发者的错误相似，他/她开发的模块容易出现类似的错误。

　　（5）比较：评审相似测试的结果，发现变化的情况。

　　（6）总结：简述客户或用户的质量体验和观察到的一些特征。这是错误评审会议上惟一必须宣读的，这是客户不满意的来源，是产品未来市场的绊脚石，是开发方、测试方和用户共同特别关注的一些内容。

　　（7）压缩：精简任何不必要的信息，特别是冗余的测试步骤。

　　（8）去掉歧义：清晰避免含糊，避免误解。

　　（9）中立：公正陈述事实，避免夸张、幽默或讽刺。

　　（10）评审：同行或领导评审。

　　3、创建错误跟踪数据库

　　要灵活地存储、操作、查询、分析和报告大量数据，就需要数据库。

　　错误跟踪数据库至少要保存故障描述，包括概要、再现步骤、隔离，还有标识信息，例如：顺序号、项目名字、报告作者，以及报告填写日期。

　　使用错误跟踪系统自动形成的错误报告，一定要有人负责审核把关，防止把一些需要在测试团队内部处理的事情，或者不完全确定的事情，或者不完整的错误报告，传递给其他部门或者客户，造成不好的/难以挽回的影响。

　　4、重要的少，次要的多：错误按重要性排序

　　严重性等级：

　　1．数据丢失、硬件损坏或安全问题

　　2．无解决办法的功能丢失

　　3．有解决办法的功能丢失

　　4．功能部分丢失

　　5．表面的和不重要的

　　修改优先级：

　　1．系统值完全丢失

　　2．系统值不可接受的丢失

　　3．系统值可接受的丢失

　　4．系统值可接受的减少

　　5．系统值可忽略的减少

　　或者按以下分类排定测试错误报告中的问题等级：

　　5级：灾难性的？D系统崩溃、数据被破坏；

　　4级：很严重的？D数据被破坏；

　　3级：严重的？D特性不能运行，无法替代；

　　2级：中等的？D特性不能运行，可替代；

　　1级：烦恼的？D提示不正确，报警不确切；

　　0级：轻微的？D表面化的错误，拼写错等。

　　问题等级大致相当于严重性等级，可以将问题等级0与1合并，然后按下式取值：

　　严重性等级＝6－问题等级

　　严重性等级与优先级有交叉的情况，说明关注点不同。依据前面的说明：

　　风险优先级数＝严重性×优先级×可能性

　　一般用严重性等级（严重度）与优先级相乘确定实际应先修改哪个错误，忽略可能性（错误出现的几率）；如果明确知道功能执行频率的差异，日常操作与月统计功能的执行频率相差很大，可以为可能性分配适当的数值，使之影响修改的顺序。个别情况下错误有一定的相关性，这是应优先修改聚簇的错误。

　　5、设置错误跟踪，添加动态信息

　　需要明确：目前谁负责完成某错误的改正？解决问题进展是否顺利？什么时候能修复错误？

　　5.1 使用状态来管理错误生命周期

　　可供参考的生命周期：

　　1）评审：决定是否需要对某项错误报告进行公开。

　　2）驳回：份量不够，或需要进一步证实，或需要补充信息。

　　3）公开：完全描述并隔离了问题，把问题公布给开发团队，必要时给其他相关方，例如：共同的上级领导或者质量监督管理组织或部门、销售部门（如果临近发布日期）、维护服务部门（以便他们知道该错误的存在，向客户致歉并承诺适当时机将消除错误、更新程序）等。

　　4）分配：错误归类分级à开发经理à开发人员。这一过程至少需要两级确认，首先，测试经理或负责人需要确认错误报告没有纰漏，错误分类分级合理，提交给开发经理时没有异议，或者异议已得到合理的解释，测试团队不需要补充材料说明问题；其次，开发经理明确理解了问题本身，把修改任务下达给开发人员。一般来说，测试团队不需要关心由谁来修改错误，只要能改好就行，所以好像不用关心任务下达，但实际上这里有一个潜在地威胁，即开发团队忙于其他工作，可能暂时搁置这些错误，如果测试团队不了解这一重要信息，将会耽误许多时间等待未进行的问题修改。所以测试团队需要了解修改进程，以便及时与相关方进行协商，或者调整自己的工作安排。

　　5）测试：开发小组报告彻底修复，提交验收测试和回归测试。

　　6）重新公开：修复后的验收测试失败，重新公开错误报告；如果通过了验收测试未通过回归测试，公开新的错误报告。（引入了新错误）

　　7）关闭：如果修复通过验收测试，关闭错误报告。

　　8）延迟：延迟修复，带伤发布。可能下次发布时修复。

　　5.2 强调职责和业务关系

　　跟踪错误分配的人员和预期修复日期，利于估计安排测试工作。如果出现“踢皮球”，错误被多次重新分配，可能严重影响修复和测试。

　　对有关人员的工作进行跟踪：明确开发人员、测试人员的职责和业务关系，以及交流方式和制度，协调并控制好过程，以解决问题：软件错误问题、测试报告问题、交流问题、修改执行问题等等。

　　状态变化时记录日志，说明责任已完成情况。不能当作日记用，事务性记录可能会浪费别人的时间。中间状态可按协约记录。

　　好的错误跟踪系统应能适合两类工作流：正常工作流和特殊工作流。在工作流中各个角色互相配合，才可能尽早到达终止状态。

　　5.3 关键转移：隔离到调试

　　测试组织与开发人员在关键转移：隔离到调试的界限上应达成一致，但实际与期望结果或行为之间常有差异，必须回答以下问题：

　　1）什么是再现错误现象要求的准确性和最少步骤？这些步骤成功再现错误的几率是多少？

　　2）故障说明是测试错误还是被测系统的错误？测试错误：测试系统或测试人员的错误，被测系统的错误：应该报告的错误。

　　3）影响错误现象的外部因素是什么？即使同样的方法，用例可能不一样，描述更是因人而异。

　　4）问题的根本原因：被测系统内部因素？硬件、软件、网络？

　　5）如何能修复问题，而不引入新问题？

　　6）系统变化都正确地调试了吗？

　　7）问题修复了吗？以前的测试现在能通过吗？其余部分是否影响？

　　步骤1证明错误并精化实践，步骤2步骤3测试人员隔离错误，步骤4、5、6开发人员执行调试任务，步骤7返回到测试。步骤3和步骤4之间是测试组织与开发人员关键转移界限，需要细化定义。

　　前4步容易混合，测试人员陷入调试过程，浪费资源。

　　评审错误报告，一定要确保清楚地回答步骤1～3的问题。这样才能划清界限，让测试人员集中精力测试。但当在开发实验室不能再现错误时，测试人员需协助开发人员调试。

　　5.4 引导错误生命周期：错误分类过程

　　除非错误有明显的高优先权且易于修改（如小于20分钟）和测试（如小于8分钟完成确认测试），可以直接与开发人员协商处理解决这类问题，一般应通过正式过程来管理关键转移和修复。

　　方法：通过错误分类或错误评审委员会、变更控制委员会（CCB）来决定如何开展修复工作。

　　错误分类或错误评审委员会：相关代表参加，一般定期开会（如每天一次）确定：错误是否修复？何时修复？进度、预算？影响其他测试进行的错误应优先修复。

　　变更控制委员会（CCB）：还要决定需求、设计、界面、配置、计划等的变更如何实施。

　　错误分类过程依据项目或组织背景变化，需要有效地控制周期和频率，每个错误的讨论不超过5分钟，决定修复或延时。频繁安排会议（如每天一次），让会议不超过一小时，这样易于随时解决测试发现的问题，但关系不太密切的会议参与人员可能不厌其烦，频繁召开的测试问题与软件修改会议只适合直接相关的人员参与，上级领导及其他利益相关方只适合听取阶段性的综合汇报与评审结论，或者参加关键问题的讨论，批准其中的取舍事项。

　　5.5 设置动态标识

　　为测试项目各项任务、活动、及发现的错误设置状态、所有人、预计修复日期、日志，记录进展情况。

　　6、为分析获取错误数据

　　1）与错误相关的信息：子系统、配置、质量风险，故障模式和效果分析。

　　2）错误来源：解决方案和根本原因

　　解决方案：记录编程人员是如何解决的，记录根本原因分析过程和错误分类。（除了本项目需要这些，还可用作后续项目的参考。）

　　错误可能隐藏，不引起可观察到的故障。此时需要全面完整的测试才能发现问题。

　　硬件错误：设计、产品或原料

　　设计错误：错误使用组件，错误理解芯片的局限，不适当的空气流，或者其他错误，如分析比较不够引起的选择失误。

　　产品错误：生产线上的错误，如CPU插入不正确。

　　原料错误：配件供应商的配件有问题，甚至其内置软件有问题。

　　软件错误方面：

　　a）功能：规格说明错误，功能实现错误，测试报告了伪错误。

　　b）系统

　　内部接口，硬件设备，操作系统，支持软件等。

　　软件体系结构：基本设计假设无效。

　　资源管理：设计假设正确，但有些实现的假设是错误的。

　　c）过程

　　算术，初始化，控制或顺序，静态逻辑等。

　　其他：控制流或处理错误。

　　d）数据：类型，结构，初始值，其他。

　　e）代码：输入、拼写、风格错误，编码错误。

　　f）文档：文档与程序不对应，或者不全。

　　g）标准：未符合工业或供应商标准、代码标准、命名规范等。

　　h）其他：不在前述分类中

　　i）重复：错误描述重复。

　　j）不是问题：因误解产生，文档不够细，将正确行为理解为错误的输出。

　　k）坏单元：由随机的硬件故障引起

　　l）需要根本原因：开发人员不提供根本原因解释，但错误已关闭。

　　m）未知的：再现性差的问题

　　3）错误何时结束？关闭日期和注入、检测发现和删除阶段

　　可能出现错误的项目阶段：包括需求、设计、实现、组件测试、集成测试、系统测试、验收测试、发布后。

　　可以用缺陷去除模式分析错误被注入、检测发现和删除的阶段。

　　4）完成错误跟踪数据库

　　错误的注入阶段、发现阶段、去除阶段、严重度、优先权、根本原因等体现错误的基本特征，测试人员、子系统、所有者、配置、质量风险等体现错误跟踪过程中的变化内容，这里有测试任务、修复任务分配问题，回归测试可能多次反复。

　　7、从错误跟踪数据库中抽取度量

　　1）缺陷去除统计：发现/修复图表

　　在系统测试阶段，记录每日的公开与关闭错误数量，就可以形成一个趋势图表，可以包含累计发现/修复、延时的数量，及每日的公开与关闭和延时错误数量，根据这些数量与时间的对应关系就可以做一组折线图反映发现/修复、延时的发展趋势。

　　开发结束，错误数虽然未知但已固定。累计发现曲线与修复曲线开始都是上升势头。中间修复、测试的过程中，修复一个问题，可能引发多个问题。

　　如果累计发现的曲线不平滑，说明很多问题等待发现：开发人员能力不一致或者重视程度不一致，或者测试系统设计或用例数据有问题，或者测试人员能力和状态不一致。

　　当累计发现的曲线低头趣平时，说明发现错误的能力在衰退或者测试接近尾声。当累计发现曲线与修复曲线交叉或接近时。可以对外发布产品了。可能还有未发现的问题。

　　开发过程中，当开发人员从开发程序转入修复错误时，公开累积曲线即累计发现曲线出现一个尖峰，表示部分错误已被消除。

　　如果出现成批延迟的情况，关闭累积曲线可能是跳跃似的，即体现成批的错误在较长时间之后才被消灭。

　　如果没有错误跟踪管理过程，哪些问题已经修复就无法确认。如果从开发到报告错误的时间太长，开发者可能忘了原来的编程思路；或者从发现到报告错误的时间太长，相关人员可能不清楚错误报告的含义。这样不利于错误修复，控制适度紧凑的公开/关闭节奏（例如不超过一周），有利于提高工作效率。

　　2）统计发生错误的根本原因

　　根据根本原因分析的结果和错误分类进行统计，使用前面的错误分类信息以及处理过程信息，为以后的开发和测试工作提供借鉴。

　　应根据分类发生错误的比率，分配注意力，正如前面质量风险优先级数所提示的那样，影响严重的需要优先修改的易发错误当首先进行整改修复，其实这里可能包含两个方面，一是开发人员认识层面的重视，二是错误的消除，接下来测试人员还要进行验证。

　　3）统计开发小组响应？D？D平均关闭周期

　　可以使用每日平均关闭周期和滚动（累计）平均关闭周期，检查错误报告？D？D修复？D？D测试环节有没有问题。