覆盖将近的自动化测试是怎么样做到的
作者:网络转载 发布时间:[ 2017/7/3 11:30:09 ] 推荐标签:接口测试 自动化测试 函数
想写一篇自动化测试的总结给大家看看,但是又不知道从何说起,或许是感觉自己不成熟,不要误导了大家,但是看网上的文章一篇篇,反而动摇了很多人的心,觉得测试怎么怎么了,写写也很好,和大家交流交流,没准自己只是个井底之蛙。希望和同仁交流交流,成长自己,成长大家。
为什么要选择接口自动化测试?
敏捷开发,主要的问题来自于这个词,既然是敏捷开发,需要快速迭代,像我所在的这样做企业级产品的公司来说,客户需求为核心是不得不做的选择,定制化,快速功能交付,导致整个研发部门处于紧张、忙碌的状态,2周一交付,这么快速的企业产品迭代,由谁来保证其质量,如果只做手动测试,这时候开发任务已经由后端流转到前端,再抛bug回后端的话所造成的时间浪费和在需求之间交替带来的痛苦将会给产品毁灭性打击。
总结起来,这个产品:
1.企业级产品,持续交付,项目周期长
2.对接客户广泛,定制化需求多
3.交付周期短,2周一个迭代
这时候,自动化的API测试,给整个产品线吃了一颗定心丸,好处很明显:
1.持续的自动化集成测试保证质量
2.完善的接口检查保证接口及健壮性
3.保证基本功能的正确性和完整性
4.复杂的功能交互场景测试
5.接口的安全测试
换句话说,我的标题为什么是将近的覆盖率,是这个,我们做完了几乎所有的测试,所以,我们可以很自豪的说我们是保证产品稳定的定海神针。筛选用例由研发提交修改后自动冒烟,每天持续自动运行所有用例,这是质量的保证。所以,当研发一个八竿子打不着的功能提交正常,但是影响到了其他地方的用例,我们也能快速指出问题所在,这时候,是自豪。
这样的自动化测试看起来是完美的,但其实,对测试人员的要求比较高,比如,既然要覆盖所有场景,需要对产品、功能、用例编写过程非常精通,到什么程度呢?看到这里用例挂了,知道代码里是哪里出了问题,很多时候,我们自己找出问题让开发修改提交;再比如,要达到这样的覆盖率,需要能做到所有场景覆盖,不仅是写用例了,还需要巧妙的实现这个用例,自行编写函数库、windows脚本、linux脚本编写、sql脚本编写这些技能的熟悉。上面这些需要很长的时间来积淀,来改进,所以,在之前不久,我们自动化小组自行对测试架构进行重构以完善,这些东西不是一朝一夕的。
介绍下我们现在使用的测试框架,总结起来,好用实惠。
测试语言:python
测试框架:robotframework
纯粹的接口测试使用robotframework可以完美的完成,有python强大的库的支持,只需要内建库和自行编写的函数库可以了,加上持续集成,是质量的保证。关于python和robotframe有很多教程和书籍了,之后我把自己的总结也写出来。
然而,软件测试没有银弹,不可能有的覆盖率,用一句话来说,不管你采用什么样的测试方法、你的测试团队有多么强大、你在测试上投入了多少人力物力,测试中也会发生“黑天鹅”事件。在测试思维上的进步比会使用多少个工具要强的多,只是这样深耕在测试领域中不被人发觉,终也可能埋没了自己,那么我们要这样面对,让我们来改变测试,让测试思维改变我们自己。
相关推荐

更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11