第9章软件测试过程所需的技能.ppt

《第9章软件测试过程所需的技能.ppt》由会员分享，可在线阅读，更多相关《第9章软件测试过程所需的技能.ppt（85页珍藏版）》请在三一办公上搜索。

1、1,第9章软件测试过程所需的技能,2,本章内容提要 软件测试文档的编写 软件测试用例的设计 缺陷的报告和分析 问题跟踪系统,3,9.1 软件测试文档的编写,和程序员开发程序必须编写程序规格 说明一样，测试人员在测试过程中也需要编写例如测试计划或是测试用例的测试文档。良好的测试文档可以提供以下三个主要的功能：1.为完成测试技术任务提供了便利 为了编写一个好的测试计划，在开发该计划时必须以一种系统的方式对程序进行调查，从而使得对程序的处理更加清晰、彻底和有效。在测试的规 划期间创建的清单和图表会以如下的方式 提高测试程序的能力。,4,（1）提高测试覆盖率：测试计划要求有一个程 序特征清单，要列出该

2、清单就必须找出所有的 特征。如果在测试中使用该清单，就不会遗漏掉任何 一个特征。常见的有用的做法是在清单中列出由该 程序创建的所有报告，以及所有错误信息、菜单选 项、对话框，每一对话框的所有选项等。创建清 单时越仔细彻底，遗漏的东西就越少。（2）避免不必要的重复和遗忘项目：当核对测 试的清单或图表上的项目时，可以很容易地 看出已经测试过的和还没有测试过的项 目。,5,（3）分析程序并提出好的测试用例：例如 在图形用户界面的数据输入项，每一个边界 值都是一个很好的测试用例，因为边界值要 比非边界值更容易发现缺陷。（4）削减测试数量：不是从本质上增加遗漏缺 陷的数量，而是改进测试的效率。其中的诀窍

3、 在于确定那些足够相似的测试用例，这样就可 以预期从每一个用例中获得同样的结果。接着 只使用这些测试之一，而不是所有。,6,（5）提供最终测试的结构：当所有编码工作完 成，系统的每部分看起来可以一起工作了，最 终测试就开始了。但是现在的产品发布都存 在着很大的压力，只有很少的时间可以用来 安排最终测试。所以以前测试的优秀笔录 将帮助确保最后一次运行了重要测试。如果 没有这些笔录，就不得不记住哪些测试需要重新运行。（6）检查完整性：不完整的测试计划会不同程度 地遗漏程序中的缺陷。测试计划通常会因 为忽略了程序区域、缺陷类别、测试 类别，或是简单疏忽而存在漏洞。,7,2改善了测试任务与测试过程间的

4、联系,（1）交流了测试人员策略背后的思想。（2）得出测试准确度和覆盖率的反馈。文档的读者会告诉你忘记测试的程序区域，你对程序某些方面 的误解，以及未反应出的产品最新变化。（3）得出测试深度和时间进度的反馈。有些测试计划会产生许多关于测试数量的争议。一些项目经理 辩称测试计划要求的测试过多，这样就产生了不 必要的进度延迟，而其他项目的经理可能会抗 议说测试太少了，想要延长测试进度或者增 加测试人员从而增加测试的数量。,8,不管是否存在测试文档，上面的问题都会浮现出来，而测试计划则有助于集中讨论，并 使得达成特定协议更加容易。当一个清晰、详 细的测试计划可供参考时，这些讨论就会更 加理性，现实和实

5、用。（4）交流测试工作的规模。测试计划显示出了要进行的工作以及已完成工作的数量，这会帮 助经理及其他人理解为何你的测试小组规模 如 此庞大，而且要花这么长的时间来完成。如果项目只对如何更快或是不那么昂贵 地执 行项目感兴趣，那他就会考虑 简化或者淘汰最难以测试的程序区域。,9,（5）分派工作。如果你能够给下一个测试 人员提供一个书面的详细指令集，那么委 派及监督产品的部分测试就要容易得多。3为组织、规划与管理测试项目提 供了结构（1）达成有关测试任务的协议。测试计划明确指出测试人员将要做（或不做）什么工作。让其他 人对这个计划进行评审，包括项目经理以及相 关的经理、程序员、测试人员、营销人员，

6、以及 可能在项目中提出更进一步测试要求的其他 人，尽早利用评审引出不同意见，讨论并 解决。,10,（2）确定任务。一旦你了解了要做什么，就能估计并证明所需资源（金钱、时间、人员和设备）是否有效。（3）结构。确定任务时，可以看到很多概念上相关的以及方便共同进行的事情。把这些任务 集分组，并把某组中的所有任务分配给同一 个人或同一小组。一组接一组地集中测试。（4）组织。一个全面开发的测试计划要确定由谁执行什么测试，如何测试，何时何地，利用 什么资源完成，以及为何要完成这些特 定的测试或测试集。,11,（5）调整。项目经理或项目的主任测试员把测试 计划作为一个委派工作以及告知其他人某人已 分配了什么

