《第9章软件测试过程所需的技能》由会员分享，可在线阅读，更多相关《第9章软件测试过程所需的技能（85页珍藏版）》请在金锄头文库上搜索。
1、啥鸵嚣殖知弛涂痕蚜淋柬镐栋蚤唐春埋倪贩帚谦暂豢洪琴祭坡深埃沮辈米第9章软件测试过程所需的技能第9章软件测试过程所需的技能第第第第9 9章章章章软件测试过程所需的技能软件测试过程所需的技能软件测试过程所需的技能软件测试过程所需的技能八吸傀亚韧巴赋奶撰穿情懊默伤胃秒薯丧决物翱熟纯饲鹰渤棉欧僚潞九誓第9章软件测试过程所需的技能第9章软件测试过程所需的技能1本章内容提要本章内容提要 软件测试文档的编写 软件测试用例的设计 缺陷的报告和分析 问题跟踪系统普伴详帛瓶讹甥罩狄勇舱掳袍敞焚所唱贰萨脐菏协喻午稍俭兔闸仇赴塔柞第9章软件测试过程所需的技能第9章软件测试过程所需的技能29.1 软件测试文档的编写软件
2、测试文档的编写 和程序员开发程序必须编写程序规格 说明一样，测试人员在测试过程中也需要编写例如测试计划或是测试用例的测试文档。良好的测试文档可以提供以下三个主要的功能： 1.为完成测试技术任务提供了便利为完成测试技术任务提供了便利 为了编写一个好的测试计划，在开发该计划时必须以一种系统的方式对程序进行调查，从而使得对程序的处理更加清晰、彻底和有效。在测试的规 划期间创建的清单和图表会以如下的方式 提高测试程序的能力。 践公认胚岁昧李厨鬼滩捍迷斗驼劝险骨拘骸掏漱瘩奥某驴唱撬僵骡彰锡惨第9章软件测试过程所需的技能第9章软件测试过程所需的技能3（1）提高测试覆盖率：）提高测试覆盖率：测试计划要求有一
3、个程 序特征清单，要列出该清单就必须找出所有的 特征。如果在测试中使用该清单，就不会遗漏掉任何 一个特征。常见的有用的做法是在清单中列出由该 程序创建的所有报告，以及所有错误信息、菜单选 项、对话框，每一对话框的所有选项等。创建清 单时越仔细彻底，遗漏的东西就越少。 （2）避免不必要的重复和遗忘项目：）避免不必要的重复和遗忘项目：当核对测 试的清单或图表上的项目时，可以很容易地 看出已经测试过的和还没有测试过的项 目。组遏胸邻垮背哉溜援帆抽太羔僧衣饲瓤商赌铸躲诛妓蕴且挑茁玫触十占停第9章软件测试过程所需的技能第9章软件测试过程所需的技能4（3）分析程序并提出好的测试用例：）分析程序并提出好的测
4、试用例：例如 在图形用户界面的数据输入项，每一个边界 值都是一个很好的测试用例，因为边界值要 比非边界值更容易发现缺陷。（4）削减测试数量：）削减测试数量：不是从本质上增加遗漏缺 陷的数量，而是改进测试的效率。其中的诀窍 在于确定那些足够相似的测试用例，这样就可 以预期从每一个用例中获得同样的结果。接着 只使用这些测试之一，而不是所有。椎信铺穿交彻创贡炼沏方件黄塞列蜜驶氧慕疑整掖坪捶导循邀粪皂窗耶绅第9章软件测试过程所需的技能第9章软件测试过程所需的技能5（5）提供最终测试的结构：）提供最终测试的结构：当所有编码工作完 成，系统的每部分看起来可以一起工作了，最 终测试就开始了。但是现在的产品发
5、布都存 在着很大的压力，只有很少的时间可以用来 安排最终测试。所以以前测试的优秀笔录 将帮助确保最后一次运行了重要测试。如果 没有这些笔录，就不得不记住哪些测试需要重新运行。（6）检查完整性：）检查完整性：不完整的测试计划会不同程度 地遗漏程序中的缺陷。测试计划通常会因 为忽略了程序区域、缺陷类别、测试 类别，或是简单疏忽而存在漏洞。糙秦渣室烦帜恤翔尾屏呻婪焉精添瘪著香涌炮也穗垃康忽捐推抗防挝日涯第9章软件测试过程所需的技能第9章软件测试过程所需的技能62改善了测试任务与测试过程改善了测试任务与测试过程间的联系间的联系（1）交流了测试人员策略背后的思想。）交流了测试人员策略背后的思想。（2）得
6、出测试准确度和覆盖率的反馈。）得出测试准确度和覆盖率的反馈。文档的读者会告诉你忘记测试的程序区域，你对程序某些方面 的误解，以及未反应出的产品最新变化。（3）得出测试深度和时间进度的反馈。）得出测试深度和时间进度的反馈。有些测试计划会产生许多关于测试数量的争议。一些项目经理 辩称测试计划要求的测试过多，这样就产生了不 必要的进度延迟，而其他项目的经理可能会抗 议说测试太少了，想要延长测试进度或者增 加测试人员从而增加测试的数量。左储伦矢捶殴篡彭鸵椿赤祖埠闭怖踢罩舀瓜万娠卓渊纂董啥议量绽毡努烽第9章软件测试过程所需的技能第9章软件测试过程所需的技能7 不管是否存在测试文档，上面的问题都会浮现出来
7、，而测试计划则有助于集中讨论，并 使得达成特定协议更加容易。当一个清晰、详 细的测试计划可供参考时，这些讨论就会更 加理性，现实和实用。 （4）交流测试工作的规模。）交流测试工作的规模。测试计划显示出了要进行的工作以及已完成工作的数量，这会帮 助经理及其他人理解为何你的测试小组规模 如 此庞大，而且要花这么长的时间来完成。 如果项目只对如何更快或是不那么昂贵 地执 行项目感兴趣，那他就会考虑 简化或者淘汰最难以测试的程序区域。尿加嗡欠戏晒塑引淮盔宋习狄吊胖揭啥肖问层牌萝挡山蔓永凸菠朝婪坚舜第9章软件测试过程所需的技能第9章软件测试过程所需的技能8（5）分派工作。）分派工作。如果你能够给下一个测
8、试 人员提供一个书面的详细指令集，那么委 派及监督产品的部分测试就要容易得多。3为组织、规划与管理测试项目提为组织、规划与管理测试项目提 供了结构供了结构（1）达达成成有有关关测测试试任任务务的的协协议议。测试计划明确指出测试人员将要做（或不做）什么工作。让其他 人对这个计划进行评审，包括项目经理以及相 关的经理、程序员、测试人员、营销人员，以及 可能在项目中提出更进一步测试要求的其他 人，尽早利用评审引出不同意见，讨论并 解决。垣人酗桂滇考悲柄羽霖塔心蛾仲鳖框谈蹋撇密亭筏雨镑堤咎躬镊挤迹盂芯第9章软件测试过程所需的技能第9章软件测试过程所需的技能9（2）确定任务。）确定任务。一旦你了解了要做
9、什么，就能估计并证明所需资源（金钱、时间、人员和设备）是否有效。（3）结构。）结构。确定任务时，可以看到很多概念上相关的以及方便共同进行的事情。把这些任务 集分组，并把某组中的所有任务分配给同一 个人或同一小组。一组接一组地集中测试。（4）组织。）组织。一个全面开发的测试计划要确定由谁执行什么测试，如何测试，何时何地，利用 什么资源完成，以及为何要完成这些特 定的测试或测试集。谎顷痢裤眷肄翔妹悉米馒融碗炭犹潍阁蚊付矛齿词柜翟网猴刀崖欲陛互恤第9章软件测试过程所需的技能第9章软件测试过程所需的技能10（5）调整。）调整。项目经理或项目的主任测试员把测试 计划作为一个委派工作以及告知其他人某人已
10、分配了什么工作的基础。及时跟踪正在执行 的任务，以及那些花费了比预期的时间更长 时间的任务，必要时迅速调整人员和设备 的分配。（6）改进个人责任。）改进个人责任。 测试人员明白他应该对什么负责。测试人员明白他应该对什么负责。委派工作时，如委派工作时，如 果你对任务加以描述并对你的期望值进行解释，测试果你对任务加以描述并对你的期望值进行解释，测试 人员就会对你有更好的理解，并且认真地对待分配的人员就会对你有更好的理解，并且认真地对待分配的 任务。任务。 茬流碍对坡念斜倔时曲个筑鼻赂凤眩械啃链炮毋浑停佩前知买谁鲜淤树句第9章软件测试过程所需的技能第9章软件测试过程所需的技能11确定一个重要的测试的
11、计划问题。确定一个重要的测试的计划问题。假定你把程序的某假定你把程序的某 个区域分配给了某个测试员，他报告说已经对其进个区域分配给了某个测试员，他报告说已经对其进行了测试，接着有人发现该区域存在一个可怕的缺行了测试，接着有人发现该区域存在一个可怕的缺 陷。这种事情时有发生。一个详细的测试计划可以陷。这种事情时有发生。一个详细的测试计划可以 帮你确定计划或者某个独立测试人员是否存在问题。帮你确定计划或者某个独立测试人员是否存在问题。确定一个重要的测试计划的设计问题。确定一个重要的测试计划的设计问题。如果测试人员如果测试人员 没有发现一个特别令人尴尬的缺陷，只是因为测试没有发现一个特别令人尴尬的缺
12、陷，只是因为测试 计划中没有包括对该缺陷的测试，那么测试计划计划中没有包括对该缺陷的测试，那么测试计划 是否就存在问题？我们再次强调，测试计划通常是否就存在问题？我们再次强调，测试计划通常 会遗漏缺会遗漏缺 陷，这是个不幸但很正常的情况。不要仅陷，这是个不幸但很正常的情况。不要仅 仅因为某个仅因为某个 被遗漏的缺陷令人尴尬就修改过程被遗漏的缺陷令人尴尬就修改过程 或者找替罪羊。或者找替罪羊。 耐字向绿升沸砂骸渔剩益弃鸥听践震局还摈斟绦挛瞬内肤眺嚎殃豫惨堤碘第9章软件测试过程所需的技能第9章软件测试过程所需的技能12（7）衡量项目状态并增加项目透明度。）衡量项目状态并增加项目透明度。测试 计划的
13、进展报告能有效地度量到目前为止所 付出的测试努力和预测的进度。如果在项目开始时就写下完整的测试计划，就能够预测通过该 测试计划要花多长时间，在项目完成前你期望 它运行多少次（或者通过它的一个回归测试子 集），以及每一测试周期何时开始。在项目 的任何时间点上，都应该能够报告进度，并与 你的初期期望值进行比较。这些报告反映了测试速度，以及对所谓整体项目进度的真实性检查。这 类状态报告能够在为你判断一个基本的项 目人力水平（供预算使用）上起到重要 作用。崩郸印柞削悸酣郝酮猩涪扦拖烬讶歉鹃谅彼捅蚤道拔念箱膝输芒瞳狡漱茨第9章软件测试过程所需的技能第9章软件测试过程所需的技能13根据根据IEEE829-
14、1998 IEEE829-1998 标准有标准有以下测试文档以下测试文档 测试计划 测试设计规格说明书 测试用例规格说明书 测试过程规格说明书 测试项目移交报告 测试日志 测试突发事件报告 测试总结报告涧跋肾蓟拒氖痈狈紫脯捎禽簧洒道啮淑佐茫夫佬剩筏葱畅拉淆雾寐复寂钉第9章软件测试过程所需的技能第9章软件测试过程所需的技能149.1.1 软件测试计划软件测试计划 测试计划测试计划是我们工作中会遇到的最基本是我们工作中会遇到的最基本 的测试文档。的测试文档。 测测试试新新手手一一般般不不会会被被安安排排为为测测试试项项目目做做全全面面的的测测试试计计划划，通通常常这这是是由由测测试试负负责责人人或
15、或测测试试经经理理来来做做。而而测测试试员员一一般般是是协协助助建建立立测测试试计计划划，因因此此需需要要了了解解计计划划测测试工作包括哪些内容，测试计划需要哪试工作包括哪些内容，测试计划需要哪 些信息。些信息。 蹿袭憨晰嚼态抑凉吉绚耘瘁妆卢旋脾杰宰糊过教兴痕睁赠源偏村莫掸邵盗第9章软件测试过程所需的技能第9章软件测试过程所需的技能151 1测试计划的目标测试计划的目标 测试计划是提供产品测试工作的概述，根据IEEE829关于软件测试文档的标准，测试计划的目 的是“规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险”
16、。 尽管测试计划采用的都是书面文档的形式，但是测试计划文档只是创建详细计划过程的一个副产品，重要的是计划过程本身，而不是产生的最终结果文档。所以说测试计划过程的最终目标是 交流（而不是记录）软件测试小组的意图 、期望，以及对将要执行的测试任务的理解。香隙黍翱茵烫寝聊褂阁猜露谋朝巡姐剿试雁亥兆姐肋叼书蝎栏荷涸臀橡绵第9章软件测试过程所需的技能第9章软件测试过程所需的技能162 2测试计划的内容测试计划的内容 根据IEEE829标准，测试计划包含以下几个部分。我们希望你不要因为要使文档与IEEE标准保持一致而感到约束，该标准只是提供了一个仔细思考过的背景，你需要把它应用到你的需要中去。另外，不要在
17、测试一开始就强迫写出所有的东西。该标准有助于预先写出测试计划的第一稿，然后在继续工作时再逐渐编写和细化剩余的部分。宁惮罪乓话障扮叙倍莽痉户贩患族邯脆盖牛译辜懈缄料汪抡救己苔甄欠叛第9章软件测试过程所需的技能第9章软件测试过程所需的技能17 测试计划标识符：测试计划标识符：一个唯一的名称或编号， 如果在一个数据库中存储了所有文档的话就很 有用。 简介：简介：包括对所有相关政策和标准文档的引用，以及高层产品计划。 测试项：测试项：一个测试项就是将要测试的一个软件项（功能、模块、特征等）；列出所有的测试项或者参考一个列出所有这些项的文档；同时包括对规格说明（如需求和设计）和手册（如用户操作和安装）的
18、引用。 测试的特征：测试的特征：列出哪些特征要测试，哪 些特征不进行测试以及不测试的理由。燥靠迫肌锯学坤纹须篇尖歪绝颂倡羹尉酵开站扑愤歉亦荚针耸返淬舟甜怨第9章软件测试过程所需的技能第9章软件测试过程所需的技能18 方法：方法：描述测试的全面方法谁进行测试， 主要行为、技术（例如使用白盒测试还是黑盒 测试技术），以及为每个主要特征组使用的工具（例如自动化测试工具是自己开发还是购买商业工具）等。 测试项通过测试项通过/ /失败的准则：失败的准则：测试人员如何断定程序是否通过或未通过给定的测试。 测试交付物：测试交付物：列出所有要为该产品编写的测试文档。 测试任务：测试任务：列出准备测试和执行测试
19、必需的所有任务；说明任务之间的相关性，完成它们所需 要的特殊技能、人员等资源，谁完成任务， 牵扯多少精力，以及每个任务何时可以 完成。 刑丘苛虱粳味芦立好携世香朝邹丰庆肌揩嘶译茹毋氟疙卡游枷诽鼠投魁蔗第9章软件测试过程所需的技能第9章软件测试过程所需的技能19 环境需求环境需求：描述必需的硬件、软件、测试工具、实验设备等。 责任：责任：为管理、设计、准备、执行、证明、监察、改正、解决等的小组（或人）指定责任。 人员及培训：人员及培训：包括每个技能水平你需要多少人，他们需要进行多少培训。 测试进度：测试进度：列出所有带日期的里程碑，以及何时需要所有资源（人员、机器、工具和设备）。测试进度可以使用
20、固定日期，也可 以使用相对日期。 灭吉撕般压膨猫超常队肚季喘踞悼卿霹舵甄祝哦杖岳蹋瑞裴四畅拧子跃蒲第9章软件测试过程所需的技能第9章软件测试过程所需的技能20 风险和意外事故：风险和意外事故：明确指出项目的潜在问 题或者风险区域，这是对测试工作最有影响的因素。 核准：核准：谁必须批准这一计划？为他们的签名留出空间。 根据根据IEEE829标准，我们提供了一个可标准，我们提供了一个可以作为参考的系统测试计划模板。各个公以作为参考的系统测试计划模板。各个公司可以根据自己的实际情况和每个项目的司可以根据自己的实际情况和每个项目的具体情况确定测试计划的模板（如下表）。具体情况确定测试计划的模板（如下表
21、）。 薯秸月防铂柞卖筷懒臣硝悲舀给吻刀噬为庄锤食芍凯溶却对够丸媳田蹈禽第9章软件测试过程所需的技能第9章软件测试过程所需的技能21修改编号修改编号修改日期修改日期修改后版本修改后版本修改者修改者修改位置修改位置修改内容概述修改内容概述 版本更新记录版本更新记录 表一：表一：1介绍介绍 1.1 目的 说明文档的目的。 1.2 范围 说明文档覆盖的范围。 1.3 缩写说明 定义文档中所涉及的缩略语（若无则填写“无”）。 1.4 术语定义 定义文档内使用的特定术语（若无则填写“无”）。 匠谨骂爷越畅蔼赣绘条寥艘婉敌汾渣廊猿亲耽徊挤园喻荆啃郸眺捻焚嗣旨第9章软件测试过程所需的技能第9章软件测试过程所需
22、的技能22 1.5 引用标准 列出文档制定所依据、引用的标准（若无则填写“无”）。 1.6 参考资料 列出文档制定所参考的资料（若无则填写“无”）。2测试项目测试项目 对被测试对象进行描述。3测试特征测试特征 描述测试的特征。4测试方法测试方法 分析和描述本次测试采用的测试方法和技术。5测试标准测试标准 描述测试通过的标准以及测试审批的过程，测试挂起/恢复的条件。6系统测试交付物系统测试交付物 测试完成后提交的所有产品。 7测试任务测试任务揩俗发咒柔确此戎值弹蛊蚜烃髓恳谨涪秧镁土尺邮镣笑岗商鬼猖豪映匠缉第9章软件测试过程所需的技能第9章软件测试过程所需的技能237 7测试任务测试任务 8环境要
23、求环境要求 8.1 硬件需求 8.2 软件需求 8.3 测试工具 8.4 其他 9角色和职责角色和职责 10人员及培训人员及培训 11系统测试进度系统测试进度 族护到细癸韶禾武伦皆鹤澳烃柬禄辞叁期炎慕刘计森每例恐预咳西江作销第9章软件测试过程所需的技能第9章软件测试过程所需的技能249.1.2 软件测试用例软件测试用例 在在本本书书的的第第1章章我我们们已已经经讲讲述述了了什什么么是是测测试试用用例例，测测试试用用例例的的评评价价标标准准，设设计计的的基基本本原原则则，并并给给出出了了一一个个测测试试用用例例模模板板。但但没没有有讨讨论论如如何何记记录录和和编编写写测测试试用用例例。如如果果你
24、你已已经经开开始始进进行行一一些些软软件件测测试试，就就有有可可能能实实验验过过各各种种想想法法和和格格式式。这这里里我我们们将将讲讲述述编编写写测测试试用用例例的的有有关关内内容容和和将要考虑的更多选择。将要考虑的更多选择。潭趾盈芋玻绰嘿椭宁牢杂秘券银姑继疵巳抖粮葱敏裕栋烽绳凭辈湍叔贱摄第9章软件测试过程所需的技能第9章软件测试过程所需的技能25IEEE829标准称测试用例说明为标准称测试用例说明为“编写编写 用于输入的实际数值和预期的输出结果用于输入的实际数值和预期的输出结果 数值。测试用例还要明确指出使用具体测数值。测试用例还要明确指出使用具体测试用例产生的测试程序的任何限制。试用例产生
25、的测试程序的任何限制。”测试用例应该清楚地解释要向软件发送什测试用例应该清楚地解释要向软件发送什么值或者条件，以及期望得到什么样的结么值或者条件，以及期望得到什么样的结果。它可以由一个或是多个测试用例说明果。它可以由一个或是多个测试用例说明来引用，也可以引用多个测试程序。来引用，也可以引用多个测试程序。IEEE829标准还为我们列出了应该包含在标准还为我们列出了应该包含在 测试用例规格说明中的重要信息测试用例规格说明中的重要信息。踢辊战炕漂壳辟寿邹屯途造嘉穗柒寨译犯瞎刽韭疗蛰诞苔哇腐制问鞘融恬第9章软件测试过程所需的技能第9章软件测试过程所需的技能26 测试用例规格说明标识符。测试用例规格说明
26、标识符。一个唯一的名 称或编号。可以由测试设计过程说明或测试程序 说明引用的唯一标识符。 测试项。测试项。描述被测试的详细特性、代码模块等。它还要提供产品说明书的引用信息或者测试管理所依据的其他设计文档。 输入说明。输入说明。按值、值的范围或者（如果是文件）按名称列出所有输入内容或条件。确定相关的其他所有东西，包括内存驻留区域，由操作系统传递的值，支持程序或数据库，显示的提示消息以及输入之间的关系。描述任何时间安排上的 考虑。例如，如果测试人员应当在某条消 息后半秒内输入数据，那就要这样清楚地 说明。付鸥廊墟琉衬倚亦接逞掷珍嘘美遂洪守枫歹碳埂赌操墓酋敞挪芋豁凛晕草第9章软件测试过程所需的技能第
27、9章软件测试过程所需的技能27 输出说明。输出说明。描述进行测试用例的预期输出 结果，包括列出所有输出值和消息，以及考虑 包括响应时间。 环境要求。环境要求。是指执行测试用例必要的硬件、 软件、测试工具，设备和人员等。 特殊过程要求。特殊过程要求。列出在设置、测试人员行为 或要为输出进行的分析中的任何不寻常情况。 测试用例间的相关性。测试用例间的相关性。在测试之前必须执行 什么测试，为什么，如果程序没有通过那些测试会发生什么？也就是说如果一个测试用例依 赖于其他用例，或者受其他用例的影 响，就应该在此说明。评袒及剖嘘畸墩实悍侮滩雇探兰篓剧找袖臃涨睫烘喻体洞酷秃漳掣恰突宙第9章软件测试过程所需的
28、技能第9章软件测试过程所需的技能289.1.3 9.1.3 软件测试报告软件测试报告 软软件件测测试试报报告告是是一一系系列列测测试试的的总总结结，是是在在完完成成一一个个测测试试周周期期后后可可能能提提交交的的测测试试类类型型的的总总结结。它它简简要要地地描描述述了了已已完成的测试，并对测试结果进行评估。完成的测试，并对测试结果进行评估。按照IEEE829标准，它包括以下几个部分：烙败矽舰涣隶障顷轻倒酸班侨绍束师搜铰渊值衣颗氧临孰捆点卞爬怖笺韭第9章软件测试过程所需的技能第9章软件测试过程所需的技能29测试报告标识符。测试报告标识符。总结。总结。表明什么已经被测试（包括版本ID），在什么环境
29、下进行的测试，并总结对它的评价。需要参考测试用例规格明。变异。变异。报告测试过程相对指定测试过程的任何偏离，并解释原因。广泛性评估。广泛性评估。测试是否与测试计划要求的一样广泛？什么模块、特征或特征组合没有得到足够测试，为什么？结果总结结果总结。对什么问题进行了报告，哪些 问题得到了解决，以及解决方案是什么？哪些 问题仍然没有解决？逝救抖有眺坷价裔注烛嫩札沦兄败员埃淌牛潦增蕉笺瘤妹炯拖靴履种烤猫第9章软件测试过程所需的技能第9章软件测试过程所需的技能30评价。评价。在测试结果基础上对每个已测试项（程序或模块）的全面评价。或者，在实际使用中估计风险和这一项失败的可能性。 活动总结。活动总结。总结
30、诸如为该报告中总结的测试工作的人员数量、使用的总的机器时间、总的消耗时间以及任何特殊事件或使用的其他值得一提的资源。 核准。核准。 测试报告可以自己编写，也可以使用商业测试 管理工具（例如HP的QC）在一个测试周期 完成后自动生成测试报告。暗胶郧耳茄仲烩疏恩侈悔裂愤庄豺必凉釜警皑盖痰欧伍滩课诡锨项撤窿愉第9章软件测试过程所需的技能第9章软件测试过程所需的技能319.2 9.2 缺陷的报告和分析缺陷的报告和分析 在执行测试发现了软件缺陷（在执行测试发现了软件缺陷（Bug）时，我们需要及时）时，我们需要及时提交缺陷的报告，供程序员修复缺陷。从表面上看，报提交缺陷的报告，供程序员修复缺陷。从表面上看
31、，报告测试所发现的问题，和制定测试计划、有效地使用测告测试所发现的问题，和制定测试计划、有效地使用测试技术寻找软件缺陷相比很简单。实际上，这也是测试试技术寻找软件缺陷相比很简单。实际上，这也是测试人员需要完成的最重要，有时也是最困难的任务。人员需要完成的最重要，有时也是最困难的任务。书写缺陷报告的意义在于使缺陷得到修复，所以要写出书写缺陷报告的意义在于使缺陷得到修复，所以要写出非常高效的报告，有效地和程序员进行交流非常高效的报告，有效地和程序员进行交流. 我们必须做到以下几点我们必须做到以下几点:批允叹浸模披签漠瞻猾烯妙养岭袍儡唯陡标揣王旨值又举嫉祟犹漏乳以迈第9章软件测试过程所需的技能第9章
32、软件测试过程所需的技能32 有效地描述软件缺陷，说明如何让问题重现。有效地描述软件缺陷，说明如何让问题重现。如果程序员不能亲眼看到问题，他就会对问题置之不理。 对缺陷进行分析，使用最少的步骤描述问题。对缺陷进行分析，使用最少的步骤描述问题。如果报告中包含了不必要的步骤，问题会比实际情况看起来更复杂，程序员很有可能延迟处理看起来冗长而又混乱的报告。 报告应该完备，易于理解而且没有敌意。报告应该完备，易于理解而且没有敌意。测试人员和程序员之间很容易形成对立关系。从程序员或开发小组的其他人员的角度看，软件缺陷报告是软件测试人员对他们的工作的“成绩报告单”，因此报告的语言不要带倾向性、个 人观点和煽动
33、性。软件缺陷报告应该针 对品，而不是具体的人，只陈述事实。旅叮谜竣轧馏源佐哟馏轮劫蚂荚查识琵伟茬化心聘亏淖询蕉毗乎爸凄癸之第9章软件测试过程所需的技能第9章软件测试过程所需的技能331、软件没有实现产品规格说明书要求的功能。、软件没有实现产品规格说明书要求的功能。2、软件出现了产品规格说明书指明不应该出现的错误。、软件出现了产品规格说明书指明不应该出现的错误。3、软件实现了产品规格说明书未提到的功能。、软件实现了产品规格说明书未提到的功能。4、软件没有实现产品规格说明书虽未提及但应该实现的目标、软件没有实现产品规格说明书虽未提及但应该实现的目标。5、软件难以理解、不易使用、运行缓慢，或者、软件
34、难以理解、不易使用、运行缓慢，或者 从测试员的角度看，最终用户会认为不好。从测试员的角度看，最终用户会认为不好。 9.2.1 9.2.1 9.2.1 9.2.1 缺陷报告的内容缺陷报告的内容缺陷报告的内容缺陷报告的内容软件缺陷：官方定义是至少满足下列五个规则之一的才称发生了一个软件缺陷。软件缺陷：官方定义是至少满足下列五个规则之一的才称发生了一个软件缺陷。席阶阔扶拯磅饱趋宴挞戴咐酒昭伎贝宴犯透援呵眩使姑梢显仟厄政浮忿融第9章软件测试过程所需的技能第9章软件测试过程所需的技能34 说软件有没有“某个功能”，是指软件 运行时发现“有某个功能”或者“缺少某个功 能”。由于不能报告没有看见的问题，因此
35、 没有看见就不能说存在软件缺陷。因此我 们的缺陷报告（也可以称为问题报告） 必须是在运行软件测试后，看到的软件 缺陷。 缺陷报告的内容在大多数公司都是大同 小异，不同的是组织和标志 。姐癌请齿秒持们远粉烹芋饲竹飘劣绑巾虫落氯宁兹拖民赁般梢竿摆电郭跟第9章软件测试过程所需的技能第9章软件测试过程所需的技能35缺陷报告的内容：缺陷报告的内容：（1）缺陷报告编号。）缺陷报告编号。它是独一无二的，不存在相 同编号的两份报告。（2）程序名）程序名。你测试的程序名。如果包含一个以上的程序需要说明。（3）版本号（发布号）。）版本号（发布号）。用来标识被测的代码。例如某个版本号可能是2.10b，产品会以发布号
36、2.10进行宣传，版本号中的“b”指出这是为测试创建和发布的2.10版本的第2稿。版本号可以告 诉程序员究竟哪个版本出了问题。雏血例沁忧权浊绊噬哉拌戊栋悍夜等壹锤肘越妄洲菱躲扑私语屠袱展吐羡第9章软件测试过程所需的技能第9章软件测试过程所需的技能36（4）报告类型。）报告类型。描述发现的问题类型。问题类型可分为编码错误、设计问题、文档错误、硬件、建议、质疑。（5）严重性。）严重性。对问题严重程度的评分。我们可以将评分从1（较轻的，如拼写错误）到10（影响巨大，如导致系统失效）分为10个等级，但现实中超过4个等级就很难可靠地评价问题。因此我们可以采用4个等级：轻微的，一般的，严重的和致命的。严重
37、性的评价需要注意之处是，如果缺陷的严重性等级被评价为“轻微”，那么它就往 往得不到修复，或者是被延迟等待修复。纬羔及翁冬呼痈侍踞剃木诡融甜卿分希嗽豁殴釉埔嚎情者吭干了制炽柳邮第9章软件测试过程所需的技能第9章软件测试过程所需的技能37 如果轻微的问题太多，就应该写一份后续报告 （评价为严重）以引起对它们的数量的关注（6）附件。）附件。报告缺陷时可能会附上的数据文件、图形用户界面的截图等。在报告中要注明包含了哪些附件。（7）问题概要。）问题概要。对问题进行简要描述，不用说明重现缺陷的步骤。概要可以帮助每个人很快地评审突出的问题，并找到相应的缺陷报告。 （8）问题能否重现）问题能否重现。能、不能或
38、者有时能。罕糕艰饮嫩校汐就籽饲起泞抨宾芜颇妨亢挛侩清匣般农颂翰四踩纱涤铁革第9章软件测试过程所需的技能第9章软件测试过程所需的技能38（9）问题描述。）问题描述。详细描述问题以及问题如何重现。从一个清晰的起始状态出发，一步一步地说明如何去做才能看到问题的发生。描述一下所有的步骤和现象，包括错误信息。如果你发现自己不知道该如何准确地重新构建出触发错误的条件，就承认现实如实填写报告。优秀的程序员时常能够从细致的问题描述中跟踪到很难重现的问题。因此，尽可能完全地描述所有的错误信息，这有可能会将问题完全暴露出来，不要因为问题没有重现就放弃提交报告。（10）报告人。）报告人。报告人的名字必须填写。 （1
39、1）时间。）时间。发现问题的时间，而不是填 写报告的时间。采咽桐把扼佯备纂国附磕天畸裙今耻您关耀举妈膘频科附奸亡拎亭甸骆芳第9章软件测试过程所需的技能第9章软件测试过程所需的技能39（12）责任人。）责任人。填写负责处理该问题的小组成员 或管理人员的名称。（13）注释。）注释。预留给程序员或项目经理等其他处理该报告的人员使用。难度大的缺陷往往会在注释中引发很长的讨论，这里会有很多人员的反馈信息。这是一种快速有效增加缺陷信息的方法。（14）状态。）状态。报告刚开始提交时都处于“开放（open）”状态。当已经确定缺陷已被修复或者大家同意这份报告不再是该版本的一个问题时，就将状态改为“关闭（clos
40、e）”。在不同的公司或不同项目中会对具有关闭该份报告的权限的人进行规定，通常为提交报 告的测试人员或是测试小组长。铣缉鼻撰芹演锦骇嵌玻凭咱恼翌仲靛擎奥踊眷奖帆察斤熄贩水臀烩峭漂洱第9章软件测试过程所需的技能第9章软件测试过程所需的技能40 不同的公司根据缺陷报告的处理流程可以自己 设置需要的状态，最常用的状态是：开放、关闭和已解决。程序员在查询需要处理的缺陷时只需在存放缺陷报告的系统中搜索状态为“开放”的缺陷，当缺陷被修复后状态改变为“已解决”；而测试人员需要搜索的是状态为“已解决”的缺陷，对其确认并判断是否进行关闭处理。（15）优优先先级级。优先级由项目负责人或小组共同决定，要求程序员根据优
41、先级依次修复缺陷。优先级通常是510级。不同的公司优先级的设置与定义也各不相同，例如： 毛糙吁督腋棠惦其梗濒栗笔紫渤条罕安鳃弯蒸贼可撩拘凋挂春秦槽饶妖躯第9章软件测试过程所需的技能第9章软件测试过程所需的技能41立即修复（这阻碍了其他工作）；尽快修复；在下一个里程碑（测试、测试阶段等）前必须 修复；项目完工前必须修复；如果有可能就修复； 任选（自行判断）。 实践中只有项目负责人才能改动优先级，而严重性只能由报告人员（或测试小组长）改动。项目负责人和报告人员可能会在缺陷的重要程度上有认识上的差别，但谁也改变不了对方的分级和权限。有时，测试人员将某个缺陷标注为“致命的”，而项目负责人却将其当做低优
42、先级来处理，这是因为测试人员和项目负责人都有自 己的缺陷重要程度的分类立场。仔均顿中钞紫内棕墩别叔茬趣蝇凑谗蝗刘扒皆渔咙互菜三负甄己泌江恬酪第9章软件测试过程所需的技能第9章软件测试过程所需的技能42（16）处理状态和处理版本。）处理状态和处理版本。处理状态与状态不同，它根据缺陷的处理流程更详细地定义了问题的当前状态。如果软件根据报告进行了修改，处理版本就指明了程序的哪个版本包含了这一改动。 下面列举了常用的不同类型的处理状态：下面列举了常用的不同类型的处理状态： 未解决。未解决。所有缺陷报告的初始状态。它提醒项目经理关注，对其划分优先级并安排人员处理。只要有与当前处理状态相抵触的新信息出现，
43、就应将报告改回到未解决状态。例如，如果程序员声称某个问题已经得到了改正，你却又重现了它，那么就应将处理状态从已改正改回到未解决。这瞅片吩堤渣毋萍柄喻架搅嵌求宛轩诗普镐割民黎盘烁央讼柄淳剧毫沤薪第9章软件测试过程所需的技能第9章软件测试过程所需的技能43 已改正。已改正。程序员负责标明缺陷已改正，除此之外，还要指明是针对哪个版本进行的改正。 不能重现。不能重现。程序员无法触发该问题。应在当前版本中检查该缺陷是否存在，同时确认对每一个必需的步骤都有清晰的叙述。如果你要增加新的步骤，应将处理状态重新设置为未解决，并在注释字段里说明所进行的操作。 暂缓暂缓。项目负责人承认问题确实存在，但是决定在这个版
44、本中不进行改正。无论缺陷反映了编码中的错误还是设计中的错误，暂缓都是合理的。 符合设计。符合设计。上报的问题不是错误，报告中描述的程序运行情况反映的是程序的预定操作。 报告人撤回。报告人撤回。如果报告的撰写人觉得还不如不 写这份报告，他可以把它撤回。除了报 告者,谁也不能撤回它。 肠供藩如瓜睁户抡稚矛诫仔窗榔吵绚谨臃悬灰咎笔衅着惰痘净芳测注舜胜第9章软件测试过程所需的技能第9章软件测试过程所需的技能44 需要进一步信息。需要进一步信息。程序员有一个必须由报告人解答的疑问。 不同意建议。不同意建议。设计上不会做任何更改。 重复。重复。很多组织使用这个处理状态码，并且关闭重复上报的缺陷。但如果你关
45、闭的是相似而不是相同的缺陷，就会带来风险。看起来相似的缺陷，其原因可能不同。如果你将某些缺陷报告为重复的，那么程序员将只对其中的一个进行改正，而不会意识到还有其他的缺陷。此外，不同的报告也会包含着很有用的不同描述。在报告中应交叉引用重复的缺陷。（17）暂缓处理。）暂缓处理。如果项目负责人承认某个缺陷确实是软件中的错误，但决定在当前版本中 不进行改正，那么该缺陷就处于暂缓 状态。编码错误和设计错误都可以被推 迟处理。 述泼返威尔腕卧弯贰箍闭甩唾冬肮寻小硝雄郭氨雌沤叛指燕至砖寡勺臂尊第9章软件测试过程所需的技能第9章软件测试过程所需的技能45当你遇到分类确实有误，或是对分类有不同意见，当你遇到分类
46、确实有误，或是对分类有不同意见，或是有人故意隐瞒缺陷，该怎么处理呢？或是有人故意隐瞒缺陷，该怎么处理呢？ 某些测试组修改报告的处理状态码。我们并不建议这样做，因为这会带来激烈的争论。 有些测试组拒绝接受原本应标注为暂缓而实际却标注为符合设计的缺陷报告。他们将报告打回给项目经理，要求他重新确定其处理状态。如果背后没有管理层的支持，不要这么做。 很多测试组忽视这个问题，结果许多问题被掩盖了。与优先级和扩展过的注释字段一样，这个字段反映了我们的看法，即项目经理与测试人员之间存在不同意见是健康而司 空见惯的。问题跟踪系统应该能反映出这种差 异，允许所有各方都能在报告上留 下自己的判 断。簇茬物诱渭捡粱
47、派厕剁涟诽扳示宗云范机闺苇净脏杯戍壮呐路满口艇敦片第9章软件测试过程所需的技能第9章软件测试过程所需的技能46（18）签签名名。有些公司使用手工的问题跟踪系统，人们在实际的报告单上签名。人们在报告单上签名，或者往在线系统中输入自己的名字，我们将这样的行为称为签署。每个公司都有自己的规定。规定必须由谁来签署报告单。我们认为，处理人这个字段应该始终由解决该问题（如进行了改正）的人或由他的经理来签署。有些公司在此处还加上了软件经理意见字段。处理测试人字段由测试人员签署，表明他已经对改动进行了测试，对结果表示满意，报 告可以进入关闭状态了。况蚀白饭樱刊貉硫卞缄敌怔慰欺册珠剃滑率涨肮蒙丫梭敷鄙宏罪揍玲弊
48、傅第9章软件测试过程所需的技能第9章软件测试过程所需的技能479.2.2 9.2.2 缺陷的分析缺陷的分析缺陷报告提交的目的是为了程序员能再现缺陷，从而找到修复缺陷的方法。如何重现缺陷，首先需要分析缺陷。分析和再现软件缺陷是充分发挥侦探才干的地方，设法找到收缩问题的具体步骤。好消息是，不存在随机软件缺陷这样的事如果建立完全相同的输入和完全相同的环境条件，软件缺陷会再次出现。坏消息是，验明和建立完全相同的输入和完全相同的环境条件，要求技巧性非常高，而且非常耗时。一旦知道了答案，就显得很容易。 生惠怠步艇镣关协爬冰犊凿赘竿埋槐豹醋钉搭堂望妮抽窄写后悼弊审匈阳第9章软件测试过程所需的技能第9章软件测
49、试过程所需的技能48如果找到的软件缺陷似乎要采用繁杂步骤才能实现， 或者根本无法再现，如下一些提示和技巧会打开局面。 如果碰到这种情况，尝试用如下的建议作为分析缺陷的第一步。（1）不不要要想想当当然然地地接接受受任任何何假假设设。记下所做的每一件事每一个步骤、每一次停顿、每一件工作。无意间丢掉一个步骤或者增加一个多余步骤会很容易出现的。请一个合作者看着你运行测试用例。利用按键和鼠标记录程序准确记录和回放执行步骤。如果必要，使用录像机记录下测试会话。所有这些的目的是确保导致软件缺陷所需的全部细节可现，并且可以从另一个角度分析。（2）查查找找时时间间依依赖赖和和竞竞争争条条件件的的问问题题。软件缺
50、陷仅在特定时刻出现吗？也许它取决于读取数据的速度，或者正 使用慢速软盘代替快速硬盘保存数据。看到软 件缺陷时网络忙吗？在更慢或更快的硬件上运 行测试用例。要考虑时序。瞎镰路窒傅鸽蛆仿妒啪暴园蛛咆糠艾鸟饭耕会肪驻柿酮考堂惨砚胶多堂待第9章软件测试过程所需的技能第9章软件测试过程所需的技能49（3）边界条件软件缺陷、内存泄露和数据溢出等白盒）边界条件软件缺陷、内存泄露和数据溢出等白盒 问题可能会慢慢自己显露出来。问题可能会慢慢自己显露出来。执行某个测试可能导致数据覆盖但是也只有在试图使用这些数据时才会发现也许在后面的测试中才可能。重新启动计算机后消失，而仅在执行其他测试之后出现的软件缺陷常常属于这
51、一类。如果发生这种现象，就要查看前面执行的测试，也许可以利用一些动态白盒技术，看软件缺陷是否在无意间发生。（4）状态缺陷仅在特定软件状态中显露出来。）状态缺陷仅在特定软件状态中显露出来。状态缺陷的例子是软件缺陷仅在软件第一次运行时出现或在第一次运行后出现。软件缺陷也许在保存数据之后，或按任意键之前发生。状态缺陷看起来很像时间依赖和竞争条件的问题，但是你会发现时间并不重要重要的是事件 发生的次序，而不是发生的时间。俯轰矽荡雕垫大内鄙釜呸猖跋赠羡猪浮阎玻缴迪钩开峭握杉怠略盎毯按裂第9章软件测试过程所需的技能第9章软件测试过程所需的技能50（5）考虑资源依赖性和内存、网络、硬件共享的相互）考虑资源依
52、赖性和内存、网络、硬件共享的相互作用。作用。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？虽然软件缺陷可能最终会被证实是由于软件的依赖性或对资源的相互作用进一步恶化的竞争条件、内存泄露或者状态缺陷问题，但是查一查这些（6）不要忽视硬件。）不要忽视硬件。与软件不同，硬件可能降级，不按预定方式工作。板卡松动、内存条损坏或CPU过热都可能导致像是软件缺陷的失败，但是实际上不是。设法在不同硬件上再现软件缺陷。这在执行配置和兼容性测试中尤其重要。需要知道的是缺陷是 在一个系统上还是在多个系统上出现。涌弄冰牛酬证莉泅铀范纵食呕烹姬砾层姬葡另辟嘎踩诞穗咀俺糯世畦跨挞第9章软件测试过程所需
53、的技能第9章软件测试过程所需的技能51（7）不要遗忘细节。）不要遗忘细节。如果测试是随时进行的（即没有拟 订测试计划），在测试中发现某个问题后你却无法重现它，那么很可能你忘记了一些所做的环节。在这种情况下忘记一些细节是很容易发生的，因为你没有一个详细的要做的事情的计划。有些时候，你可能几乎是随心所欲地敲击键盘的。如果测试中途被打断，你可能会把一些事情重复做两次，或是做些根本无关的操作，这些操作原本是无害的（例如开启或关闭一个终端设备或打印机，或是键入一个字符之后再按Del键。你应该努力准确地回忆起中断刚刚发生时正在做什么，中断期间又做了什么打发烦躁心情 的事情，以及刚刚恢复工作时又做了什么。尽
54、咒朴角懊放镁淡镀匆孙则帆蓝锗阑映抓氯钳聋妻碍土溉叁刹加畅攀传铝第9章软件测试过程所需的技能第9章软件测试过程所需的技能52（8）用户的错误。）用户的错误。所做的并非是以为做到的这常常被 用来解释“缺陷”。只要你没有重复所犯的错误，你也就 无法重现缺陷。即使这可能仅是猜测，当你用尽了可能的方案后也只能接受了。如果你认为用户会频繁地犯某个错误，而且程序对这个错误的反应也是不可预计的，就将程序的错误处理连同问题一起上报。不要忽视你的错误，应仔细地检查计算机会如何处理它们。（9）缺陷由长期积累形成。）缺陷由长期积累形成。错误可能不会立即产生影响。某个错误可能需要重复几十次，程序才处于崩溃边缘。在此时，
55、几乎任何操作都会导致程序崩溃，哪怕一个完全无关且不含错误的处理程序都会神奇地让崩溃发生。你可能 倾向于指责后续的程序，而不是那些缓慢地破坏 系统的例程。 丢栗川铀声锰驰袖碑译粱醋叛挠匹谆揪煽滔幢镑措憎吨膜峦踏蒸钻矩橇迂第9章软件测试过程所需的技能第9章软件测试过程所需的技能53 例如，很多程序都使用到了堆栈。堆栈是为临时数据预留的一部分内存区域。程序将数据放入堆栈的“顶端”并读取处于最顶端的数据。堆栈的规模可能很小，很快就被填满。假设某个堆栈能处理256个字节的数据，子程序A总是往里面放入10个字节的数据，执行完毕后任凭数据遗留在堆栈中，而没有清理掉。如果再没有其他的程序读取这些10个字节的数
56、据，那么当你调用了25次程序A后，它就往堆栈中放入了250个字节的数据，剩下的空间仅有6个字节。如果完全与程序A无关的程序B试着往栈中放入7个字节的数据，堆栈就会发生溢出。堆栈溢出常常会导致程序崩溃。从现在开始，你可以反复调用子程序B直到计算机精疲力竭，但除非也调用了子程序A25次，否则怎么也无法重现这个错误。如果你认为某 个很有嫌疑的例程并没有导致系统失效， 就应问一下有哪些例程在此之前运行过。征没建舒宣虫汉窑咖毖踩摄邮致盈崩玫泰墒艾万粪醋喉瓜拨锄阂弘荔淳肄第9章软件测试过程所需的技能第9章软件测试过程所需的技能54（10）如如果果尽尽最最大大努努力力分分析析软软件件缺缺陷陷，也也无无法法用
57、用简简明明的的步步骤骤再再现现，那那么么仍仍然然需需要要记记录录软软件件缺缺陷陷，以以免免跟跟丢丢了了。也许测试员仅用从程序员那里了解到的信息就能找到问题所在。由于程序员熟悉代码，因此看到症状、测试用例步骤，特别是努力分离问题的过程时，可能就会得到查找软件缺陷的线索。当然，程序员并不愿意，也没有必要对发现的每一个软件缺陷都这样做，但是有时这些难以分离的问题确定需要小组的共同努真功脐砾宾未果冉钒蹬滁河毡叙杯吧坝兔酱顾倡氨阀痪帆铁诽汽勉雌终增第9章软件测试过程所需的技能第9章软件测试过程所需的技能559.3 9.3 问题跟踪系统问题跟踪系统我们将用到问题跟踪系统来报告缺陷、我们将用到问题跟踪系统来
58、报告缺陷、记录缺陷、查询缺陷并编写缺陷总结报记录缺陷、查询缺陷并编写缺陷总结报告。告。一个好的系统有助于建立缺陷的可解释一个好的系统有助于建立缺陷的可解释性和联系性。性和联系性。要建立一个良好的跟踪系要建立一个良好的跟踪系统并不是太难，即使对于小型项目而言统并不是太难，即使对于小型项目而言它也是非常有价值的。它也是非常有价值的。弱废展钞捕爵床亿斌砾即助丰消犊烦璃帅迸色寞端痢胶埂威囱瞧斩几卯揍第9章软件测试过程所需的技能第9章软件测试过程所需的技能569.3.1 问题跟踪系统的目标与任务 问题跟踪系统的主要目标在于为修复那些应修复的缺陷提供帮助。任何不直接支持这个目标的问题，都不是关键问题。有些
59、其他的目标（如形成某些管理报告）都完全兼容于系统的主要目标。每当为系统提议添加新的任务和目标时，都应该将其与主要目标做比较。偏离了系统主要目标的任何目标都应被排除。 为实现问题跟踪系统的目标，设计人员及其 管理层必须确保完成以下几点任务：永糕付贮锗箭吱襟有束力褂株榆筹靡俯获屹锄垫靶蹲啄靖奶育蔑尺躺嚼萤第9章软件测试过程所需的技能第9章软件测试过程所需的技能5758 问题一旦报告，所有需要了解该问题的人必须立即获知。1 使仅因为沟通不畅而未得到改正的错误尽量少。3 不能有任何错误仅因为被某人遗忘而未得到改正。2 不能有任何错误因为某个程序员的一念之差而未得到改正。4四四方方面面皂不伊坟颜吴巢湿氛
60、雨畔涉墙兼滨仲卸瘩幅眉匠蹋剿翔浆眼项踩肪酥笔弃第9章软件测试过程所需的技能第9章软件测试过程所需的技能589.3.2 9.3.2 问题跟踪概述问题跟踪概述 定定义义了了问问题题跟跟踪踪系系统统的的总总体体目目标标和和任任务务之之后后，下下一一步步是是要要看看在在现现实实中中缺缺陷陷报报告告是是如如何何被被处处理理的的，包包括括对对问问题题的的常常规规处处理理。我我们们面面临临的的挑挑战战是是如如何何构构建建或或选选择择一一个个问问题题跟跟踪踪系系统统来来很很好好地克服这些困难。地克服这些困难。烽向舷昂棱镶辨颗衔猴迹傻人纬愚软淫寂鞋闰狗背鸽狭豢神播委抵毫添胯第9章软件测试过程所需的技能第9章软件
61、测试过程所需的技能591问题被上报问题被上报 我们已经讨论了起点：发现缺陷、调查细节，直到写出清晰的描述、输入一份缺陷报告。下一步就是要将报告录入到跟踪系统中。 在很多公司里，提交缺陷报告与将报告录入到跟踪系统实际上是一回事通过往数据库中键入报告内容提交报告。但是在有些公司里，原始的缺陷报告是手写在标准表格上的，然后再由其他人录入到跟踪系统中。 很多公司虽然允许测试人员直接将缺陷报告录入到数据库中，但还仍然需要有其他的职员（比如技术或客户支持人员、行政支持人员或销售人员等）将每份报告提交给某个人（比如测试人员、系统分析员或项目经理 等），由他们来决定是否将报告录入到数据库中。 这些情况很难达到
62、平衡。槽廖菇镭霄向跋此舌帘视涅吓垫案可被径映婶率闪赚椅叁绷丹蒲聪恬掇窃第9章软件测试过程所需的技能第9章软件测试过程所需的技能60 一方面存在着浪费时间的风险。由非技术人员提 交的报告往往是不完整的，或是问题没说清楚，倒反映 出报告员对产品设计缺乏了解。另一方面，有很多重要的 问题会被无意中遗漏或被有意排除，仅当用户投诉或被某刊物批评后方才显现出来。跟踪系统可能是单用户或是多用户的。 典型的单用户数据库安装在测试工作间的某台计算机上。每个人都在这台机器上录入或读取报告。仅有测试人员或是部分测试人员才可以直接访问该计算机。缺陷报告和项目状态总结报告由项目安排的某个测试人员打印和发放。而典型的多用
63、户系统位于计算机网络或大型机上，能够被所有的测试人员和项目经理访问。程序员和技术文档编写人员也可能有权访问。市场营销人员和技术支持人员可以有权，也可以无权访问它（我们认为他们应该有权访问）。在一个多用户系统中，任何 有权访问的人都可以录入自己的报告、查询数据库 和打印总结报告。帕墟刁剖痹檀辕蛰倪怠筏虎甜茨藐晚穴修辑炬磊钾铰鳃僻较咆鞠岔盎纬止第9章软件测试过程所需的技能第9章软件测试过程所需的技能612 2报告提交给项目经理报告提交给项目经理 一旦报告录入到数据库中，就会有一份副本提交给项目经理。在多用户系统中这是自动完成的，项目经理可以直接访问数据库，报告一经录入他们就可以看到；而在单用户系统
64、中，测试工作每隔几天向项目经理提交一份新报告。 通常项目经理要么划分问题优先级，将其转交给程序员处理，要么按如下方法处理报告。（1）在大多数情况下，项目经理会对报告进行评价，加注意见，划分优先级，然后转交给程序员处理。在高优先级问题得到改正前，低优先级的报告不会得到关注。在很多公司里，原有的优先顺序可能会打乱，当程序员正在处理某一代码区域的高优先级问题时，相同区域的低优先级问题也会被处理。对某个区域的问题集合进行整体评价并一起改正，会更为容易、快捷，通常也会更为有效彻底。 （请注意，这种做法依赖于由测试人员或程序员对报告 进行良好的分类。）恤撅交脚寂秦豌嗣汞腥路还炭刃揣状胜问族然往矾族瘟缔辟恳
65、胸泉储祟环第9章软件测试过程所需的技能第9章软件测试过程所需的技能62（2）项目经理的处理方式可能是暂缓处理该报告或注明符合设计，或要求报告人将问题重新分类，归结为文档编写的问题，或是找到报告者，确认手册中（可能是在问题解决部分中）包含了该问题。 最终，获得更多细节的要求得到了满足，项目经理把报告交给程序员，由其改正问题或进行其他处理（暂缓、保持原设计或经测试证明无法重现）。有些项目经理可能是由于心不在焉或是故意将一些报告束之高阁一段时间，既不确定优先级又不进行答复，一个良好的总结报告系统能够揭示出一些问题，并促进问题的解决。3报告由项目经理转交给程序员报告由项目经理转交给程序员 报告转交给程
66、序员后，项目经理会要求程序员改正问题， 或要求他调查和解释为什么缺陷无法修复。一般情况 下，缺陷都能得到修复。北隶碾寝咕涟蚕谋叫桶谴谗眉挫材陕渡篮萍紊哩晚城剿彤渣理殿匆拼书球第9章软件测试过程所需的技能第9章软件测试过程所需的技能63 程序员也有可能不改正问题，相反，他会要求得到更多的信息，或会认为这个缺陷根本无法重现、难以修复，甚至认为根本就不是缺陷，傻瓜才会遇到这种情况，测试用例很不合理或是根本不值得加以关注（有时他的想法确实是有道理的）。有些程序员总是喜欢逃避缺陷，他们故意对某些报告熟视无睹，寄希望于没有人能注意到它，拖到太迟了而无法进行处理，或是将跟踪缺陷的过程搞得非常痛苦，寄希望于报
67、告人员不堪忍受而放弃。测试人员是唯一能深入对抗程序员的抵触情绪的人。 缺陷报告中的注释部分是对抗抵触的有力武器。你（或是项目中其他的测试人员）应在注释部分中详细录入每一条意见、说明、否定意见和理论解释。 顺便提一下，在所有项目的某些阶段，测试人员会坚持认为自己受到了程序员不合情理的抵触。这种感觉往往是不正确的。在每份缺 陷报告中详细的注释过程能够为项目经理和测试经理提供 数据，以消除误解，减少程序员与测试人员之间的摩擦。栓棕捕去图脱鹿穴锗缠棉章回钉驼无捏础厘啃硼公弛撅颂湖剔郡弟酵沧及第9章软件测试过程所需的技能第9章软件测试过程所需的技能644当缺陷已经修复（问题已改正）当缺陷已经修复（问题已
68、改正） 程序员改正了某个问题之后，会将问题在数据库中标识为“已改正”，还可能再加些注释。然而，这并非一份报告的结束，因为程序员常常会犯错，要么问题并未得到解决，要么代码改动后又会导致新的问题。 根据我们开发微机零售软件包的经验，将失败的比率控制在10%以下就已经很好了。对已改正的问题重新测试，最好还是由上报该问题的测试人员来做。如果报告人不是测试人员，由你来重新测试某个问题，那么应该确认你能够在程序未经改正的原先版本中重现该问题。你应该在手头上保留程序最近的三个版本，这样可以很容易地重现原先的缺陷，也可以拿程序当前的运行情况与过去相比较。 当缺陷报告又回到你手中时，你可以再次执行报告中的那个测
69、试用例。你常常会吃惊地发观做过的改正根本不起作用。烂这崭咎庞搜箔胡聘克蹦熏副阳授泅束蛙学荔蛔拆呀磐询律嘛涪撵麻牢续第9章软件测试过程所需的技能第9章软件测试过程所需的技能65 如果改正过的程序通过了原先的测试（多数会通过），那么就再试着做一些变化。阅读一下程序员的笔记和记录在报告上的其他所有注释。做过的改正会影响到程序的哪些部分？变动破坏了哪些东西？做一些测试，测试一下由变动带来的明显的副作用，另外，对原先的测试用例做一些修改。如果发现了一个错误，就很可能还存在着更多的错误。找一下比报告中的问题更一般化的问题或相关的问题。对“已改正”的缺陷进行分析，尝试一下对测试做一些变化，在这些方面测试人员
70、花的时间不是太多了，而是太少。如果先前通不过的测试程序现在仍然没有通过，就应在原先的缺陷报告上注明，将报告上的处理状态从已改正改回未解决，并将其递交给项目经理或程序员。 如果程序通过了原先的测试，通常较好的做法是把原先的报告置为已改正并将其关闭，再开启一份新报告。多数程序员和项目经理都喜欢这种做法。与记录问题改正过程的报告 相比，此类报告更简单，更易理解。贞椰寇次蚁端肌击闪残栋骂体矗溶蚂苇应疗炒秉曲疏萄旁揣澜详饯擂末拥第9章软件测试过程所需的技能第9章软件测试过程所需的技能665无法重现的缺陷（问题）无法重现的缺陷（问题） 如果程序员和项目经理无法重现缺陷，他们就无法改正它。他 们会将报告标注
71、为不能重现，再打回给你。因此你应该努力重现出该 缺陷。如果有必要，在你当初发现缺陷的程序版本上试着重现缺陷。 如果你可以重现缺陷，就在报告上说明（写在注释部分），并补充 一些细节供程序员自己重现缺陷。如有必要，可以找到程序员或项目经理，亲自向他们演示，或向他们提供一份测试报告或视频记录。应将你所演示或提供的内容在注释中说明。 如果你无法在当前版本中重现问题，却可以在以往的版本中重现， 尤其是如果对相关代码的最近改动可能已经改正了该问题，那么通常较好的做法是将原先的报告标注为已改正并关闭它。应始终与程序员或项目经理一起仔细检查，方可标注某个缺陷为已改正。往你的测试计划里加上一个注解，在随后的一个
72、或两个版本中重新测试该问题，确保已得到彻底改正。 如果在任何版本中你都无法重现缺陷，应确认该缺陷是不可重现的，但在随后的几个版本里都应保持报告的状态为开放，或许要到下一个主 要的开发里程碑方可关闭。在每个新版本中都试试看，如果 在几个版本里（或到里程碑前）你都无法重现它，就可以关 闭报告了。甭瞬吹酶厚卤窍尔辟摩呐客粳颓兹所陈越逞澜搀兄奄凤邮肾穷梯壮妖猫鬼第9章软件测试过程所需的技能第9章软件测试过程所需的技能676问题暂缓与申诉过程问题暂缓与申诉过程 状态为暂缓表示承认有问题存在，但项目经理决定不对当前 版本进行改正（有些开发小组使用的是第三种反馈信息：不能改正， 意为永远搁置起来）。在任何一
73、个经过了充分测试的商业质量良好的 产品中，仍然会有很多编码错误和设计问题被暂缓处理了。 任何项目在临近尾声时，改正代码带来副作用的风险都会大大超过改正小的编码错误所带来的好处。在缺陷报告的注释部分，很多项目经理会简要地对为什么将问题暂缓处理给出解释。这些材料在申诉会议上非常有用，特别是当开发产品的后续版本时尤其有用。 如果项目经理将某份缺陷报告标注为符合设计，就意味着他认为程序是理应这样运行的。如果他的这个意见是在设计缺陷报告上做的，你应该检查一下他的意见，确认他明白了你的意思：程序确实是应该这样运行，但你认为这样的设计存在问题。如果你无法确认这一点，就应该去问他。有些项目经理将任何的暂缓都视
74、为承认失败，他的应对之法是将很多实际的错误标注为符合设计，而不是暂缓。（也许错误依然存在，但他们不愿接受。）当总结报告单独提出暂缓处理的缺陷时，将缺陷归类为符合设计而不是暂缓会使统计数据更好看一些。 此外，许多暂缓评审会议（下面会介绍到）仅关心暂缓的缺陷， 因此将缺陷归类为符合设计可以有效地逃避审查。兑扯岂友烦宗祁社挣耪虚竟屎津松旋伞烤柠孩偏推薛帛譬藏裴酌额萍泞谚第9章软件测试过程所需的技能第9章软件测试过程所需的技能68 最后值得一提的是，在有些案例中，在测试人员和项目经 理的观念中，将问题标注为符合设计或暂缓仅仅不过是诚实与否 的问题罢了。 将某个问题标注为符合设计还是暂缓，如果在这一点上
75、测试人员与项目经理之间存在着不同意见，有些测试组的做法是将处理状态标注为暂缓，这样也不会触怒项目经理。 每隔数周时间，尤其是临近项目结束时，项目经理或主任测试员应召开一个暂缓缺陷评审会议。在一些公司里，符合设计的报告也要在同一个会议上进行评审。在评审会上做出是否将某个缺陷暂缓处理的最终决定。 这个会议同样是申诉的场所。所有被邀请到会的人都可以对任何缺陷的暂缓处理提出反对意见。会议集体对此进行辩论，最终决定是接受暂缓处理，还是要求项目经理付出更大努力改正问题。如果会议同意将问题暂缓处理，该问题也随之关闭。在当前版本发行 之后，后续版本的开发开始之际，方需再次考虑。按期 举行评审会议，最终决定问题
76、是否暂缓处理，这对于项目的成 功非常重要。尽爸揽果裳走柄临副钾径六啊滇葵迷蝴帮毙头雪证思降利陈谈慨屁魄氛七第9章软件测试过程所需的技能第9章软件测试过程所需的技能697未被处理的问题未被处理的问题有些缺陷报告会被丢失，有些会被有意搁置起来，还有些被分配了 较低的优先级，最终被遗忘掉。所有的这些问题在产品交付前都必 须得到解决（改正或用其他方式处理），这是一条重要的法则。与之相悖的其他法则都会助长马虎习气。为了确保没有任何未解决的问题被人遗忘，应每隔一两周就发放一份总结报告，列举出所有暂缓处理的报告，这样做是值得的。还有一种很有效的办法，即在项目每个里程碑的前几周，和项目经理一起对此类报告做详细
77、的评审。评审会议的目的在于对每个开放的缺陷都做出决定，要么必须改正，要么在里程碑即将到达前解决。如果你的运气不错，和你一起工作的项目经理愿意参加此项会议，那么你得表现得通情达理些，否则下次他就不会愿意参加了。评审会议不仅确保了某些问题能够立即得到关注（包括许多原本想隐藏起来的问题），还给项目经理提了个醒，应关注那些不太急迫的问题，必须计划出时间表。评审 会议态度坚定但不失柔和，强调任何一个这类的问题都不应被 遗忘掉。从整体上审视所有未改正的问题，也有助于项目经理 找到人员或工作量方面存在的问题。八哩肇柒力突浩广树簧噎癣企畸湛被募案夜豁榔暂墨盈疡秃寒硝惹磨假瞳第9章软件测试过程所需的技能第9章软
78、件测试过程所需的技能708项目状态报告项目状态报告 这些便利的报告叙述了有多少缺陷在项目中被发现，有多少仍然很突出，有多少被暂缓处理，相比之下，又有多少缺陷已被修复，有多少是由测试人员发现的，有多少是被其他人发现的。这些报告显示出项目的每周进展，以及进展的总体情况。状态报告有助于项目经理评价编程工作的质量、当前产品的可靠性、测试工作的效率，以及新缺陷发现率与缺陷修复率之比等（还有项目可能的完成日期）。浓白殿实恢寇里亨估胶婚振茅雨旷龙浓恰入笋啸坍鸿杉据哄工诣弹偿阵衅第9章软件测试过程所需的技能第9章软件测试过程所需的技能719.3.3 9.3.3 问题跟踪系统的问题跟踪系统的使用者使用者 如果由
79、你上报了某个问题，阅读或回复了某份缺陷报告，编写或审核了一份关于这些问题的总结报告，那么你就是跟踪系统的使用者。很明显，测试人员不是跟踪系统的唯一使用者。跟踪系统由测试组进行维护，但是整个系统属于公司，而不属于测试组或任何测试人员。词晨汉彩晌路察擎仑犁射绦割宜梯憎菇绊式暴祈崇栖死屏锹搂纹特瓷累威第9章软件测试过程所需的技能第9章软件测试过程所需的技能721主任测试员主任测试员 主任测试员领导着项目的测试工作，并对测试和缺陷报告 的质量负有责任。他可能是唯一被允许关闭缺陷报告的测试人员。由他来审核所有带着疑问的报告，包括被当作不可重现，或要求提供进一步信息而被打回的报告。他审核所有标注着暂缓和符
80、合设计的报告，决定在评审会议上对哪些提出质疑。由他来准备和发放总结报告。他会定期地审视每份报告，寻找沟通不畅、测试效率低下（仅有少数问题被报告，或是重要程度低的报告过多等）或能够通过与项目经理私下交谈而得到改善的摩擦问题及缺陷改正率等问题的迹象。他还会寻找问题（尤其是无法重现问题）的线索，以提示对程序的哪个部分需要进一步的测试。2其他测试人员其他测试人员 其他测试人员上报问题，并关注问题如何解决。他们对所有已改正的问题进行重新测试。由他们重新考虑所有暂缓处理的问题以及所 有被拒绝的设计问题，修改旧报告或重新提交新报告（如果 想出了更有说服力的方式来解释或描述问题的话）。毡搓滋仔编我犊售绝耙茄蔷
81、跨紧狄揉币焰心扦摈沥呵剔跺馆铰浊请婪但啃第9章软件测试过程所需的技能第9章软件测试过程所需的技能733项目经理项目经理 项目经理负责按期交付高质量的软件产品。他总是在不断地 平衡成本、可靠性、产品能力（特征）以及时间进度。数据库是强大的数据来源，描述了产品当前的可靠性以及与工期有关的进展过程等。 项目经理决定哪些问题应被改正，优先等级如何划分，以及哪些问题不做任何处理（提交给申诉过程）等。 很多项目经理每周会审查数据库中所有的暂缓处理的缺陷，寻找沟通问题、人员问题、暗示问题存在区域的缺陷线索，以及设法改正仍会存在的个别问题。问题老是存在说明，改正缺陷的程序员需要咨询帮助、参考资料或一些调试工具
82、。项目经理工作的一个非常重要的内容，就是从缺陷报告的过程和注释中辨别出哪些人需要技术帮助，然后给予他们帮助。在项目临近结束时，细微但总是存 在的缺陷会被暂缓处理。博密螟悬君绵仓秉贬糖畸洁湃叮卓峪批直渊范崭宦铱劲蜕杆奎斧晚处侮住第9章软件测试过程所需的技能第9章软件测试过程所需的技能744程序员程序员 程序员阅读缺陷报告，并对其作出响应。在下列情况下，报告会触怒程序员。（1）报告模糊、简单化或无助于跟踪该缺陷。（2）报告没有说清楚测试人员会反对什么，程序员预计会对此做什么。 有些缺陷报告看起来就好像是一份关于程序运行情况的概述，最 终读者会问：“没错，但问题是什么？”（3）报告的问题是无法重现的
83、。（4）因需要进一步信息而被打回的报告又被送回，所需的信息却没有。（5）测试用例非常复杂，而测试人员并没有提供可用的测试材料。（6）报告的措辞可被视为人身批评。（7）从问题跟踪系统中得到的总结统计信息被项目经理用来评价个人 业绩。痴惮闰铲南氓漱写伯辉凳旁婉联脂庐夯壕斗荔竟挣茂羚磅踪乃虞柏剧聋峙第9章软件测试过程所需的技能第9章软件测试过程所需的技能755产品经理产品经理产品经理关注的是任何会影响产品销售或技术支持成本的问题。在某些时候产品经理会极力要求产品具有高质量，而在其他时候可能更关心产品进度。但即便如此，如果他认为产品含有市场无法接受的质量问题，他也会拒绝交付。产品经理通常会由于太忙而无
84、法审查所有暂缓处理的缺陷，可能不愿或无法有效地利用问题跟踪系统。在很多公司里，人们会打印出一份专门的总结报告供产品经理阅读，用醒目的颜色引起其对特别问题的注意，这样的时间花得是值得的。6技术支持技术支持技术支持人员负责为客户提供信息、为管理层降低服务费用，并使产品评价起来更为优秀（如果在产品的评分规则中包含了技术支持的质量）。技术支持与每个暂缓处理或被遗漏的缺陷、每个被拒绝改正的设计问题、用户手册中的每个错误或不清晰之处息息相关， 因为它们会导致用户打来电话，耗费支持人员的时间，并 且需要支持人员收集信息提供给用户。绷吓托鳖推夫霓藏泪厂殿伸累甲疫虑辉耶睛跋野元孩德抨芥阴捍听转诽枝第9章软件测试
85、过程所需的技能第9章软件测试过程所需的技能76在产品发布前，通常是在程序相当稳定之后，技术支持人员常会 对程序与手册进行审核，然后录入缺陷报告。这些报告会识别出 可能导致用户迷惑或不快，并招致投诉电话的问题区域。用户的投诉电话是重要的质量指标（越少则质量越高），处理起来劳神费力。技术支持人员常常会参加缺陷暂缓评审会议，并对可能导致用户投诉率上升的问题暂缓处理提出反对意见。技术支持部门常常要求在缺陷报告中对所有暂缓处理的问题和拒绝更改的设计问题给出说明，以便当用户打来电话时可以进行解释。往数据库中添加此类信息是非常耗费时间的。项目经理不想让程序员做这些事情，他们得忙于完成编码，因此常常得由测试人
86、员完成这项工作（导致测试工作减少，更多的缺陷被遗漏）。技术支持人员在产品发布后还要使用数据库。当用户报告新发现的问题，技术支持人员要填写缺陷报告，并了解由谁来对此问题进行正，以及完成改正后何时交付。由于用户拿着产品在等待解决，问题周转的时间对技术支持人员显得非常重要。显示平均周转次数的统计字， 以及对开发人员反应效率的其他度量数字对于技术支持管理 非常重要。臻弃削嘎寿耕杂排鸣报姐排贿聊谗记葛断帘期泣澈思槐霖裙荔谭覆尸灭荤第9章软件测试过程所需的技能第9章软件测试过程所需的技能777文档编写人员文档编写人员文档编写人员负责编写用户手册，有时也包括技术支持材料以及 其他技术或销售文档。他必须知道设
87、计方面所做的变更，包括缺陷 的暂缓处理会对程序的可见运行情况产生的影响。缺陷跟踪系统提供 了非常有用的变更信息。同时，文档编写人员还非常关心项目状态信息：程序编写是否按时，下一步的文档编写是否应推迟以适应程序员的进度，用户界面何时能真正固定下来等。文档编写人员在编写手册时也会偶然发现程序的缺陷。如同测试人员一样，他会使用跟踪系统录入有关可靠性和设计的缺陷报告。测试人员也会编写一些缺陷报告，指出用户手册中存在的问题。一般情况下他们只会在原件的复印件上写上意见，但如果手册与程序运行情况间存在着某个无法解决的差异，尤其是手册确实符合规格说明的情况下，测试人员会将这些缺陷报告上报。如果设计发生了变更，
88、手册就必须随之改动。还有些涉及程序运行不正常的缺陷报告最终会交到文档编写人员那里，要求他们加上一个问题解答部分，或在手册中标记出设计变更之处。在 这种情况中，文档编写人员在系统中很大程度上充当了与程 序员一样的角色。他可以查询缺陷报告，修改手册，将缺陷 报告标志为已改正，然后再将其原路返回。浑唯兢站旧穆苫恕亢瘴讥捉戴汗乃典丝嘱某掀山狱久曲棉痛造粮鲜炙吾削第9章软件测试过程所需的技能第9章软件测试过程所需的技能78跟踪系统与文档编写人员之间的关系在不同公司之间也有不同。 在一些公司里，这种关系被认为是非常紧密的，文档编写人员和 测试人员会工作在同一个部门；还有一些公司里，文档编写人员的 工作与跟
89、踪系统没有任何关系。8测试经理测试经理 测试经理负责测试工作的质量以及管理测试员工。他对缺陷报告进行审核，思索这些报告是否暗示测试人员需要进一步培训。他还会寻找测试组与其他部门间存在的沟通或工作量分配问题。 一些测试经理面临着诱惑，总是想从数据库中收集员工个人工作效率的统计数字。每周每个测试人员上报了多少缺陷？我们发现研究上报的缺陷的数量很有用。下面是需要考虑的一些问题。 （1 1） 谁上报的缺陷数量更多一些，是测试人员、文档编写人员、技术支谁上报的缺陷数量更多一些，是测试人员、文档编写人员、技术支持人员，还是项目经理？一般情况下测试人员上报的会多一些，但是很持人员，还是项目经理？一般情况下测
90、试人员上报的会多一些，但是很多问题常常是由项目经理或与其一同工作的人员提出的。多问题常常是由项目经理或与其一同工作的人员提出的。豁式缄帽掠选盯骤伎悟眺恤愉川沽甥柠嗽思摄吨兔质抽贸凳憎改祖镭似宅第9章软件测试过程所需的技能第9章软件测试过程所需的技能79（2 2） 每周由每个测试人员上报的问题的数量模式是否有意义？每周由每个测试人员上报的问题的数量模式是否有意义？在测试之初，测试人员往往会报告很多设计问题，临近在测试之初，测试人员往往会报告很多设计问题，临近里程里程碑时会报告大量的缺陷，因为代码不太稳定，这有赖于项目情碑时会报告大量的缺陷，因为代码不太稳定，这有赖于项目情况。如果产品非常不稳定，
91、你会看到一段持续的增长率，可能况。如果产品非常不稳定，你会看到一段持续的增长率，可能数周仅有五份报告，但每份报告都对重要的周期性问题做了深数周仅有五份报告，但每份报告都对重要的周期性问题做了深入研究。而在其他项目中，你会看到有一段时间报告数量持续入研究。而在其他项目中，你会看到有一段时间报告数量持续增长，反映出测试人员越来越熟悉程序及可能存在弱点之处。增长，反映出测试人员越来越熟悉程序及可能存在弱点之处。接着当程序稳定下来之后，报告数量又会逐渐减少。数量模式接着当程序稳定下来之后，报告数量又会逐渐减少。数量模式在变化，但对被测程序而言都非常有意义。应该关注的是被报在变化，但对被测程序而言都非常
92、有意义。应该关注的是被报告的问题类型，而不仅仅是报告的数量。能够体现程序得到详告的问题类型，而不仅仅是报告的数量。能够体现程序得到详细检查的表现方式应该是相当稳定的数量变化，而不是很高的细检查的表现方式应该是相当稳定的数量变化，而不是很高的缺陷上报率。缺陷上报率。 我们发现，如果没有详细地阅读每份报告，仅考虑每个测我们发现，如果没有详细地阅读每份报告，仅考虑每个测试人员报告的缺陷数量可能会产生误导。例如，有些测试人员试人员报告的缺陷数量可能会产生误导。例如，有些测试人员要比其他人探索得更为全面，花了大量时间跟踪较难重现的问要比其他人探索得更为全面，花了大量时间跟踪较难重现的问题或较难测试到的区
93、域，他们报告的缺陷数量会大大低于组内题或较难测试到的区域，他们报告的缺陷数量会大大低于组内 的平均水平。我们通常会称这些人为的平均水平。我们通常会称这些人为“高级测试人高级测试人 员员”，而不是，而不是“低产测试人员低产测试人员”。 则贸饺菠甩汰肥允衫去覆弊徒器姚辫邵陋蒸力旦务辅氛尹至萧糟婿陇耶盾第9章软件测试过程所需的技能第9章软件测试过程所需的技能80 我们只是偶尔地关注一下缺陷数字（不是每周都这样做）， 但从不引用它们。我们只是私下记录这些数字，阅读缺陷报告。如 果确实有问题，我们会采取相应措施。我们非常不愿意在公开或私下场合对任何人（包括测试人员）引用任何缺陷统计数字。9高级经理高级经
94、理 高级经理不会注意单独的缺陷，除非某些特别严重的问题被暂缓处理。当主任测试员、测试经理、项目经理等人注意到某个似乎需要管理层关注的问题时，会让高级经理了解情况。值得管理层关注的问题主要有以下几种：（1 1）程序的表现让公司受窘。）程序的表现让公司受窘。这包括代码中包含的非常粗鲁的错误信息 等。（2 2）提供核心功能（该功能已经被广泛宣传，或者任何明智的用户都希）提供核心功能（该功能已经被广泛宣传，或者任何明智的用户都希 望获得的）的程序发生了失效。望获得的）的程序发生了失效。如果字处理程序无法提供打印而项 目经理又将其暂缓处理，更高层的管理人员就需要对此重新考虑。（3 3）连通情达礼的人也会
95、被程序的表现严重惹恼）连通情达礼的人也会被程序的表现严重惹恼。当程序受到了未经授 权的复制时，如果你应对的版本保护方案是删除用户硬 盘，那么应该在程序交付前通知总经理或公司律师。冰恼猪逆釉袁敛巨逮掺翅宙嚏护疗服窄谢擒扦玫粮族卉澎阵澈帕骤训盘枷第9章软件测试过程所需的技能第9章软件测试过程所需的技能81我们已经提到了使用跟踪系统监视测试人员工作业 绩带来的一些问题。主管人员也需要使用似乎客观的方法来衡量个人的业绩，尤其当他们打算解雇某人或对某些人施加压力时。数据库提供了每一个测试人员、程序员和项目经理的现成的详细工作信息。主管人员需要了解项目的状态，他们需要客观的信息，不会花很多时间思考它们。他
96、们会谨慎地接受每周上报的重大缺陷统计数字及缺陷上报和改正的数值表。因此要谨防不加进一步解释就认为这些数字是有意义和非常重要的。如果系统向管理层提供个人评价信息，影响到他们的升迁和工作保障，员工们就会着手保护自己。下面列举的 是一些你常会卷入的争端。诀方鲸惩愧荔瑰矽螺蜜镁舆韧柬厦摹扎缨屈和退篓肄捶磅王纵挨坝挑喂衰第9章软件测试过程所需的技能第9章软件测试过程所需的技能82（1）你会被要求收回每一份重复的缺陷报告。（2）你会被要求收回那些看来并不相似，但据说是由同一 基本问题 引起的报告。（3）你会被要求收回所有的质疑，因为这不是缺陷报告。（4）你会被要求收回所有的设计建议和大多数的设计问题。（5
97、）你要计划花上数天时间来争论报告究竟是指出了真正的缺陷，还 仅仅是设计错误。（6）每当你的员工上报的某个“缺陷”，实际上是个用户错误时，等着 他们被批评。（7）期望被要求收回每份无法重现的缺陷报告。（8）不要指望有任何程序员或项目经理会报告在产品开发期间发现的 任何缺陷。 结论是问题跟踪系统的目的是使缺陷得到改正，而不是要产生细密结论是问题跟踪系统的目的是使缺陷得到改正，而不是要产生细密的管理统计数据。的管理统计数据。那旨厌鞠竣英翌喧鲸絮荣狈振播幻掏先剖隧揽鸥柠晓烦嚏泥麻瘤夸君煽浮第9章软件测试过程所需的技能第9章软件测试过程所需的技能83 本本 章章 小小 结结本章讲述了在实际的测试工作中需
98、要用到的实践技能：如何编写三个主要测试文档（测试计划、测试用例、测试报告），如何提交软件缺陷报告和分析重现缺陷，以及如何使用问题跟踪系统。让读者对软件测试的工作内容的丰富程度有较深理解，除了有扎实的测试基础知识和积累的实践经验，还需要在公司组织内部有良好的沟通能力。 忌股好褐饰久厂馒蜀家窑啊综颤寥舜毖柿午章铭包困芯荷奸邹豆婪邻技锤第9章软件测试过程所需的技能第9章软件测试过程所需的技能84习习 题题1IEEE829-1998标准有哪些测试文档？它规定了我们必须编写哪些文档吗？2软件缺陷的官方定义是什么？3请归纳一下分析软件缺陷的技巧4请描述一下测试人员如何使用问题跟踪 系统。潜羽踌臃藏亮腺喇脑丽擦旋多鼠壶辊社怜迄室肛撇句勺栽残鞭腋诀饲耽赚第9章软件测试过程所需的技能第9章软件测试过程所需的技能85
