《测试执行与监控.ppt》由会员分享，可在线阅读，更多相关《测试执行与监控.ppt（29页珍藏版）》请在三一文库上搜索。
1、测试执行与监控,课程概览,在本章中，我们将学习： 测试的执行 如何结束测试 测试执行的监控,课程目标,完成此课程之后，学员将具备以下能力： 执行测试用例 理解测试执行的监控过程 掌握结束测试的条件,课程目录,执行测试 监控测试执行 结束测试执行,测试执行,测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程,测试执行的前提,进入系统测试执行的要求： 软件实现基本已经完成 所有需求、设计文档均已批准、定稿 已经通过BVT测试或Smoke测试，检查主要功能是否能测试，表明该软件具备一定的可靠性，可以开始正式的、全面的测试 测试计划、用例设计已完成。测试环境已准备好,测试用例执行过程中的问
2、题,软件是否有缺陷 填写软件缺陷报告 确定造成这些缺陷的原因 需求、设计是否有缺陷 测试环境和测试部件是否有缺陷 测试用例设计是否不合理,测试用例的手动执行,根据测试用例的要求人工的进行软件操作，输入数据，观测输出结果,测试用例的自动执行,使用录制回放工具 使用通用脚本,测试执行过程,根据测试的阶段、任务，选择执行全部或部分测试用例 任务分配：将测试用例分配给测试工程师 执行测试，记录原始数据，报告发现的缺陷 执行某些测试用例时，如果需要先将被测对象置于某个特定的状态，则应保留测试环境、状态,测试执行过程,解决测试中阻碍进度的问题 向管理层报告测试的进度、发现的主要问题等等,测试执行过程,测试
3、用例的状态和生命周期,课程目录,执行测试 结束测试执行 监控测试执行,测试执行的结束,测试执行的结束 测试达到预期目的后，按计划结束 受到时间进度、资源的限制，测试被迫结束 在测试计划中明确说明测试结束的条件 Good-Enough原则 结束条件的判定是在质量和成本之间的折衷,测试执行的结束条件,达到了覆盖率的要求 单元测试：语句覆盖、 集成测试：API、API/参数组合 系统测试：功能、用例、用例场景(scenario) 例如： 100%语句覆盖 90%用例场景覆盖,测试执行的结束条件,指定的时间段内没有发现新的缺陷,测试执行的结束条件,基于成本的考虑 测试执行到一定阶段时，查找未发现的缺陷
4、的成本逐渐增大，如果超过了由潜在缺陷所引起的代价，则可以停止测试 不适用于要求高可靠性的软件：武器、医学设备、,测试执行的结束条件,项目组达成一致 基于技术、资金、开销等各种因素，项目组（包括管理层、开发、测试、市场销售）意见一致，认为可以停止测试,测试执行的结束条件,因时间进度、资源的限制必须结束 一般是为了按计划尽快发布软件，抢占市场 可能存在潜在的严重缺陷 已知的缺陷可能还未修改,课程目录,执行测试 结束测试执行 监控测试执行,测试执行的监控,测试监控的任务和目的,记录和管理测试用例的执行状态 根据当前的执行状态，判定测试用例的设计质量和效率 使用脚本进行自动测试 根据发现的缺陷分布，判
5、定结束测试的条件是否成熟,测试监控的任务和目的,评估测软件的质量 缺陷的数量、种类、 评估开发过程的质量 缺陷的分布、修复缺陷的时间、回归测试时发现的缺陷数量、 评估测试工程师的表现 是否按计划完成任务 发现缺陷的数量,测试监控的内容,测试用例执行的进度 = 已执行的数目/总数目 此数据只表明执行进度，不表示测试的成功率 为了得到更精确的进度数据，可计算测试步骤数,测试监控的内容,缺陷的存活时间 =缺陷从open到closed的时间 表明修改缺陷的效率,测试监控的内容,缺陷的趋势分析 - 按照测试执行的时间顺序(以月、周、天为时间单位)，被发现的缺陷数量的分布 如果越来越少，趋近于0，则考虑结
6、束测试执行 相反，则说明存在以下的问题： 代码修改引发新的缺陷 前一版本的测试存在覆盖率的问题，新的测试发现了原先未发现的缺陷 必须先修改某些缺陷后才能继续测试，然后才发现其他的缺陷,测试监控的内容,缺陷分布密度 =对应于一项需求的总缺陷数/对应于该项需求的测使用例总数 需要考虑缺陷的优先级和严重程度 如果过多的缺陷集中在某项需求上，可能表明以下问题： 该项功能需求是否过于复杂？ 该项的需求设计、实现是否有问题？ 分配给该项的开发资源是否不足？ ,测试监控的内容,缺陷修改质量 = 每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷） 评价开发部门修复缺陷的质量 如果修改某项功能后，此数值较高，测试部门应当及时通知开发部门,改进测试执行过程,基于质量风险分析，先测试最容易出现缺陷、对软件影响最大的部分 正确分析测试结果 ,