由单元测试引发的一些思考与总结

简述

工作以来，主要做企业级Web应用开发，我主要的后端技术栈JAVA，Spring生态，Maven， 从项目构建到业务代码的完成，单元测试免不了，不过大部分的测试我是直接用PostMan/PostWoman测接口，看测试结果，出问题了直接Debug。有些业务场景涉及到并发操作的，我会直接用JMeter + Badboy去实现并发测试。

作为一名程序员，不仅要保证自己写的代码能通过编译，正常地运行，而且要满足需求和设计预期的效果。

下面我从自身工作经历简单罗列下自己常用的测试工具。

单元测试框架/工具

JUnit

我目前一直用JUnit4；
这里给出一个别人的入门教程：JUnit4单元测试入门教程
注：虽然这个这个教程里面有些内容有点滞后，但是不影响入门JUnit4；

如果你用maven构建项目的话，配置JUnit4依赖就可以在你的代码中使用JUnit4测试框架了；

小技巧：IDE有生成测试代码的快捷键，用起来很方便，不要自己瞎倒腾从0到1的去写测试类，没有必要这样子。

IDE是啥？
Integrated Development Environment, 例如Eclipse、IntelliJ IDEA这样的集成开发环境；

TestNG

个人直观的感受是日常使用和JUnit4差不多，我并没有把它用出花来（我没有深度使用过它）。
参考资料：TestNG详解-深度好文

Mockito

Mockito 是一个强大的用于 Java 开发的模拟测试框架, 通过 Mockito 我们可以创建和配置 Mock 对象, 进而简化有外部依赖的类的测试.
使用 Mockito 的大致流程如下:
• 创建外部依赖的 Mock 对象, 然后将此 Mock 对象注入到测试类中.
• 执行测试代码.
• 校验测试代码是否执行正确.

为什么要使用Mock?

在单元测试中，模拟对象可以模拟复杂的、真实的（非模拟）对象的行为， 如果真实的对象无法放入单元测试中，使用模拟对象就很有帮助。

哪些场景，可能需要使用模拟对象来代替真实对象

• 真实对象的行为是不确定的（例如，当前的时间或当前的温度）；
• 真实对象很难搭建起来；
• 真实对象的行为很难触发（例如，网络错误）；
• 真实对象速度很慢（例如，一个完整的数据库，在测试之前可能需要初始化）；
• 真实的对象是用户界面，或包括用户界面在内；
• 真实的对象使用了回调机制；
• 真实对象可能还不存在；
• 真实对象可能包含不能用作测试（而不是为实际工作）的信息和方法。

例如，一个可能会在特定的时间响铃的闹钟程序可能需要外部世界的当前时间。要测试这一点，测试一直要等到闹铃时间才知道闹钟程序是否正确地响铃。如果使用一个模拟对象替代真实的对象，可以变成提供一个闹铃时间（不管是否实际时间）,这样就可以隔离地测试闹钟程序。
摘自:维基百科 、Mock和Mockito简介

注：建议测试框架用好一个就可以了，不过自己平时写Demo或参与研究型的项目，可以换个框架、工具尝尝鲜；

并发测试工具

JMeter

开源，简单易学，无需安装；
The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
JMeter 官网

注：我之前的测试搭档用loadrunner，不过她老用不好，录制脚本总失败，所以我对loadrunner有个刻板的印象：不好用噻，还得花钱买。

我是为什么开始用BadBoy、JMeter 的呢？

2017~2018年负责某个平台的运维开发工作，发现该平台某个企业级Web应用在Weblogic集群中频繁出故障，经过分析应用的运行日志及业务日志发现是IO并发引起的，于是开始借助BadBoy录制压测脚本、JMeter 来做压力测试，在测试环境中复现该应用在生产环境中的故障，生成dump文件来分析、调优，为了避免走题，后面具体的实施方案就不这里介绍了；

入门资料：
JMeter入门教程
Jmeter+badboy环境搭建

BadBoy

BadBoy官网

项目的一般测试流程

为什么需要了解项目的一般测试流程呢？

团队协作，工作协同，项目的测试流程开发人员也需要了解，因为你面对的对象是项目经理、开发同事、你的Leader、业务人员、测试人员、用户（或者说甲方爸爸），而这些对象由于各方面的原因，会出现项目流程安排、项目计划错误或者说偏差。
比如项目经理在定开发人天时没有想到测试人天，你的Leader也未必考虑周全测试人天（而且不是每个Leader、项目经理都懂项目流程），你的测试搭档或许入行不久或许入职不久或许是外包的测试人员，然后项目经理Email你人天计划表让你确定最终开发人天的时候你也不知道测试流程，于是开发人天中没有测试人天或者测试人天预估少了，buffer里面也没有考虑测试人天，后面的故事就精彩了……

注：测试人天一般由测试Leader那边过目最终定夺，但是大部分情况下会由测试、开发商量确定。

测试流程

不同公司、不同性质（级别）的项目测试流程不一样，下面简单的说下项目的一般测试流程。

测试需求分析

测试人员阅读需求，理解需求，主要就是对业务的学习，分析需求点。
这时候往往：业务、开发都会参与进来帮助测试理清业务需求，方便测试人员写测试案例；

搭建测试环境

这个一般开发人员来做；
注：UAT前还要搭建好生产环境，一般开发和运维一起做；

编写测试计划

这个一般是测试人员了解清楚项目的业务需求后制定给出；

编写测试用例

测试计划确定了以后，测试人员便开始编写测试用例；
编写测试用例一般有模板文档，每个公司测试用例模板文档不一样；
注：
（1）编写测试用例是一件枯燥且辛苦的事情，一定程度上可以检验测试人员是否理解了业务；
（2）通过和测试搭档聊天了解到他们在做测试案例的时候同一个功能要写正面正例,反例（多种），有时候反例考虑不全会出现一些明显的、可以避免的bug没有被测到；
（3）对测试好点，体谅是一方面，另一方面是：也给自己留条后路；

集成测试（SIT）

测试人员做；

SIT (System Integration Testing) 系统集成测试，也叫做集成测试，是软件测试的一个术语，在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。

系统测试（ST）

从技术角度看，系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。
该阶段主要对系统的准确性及完整性等方面进行测试。
主要进行： 功能确认测试、运行测试、强度测试、恢复测试、安全性测试等。
系统测试的测试人员由测试组成员（或质量保证人员）或测试组成员与用户共同测试。在整个系统开发完成，即将交付用户使用前进行。在这一阶段，完全采用黑盒法对整个系统进行测试。

用户验收测试(UAT)

用户来测；

UAT (User Acceptance Testing)用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。