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

  A)Sh ?x,sh -n 单步执行

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

  B)分块儿执行

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

  C)整体多次执行考虑

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

  D)可维护角度

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

  E)上线阶段

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

  F)上线检查

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

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

  本次只是针对awk测试重点进行讲述,awk如果出问题都是数据问题,影响效果,下面针对awk的陷阱做了一些总结:

  Case1:代码阅读发现缺陷,基于逻辑的数据检查,注意第一条和后一条的输出逻辑:

16 awk ‘BEGIN{
17 pre_user="";check=0;dead=0
20 }{
21 # pattern need check
22 if(ARGIND==1)
23 dict[$1]=$2;
24 else{
25 t=split($1,a,"/");
26 p1=a[1]"/"a[2]"/";
27 p2=a[1]"/";
29 if(p1 in dict)
30 p=p1;
31 else if (p2 in dict)
32 p=p2;
33 else next;
34 if(check!=0&&p!=pre_user){
35 print p,check >>"‘$3‘";
36
37 if(check==dead)
38 {
39 if(check>=dict[p])
40 print p,check >>"‘$4‘";
41 else print p,check >>"‘$5‘";
42 }
43 check=0
44 dead=0
45 }
46 check++;
47 if($3==0) dead++;
48 pre_user=p
49 }
50 }‘ $1 $2


  Case2:脚本中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 BEGIN{
79 key_url=""
80 key_all=""
81 ret=1
82 }
83 {
84 if($2<‘$OLDEST_TIME‘) next
85 url=$1
86 while( url>key_url){ ######修改为while(ret>0 && url>key_url)

87 if(key_all) print key_all
88 while((ret=getline line < "‘$1‘")>0){
89 sp=index(line, " ")
90 tmp_url=substr(line, 1, sp-1)
91 if(tmp_url>key_url){
92 key_url=tmp_url
93 key_all=line
94 break
95 }
96 print line
97 }
98 if(ret==0) break
99 }
100 print
101 }
102 END{
103 if(ret) print line
104 while(ret=getline line < "‘$1‘"){ #######修改为((ret=getline line < "‘$1‘")>0 print line
105 print line
106 }
107 }‘ $2
 

  4、加快脚本测试方法

  做任何事情,如果想加快,都有一些熟知的方法:1、并行处理; 2、借助于工具,自动化不需要人工介入的部分;3、加快必须人工部分的速度。如果把上面的基本方式映射到我们的脚本测试中:

  4.1 并行执行多个CASE

  我们可以对多次运行做并行化。对于脚本类测试,大多数是挖掘类,基于一个比较复杂的测试周边环境,但是,不会修改本模块以外的环境和数据。

  我们可以利用一个周边环境,部署多个被测程序,通过修改conf来保证运行:

  a)对同一台机器部署多个不同目录(减少搭建周边环境)

  b)对不同机器相同路径部署(减少修改conf)

  对不同目录进行不同case运行。比如,新旧对比,性能,功能等同时进行。同时对多个粒度进行测试,避免因为某次运行,占用环境,而堵塞我们的测试过程。

  4.2 借助工具

  自动化操作步骤,这个我们自己可以编写test脚本来完成,比如性能监控,环境清理等功能。

  借助于自动化通用工具,比如类似编译器的变量检查,路径检查,函数接口检查等,实现脚本之间调用关系和数据依赖关系的检查等。对很多产品线的公共问题,统一处理,这些都是大组、专人来开发和维护。

  4.3 脚本测试技巧

  人是灵活的,不是所有的工作都适合自动化。脚本测试设计中和代码逻辑强相关的部分,不易自动化,因为自动化要兼容多种可能性的时候,太复杂,而且不能保证的准确率,还是需要人工参与,比如:

  问题1:if的异常分支,空文件构造,数据的清空逻辑,数据的历史维护逻辑,ssh逻辑,如何快速验证?

  问题2:我们为了不同粒度的测试,需要多次运行脚本,有些脚本运行时间很长,是否可以一次运行,测试完所有粒度的功能?

  上面这个例子中的一些技巧:

  A)异常分支,我们可以通过添加语句mkdir ?p a;rm a,来保证#?的检测

  B)构造各种逻辑,或者看代码,看是否满足线上对数据逻辑的需求。

  C)中间数据的保留,对需要长时间运行的代码块儿,插上桩,将结果cp到其他文件,缩短时间,后续修改脚本代码,利用备份的中间文件多次独立运行,节省时间。

  D)成功运行一次,和多次运行相结合,对中间文件如果在脚本被删除,需要我们再需要关注的关键点cp得到bak文件,运行一次后,保证任何段的代码(粒度),单独都可以运行。加上多环境,我们可以在一次成功运行后,测试完所有的功能,同时并行完成性能测试。)

  E)多机不同用户部署,可以变为单机不同用户部署;总控和运行机器,也可以通过单台模拟,和自己建立信任关系,来验证功能。