十年经验大牛浅谈自动化测试与测试用例的编写

Posted 2021-02-20

今天聊得是自动化测试与测试用例的编写，首先来聊一聊框架(Framework)。

框架是工程学上一个非常重要的概念。在计算机和软件工程领域，我们可以轻松列举出一些耳熟能详的框架。例如，Windows软件开发框架.NET，Web开发框架React JS、 Angular JS、Python Django、Ruby on Rails, 机器学习框架TensorFlow、Caffe，等。

　　那么，什么是一般意义上的框架呢？首先，框架是一个“架子”。这个架子能够完成领域内基础的、重要的功能。基于这个已有的架子，我们可以将重心放在面向业务的开发上。其次，框架也是一个“框框”。“框框”为我们设置了有形和无形的约束。所谓有形的约束，就是我们的开发工作需要符合框架的定义、与框架兼容。所谓无形的约束，就是我们的开发工作需要承受框架的缺点和不足(毕竟，没有十全十美的框架)。

回到测试自动化领域，什么是测试自动化框架呢？顾名思义，就是用于测试自动化的框架。具体来说，它提供了自动化测试用例编写、自动化测试用例执行、自动化测试报告生成等基础功能。我们只需要基于这个框架，完成和业务高度相关的测试用例设计和实现即可。另外，框架会为我们处理好复杂度与扩展性的问题，我们无需为此操心。

　　相比手动测试，自动化测试更加注重框架。毕竟，自动化测试本质上也是一种软件开发活动，也需要适当的软件框架。在多个项目中，使用一致的自动化测试框架，可以让复用自动化测试成为可能。

　　在某一领域，经常存在着多种类型的框架。测试自动化也不例外。那么，有哪些种类的测试自动化框架呢？它们各自有什么特点？

　　线性框架：又指录制和回放(play and record)框架。在这种框架中，测试人员通常不需要编写测试脚本，只需要录制某一次测试的过程(自动生成测试脚本)，然后在后续的测试中回放这次录制的结果(执行测试脚本)即可。线性框架最大的好处是无须手动编写测试代码，因此门槛较低、易于上手。然而线性框架的不足之处也很明显：录制的脚本是固定的(hardcode)。这意味着，当应用发生微小变化时，上一次录制的脚本可能就无法使用了，需要重新录制(rework)，从而产生大量的后期维护成本。

　　数据驱动框架：在数据驱动框架中，测试数据和测试脚本是分离的。在许多测试场景中，需要使用不同的测试数据多次测试同一功能或特性。如果测试数据是hardcode进测试脚本的，那么每更换一次测试数据都需要修改测试脚本。这是很大的工作量。此时，可以使用数据驱动框架。具体来说，测试脚本是固定的，而测试数据可以从外部的数据文件，以Excel、CSV、SQL等形式作为参数传入测试脚本。这样，我们只需要维护一份脚本和一份数据文件即可。总体来说，这种框架最大的好处就是易于维护。但是识别与格式化数据、编写通用测试脚本等需要花费技术和时间。

关键词驱动框架：在关键词驱动框架中，测试数据和测试脚本也是分离的。不同的是，这个框架更进一步地将测试脚本中的通用功能剥离出来，形成关键词(keyword)。测试脚本本质上就是对一系列通用的或者自定义的关键词的调用。这样做的好处是关键词可以在多个测试中复用，并且测试脚本更加易于维护。不过，实现这样一个框架并非易事。

　　除了上述三种类型，测试自动化框架还有：模块化框架、库结构框架、混合框架等类型。

　　需要指出的是，业界已经有了实现上述各种测试自动化框架的工具。通常来说，我们并不需要重新发明一个新的框架，而是基于已有的框架完成自动化测试工作。那么，面对一个新的自动化测试框架，如何着手工作呢？笔者认为，我们应该聚焦在以下四个问题上。

如何生成测试用例？不同的框架，生成测试用例的方法不一样。对于线性框架来说，无须编写脚本，只需要点击预设的按钮就能够生成测试用例；对于多数框架来说，生成测试用例需要编程。当然，不同框架使用的编程语言、编程风格有差异。对于Selenium框架来说，使用的是通用编程语言Java；对于Robot Framework来说，使用的是其专用的Robot Framework编程语言。一般来说，使用框架编程的过程很多时候就是调用库接口的过程。因此作为前提，在编写用例之前，我们需要熟悉框架提供的库的种类和功能，以及这些库所提供的API的使用方法。

　如何执行测试用例？当测试用例完成之后，我们需要运行测试用例。自动化测试是通过GUI图形界面来触发，还是通过CLI命令触发，这因框架而异。当然，仅仅知道如何触发测试是不够的。我们通常有更多的需求。例如，如何选择性地执行满足特定条件的测试用例子集？如何设置全局的执行参数(超时时间、日志路径、报告形式、...)？如何动态地给测试用例集传入参数？一般来说，一个完整的框架需要提供足够多的控制选项，从而让我们根据需求定制执行测试的方式。以Robot Framework为例，其执行用例的命令具有30多个不同的选项。这提供了足够的自由度和一些非常棒的功能。例如其dryrun选项，可以让我们在不实际执行用例的情况下，快速检查出测试用例中参数不匹配、语法不正确、关键词找不到、库导入失败等错误，非常实用。

如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加软件测试交流：1085991341，还会有同行一起技术交流。

　如何检查测试结果？测试执行结束之后，我们需要关注测试结果。不同的框架会以不同形式提供测试结果。例如，测试结果既能以控制台日志的形式体现、也能够以图表和报告的形式体现。根据测试结果，我们可以很容易地了解测试的执行情况，包括测试的成功/失败情况、测试的整体/局部用时等。当测试失败时，我们尤其需要关注测试失败的具体情况。通常，我们关心失败是由于我们使用框架的方法不当造成的，还是由于被测软件的质量问题。这一点，只能通过检查和分析测试结果得到。

　如何扩展测试框架？一般来说，框架只是提供了最基本的功能。很多时候，框架并不能直接满足自动化测试的需求。这时我们可以寻求第三方的、与框架本身兼容的库或者插件。如果第三方工具不能满足我们的需求，我们就需要开发自己的库和工具。例如，对于HTTP、SSH等公有协议，我们很容易在网络上找到某个框架的第三方库；而对于只用于公司产品的私有协议，我们通常无法找到第三方库，只能自己开发。自己开发时，需要注意的是要遵从框架的规范，使得开发出的库能够与框架无缝兼容。

　　我们已经强调过，选择了一个框架，在享受其好处时，也不得不承受其不足。如果我们的关键需求受制于框架，并且框架也不容易扩展，那么我们就可能需要开发自己的框架。这是一件投入较大的事情。

以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。