关于测试

前言

关于测试这方面的知识其实很早就想去接触和了解，然而公司的项目测试系统并不是特别完善，导致整个开发组没有几个人在写测试，我觉得这是一件非常可怕的事情。在我看来，一个有效且可靠的测试是可以避免很多低级错误，而且也极大的减轻了测试人员的负担，像我们开发组常年堆积 PR，一方面是我们 CI 架构的问题，另一方面是开发者对自己的代码没有足够的信心，导致一些较简单的 Bug 修复都要“麻烦”测试人员，如何解决这些问题呢？让我们来了解一下测试吧。

测试的基本概念

读大学的时候，如果是科班出身的开发者，应该都有上过一门测试的课程（吧），我不清楚是不是每个计算机专业的都有这门课，反正我们当时的的确确是有这门课，而且在当时看来是挺枯燥的，我当时天真的认为测试还需要这么麻烦，什么等价类，边界问题，我心想这些问题不是开发阶段就能发现的吗？开发完肯定要跑跑程序啊，跑程序过程中肯定会注意到这些点呀。想想当时还确实是 too young，实际上很多问题是开发过程注意不到的，因为很多时候我们都是在专注的写业务，赶时间，并没有留给我们过多的时间去考虑这些细节。下面来回顾一下几个基本概念

白盒测试

白盒测试又称为“结构测试”和“逻辑驱动测试”

定义：把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通俗来说，白盒测试就相当于假设一个盒子是全透明的，全透明意味着你可以看到内部的所有结构，然后设计数据来对内部的结构进行覆盖性测试，放到代码层面来说呢，就是需要测试人员熟悉你编写的代码，看懂你的代码是在做什么，从而设计一系列的数据进行下面几种测试，如：

• 语句覆盖
• 判定覆盖
• 条件覆盖
• 判定/条件覆盖
• 条件组合覆盖
  这种情况需要测试人员的技术水平比较高，需要能看懂代码而且明白业务逻辑是在干什么，但是一般小公司都不会有这种类型的测试人员，考虑到成本可能相对较高。所以这种测试白盒测试只能由你，也就是写代码的那个人来进行，只有你知道哪里可能会出现边界值问题，哪里会有死循环等等一系列潜在的 Bug

黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
黑盒测试是用得相对较多的一种测试方法，黑盒测试是站在用户的角度来进行测试。举个例子，就拿 Web 项目来说，某开发者提交了一个新功能，该功能是一个登录的功能，那测试人员需要做的事情是什么呢？

1. 拉取该功能代码的分支
2. 部署到测试环境
3. 开始测试
   怎么测试？ 就按用户的操作来一遍，首先，输入账号密码，测试能不能登录成功，然后，输入一些不合法的数据，再次测试登录，查看网页上的提示信息是否正确，比如说登录失败，那为什么失败，网页上有给出错误提示吗？是没有输入验证码还是密码错误……

TDD（Test-Driven Development）

TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。 - 引自百度百科

传统的编码方式

传统的方式在当前来看仍然有很多的人在采用，特别是一些初创团队，为什么？因为赶需求呀，一般有如下这类编码方式

• 接到一个大需求，不去分解，直接一顿操作输出，这种情况到最后代码都会变成一坨东西，而且还不能轻易去变动，因为这就像一座没有地基的房子，稍微一个小改动，整栋大厦都崩塌
• 一个小改动，但是涉及很多模块的调用，只管自己当前的需求完成就好，看到效果 OK 就万事大吉，
• 调试，调了好久，终于调出来了，不去细究原因，结果一些边界值线上就出现了 500
• …

TDD编码方式

• 大任务先分解成 N 个子任务，从每个最小的子任务下手
• 大模块先画出流程图
• 根据流程图进行编写测试，注意：是先写测试
• 边写测试边实现代码逻辑，这也就是为什么要分解任务，如果任务不是足够小的话，你是无法边写测试边写逻辑的，这得乱成什么样子啊

BDD（Behavior Driven Development）

BDD是行为驱动开发，它是从 TDD 发展而来的一种软件开发方法。它的不同之处在于，它是用一种共享语言编写的，这可以改进技术团队和非技术团队以及利益相关者之间的交流。在这两种开发方法中，测试都是在代码之前编写的，但是在BDD中，测试更以用户为中心

不知道大家注意到没有，BDD 三个单词都没有含有 Test 的字眼，这说明这种模式跟测试无关（Behavior driven development has nothing to do with testing），BDD 主要是帮助你跟你的leader，boss 或者是运营等沟通交流需求。在公司日常需求讨论大会上，产品经理、运营或者设计的小姐姐们都喜欢讨论当前这个需求需要怎么做，基于用户的角度去看这个需求，以及用户的动作行为（behavior），其实这就是一种 BDD

Given-When-Then

原谅我真的不知道怎么把它翻译为中文，符合这种模式下的一般都是 BDD

1. 给（Given）定一个实际的场景
2. 当（When）动作或行为发生时
3. 然后（Then）产出结果

这么说可能不太理解，一个比较实际的例子就是：

1. 假设用户没有在登录表单填入任何数据
2. 这时，用户点击登录
3. 然后显示错误信息

优势

• 你不再需要去定义各种各样的测试，而是定义用户的行为
• 你可以用这种方式来跟你的开发人员、运营人员以及产品经理进行沟通，降低沟通成本
• BDD 学习的周期相对较短，毕竟不需要编码
• 在开发前就已经明确完成时的目标

劣势

• 使用 BDD 的前提需要 TDD 的经验，因为如果你不知道技术方案的实现，BDD 讨论出来的结果也是毫无意义的
• BDD 与 瀑布方法不兼容

参考资料：
《深度解读 - TDD》
《What is BDD - 01》
《What is BDD - 02》