软件单元测试培训(二)分析报告.ppt

确定待测特性 研究待测特性要从研究单元的需求开始 功能需求、非功能需求（如性能或设计约束等）、与待测单元相关的任何使用或操作过程 单元的状态识别 针对状态机测试 单元的数据特性识别 单元的输入输出数据分析 以上研究分析对于制定单元测试方案和指导测试用例的设计很重要 待测特性分析过程中还有可能发现单元需求上的缺陷。 制定单元测试规程 输入 单元测试计划、待测特性分析结果、项目总体进度计划 识别可重用技术（待查） 通过待测特性分析，可从用例库中识别出可以重用的测试用例和测试规程，以减少重复工作。 资源 详细列举单元测试所需资源，包括人员、设备、工具、环境等， 进度计划 详细的进度计划，包括风险分析和应对措施 规程评审 设计测试套件 测试套件 测试用例、脚本、驱动、桩、测试数据 测试规程和测试用例的开发 目前测试规程和测试用例是合一的。开发过程中在重用的基础上新增和修改。结合待测单元特性分析，充分考虑测试用例的覆盖率。 ?测试工具的设计 自研测试工具的设计要充分考虑可重用性，不同项目间通用性一般较小，统一项目不同版本间一定要具备通用性。 测试规程/用例的评审 单元测试数据 单元测试设计中，测试数据的设计是很关键的，同样的测试规程，不 同的测试数据，可能会达到不同的测试结果。 a) 正常数据：在测试中所用的正常数据的量是最大的，而且也是最关 键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一 些具有高度代表性的数据作为测试数据，以减少测试时间。 b) 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。 它可以针对某一种编程语言、编程环境或特定的数据库而专门设 定。边缘数据要靠测试人员的丰富经验来制定。 c) 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数 据从而检测输入筛选、错误处理等程序的分支。 构建测试套件 测试数据的准备 测试工具的开发/调试 构建测试环境 执行测试套件 运行测试 确定测试结果，处理测试过程中的异常 对每个测试用例，确定单元是否通过测试。对异常进行分析，并根据情况处理： 情况1：测试用例或测试数据的问题。修正并重新运行。 情况2：测试规程执行的问题。重新运行。 情况3：测试环境的问题。纠正测试环境并重新运行；或者异常终止测试，并汇报记录异常终止原因。 情况4：单元实现中的故障。纠正单元的故障，并运行所有的测试；或者异常终止测试，并汇报记录异常终止原因。 情况5：单元设计中的故障。纠正单元设计和实现中的故障，必要时修改测试设计和测试数据，并重新运行所有的测试。 检查终止条件 测试充分性检查 检查是否达到覆盖率要求，包括测试用例执行/通过覆盖率和被测单元代码/分支覆盖率。以及其它测试充分性要求。 异常终止条件检查 补充测试套件 以上条件不满足时，则需要补充测试套件，继续进行测试。 评估测试结果 按照单元测试报告模块出具单元测试报告 如有必要对单元测试报告进行评审 将所有测试相关工作产品纳入配置管理 主题内容 1.为什么做单元测试 2.单元测试的概念和内容 3.单元测试的方法、技术与工具 4.如何做单元测试 5.单元测试的难点和对策 参见的单元测试的难点 没有时间做单元测试 单元测试责任人不清楚 测试代码难以管理 覆盖率难以手工统计 故障报告形式 驱动和桩编写困难（可测试性） 对策：没有时间做单元测试 单元测试计划在项目计划应该有体现。 编写代码之前或同时，先设计测试用例。每个软件单元应该有什么功能？是否每个功能都有测试用例来验证它？ 对策：单元测试责任人不清楚 ?? 强调单元测试必须由类包的设计者负责编写，因为只有这样，测试才能保证对象的运行时态行为符合需求。 ?? 让测试人员或第三方人员编写测试用例，将花费更多的工作量。（20 1） ?? 执行测试用例可以让测试人员或自动构造系统。 对策：测试代码难以管理 ?? 采用测试工具管理测试代码 如XUnit、C++Test、RTRT ?? 配置管理中建立配置项 如，不同模块的一组代码，建立相应测试代码目录和配置 项 对策：覆盖率难以手工统计 利用各种工具 PureCoverage (C/C++/Java/.Net,Windows/UNIX) RTRT(C/C++/Java/Ada,嵌入式系统) C++Test(C/C++,Windows/UNIX) Discover(Delphi,Windows) 对策：故障报告形式 各种工具一般都会生成测试报告 XUnit 测试用例执行报告 RTRT、C++Test各种综合报告（测试用例执行结果、测 试用例覆盖率、内存检查和性能） 对策：驱动和桩编写困难（可测试性差） ?? 通常情形下，测试驱动难以编写，测试难以进行由以下几方面原因导致： 1、被测试对象需要传入