QTP/UFT（二）：自动化测试脚本编写方法

2021.04.24

 

自动化测试方案选取时需考虑的因素（康康就行，并不是很重要）

1. 项目的影响：自动化测试能否对项目进度、测试覆盖率、风险有积极的作用，或者让开发更敏捷
2. 复杂度：自动化是否容易实现，包括数据和其他环境的影响。

 

自动化测试在构建时有一个较为麻烦的事情——数据，它需要大量的数据，而且要在自动化测试之前开始做好。与手工测试在造数据的点上不太一样。

比如：往一个部门里面加人，如果是手工测试，在跑用例过程中或者跑之前加都行（跑之前再加人也赶趟，或者做一条加一个做一条加一个也不是不可）。但是做自动化测试就必须要求你，最好是在跑自动化测试之前，先把要加的数据一股脑全加进去（加，都可以加）。因为自动化测试不希望跑一跑停一停，而是想达到一个一鼓作气，一口气跑下去的效果。因此自动化测试需要在开始之前构造相应的大量的测试数据。

1. 时间：自动化测试的实现需要多少时间

打个比方：如果做的自动化测试比手工测试花的时间还长（一般很少出现这种可能）。那这自动化测试就没意义了，可以选择丢弃。因为本来目的既是节省时间，提高效率。

1. 早起需求和代码的稳定性：需求或早期的代码是否能证明是在一定范围内变化的

假如说，需求与代码还在变化过程中，一般不建议开展自动化测试。如果实在要开展，需求与代码的变化一定要在一定范围内，不能影响全局，然后我们可以去测试没有变化的部分（应该说是没有被变化的部分所影响的未变化部分）。有变化的部分就先按兵不动，不然很容易GG。

1. 编护工作量：代码是否能长期保持相对稳定？功能特性是否会进化

指的是相应的代码在长期的过程中是否能够保持稳定，编码的维护过程中这个特性是否会发生变化，如果都为否定答案，则并不建议开展自动化方案。

1. 覆盖率：自动化测试能否覆盖程序的关键特性和功能

取决于脚本的设计。

1. 资源：测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动化测试
2. 自动化测试的执行：负责执行自动化测试的小组是否拥有足够的技能和时间去运行自动化测试

 

在进行自动化测试前需要考虑以上因素，如果得到的为良性答案，则可以开始考虑采用何种自动化测试方案，如果得到的为劣性答案，则需要考虑是不是要使用自动化测试方法了。

 

自动化测试脚本编写方法

前言：

在了解自动化测试时，都或多或少会看到自动化测试的框架。所谓自动化测试的框架，一般情况下有三个相应的组成部分：①工具本身；②自动化测试的脚本（最重要的部分）；③被测软件。

• 工具本身：用啥工具，一般为QTP/UFT和selenium，不建议掺和着用，一是因为两种都熟练的人群较少，二是采集数据和分析结果具有一定差异性。需要注意的是工具决定脚本。
• 自动化测试的脚本：不一样的工具，所用的脚本就会不一样。

何为脚本：用例（一种情况，输入啥而获得啥输出）+数据+代码（UFT使用VB；Selenium使用java/python）

• 被测软件：有占比，但没那么重要，pc端上，要么是B/S要么是C/S，而B/S或者C/S会反过来决定使用的工具。比如说selenium在做C/S测试时不太好用，而QTP早期便是做C/S测试的，选谁一目了然（）。

注意：以下的脚本编写方法是从最不适用最不科学到最科学的一个演化。真正需要记的是最后一个。

 

线性脚本的编写方法

1. 一种非结构化的编程方式 Y
2. 测试用例由脚本定义
3. 非常低的开发成本
4. 测试人员所需要的编程方面技巧几乎可以忽略
5. 不需要计划、设计
6. 测试数据在脚本中是硬编码的 Y
7. 脚本会很脆弱，因此维护成本很高
8. 没有公用的脚本，因此可能造成重复劳动

线性可以通俗的理解：只能往一个方向走，从前到后或者从后到前，不能转弯~~

硬编码说白了就是录什么就放什么，不能改，或者说不能很灵活的改动。

