预备知识：深入理解接口测试！

实验简介

随着移动互联网甚至物联网的触角深入到人们生活的每个场景，每个角落，伴随而来的便是企业对其软件系统接口定义和研发，以便于进行数据传输和交换。由此导致目前企业急需大量专职接口测试工程师，因为接口测试天然具备自动化测试的可行性。所以本章内容专门就接口测试的各种存在形式给大家统一一下思路。

实验目的

（1）理解接口测试的含义与作用。

（2）理解代码级接口测试与协议级接口测试。

实验流程

1. 关于接口测试

接口测试是一个比较宽泛的概念，近几年在国内也受到很多企业和测试从业者的追捧。但是很多人对接口测试的理解并不完整，事实上，我们无论通过何种方式运行一段程序，我们都必须依赖于调用该程序的接口才能实现。

比如，假设我们现在通过登录界面输入用户名和密码，点击登录按钮，最终该操作会被组装为一个HTTP请求进而发送给后台服务器端，后台服务器则会直接调用实现登录的接口，通过该接口来运行登录的实际代码。

那么在这个过程中，点击“登录”按钮是一个前端界面，所以我们如果通过该方法来观察其最终运行状态的，我们称之为界面级的黑盒测试。当然，我们也可以利用各种协议发送工具甚至用代码发送协议数据包给后台服务器进而观察其运行状态，此时，我们称之为协议级的接口测试。当然，我们也可以从代码层面直接调用该登录接口，那么此时我们称之为代码级的接口测试。最后，我们还可以直接深入到代码实现层，对代码的实现逻辑进行详细的测试，我们又称之为白盒测试或单元测试。

那么问题来了，这整个过程唯一的区别仅在于我们调用该登录代码的方式不一样，最终真正工作的，都是同样的一段代码，这个本质是绝对不会因为被调用的方式不同而发生一丁点的变化的。所以，任何一种调用的方式，都是在驱动程序运行而已，本质上来说，他们所做的事情没有任何区别，那么与其这样，我们为什么还要基于界面来测试登录的功能呢？我们完全可以基于其接口来进行测试，也可以达到同样的目的。比如我们可以通过发送HTTP请求的方式来测试登录功能，也可以直接调用登录代码来测试登录的功能。而且这样的做法都是可以自动化的，也是可以重用的。这也是为什么接口测试越来越受到重视的原因。

当然，也正是因为接口测试的所谓接口，是一个不太容易下定义的概念，所以我们千万不能盲目地认为协议级的测试就是接口测试，或者代码级的测试就是接口测试，这些理解都太过绝对。事实上，点击“登录”按钮，也可以被称之为一个接口，而与之对应的测试，我们则只能称其为界面级的接口测试了。所以请大家不用纠结于概念本身，更多地专注于从不同角度来完成对一个功能的测试，进而达到更全面的测试覆盖，尽早地找出Bug才是王道。

2. 关于白盒测试

本书在前一章便将自动化测试从另外一个角度为大家进行了归类：代码级，协议级和界面级。本书所讲的白盒测试，统指代码级的测试。白盒测试是相对于黑盒测试而言的一种测试方法而已。是指我们可以基于系统的代码层逻辑来实现非常有针对性的测试，其参考文档主要是系统的详细设计文档，甚至可以精确到算法层实现，也可以向上提升到代码接口层。

白盒测试的核心就是利用测试驱动程序来测试被测程序（如某个函数或方法），所以白盒测试默认情况下自带自动化测试属性。从接口测试的定义来看，白盒测试自然也是通过调用其函数或方法的接口才能完成测试的执行。所以，本书后续所介绍的白盒测试，均是指基于代码级接口实现的测试。我们既关注接口规范，也关注代码的逻辑实现。

白盒测试既然天然就是属于自动化测试，我们当然应该重视白盒测试工作，将白盒测试，灰盒测试和黑盒测试有效地结合起来，各自完成不同的测试。比如我们可以重点利用白盒测试来完成对基本功能点的测试或部分性能测试，利用灰盒测试如协议级测试来完成可靠性，安全性，性能等测试工作，利用黑盒测试完成用户体验，兼容性方面的测试。通常情况下，这样的组合，会让我们的测试工作变得更加有效率。建议大家不妨在工作当中尝试这样的组合。

3. 代码级接口测试实施价值

代码级测试在预防软件产品的Bug方面其实是非常有效的。如果我们将其发挥好，从组织和技术层面做好协调和规范，其价值不容小觑。简单将其归结为如下几点：

（1）容易上手：只要对代码有一定概念，都可以轻易完成针对代码的专项测试。即使是一个没有受过正统的程序设计培训的人，也可以比较容易地按照标准流程和模板完成测试脚本的开发和测试数据的准备。