7、工作的基础。及时跟踪正在执行 的任务，以及那些花费了比预期的时间更长 时间的任务，必要时迅速调整人员和设备 的分配。（6）改进个人责任。测试人员明白他应该对什么负责。委派工作时，如 果你对任务加以描述并对你的期望值进行解释，测试 人员就会对你有更好的理解，并且认真地对待分配的 任务。,12,确定一个重要的测试的计划问题。假定你把程序的某 个区域分配给了某个测试员，他报告说已经对其进行了测试，接着有人发现该区域存在一个可怕的缺 陷。这种事情时有发生。一个详细的测试计划可以 帮你确定计划或者某个独立测试人员是否存在问题。确定一个重要的测试计划的设计问题。如果测试人员 没有发现一个特别令人尴尬的缺陷

8、，只是因为测试 计划中没有包括对该缺陷的测试，那么测试计划 是否就存在问题？我们再次强调，测试计划通常 会遗漏缺 陷，这是个不幸但很正常的情况。不要仅 仅因为某个 被遗漏的缺陷令人尴尬就修改过程 或者找替罪羊。,13,（7）衡量项目状态并增加项目透明度。测试 计划的进展报告能有效地度量到目前为止所 付出的测试努力和预测的进度。如果在项目开始时就写下完整的测试计划，就能够预测通过该 测试计划要花多长时间，在项目完成前你期望 它运行多少次（或者通过它的一个回归测试子 集），以及每一测试周期何时开始。在项目 的任何时间点上，都应该能够报告进度，并与 你的初期期望值进行比较。这些报告反映了测试速度，以

9、及对所谓整体项目进度的真实性检查。这 类状态报告能够在为你判断一个基本的项 目人力水平（供预算使用）上起到重要 作用。,14,根据IEEE829-1998 标准有以下测试文档,测试计划测试设计规格说明书测试用例规格说明书测试过程规格说明书测试项目移交报告测试日志测试突发事件报告测试总结报告,15,9.1.1 软件测试计划,测试计划是我们工作中会遇到的最基本 的测试文档。测试新手一般不会被安排为测试项目做全面的测试计划，通常这是由测试负责人或测试经理来做。而测试员一般是协助建立测试计划，因此需要了解计划测试工作包括哪些内容，测试计划需要哪 些信息。,16,1测试计划的目标 测试计划是提供产品测试

10、工作的概述，根据IEEE829关于软件测试文档的标准，测试计划的目 的是“规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险”。尽管测试计划采用的都是书面文档的形式，但是测试计划文档只是创建详细计划过程的一个副产品，重要的是计划过程本身，而不是产生的最终结果文档。所以说测试计划过程的最终目标是 交流（而不是记录）软件测试小组的意图、期望，以及对将要执行的测试任务的理解。,17,2测试计划的内容 根据IEEE829标准，测试计划包含以下几个部分。我们希望你不要因为要使文档与IEEE标准保持一致而感到约束，该标准只是提供

11、了一个仔细思考过的背景，你需要把它应用到你的需要中去。另外，不要在测试一开始就强迫写出所有的东西。该标准有助于预先写出测试计划的第一稿，然后在继续工作时再逐渐编写和细化剩余的部分。,18,测试计划标识符：一个唯一的名称或编号，如果在一个数据库中存储了所有文档的话就很 有用。简介：包括对所有相关政策和标准文档的引用，以及高层产品计划。测试项：一个测试项就是将要测试的一个软件项（功能、模块、特征等）；列出所有的测试项或者参考一个列出所有这些项的文档；同时包括对规格说明（如需求和设计）和手册（如用户操作和安装）的引用。测试的特征：列出哪些特征要测试，哪 些特征不进行测试以及不测试的理由。,19,方法

12、：描述测试的全面方法谁进行测试，主要行为、技术（例如使用白盒测试还是黑盒 测试技术），以及为每个主要特征组使用的工具（例如自动化测试工具是自己开发还是购买商业工具）等。测试项通过/失败的准则：测试人员如何断定程序是否通过或未通过给定的测试。测试交付物：列出所有要为该产品编写的测试文档。测试任务：列出准备测试和执行测试必需的所有任务；说明任务之间的相关性，完成它们所需 要的特殊技能、人员等资源，谁完成任务，牵扯多少精力，以及每个任务何时可以 完成。,20,环境需求：描述必需的硬件、软件、测试工具、实验设备等。责任：为管理、设计、准备、执行、证明、监察、改正、解决等的小组（或人）指定责任。人员及培

13、训：包括每个技能水平你需要多少人，他们需要进行多少培训。测试进度：列出所有带日期的里程碑，以及何时需要所有资源（人员、机器、工具和设备）。测试进度可以使用固定日期，也可 以使用相对日期。,21,风险和意外事故：明确指出项目的潜在问 题或者风险区域，这是对测试工作最有影响的因素。核准：谁必须批准这一计划？为他们的签名留出空间。根据IEEE829标准，我们提供了一个可以作为参考的系统测试计划模板。各个公司可以根据自己的实际情况和每个项目的具体情况确定测试计划的模板（如下表）。,22,版本更新记录,表一：,1介绍 1.1 目的 说明文档的目的。1.2 范围 说明文档覆盖的范围。1.3 缩写说明 定义

