测试培训交流.ppt

测试活动-测试需求分析与测试计划 目的：明确测试类型，各类型的测试内容，相关的标准和规范，是测试设计和执行的基础。 主要活动： 根据合同或者方案建议书，确定测试类型 对于每种测试类型，细化测试内容、测试环境、测试标准 输入：合同、系统介绍、需求、设计、用户手册等系统有关文档 输出：测试需求、测试计划 测试活动-测试设计 目的：根据测试需求，完成测试用例、测试实施方案的详细设计 主要活动： 对于每种测试类型的测试需求，进行测试设计 输入：测试需求、系统有关文档 输出：测试用例或测试方案 测试活动-测试执行 目的：根据测试设计，完成测试的实施 主要活动： 搭建测试环境 实施测试 记录测试结果（BUG，性能测试数据等） 讨论和确认测试发现的问题 输入：测试用例或测试方案、系统有关文档 输出：测试缺陷记录、测试用例执行情况 测试活动-回归测试 目的：根据测试发现问题的修改情况和影响情况，对修改后的系统进行复测 主要活动： 分析测试范围和系统修改情况 修改测试设计 搭建测试环境 实施回归测试 记录测试结果（BUG，性能测试数据等） 讨论和确认回归测试的问题 输入：测试发现问题的修改及其影响说明、回归测试的范围 输出：回归测试问题记录、测试用例执行情况 测试活动-测试总结 目的：对测试的结果进行总结，对系统的质量情况进行评价 主要活动： 对各种类型的测试进行总结 对整体测试情况进行综合，分析统计测试结果，产生测试报告 输入：测试缺陷记录、测试用例执行情况 输出：测试报告 测试方法-黑盒与白盒 白盒测试 了解被测对象的内部结构和动作原理 检测软件内部动作是否按照编码规格的规定正常进行，而不考虑需求和功能 黑盒测试 被测对象的内部结构、动作情况对测试人员是不可见的。 不考虑内部逻辑结构，与具体的实现无关。 测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性 测试用例 用例编号 用例标题 用例目的 预置条件 优先级 操作步骤 输入时间 期望结果 用例编写者 好的测试用例的特点 好的用例设计能够很快地定位问题。 好的用例设计能够发现许多隐藏的bug。 好的用例设计能够在测试初期发现许多致命性及严重性问题。 好的用例设计能够重复几轮使用，可重复利用率高。 好的用例设计在需求稳定的情况下，不需要在以后的几轮测试活动中进行修改和变动。 好的用例设计能够尽可能多地覆盖功能点的分支。 好的用例设计是有用的，而不是冗余的。 好的用例设计应该是本类用例中最佳的选择。 好的用例设计即不过于复杂，又不过于简单。 好的用例设计应该是利用率高，方便以后的重复使用及其它人员的使用，即使当产品的测试人员发生变动时，新的测试人员只要拿到设计的用例，能够明白用例设计的意图，并很快地投入到测试活动过程中。 缺陷管理-缺陷优先级 高优先级 中优先级 低优先级 缺陷管理-缺陷描述 缺陷ID 摘要 描述 状态 级别 优先级 可否复现 提交人 提交日期 指派给/责任人 修复日期 回复内容 写出高效的Bug的9点建议 清晰地描述Bug 不要放过你判断 重现的步骤 使用简洁的语言 引用相关的例子 提供参考信息 为Bug分配优先级和严重等级 通过抓屏截图来解释 时刻准备着向开发人员展示你发现的Bug 测试报告 测试执行情况 测试统计与度量 覆盖率 需求覆盖率 用例覆盖率 缺陷统计 按缺陷级别分布 按功能模块分布 缺陷密度 缺陷修复率 缺陷变化趋势图 缺陷驻留周期 * * 个人总结 * * * * 一般性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据。 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题 压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力 并发用户数：网络的角度，单位时间内网络上的流量，对于web系统，可以看作请求数/s 响应时间：客户端的响应时间实际可分解为客户端呈现的响应时间＋系统处理的时间 吞吐量/处理能力：单位时间内系统处理的客户请求的数量(对于非交互式系统更多考查的内容) 资源占用率：网络的角度，单位时间内网络上的流量，对于web系统，可以看作请求数/s * 系统级的可恢复性测试：看系统在异常情况下的恢复能力。 不仅仅是数据库恢复测试，还有恢复后，系统其他方面与数据库的一致性检查（如：国库系统恢复测试中发现，数据库恢复后，库中只包含有8月12日前的数据，但是系统当前录入日期却是当前