测试计划、测试用例、测试工具、测试体系结构、测试覆盖度量,以及相对稳定的测试系统,有了这些内容,作为测试经理或测试项目负责人仍然不能放松。你需要收集执行数据,调整优先级,适应项目变化。由于数据和变化太多,需要一定的方法进行跟踪测试结果和各种变化。
  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、为分析获取错误数据
  1)与错误相关的信息:子系统、配置、质量风险,故障模式和效果分析。
  2)错误来源:解决方案和根本原因
  解决方案:记录编程人员是如何解决的,记录根本原因分析过程和错误分类。(除了本项目需要这些,还可用作后续项目的参考。)
  错误可能隐藏,不引起可观察到的故障。此时需要全面完整的测试才能发现问题。
  硬件错误:设计、产品或原料
  设计错误:错误使用组件,错误理解芯片的局限,不适当的空气流,或者其他错误,如分析比较不够引起的选择失误。
  产品错误:生产线上的错误,如CPU插入不正确。
  原料错误:配件供应商的配件有问题,甚至其内置软件有问题。
  软件错误方面:
  a)功能:规格说明错误,功能实现错误,测试报告了伪错误。
  b)系统
  内部接口,硬件设备,操作系统,支持软件等。
  软件体系结构:基本设计假设无效。
  资源管理:设计假设正确,但有些实现的假设是错误的。
  c)过程
  算术,初始化,控制或顺序,静态逻辑等。
  其他:控制流或处理错误。
  d)数据:类型,结构,初始值,其他。
  e)代码:输入、拼写、风格错误,编码错误。
  f)文档:文档与程序不对应,或者不全。
  g)标准:未符合工业或供应商标准、代码标准、命名规范等。
  h)其他:不在前述分类中
  i)重复:错误描述重复。
  j)不是问题:因误解产生,文档不够细,将正确行为理解为错误的输出。
  k)坏单元:由随机的硬件故障引起
  l)需要根本原因:开发人员不提供根本原因解释,但错误已关闭。
  m)未知的:再现性差的问题
  3)错误何时结束?关闭日期和注入、检测发现和删除阶段
  可能出现错误的项目阶段:包括需求、设计、实现、组件测试、集成测试、系统测试、验收测试、发布后。
  可以用缺陷去除模式分析错误被注入、检测发现和删除的阶段。
  4)完成错误跟踪数据库
  错误的注入阶段、发现阶段、去除阶段、严重度、优先权、根本原因等体现错误的基本特征,测试人员、子系统、所有者、配置、质量风险等体现错误跟踪过程中的变化内容,这里有测试任务、修复任务分配问题,回归测试可能多次反复。