测试执行与缺陷报告跟踪

1、第十三章测试执行与缺点汇报、跟踪1/49目 录 软件测试执行与跟踪 1 软件缺点描述2 软件缺点相关信息3 软件缺点跟踪和分析4 软件缺点跟踪系统52/491软件测试执行与跟踪 3/491.软件测试过程关键点不一样测试阶段执行关键点测试用例执行团体建设与沟通测试执行结束 4/491.软件测试过程关键点测试执行实践过程执行前开一个动员会，严格审查测试环境抽查性质探索式测试，验证高风险区域测试质量交叉交换测试人员所测试模块，能够发挥互补作用良好沟通，如每七天例会，以及和开发人员及时沟通测试时间被压缩 测试策略优化、计划调整 测试需求优先级、调整测试范围常规缺点审查，及时发觉问题、纠正问题，使整个测

2、试进程在控制轨道上发展。阶段性结果分析，确保阶段性测试任务得到完整执行并到达预定目标。5/492.测试项目进度管理方法 测试项目里程碑任 务天任 务天任 务天任 务天M21: 测试计划制订11M23: 测试设计12开发测试过程5验证测试结果2确定项目1测试用例设计7测试和调试测试过程2调查突发结果1定义测试策略2测试用例审查2修改测试过程2生成缺点日志1分析测试需求3测试工具选择1建立外部数据集1M62: 测试评定3估算测试工作量1测试环境设计2重新测试并调试测试过程2评定测试需求覆盖率1确定测试资源1M26: 测试开发15M42:功效测试9评定缺点0.5建立测试结构组织1建立测试开发环境1设

3、置测试系统1决定是否抵达测试完成标准0.5生成测试计划文档2录制和回放原型过程2执行测试4测试汇报16/492.测试项目进度管理方法 进度与质量关系 进度与成本关系 7/492.测试项目进度管理方法 测试进度 S曲线法 进度S曲线法经过对计划中、尝试与实际进度三者对比来实现，其采取基本数据主要是测试用例或测试点数量 8/492.测试项目进度管理方法 测试进度NOB曲线法在整个测试期间主要搜集当前全部打开缺点数量，也能够将严重级别缺点分离出来进行控制，从而形成NOB曲线，在一定程序上反应了软件质量和测试进度时间发展趋势9/492.测试项目进度管理方法 10/493.测试过程管理工具 商业性工具：

4、HP ALM，IBM Rational Test Manager和Team Test，Compuware QADirector、Borland SilkCentral Test Manager和Microsoft Visual Studio Team System等开源工具：TestLink、Bugzilla Test Runner、验收测试管理工具FitNesse、基于XML文件测试用例管理工具JtestCas、Eclipse测试和性能工具平台（Test & Performance Tools Platform，TPTP）。除此之外，还有其它一些测试管理框架，如TestMaker、Salom

5、eTMF、JTR （Java Test Runner）、Jetif、Marathon、Grinder、TESTARE等11/492软件缺点描述12/491.软件缺点生命周期软件缺点生命周期指是一个软件缺点被发觉、汇报到这个缺点被修复、验证直至最终关闭完整过程缺点生命周期是各类开发人员一起参加、协同测试过程。软件缺点一旦发觉，便进入严密监控之中，直至软件缺点生命周期终止，这么即可确保在较短时间内高效率地关闭全部缺点，缩短软件测试进程，提升软件质量，同时降低开发、测试和维护成本。 13/491.软件缺点生命周期基本缺点生命周期发觉-打开：测试人员找到软件缺点并将软件缺点提交给开发人员。 打开-修复

6、：开发人员再现、修复缺点，然后提交给测试人员去验证。 修复-关闭：测试人员验证修复过软件，关闭已不存在缺点。 发觉 打开 修复 关闭 14/491.软件缺点生命周期实际缺点生命周期创建激活状态Send email to DEV是否清楚、可再现？已处理状态已修正状态Send email to QA不能再现缺乏信息缺点评审关闭状态延期增强设计无法处理需要处理验证是否经过Unit test, code reviewCheck in CVSNoNoYesYes15/492.严重性和优先级严重性（severity）衡量缺点对客户满意度影响程度致命（fatal）、严重（critical）、普通（major

