适用等级：高级
1. 概况身份验证通常被定义为是对某个资源的身份的确认的活动，这里面资源的身份指代的是API的消费者（或者说是调用者）。一旦一个用户的身份验证通过了，他将被授权访问那些期待访问的资源或API。
验证（Authentication）- 指的是对API最终使用者的确认的活动。
授权（Authorization）- 指对那些验证通过的用户能所能够访问的资源进行确认的活动。
2. 身份验证的标准（Authentication Standars）身份验证的标准和技术太多了，比如，
2. 1 基于表单的验证（Form Based）基于Web/HTML的身份验证通常适用HTTP Cookie。
2.2 Basic/Digest/NTLM身份验证这种身份验证方式使用HTTP头来鉴别用户。
2. 3 WS-Security SAML and Username Tokens基于SOAP/XML的身份验证方式是通过在SOAP的消息头传递凭证实现的，同时你也可以对该凭证信息进行签名或加密，当然这个过程不是必须的，，可选的。
2.4 API关键字（API Key）每一个API的请求都包含一个唯一标识用户的关键字。
2.5 OAuth 1.x/2基于HTTP的交互和工作流，授权对资源的使用，如API、Web等。
OAuth包括了一个间接进行身份验证的步骤，但是并没有宣布这个验证要如何进行。
当你的身份验证以来于凭证或者关键字，并且通过HTTP传输，那么你就要小心了。
因此为了避免潜在的攻击者偷听或窃取你得身份信息，你应该强迫自己使用HTTP/SSL而不是未加密的HTTP请求。
当你考虑测试API的身份验证的时候，这方面有很多最佳实践供你选择。
这些最佳实践除了与通用的测试管理相关，还有关于通身份验证测试技术。
3. 集中并且安全存储身份凭证信息如果你的测试用例脚本包含用户身份凭证信息或者包含访问限制的令牌，那么你就必须考虑集中存储这些信息，并且能够使该信息被轻松及安全的修改，就算其他人能够访问你的测试脚本但也不见得就能读取用户的身份凭证或访问令牌信息。另外，也要确保这些信息不会在日志文件或者测试报告文件中出现：比如你有一个验证用户登陆的测试用例，那么就别把用户名和密码都输出来，至少得做些“手脚”掩盖一下吧。
（我至今还没发现哪个项目组对于用户名和密码有转义、加密或编码的，能完全遵守这条的请护住你的脸~~）
4. 像真实世界的用户一样进行身份验证不管是作为演示，还是测试环境做测试，都别创建超级用户（超级用户指权限很高的用户）进行登陆或访问关键字身份验证（对于API接口来说）。如果按接下来的方式进行测试，那这种测试绝对是不可信的；没有跟你的实际用户一样使用相同的身份验证机制，就不能发现相应的问题，例如回话过期，未授权访问错误，或者身份验证流程本身存在的错误等。因此，如果具有可行性，请确保你对系统身份验证的方式与现实中的用户保持一致；千万被给你的测试用例或脚本留下后门和隐患。
5. 考虑创建负面测试你当然也要确保拥有一些身份验证和授权验证相关的测试用例。比如：
输入无效的用户名和密码。
试图在没有身份凭证信息的情况下访问受保护的内容（或资源）。
尝试使用无效的身份凭证或会话令牌。
锁住一个账户，然后验证这个锁定逻辑或时间段被强制执行了。
尝试通过不安全的信道发送（无效或非法）的凭证信息，如使用HTTP而不是HTTPS，未加密的的XML或JSON等等。
任何一个负面的测试用例，都应该验证响应信息，或者返回报文里所包含的响应的错误代码，但是对于客户来说没啥有用的信息返回给他，因此他不能把系统怎么地。例如，一个失败登陆尝试应该被粉饰一下，如果输入的用户名已经在系统中注册过了。
6. 心里时刻想着设计关于身份验证的测试用例当你设计测试用例的时候，有若干技术能够使身份验证相关的流程更加简便：
模块化你得测试用例 - 如果可行，把你每一个流程里的用来进行身份验证的测试用例、代码或脚本放到一个共享的测试脚本或测试用例李米娜，通过其他的测试用例调用。这样，你就能很容易的修改和维护，尤其是底层的技术或需求变化的时候。
参数化环境配置 - 如果你的测试用例支持不同的测试环境，（dev/test/stagin/production/etc）- 确保你的测试用例很容就能在各环境之间切换。
使用数据驱动的技术 - 对于运行大量的用户身份的测试用例，请使用数据驱动的技术（啥是数据驱动，不需要我解释吧？简单来说就是数据是变化，代码逻辑是不变，你看到是传入的数据和输出的结果。）这么做也是为了在考虑访问控制的情况下所有的数据请求都被正确接收和处理。
7. 也别忘了跑跑性能与压力测试