本文已参与掘金创作者训练营第三期「高产更文」赛道
1.写自动化case真的很简单吗？
最近在于一些同事和老同事沟通时，大家都会有意无意聊起一些工作进展，自动化作为测试工作最最基本的建设，被聊到的频率比较高，但是最近，不知道为什么，貌似有了“孕妇效应”，大家都不约而同认为：
- 写自动化case太简单了，太没挑战了
- 写自动化case太无聊了
- 写自动化case无法让自己获得更多成长 不可否认有些优秀同事确实非常精通，但是对于很多年轻同事，在更深一层问到一些细节，比如自动化收益如何？稳定性怎么样？的问题，大家马上开始了第二轮吐槽：
- 人力不足，自动化跟不上需求迭代
- 自动化case经常因为缺乏维护，变得不稳定
- RD因为case不稳定，经常告状
- case执行总是不稳定，环境太差了 因此，写自动化case真的有这么简单吗？这些问题，都是外部原因吗？我不这样认为。
2.什么是好的自动化case
这个标题有点标题党，准确讲，正确的问题是什么样的框架是好的自动化框架。写自动化的过程也是开发的过程，既然是开发，衡量代码质量的标准完全适用自动化：
- 高可扩展性
- 良好的抽象能力：很多业务比较庞杂，需要对业务做合理抽象
- 良好的用例管理能力：常用的测试框架基本都满足这一条（比如：pytest）
- 高可维护性
3.自动化case常见错误
- 不用框架用脚本：在这里不讨论炫技或者调研不充分的问题，总之，业内自动化测试框架几乎每个语言都有，而且功能强大，语言本身适配性非常好，如果自己写框架，不是明智之举。
- case就要粒粒分明：多个case通常都有一些共同的逻辑，比如一些前置准备等，不做任何抽象，每次写case都要重新写，不仅仅会导致维护成本高、容错性低，还会使得case臃肿，易用性非常差。
- 数据准备与用例混淆：通常case能够执行都有一些前置条件，我们叫做数据准备阶段（是泛指），数据准备失败并不是用例执行失败，这一点很重要。
- 业务与框架强耦合
- 业务逻辑与断言强耦合
- 测试数据缺乏管理
- 代码风格问题：比如常量hard code
每一件看上去很简单的事情，背后都有很多细节，切忌眼高手低，共勉！
