小伙伴们都看了吗，青春的记忆
理想情况的测试输入
在理想的情况下，我们在进行测试前会收到各类文档，其中就包括了产品需求，原型设计，它们由产品经理提供；也会收到接口文档，单元测试脚本，它们由研发工程师提供。为了能够更好开展测试，这些文档都是必须输入的内容，它们的作用如下:
- 产品需求描述了系统的业务逻辑，只有掌握了产品需求，测试工程师才能知道怎么设计测试用例。
- 原型设计更加直观地指明了系统的使用逻辑，对于测试用例的设计和系统的前期认知，原型设计是有辅助作用的。
- 接口文档详细描述了后端接口的访问方式和参数说明，只有掌握了这些，测试工程师才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建。
- 单元测试脚本既是保障接口测试提测项目质量的重要因素，也是研发工程师自测的一种有效手段。
理想的情况很难会有理想的情况确实挺美好的，但现实情况大家也都知道，工作的小伙伴肯定遇到到过下面的情况。
- 仅仅因为产品经理的一句话需求，研发工程师便开始任意发挥，“所见系统即需求” 的情况普遍存在，更别提后续的单元测试和接口文档了。
- 研发工程师从来不写单元测试脚本，提测项目的质量无法保障，接口文档更无从谈起，不知道如何开始完成接口测试。
- 拿到提测项目后，从部署测试环境到开始测试，一直都摸着石头前进。由于接口测试没有充分的输入条件，因此只能从UI层开始测试，结果导致交付质量大打折扣。
项目如果没有接口文档，我们要怎么开始接口测试，还是不考虑什么接口了，直接摆烂，摆烂长期以往影响的还是你自己，我们要学会遇到困难，解决困难。
到底要如何解决接口文档的问题，这里有一套方法可供大家参考。
我们可以通过循环执行 工具辅助，分析问题，询问解惑3个步骤来完成。
首先我们需要先借助一些工具来获取接口信息，然后通过分析接口的访问方式、参数等信息，整理出一些问题并与研发工程师沟通这些问题，从而将一些不知道的参数含义、取值范围等问题弄清楚。
一、工具辅助
接口的抓包工具很多，这次我们使用的是Fiddler工具，有还不会用的小伙伴，可以看看之前分享的文章。
=======《协议测试》抓包工具Fiddler实战教程========
=====《协议测试》HTTP协议请求方法和状态码=======
二、分析问题
下面我们将使用Fiddler工具来分析51CTO登录页的信息，首先启动Fiddler，然后打开51CTO的web端首页，我们可以看到Fiddler截获了很多信息，如下图所示，在界面右侧的Inspectors标签页下，我们可以看到请求和响应的具体内容。
Request消息正文
从Request消息正文中我们可以获知，请求的访问方式是POST，访问的URL是https://home.51cto.com/index？tab=mobile&reback=https%3A%2F%2Fhome.51cto.com&iframe=0&is_go_to_user_set_mobile=1 。读者可以自行查看Request消息正文中各个选项的具体内容，这里重点介绍如下几个选项。
- Host：用来指定访问的服务器域名。
- Connection：其值为keep-alive，表示需要持久连接。
- Accept：用来指定客户端可以接收的内容类型。
- User-Agent：用来指定请求是从哪里发出去的。
- Sec-Fetch-Site和Sec-Fetch-Mode：用来指定JavaScript中有关跨域的一些设置。
- Accept-Encoding：用来指定Web服务器返回的内容压缩编码类型。
- Accept-Language：用来指定语言。
注意，我们需要特别关注Cookie的内容，因为Cookie中包含的都是与确认用户身份、鉴定角色权限等有关的重要参数。进行完上述分析后，我们就可以自行绘制接口信息表了，如下图所示。
接口信息表
在上图接口信息表中，标注了白色背景的部分是此次访问的基本信息，标注了灰色背景的部分是此次访问的头信息，对于这些内容我们已经知晓；标注了黑色背景的部分是Cookie信息，对于这些内容我们尚不知晓。此次访问的body信息是空的。
接口的返回值包含了很多参数，大家有必要关注一下这些参数，因为很多时候，一个接口的返回值有可能是另一个接口的入参，它们起到串联业务逻辑上下文的作用。接口信息表中还包含一些未知的Cookie，由于Cookie中包含了完成接口测试所必须模拟和传递的一些重要信息，因此我们要尽可能完善Cookie，使其成为接口测试的必要输入条件。有了接口信息表之后，我们就可以解惑了。
三、询问解惑
对于此次访问的Cookie中的参数，从语义上讲，我们既不知道这些参数是用来干什么的，也不知道它们起什么作用。
为此，我们拿着接口信息表，找到相应的研发工程师，向他们询问接口信息表中深灰色背景部分的参数。对于其中的每一个参数，都要详细询问以下3点内容，并保证自己已经真的理解。
- 参数的含义及来源。我们要搞清楚每一个参数的含义，记录每一个参数的中文语义，另外，我们还要知道参数的赋值是从哪里来的，是从其他页面或接口返回的，还是由JavaScipt生成的。这样当我们进行接口测试时，就知道应从哪里得到参数的赋值了。如果参数是另一个接口的返回字段，那就需要维护一份接口信息表，以便下次创建对应的参数。如果不允许创建参数，那么我们还需要知道参数的生成规则，以便需要时能够手动构造参数。
- 参数的作用域。参数的作用域涉及的问题包括参数在接口中是用来干什么的，参数在哪一个访问周期中一直存在，参数是否导致业务逻辑分支等。比如，参数是用来验证用户权限的吗？参数的验证算法是什么？之所以要搞清楚这些问题，是为了让我们在进行接口测试时，能够设计更小的参数组合以覆盖更多的业务逻辑，这是对测试用例去冗余的一种好方法。
- 返回值的含义。对于接口的返回值，我们要理解JSON中每一个键对应参数的含义，从而完成业务逻辑上下文的串联。
总的来说，请求和响应的全部参数对于接口测试而言都是必要的输入项，因此我们有必要花费精力完善并留存它们。
整理完文档后，我们就可以编写接口测试用例了。
接口测试要遵循一些要点:
- 测试接口的功能实现. 检查不同参数的数据请求时,接口返回的数据与预期结果也就是接口文档的规范的一致性.
- 测试接口的健壮性(容错性), 比如说传递的数据类型是错误或者传递空数据,特殊字符等与接口规范不符的能否正常处理.
- 测试接口参数的边界值. 比如说传递的数据超出了接口规范的规定的范围,或者数据足够大或者为负数时能否正常处理
- 测试接口的性能, 接口处理和响应数据的时间,并发性等等, 当然这牵扯到代码实现的优化,需要与开发人员沟通
- 测试接口的安全性.比如登录的用户名密码等敏感数据是否明文显示,需要权限的接口是否暴露在外面
- 附上接口测试用例模板：
