单元测试案例 &单元测试报告

良好的测试习惯是提升开发质量的重要步骤之一，软件的测试过程主要分为 3 大部分：单元测试（开发主导）、SIT 技术测试（第三方测试团队主导）及 UAT 联调测试（业务人员及上下游系统主导）。假如软件属于首次上线或重大版本上线，还会涉及压力测试、冒烟测试、回归测试等性能测试。在这里主要分享的是由开发人员主导的单元测试。

单元测试的重点是针对需求描述的功能点进行内部测试，至少保证开发内容是符合需求要求及没有明显的缺陷。在单元测试前必须要先编写测试案例，并与需求分析人员进行交叉检查，保证单元测试范围能覆盖需求所要求的内容。

单元测试案例的模板包含以下内容：

1）编号/ID：登记测试案例的唯一标识，一般使用自然数序列或按开发规范要求命名，主要用于沟通或引用。

2）案例描述：简述测试案例的内容，比如“验证批量导出功能是否能导出全表数据”。这里要注意的是测试案例内容而非测试案例的操作步骤，操作步骤会单独说明。

3）测试步骤：清晰列出该案例的操作步骤，并按序号列出来。比如上述的测试案例，可以写为：

a.使用 XX 用户登录系统，并打开 XX 页面；

b.点击报表右上角的批量导出按钮并下载。

4）期望结果：简述测试步骤完成后理应出现的结果。比如上述的测试案例，可以写为：文件下载格式为 xls，文件首行为报表标题，底色为空色，数据与系统显示的一致。

5）测试人员：标注案例测试的负责人员名称。

编写好测试案例后，就可以以此进行测试，并把测试过程及结果编写为测试报告。一般测试报告模板包含以下内容：

1）需求描述：简述测试需求的基本内容，可把需求文档的内容复制粘贴。

2）测试结果：依照测试案例填写列出测试内容，预期结果，实际结果，是否通过，负责人及遗留事项。若测试结果不通过且需要遗留，则在遗留事项中填入遗留原因及处理时间。

3）结论：首先要对测试结果进行汇总，汇总项有：测试案例总数、已测试案例数、未测案例数、通过数、失败数及遗留数。这些数据为后续的结论打下数据基础。

最后依据测试结果及数据汇总给出通过或不通过的结论。若结论是不通过，则需要注明不通过的理由，或者结论通过但出现失败数或遗留数的时候，则需要注明通过的理由。

检查列表

检查列表已有专门文章介绍，详细请看《开发质量提升系列：checklist 投产检查列表（上）》及《开发质量提升系列：checklist 投产检查列表（下）》。

投产文档 &验收列表

投产文档主要用于指导投产人员完成投产动作的操作步骤，一般情况下由运维人员进行操作。由于运维人员不熟悉所投产的系统，所以要求操作步骤必须细化到可以直接放到命令窗口执行，或者把操作步骤汇总成脚本直接执行。

投产也是开发质量提升重要的一部分，若要详细分享的话会涉及较多的内容，所以这部分内容我们明天再继续分享。