软件测试作为软件质量的保障, 有着十分重要的意义. 按照不同的层次划分, 测试也有着诸多的种类. 按照测试方式分, 有白盒测试, 黑盒测试, 灰盒测试. 按照测试范围或流程来分, 有单元测试, 集成测试与系统测试等. 其中, 应用覆盖面最广, 也是最为基础的就是单元测试.
何为单元测试
单元测试 (Unit Test) 又被称为模块测试, 是针对程序中最小可测试单元来进行测试的活动. 一般来讲, 在如今的软件开发工程中, 是指对程序中方法 (或称函数) 的测试. 通过为这个方法构造初始化的条件, 并运行这个方法, 看这个方法的行为是否与预期的一致, 以此来决定该方法是否正常.
单元测试的意义
快速定位问题
单元测试的主要作用, 就是将原本人工检查程序行为的方式, 在最小可测单元范围内, 用程序检测程序的方法来代替. 为此, 单元测试的主要作用就是定位问题. 同时, 由于单元测试的执行效率较高, 可以大批量快速执行. 这对于对于单元测试覆盖率较高的工程, 若代码工程有任何问题, 则可以快速执行全部单元测试, 能够帮助开发者快速定位或排除问题.
持续集成
目前的软件交付要求快速迭代与持续集成, 在这样的团队中每一天都有代码合入, 并且定期都会有新版本发布. 在这一过程中, 若使用单元测试覆盖软件各部分, 在开发与集成的过程中不对代码进行测试, 发现问题就立即告警, 则可以提高软件质量与开发效率.
优化软件设计与架构
单元测试并不是在代码开发完毕才开始撰写的, 一般情况下都是与开发过程并行或者先与开发过程的. 在这个过程中, 为了构造可测试的接口与参数, 自然会让开发者在软件设计时让程序趋于模块化, 并且接口明确, 层次清晰. 这也就在无形中优化了软件的设计与架构.
重构的保障
在重构代码时, 可能会影响既有业务和功能, 常常会为了解决一个问题而不慎引入更多问题. 若有单元测试的覆盖, 在重构时则有所保障, 能够帮助开发者快速发现问题, 提高重构效率.
单元测试思路
开发者在未接触单元测试之前, 往往无从下手. 其实, 单元测试代码的开发与普通程序的开发没有本质的差别. 它的核心逻辑是:
确认待测试的方法或对象
为待测试的方法构造初始化条件
调用 (运行) 该测试方法
比较被测试方法的行为 (结果) 与预期的是否一致
通过这样一个模板或思路去理解单元测试, 那就非常简单了. 在现行的软件测试实践中, 为了提高测试代码的开发效率, 业界有着许多测试框架, 利用这些测试框架, 可以帮助开发者快速开发测试代码. 为此, 在进行单元测试前, 需要根据自身的情况, 对单元测试框架做一定的学习. 但不管测试框架是怎样的, 其核心思路都与上文讨论的一致.
单元测试原则
单元测试原则常被概括为: FIRST, 分别是:
快速(Fast)
单元测试应该能够被快速地执行完毕, 执行效率低会让开发者不愿意运行. 同时, 单元测试需要在整个开发过程中执行很多次, 过慢的运行速度会影响开发效率
用例独立(Independent):
单元测试用例之间应该相互独立, 最好不要有关联, 也不要有执行顺序的要求.
可重复(Repeatable):
单元测试不应该依赖于环境中的数据, 它应该有自己的初始化数据或条件, 每一次单元测试都是可重复的.
可自验证的(Self-Validating):
单元测试应该不用人工检查, 而是可以自验证的.
全面完整的(Thorough):
单元测试不应该追求每一个方法都覆盖到, 而是应该追求所有的使用场景都全面完整的覆盖到. 例如对边界条件, 错误输入, 大数据量的情况都要覆盖到.
Android 单元测试分类
按照单元测试运行的环境区分, 可以分为本地测试以及设备测试.
本地测试
本地测试 (Local unit test) 运行在 JVM 中, 一般适用于对于没有 Android 依赖的测试. 该部分测试代码一般放置于安卓工程的<模块名>/src/test/java 中.
优点: 运行速度快, 效率高.
缺点: 一般情况下, 测试代码不能有 Android 依赖.
若有 Android 依赖且要使用本地测试的方式, 可以使用测试框架如 Mockito 来实现.
设备测试
设备测试 (Instrumented test) 运行在手机或模拟器中, 一般适用于需要 Android 依赖的测试. 该部分测试代码一般放置于安卓工程的<模块名>/src/androidTest/java 中.
优点: 测试代码直接支持对 Android 的依赖.
缺点: 需要真机或模拟器配合, 运行速度较本地测试稍慢.
实际上, 在这类测试过程中是编译了一个额外的 Apk, 并安装到手机或模拟器中运行的.
测试框架选择
目前流行的 Android 测试框架较多, 按照对 Android 依赖的强弱情况, 可以分为:
无依赖: JUnit
弱依赖: AndroidJUnitRunner,Mockito
强依赖: Espresso
开发者可以根据自身情况来对测试框架进行选择, 若仅仅测试无安卓依赖的 Java 代码, 可以仅仅使用 JUnit 框架. 若待测试的代码对安卓库有一定的弱依赖, 则可以选择 AndroidJUnitRunner,Mockito. 若待测试代码对安卓库有着非常强的依赖, 可以选择 Espresso.
这些框架除了可以满足待测试代码对安卓库的不同依赖情况, 还有各自不同的特点, 如运行环境与条件均可能存在差异. 开发者可以对所需要的框架有一个大致了解后, 再选择进行学习.
来源: https://www.cnblogs.com/chengxuyinli/p/9998637.html