流量回放和自动化测试的区别
使用线上的真实数据
适合高并发场景
对目标服务器无干扰
编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高
构造压测模拟数据麻烦
写接口：由于回放后对写接口的操作，可能会产生脏数据，这些还依赖于业务侧进行相应的脏数据过滤，或者对写接口的回放操作进行必要的转发，鉴于以上问题的风险，写接口的回放操作平台还不能很好的支持，这也是后续我们需要持续改进的地方。
在日常的测试工作中我们或多或少总会遇到下列问题：
服务架构升级或重构，需要验证原始接口逻辑，对原有的一堆接口做回归
对于业务逻辑复杂的场景，每个迭代版本都需要大量的时间用于回归测试
编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高
构造压测模拟数据麻烦
自动化测试场景和局限性
据上面的描述，你就不难推导出自动化测试适用的测试场景了：
回归测试。每一次应用发布，都伴随着一次回归测试。对于重复性的工作，机器显然更适合。
兼容性测试。不管是Web测试，还是App测试，兼容性测试都是必不可少的一环。以Web测试为例，同样的测试用例，需要在不同的浏览器上分别运行一遍，这对测试人员而言不可谓不是一种折磨。
大规模测试。如果一次测试涉及的测试用例过多(比如100+)，功能测试难免会有遗漏或者重复，而自动化测试可以轻松确保一个不少，一个也不多。
自动化测试也不是万能的，再来看一下它的局限所在：
不低的技术门槛。不论是使用哪种自动化测试框架，对于测试人员而言，都存在一定的技术门槛，一般至少需要学习并掌握一门编程语言。
可观的开发成本和维护成本。跟任何程序一样，无论是编写自动化测试脚本，还是在需求变化时修改脚本，都需要花费大量的时间。
需求要稳定。自动化测试的前提是测试用例要稳定，而测试用例稳定的前提是需求要稳定。对于临时的或者说一次性的需求，自动化测试往往是得不偿失的。
应用周期长。应用的生命周期越长，自动化测试节省的时间越多，带来的价值也越大。
应该说，功能测试是自动化测试的基础，自动化测试是功能测试的补充，两者相互依赖，又相互促进。测试人员两手都要抓，两手都要硬。
【免责声明】本文系转载，文章来源于公众号：码同学软件测试。转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与联系我们，我们会予以更改或删除相关文章，以保证您的权益!
|
