惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
罗磊的独立博客
T
Tailwind CSS Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Jina AI
Jina AI
V
V2EX
美团技术团队
阮一峰的网络日志
阮一峰的网络日志
酷 壳 – CoolShell
酷 壳 – CoolShell
月光博客
月光博客
量子位
MyScale Blog
MyScale Blog
G
Google Developers Blog
M
MIT News - Artificial intelligence
L
LangChain Blog
Microsoft Azure Blog
Microsoft Azure Blog
Recent Announcements
Recent Announcements
MongoDB | Blog
MongoDB | Blog
N
Netflix TechBlog - Medium
有赞技术团队
有赞技术团队
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
D
DataBreaches.Net
云风的 BLOG
云风的 BLOG
B
Blog

Posts on WKLKEN THINKING

apisix 中的 lrucache apisix 中的服务发现机制 apisix 中的负载均衡 apisix etcd机制 聊聊框架 关于 k8s 的 zero downtime deployment 一些建议 apisix 遇到的一些问题 关于在除夕前一天换了一个洗衣机的故事 Django DRF 性能优化 DRF 的一些实践 Part1: Serializer DRF继承关系图 Better Code: 关于接口的灵活性 新的仓库: wklken/naming 缓存使用的一些经验 Better Code: 抽象: 可扩展性与可维护性的抉择 Better Code: 异常时, 该提示用户哪些信息? Better Code: 更好的异常日志打印 Go: some libs Go: go-redis/cache升级的坑 Go: logrus性能提升 Go: gin validation 远程办公的一点总结 Go: 开发过程中的一些bug 项目管理实践: 风险驱动开发 Go: 一种error wrap调用链处理方式 漫谈技术选型 Go: 基于 apitest 做handler层单元测试 Go: go-sql-driver interpolateparams参数优化 [分享]深度工作 你需要更多的思考时间
如何进行shell脚本正确性测试
2012-09-15 · via Posts on WKLKEN THINKING

在实际工作中,需要对shell脚本进行正确性测试。

如何用最快最有效的方式进行测试?

很多开发的习惯是,二话不说,写完/拿到,就跑一把,看看输入,输出,想要的操作是否完成,也就过了。

其实这是十分不严谨的,若是未经过QA,风险还是相当大的。

以下即shell脚本测试流程,仅供参考

1.代码走读:

写完,或者拿到一个shell脚本,不必急于运行,虽然实践是检验整理的唯一标准,但是,在读代码这个过程中,可以规避很多低级的bug.

读什么?

A.代码逻辑,这个脚本用来做什么,主要分为多少步,分别做了什么事情?
  用于检查是否有遗漏逻辑,或有悖于需求。
B.具体语法,变量,判断语句
  语法方面的东西,变量是否定义,判断语句逻辑是否正确,是否考虑各种异常,错误是否退出,返回正确状态值等。

2.语法检测:

shell的语法还是相当让人无语的,很多很容易疏忽遗漏的地方

命令格式:

sh -n ***.sh

若是没有异常输出,证明脚本没有明显的语法问题。

运行结果

3.运行跟踪:

实践是检验整理的唯一标准,跑一把。

不过,可不是直接运行然后去看最终结果,这样会遗漏掉很多中间过程。

命令格式:

sh -vx ***.sh

得到效果如下:

运行结果

我们可以看到

每行代码原始命令(无+的):[这是-v的效果]

代码执行时的情况(带+),包括运算结果,逻辑判断结果,变量赋值等等[-x的效果]

而我们所要关注的就是这些信息,主要是变量值和逻辑判断结果。

4.覆盖分支:

直接跑,只能覆盖到主体流程,对于其他控制流分支的代码是无法覆盖到的。

对于关键性的,重点的逻辑,我们需要制造条件,使运行脚本可以进入对应分支

5.其他:

A.关于bashdb:
  可以尝试下,但是感觉投入产出比不高
B.关于单元测试:
  实际工作中,由于项目压力比较大,单元测试的成本还是相当高的,所以目前为止没有。

6.有没有更好的方式?

好吧,单步跟踪,脚本短的还好,日志信息不会太多,要是多了,存在调用其他脚本等等…..

日志量达到几千行,这是很轻易的事情。

跟踪过的童鞋有同感,展现不够友好,惨白惨白一片,一千行下来,看的眼花。

很容易遗漏(LZ被坑了好多回,你看,或不看……错误信息明明就在那里,就是视而不见)

So.进行了一层优化,对日志进行处理,使用正则,标注我关心的信息

效果图对比:

原始图

扩展图

脚本是用python实现的,位置:https://github.com/wklken/pytools/tree/master/shell

思想是:执行,抓到所有日志,用正则进行匹配,打上颜色,然后输出

好了,就这些

工具的实现是为了提高效率,节约时间。

The end!

wklken

Gighub: https://github.com/wklken

Blog: https://wklken.me

2012-09-15

转载请注明出处,谢谢!