课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
Bash脚本单元测试是我们在学习软件测试技术的时候需要考虑到的一个测试需求,而今天我们就通过案例分析来了解一下,在哪些场景需求下会做Bash脚本单元测试。
场景一:在执行Bash脚本测试前,我们需要需要事先安装好所有在Bash脚本中会用到的三方工具,否则这些测试将会因为命令找不到而执行失败。例如,我们在脚本中使用了Bazel这个构建工具。我们必须提前安装并配置好Bazel,而且不要忘记为了能够正常使用Bazel还得需要一个支持使用Bazel构建的工程。
场景二:测试结果的稳定性可能取决于脚本中访问的三方服务的稳定性。比如,我们在脚本中使用curl命令从一个网络服务中获取数据,但这个服务有时候可能会访问失败。有可能是因为网络不稳定导致的,也可能是因为这个服务本身不稳定。再或者如果我们需要三方服务返回不同的数据以便测试脚本的不同分支逻辑,但我们可能很难去修改这个三方服务的数据。
场景三:Bash脚本的测试用例的执行时间取决于脚本中使用的命令的执行时间。例如,如果我们中脚本中使用了Gradle来构建一个工程,由于不同的工程大小Gradle的一个构建可能要执行3分钟或者3个小时。这还只是一个测试用例,如果我们还有20个或者100个测试用例呢?我们是否还能在几秒内获得测试报告呢?
即使使用了容器来执行Bash脚本测试,也一样无法避免上面的几个问题。环境的准备过程可能会随着测试用例的增多而变的繁琐,测试用例的稳定性和执行时长取决于三方命令和服务的稳定性和执行时长,还可能很难做到使用不同数据来覆盖不同的测试场景。
对于测试Bash脚本来说,我们真正要验证的是Bash脚本的执行逻辑。比如在Bash脚本中可能会根据传入的参数来组合出内部所调用的命令的选项和参数,我们要验证的是这些选项和参数确实如我们预期的。至于调用的命令在接受了这些选项和参数后由于什么原因而失败,可能我们并不关心这所有的可能原因。因为这会有更多的外部影响因素,比如硬件和网络都是否工作正常、三方服务是否正常运行、构建工程所需的编译器是否安装并配置妥当、授权和认证信息是否都有效、等等。但对于Bash脚本来说,这些外部原因导致的结果就是所调用的命令执行成功或者失败了。所以Bash脚本只要关注的是脚本中调用的命令是否能够成功执行,以及命令输出了哪些,并决定随后执行脚本中的哪些不同分支逻辑。
如果说我们就是想知道这个命令搭配上这些选项参数是否能按我们预期的那样工作呢?很简单,那就单独在命令行里面去执行一下。如果在命令行中也不能按预期的工作,放到Bash脚本里面也一样不会按预期的工作。这种错误和Bash脚本几乎没什么关系了。
所以,为了尽量去除影响Bash脚本验证的那些外部因素,我们应该考虑为Bash脚本编写单元测试,以关注在Bash脚本的执行逻辑上。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。