自动化测试框架的选用
一、自动化测试
众所周知，软件测试按照不同的分类方式，可以划分成多种。如果按照是否执行手工划分，可划分为手工测试、自动化测试。自动化测试进一步细分的话，从软件开发周期的角度可分为：单元自动化测试、接口自动化测试、UI自动化测试（web自动化、移动端自动化）；从测试目的的角度可划分为：功能自动化测试、性能自动化测试、安全自动化测试。
二、预期收益
维护自动化会花费一定量的时间及人力成本，预期换来的收益效果是什么？
1.冒烟准入：自动化测试结果，作为准入冒烟case的参照标准，以确保老业务功能的畅通
2.全量回归：协助上线前的全量回归，提高测试效率，节约手工测试时间、人力成本
3.生产回归：线上环境全功能回归，监控线上功能畅通
4.额外收益：测试环境执行自动化测试，检测排查测试环境的问题
三、自动化适用领域
切记：不是所有的系统都适合做自动化测试！！！
如果不能做自动化测试的系统，没必要硬上，毕竟强扭的瓜不甜，否则有可能竹篮打水一场空~
什么样的系统适合自动化测试呢？且看下图所示：
项目中，接口测试的ROI（产出投入比）要比UI测试高，因为接口层相比于UI层的稳定性高、可复用性好、存在周期长。
四、现有框架
1.无需写代码的自动化框架
- JMeter + Ant+ Jenkins
3.需写代码的自动化框架
- python版：requests + unittest
- java版：httpclient + testng
4.其他框架：
- pytest版接口自动化测试框架
- Robot framework接口、ui自动化测试框架
- web端ui自动化测试框架
- app端ui自动化测试框架
- 性能自动化测试框架
五、框架对比
RF框架：
- 属于半懂代码，懂接口的结构体就易上手的测试框架，测试人员使用成本低
- 关键字驱动测试，扩展性高
- 功能完善，支持跨平台
- 有界面，交互体验好
- 可生成测试报告及清晰的Log报告
- 用例编写类似填写Excel表格的易上手，但操作起来并不够友好
- 尤业务层系统的接口自动化测试，参数设置过多，业务逻辑复杂，响应结果校验偏多，设置编写会存在诸多的填写工作量
TestNG框架：
- 需懂代码的测试框架，对于测试人员要求高一些
- 涵盖单元测试、功能测试、集成测试等，覆盖面广
- 基于Annotation（注解）机制，测试方法更灵活
- 支持多线程，效率高
- 自动生成html、xml格式的测试报告
- 可以测试依赖性，又可以任意顺序运行测试用例
六、框架选择
公司项目采用的微服务架构体系，后端方向主要由java代码实现，对于搞起自动化方面，测试团队结合自身状况及项目业务状况，对于框架选择做了如下考量：
- 业务版本迭代快，导致UI层面稳定性差、变化快、可复用场景不多，暂不考虑UI自动化测试
- 业务系统主要对外输出接口，考虑到整体测试人员的能力水平以及易于上手、易用性方面，进行接口自动化测试优选RF框架
- 中台系统逻辑较为复杂、场景较多，为了提高测试颗粒度，进行单元自动化测试优选testNG框架