14、文档中所涉及的缩略语（若无则填写“无”）。1.4 术语定义 定义文档内使用的特定术语（若无则填写“无”）。,23,1.5 引用标准 列出文档制定所依据、引用的标准（若无则填写“无”）。1.6 参考资料 列出文档制定所参考的资料（若无则填写“无”）。2测试项目 对被测试对象进行描述。3测试特征 描述测试的特征。4测试方法 分析和描述本次测试采用的测试方法和技术。5测试标准 描述测试通过的标准以及测试审批的过程，测试挂起/恢复的条件。6系统测试交付物 测试完成后提交的所有产品。7测试任务,24,7测试任务,8环境要求 8.1 硬件需求 8.2 软件需求 8.3 测试工具 8.4 其他 9角色和职责

15、 10人员及培训 11系统测试进度,25,9.1.2 软件测试用例,在本书的第1章我们已经讲述了什么是测试用例，测试用例的评价标准，设计的基本原则，并给出了一个测试用例模板。但没有讨论如何记录和编写测试用例。如果你已经开始进行一些软件测试，就有可能实验过各种想法和格式。这里我们将讲述编写测试用例的有关内容和将要考虑的更多选择。,26,IEEE829标准称测试用例说明为“编写 用于输入的实际数值和预期的输出结果 数值。测试用例还要明确指出使用具体测试用例产生的测试程序的任何限制。”测试用例应该清楚地解释要向软件发送什么值或者条件，以及期望得到什么样的结果。它可以由一个或是多个测试用例说明来引用，

16、也可以引用多个测试程序。IEEE829标准还为我们列出了应该包含在 测试用例规格说明中的重要信息。,27,测试用例规格说明标识符。一个唯一的名 称或编号。可以由测试设计过程说明或测试程序 说明引用的唯一标识符。测试项。描述被测试的详细特性、代码模块等。它还要提供产品说明书的引用信息或者测试管理所依据的其他设计文档。输入说明。按值、值的范围或者（如果是文件）按名称列出所有输入内容或条件。确定相关的其他所有东西，包括内存驻留区域，由操作系统传递的值，支持程序或数据库，显示的提示消息以及输入之间的关系。描述任何时间安排上的 考虑。例如，如果测试人员应当在某条消 息后半秒内输入数据，那就要这样清楚地

17、说明。,28,输出说明。描述进行测试用例的预期输出 结果，包括列出所有输出值和消息，以及考虑 包括响应时间。环境要求。是指执行测试用例必要的硬件、软件、测试工具，设备和人员等。特殊过程要求。列出在设置、测试人员行为 或要为输出进行的分析中的任何不寻常情况。测试用例间的相关性。在测试之前必须执行 什么测试，为什么，如果程序没有通过那些测试会发生什么？也就是说如果一个测试用例依 赖于其他用例，或者受其他用例的影 响，就应该在此说明。,29,9.1.3 软件测试报告,软件测试报告是一系列测试的总结，是在完成一个测试周期后可能提交的测试类型的总结。它简要地描述了已完成的测试，并对测试结果进行评估。按照

18、IEEE829标准，它包括以下几个部分：,30,测试报告标识符。总结。表明什么已经被测试（包括版本ID），在什么环境下进行的测试，并总结对它的评价。需要参考测试用例规格明。变异。报告测试过程相对指定测试过程的任何偏离，并解释原因。广泛性评估。测试是否与测试计划要求的一样广泛？什么模块、特征或特征组合没有得到足够测试，为什么？结果总结。对什么问题进行了报告，哪些 问题得到了解决，以及解决方案是什么？哪些 问题仍然没有解决？,31,评价。在测试结果基础上对每个已测试项（程序或模块）的全面评价。或者，在实际使用中估计风险和这一项失败的可能性。活动总结。总结诸如为该报告中总结的测试工作的人员数量、使用

19、的总的机器时间、总的消耗时间以及任何特殊事件或使用的其他值得一提的资源。核准。测试报告可以自己编写，也可以使用商业测试 管理工具（例如HP的QC）在一个测试周期 完成后自动生成测试报告。,32,9.2 缺陷的报告和分析,在执行测试发现了软件缺陷（Bug）时，我们需要及时提交缺陷的报告，供程序员修复缺陷。从表面上看，报告测试所发现的问题，和制定测试计划、有效地使用测试技术寻找软件缺陷相比很简单。实际上，这也是测试人员需要完成的最重要，有时也是最困难的任务。书写缺陷报告的意义在于使缺陷得到修复，所以要写出非常高效的报告，有效地和程序员进行交流.,我们必须做到以下几点:,33,有效地描述软件缺陷，说

