測試與改錯(4)

　　粗暴一些的容錯性測試俗稱“大猩猩”測試，除了不能拳打腳踢嘴咬，什么招術都可以使出來。這里我舉不出例子，因為我沒有對程序粗暴過，并且這輩子也不打算學會粗暴。

　　7.3.3 性能與效率測試

　　性能與效率測試主要是測試軟件的運行速度和對資源的利用率。有時人們關心測試的“絕對值”，如數據送輸速率是每秒多少比特。有時人們關心測試的“相對值”，如某個軟件比另一個軟件快多少倍。

　　在獲取測試的“絕對值”時，我們要充分考慮并記錄運行環境對測試的影響。例如計算機主頻，總線結構和外部設備都可能影響軟件的運行速度;若與多個計算機共享資源，軟件運行可能慢得像蝸牛爬行。

　　在獲取測試的“相對值”時，我們要確保被測試的幾個軟件運行于完全一致的環境中。硬件環境的一致性比較容易做到(用同一臺計算機即可)。但軟件環境的因素較多，除了操作系統，程序設計語言和編譯系統對軟件的性能也會產生較大的影響。如果是比較幾個算法的性能，就要求編程語言和編譯器也完全一致。

　　性能與效率測試中很重要的一項是極限測試，因為很多軟件系統會在極限測試中崩潰。例如，連續不停地向服務器發請求，測試服務器是否會陷入死鎖狀態不能自拔;給程序輸入特別大的數據，看看它是否吃得消。

　　7.3.4 易用性測試

　　易用性測試沒有一個量化的指標，主觀性較強。調查表明，當用戶不理解軟件中的某個特性時，大多數人首先會向同事、朋友請教。要是再不起作用，就向產品支持部門打電話。只有30%的用戶會查閱用戶手冊。[Cusumano 1995]

　　一般認為，如果用戶不翻閱手冊就能使用軟件，那么表明這個軟件具有較好的易用性。

　　7.3.5 文檔測試

　　文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個組成部分。

　　正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內容前后矛盾。

　　完備性是指文檔不可以“虎頭蛇尾”，更不許漏掉關鍵內容。有些學生在證明數學題時，喜歡用“顯然”兩字蒙混過關。文檔中很多內容對開發者可能是“顯然”的，但對用戶而言不見得都是“顯然”的。

　　文檔不可以寫成散文、詩歌或者偵探、言情小說，要讓大眾用戶看得懂，能理解。

　　很多程序員能編寫出好程序，卻寫不出清晰的文檔。不要說自己以前語文學得差，現在已沒救了，找借口不是辦法。沒有人天生就能寫出好程序，都是練出來的。同理，若第一次寫不好文檔，就多寫幾次文檔，慢慢地就會寫出好文檔來。我上大學前不會說普通話，不會寫作文，現在我極能說會寫，當個秘書或書記已綽綽有余。

　　7.4 改 錯

　　在軟件測試時如果發現了錯誤，必須請程序員改錯，否則測試工作就白干了。

　　改錯是個大悲大喜的過程，一天之內可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過上萬個程序錯誤，那么少男少女們不必經歷失戀的挫折也能變得成熟起來。

　　我從大三開始真正接受改錯的磨練，已記不清楚多少次汗流浹背、濕透板凳。改不了錯誤時，恨不得撞墻。改了錯誤時，比女孩子朝我笑笑還開心。

　　在做本科畢業設計時，一天夜里，一哥們流竄到我的實驗室，哈不攏嘴地對我嚷嚷：“你知道什么叫茅塞頓開嗎?”

　　我象白癡似的搖搖頭。

　　他說：“今天我化了十幾個小時沒能干掉一個錯誤，剛才我去了廁所五分鐘，一切都解決了。”

　　他還用那沒洗過的手拉我，一定要請我吃“肉夾饃”。那得意勁兒仿佛同時談了兩個女朋友。

　　在本節，我要替程序員們總結關于改錯的幾點思想方法：

　　(1)要有勇氣。東北有個林場工人，工作勤奮，一人能干幾個人的活。前三十年是伐樹勞模，受到周總理的接見。忽有一天醒悟過來，覺得自己太對不起森林，決心補救錯誤。后三十年成了植樹勞模，受到朱總理的接見。此大勇也。

　　程序中的錯誤只有開發者自己才能找出并改掉。如果因畏懼而拖延，會讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。

　　(2)不可蠻干。都說急中生智，我不信。我認為大多數人著急了就會蠻干，早把“智”丟到腦后。不僅人如此，動物也如此。

原文轉自：http://www.uml.org.cn/Test/200608303.htm