1、 1、脚本测试特点脚本语言语法简单灵活，与效率不是很相关的部分，使用脚本比较方便。对于多个文件的读写和控制，有比较成熟的库，几行代码可以解决 C、C+需要较多代码才能实现的功能。特别是对多文件的处理，数据流动和处理比较复杂的情况。脚本语言的劣势在于，缺乏严格的编译环节，变量定义，函数定义等问题发生概率比较大，会多制造一些障碍给测试人员。上帝关上一扇门，同时也开启了另一扇 门，解释性的运行方式，使我们很容易在程序中插入测试代码，从而灵活的进行测试，对程序代码行、函数、代码段、脚本，都能在不同的粒度上进行控制，测试更 加彻底，不易出现漏测问题。2、打好语言基础对脚本的快速测试，需要基于一定的语言基
2、础，增强对脚本执行的调试能力：1)sh vx 执行看变量， sh n 基本语法检查2)快速多行注释，%s ，快速注释多行方法“功能-整体运行维护：A)Sh x，sh -n 单步执行解决语法问题、变量问题、文件存在性问题。B)分块儿执行避免语法、逻辑问题、异常处理验证、下载验证、md5 验证、数据验证C)整体多次执行考虑线上是多次运行，历史数据维护，会不会有硬盘问题，会不会自动清理历史文件，历史文件的清理是否正确。D) 可维护角度报警是否合理，是否报警过多。E)上线阶段上线时间是否合理，是否正在运行中，上下游数据准备好的时间是否有足够的时间缓冲。F)上线检查对 log 进行检查，及时发现问题。从
3、以上几个角度出发，测试的过程是完整的，有效地避免了 bug 中的大部分。测试难点在于： 大 awk 的测试，异常测试、数据流程理解和数据异常测试、历史环境、复杂上线单测试、多机环境部署配合测试。本次只是针对 awk 测试重点进行讲述， awk 如果出问题都是数据问题，影响效果，下面针对 awk 的陷阱做了一些总结：Case1：代码阅读发现缺陷，基于逻辑的数据检查，注意第一条和最后一条的输出逻辑：16 awk BEGIN17 pre_user=“；check=0；dead=020 21 # pattern need check22 if(ARGIND=1)23 dict$1=$2;24 else
4、25 t=split($1,a,“/“);26 p1=a1“/“a2“/“;27 p2=a1“/“;29 if(p1 in dict)30 p=p1;31 else if (p2 in dict)32 p=p2;33 else next;34 if(check!=03637 if(check=dead)38 39 if(check=dictp)40 print p,check “$4“;41 else print p,check “$5“;42 43 check=044 dead=045 46 check+;47 if($3=0) dead+;48 pre_user=p49 50 $1 $2C
5、ase2：脚本中 dump.sh 调用 filter.awk 时，取不到 dump.sh 中使用的 shell 变量，DEL_REASON 的变量值，导致 从 LINKBASE 上取到的数据经filter.awk 处理后没有任何数据输出，dead.url_age.$i永远为空。Case3：对 2 个有序文件进行 merge，构造 case 的时候，构造文件$1，$2进行 merge，如果$1 先结束，会造成$1 的最后一条还 会不断打印出来，使文件无序，如果$2 文件先结束，则不会出现该情况，构造数据验证时要注意等价类划分情况，保证所有情况都被测试到。错误代码：77 awk 78 BEGIN7
6、9 key_url=“80 key_all=“81 ret=182 83 84 if($2key_url) #修改为 while(ret0 2、借助于工具，自动化不需要人工介入的部分;3、加快必须人工部分的速度。如果把上面的基本方式映射到我们的脚本测试中：4.1 并行执行多个 CASE我们可以对多次运行做并行化。对于脚本类测试，大多数是挖掘类，基于一个比较复杂的测试周边环境，但是，不会修改本模块以外的环境和数据。我们可以利用一个周边环境，部署多个被测程序，通过修改 conf 来保证运行：a)对同一台机器部署多个不同目录 (减少搭建周边环境)b)对不同机器相同路径部署( 减少修改 conf)对不
7、同目录进行不同 case 运行。比如，新旧对比，性能，功能等同时进行。同时对多个粒度进行测试，避免因为某次运行，占用环境，而堵塞我们的测试过程。4.2 借助工具自动化操作步骤，这个我们自己可以编写 test 脚本来完成，比如性能监控，环境清理等功能。借助于自动化通用工具，比如类似编译器的变量检查，路径检查，函数接口检查等，实现脚本之间调用关系和数据依赖关系的检查等。对很多产品线的公共问题，统一处理，这些都是大组、专人来开发和维护。4.3 脚本测试技巧人是灵活的，不是所有的工作都适合自动化。脚本测试设计中和代码逻辑强相关的部分，不易自动化，因为自动化要兼容多种可能性的时候，太复杂，而且不能保证
8、100%的准确率，还是需要人工参与，比如：问题 1：if 的异常分支，空文件构造，数据的清空逻辑，数据的历史维护逻辑，ssh 逻辑，如何快速验证?问题 2：领测国际为了不同粒度的测试，需要多次运行脚本，有些脚本运行时间很长，是否可以一次运行，测试完所有粒度的功能?上面这个例子中的一些技巧：A)异常分支，我们可以通过添加语句 mkdir p a;rm a，来保证#?的检测B)构造各种逻辑，或者看代码，看是否满足线上对数据逻辑的需求。C)中间数据的保留，对需要长时间运行的代码块儿，插上桩，将结果 cp 到其他文件，缩短时间，后续修改脚本代码，利用备份的中间文件多次独立运行，节省时间。D) 成功运行一次，和多次运行相结合，对中间文件如果在脚本被删除，需要我们再需要关注的关键点 cp 得到 bak 文件，运行一次后，保证任何段的代码(粒度)，单独都可以运行。加上多环境，我们就可以在一次成功运行后，测试完所有的功能，同时并行完成性能测试。)E)多机不同用户部署，可以变为单机不同用户部署;总控和运行机器，也可以通过单台模拟，和自己建立信任关系，来验证功能。