20、明如何让问题重现。如果程序员不能亲眼看到问题，他就会对问题置之不理。对缺陷进行分析，使用最少的步骤描述问题。如果报告中包含了不必要的步骤，问题会比实际情况看起来更复杂，程序员很有可能延迟处理看起来冗长而又混乱的报告。报告应该完备，易于理解而且没有敌意。测试人员和程序员之间很容易形成对立关系。从程序员或开发小组的其他人员的角度看，软件缺陷报告是软件测试人员对他们的工作的“成绩报告单”，因此报告的语言不要带倾向性、个 人观点和煽动性。软件缺陷报告应该针 对品，而不是具体的人，只陈述事实。,34,1、软件没有实现产品规格说明书要求的功能。,2、软件出现了产品规格说明书指明不应该出现的错误。,3、软件

21、实现了产品规格说明书未提到的功能。,4、软件没有实现产品规格说明书虽未提及但应该实现的目标。,5、软件难以理解、不易使用、运行缓慢，或者 从测试员的角度看，最终用户会认为不好。,9.2.1 缺陷报告的内容,软件缺陷：官方定义是至少满足下列五个规则之一的才称发生了一个软件缺陷。,35,说软件有没有“某个功能”，是指软件 运行时发现“有某个功能”或者“缺少某个功 能”。由于不能报告没有看见的问题，因此 没有看见就不能说存在软件缺陷。因此我 们的缺陷报告（也可以称为问题报告）必须是在运行软件测试后，看到的软件 缺陷。缺陷报告的内容在大多数公司都是大同 小异，不同的是组织和标志。,36,缺陷报告的内容

22、：（1）缺陷报告编号。它是独一无二的，不存在相 同编号的两份报告。（2）程序名。你测试的程序名。如果包含一个以上的程序需要说明。（3）版本号（发布号）。用来标识被测的代码。例如某个版本号可能是2.10b，产品会以发布号2.10进行宣传，版本号中的“b”指出这是为测试创建和发布的2.10版本的第2稿。版本号可以告 诉程序员究竟哪个版本出了问题。,37,（4）报告类型。描述发现的问题类型。问题类型可分为编码错误、设计问题、文档错误、硬件、建议、质疑。（5）严重性。对问题严重程度的评分。我们可以将评分从1（较轻的，如拼写错误）到10（影响巨大，如导致系统失效）分为10个等级，但现实中超过4个等级就很

23、难可靠地评价问题。因此我们可以采用4个等级：轻微的，一般的，严重的和致命的。严重性的评价需要注意之处是，如果缺陷的严重性等级被评价为“轻微”，那么它就往 往得不到修复，或者是被延迟等待修复。,38,如果轻微的问题太多，就应该写一份后续报告（评价为严重）以引起对它们的数量的关注（6）附件。报告缺陷时可能会附上的数据文件、图形用户界面的截图等。在报告中要注明包含了哪些附件。（7）问题概要。对问题进行简要描述，不用说明重现缺陷的步骤。概要可以帮助每个人很快地评审突出的问题，并找到相应的缺陷报告。（8）问题能否重现。能、不能或者有时能。,39,（9）问题描述。详细描述问题以及问题如何重现。从一个清晰的

24、起始状态出发，一步一步地说明如何去做才能看到问题的发生。描述一下所有的步骤和现象，包括错误信息。如果你发现自己不知道该如何准确地重新构建出触发错误的条件，就承认现实如实填写报告。优秀的程序员时常能够从细致的问题描述中跟踪到很难重现的问题。因此，尽可能完全地描述所有的错误信息，这有可能会将问题完全暴露出来，不要因为问题没有重现就放弃提交报告。（10）报告人。报告人的名字必须填写。（11）时间。发现问题的时间，而不是填 写报告的时间。,40,（12）责任人。填写负责处理该问题的小组成员 或管理人员的名称。（13）注释。预留给程序员或项目经理等其他处理该报告的人员使用。难度大的缺陷往往会在注释中引发

25、很长的讨论，这里会有很多人员的反馈信息。这是一种快速有效增加缺陷信息的方法。（14）状态。报告刚开始提交时都处于“开放（open）”状态。当已经确定缺陷已被修复或者大家同意这份报告不再是该版本的一个问题时，就将状态改为“关闭（close）”。在不同的公司或不同项目中会对具有关闭该份报告的权限的人进行规定，通常为提交报 告的测试人员或是测试小组长。,41,不同的公司根据缺陷报告的处理流程可以自己 设置需要的状态，最常用的状态是：开放、关闭和已解决。程序员在查询需要处理的缺陷时只需在存放缺陷报告的系统中搜索状态为“开放”的缺陷，当缺陷被修复后状态改变为“已解决”；而测试人员需要搜索的是状态为“已解

