浅谈自动化测试
文章目录
金融交易系统在测试上的投入，远超其他系统，繁琐的测试步骤重复进行，ROI 太低。随着项目和人员的更替，不可避免引入更多的不可控因素，常见的情况，修改的是A接口输出的某个字段，却影响了B接口的结果，每次版本发布，风险也在积累。
理论知识
- 如何衡量自动化的价值？
一个自动化测试案例ROI = （手工运行时间）*（运行次数）/ (开发成本 + 维护成本)
- 哪些功能需要做自动化测试？
用户常用的功能，不会经常改变的功能。针对此类型的接口编写自动化测试代码，收益最高。
- 为什么选择这个时间点推动自动化测试？
临近项目上线，肯定不合适，远水解不了近渴，自动化属于长期收益模型。项目已经在生产环境上线，进入稳定发布周期，此时最为合适。
框架的选择
缺乏相关实践经验的情况下，拿到自动化测试这么一个任务，常规开局：打开搜索引擎，寻找当前系统技术栈能用上的工具和框架，过一遍使用手册，开工大吉。能立马找个合适的工具，恭喜你，完美开局。
先说一声我错了，翻查了相关的资料，不是说没有，而是框架本身太复杂了，部署占用的资源也过多。小白入门需要的是小巧的，精简的，咨询测试组的同事，提到了 Python 自建框架，简单来说就是用现有的单元测试框架，封装成自动测试框架。
参考此项目的设计思路：https://github.com/wintests/pytestDemo
为什么需要框架？
服务有多个不同的部署环境，开发环境、测试环境、线上测试环境，框架的作用在于做一层剥离，测试案例和数据进行分离，按照不同的环境配置不同的案例数据，当然也支持公用的数据。
核心的逻辑都是为了提高自动化的利用率。场景再复杂一些，不同环境之间的数据就是不通的，完全没有任何关系，配置案例数据的时候，增加 label 标签即可，指定当前数据支持的环境。