在實際工作中，需要對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!
轉自： http://wklken.me/posts/2012/09/15/how-to-test-shell.html