26、决”的缺陷，对其确认并判断是否进行关闭处理。（15）优先级。优先级由项目负责人或小组共同决定，要求程序员根据优先级依次修复缺陷。优先级通常是510级。不同的公司优先级的设置与定义也各不相同，例如：,42,立即修复（这阻碍了其他工作）；尽快修复；在下一个里程碑（测试、测试阶段等）前必须 修复；项目完工前必须修复；如果有可能就修复；任选（自行判断）。实践中只有项目负责人才能改动优先级，而严重性只能由报告人员（或测试小组长）改动。项目负责人和报告人员可能会在缺陷的重要程度上有认识上的差别，但谁也改变不了对方的分级和权限。有时，测试人员将某个缺陷标注为“致命的”，而项目负责人却将其当做低优先级来处理，

27、这是因为测试人员和项目负责人都有自 己的缺陷重要程度的分类立场。,43,（16）处理状态和处理版本。处理状态与状态不同，它根据缺陷的处理流程更详细地定义了问题的当前状态。如果软件根据报告进行了修改，处理版本就指明了程序的哪个版本包含了这一改动。下面列举了常用的不同类型的处理状态：未解决。所有缺陷报告的初始状态。它提醒项目经理关注，对其划分优先级并安排人员处理。只要有与当前处理状态相抵触的新信息出现，就应将报告改回到未解决状态。例如，如果程序员声称某个问题已经得到了改正，你却又重现了它，那么就应将处理状态从已改正改回到未解决。,44,已改正。程序员负责标明缺陷已改正，除此之外，还要指明是针对哪个

28、版本进行的改正。不能重现。程序员无法触发该问题。应在当前版本中检查该缺陷是否存在，同时确认对每一个必需的步骤都有清晰的叙述。如果你要增加新的步骤，应将处理状态重新设置为未解决，并在注释字段里说明所进行的操作。暂缓。项目负责人承认问题确实存在，但是决定在这个版本中不进行改正。无论缺陷反映了编码中的错误还是设计中的错误，暂缓都是合理的。符合设计。上报的问题不是错误，报告中描述的程序运行情况反映的是程序的预定操作。报告人撤回。如果报告的撰写人觉得还不如不 写这份报告，他可以把它撤回。除了报 告者,谁也不能撤回它。,45,需要进一步信息。程序员有一个必须由报告人解答的疑问。不同意建议。设计上不会做任何

29、更改。重复。很多组织使用这个处理状态码，并且关闭重复上报的缺陷。但如果你关闭的是相似而不是相同的缺陷，就会带来风险。看起来相似的缺陷，其原因可能不同。如果你将某些缺陷报告为重复的，那么程序员将只对其中的一个进行改正，而不会意识到还有其他的缺陷。此外，不同的报告也会包含着很有用的不同描述。在报告中应交叉引用重复的缺陷。（17）暂缓处理。如果项目负责人承认某个缺陷确实是软件中的错误，但决定在当前版本中 不进行改正，那么该缺陷就处于暂缓 状态。编码错误和设计错误都可以被推 迟处理。,46,当你遇到分类确实有误，或是对分类有不同意见，或是有人故意隐瞒缺陷，该怎么处理呢？,某些测试组修改报告的处理状态码

30、。我们并不建议这样做，因为这会带来激烈的争论。有些测试组拒绝接受原本应标注为暂缓而实际却标注为符合设计的缺陷报告。他们将报告打回给项目经理，要求他重新确定其处理状态。如果背后没有管理层的支持，不要这么做。很多测试组忽视这个问题，结果许多问题被掩盖了。与优先级和扩展过的注释字段一样，这个字段反映了我们的看法，即项目经理与测试人员之间存在不同意见是健康而司 空见惯的。问题跟踪系统应该能反映出这种差 异，允许所有各方都能在报告上留 下自己的判 断。,47,（18）签名。有些公司使用手工的问题跟踪系统，人们在实际的报告单上签名。人们在报告单上签名，或者往在线系统中输入自己的名字，我们将这样的行为称为签

31、署。每个公司都有自己的规定。规定必须由谁来签署报告单。我们认为，处理人这个字段应该始终由解决该问题（如进行了改正）的人或由他的经理来签署。有些公司在此处还加上了软件经理意见字段。处理测试人字段由测试人员签署，表明他已经对改动进行了测试，对结果表示满意，报 告可以进入关闭状态了。,48,9.2.2 缺陷的分析,缺陷报告提交的目的是为了程序员能再现缺陷，从而找到修复缺陷的方法。如何重现缺陷，首先需要分析缺陷。分析和再现软件缺陷是充分发挥侦探才干的地方，设法找到收缩问题的具体步骤。好消息是，不存在随机软件缺陷这样的事如果建立完全相同的输入和完全相同的环境条件，软件缺陷会再次出现。坏消息是，验明和建立

