自动化测试方法

摘 要2015 年在上海东方明珠新媒体股份有限公司，在自动化测试中由于每次修改需求都要相对应的修改自动化测试脚本，造成时间和人力上的浪费，迫切需要一种简单可行减少脚本的利用率方法来提高工作效率，因此想到通过控件ID与被测系统映射表中的映射关系、控件类型与被测系统映射表中的映射关系、控件类型与代码映射表中的映射关系来实现该想法。

【关键词】控件ID 映射关系 自动化测试

在自动化测试领域中，传统的自动化测试脚本的开发一般有两种方法。第一种方法是通过手工运行一次测试，同时使用自动化测试工具的录制功能，把所进行的操作记录下来，生成测试脚本。这种技术生成的脚本回放成功率比较低，后期维护也比较困难。第二种方法是编写测试框架，对测试需要的基础操作提供接口供调用，测试人员根据用例操作需求，手工编写调用接口的自动化测试脚本，这种方法对测试人员的代码水平要求很高。

目前自动化测试中，测试小组成员编写完用例以后，还需要脚本开发人员单独编写一条针对此用例的自动化测试脚本，然后使用自动化测试工具运行脚本进行测试。当测试用例变更后，还需要重新编写这条测试脚本，资源耗费比较大。测试用例和测试脚本之间的维护比较复杂。

1 实施过程

1.1 项目介绍

针对现有技术中的缺陷，本想法要解决的技术问题是：如何将测试用例自动地转化为自动化测试脚本，以减少自动化测试脚本的代码量、资源消耗及测试用例和测试脚本之间的维护。

为解决上述技术问题，我和小组人员不断的摸索以及通过实际工作中多次测试和联调，探索出一种只要被测产品中没有产生新的控件类型，就不需要修改自动化测试脚本的解决办法。通过在实际项目中多次试验，本控件类型在测试用例中可以任意制定被测产品的流程，不会局限某个系统、某个产品。

根据多次实验结果得出一种自动化测试方法，包括如下步骤：

步骤1：定义控件属性与预置测试脚本代码之间的对应关系。本环节是通过设置的相应的对应关系，在前期就降低控件的可变化性。

步骤2：读入测试用例的测试数据，其中，所述测试数据包括控件属性。

该数据从项目实际运营过程中获取，保证能够在测试过程中发现更多的问题，确保一旦正式后在实际运行过程中避免出现类似错误。

步骤3：针对读入的控制属性，查找到对应的预置测试脚本代码；大多数自动化测试并没有这一步骤，通过读入控件属性，可以降低代码的重复性，是本设计特有的环节。

步骤4：根据预置测试脚本代码形成自动化测试脚本代码；

步骤5：将预置测试脚本代码添加到编写的自动化测试代码框架中，形成自动化测试脚本代码，执行自动化测试脚本代码，其中，自动化测试脚本代码用于模拟手动执行测试用例中各个控件类型的动作。

以上二分部主要由软件自动完成，无需手动进行，这也就是自动化测试的魅力所在，可以在很大程度上降低人力手动操作的时间，腾出更多时间去完成其他事情，增加工作效率。

2 附图说明

2.1 测试流程

为了将思想的其它特征、目的和优点更明显展示出来：通过阅读参照图1附图将会更直观。

2.2 解决办法

下面结合具体实施例对本方案进行详细说明。以下实施案例将有助于本领域的技术人员进一步理解本人的思想，但不以任何形式限制本思想。应当指出的是，对本领域的普通技术人员来说，在不脱离本方案构思的前提下，还可以做出若干变形和改进。

每个项目都需要人员的配合。需要需求人员、产品开发人员和自动化测试脚本代码开发人员共同配合，产生控件ID与被测系统映射表、控件类型与代码映射表，例如表1和表2所示，其中，控件ID与被测系统映射表记录了控件名称、测试用例中控件ID、被测系统中的控件ID之间的映射关系，控件类型与代码映射表记录了控件类型、测试用例中控件类型、被测产品中控件类型、测试脚本中控件类型的映射关系。

本方案的方法和系统可以连接测试用例管理工具，读取测试用例，通过解析模块解析测试用例信息，生成脚本可读的信息，然后根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块，最后确定被测模块；我的主要想法还是根据测试用例中的控件类型在控件类型与代码映射表中查找对应的测试脚本代码，执行自动化测试脚本来最终产生测试结果。具体步骤如图1所示，包括：

