测试之厘清测试类别(一些看法)

测试之厘清测试类别(一些看法)

前文提到,我们存在

• 自动化测试
• 端到端测试
• 视觉回归测试

---

试想从软件产品出发，当我们编写我们的软件开始。

开发第一版，也许我们的功能测试case可能只有几个。

测试在手工进行测试，在很多不同终端设备，不同的操作系统上手动测试。

这样的问题会发生什么呢。以后的一次功能的迭代，需要对以前功能做回归测试。

回归的过程中我们很容易想想象得到，这种消耗是指数级的，压在上头的是各种个样的终端设备与操作系统。

即使有专门的测试做回归操作也是很疲惫的。而且很枯燥。枯燥重复的动作为什么不给电脑做呢。

软件添加功能远比缩减来得容易。

个人观点： 在一定程度上，释放人手消耗的测试都是自动化测试。

也就说，单元测试、集成测试、端到端测试可以说都是自动化的一部分。

而视觉回归测试，是当产品到了某一版迭代，测试可能需要对产品进行校验所进行的。

大多数公司的回归测试都是重复的消耗。

---

以下集中讲一下单元测试、集成测试、端到端测试(e2e) (仅一家之言，若有偏颇还望指出)

它针对于软件中的各个最小模块进行校验，这种校验是在模块层次的。

例如我们针对一个模块进行单元测试，模块代码的覆盖性高，分支判断覆盖率高。在以后经过多次迭代以后，在改动当前模块时，这样的单元测试，可以让我们的模块功能得到保障，即时地反馈出功能的校验。

对一些模块unit lib，我们调用的时候其实根本不需要深入到代码细节进行获取调用方法，这种避免的前提下是模块的功能在前置显示，且模块命名等符合直观。

单元测试应该是在最基础也是重要的一环保障了我们代码的质量与可维护性。

集成测试一般指模块间调用关系的case。A模块调用B模块，验证当中调用API功能是否完备，功能符合预期，因为模块测试没有问题，但是在模块连接上也可能存在一些问题。

集成测试也用作测试整个软件的实际功能测试。

可想而知集成测试消耗很昂贵，1、它可能需要模拟真实的一些环境，所以速度上势必较单元测试缓慢。2、覆盖软件中多个部件，所以测试功能也许会变得非常脆弱。3、测试的编写相对于单元测试没有那么直观。

而且集成测试也不能很好得告知错误的确切位置。

(一般来说集成测试的test case会较单元测试少。)

端到端测试(e2e)

端到端测试一般表现为黑盒测试我们的软件，在前端而言，这种黑盒测试，相当于测试手工点点点。

这种测试一般是模拟真实终端环境，模拟用户操作，测试预期是否符合功能要求。

毫无疑问，使用端到端测试的消耗更大，因为它需要真实的终端环境（前端而言）（测试也是很脆弱的）

所以端到端测试的case一般更少，而cover一些核心功能的保障。

一些通用行为，可以交由测试人员进行手工化操作。

---

就前端而言

试想一下，当你做功能在网页验证点点的时候，实际上这个校验就是测试，只是这次测试是不被保存的，当你依赖文件改动，网页功能改变，可能你又要回来验证这个功能。

因为没有途径也没有方法保证你的代码是未被影响的。

前端的页面有没有必要做到百分百覆盖？

前端页面是很多变的，页面结构元素颜色的改变，完全取决于产品的一个想法。这样子改动的成本对测试的依赖是很大的。

在后端而言，API接口，模块接口一般是少变的，这种情况下完全覆盖带来的价值应该更大一些。

我们的测试肯定是会增加工作量的，但是在工作量增加的前提，可以使得当前的代码在可预知的未来有一定的保障性。

从一个地方开始，总好比永远不动来的要好一些。

---

测试是必要的，对代码不光要有产出，还有有保障，对以后接手的人要有同理心。而不是当个撒手掌柜。

---

本文参考元素：

google 搜索端到端测试
google 搜索单元测试
google 搜索集成测试
单元测试到底是什么？应该怎么做？

---

测试的下一篇会回归到代码层面，写一些测试用例。

本篇只表达了目前本人的看法。也许略显稚嫩。

如有错漏，有望斧正

这里联系我

kangkang blog
segmentfault
github ZWkang

### Contact Me

> all encode by base64

- Email: a2FuZzk1NjMwQGdtYWlsLmNvbQ==
- QQ: OTA3NzQ3ODc0QHFxLmNvbQo=

*转载需注明出处与作者*

*否则将被视为侵权*

*Reprinting must indicate the source and author*

*Otherwise it will be regarded as infringement*

Comments