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

 

上回说到，小艾写了一段产品代码，却因为未作好单元测试而致使过多细微的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密度降低了，不过耦合度依然没怎么下降，忽然他隐约想起组长提到过测试驱动开发，好奇心起的小艾，因而又找到组长跟着学习了，那么什么是测试驱动开发，测试驱动开发又有什么好处呢？咱们下回分解~

 

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