01、单元测试计划模板.docVIP

单元测试计划 （Unit Test Plan） 1 引言 1.1 目的 本文档为XX系统以下模块的单元测试活动提供范围、方法、资源和进度方面的指导：XX模块。 本文档的读者主要是开发经理和开发人员。 1.2测试策略 以类为单元，采用独立的单元测试策略，通过设计相应的驱动和桩的方法来测试类中的方法。在选择类中被测方法时，根据方法的规模和复杂度进行判定。非空非注释代码行数LOC20，或者复杂度VG3的方法进行单元测试，其他方法不进行单元测试。 对于子类的测试采用分层增量测试（Hierarchical Incremental Testing）策略，对子类的变化部分设计新的测试用例，与父类相同的部分则重用父类的测试用例。 执行单元测试的次序是根据《软件设计说明》中的用例实现交互图，从图中最小依赖关系的类开始测试，再逐步扩大到依赖关系较强的类，直至所有类测试完毕。 1.3范围 单元测试包含了计划阶段、设计阶段、实现阶段和执行阶段四个阶段。本单元测试计划是整个软件开发项目中的一部分，起始于详细设计阶段，直到单元测试阶段结束后终止。该计划主要处理与MiniLibrary系统单元测试有关的任务安排、资源需求、人力需求、风险管理、进度安排等内容。 1.4参考文献 《软件需求规格说明（Software Requirement Specification）》 《软件设计说明（Software Design Descriptions）》 《用户界面规格说明（User Interface Specification）》 1.5术语 无。 2 测试项目 根据《软件设计说明》中的详细设计内容，单元测试的测试项目如2.1-2.8小节所示。 2.1 XX模块 1 设计类标识:XX设计类 方法标识符 方法名 代码行（LOC） 复杂度（VG） ... 2.2 XX模块 3 被测函数 根据测试策略中制定的被测方法选取标准，被测函数如表1所示。 表1 被测函数 方法标识符 方法名 代码行（LOC） 复杂度（VG） ... ... 4 不被测函数 对不满足测试策略中被测方法选取标准的方法将不进行单元测试，但这些方法必须经过严格代码检视，以保证不会出现一些低级性的错误，并且在集成测试阶段统一验证其接口功能的正确性。不被测函数如表2所示。 表2 不被测函数 方法标识符 方法名 代码行（LOC） 复杂度（VG） ... ... 5 测试方法 根据类规约和操作规约构建测试用例，利用传统等价类划分法、边界值分析法、判定表法等黑盒测试技术对边界值、正常值、错误值等情况进行全面测试，以覆盖所有前置条件和后置条件组合。 对具有特殊需求的类辅以以下两种方法设计测试用例： （1）根据状态转换图构建测试用例。该方法根据被测试的类的对象所处的状态以及状态之间的转移来构造测试用例，对状态之间和状态内部的每一转换及其可能发生的异常转换、转换的监护条件等进行全面测试。 （2）基于实现构建测试用例。该方法利用传统逻辑覆盖法、数据流分析法等白盒测试技术对程序的逻辑结构或数据流进行测试，以达到一定的代码覆盖率。 更详细的测试策略描述参考《单元测试说明》。 6 测试通过/失败标准 测试通过的标准表述如下： 所有单元测试的用例都被执行并通过； 所有发现的缺陷都被修正并回归测试过； 所有被测对象的前置条件和后置条件组合覆盖率达到100%，或能明确给出不需要达到的理由； 单元测试报告被权签人批准。 测试失败标准表述如下： 严重缺陷密度大于15个/kLOC； 发现软件结构有重大设计问题，其修改会导致20%以上的接口、功能、数量的变化，进一步测试相关特性已经无意义； 发现关键功能未被设计，该功能的设计会导致20%以上的接口、功能、数量的变化，进一步测试相关特性已经无意义； 测试结果审批过程： 开发人员提交单元测试报告→开发经理签字并提交SQA→SQA对报告进行评审并签字（测试经理参与）→产品经理签字。 7 测试挂起/恢复的条件 测试挂起的条件有： 当某个类在单元测试执行过程中发现有阻塞用例的时候，该类的单元测试被挂起。 当有20%以上的被测类都遇到有阻塞用例的时候，所有类的单元测试被挂起。 当出现有新增需求的时候，与该需求相关的所有类的单元测试被挂起。 当开发人员提出要进行设计变更的时候，相关类的单元测试将被挂起。 测试恢复的条件有： 测试被挂起的条件已经被解决。 需要恢复测试的对象达到单元测试入口条件，在这里要求这些被测对象已经通过代码走读（要提交走读报告）和语法检查（要提交检查结果）。 8 单元测试交付物 单元测试计划（Unit Test Plan）； 单元测试设计规