2023年6月28日发(作者：)

java接⼝⾃动化（⼆）-接⼝测试的⽤例设计1.简介　　在这篇⽂章⾥，我们来学习⼀下接⼝测试⽤例设计，主要是来学习⼀些⽤例设计要点。其实说⽩了，接⼝⽤例设计和功能⽤例设计差不多，照猫画虎即可。不要把它想象的多么⾼⼤上，多么的难，其实⼀样，以前怎么设计，现在就怎么设计，和⿊盒测试设计测试⽤例半⽄⼋两。这⾥不再赘述，想详细了解的可以看⼀下Python的接⼝⾃动化⽤例设计。宏哥在这⾥，换⼀个⾓度来说接⼝测试的⽤例设计，⾸先我们看⼀下接⼝测试的范围。2.接⼝测试范围2.1功能测试：验证产品逻辑是否正确　　功能测试是我们接⼝测试时候相当重要的⼀部分，接⼝的功能都没实现，后边的异常、性能就更加谈不上了。其实接⼝测试和在web页⾯、或者移动端操作那些按钮、输⼊框是⼀样的。按钮将绑定的参数通过接⼝传过去，⽽输⼊框是将你输⼊的参数通过接⼝传过去。接⼝测试是在产品还没有开发好按钮和输⼊框，你⼿动写参数通过⼯具或者其他⽅法传过去，验证是否可以得到期望的。下边的这⼋种接⼝功能测试的8种⽅法和web页⾯的测试⽤例的设计⽅法⼀模⼀样的，这个都是测试的基础知识，不知道的⾃⼰可以单独查询⼀下各种⽅法的概念及其的⽤法。　　2.2异常测试null : 是开发过程中特定指的⼀个对象为空的端符，就是⼀个空对象，不指向任何内存地址" " : 指⼀个空字符串，代表该对象有值，指向⼀个空地址数据类型：例如我们有个年龄的字段要求传的是ini类型的值，我们给它传的是字符串。这就是数据类型异常。8中基本数据类型，我们传⼀个不符合规定的数据类型。负载均衡架构：测试某⼀个后台(Tomcat 4)挂了，挂了之后 Tomcat4的请求会直接返回⼀个错误（前台1个nginx ,后台多个 Tomcat），测试是否会返回这个错误，能否会使⽤户访问失败；⼀段时间后，想让 Tomcat4 重新加⼊，判断能否重新加⼊集群中并正确处理所有请求。冷热备份：冷备份不常见，热备份：前⾯有4个Tomca，后⾯有4个Tomca备份，如果Tomca4挂了，判断Tomca4的备份能否顶替之前的，仍然保持4个服务器存活；当Tomca4 正常后，判断能够成为Tomca4的备份。1.3性能测试（狭义）负载测试：我发了好多请求，看看能不能正常发出去，再看看服务器端能不能正常处理这些发过来的请求。稳定性测试：⽐如我跑服务跑了好长时间，⽐如24h、⼀周等，看看能不能将程序压垮等等。3.⾃动化接⼝测试范围为什么在这⾥没有涉及到前边接⼝测试的环境异常和功能测试。在这⾥宏哥做了细分，这部分主要是有其他的测试负责的，⽐如：环境异常测试，⼀般需要我们协调和运维配合。需要他们把环境部署成和线上⼀样的架构，以及硬件、内存等等。由于各个公司的资源和重视不⼀样，但是最差了也得是等⽐例缩⼩的⼀个初始化的模型。这样做的接⼝测试才有意义。性能测试也可以⾃动化测试，这个也有专门的测试，当然了，你也可以进⾏⼀些简单的测试，如果你是全栈测试，那么这三部分你都精通那最好了。这⾥宏哥主要介绍的围绕的功能测试和数据异常测试。4.⾃动化接⼝测试⽤例设计　　这⾥宏哥通过具体实例说明⼀下。⾃动化接⼝测试原则：你能够把你设计的接⼝测试⽤例映射成⼀张表。因为映射成⼀张表你才可以更好的⽅便的操作，并且可以⾃动加载它。4.1接⼝⾃动化⽤例设计⽰例：登录环境异常测试时需要运维⼩伙伴配合测试的，此暂时不做描述以常见的登录界⾯为例输⼊：⽤户名：邮箱或者⼿机号码输⼊：密码：6-16位的长度，区分⼤⼩写，不能⽤空格⾸先，我们先要知道接⼝测试⽤例的规则，与功能测试⽤例不同，不需要描述测试步骤。我们需要描述id（序号）、⽬标URL、username、password、协议状态码（可写可不写）、程序状态码（开发返回成功的状态码）、返回内容（例如success）、实际结果、执⾏状态（⾃定义，例如0：失败。1：成功）。根据如上内容，可以把这个整理成⼀个表中，如上字段作为表头。按照正常数据和异常数据维护成Excel就可以。数据异常：null、“”、特殊符号（&、*）PS:红⾊框圈住的针对执⾏SQL时数据截断的情况。select username，password from user where username = “”" 中间的单引号将会截断，抛出异常。设计⽤例表头时，将中⽂转换成英⽂，⽅便程序做映射时处理,同时也⽅便写⼊代码中。5.环境异常测试　　前边虽然说需要协调运维的⼩伙伴配合测试环境异常，但是在这⾥你可以提前考虑⼀下，什么事情都要向到前边，未⾬绸缪。不要等出事了临时抱佛脚。5.1简单web架构集群上图是⼀个简单的web部署架构。接⼝测试主要是前台传递参数，后台接⼝参数并处理返回期望的结果。简单的描述⼀下上边的架构：⽤户通过web页⾯发送请求到nginx，nginx接收到请求不作任何处理，将请求分发到后台的tomcat1、tomcat2、tomcat3服务器上。服务器处理请求后，将结果返回到web页⾯，⽤户看到结果。这⾥分发是有规律的，不是⼀同乱分发，那样还不得有的服务器先得没事⼲，有的服务器累死了，分发原则：根据userid来进⾏区分。例如：取余，当余数为0时，分发到1，当余数为1时，分发到2，到余数为2时，分发到3。环境异常条件：tomcat2服务器挂掉了，专业点就是宕机了。假如此时有9个⽤户，他们的userid分别是：1，2，3，4，5，6，7，8，9。此时恰好是1⽤户把tomcat2给玩挂了。5.2环境异常测试⽰例：结合上图：宏哥来描述⼀下，这个环境异常的场景，根据这个场景设计的测试⽤例。⽤户1将服务器tomcat2玩挂机了，恰好此时⽤户1⼜发出请求，所以此时⽤户1的请求期望结果只能发送到tomcat1或者tomcat3上。服务器挂机以后运维团队收到告警，快速修复tomcat2服务器（例如重启），当下⼀次⽤户4发送请求的时候，由于tomcat2正常所以预期结果还是正常环境了分发到tomcat2上。这⾥我们主要是观察⼀下tomcat2是否可以正常加⼊到集群中。这些策略可以提前和运维的⼩伙伴定好了进⾏测试。5.3如何确定分发到那台服务器　　⽅法：通过⽇志查看有没有分发到，例如：⽤户1分发2上，即使访问成功但是没有⽇志，那么这就是⼀个bug，和我们之前定好的均衡策略有冲突。其他的都类似。