重读《从菜鸟到测试架构师》-- 单元测试测点啥

 

上回说到，小艾写了一段产品代码，却由于未做好单元测试而导致过多细微的bug流入到了功能测试阶段，经过组长一番谆谆教诲，小艾明白了单元测试是什么，谁来做单元测试以及为什么要做单元测试，可是对于单元测试测什么，怎么测却依然毫无头绪……

 

摇篮有多大——单元测试的范围

单元测试需要保证：覆盖到所有新开发代码、修改代码及受影响的代码。

    覆盖代码所有分支，包括正常路径及错误路径

    覆盖所有有效输入/输出情况

    覆盖无效的或预期外的输入/输出情况

    覆盖所有的日志文件和返回代码

    若有出错恢复步骤，确保其正确

    验证代码的逻辑正确

    为满足国际化要求，确保包含虚拟翻译的build环境中通过测试

    对敏感代码要测试其性能，若有必要，需描述代码路径及对数据库的访问

    单元测试需要在开发环境中完成

    修改所有可翻译的代码片段，保证无错误

对于Java等代码源文件，需要经过代码审查，保证其满足代码开发标准和编程规范~

 

有规范、有步骤地捉虫子——单元测试的流程

单元测试开始的标志：接到一份新的设计文档或一个bug之后就要开始考虑单元测试了。

单元测试结束的标志

    全部新增的代码和更改的代码都已经完成，且集成到代码储存库

    代码审核完成

    所有单元测试已经执行并通过，用例集成到用例存储库

    所有的注释已经在代码中编写且通过代码审查

    所有已知的问题都已经得到解决，或已经提出了解决遗留问题的下一步计划

程序

1. 创建/修改代码和相关文档

2. 对新开发代码或修改代码进行单元测试

3. 代码审核

4. 版本控制

 

来一套杀虫装备：单元测试的工具

（作为IBM的技术文章，书中是以JUnit来测试Java代码的开源框架，由于本人对Java不熟悉，也对JUnit不熟悉，在这篇代码量占比比较大的章节中，没有打算一一敲代码将其搬上来。如果对这一章节有兴趣的朋友们，可以上网搜寻JUnit的相关文章。当然，小编也并没有偷懒哦，早在2015年4月，小编写了一篇文章叫《利用单元测试框架进行单元测试》，当然，由于小编使用的是C#语言，因此使用的是Visual Studio的测试模板，如果有兴趣的话可以查看这篇文章：http://www.cnblogs.com/Ribbon/p/4432455.html，这一章节的原文内容就此略过，敬请各位看官谅解。）

 

尾声

在审核单元测试报告时，需注意：

    手动的单元测试报告需要有详细的步骤，包括使用到的数据集。

    自动化的单元测试报告不仅要有运行结果，还要给出描述，说明这一组单元测试所测的是哪一部分的代码。

而关于测试覆盖率，需要保证：

    所有新增流程都已经被覆盖到。

    覆盖有效/无效的输入/输出

    覆盖日志信息

    覆盖可接受性测试涉及的全部流程

    对于Services，覆盖每一个API.

    覆盖全球化和国际化的要求

    无法通过UI验证的功能点，要在单元测试中覆盖

 

小艾终于算是明白了单元测试的全过程了，而在工作过程中，开发也愈发有效率的同时bug密度下降了，不过耦合度依然没怎么降低，突然他隐约想起组长提到过测试驱动开发，好奇心起的小艾，于是又找到组长跟着学习了，那么什么是测试驱动开发，测试驱动开发又有什么好处呢？我们下回分解~

 

想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月