（2）容易实施：由于代码级测试工作直接使用测试代码来调用被测代码（通过其开放出来的接口进行调用），所以实施过程非常容易。我们只需要通过简单的判断就可以确定该项测试是通过还是失败。

（3）容易维护：通常情况下，在软件研发的过程中，一旦代码的接口确定，变动相对比较少，所以维护该测试脚本的工作量相对较低。测试脚本也相对比较稳定。

（4）容易见效：一旦我们将代码级测试工作实施起来，效果是非常明显的。马上可以看到测试脚本所产生的效果。

（5）容易定位：由于测试脚本直接调用被测试代码，所以一旦测试脚本无法运行通过，要定位该问题将会变得非常容易，同样的，修复该问题的成本也会更小。

（6）增强质量意识：事实上，很多企业的代码级测试工作会由测试团队和程序员团队共同负责，这将非常有助于程序员团队在编写代码时增强其代码的质量意识，为全员质量意识打下坚实的基础。

4. 代码级接口测试实施难题

那么，代码级测试既然这么有价值，为什么现在很多企业并没有真正将其实施得很好呢？为什么我们平时看到的绝大多数企业都只是在大谈特谈接口测试或界面级功能测试，或者是系统级性能测试，很少谈及代码级测试呢？当然，这当中有技术原因，但是更重要的，是人为的原因。笔者就这些年的经验，为大家总结一下为什么很难将代码级测试实施起来的一些原因：

（1）程序员不习惯：程序员们都非常习惯了直接上手写代码，并没有养成写代码之前或之后还要来写测试代码的习惯。每一个程序员，从开始写代码的第一天起，就从来没有人给他们传递过，什么叫质量意识，什么叫代码之美，什么叫敬畏之心。

（2）测试人员编码能力差：很多测试工程师在编码方面的能力的确不敢恭维，而且国内普遍存在这样一种奇怪的现象就是写不好代码的人才去做软件测试，可以相像，这样的软件测试，又能测试得有多深入？

（3）程序接口无规范：代码级测试能够实施好，必须需要一个规范的设计文档和接口说明，甚至清晰的算法实现。但是在很多研发团队中，能把客户的需求分析清晰，形成文档已经不易，根本没有时间来设计接口规范等这么细节的事情。所以程序编写的过程就是一个打补丁的过程，导致代码级测试工作很难实施。

（4）利用调试代替测试：程序员团队都会将自己的代码进行调试，进而尽早地发现程序中可能存在的Bug。这本身并没有错，错的是误认为这就是测试。事实上，调试是单次的，随机的行为，不具备可重用性，比如程序员每一次调试输入的数据可能都是随机的，而且这个数据很有可能没有很好地覆盖代码逻辑。而代码级测试则是严谨的，可重复运行的。无论程序怎么样修改，只要能够顺利通过代码级测试，则都是可以接受的，除非测试程序有Bug。

（5）项目时间紧迫：这应该是每一个团队都会提到的一个问题。由于时间紧迫，我们没有时间完整地测试；由于时间紧迫，我们没有时间写测试脚本；由于时间紧迫，我们只能全部时间都用来写代码？但是真的这样就可以提高效率吗？无数失败的或延期交付的项目经验告诉我们，如果没有很好地规范和严谨的流程，以及全员质量意识，即使项目赶出来了，客户也不一定认可。

（6）只关心用户看得到的东西：什么，代码还需要专门测试？我们只做黑盒测试，将用户的操作过程模拟好就行，这样用户就不会发现问题了。但是，很奇怪的是，往往用户什么问题都可以发现，我们千万不能抱有侥幸心理。

（7）测试程序复杂度高：有时候我们为了能够调用一个被测代码，我们需要准备大量的测试环境和测试数据，这个是代码级测试经常遇到的问题。就是测试驱动程序很难开发，导致代码级测试的门槛较高。还不如最后由黑盒测试来完成来得简单方便。事实上，这个问题我们需要辩证地来看待，针对测试环境非常复杂的情况，无论白盒，黑盒，可能测试起来都会比较复杂。问题始终都得解决，通常笔者会建议代码级测试更多关注在代码的算法层或逻辑实现层（即层次更低的代码）。而协议级或界面级的测试，更多关注于控制层代码。

事实上，笔者并不想鼓吹代码级测试多么完美，多么有价值，但是我们一定不能无视它的存在。如果在研发团队中，我们把代码级测试简单实施起来，迈出第一步，或许，我们会更容易理解并接受，进而认可其价值。简单来说，代码级测试的工作多做一些，系统测试的工作我们就可以少做一些，而且根据缺陷放大模型，把问题扼杀在摇篮中，更能看到其价值。

思考练习

（1）请理解单元测试与白盒测试，代码级接口测试与灰盒测试在作用上的区别。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。