7、）、微小（minor）优先级(Priority)：指缺点被修复紧急程度。缺点优先级 描述 马上处理(P1级) 缺点造成系统几乎不能使用或测试不能继续，需马上修复 高优先级(P2级） 缺点严重，影响测试，需要优先考虑 正常排队(P3级） 缺点需要正常排队等候修复 低优先级(P4级） 缺点能够在开发人员有时间时候被纠正。 16/493.缺点其它属性缺点标识（ID）缺点类型（type），如功效、UI、性能、文档缺点产生可能性（frequency）/可再现概率缺点起源（source）：需求、设计、编码缺点原因（cause）：数据格式、计算错误、接口参数、变量定义与引用等见 P.327328 诸表17/

8、494.完整缺点信息见 P.328 表15-7ID标题前提环境操作步骤期望结果实际结果频率严重程度优先级类型缺点提交人缺点指定处理人起源产生原因构建包跟踪版本跟踪提交时间修正时间验证时间所属项目/模块产品信息状态18/494.完整缺点信息“步骤”提供了怎样重复当前缺点准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键，视为修复缺点向导 “期望结果”与测试用例标准或设计规格说明书或用户需求等一致，到达软件预期功效。是验证缺点依据。 “实际结果”实际执行测试结果，不一样于期望结果，从而确认缺点存在 19/495.缺点描述基本要求单一准确 能够再现 完整统一短小简练特定条件补充完善 不做评

9、价 20/496.软件缺点汇报 任何一个缺点跟踪系统关键都是“软件缺点汇报”，一份软件缺点汇报详细信息如表：分类 项目 描述 可跟踪信息 缺点ID 唯一、自动产生缺点ID，用于识别、跟踪、查询 软件缺点基本信息 缺点状态 可分为“打开或激活”、“已修正”、“关闭”等 缺点标题 描述缺点最主要信息 缺点严重程度 普通分为“致命”、“严重”、“普通”、“较小”等四种程度 缺点优先级 描述处理缺点紧急程度， 1是优先级最高等级，2是正常，3是优先级最低 缺点产生频率 描述缺点发生可能性1%-100% 缺点提交人 缺点提交人名字（会和邮件地址联络起来），普通就是发觉缺点测试人员或其它人员 缺点提交时间

10、 缺点提交时间 21/496.软件缺点汇报 软件缺点基本信息 缺点所属项目/模块 缺点所属项目和模块，最好能较准确定位至模块 缺点指定处理人 预计修复这个缺点开发人员，在缺点状态下由开发组长指定相关开发人员；也会自动和该开发人员邮件地址联络起来，并自动发出邮件 缺点指定处理时间 开发管理员指定开发人员修改此缺点时间 缺点验证人 验证缺点是否真正被修复测试人员；也会和邮件地址联络起来 缺点验证结果描述 对验证结果描述（经过、不经过） 缺点验证时间 对缺点验证时间 缺点详细描述 步骤 对缺点操作过程，按照步骤，一步一步地描述 期望结果 按照设计规格说明书或用户需求，在上述步骤之后，所期望结果，即正

11、确结果 实际发生结果 程序或系统实际发生结果，即错误结果 测试环境说明测试环境 对测试环境描述，包含操作系统、浏览器、网络带宽、通讯协议等 必要附件 图片、Log文件 对于一些文字极难表示清楚缺点，使用图片等附件是必要；对于软件瓦解现象，需要使用Soft_ICE工具去捕捉日志文件作为附件提供给开发人员。 22/496.软件缺点汇报 示例优异缺点汇报重现步骤 :打开一个编辑文字软件而且创建一个新文档（这个文件能够录入文字）在这个文件里随意录入一两行文字 选中一两行文字，经过选择Font 菜单然后选择Arial字体格式 一两行文字变成了无意义乱字符 期望结果：当用户选择已录入文字并改变文字格式时候

12、，文本应该显示正确文字格式不会出现乱字符显示。实际结果:它是字体格式问题，假如改变文字格式成Arial之前，你保留文件，缺点不会出现。缺点仅仅发生在Windows98而且改变文字格式成其它字体格式，文字是显示正常。 见所附图片 23/496.软件缺点汇报 散漫缺点汇报重现步骤：在Window98上打开一个编辑文字软件而且编辑存在文件 文件字体显示正常 我添加了图片，这些图片显示正常 在此之后，我创建了一个新文档 在这个文档中我随意录入了大量文字 在我录入这些文字之后，选择几行文字.而且经过选择Font 菜单然后选择Arial字体格式改变文字字体。 有三次我重现了这个缺点 我在Solaris操作

13、系统运行这些步骤，没有任何问题。 我在Mac操作系统运行这些步骤，没有任何问题。期望结果：当用户选择已录入文字并改变文字格式时候，文本应该显示正确文字格式不会出现乱字符显示。 实际结果：我试着选择少许不一样字体格式，不过只有Arial字体格式有软件缺点，不论怎样，它可能会出现在我没有测试其它字体格式 24/493软件缺点相关信息25/491.软件缺点图片信息软件缺点相关信息包含软件缺点图片、统计信息和怎样再现和分离软件缺点，使开发人员和其它测试人员更轻易分离和重现它。一些包括用户界面(User Interface)软件缺点可能极难用文字清楚地描述，所以软件测试人员经过附上图片比较直观地表示缺点

14、发生在产品界面什么位置、有什么问题等。 26/492.使用WinDBG统计软件缺点信息WinDbg是微软公布源码级调试工具，用于Kernel模式调试和用户模式调试，可用于调试软件瓦解后形成Dump文件，包含操作系统信息、进程运行状态、时间和环境变量、汇编指令、调用堆栈等安装、使用详细操作方法，如提供了图形界面和命令行两种运行方式调试方式：远程调试、Dump调试、当地进程调试windbg remote npipe:server=SERVER_NAME,pipe=PIPE_NAMEwindbg z DUMP_FILE_NAME Windbg p “process id”惯用命令 P30327/49

15、3.使用Soft-ICE统计软件缺点信息Soft-ICE是 Compuware企业产品NuMega DriverStudio中一个代表性工具，用于跟踪软件运行时变量、内存等状态，而且能够捕捉系统瓦解时状态。使用它能够统计产品发生缺点地方，同时生成日志文件。 28/493.使用Soft-ICE统计软件缺点信息怎样使用Soft-ICE在开始测试之前，已经安装了Soft-ICE并开启了“faults on”命令。当软件发生瓦解现象时，能够使用下面命令去捕捉必要信息：stack u eip-80 假如数据窗口是开启状态，能够输入”wd”来关闭该窗口，然后再输入 “dd esp-20”命令。stack

16、、dd esp-20是为了标注跟踪信息。经过输入x，退出 Soft-ICE窗口；假如还是无法退出Soft-ICE，需要输入faults off，然后输入x。 打开Soft-ICE应用程序，马上保留日志文件。一旦再次打开Soft-ICE，请输入faults on 29/494.分离和再现软件缺点 确保全部步骤都被统计。特定条件和时间。压力和负荷、内存和数据溢出相关边界条件。考虑资源依赖性包含内存、网络和硬件共享相互作用等。 不能忽略硬件。与软件不一样，硬件不按预定方式工作。 和开发人员紧密合作30/494.分离和再现软件缺点 分离和调试软件缺点之间区分 再现软件缺点现象所需最少步骤有哪些？这些步

17、骤成功再现可能性多大？ 软件缺点是否成立存在？换句话说，测试结果是否可能起源于测试原因或者测试人员本身错误，还是影响用户需求、系统真正故障？哪些外部原因产生软件缺点？ 哪些内部原因，是代码、网络、还是环境引发软件缺点？ 怎样才能在不产生新缺点条件下使这个软件缺点得到修复？ 这种修复是否经过调试，单元是否经过测试？ 问题处理了吗？它是否经过了确认和回归测试，确定系统其余部分仍工作正常？ 31/494软件缺点跟踪和分析32/491.软件缺点处理和跟踪 对缺点跟踪管理，普通而言需要到达以下目标：确保每个被发觉缺点都能够被处理，“处理”意思不一定是被修正，也可能是其它处理方式（比如，延迟到下一个版本中

18、修正或者因为技术原因不能被修正），总之，对每个被发觉BUG处理方式必须能够在开发组织中到达一致；搜集缺点数据并依据缺点趋势曲线识别测试处于测试过程中哪个阶段； 决定测试过程是否结束，经过缺点趋势曲线来确定测试过程是否结束是惯用而且较为有效一个方式。搜集缺点数据并在其上进行数据分析，作为组织过程改进财富。 33/492.软件缺点处理技巧 审阅。能够由测试管理员、项目管理员或其它人来进行，审阅缺点汇报质量水平；拒绝。假如审阅者决定需要对一份缺点汇报进行重大修改，应该和测试人员一起讨论，由测试人员纠正缺点汇报，然后再次提交； 完善。完整地描述了问题特征并将其分离，那么审查者就会必定这个汇报； 分配。

19、分配给适当开发人员，假如不知道详细开发人员，应分配给项目开发组长，由开发组长再分配给对应开发人员； 34/492.软件缺点处理技巧 验证。缺点修复需要得到测试人员验证，同时还要进行回归测试，检验这个缺点修复是否会引入新问题； 重新打开。重新打开一个缺点，需要加注释说明、电话沟通等，不然会引发“打开-修复”多个往返，造成测试人员和开发人员无须要矛盾 关闭。只有测试人员相关闭缺点权限，开发人员没有这个权限。 暂缓。假如每个人都同意将确实存在缺点移到以后处理，应该指定下一个版本号或修改日期。一旦新版本开始时，这些暂缓缺点应该重新被打开。35/493.缺点趋势分析软件项目怎样发展：软件缺点打开/关闭图

20、表产品开发质量情况取决于累积打开/关闭曲线趋势。 项目进度取决于累积关闭/打开曲线起点时间差。 开发人员、测试人员工作进度、效率也能得到反应理想趋势图36/493.缺点趋势分析新发觉、修复、关闭累计缺点数理想趋势图37/493.缺点趋势分析微软企业基于缺点趋势图里程碑定义日期1234567891011121314Bug数量汇报Bug处理BugBug收敛点38/493.缺点趋势分析微软企业基于缺点趋势图里程碑定义39/494.缺点分布分析最惯用缺点分析方法：缺点分布汇报，允许将缺点计数作为一个或多个缺点参数函数来显示，生成缺点数量与缺点属性函数。如测试需求和缺点状态、严重性分布情况等。缺点趋势汇报，按各种状态将缺点计数作为时间函数显示。趋势汇报能够是累计，也能够是非累计；缺点年纪汇报，显示缺点处于活动状态时间，展示一个缺点处于某种状态时间长短，从而了解处理这些缺点进度情况。测试结果进度汇报，展示测试过程在被测应用几个版本中执行结果以及测试周期40/494.缺点分布分析软件缺点为何发生：根本原因图表41/495.缺点跟踪方法当前缺点状态 Bug Das