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

　　事實錯誤

　　記得測試時需要測試那些更新過的功能，在舊的幫助上的方法可能在新軟件中是行不通的。這個時候開發人員的代碼更新日志就顯得很必要了，你不必對每項功能進行檢查，完全可以把這類回歸測試交給自動化測試工具完成，而你只需要關注其新內容即可。

　　上下文錯誤

　　不要把上下文之間的關系搞錯了，這會帶來閱讀時的不便。比較清晰的方法是首先列出上下文關聯列表，并按照操作順序的先后進行組織。

　　沒有識別出錯誤來源

　　通常，一個好的錯誤信息不僅可以指出是什么情況，而且還要指出為什么有些東西出了錯，以及如何處理此類錯誤的方法。在過往的項目中，常常有很多這樣 的問題：如“打印錯誤”、“保存錯誤”等等含糊的說明。如果用戶在獲得了錯誤信息后，還是一臉茫然，那就應該認真考慮一下錯誤說明的編寫方式是否可以再改 進一些了。

　　不能立刻重現的錯誤很可能是個大問題

　　沒有說明原因就禁止一個資源

　　如果程序嘗試使用打印機、內存控件等資源，卻做不到，錯誤信息應當包含的不僅僅是宣布失敗，還需要說明原因。

　　報告說沒有錯誤

　　首先，還是先承認這種情況是不太可能會出現的;錯誤信息只能由錯誤狀態出發，如果大部分是通常情況的調試消息，或者是少部分并不一定由某個缺陷引起的事件報告，那么，你可能就會忽略所有的錯誤信息。

　　3)顯示上的(問題)缺陷

　　這是一個比較客觀的問題，至少表面上看上去是這樣的。任何可見的錯誤都會產生讓人不快的感覺(盡管這些問題不一定很嚴重)，用戶就不一定會相信或者 購買該產品?？赡苁且驗榇祟愬e誤大多都是屬于低級錯誤，通常并不受到開發人員和項目經理的重視，但是我們必須重視它――它就是問題(Bug)，它就是我們 要找的東西之一。

　　另外提一點：總是拘泥于這類Bug――放過重要的功能需求，“吹毛求疵”――可能會使測試失去意義，它可能是造成開發人員和項目經理不重視測試的一個借口。盡管如此，我們還是要提出這類問題，但并不是說可以遺漏重要的功能需求。

　　――數據寫到了錯誤的屏幕位置

　　光標提示在正確的位置，但是數據卻顯示在屏幕錯誤的位置(張冠李戴)。這類錯誤對開發人員而言，不應該是個很棘手的問題，但對用戶來說，那是致命的。

　　――未能清除部分屏幕

　　一條信息在屏幕上顯示了幾秒鐘，接著卻只有一部分被擦除了;或者你對前一問題的回應仍然留在屏幕上，我們固然可以以計算機整體性能為借口，但也不能 排除技術因素。為了輸入一些新東西，不得不在提示或不相關的回應上輸入，這是令人頭疼而且迷惑不解的。在以前測試的項目中，就曾經出現過由于屏幕未正確刷 新導致的清屏不完整及無故彈出不相關提示的問題――這種問題比較普遍，需要多加注意。

　　――未能突出顯示部分屏幕

　　如果程序常常需要突出顯示某個特定類別的項目，例如提示或者在激活窗口中的所有文本，那么它就必須一直這么做。

　　――未能清除突出顯示

　　屏幕位置的屬性與顯示的文本分開儲存時這是很普遍的。程序員刪除了突出顯示的文本，但是忘記了從屏幕的那一區域清除突出顯示。這類問題一般都和數據刷新有關系，無論是界面上的處理還是系統底層的處理。

　　――顯示的字符串錯誤或不完整

　　顯示的消息可能是毫無價值的文本，一個冗長的信息的一個片斷或是一條應該顯示在其他時間出現的完整信息。這其中任何一條都可能反映出程序邏輯上，用來發現消息文本的指針的值或者已儲存的文本副本中的錯誤。

　　――顯示信息過長或者不夠長

　　消息在屏幕上顯示的時間應該足夠長，至少應該保持到能讓用戶讀到結束為止。如果對同一條消息有時顯示時間長，有時顯示時間短則需要注意，這可能預示著外部資源之間的競爭條件(比如對內存資源的爭奪)，往往這些條件是在我們考慮之外的，需要認真對待。

　　4)界面布局的顯示

　　屏幕看上去應該是很有條理的，別讓它看起來像是一個亂糟糟的房間。不同類別的對象應該在可預知的區域分開顯示。你可以參考一些關于UI布局的文章，但歸結起來說：顯示布局應該很容易讓你在屏幕上找到你要的東西。

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