我对测试方法的理解

我想讨论的是如何设计测试用例更有效，即用最少的测试用例覆盖更多的可能条件，但讨论这个问题前不得不先把测试方法梳理一下。如果把软件看成一个盒子的话，测试方法有三种：

• 1 白盒测试：

  • 1.1 定义：白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。也就是说程序代码你是看得见的，意在检查程序的逻辑结构是否正确。
  • 1.2 优点：由于可以看到程序底层逻辑是如何实现的，因此bug定位更加准确，减少代码调试时间，从根本上调整代码结构。
  • 1.3 缺点：对比直接测试代码实现的功能（黑盒）和一条条检查代码的逻辑结构是否正确来讲，前者更快捷，而且白盒测试也无法从UI层面和性能层面检查软件是否符合预期结果。
  • 1.4 使用阶段：因此白盒测试一般都是用于单元测试，所谓单元就是程序的最小单元，可能是单个程序、类、对象、方法（函数）等。一般是程序员进行的。
  • 1.5 方法：白盒测试意在穷举测试路径或测试条件。参考网址：https://www.cnblogs.com/wwq1993/p/4440201.html

• 2 黑盒测试

  • 2.1 定义：在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。黑盒测试关注的是数据的输入和输出，而不考虑它的内部逻辑是如何实现的。
  • 2.2 优点：黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。相比白盒测试一句一句执行代码，黑盒测试更快捷，出现的错误也更直观，同时也弥补了白盒测试无法进行界面测试、性能测试的缺点。
  • 2.3 缺点：黑盒测试无法快速的定位缺陷。因为软件相当于一个不透明的盒子，具体代码你是看不见的，你只知道出现了什么问题，却无法快速定位哪行代码出了问题。
  • 2.4 使用阶段：一般用于系统测试中，黑盒测试是我们测试人员经常用到的测试方法。
  • 2.5 使用方法：黑盒测试意在穷举可能的输入条件。

• 3 灰盒测试：（以下是自己对灰盒测试的理解，有什么错误请指正）

  • 3.1 定义：我认为的灰盒测试，指的是不像白盒测试那样，力求验证每一个执行语句的正确性，也不像黑盒测试那样，完全不管基础代码逻辑是如何实现的，只管尽可能全面的猜测输入的可能性，灰盒测试是在认为单元测试没问题基础上，既像黑盒测试那样站在客户的角度，推断测试的可能输入，同时也会关注代码对于输入条件的定义、输入的逻辑路径如何实现，从而帮助测试人员快速判断更有效的测试用例，出现问题也能更科学的定位。
  • 我认为灰盒测试究竟对代码的关注程度是多少，取决于你测试的规模有多大。例如，如果对接口进行测试，那么就只需要知道各个模块之间是如何进行调用的；如果对一个模块进行灰盒测试，那就需要知道有关的输入条件是如何定义的，以及输入条件经过的逻辑判断是什么。你测试的模块越小，你关注代码的内容越细。
  • 灰盒测试，力求避免盲目进行测试用例的覆盖，也力求避免细致入微的去验证每一条代码路径的可行性，而是仍然站在客户的角度，仍然去考虑输入可能性，但是会参考代码的逻辑实现，会去分析输入条件在代码中的运行路径。
  • 3.2 优点：我认为灰盒测试是最科学的测试方法，因为不看代码如何实现而单纯的去猜测可能的输入有哪些，那这种可能的输入是无限大的。但在知道输入条件之间的逻辑关系以及定义之后，会更有选择性的排除掉一些不可能的测试用例。例如一个变量，代码定义的类型的是整型，那么再清楚其输入的逻辑逻辑之后，只需要进行整型可能的测试用例即可，排除了测试其是否是中文、是否是英文、以及特殊符号等内容。同时根据这种逻辑关系，可以去设计更多可能的测试用例，而这些测试用例可能在黑盒测试中是不易想到的。
  • 3.3 缺点：需要去快速的读懂代码，需要代码能力。
  • 3.4 使用阶段：有人说用于集成测试中，我觉得也可以用于一个输入条件是无限可能的情况下，例如web中的type=text输入框，当你觉得这个功能非常重要，或这个输入有无限可能的情况下，可以进行灰盒测试，去帮助你排除掉一些可能的输入条件。例如黑盒测试的边界值方法，我觉得就一种灰盒测试的观点，是考虑程序员输入判断条件的时候容易出错的情况下进行的。