32、完全相同的输入和完全相同的环境条件，要求技巧性非常高，而且非常耗时。一旦知道了答案，就显得很容易。,49,如果找到的软件缺陷似乎要采用繁杂步骤才能实现，或者根本无法再现，如下一些提示和技巧会打开局面。如果碰到这种情况，尝试用如下的建议作为分析缺陷的第一步。（1）不要想当然地接受任何假设。记下所做的每一件事每一个步骤、每一次停顿、每一件工作。无意间丢掉一个步骤或者增加一个多余步骤会很容易出现的。请一个合作者看着你运行测试用例。利用按键和鼠标记录程序准确记录和回放执行步骤。如果必要，使用录像机记录下测试会话。所有这些的目的是确保导致软件缺陷所需的全部细节可现，并且可以从另一个角度分析。（2）查找时

33、间依赖和竞争条件的问题。软件缺陷仅在特定时刻出现吗？也许它取决于读取数据的速度，或者正 使用慢速软盘代替快速硬盘保存数据。看到软 件缺陷时网络忙吗？在更慢或更快的硬件上运 行测试用例。要考虑时序。,50,（3）边界条件软件缺陷、内存泄露和数据溢出等白盒 问题可能会慢慢自己显露出来。执行某个测试可能导致数据覆盖但是也只有在试图使用这些数据时才会发现也许在后面的测试中才可能。重新启动计算机后消失，而仅在执行其他测试之后出现的软件缺陷常常属于这一类。如果发生这种现象，就要查看前面执行的测试，也许可以利用一些动态白盒技术，看软件缺陷是否在无意间发生。（4）状态缺陷仅在特定软件状态中显露出来。状态缺陷的

34、例子是软件缺陷仅在软件第一次运行时出现或在第一次运行后出现。软件缺陷也许在保存数据之后，或按任意键之前发生。状态缺陷看起来很像时间依赖和竞争条件的问题，但是你会发现时间并不重要重要的是事件 发生的次序，而不是发生的时间。,51,（5）考虑资源依赖性和内存、网络、硬件共享的相互作用。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？虽然软件缺陷可能最终会被证实是由于软件的依赖性或对资源的相互作用进一步恶化的竞争条件、内存泄露或者状态缺陷问题，但是查一查这些（6）不要忽视硬件。与软件不同，硬件可能降级，不按预定方式工作。板卡松动、内存条损坏或CPU过热都可能导致像是软件缺陷的失败，

35、但是实际上不是。设法在不同硬件上再现软件缺陷。这在执行配置和兼容性测试中尤其重要。需要知道的是缺陷是 在一个系统上还是在多个系统上出现。,52,（7）不要遗忘细节。如果测试是随时进行的（即没有拟 订测试计划），在测试中发现某个问题后你却无法重现它，那么很可能你忘记了一些所做的环节。在这种情况下忘记一些细节是很容易发生的，因为你没有一个详细的要做的事情的计划。有些时候，你可能几乎是随心所欲地敲击键盘的。如果测试中途被打断，你可能会把一些事情重复做两次，或是做些根本无关的操作，这些操作原本是无害的（例如开启或关闭一个终端设备或打印机，或是键入一个字符之后再按Del键。你应该努力准确地回忆起中断刚刚

36、发生时正在做什么，中断期间又做了什么打发烦躁心情 的事情，以及刚刚恢复工作时又做了什么。,53,（8）用户的错误。所做的并非是以为做到的这常常被 用来解释“缺陷”。只要你没有重复所犯的错误，你也就 无法重现缺陷。即使这可能仅是猜测，当你用尽了可能的方案后也只能接受了。如果你认为用户会频繁地犯某个错误，而且程序对这个错误的反应也是不可预计的，就将程序的错误处理连同问题一起上报。不要忽视你的错误，应仔细地检查计算机会如何处理它们。（9）缺陷由长期积累形成。错误可能不会立即产生影响。某个错误可能需要重复几十次，程序才处于崩溃边缘。在此时，几乎任何操作都会导致程序崩溃，哪怕一个完全无关且不含错误的处理

37、程序都会神奇地让崩溃发生。你可能 倾向于指责后续的程序，而不是那些缓慢地破坏 系统的例程。,54,例如，很多程序都使用到了堆栈。堆栈是为临时数据预留的一部分内存区域。程序将数据放入堆栈的“顶端”并读取处于最顶端的数据。堆栈的规模可能很小，很快就被填满。假设某个堆栈能处理256个字节的数据，子程序A总是往里面放入10个字节的数据，执行完毕后任凭数据遗留在堆栈中，而没有清理掉。如果再没有其他的程序读取这些10个字节的数据，那么当你调用了25次程序A后，它就往堆栈中放入了250个字节的数据，剩下的空间仅有6个字节。如果完全与程序A无关的程序B试着往栈中放入7个字节的数据，堆栈就会发生溢出。堆栈溢出常

38、常会导致程序崩溃。从现在开始，你可以反复调用子程序B直到计算机精疲力竭，但除非也调用了子程序A25次，否则怎么也无法重现这个错误。如果你认为某 个很有嫌疑的例程并没有导致系统失效，就应问一下有哪些例程在此之前运行过。,55,（10）如果尽最大努力分析软件缺陷，也无法用简明的步骤再现，那么仍然需要记录软件缺陷，以免跟丢了。也许测试员仅用从程序员那里了解到的信息就能找到问题所在。由于程序员熟悉代码，因此看到症状、测试用例步骤，特别是努力分离问题的过程时，可能就会得到查找软件缺陷的线索。当然，程序员并不愿意，也没有必要对发现的每一个软件缺陷都这样做，但是有时这些难以分离的问题确定需要小组的共同努,5

