一種基於沙箱的動態測試的設想
- 2020 年 3 月 3 日
- 筆記
為什麼長期佔據我瀏覽器的一個 tab 頁？主要是我作為實用派，一直對單元測試的投入產出比存在疑問，但是自己又沒有實際做過單元測試，所以很想知道別人反駁的理由，順便結合自己的項目，做個取捨。
整篇文章讀下來，作者並沒有全盤否定單元測試，只是建議只做必要的單元測試，主要反駁的是實際項目中，單元測試至上的思想，至於不做單元測試的部分，作者建議用斷言、系統測試以及開發同學的意識來替代。
我很贊成這種想法，但實際落地的可行性仍然存在疑問，之前的單元測試，要麼是具備很好品質意識的開發來做，要麼是具備很好程式碼能力的測試來做，現在等於完全傾向於具備很好品質意識的開發了，而中國開發人員的現狀，離這個程度還是有一定差距的（開發同學別懟我）。
那我的建議是什麼呢？
目前在編碼階段就介入進行品質保證裡面比較實用的做法，一個是自動化靜態程式碼檢查，一個是人工靜態程式碼 Review。
自動化靜態程式碼檢查，可以發現那些比較固定的、有明確檢查條件的問題。
人工靜態程式碼 Review，如果碰到負責任的開發，不僅可以發現業務實現上的邏輯問題，還可以發現一些潛在的技術問題。
但是這兩種方法都有一個共同的缺點，就是很難發現一些動態執行過程中的問題，比如記憶體泄露，就是很難確認分配記憶體和釋放記憶體的匹配操作。那有沒有解決方案呢？
也算有吧，一種是針對性程式碼插樁，對症下藥，就是麻煩，一種是安裝一些插件，程式碼編譯時自動實現了插樁，但是需要帶著插樁的程式碼進行測試，也是個問題。
所以我突然想到了一種藉助沙箱進行動態測試的方案。
所謂沙箱，就是一個完全獨立隔離的可執行環境，目前主要應用於安全領域。
說起它的演進過程也挺有意思，很久之前殺軟識別病毒都是靠靜態特徵碼（類似我們的靜態程式碼掃描邏輯），後來病毒進化了，沒有顯著的可以識別的靜態特徵了，或者有些敏感特徵正常軟體也會用到，所以殺軟就發展出一種行為檢測的方法，就是通過檢測病毒/木馬乾了啥來判斷是否惡意，而判斷木馬乾了啥，一種方式是等木馬乾活時抓現行（滯後、被動），另一種則是把木馬丟到沙箱裡面主動運行起來，這是目前一種非常有效的識別手段。
同理，對於我們靜態掃描沒法判斷的檢查點，是不是也可以利用沙箱 + 程式碼執行 + 行為監控點的方式，去發現那些需要動態執行，並且黑盒測試又不方便驗證的點呢？
以上，我好費勁的從敏捷測試引到了沙箱動態檢測，不知道你看明白了沒有？目前，這個方法還只是個猜想，如果大家有其他的方式，請多賜教，如果針對上面的方案有任何問題和建議，歡迎留言一起討論。