步骤1：我们要先读取用户编写的测试用例，例如可以连接测试用例管理工具，从存储有用户编写测试用例的测试用例管理工具中读取，测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，测试用例中的控件ID与被测系统的控件ID一致。

步骤2：解析测试用例信息，生成脚本可读的信息。

步骤3：根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块。具体地，根据测试用例中的控件ID，在控件ID与被测系统映射表中，首先查找到对应的被测系统中的控件ID，然后根据该被测系统中的控件ID再查找到对应的被测模块，其中，所述被测模块是被测系统的某个测试单元，例如，一个文本框、一个多选框、一个单选框等。

本组成员在项目中反复实践发现了一致性的关键点。目前很多自动化测试都是由于忽略了一致性才导致脚本可用性降低从而人为的增加了测试的工作量，说是实现了自动化测试，反而却是增加成本。

步骤4：根据测试用例中的控件类型在控件类型与代码映射表中查找对应的自动化测试脚本代码。具体为，根据测试用例中的控件类型，在控件类型与代码映射表中，首先查找到对应的测试脚本中控件类型，然后根据该测试脚本中控件类型再查找到对应的自动化测试脚本代码。

步骤5：执行步骤4的控件类型对应的自动化测试脚本代码，该自动化测试脚本代码用于模拟手动执行通过步骤3查找到的被测模块的控件类型的动作。

步骤6：输出自动化测试脚本代码产生的实际结果。

步骤7：比较自动化测试脚本代码产生的实际结果与测试用例中的预期结果是否一致，如果一致说明测试通过；如果不一致说明测试不通，并且指出不通过的原因

使用本方案的方法，即使当测试用例变更后，测试人员只需按照关键字规范，手工修改一次测试用例即可。

下面对本方案的一个优选具体实施方式进行描述，在本具体实施方式中，包括以下步骤：

Step1：需求人员、产品开发人员和自动化测试脚本代码开发人员共同定义好被测产品中控件类型与控件的ID，产生相应的映射表，标准控件的使用标准定义。

共同定义是非常重要的，针对不同项目，前期应把控件类型和id定义成标准，并在开发过程中使用统一标准。

Step2：产品开发人员和自动化测试脚本代码开发人员根据映射表为被测产品的每个控件设置控件类型、控件ID。

Step3：定义测试用例内容以及格式；测试用例内容包含：控件类型、控件ID等；测试用例的格式如：（系统模块名称，控件类型，控件ID，输入内容，操作命令，预期输出，时间输出，测试结果）。

Step4：执行自动化测试脚本代码，包括如下子步骤：

Step4.1：读取用户编写的测试用例，所述测试用例中的控件类型和操作命令、自动化测试脚本中控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，测试用例中的控件ID与被测系统的控件ID一致。例如，可以首先连接存储有用户编写的测试用例的测试用例管理工具，然后从测试用例管理工具中读取测试用例。

其中，Step4是自动化测试一个控件过程，在自动化测试脚本代码中，分别实现模拟手动执行每个控件类型的动作，并且使每一个控件类型的动作成为一个独立的模块，根据控件类型可以查找到对应的测试脚本代码。脚本代码可以重复利用，只要被测产品中没有产生新的控件类型，就不需要修改自动化测试脚本。测试用例中可以任意制定被测产品的流程，不会局限某个系统、某个产品。

其实优选具体实施方式和之前介绍的没什么区别，这里要说的是不管哪种方案要强调的是测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，这个是本文的重点，也是提出本方法的关键。

3 结论

根据本方案提供的一种自动化测试系统，所述自动化测试系统用于执行上述的自动化测试方法。

通过控件ID与被测系统映射表中的映射关系、控件类型与被测系统映射表中的映射关系、控件类型与代码映射表中的映射关系这种方法实现了测试用例到自动化测试脚本的自动转化，进而提高代码重复利用率、缩小了代码量、提高了自动化测试的效率，降低了资源消耗和维护复杂度，达到了前期需要目的。该方法不局限于某一个系统，要做的就是一致性，而该一致性需要团队的合作。