自动化测试框架设计原则

易上手

自动化测试框架易上手体现在两点：

1. 框架知识的 「学习成本低」
2. 编写用例的 「操作步骤简单」。

由于自动化测试的目标仅仅是提升测试执行效率，而编写自动化测试用例也只是软件测试工作的一小部分。

如果为了该目标而开发的框架学习成本高，用例编写步骤复杂，会使得测试人员不得不投入更大精力在学习框架知识和配置用例步骤上。

这样不但会使测试工作本末倒置，也不利于降低自动化测试用例的边际成本，甚至会使测试人员对框架最终失去耐心。

易编写

用例编写主要包括业务步骤实现、测试断言和用例配置；自动化测试用例易编写体现在两点：

1. 「用例编写效率高」
2. 「用例编写灵活度高」。

写过自动化测试用例的同学应该都感受过用例写一天，执行一分钟的痛苦。

由于规范的用例需要清晰地写明测试步骤和繁杂的预期结果（或许还得写上前提条件），导致编写过程漫长而痛苦。

自动化测试用例其实也是如此，有些步骤或预期结果过多的用例，代码或脚本量必然不小。

在尽可能重用已有方法的同时，也必须要考虑如何偷懒（少敲击几下键盘或点击几次鼠标，当然仅仅几次肯定不够）。

而想要保证用例编写灵活度，则必须需保证业务步骤实现不受约束或少受约束，测试断言足够灵活多样不受限制。

个人认为：纯代码+IDE 的模式无疑是实现测试用例易编写的最佳实践。

纯代码可以让我们在非常有限的约束下（主要是团队的代码规范）实现业务步骤和测试断言；成熟的 IDE 可以为我们带来智能提示、代码补全、自动跳转、动态模板等可以极大提升工作效率的工具，当然，这也依赖于我们自己能善于利用。

易维护

自动化测试工程易维护体现在三点：

1. 「模块化程度高」
2. 「代码可重用性强」
3. 「测试用例易调试」

模块化工作本质上就是分类工作，让不同的业务、功能或操作可分门别类地独立放置在不同的区域，并且还需要设置有效的隔离机制，保证区域间不产生相互影响。

支持关键字驱动，将有效提高测试代码的模块化程度。在此基础上可通过实现更好的设计模式，来进一步提高测试用例代码模块化程度。

在增强代码可重用性方面，数据驱动+关键字驱动的用例编写风格几乎可以认为是版本答案。如果还能支持测试代码（主要指为自动化测试用例代码）重用于其它测试场景，代码可重用性将得到数倍提升。

测试用例想要容易调试，本地执行、自定义日志输出，断点调试则是框架必须要考虑支持的功能。