脚本测试经验分享

脚本测试经验分享

脚本测试经验分享

脚本， 读音为jiǎo běn，汉语词语，指表演戏剧、拍摄电影等所依据的底本或书稿的底本。下面是整理的脚本测试经验分享，欢迎阅读，希望大家能够喜欢。

脚本测试经验分享 篇1

1、脚本测试特点

脚本语言语法简单灵活，与效率不是很相关的部分，使用脚本比较方便。对于多个文件的读写和控制，有比较成熟的库，几行代码可以解决C、C++需要较多代码才能实现的功能。特别是对多文件的处理，数据流动和处理比较复杂的情况。

脚本语言的劣势在于，缺乏严格的编译环节，变量定义，函数定义等问题发生概率比较大，会多制造一些障碍给测试人员。上帝关上一扇门，同时也开启了另一扇门，解释性的运行方式，使我们很容易在程序中插入测试代码，从而灵活的进行测试，对程序代码行、函数、代码段、脚本，都能在不同的粒度上进行控制，测试更加彻底，不易出现漏测问题。

2、打好语言基础

对脚本的快速测试，需要基于一定的语言基础，增强对脚本执行的调试能力：

1）sh –vx 执行看变量，sh –n 基本语法检查

2）快速多行注释，%s，快速注释多行方法“<<标记 标记”

3）熟悉awk，shell的基本语法， 基本用法

4）掌握awk快速对数据的分析能力

5）Perl、python的调试能力

3、如何做到无漏测

从问题角度出发，看存在哪些类问题，发现阶段最早在？

1）历史漏测点

A） Awk漏测，数据测试不充分，基于构造的方法比较困难，（看懂代码+理解逻辑+异常构造）

比如awk中的数据处理的第一条和最后一条是否符合预期，awk内存占用是否正常，可优化，数据的处理结果是否和预期一致。

B）上线单漏测

复杂上线单中的验证，上线的时间点是否合理（非线上运行时间）

C）多级环境部署漏测

多机环境下需要模拟，远程登录执行或者scp数据，用户之间要有信任关系，如spider@A到work@B的信任关系，需要在前面加上用户名，否则ssh B会有问题。

2）历史bug（可能漏测点）

知史而至今，前提是知史，需要对前面的问题有个学习，避免今后工作中出现。

3）无遗漏发现问题

从发现途径上，单步执行、分块执行、整体执行、考虑重复多次执行环境问题。从多个层次上对脚本进行测试和考虑，从细节->功能->整体运行维护：

A）Sh –x，sh -n 单步执行

解决语法问题、变量问题、文件存在性问题。

B）分块儿执行

避免语法、逻辑问题、异常处理验证、***验证、md5验证、数据验证

C）整体多次执行考虑

线上是多次运行，历史数据维护，会不会有硬盘问题，会不会自动清理历史文件，历史文件的清理是否正确。

D）可维护角度

报警是否合理，是否报警过多。

E）上线阶段

上线时间是否合理，是否正在运行中，上下游数据准备好的时间是否有足够的时间缓冲。

F）上线检查

对log进行检查，及时发现问题。

从以上几个角度出发，测试的过程是完整的，有效地避免了bug中的大部分。测试难点在于： 大awk的测试，异常测试、数据流程理解和数据异常测试、历史环境、复杂上线单测试、多机环境部署配合测试。

脚本测试经验分享 篇2

前言

本文描述了一些构建更易维护的和健壮的自动化测试脚本的技巧。给那些使用自动化测试工具并且为将来测试工作而建立自动化测试脚本库的测试人员提供了有价值的远见。提供了许多在文档化测试脚本，调试测试脚本，执行测试脚本的同行评审和同步测试脚本方面的建议。

增量式调试脚本

录制测试脚本，和其他的软件开发成果一样，会变得非常大。为了可以成功的回放，需要调试几百行的代码，为了参数化的数据驱动测试脚本，它可能包含了几个数据集。常见的调试测试脚本方法是首先录制所有的业务流程和需求，然后测试人员回放测试脚本以验证并纠正问题。测试人员继续调试脚本直到它和可以一（或多）组数据集一起成功地回放。

当测试脚本有成百的代码行，验证点，分支的逻辑，错误处理，参数和数据在多个已录制的业务流程之间的相关性时，调试并且解决测试脚本中的问题变得特别的乏味和难以处理。对于调试那些复杂且又冗长的测试脚本，一个更加容易管理的方法是录制脚本的一部分并且在录制测试脚本的其他部分之前分开调试他们。在测试单个的部分后，你可以决定测试脚本的一部分如何和另一部分工作和数据如何从一个已录制的流程流向其他的流程。在测试脚本的所有部分都录制后，测试人员就可以回放整个测试脚本，并确保脚本同一个或多个数据集一起从头到尾被正确地回放了。

举个例子，我录制并自动化了一个执行了以下业务流程的复杂的测试脚本：

检查在货仓中的库存

执行一次MRP运行

