1、脚本测试的苦难

　　因为脚本使用的自由度很大，对于程序员限制很少，功能实现的随意性给测试带来了不少困难。首先，很多Shell脚本编写不规范，没有同意的Shell脚本编程规范，其次，脚本参数配置与程序逻辑混杂，区分不清晰。往往脚本作者同时承担多个开发任务，由于开发周期以及复杂的线上环境等原因，与其他脚本接口的沟通难以面面俱到，导致RD单元测试进行得很不充分。

　　2、我们应该如何入手

　　首先，代码走查结合动态单步跟踪以及观察日志与文件输出，网络、CPU状态。

　　然后，撰写测试桩与驱动，白盒测试保证代码逻辑中循环和分支都能够走到，黑盒测试保证函数和功能脚本接口正确，输入输出符合设计预期。

　　对于异常处理，特别是变量的检查需要特别关注，变量在使用前都需要进行检查，是否为空？或者为0？对于文件名和路径必须检查，确认文件是否存在，路径是否可达之后再进行后续操作。

　　另外，需要考虑所依赖的其他功能脚本以及二进制工具，这些功能性单元应该如何使用，调用后的返回会有哪些情况，对于正常和异常结果，脚本是否能够捕捉到并且作出正确的判断。

　　3、 静态测试 && 动态测试

　　1）新旧版本代码对比

　　可以基于icafe平台的codereview功能查看新旧版本的diff代码行，对比升级点，及时与RD沟通确认，避免遗漏，保证测试的全面性。代码对比的方式可能局限性比较大，适用于两个连续版本间代码结构无大的改动的情况，很多情况下，新版本的脚本会与之前的版本完全不同，Shell脚本与C语言模块有一个很大的区别就是，IM 模块C 代码的前后版本实现的承接关系很明显，但是Shell脚本不一定，可能后来的RD会将之前版本的脚本完全推翻。代码结构完全不同，因此在这种情况下，我们应该直接进入代码走查环节。

　　2）代码走查

　　全面、深入、细致地关注脚本分支、循环逻辑正确性。

　　例如：retrbs重启脚本，在重启PS平台所有retrbs之后，需要清理PS平台retras cache，新增的启动方式升级分成两种启动方式，normal与continue模式，实际在codereview时发现normal方式重启完成后清理cache，continue方式重启完成后直接退出，这肯定是有问题的，因为按正常逻辑来说，不管那种启动方式，在重启完成之后都需要清理cache。

　　3）搭建环境

　　搭建环境需要了解脚本的运行场景，运行频率，环境依赖以及与其配合的上下文脚本及程序：

　　脚本执行时所处的目录和配置文件

　　对应的产品模块功能

　　数据的周期性更新

　　server间的ssh认证

　　网络通信端口检查

　　脚本中的使用的工具

　　脚本硬件要求

　　比如说：脚本在什么目录下执行，每天几点钟执行，执行的时候需要什么数据以及工具提前准备好，等等。

　　4、如何调试Shell脚本

　　1）检查语法错误：

　　一般来说我们可以通过修改shell脚本的源代码，令其输出相关的调试信息来定位错误，那有没有不修改源代码来调试shell脚本的方法呢？答案就是使用shell的执行选，下面是一些常用选项的用法：

　　-n 只读取shell脚本，但不实际执行

　　-x 进入跟踪方式，显示所执行的每一条命令

　　-c “string” 从strings中读取命令

　　“-n”可用于测试shell脚本是否存在语法错误，但不会实际执行命令。在shell脚本编写完成之后，实际执行之前，首先使用“-n”选项来测试脚本是否存在语法错误是一个很好的习惯。因为某些shell脚本在执行时会对系统环境产生影响，比如生成或移动文件等，如果在实际执行才发现语法错误，您不得不手工做一些系统环境的恢复工作才能继续测试这个脚本。