39、6,9.3 问题跟踪系统,我们将用到问题跟踪系统来报告缺陷、记录缺陷、查询缺陷并编写缺陷总结报告。一个好的系统有助于建立缺陷的可解释性和联系性。要建立一个良好的跟踪系统并不是太难，即使对于小型项目而言它也是非常有价值的。,57,9.3.1 问题跟踪系统的目标与任务,问题跟踪系统的主要目标在于为修复那些应修复的缺陷提供帮助。任何不直接支持这个目标的问题，都不是关键问题。有些其他的目标（如形成某些管理报告）都完全兼容于系统的主要目标。每当为系统提议添加新的任务和目标时，都应该将其与主要目标做比较。偏离了系统主要目标的任何目标都应被排除。为实现问题跟踪系统的目标，设计人员及其 管理层必须确保完成以下

40、几点任务：,58,58,四方面,59,9.3.2 问题跟踪概述,定义了问题跟踪系统的总体目标和任务之后，下一步是要看在现实中缺陷报告是如何被处理的，包括对问题的常规处理。我们面临的挑战是如何构建或选择一个问题跟踪系统来很好地克服这些困难。,60,1问题被上报 我们已经讨论了起点：发现缺陷、调查细节，直到写出清晰的描述、输入一份缺陷报告。下一步就是要将报告录入到跟踪系统中。在很多公司里，提交缺陷报告与将报告录入到跟踪系统实际上是一回事通过往数据库中键入报告内容提交报告。但是在有些公司里，原始的缺陷报告是手写在标准表格上的，然后再由其他人录入到跟踪系统中。很多公司虽然允许测试人员直接将缺陷报告录入

41、到数据库中，但还仍然需要有其他的职员（比如技术或客户支持人员、行政支持人员或销售人员等）将每份报告提交给某个人（比如测试人员、系统分析员或项目经理 等），由他们来决定是否将报告录入到数据库中。这些情况很难达到平衡。,61,一方面存在着浪费时间的风险。由非技术人员提 交的报告往往是不完整的，或是问题没说清楚，倒反映 出报告员对产品设计缺乏了解。另一方面，有很多重要的 问题会被无意中遗漏或被有意排除，仅当用户投诉或被某刊物批评后方才显现出来。跟踪系统可能是单用户或是多用户的。典型的单用户数据库安装在测试工作间的某台计算机上。每个人都在这台机器上录入或读取报告。仅有测试人员或是部分测试人员才可以直接

42、访问该计算机。缺陷报告和项目状态总结报告由项目安排的某个测试人员打印和发放。而典型的多用户系统位于计算机网络或大型机上，能够被所有的测试人员和项目经理访问。程序员和技术文档编写人员也可能有权访问。市场营销人员和技术支持人员可以有权，也可以无权访问它（我们认为他们应该有权访问）。在一个多用户系统中，任何 有权访问的人都可以录入自己的报告、查询数据库 和打印总结报告。,62,2报告提交给项目经理,一旦报告录入到数据库中，就会有一份副本提交给项目经理。在多用户系统中这是自动完成的，项目经理可以直接访问数据库，报告一经录入他们就可以看到；而在单用户系统中，测试工作每隔几天向项目经理提交一份新报告。通常

43、项目经理要么划分问题优先级，将其转交给程序员处理，要么按如下方法处理报告。（1）在大多数情况下，项目经理会对报告进行评价，加注意见，划分优先级，然后转交给程序员处理。在高优先级问题得到改正前，低优先级的报告不会得到关注。在很多公司里，原有的优先顺序可能会打乱，当程序员正在处理某一代码区域的高优先级问题时，相同区域的低优先级问题也会被处理。对某个区域的问题集合进行整体评价并一起改正，会更为容易、快捷，通常也会更为有效彻底。（请注意，这种做法依赖于由测试人员或程序员对报告 进行良好的分类。）,63,（2）项目经理的处理方式可能是暂缓处理该报告或注明符合设计，或要求报告人将问题重新分类，归结为文档编

44、写的问题，或是找到报告者，确认手册中（可能是在问题解决部分中）包含了该问题。最终，获得更多细节的要求得到了满足，项目经理把报告交给程序员，由其改正问题或进行其他处理（暂缓、保持原设计或经测试证明无法重现）。有些项目经理可能是由于心不在焉或是故意将一些报告束之高阁一段时间，既不确定优先级又不进行答复，一个良好的总结报告系统能够揭示出一些问题，并促进问题的解决。3报告由项目经理转交给程序员 报告转交给程序员后，项目经理会要求程序员改正问题，或要求他调查和解释为什么缺陷无法修复。一般情况 下，缺陷都能得到修复。,64,程序员也有可能不改正问题，相反，他会要求得到更多的信息，或会认为这个缺陷根本无法重