补充库存

挑出一些要发送的货物并且进行发货

确定交货需要移交的订单

验证发送的货物到达了它们的目的地。

这个测试脚本有一些代码行，参数，验证点和需要象一个整体一样工作的数据相关性。首先我录制了每一个单独的流程并且验证了他们分别可以成功的回放。然后我将所有录制好的流程集成尾一个大的测试脚本并且验证它同多个数据集一起能够成功的回放。如前面所述，一个关键的目的是确信在继续录制整个测试脚本的剩余部分之前每一个已录制的流程可以成功的回放。我没有录制所有提及的流程（从1到6）并把它们排列一起回放，而不首先验证所有的流程可以作为单独的流程成功的回放。

这部分是为了避免等待调试脚本，直到整个测试脚本录制好。

测试脚本的同步

测试工具会用比终端用户手工按键快的多的速度回放已录制的测试脚本。接着由于应用程序可能不够快地显示数据或从数据库取出数值以允许测试脚本正确地回放，这可能会击垮所测试的应用程序。当测试地应用程序不能响应测试脚本时，脚本执行会突然中断，然后需要用户干涉。为了同步所测试应用程序和回放中地测试脚本，测试小组在已录制的测试脚本中引入了人为的等待时间。为了放慢测试脚本的执行，嵌入在测试脚本中的等待时间是最任意的且通过试验和错误最佳估计。等待时间主要的问题是它们要不是等的太长就是不够长时间。

例如，测试人员或许注意到对于所测试的应用程序测试脚本回放得太快。他可能打算放慢它几次直到测试脚本执行和测试的应用程序相同步。这个技巧可以会造成相反的结果－甚至失败－如果在测试执行时，由于外部的因素（例如网络有延迟或系统维护）导致应用程序运行比新引入的等待时间更慢。在这种情况下，每次测试人员将不得不不断的猜测一个新的合理的等待时间。用等待时间放慢脚本不是十分科学的，并且对于创建强健的，在没有用户干涉情况下能够成功运行的自动化测试脚本没有什么帮助。

如果有可能的化，测试人员应该避免引入人为的等待时间或任意的sleep变量以使测试脚本和应用程序同步。

"While"语句或嵌套的"loops"语句是用于同步需要同步点的测试脚本且不管所测试程序的响应时间都可以成功回放的正确的技术。在测试脚本种插入嵌套的loops或“while”语句也可以减少在测试脚本回放时用户的干涉。例如，我插入"while"语句在录制好的测试脚本里，不断按Enter键直到创建了一个计划中的协议，不管所测试应用程序要花多长时间产生协议。测试脚本不依赖所测试应用程序的响应时间工作。

已签核，通过了同行评审

作为测试准备审核标准的一部分，测试脚本应该被正式的接受并且在开始测试循环之前被批准。***Es， 业务分析人员和开发人员都应该参与到批准已录制的测试脚本中。编写已自动化的测试脚本的测试人员应该证明测试脚本可以成功的在QA环境中回放，如果有可能的话，可以带上多种数据集。

录制、回放隐藏的对象

脚本可能被录制为增加或是双击表格中一个字段或字段位置没有被固定的一个数组的值。如果表格或数组中字段的位置从开始录制时就不断地变化，脚本可能在回放时会失败。测试脚本经常在回放中失败就是因为那些没有显示或在屏幕中可见的对象的位置发生了改变。

为了回放那些位置敏感或位置受变更影响的脚本，有必要用功能性增强脚本，例如“向下滚屏”，“”或“查找”。包含这些实用性功能可以确保需要回放的隐藏对象将可以被识别，增加或是双击而不顾其在矩阵，表格，显示的屏幕上的位置。

举个例子，我曾经录制果一个脚本，在最初录制时它需要向下滚屏两次来查找一个可以在表格中输入的空字段。当我在几个星期之后回放它时，我不得不向下滚屏四次来查找空字段，而不是相之前录制的两次。接着脚本失败了，因此我在脚本中嵌入了逻辑判断以指导脚本向下滚屏需要的次数来查找一个空字段。我通过在一个“while”循环中放置一个“”（"next page"）功能实现了这个目的，它可以驱动脚本不停的“”（page down）直到找到空字段。

安排重运行脚本/储存执行日志

为了绕过测试工具不能在安排测试脚本重运行的局限，测试人员可以通过可以支持多种命令行选项的NT的scheduler安排测试脚本。测试百年应该将执行日志存储在一个共享的驱动盘或针对审核的测试结果的测试管理工具中。

为关键的脚本创建自动的消息通知

可以用错误处理程序逻辑增强测试脚本，当错误发生时它可以不断的发送错误信息给无限设备或email地址。一些测试脚本是关键性的业务并且可能在午夜批量地运行。正确并成功运行这些关键性业务的测试脚本会作为其他自动化任务的一个依赖或者前提条件。

通常也包括在关键业务脚本中一旦出现失败时自动发送消息通知的逻辑。