在實際工作中，需要對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.進行了一層優化，對日誌進行處理，使用正則，標註我關心的信息
效果圖對比：
