软件测试课件9

1、软件工程学科研究生课程 软件质量保证与测试1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)测试计划的结构和目标1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Te

2、st Milestone)总结被测试的系统特征1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)由于各种原因，测试计划中没有进行设计的测试用例部分1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)识别出测试分类1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略

3、8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)基于测试方法部分识别出的测试分类，在测试套件结构中列出详细测试组和下属组1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)计划并设计测试环境（也测试平台或测试实验室）1.导言2.特征描述3.假设前提4.测试方法5.测试套件(Test Suites)结构6.测试环境7.测试执行策略8.测试工作量估计9.安排进度和测试里程碑(Test Milestone)有用而高效的执行策略必须考虑测试执

4、行、缺陷检查和缺陷修复该策略清晰地定义了开始系统测试的进入条件如何安排测试用例执行的先后次序何时从一个测试周期过渡到下一个何时重新执行失败的测试用例何时暂停一个测试周期和启动原因分析如何为回归测试的最终测试周期选择测试用例的子集测试周期由6个参数表示目标：假设测试执行（测试优先级排序）重做和延长标准行动退出条件（周期的结束）涉及5个功能交叉组：营销硬件软件技术发布和系统测试每个组有一到多个条件项，当所有条件项都满足是，系统测试才开始应用回归测试的概念基于以下几点选择：测试用例之前的执行结果测试用例的成员属性：基本要素、功能性、健壮性、互操作性、可扩展性、性能、负载、稳定性测试用例与已经修改的软

5、件组件的关联性第一个测试周期原理：允许最大数量的测试用例完全执行而不被阻塞第二个测试周期原理：前一次测试中失败的测试用例在本次测试周期中要尽早执行第三个测试周期原理：与第二个测试周期相似测试工作量一人一天创建的测试用例数量一人一天执行的测试用例数量测试用例数量估计基于测试组类别的估计基于功能点的估计通过分析需求文档来估算资源，这种方法学最早由A.J. Albrecht提出一个系统的功能点由软件生成的输入、输出、主文件、查询这些数量的加权总和UFP= WFNIxNI + WFNOxNO + WFNQxNQ + WFNLxNL + WFNExNEUFP：未经调整功能点数NI ：外部输入类型数NO：

6、外部输出类型数NQ：外部查询类型数NF：内部逻辑文件类型数NE：外部接口文件类型数WF ： 加权因子经验公式来计算一个系统的功能点FP FP = UFP x (0.65 + 0.01 x PCA)PCA：复杂度调整因子，由14种会影响一个项目的必需开发工作量的因子的评级总和构成，每种因子会指定一个0 5之间的评级因此， FP的值通过PCA在正负35%的范围内波动测试用例数量通过下面两种方式估计间接方式Caper Jones给出了一个功能点和软件代码行数LOC间的关系Hitachi Software经过30年的研究结果，给出了没10 15行代码需要一个测试用例这样一个标准直接方式Caper Jo

7、nes给出了如下关系：测试用例数量总和 = (FP) 1.2为测试项目制定日程表和里程碑的重要性测试项目管理面临的问题：时间vs质量测试工作量的估计和时间安排要反复进行以确保它们是可靠的用甘特（Gantt）图来表示项目的时间表，包括各个任务的持续时间、任务依赖关系和他们的顺序例如: 常见的项目管理工具MS Project等自动化测试的优点：提高测试工程师的生产力回归测试的覆盖测试用例的可重用性一致性测试减少测试间隔降低软件维护成本提高测试效率评估自动化测试准备就绪的先决条件：系统稳定，功能定义良好需要自动化执行的测试用例定义良好测试工具和基础设施已到位测试人员已具有自动化测试的成功经验分配了充

8、足的预算用于采购软件工具好的自动化测试利用计算机的能力利用计算机的能力去执行人力无法有效执行的测试 软件发布前或维护时，可能需要执行上百次、上千次、甚至百万次的测试自动化测试不是测试工程师的替代品不是测试工程师的替代品 能思考的人执行测试的作用远远超过机器有效地利用，自动化测试会节省大量的时间和开支选取windows自带软件或web站点为例组织学生讨论 为确保软件质量需要进行哪些测试？ 哪些测试可以交由工具完成？ 哪些测试必须由工具完成？需要适用机器和软件工具机器和软件工具 用软件把已存在的手工测试过程自动化模拟人工操作 设置测试环境 控制测试的执行过程完成对被测试软件的输入 自动执行对输出结

9、果结果进行检验检验 比较实际结果和预期结果记录测试结果测试结果 生成测试结果报告阶段一：手工测试阶段二：硬编码测试自动化阶段三：测试库和框架阶段四：数据驱动测试阶段五：基于模型的测试手工测试的原因 有一些测试很难自动化 有些测试只需测试一次或有限次 产品功能变更频繁 调整自动测试耗费大量成本手工测试可以是 仔细计划的：系统性的、覆盖关键场景 随机的：尝试不同的变量，测试未被计划的场景不可轻视手工测试 容易进行，在特定情况下有效且高效手工测试的局限 只可能用于端到端的测试，不能用于不能用于APIAPI测试测试 本质上不可重复 如果要重复执行，代价较大， 如果发生人事变动，还要重新培训比如 记录和

10、回放用户界面测试 直接使用目标API取样测试优点 容易并且快速自动化局限性 脆弱：只在有限几种环境下可以工作，极小的变更都会导极小的变更都会导致无法工作致无法工作 维护：产品做了极小变更都会导致对自动化脚本的极大变更适用的场景 测试自动化概念验证 用于测试那种一旦完成就不轻易改变的功能测试那种一旦完成就不轻易改变的功能建构一个测试库/测试框架（Test Harness） 常见任务使用库优势 更多的代码共享和重用 更强健的测试代码 更低的维护和改进成本 编写额外测试代码更快 更适应变化基于不同类型的数据输入，编写一次测试代码，就可以覆盖不同的测试场景 容易增加新的测试用例而不用编写新代码 绝大部

