MOCKService与回放技术学习

利用Mock与回放技术助力自动化回归

持续交付中的测试难点其实，对于持续交付中的测试来说，自动化回归测试是不可或缺的，占了很大的测试比重。而进行自动化回归测试，就始终会有“三座大山”横在你面前。
“第一座大山”：测试数据的准备和清理。通常情况下，回归测试的用例是可以复用的，所以比较固定，结果校验也比较确定。而如果要实现回归测试的自动化，就需要保证每次测试时的初始数据尽量一致，以确保测试脚本可复用。如果每次的数据都不同，那么每次的测试结果也会受到影响。为了做到测试结果的可信赖，就有两种方法：一种是，每次全新的测试都使用全新初始化数据；另一种是，在测试完成后，清除变更数据，将数据还原。但是，这两种方法的实现，都比较麻烦，而且很容易出错。
“第二座大山”：分布式系统的依赖。分布式系统因为有服务依赖的问题，所以进行一些回归测试时，也会存在依赖的问题。这个问题，在持续交付中比较难解决：单元测试时要面对两难选择，测依赖还是不测依赖；集成测试时，如何保证依赖服务的稳定性，或者说排除由稳定性带来的干扰，所以到底是依赖服务的问题，还是被测服务的问题很难确定；真实的业务系统中，往往还存在多层依赖的问题，你还要想办法解决被测应用依赖的服务的依赖服务。我的天呢，“这座大山”简直难以翻越。
“第三座大山”：测试用例的高度仿真。如何才能模拟出和用户一样的场景，一直困扰着我们。如果我们的回归测试不是自己设计的假想用例，而是真实用户在生产环境中曾经发生过的实际用例的话，那么肯定可以取得更好的回归测试效果。那么，有没有什么办法或技术能够帮