是不是可以这么理解：
API 调用和数据库操作创建，本质上都是操作数据库，不过 API 调用是做了一层封装，保证了操作的可控性（避免胡乱写数据库操作语句）。
实时创建数据和事先创建测试数据，其实也是不冲突的，我理解他俩并不是互斥的关系，而是互为补充，在 API 调用逻辑内部，先检查数据库中是否存在需要的测试数据，存在则继续，不存在则创建即可。
欢迎沟通交流，公众号「sylan215」

小公司，没有做GUI自动化测试，更无从测试数据的准备谈起，只能自己摸索，不断尝试，总结更多的实践经验。

我们是out the box 脚本预制 然后on the fly 接口调用，API测试，经常因为接口变动大，数据库也有变化 这样脚本经常容易改动 有什么方法可以设置变量方面，灵活性的脚本？

我们的产品有一个best practice的包，里面包含了很多数据，对测试非常有用

最近几张讲的GUI测试，听起来主要是基于浏览器的业务测试，对于APP的测试如何应用

我的做法是备份还原整个数据库😂，当然也是看业务场景的

老师讲的很清楚～～我有个小问题想请教一下：自动化做完 要进行数据还原，老师有没有什么数据还原的方法推荐呢？比如数据库快照什么的。或者说有哪些类型的自动化测试根本不用还原？

老师，我以前做过一个项目，测试数据我们直接copy一些现网数据来创造数据，尤其是性能测试高并发的时候，请问这个是不是一种好方法呢？

并不矛盾，GUI自动化测试是基于功能稳定的情况下进行的！

数据库监控工具有推荐的吗

1，本文中需要注意的是，这两种思路的前提都是，假定产品功能正确，否则就会出现“一错到底”的尴尬局面。一一－前题是产品功能正确，测试的目的是找到产品中的Bug，没觉得这有矛盾吗？
2，在自动化测试中，teatdown方法中往往作的最重要的事情是清除脏数据。但是自动化测试往往出现的状况是测试程序在测试过程中遇到问题，挂掉了，这样造成的结果是执行不了teatdown方法中清除脏数据的操作，从而影响其他用例的运行。我一般Have to在所有测试开始(setup方法)一开始都清除所有脏数据，保证此测试用例在干净环境下运行。请问作者没有别的好办法。

hui测试的两类数据感觉没有什么区别，老师能详细说下嘛

打卡15

在准备测试数据中，我觉得应该尽量减少第三方的依赖，避免脚本的不稳定性，也就是说能预先设定的就先考虑，不能的再采取实时产生的方式