45、现、难以修复，甚至认为根本就不是缺陷，傻瓜才会遇到这种情况，测试用例很不合理或是根本不值得加以关注（有时他的想法确实是有道理的）。有些程序员总是喜欢逃避缺陷，他们故意对某些报告熟视无睹，寄希望于没有人能注意到它，拖到太迟了而无法进行处理，或是将跟踪缺陷的过程搞得非常痛苦，寄希望于报告人员不堪忍受而放弃。测试人员是唯一能深入对抗程序员的抵触情绪的人。缺陷报告中的注释部分是对抗抵触的有力武器。你（或是项目中其他的测试人员）应在注释部分中详细录入每一条意见、说明、否定意见和理论解释。顺便提一下，在所有项目的某些阶段，测试人员会坚持认为自己受到了程序员不合情理的抵触。这种感觉往往是不正确的。在每份缺

46、陷报告中详细的注释过程能够为项目经理和测试经理提供 数据，以消除误解，减少程序员与测试人员之间的摩擦。,65,4当缺陷已经修复（问题已改正）程序员改正了某个问题之后，会将问题在数据库中标识为“已改正”，还可能再加些注释。然而，这并非一份报告的结束，因为程序员常常会犯错，要么问题并未得到解决，要么代码改动后又会导致新的问题。根据我们开发微机零售软件包的经验，将失败的比率控制在10%以下就已经很好了。对已改正的问题重新测试，最好还是由上报该问题的测试人员来做。如果报告人不是测试人员，由你来重新测试某个问题，那么应该确认你能够在程序未经改正的原先版本中重现该问题。你应该在手头上保留程序最近的三个版本

47、，这样可以很容易地重现原先的缺陷，也可以拿程序当前的运行情况与过去相比较。当缺陷报告又回到你手中时，你可以再次执行报告中的那个测试用例。你常常会吃惊地发观做过的改正根本不起作用。,66,如果改正过的程序通过了原先的测试（多数会通过），那么就再试着做一些变化。阅读一下程序员的笔记和记录在报告上的其他所有注释。做过的改正会影响到程序的哪些部分？变动破坏了哪些东西？做一些测试，测试一下由变动带来的明显的副作用，另外，对原先的测试用例做一些修改。如果发现了一个错误，就很可能还存在着更多的错误。找一下比报告中的问题更一般化的问题或相关的问题。对“已改正”的缺陷进行分析，尝试一下对测试做一些变化，在这些方

48、面测试人员花的时间不是太多了，而是太少。如果先前通不过的测试程序现在仍然没有通过，就应在原先的缺陷报告上注明，将报告上的处理状态从已改正改回未解决，并将其递交给项目经理或程序员。如果程序通过了原先的测试，通常较好的做法是把原先的报告置为已改正并将其关闭，再开启一份新报告。多数程序员和项目经理都喜欢这种做法。与记录问题改正过程的报告 相比，此类报告更简单，更易理解。,67,5无法重现的缺陷（问题）如果程序员和项目经理无法重现缺陷，他们就无法改正它。他 们会将报告标注为不能重现，再打回给你。因此你应该努力重现出该 缺陷。如果有必要，在你当初发现缺陷的程序版本上试着重现缺陷。如果你可以重现缺陷，就在

49、报告上说明（写在注释部分），并补充 一些细节供程序员自己重现缺陷。如有必要，可以找到程序员或项目经理，亲自向他们演示，或向他们提供一份测试报告或视频记录。应将你所演示或提供的内容在注释中说明。如果你无法在当前版本中重现问题，却可以在以往的版本中重现，尤其是如果对相关代码的最近改动可能已经改正了该问题，那么通常较好的做法是将原先的报告标注为已改正并关闭它。应始终与程序员或项目经理一起仔细检查，方可标注某个缺陷为已改正。往你的测试计划里加上一个注解，在随后的一个或两个版本中重新测试该问题，确保已得到彻底改正。如果在任何版本中你都无法重现缺陷，应确认该缺陷是不可重现的，但在随后的几个版本里都应保持报

50、告的状态为开放，或许要到下一个主 要的开发里程碑方可关闭。在每个新版本中都试试看，如果 在几个版本里（或到里程碑前）你都无法重现它，就可以关 闭报告了。,68,6问题暂缓与申诉过程 状态为暂缓表示承认有问题存在，但项目经理决定不对当前 版本进行改正（有些开发小组使用的是第三种反馈信息：不能改正，意为永远搁置起来）。在任何一个经过了充分测试的商业质量良好的 产品中，仍然会有很多编码错误和设计问题被暂缓处理了。任何项目在临近尾声时，改正代码带来副作用的风险都会大大超过改正小的编码错误所带来的好处。在缺陷报告的注释部分，很多项目经理会简要地对为什么将问题暂缓处理给出解释。这些材料在申诉会议上非常有用