我的經驗manual tester在剛入手的時候發現漏洞的機會越多，因爲剛開始更像客戶，更容易做出不可預知的亂七八糟的行爲。
這次有點像白盒測試，要測試一組轉換過後的代碼。
1）用parser轉換代碼。
2) 憑經驗直接編輯代碼至沒有語法錯誤及避免常見問題。將現實參數代入。差不多就得到一個可測試的腳本了。
3) 編寫測試腳本:
i. 複製所有的函數名字。有些函數之間類似，不能順序測，或者看上去鐵定鐵定沒有問題；還是要都複製下來。
ii. 歸類函數：
可以順序測試的放在一組
類似的可以一起順序測試的放在一組
類似的必須獨立測試的放在一組
被其他函數調用的底層函數可以不測
其實原則就是：分類測試，不要遺漏
重複性的勞動不要做，包括重複性的思考。在原則清楚的情況下執行易行的操作步驟，而不是每次操作都需要思考，更省力，不容易出錯。
4）還有時間的話加上一些邊際的數據。
5）這樣測試容易遺漏的是什麼呢？ 一個是那些developer以爲肯定沒有問題的代碼：類似的函數，微小的函數，簡單的函數； 還有這樣測試最多能做到這些代碼能正常工作，不容易發覺設計上的漏洞。更復雜的情況比如操作順序等等 如果在設計時沒有想到測試時也沒有覆蓋到就會出問題。
我覺得寫代碼的人的目的只是代碼能用，不是在各種情況下萬能。測試腳本是比較硬代碼的測試方法，要覆蓋到所有的執行路線工作量比較大，而且需要更多的‘設計’。在新代碼時應該考慮儘量多的應用環境。在新代碼穩定後再形式化，固化這些測試的路徑。
尤其是大型項目，一個零部件難以預知它在大環境下的操作情境。
那麼在有新功能加入項目時呢？ 代碼有改動時呢？保持基本功能的運行能保證上層的功能嗎？
TBD