軟件GUI測試中的關注點(12)

　　6)不適當的版本控制

　　如果可執行代碼不止存在于一個文件中，那么有人會嘗試把某一文件的新版本和老版本一起使用，客戶對其軟件升級使得這類問題時常發生，但是又不能明白出了什么問題。新版本應確保所有的代碼都是最新的，當然也要對老版本有完整的備份。

　　7)針對惡意使用的不充分預防

　　人們有時會有意無意的提供程序有害輸入，或者嘗試觸發錯誤狀況(特別是做測試的家伙們)。不要假定“任何有理智的人都不會這么做”，相信我：程序不完全是為了“有理智”的人開發的。

　　2、錯誤檢測

　　程序通常有足夠的可用信息來檢測數據中或其操作中的錯誤。這部分內容將指導一部分常見的錯誤檢測方式并對其進行歸類。

　　1)忽視溢出

　　一個數值計算結果對于程序來說太大以至于無法處理時，就會產生溢出。溢出由較大數字相加和相乘或者被0除或是由于過小的分數除而引起。在有既定規則的情況下，溢出是很容易檢測到的。

　　2)忽視不可能的值

　　在計算機當中，幾乎沒有什么不可能發生的事。程序應該檢查其變量，以確保它們在合理的界限之內，它應可以捕獲并拒絕如2月31日這樣的日期值。如果 當變量為0時，程序完成某動作，變量為1時完成另一工作，并假設其他所有值都是不可能，那么就必須保證變量只能為0或者是1，對其他所有值進行額外的處 理。在一個項目中，經過數年維護編程后，舊的假定就不一定安全了。

　　3)忽視看上去不真實的值

　　有些人可能會從自己帳戶里提取100，000，000，000的錢，那么就算他有這么多錢，也應該在通過交易之前向幾個不同的人進行確認。這類看似荒唐的用例往往包藏著錯誤的禍心，應該小心應付。

　　4)忽視錯誤標志

　　程序調用了一個子程序，結果操作不成功，它在一個被稱為錯誤標志的特殊變量中報告了該失敗。與通常一樣，程序能檢查或忽略它，并把從例程返回的誤用數據當作真實的進行處理。

　　5)忽視硬件缺陷或錯誤情況

　　程序應該假定它能連接的設備是失敗的，許多設備能夠發送警告某件事情出錯的返回信息。如果有設備這樣做了，停止嘗試與其交互，并向某人或更高級別的控制程序報告該事件。不能忽視該類情況以避免造成不必要的困擾。

　　6) 數據比較

　　結算銀行存折時，你有一個你自己認為的余額數值，銀行也會提供一個余額數值。在考慮了服務費，銀行利息，最近帳單等等數據之后，兩個數據不吻合，那么就要好好查一查了。在互相檢查兩個數據集或計算結果集時，也會產生類似的情況。

　　3、錯誤恢復

　　程序中存在錯誤，程序已經檢測到了錯誤，而且現在正設法對其進行處理。許多錯誤恢復代碼只是稍微進行了測試，或者根本沒有進行測試。錯誤恢復例程中的缺陷可能比原始問題更嚴重。

　　1)自動錯誤更正

　　通過檢查其他數據或規則集，有時程序不僅能檢測錯誤，而且還能糾正錯誤，而用不著麻煩任何人。這樣的程序是令人滿意的，但僅當這種“糾正”是正確的情況時才是如此。

　　2)未能報告一個錯誤

　　程序應該報告任何檢測到的內部錯誤，即使它能自動糾正錯誤產生的后果也一樣。在稍微不同的環境下，它可能檢測不到相同的錯誤。程序可以向用戶報告這 一錯誤，也可以向一個多用戶系統的操作員，向磁盤上的日志文件，或者是這些對象的任一組合報告錯誤?？傊?，不管怎么樣，只要發生了，它就必須報告。

　　3)未能設置一個錯誤標志

　　某子程序被調用，但是結果失敗，假定它在失敗時設置了一個錯誤標志，它把控制返回給調用程序，卻沒有對這個標志進行設置，那么調用程序就會把無用數據當作有效數據傳回去，這是應堅決避免的狀況。這可能會造成數據冗余，臟數據或是直接導致當前操作失效，嚴重的則會引起崩潰。

　　4)程序要走向何方?

　　一部分代碼失效了。它記錄了錯誤，并設置了一個錯誤標志，接下來干嘛呢?尤其是經過了幾個跳轉的情況下，它如何才能得知程序中的什么地方返回了控制?

　　5)中止錯誤

　　停止了程序，或者當它在檢測到錯誤時自動停止了，那么它是否關閉了任何打開的輸出文件呢?它是否在關閉時會記錄退出的原因呢?在最普通的條件下，在即將結束之前它是否進行了整理或者它只是結束但可能留下一團混亂呢?這都是開發人員和測試人員需要考慮的問題之一。

原文轉自：http://www.uml.org.cn/Test/200711195.asp