软件测试脚本经验分享
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的测试，异常测试、数据流程理解和数据异常测试、历史环境、复杂上线单测试、多机环境部署配合测试。
本次只是针对awk测试重点进行讲述，awk如果出问题都是数据问题，影响效果，下面针对awk的陷阱做了一些总结：
Case1：代码阅读发现缺陷，基于逻辑的数据检查，注意第一条和后一条的输出逻辑：
16 awk ‘BEGIN{17 pre_user=""；check=0；dead=020 }{21 # pattern need check22 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=044 dead=045 }46 check++;47 if($3==0) dead++;48 pre_user=p49 }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=182 }83 {84 if($2<‘$OLDEST_TIME‘) next85 url=$186 while( url>key_url){ ######修改为while(ret>0 && url>key_url)
87 if(key_all) print key_all88 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_url93 key_all=line94 break95 }96 print line97 }98 if(ret==0) break99 }100 print101 }102 END{103 if(ret) print line104 while(ret=getline line < "‘$1‘"){ #######修改为((ret=getline line < "‘$1‘")>0 print line105 print line106 }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）多机不同用户部署，可以变为单机不同用户部署；总控和运行机器，也可以通过单台模拟，和自己建立信任关系，来验证功能。
