API测试最佳实践 - 身份验证

适用等级：高级

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. 也别忘了跑跑性能与压力测试

以上的任意一个测试用例都应该做为负载测试跑一跑，确保一个API的身份验证机制在极端压力下依然正常工做（这也是黑客最经常使用的手段）。若是有问题，可能跟错误的线程管理有关，数据库链接共享有关等等。若是（没有若是）可能，考虑组合多种不一样的身份验证的测试用例，例如，为了获取很挫的错误信息，同时运行负面的身份验证相关的测试用例以及受权相关的测试用例。