流量回放和自动化测试的区别

流量回放和自动化测试的区别

1、使用线上的真实数据
2、适合高并发场景
3、对目标服务器无干扰
4、编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高
5、构造压测模拟数据麻烦

写接口：由于回放后对写接口的操作，可能会产生脏数据，这些还依赖于业务侧进行相应的脏数据过滤，或者对写接口的回放操作进行必要的转发，鉴于以上问题的风险，写接口的回放操作平台还不能很好的支持，这也是后续我们需要持续改进的地方。

在日常的测试工作中我们或多或少总会遇到下列问题：

1）服务架构升级或重构，需要验证原始接口逻辑，对原有的一堆接口做回归

2）对于业务逻辑复杂的场景，每个迭代版本都需要大量的时间用于回归测试

3）编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高

4）构造压测模拟数据麻烦

自动化测试场景

据上面的描述，你就不难推导出自动化测试适用的测试场景了：

回归测试。每一次应用发布，都伴随着一次回归测试。对于重复性的工作，机器显然更适合。
兼容性测试。不管是Web测试，还是App测试，兼容性测试都是必不可少的一环。以Web测试为例，同样的测试用例，需要在不同的浏览器上分别运行一遍，这对测试人员而言不可谓不是一种折磨。
大规模测试。如果一次测试涉及的测试用例过多（比如100+），功能测试难免会有遗漏或者重复，而自动化测试可以轻松确保一个不少，一个也不多。

自动化测试也不是万能的，再来看一下它的局限所在：

不低的技术门槛。不论是使用哪种自动化测试框架，对于测试人员而言，都存在一定的技术门槛，一般至少需要学习并掌握一门编程语言。
可观的开发成本和维护成本。跟任何程序一样，无论是编写自动化测试脚本，还是在需求变化时修改脚本，都需要花费大量的时间。
需求要稳定。自动化测试的前提是测试用例要稳定，而测试用例稳定的前提是需求要稳定。对于临时的或者说一次性的需求，自动化测试往往是得不偿失的。
应用周期长。应用的生命周期越长，自动化测试节省的时间越多，带来的价值也越大。
应该说，功能测试是自动化测试的基础，自动化测试是功能测试的补充，两者相互依赖，又相互促进。测试人员两手都要抓，两手都要硬。