自动化测试框架设计的一低二高三容易

　　一、低

　　框架学习成本低

　　软件测试工作的核心是测试策略和测试设计，而自动化测试的目标重点在于提升测试执行效率。为了实现该目标而设计的自动化测试框架如果过于复杂，从而导致学习成本过高，这就本末倒置了。

　　二、高

　　测试用例可重用程度高

　　测试用例天然具有较高的重复性。比如同一个功能通常会有多种不同的场景，不同的场景也可能会有相同的预期结果。这就要求测试框架需要为这种重复性提供良好的解决方案，从框架层面上支持用例的高可重用。支持例如数据驱动风格的测试用例，是一个很好的实践。另外，纯代码的方式也会让我们可以十分方便地将某些公用代码或方法独立出来以供调用。

　　测试用例编写灵活性高

　　测试用例的验证点及验证方式具有多样性。简单的仅涉及字符串或数据的比对，稍微复杂的可能涉及到嵌套数据类型的比对，更复杂还可能是图片或文件的比对，等等。这要求自动化测试框架在验证方式上，不能仅实现呆板的固定类型的数据比较，在验证方式上一定是开放式的，可支持自行拓展。

　　三、容易

　　测试用例容易编写

　　写过测试用例的同学应该都感受过用例写一天，执行两小时的痛苦。由于规范的用例需要清晰地写明测试步骤和繁杂的预期结果，或许还得写上前提条件，导致编写过程漫长而痛苦。自动化测试用例其实也是如此，有些步骤或预期结果过多的用例，代码或脚本量必然不小。在尽可能复用测试用例的同时，也必须要考虑如何偷懒(少敲击几下键盘或点击几次鼠标，当然仅仅几次肯定不够)。个人认为，纯代码+IDE是实现测试用例易编写的最佳实践，当然这需要我们善于利用 IDE 的各种功能，如智能提示、代码补全、动态模板等。

　　测试用例容易调试

　　在实践中，我们可以深切感受到自动化测试用例在前期的执行是很容易失败的。如果每次失败，我们都需要从头再执行一遍用例的话，调试起来就必然效率低下。尤其是遇到长耗时的测试用例。为了让测试用例更容易调试，支持单测试步骤执行是必不可少的，这方面，关键字驱动的用例风格是极佳的选择。另外，能让用户进行灵活详尽的日志输出的能力也是不可或缺的。

　　测试用例容易维护

　　在实现了自动化测试用例的高可重用和易调试后，自动化测试用例也就具备了一定的易维护性。在上述基础上，还需要对自动化测试用例或代码的结构进行合理的设计，降低耦合程度，使之尽可能地模块化。1-N-1 的设计模式是一个非常好的实践。我们可以根据业务条线或系统模块将测试代码分割成多个 N，这个 N 既可以表示为一个文件，也可以表示为一个文件夹甚至是一个独立的项目。再通过后一个 1 就可以实现灵活且彻底的模块隔离。

　　以上内容为大家介绍了自动化测试框架设计的一低二高三容易，希望对大家有所帮助，如果想要了解更多接口自动化测试相关知识，请关注多测师。https://www.aichudan.com/xwzx/