软件单元测试计划-模板

XXXXXXXXXXXX 软件单元测试计划软件单元测试计划 SRIJS-T0-/V0.0SRIJS-T0-/V0.0 XXXXXXXX 年年 XXXX 月月 1 XXXXXX 软件单元测试计划 作者 审核 批准 姓名签名日期 序 号 修订 日期 修订前 版本号 修订 后 版本 号 修订 人 修订内容简述 2 XXXXXX 软件单元测试计划 目目 录录 1.介绍 4 1.1 目的 . 4 1.2 定义和缩写 4 1.3 参考资料 4 2.测试内容 4 3.单元测试策略 4 3.1 测试方法 4 3.2 测试工具 5 3.3 测试模块 5 4.测试活动计划进度 6 5.准入/准出原则 6 6.测试用例 6 7.输出文档 6 附录 7 缺陷状态定义 . 7 缺陷严重程度定义 7 3 XXXXXX 软件单元测试计划 XXXXXXXXXXXX 软件单元测试计划软件单元测试计划 1. 介绍 1.1目的 请在这里描述编制本文档的目的，并指明读者对象。 1.2定义和缩写 缩写缩写 CW BA 定义定义 代码走读 边界值分析法 1.3参考资料 序号序号文件名称文件名称文件编号文件编号版本号版本号 2. 测试内容 请描述本次单元测试的内容。 如 本次单元测试是为了验证新增加或修改的模块是否满足 SIL2 级编码规范、逻辑是否正确，从 而进行静态分析和动态分析。 3. 单元测试策略 3.1测试方法 单元测试策略将采用静态分析、动态分析两种测试方法，具体应用如下 静态分析是指不实际运行被测软件，而借助测试工具或人工检查的方式查找 被测软件中可能存在错误的一种测试方法。该方法应用于关键模块，采用静态分析中 的代码走读技术，所关注的 C 软件代码走读规则详见 C 语言编程规则 ，所关注的 FPGA 软件代码走读规则详见 FPGA 语言编程规则 。 4 XXXXXX 软件单元测试计划 动态分析是指实际运行被测软件，输入相应的测试数据，检查实际输出结果 和预期结果是否相符的过程。详细的动态测试方法如下表所示 测测 试试 方方 法简称法简称 EP BA 等价类划分法 边界值分析法 CENELEC EN 50128 B19 CENELEC EN 50128 B4 测试方法描述测试方法描述参考文件参考文件 3.2测试工具 工具名称工具名称 Testbed TBvision TBsecureTBMISRA Tbrun Tbsafe 人工检查 版本版本 9.4.0 9.4.0 9.4.0 9.4.0 9.4.0 N/A 生产厂商生产厂商说明说明 LDRA LDRA LDRA LDRA LDRA N/A 基本静态分析与动态覆盖率分析 静态软件分析 编码规则检查 动态分析与测试 软件覆盖率分析 主要应用于静态分析中 FPGA 的编码规则检查 3.3测试模块 模块名称模块名称 MVB 初始化 mue_acc_i nit mue_acc_ clean_up mvb1_stop _comm mvb1_clea n_pd_port MVB1_Co nfig mvb1_star t_comm 开始 MVB 通信CW 配置 MVB 端口CW 清除 MVB 端口CW 停止 MVB 通信CW 清除 MVB_UARTCW 源文件源文件 User_mvb1.c 函数名称函数名称 参数 初始化 MVB_UARTCW 描述描述推荐使用的测试方法推荐使用的测试方法 CWEP/BAMVB1_InitMVB1_Init外部 MVB 总线初始化相关 5 XXXXXX 软件单元测试计划 4. 测试活动计划进度 测试活动测试活动 编制软件单元测试计划 设计软件单元测试用例 审核软件单元测试计划 执行软件单元测试用例 确认软件单元测试报告 测试时间测试时间测试人员测试人员 5. 准入/准出原则 准入原则 准出原则如下表。 序号序号 1 2 准则准则 需求覆盖率 缺陷遗留 出口标准出口标准 80以上的测试用例被执行 严重度严重度 1-致命缺陷 2-严重缺陷 3-一般缺陷 4-细微缺陷 遗留数量遗留数量 0 0 0 20 说明说明 6. 测试用例 请列出此次测试使用的测试用例。 （这里可以列出全部测试用例，也可将测试用例作为独立文档编制） 7. 输出文档 软件单元测试计划 软件单元测试报告 软件单元测试缺陷报告 6 XXXXXX 软件单元测试计划 附录 缺陷状态定义 缺陷状态缺陷状态描述描述 关闭 拒绝 延迟 缺陷确认者（一般为问题生成人）验证后认为问题已解决 属实 被拒绝的缺陷经缺陷确认者确认，确实不需要修复或不是 缺陷 问题的分析者认为是缺陷，但是不影响业务办理的进行延 迟处理。 缺陷严重程度定义 严重等级严重等级描述描述 致命缺陷对进度的影响可能是非常致命的，或者可能是一个停 止器即终止用户继续使用系统；或者影响测试工作继 续进行的缺陷。 系统基本能正常工作但同一错误现象频繁出现或者问题不 解决时会给后续工作带来较大风险（如需求描述不正确导 致系统设计错误） 。 不属于“严重”、“较严重”、“微小”之外的缺陷。 不影响系统功能，但影响系统的易用性（如界面美观问题、 操作建议等）或产出物的一些非技术性质量问题（如文档 版本、错别字等） 。 严重 一般 微小 7