2023年6月29日发(作者：)

QTPUFT（⼆）：⾃动化测试脚本编写⽅法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. ⼀种⾮结构化的编程⽅式 Y2. 测试⽤例由脚本定义3. ⾮常低的开发成本4. 测试⼈员所需要的编程⽅⾯技巧⼏乎可以忽略5. 不需要计划、设计6. 测试数据在脚本中是硬编码的 Y7. 脚本会很脆弱，因此维护成本很⾼8. 没有公⽤的脚本，因此可能造成重复劳动线性可以通俗的理解：只能往⼀个⽅向⾛，从前到后或者从后到前，不能转弯~~硬编码说⽩了就是录什么就放什么，不能改，或者说不能很灵活的改动。例⼦：⽐如说磁带，从头放到尾，不能跳着放，快进也是线性操作。

结构化脚本的编写⽅法1. 结构化的脚本编写⽅法 Y（引⼊结构化语句）2. 测试⽤例在脚本中定义3. 编程的成本要⽐线性脚本编写⽅法略⾼⼀点4. 需要测试员的调整编码技巧5. 需要某种程度上的计划、设计6. 测试数据也是在脚本中被硬编码 Y7. 因为相对稳定⼀点，所以需要相对少的脚本维护，维护成本⽐线性脚本编写⽅法要相对低8. 除了编程知识外，还需要⼀些脚本语⾔的知识所谓结构化脚本和线性的唯⼀区分就在于，它引⼊了结构化语句，if、else之类的，因此⽐起线性化的，可以有分⽀，多重分⽀，循环。值得注意的此⽅法也是硬编码。

共享脚本的编写⽅法1. 脚本是结构化的2. 测试⽤例在脚本中定义3. 开发成本相对结构化脚本编写⽅法来说，要降低⼀些，因为减少了很多重复的劳动4. 需要测试⼈员的调整代码的编程技巧5. 由于脚本需要模块化，所以需要更多的计划和设计6. 测试数据（可共享）也是硬编码的 Y7. 脚本维护和维护成本要⽐线性脚本编写⽅法相对低与结构化脚本的编写⽅法关键区别就在于数据可共享。所以优于结构化脚本的⼀点在于：测试数据的使⽤可以多脚本共享。结构化脚本的编写⽅法就好⽐mp3的播放队列，⾳乐存⾥⾯是⼀种样⼦，但是播放列表是可以根据⾃⼰的添加，修改播放顺序的。⽽共享脚本的编写⽅法就好⽐直接付费下载⾳乐来听。

数据驱动脚本的编写⽅法1. 脚本是以结构化的⽅式编程的2. 测试⽤例由测试数据或脚本定义3. 由于脚本参数化和编程成本，这种⽅法的开发成本与共享脚本编写⽅法进⾏⽐较要相对⾼4. 需要测试⼈员较⾼的代码调整⽅⾯的编程技巧5. 需要更多的计划和设计6. 数据独⽴存储在数据表或外部⽂件（数据可改） Y7. 脚本维护成本较低8. 推荐在需要测试正反数据的时候使⽤最重要的特点就在于数据独⽴存储在数据表或外部⽂件，因为独⽴存储，所以代表着可以进⾏修改，这也意味着不再是硬编码了。

关键字驱动脚本的编写⽅法1. 综合了数据驱动脚本编写⽅法、共享脚本编写⽅法、结构化脚本编写⽅法 Y2. 测试⽤例由数据定义3. 开发成本⾼，因为需要更多的测试计划和设计、开发⽅⾯的投⼊4. 要求测试⼈员有很强的编码能⼒5. 最初的计划和设计、管理成本⽐较⾼6. 数据在外部⽂件存储7. 维护成本⽐较低8. 需要额外的框架或库，因此测试⼈员需要更多的编程技巧 Y9. 会在脚本中使⽤关键字来区分被测控件 Y最重要的特点：把所有相应的测试控件，⽤⼀个唯⼀区分的关键字进⾏标识。⽽这个关键字可以直接区分当前相应的数据，或者说区分脚本中某⼀步骤是具体到被测软件中的哪⼀个控件。例⼦：关键字可以直接区分以下两个输⼊控件

⼯具在进⾏录制时，会把进⾏操作的关键步骤进⾏相应的关键字命名，⽐如： 举个例⼦：前提为PC端，B/S架构的软件，正常情况下在进⾏测试时，脚本进⾏关键字驱动的⽅法中，⼀般是以 操作+被测控件的name属性值，或者直接⽤name的属性值 来命名关键字的。被测控件的name属性值即为控件变量名如此，使⽤关键字驱动时，都是以控件的唯⼀名称来区分的，位置（X,Y）反⽽成为了⼀种辅助作⽤的存在。

另外⼀提：我们在进⾏HTML标签的操作过程中，能够和相应的服务器发⽣交互的唯⼀⽅法，是HTML页⾯中的表单元素类别。例如：

当我们提交完会发现地址栏参数会出现表单name名称并且后⾯会附带具体赋值。所以name属性在表单使⽤当中具有重要作⽤，⽽且⼀定会⽤得上。再顺带⼀提：登录查询的语句要分开写，即查询⽤户名和查询密码要分开写，⽬的是为了防⽌SQL注⼊。