单元测试¶

将程序分解成独立的可测试的模块，一般是函数、方法、类、模块等代码组织单元，然后对这些模块进行单独和独立的测试。

良好的单元测试可以作为一种形式的文档，显示函数或方法应该如何使用，以及在给定输入时应该返回什么。

单元测试属于白盒测试，用例设计方法如下

语句覆盖：使每一行代码都被执行一遍。只保证了代码行被覆盖，但不能保证代码逻辑正确，是最基础也是最薄弱的一种覆盖方式。
判断覆盖：关注整个判断语句
条件覆盖：关注某个判断条件，case较多
路径覆盖：覆盖所有可能执行的路径，用的最多

3A原则

Arrange: 初始化测试对象或者准备测试数据
Act : 调用被测方法
Assert: 断言

测试方法实践¶

TDD¶

Test Driven Development，测试驱动开发，一个经常被提及但很少被执行的开发模式

先编写测试，然后编写能够使测试通过的代码

选用 TDD 并不是测试人员或者测试部门的事情，而是需要公司层面的流程和体系的配合，也正是这种原因，虽然大家都能看到 TDD 的优势，但是在实际项目中的运用还是比较有限。不过可以优化开发流程：所有人员参与需求评审 -> 测试人员编写测试用例 -> 所有人员参与用例评审 -> 开发人员按照测试用例进行编码 -> 开发人员执行用例，进行自测，所有用例通过后 -> 开发人员提测 -> 测试人员进行测试。

要让程序员能彻底地接受和习惯这种开发模式还是挺难的，毕竟很多程序员连单元测试都懒得写，更何况在编写代码之前先写好测试用例了，单元测试正好是对 TDD 的一种改进方案，先写代码，紧接着写单元测试，最后根据单元测试反馈出来问题，再回过头去重构代码。这个开发流程更加容易被接受，更加容易落地执行，而且又兼顾了 TDD 的优点。

TDD经常会碰到协同模块尚未开发完成的情况，可以用mock解决，当接口定义好后，测试人员就可以创建一个mock，把接口添加到自动化测试环境，提前创建测试

参考

BDD¶

Behavior Driven Development 行为驱动开发

参考：https://time.geekbang.org/column/article/417462

框架¶

Python：Unittest、Pytest
Java：JUnit、TestNG
JS：Mocha + Chai

覆盖率¶

代码覆盖率是度量测试是否全面的指标之一