软件测试 郑人杰 许静 于波 第7章测试组织和管理新.pptVIP

第7章 测试组织和管理 将测试作为项目来管理 在规定的时间内，利用有限的资源，完成特定的目标。 Find bugs as many and early as possible Push to get bugs fixed as many and early as possible 主要内容 项目管理 测试用例管理 缺陷管理 1.项目管理 过程：进度安排 人员：资源、责任 产品：达到的目标 测试的生命周期 测试活动的信息流 测试阶段的信息流 测试阶段的输入信息有两类： 软件配置：这是测试的对象，包括需求说明书设计说明书被测的源程序等。 测试配置：包括测试计划测试步骤测试用例（测试数据）具体实施测试的测试程序测试工具等 静态测试手段：评审 需求文档的评审 设计文档的评审 测试文档的评审 规范评审过程 量化指标 改正一个错误的相对成本 动态测试的管理 测试计划编写 Test Plan 测试用例设计 Test Case Design 测试结果评估 Test Evaluation 编写测试计划Writing a Test Plan 测试应具备的条件 需求说明书 设计说明书 运行环境及配置说明 遵循的相关标准 需要的相关工具 预算、人员、时间要求 测试阶段与测试方法 2.测试用例管理 什么是测试用例 测试用例（Test Case）通常是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例设计 测试用例设计应包括： 1.基本事件：参照规格说明书，按照需要实现的所有功能编写，覆盖率100%。 2.备选事件：设计过程中的备选情况，按照功能点编写。 3.异常事件：出错处理的路径，按照功能点编写。 在实际中，备选事件和异常事件的测试用例往往比基本事件的测试用例要多。 设计原则 （1）在任何情况下都必须使用边界值分析方法，经验表明，用这种方法设计出的测试用例，发现程序错误的能力最强。 （2）必要时，用等价类划分方法补充一些测试用例，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。 （3）用错误推测法再追加一些测试用例，这需要依靠测试工程师的智慧和经验。 （4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 （5）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。 （6）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。 （7）利用功能图法，我们可以通过不同时期条件的有效性，设计不同的测试数据。 （8）对于业务流清晰的系统，可以利用场景法贯穿整个测试用例设计过程，在用例中综合使用各种测试方法。 测试用例的评审 是否覆盖测试需求上的所有功能点？ 用例编号是否和需求对应？ 非功能测试需求或不可测试需求是否在用例中列出并说明？ 用例设计是否包含了正面、反面的用例？ 每个测试用例是否清楚填写了测试特性、步骤、预期结果？ 步骤/输入数据部分是否清晰，是否具备可操作性？ 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？ 优先级安排是否合理？ 是否已经删除了冗余的用例？ 是否简洁，复用性强？例如，可将重复度高的步骤或过程抽取出来，定义为一些可复用标准步骤。 测试用例的优化 利用设计测试用例的八种方法不断地对测试用例进行分解与合并； 采用遗传算法理论进化测试用例； 在测试时利用发散思维构造测试用例。 测试用例的更新 测试用例在形成文档后也还需要不断完善。主要起因于三个方面： 第一、在测试过程中发现设计测试用例时考虑不周，需要完善； 第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成的； 第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。 测试用例的作用 错误跟踪 更准确地反映软件的某一特性 全面地反映软件的性能和质量 明确故障责任 “Good” Test Cases 目标明确 易于理解 用最简单的步骤揭示错误 具有典型性 不过于简单，也不过于复杂 准确“抓住” Bug 测试用例执行 （1）测试开始标准 测试计划评审通过； 测试用例已编写完成，并已通过评审； 测试环境已搭建完毕。 （2）测试停止标准 满足以下条件，测试可以正常停止。 缺陷状态为“关闭”（Closed）或“推迟”（Later）状态； 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到规定的标准； 缺陷密度（n个/KLOC）需