TestNG系列-TestNG应用

猛戳：第一篇-TestNG入门

猛戳：第二篇-TestNG进阶

1.重试
2.接口测试框架

重试

为什么要做重试？

由于网络抖动、第三方服务不稳定等因素，我们第⼀次请求的时候⽆结果/结果错误，再次请求后结果正确，为避免误报，我们应加⼊重试机制。

我们选择在断言之前做重试是有意义的，断言之后的重试若接口返回值错误，会产生大量的重复报警。 image.png

重试的实现

1.@Test有⼀个属性retryAnalyzer，通过⾃定义监听器继承IAnnotationTransformer来⾃定义调⽤的重试类。
2.定义⼀个重试类，实现IRetryAnalyzer接⼝。
3.具体代码可以在github上下载，github地址附在文章最后。

接口测试框架

接口测试框架应具备的功能 image.png

挑几点说说：

• 支持多种协议：至少支持http协议，rpc协议种类繁多，要构建可扩展性好的工程结构，使得在后面多增加协议的时候可以无缝切换。
• 仅单接口case无法满足我们日常监控的需要，设计之初一定要考虑场景类case，可以利用dependOnXX来实现。
• 不同环境的case有共同的特点，只是case数据不同，设计时要考虑，分环境提供数据
• 辅助功能不可或缺，尤其是报警、报告和后续的质量数据运营。
• 如果想做接口平台，一开始就要考虑好怎么衔接。
• 接口case试运营阶段，发现框架和接口case的bug，减少误报，提升可信度。
• 作为QA，接口case报警后要及时跟进，揪出报警的真实原因，与研发一起探讨解决方案，为产品质量保驾护航。

接口测试只是质量保障的一种手段，是分层测试的开始，他涵盖很多方面，不只是需求迭代时要去做，做完就扔一边了，那我们的时间精力岂不是都浪费了？

我们为什么要做接口测试呢？

1. 前端限制逻辑，导致无法cover到后端的逻辑
2. 安全性有一定保障
3. 构造异常测试
4. 接口测试case用于回归，提升测试效率

接口测试case应用

1. 线上/线下的回归，一般线上回归case关注核心功能就够了，无需全量，新需求上线后自动触发。
2. 线下全量，加入到CI/CD流程中，作为提测的依据，一定程度上可避免因测试范围不准确而造成的漏测。

做接口测试关注的指标？

1. 接口覆盖率
2. case通过率
3. case误报率
4. 还可以增加新增case数等指标

至此TestNG系列就完结了，还有许多功能，等待大家自己去使用和挖掘。
感兴趣可以去我的github上下载代码，记得star哦～
https://github.com/bingerlby/testngpro