11、分或者全部测试用例及其衍生场景，都可以使用数据来描述（例如，参数、文件、数据库） 更大的适应性和扩展性、更低的维护成本 局限 需要花时间来理解测试代码部署配置系统的自动化工具针对某个场景的自动化工具简单多次重复的测试手工测试无法实现的场景（API测试）高频率执行的回归测试需要精确数据的测试测试开发标准测试维护标准测试执行标准测试结果标准测试管理标准GUI测试能力标准供应商资格标准定价标准波动小：测试用例稳定了重复性：如回归测试高风险易于实现自动化手工难以执行繁琐耗时很多非功能测试都适合自动化 API自动化测试 性能测试 负载测试 压力测试 安全性测试 国际化/本地化测试用于度量软件系统对用户各

12、种操作的响应时间 度量产品在受限环境下的性能常见任务 定义性能目标、建立性能基准，不断进行系统调优 验证稳定性和可靠性，预知高并发下系统运行情况 决定硬件和软件采购计划模拟许多用户同时访问一台服务器的情况负载测试可用于 冒烟测试：确定在短时间内负载较小时应用程序如何执行 压力测试：确定在较长时间内负载较大时应用程序是否能成功运行 容量测试：确定在各种容量下应用程序如何执行压力测试是性能测试的一种专门形式 目的是使应用程序产生故障 通过增加处理负载使其性能降低 直到由于资源饱和或发生错误而使应用程序开始出问题压力测试在强负载（大数据量、大量并发用户等）下的测试，查看应用系统的某项功能隐患、系统是

13、否具有良好的容错能力和可恢复性能力 并发性能 疲劳强度 大数据量关键业务应用必须应用此测试关键业务应用必须应用此测试查找应用程序或系统的潜在软肋 避免被利用来对系统进行攻击作用 提升客户满意度 降低安全风险微软安全性测试的经验总结 不要使用“系统管理员”权限来运行测试 在一个安全的文件系统上进行测试 不修改任何在注册表HKLM下的条目和%programfiles%目录下的文件 不使用明文存储或发送机密信息微软安全性测试的经验总结 使用坏数据来挑战应用极限 在有2个或者2个以上处理器的计算机上进行测试 尽可能利用工具 多分析源代码威胁建模（Threat modeling） Review（微软的一

14、个威胁模型工具） SDL Threat Modeling Tool静态分析（Static analysis） prefix,prefast,fxcop,BadApi运行时分析（动态分析，Runtime analysis） AppVerifier攻击表面分析（Attack surface analysis） XRAY渗透性攻击（Penetration） fuzzing, elevation of privileges国际化模型 i18N internationalization model比如 在windows系统通过修改“区域设置”中的默认习俗设置来达成包括修改 数字格式、货币格式 时间格式、

15、日期格式 日历格式、字符集1.决定使用自动化测试2.取得测试工具3.测试计划、设计与开发 计划、feature、测试用例、测试工具、应用framework或自己写工具4. 执行并管理测试 执行、调用目标应用程序执行预定义操作 取得结果（截屏、取控件值） 比照结果 结论与报告 跟踪Bug&新build流程 测试状态跟踪5. 测试活动的审查和评估简单化：测试用例应有一个单一的目标，测试步骤不超过10-15（不包括设置和清除步骤）模块化健壮性和可靠性可重复使用：避免硬编码可维护有记录独立自足：数据值独立失败独立最终状态独立1)简单的自动化测试只需要启动一个程序或一段脚本2)大型的自动化测试则

16、依赖复杂的构造框架（framework）确保一轮测试（test pass）产生格式一致、通用的测试报告3) 构造完好的自动化测试系统应该使得完成整个测试套件的执行就像是按一下按钮 Test Harness + Automation Framework + Set of Tools = Infrastructure (基础设施 ) 测试用例例 Test Cases自动化框架 Automation Framework测试框架/工具 Test Harness /Tools1) 用于测试软件的自动化工具 包含软件和测试数据（数据经过配置） 测试一个程序单元 控制测试在不同的条件下运行 监控行为和输出

17、2) 一般特点 结构化 自我文档化 自动并可重复执行 基于已知数据 被设计为可测试正常和异常的行为 尤其适合于在不同机器上进行测试的实现 3) 一般结构：测试执行引擎+测试脚本储存库 Test Harness 的目标 测试过程自动化。 执行测试用例。 生成相关的测试报告. Test Harness的组成部分 TCM (Test Case management)测试用例管理 测试代码框架 UI库 测试代码结构 报告系统 测试用例执行引擎 自动化测试设计-测试框架的典型执行过程 自动执行测试用例（测试用例）保存数据 确定附加的数据传递正常 顺序执行 随机执行 指定顺序（取决于Test Harnes

18、s或者数据 包括测试状态 到文件、调试器或其他位置自动化测试设计-自动化框架1）测试脚本的基础代码（Libraries）2）测试的规范3）测试惯例的集合自动化框架的实例1）UI Libraries -Windows UI Library -Web UI Library2）日志（Logging）3）错误处理自动化框架-日志目标（Logging）1）测试日志应该易于诊断 -在不需要使用或参考debugger、产品源代码、测试源代码 -这并不代表产品或测试的源代码不能在问题解决前被引用 -仅从执行情况的记录中，测试员应该有能力判定并区分错误的原因 -为区分一个错误异常，测试和产品代码必须了解的信息都应该在log内出现2）测试日志