例子：比如说磁带，从头放到尾，不能跳着放，快进也是线性操作。

 

结构化脚本的编写方法

1. 结构化的脚本编写方法 Y（引入结构化语句）
2. 测试用例在脚本中定义
3. 编程的成本要比线性脚本编写方法略高一点
4. 需要测试员的调整编码技巧
5. 需要某种程度上的计划、设计
6. 测试数据也是在脚本中被硬编码 Y
7. 因为相对稳定一点，所以需要相对少的脚本维护，维护成本比线性脚本编写方法要相对低
8. 除了编程知识外，还需要一些脚本语言的知识

所谓结构化脚本和线性的唯一区分就在于，它引入了结构化语句，if、else之类的，因此比起线性化的，可以有分支，多重分支，循环。值得注意的此方法也是硬编码。

 

共享脚本的编写方法

1. 脚本是结构化的
2. 测试用例在脚本中定义
3. 开发成本相对结构化脚本编写方法来说，要降低一些，因为减少了很多重复的劳动
4. 需要测试人员的调整代码的编程技巧
5. 由于脚本需要模块化，所以需要更多的计划和设计
6. 测试数据（可共享）也是硬编码的 Y
7. 脚本维护和维护成本要比线性脚本编写方法相对低

与结构化脚本的编写方法关键区别就在于数据可共享。

所以优于结构化脚本的一点在于：测试数据的使用可以多脚本共享。

结构化脚本的编写方法就好比mp3的播放队列，音乐存里面是一种样子，但是播放列表是可以根据自己的添加，修改播放顺序的。

而共享脚本的编写方法就好比直接付费下载音乐来听。

 

数据驱动脚本的编写方法

1. 脚本是以结构化的方式编程的
2. 测试用例由测试数据或脚本定义
3. 由于脚本参数化和编程成本，这种方法的开发成本与共享脚本编写方法进行比较要相对高
4. 需要测试人员较高的代码调整方面的编程技巧
5. 需要更多的计划和设计
6. 数据独立存储在数据表或外部文件（数据可改） Y
7. 脚本维护成本较低
8. 推荐在需要测试正反数据的时候使用

最重要的特点就在于数据独立存储在数据表或外部文件，因为独立存储，所以代表着可以进行修改，这也意味着不再是硬编码了。

 

关键字驱动脚本的编写方法

1. 综合了数据驱动脚本编写方法、共享脚本编写方法、结构化脚本编写方法 Y
2. 测试用例由数据定义
3. 开发成本高，因为需要更多的测试计划和设计、开发方面的投入
4. 要求测试人员有很强的编码能力
5. 最初的计划和设计、管理成本比较高
6. 数据在外部文件存储
7. 维护成本比较低
8. 需要额外的框架或库，因此测试人员需要更多的编程技巧 Y
9. 会在脚本中使用关键字来区分被测控件 Y

最重要的特点：把所有相应的测试控件，用一个唯一区分的关键字进行标识。而这个关键字可以直接区分当前相应的数据，或者说区分脚本中某一步骤是具体到被测软件中的哪一个控件。

例子：关键字可以直接区分以下两个输入控件

 

工具在进行录制时，会把进行操作的关键步骤进行相应的关键字命名，比如：

 

举个例子：前提为PC端，B/S架构的软件，正常情况下在进行测试时，脚本进行关键字驱动的方法中，一般是以 操作+被测控件的name属性值，或者直接用name的属性值 来命名关键字的。被测控件的name属性值即为控件变量名

如此，使用关键字驱动时，都是以控件的唯一名称来区分的，位置（X,Y）反而成为了一种辅助作用的存在。

 

另外一提：我们在进行HTML标签的操作过程中，能够和相应的服务器发生交互的唯一方法，是HTML页面中的表单元素类别。

例如：

 

 

 

当我们提交完会发现地址栏参数会出现表单name名称并且后面会附带具体赋值。所以name属性在表单使用当中具有重要作用，而且一定会用得上。

再顺带一提：登录查询的语句要分开写，即查询用户名和查询密码要分开写，目的是为了防止SQL注入。