互联网服务端测试是个啥（入门科普）

                                互联网服务端测试是个啥（入门科普）

微博：论路痴的自我修养

啥是服务端？

        一般所说的服务端是指为用户在APP或PC使用的互联网功能提供数据服务的背后的一切（你没看错，是一切）。

      移动互联网时代，服务端的概念更加清晰、明确。在PC时代，大家都是浏览器浏览各种Web页，前后端分离的概念相对模糊，反正除了浏览器，其它的都像后端。而在移动互联时代，APP承载了UI界面和交互的实现，数据处理交给大后方——服务端就好了。例如你想发一条文字微博，打开微博APP，点➕号，再点“文字”，出来个发布器，你写“今天天气真不错呀～”，截止到此时还没有任何服务端的事呢，直到你点击【发送】，这时候微博APP才会以调用接口API的形式告诉微博的服务器，有一个天使A要发一条微博，发送的内容是XXX，服务端收到之后赶紧在数据库天使A的微博列表里边新加上一条数据，然后告诉APP说：嗯，发完了。APP就提示你“已发送”。

 

接口API又是啥？

      先说什么是接口API（application programming interface）。提供数据服务的服务端是个可大可小的机构，做的事大多不止一件，它做了这么多事，最终的目标还是要为人民服务，哦，不，是给APP或其它调用方使用，于是服务端就派出了几个代表，API1负责接待发微博的数据请求，API2负责接待发送评论的数据请求等等。并规定好跟API1通讯的接头暗号是param1，param2…，跟API2通讯的接头暗号是param3，param4…，而params就是接口参数，就是用来告诉服务端你要什么服务，具体的要求是什么（我要发一条微博，发送人是天使A，发送内容XXX等等）。

     综上，接口API呢，就是服务端对外提供数据服务最常用的信息交换方式。没错，并不是唯一的方式，对外提供服务共享的方式主要分为一下几种。

• API调用之同步处理（实时、无需等待）
• API调用之异步处理（队列任务，先到先得，适用于调用多、任务重的情况）
• 定期的文件推送（数据量大且对数据实时性要求不高）
• 共享数据存储
• SDK（代码寄存，适用于跨语言、跨框架，使用频繁、服务更新却不频繁的情况）等

      另外说明一点，GET、POST方式是Http接口的参数级的传递方式差异，并不是接口层面的。尽管我们平时说Get接口、Post接口说的那么溜，是因为大多数的接口的所有参数都会才有统一的传递方式。不排除一些特殊情况，同一个接口里参数param1、param2是Get传递的，而param3、param4时Post传递的。除了常用的Http协议，接口的协议方式还有很多，有通用的，也有各公司自己内部定义的。

 

服务端测试就是接口测试么？

       因为最常用的对外提供数据服务的方式是接口，所以服务端开发提测的内容往往就是一个个的接口，毕竟应用层的测试是最好入手的，面向使用者的部分也是最需要保障的。于是一提到服务端测试，大家首先想到的就是接口测试，简历里边能写服务端测试的很少，写有接口测试经验的倒很多。

       所以服务端既然不等同于接口，那么服务端测试就不仅仅是接口测试。一方面，如前面所述，服务端对外提供服务的方式不止API；另一方面，服务端所做的工作也不止应用层这一点。所以全方位的服务端测试，首先要保证对外提供的各种形式的服务（包括API）都符合要求，其次要在测试的技术深度和业务广度上都有良好的覆盖。

 

如何进行接口测试？

       不是说服务端测试不只是接口测试么？别急。毕竟接口测试还是占服务端测试的大部分，所以我们讲讲怎么进行接口测试。

       面试官：请问你们接口测试怎么做的呢？

       候选人：参照接口文档，调用接口，看结果的返回是否跟文档说明一致。测试参数非法情况的处理。

       如果满分100的话，这个回答打多少分呢？勉强60。“不对呀，平时我们测试就是这样做的啊”“接口不就是输入输出么？”对对对，你们说的都对。但是稍稍有点本末倒置了。

      首先说非法参数，参数异常或没有传，这些检查虽然在测试用例范围内，但是论重要性来说应该跟UI测试中检查样式异常情况差不多，属于偏低优先级的那种。因为大多数的API还是属于内部调用的，接口文档相当于是双方的约定法则，非粗心的情况下，大家都会正常遵守，参数的可靠性来说比较高，至少比用户操作可控多了。

      其次参数只是我们跟服务端代码交流的入口，测试真正要重点关注的应该是数据逻辑，需要充分的了解这个API是干什么用的，什么样的数据逻辑，使用了哪些资源或服务，然后设计用例，转化为调用参数的组合，调用接口，检查执行结果。

       所以服务端测试不等同于接口测试，接口测试也不等同于参数调用。

       另外一个问题就是，这接口返回那么抽象，甚至就是一个code：100000和message，我怎么知道对不对呢？测完了心里也没底。

       还是那句话，不要停留在参数调用和程序给你返回的json串儿那点表象，要知道这个接口是干嘛的，用到哪儿，每次调用会发生什么，然后去检验改发生的有没有发生。此时就引入了一个检验深度的问题，最浅的检验就是相信程序给你返回的东西code：100000就成功了。说到底API操作的都是数据嘛，那么最深的检验就是到存储中去看看该发生的数据变化是不是真的发生了。当然，大多数情况我们没有DB等存储的访问权限（权限和风险是一对孪生兄弟），也不知道具体落到哪个数据表里了。方法就是“以不变验万变”，找到可信的数据来源或数据查询方式，验证不可信的被测对象。

      如果说接口测试参数异常不是测试重点，那么还有没有什么异常和兼容测试是测试的重点呢？有的，那就是上下游服务的容错。原则是“上游不可靠，下游要兼容”，如果被测的服务依赖了其它的服务B，那么服务B异常的时候被测服务是否有很好的容错就很重要，否则服务挂起或宕掉都是有可能的。另外作为服务提供方，要充分兼容不同的使用场景、或不同版本的调用方的使用，不能为了场景X或调用方Y做的需求，除了X、Y其它的服务使用者都用不了了。

      最后，全方位的服务端质量保证自然还要包含安全、性能、线上监控等等，除了专项的测试方法或工具知识外，还需要敏锐的嗅觉，能够及时察觉可能存在的安全、性能风险，做到防患于未然。

      要做一名合格的服务端测试人员，要十八般武艺样样精通。不好意思，开个玩笑。其实也差不多啦，要有足够的技术知识储备，要有框架意识，要有充分的质量保证理论做支撑，要有脚本、自动化能力，最好有一定的业务测试或端的测试经验，只有这样才能更好的理解服务链路，从产品的角度思考问题，而不是一头扎进技术里。归根结底，无论是服务端测试还是测试开发，终究都是测试，要立足根本才能做一个优秀的QA人员。