脚本模板 :如何提高自动化测试的稳定性和可维护性？

抖音真文案网 2022年06月30日 22:18 137 admin

大致如果现在已经有了自动化测试所应用的框架或者用例，遇到了稳定性或可维护性的问题，这个优化成本相对很高，因为此时考虑这个问题有些滞后了，要想提高稳定性和可维护性的建议，需要提供更详细的信息，比如现有的自动化测试框架设计及系统业务大致场景，否则不知从何说起。

若此时还没有开展自动化测试，或者准备开展自动化测试，这里可以提一些建议，题主可视情况采纳。

首先要对自动化测试形成正确的认知：自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试（也包含手工测试）。自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。不是为了自动化而自动化，而是为了实现一套解决方案来解决问题从而开展某种自动化，肯定是解决某些测试过程中的问题而引入自动化测试。

其次需要考虑系统或业务功能是否适合开展自动化测试IT行业甚至其它行业的产品都是能够做到自动化的，所以是否自动化不是能与不能的问题，而是是否存在合适的时间或阶段以及合适方式去做的问题，实施自动化测试之前需要对产品开发过程进行分析，通常需要同时满足以下条件：

软件需求变动不频繁(超过10%的变动是频繁变动，当然10%不是一个定值)项目周期足够长自动化测试用例可重复使用

目前主流的自动化测试框架或工具首先我们需要明白自动化测试框架更倾向于一种设计思想，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。

录制回放测试框架

录制回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

优点：对测试人员测试开发能力要求最低，通过录制就可以得到所需脚本。缺点：一般不具有逻辑判断的能力，可维护性差，效率低。适应场景：不推荐，传统的UI自动化测试逐步弱化。关于U自动化，一定要清楚被测系统是否满足开展自动化的条件，在被测系统变动频繁的项目中，开展UI自动化无疑是挖了一个很大的坑，其后期维护工作足以让大心疲惫，被迫放弃自动化测试。测试库构架框架(The Test Library Architecture Framework )

测试库构架框架的核心思想可以概括为系统功能操作和业务逻辑的解耦。将所有的针对测试系统支持的功能操作封装在测试库中，测试脚本调用测试库的同时传递外部的测试数据，测试库的编写由自动化测试发工程编写(可以不懂业务)，负责控件的变更和维护，测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑、测试数据的变更和维护。

优点：被测试系统无论是哪层发生变化(代码层或业务层等)，只需要相应的人员进行变更维护即可。缺点：变更引起的维护工作同时附加在自动化测试开发工程师与业务测试人员身上，维护代码建级大。适应场景：基于各种自动化开展方式(基于工具如Jemet或不基于工具的自研研发+持续集成)一般都会应用该框架。数据驱动的自动化测试框架( The Data-Driven Testing Framework )

数据驱动的核心思想可以概括为数据(测试数据、配置数据)与代码解耦。该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存代码，运行时脚本的输入直接从文件中读取，如此相同的脚本(代码模版)可以运行于不同的测试用例中，实现了代码与数据的分离。

优点：对于业务人员由面向代码的开发转换为面向配置的设计(参数组合设计)，降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试，实现了自动化代码不随用例的增长而增缺点：测试脚本的维护由自动化测试开发工程师负责，要求懂自动化编程和业务逻辑，初始测试脚本设计成本较大，具有一定局限性 (针对相同的测试内容并具有相同的测试逻辑).适用场景：更适应于测试内容测试逻相重复度高，被测对象对测试用例易扩展性、可复用性要求较高的场景。关键字或表驱动的自动化测试框架(The Keyword-Driven or Table-Driven Testing Framework )

关键字驱动是对数据驱动的逻相扩展，它的核心思想可以概括为数据代码流程(逻辑)解耦，同时完成了代码与测试描述(针对被测对象的测试描述)的映射。该框架的原理是基于数据驱动的基础上，完成了对被测对象的拆分、抽象、封装使之映射成个个“关键词” (测试描述)，编写测试用例时，仅需要对关键词进行组合，即可完成不同场景的测试用例开发。

优点:对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，实现了自动化代码不随用例的增长而增多。

缺点:对测试人员的测试开发能力以及业务了解程度要求很高。

适用场景:被测对象包含复杂业务流程(逻辑)，当然复杂的能做简单的更ok。

测试框架选择仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强，所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么，或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。

两个场景：

场景一:多维度的查询功能，类似于某宝商品的筛选查询。场景二:较为复杂的业务流程，类似于某逐级审批流程系统。思考:关于这两种场景，我们如何选择自动化测试框架(或工具) ?

场景一特点:类似于某宝WEB端，不同关键词(衣服、足球)的多维度(品牌、发货地)组合查询，查询逻辑单一、复用性强。推荐使用:测试库架构框架+数据驱动框架。场景二特点:类似于审批申请流程，包含复杂的业务逻辑和多用户角色。推荐使用:测试库构架框架+数据驱动框架(配置解耦）+关键词驱动框架

测试用例开发两个注意

规范性和契合性：开发规范性以及开发过程一定要与其自动化测试框架思想相契合，比加选择测试库构架框架，那么在用倒编写的时候，发现还有需要进行封装的功能操作时，需要在测试库中开发，在用例中调用，而不是随手在用例中进行开发。开发成本和维护成本：开发设计一定要考虑开发成本和维护成本问题，开发成本决定效率，维护成本决定这个自动化能否长明有效的运行下去，同时注意关于成本问题的解决思路是在对被则对象进行有效覆盖的前提下，通过框架设计和优化方案来降低成本，而不是靠少做一些做的粗一些来降低成本。

在自动化测试开展的过程中若注意上述的内容并加以实施，自动化测试的稳定性、可扩展性、可维护性可以得到进一步的保障。

若对你有帮助，点赞支持哦