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

　　――錯誤的、誤導的或令人迷惑的信息

　　每個錯誤都會讓你對程序顯示的所有其他東西產生懷疑。使用戶做出虛假歸納的細小錯誤，如遺漏條件或是不適宜的類比會比清楚的事實錯誤更讓測試人員感到惱火――因為更難對它們進行改正。

　　簡單的事實錯誤

　　在一個程序改變之后，更新屏幕顯示是低優先級任務，結果則是：屏幕上大量的信息過時。記?。簾o論何時程序發生改變，都要仔細檢查可能指示程序特征的每個消息，最簡單的辦法就是直接對更改后的屏幕進行刷新。

　　拼寫錯誤(錯別字)

　　我相信，這絕對不是設計上的問題，我也相信開發人員可能會不以為然。Oh，但是客戶會在乎，會抱怨這些的--還是改正它們吧。

　　不準確的簡化

　　在保持一個特征的描述盡可能簡單的愿望中，一條消息的創作者可能只覆蓋特征行為的最簡單方面，而忽略了重要條件。舉例來說，這種情況可能會引發歧 義，比如說關閉(到底是關閉文件還是關閉程序?)。作為一個測試人員，需要你足夠仔細的研究可能會出現問題的任何一個微不足道的細節。寧可錯殺，不能放 過!(雖然要極力避免錯殺的情況。)

　　無效的比喻(圖標之類可以指示功能(特征)的事物)

　　例如：回收站的圖標可能不是一個好的比喻;對于文件一旦移除就永久消失的情況來說，碎紙機的圖標可能來得更好一些。

　　令人迷惑不解的特征(功能)名稱

　　如果一個命令名稱在計算機領域中或語言中有一個標準含義，就必須與其含義一致。別指望著胳膊能擰得過大腿，確定現行的標準是可靠的。

　　同一特征(功能)具有多個名稱

　　相同的功能特征只要一個名稱就夠了――只要能表述清楚;用戶可不一定有時間玩同義詞的游戲。另外，這種情況對軟件在用戶面前顯示的復雜度也有影響。

　　信息超載

　　不要讓你的文檔和幫助屏幕看起來太過專業――太多技術細節了。用戶會不耐煩的，況且效果也不好。如果實在需要，可以把他們另外列出。盡量使用直白，用戶能理解的話表述這些信息。另外，信息超載的另一個意義意味著煩瑣冗長的語句，那是要極力避免的。

　　數據何時得到保存

　　假設你輸入了一些程序需要保存的信息。當你進行切換或程序退出時，當你需要每隔一段時間進行保存時，它是否會把數據按照你想的方式進行保存呢?何時 完成呢?如果你對答案感到困惑，那就意味著可能有問題出現了。曾經在同事的項目中發現過很多次這樣的情況：每次修改后直接關閉程序，卻不提示用戶保存―― 我只知道，修改信息在關閉時也消失了。在對某個模塊進行修改時，你應密切注意這個問題。

　　很差的外部模塊性

　　外部模塊性指的是程序從外部看起來產品的模塊化程度(如同程序是可分割的實體)。你如何容易地理解模塊組件?很差的外部模塊會耗費大量的時間來學習產品，還會嚇跑新用戶--它看上去太復雜了!盡可能讓信息獨立展示出來，對任何特定任務而言，你需要知道的越少越好。

　　2)幫助文本和錯誤信息

　　幫助文本和錯誤信息通常被認為是產品的次要部分。它們可能是由初級程序員編寫的(比如我)或是作者編寫，對其進行更新的工作可能被賦予低優先級。然 而，作為產品而言，這又是必不可少的部分，一份看上去賞心悅目的幫助文檔可以“主觀 ”的降低軟件的學習難度和用戶的使用興趣。

　　當你感到困惑或是有麻煩時，尋求幫助或傾向于使用錯誤處理程序將是一個明智的選擇。你可能會覺得不爽，更多的時候是不耐煩。而如果其中有信息誤導了你，那么無異于火上澆油。以下列出的是我以往在審核幫助文檔及錯誤信息時碰到的一些常見問題。

　　不合適的閱讀層次

　　在計算機終端上，人們不能很好的進行閱讀。幫助文本和錯誤信息應該盡量措辭簡單明了，多用主動語態，盡量少使用技術術語，即便用戶中有計算機經驗也是如此。

　　冗長

　　避免你的幫助文檔和錯誤信息變成裹腳布。大多數用戶在需要更多信息時，會選擇通過菜單獲得進一步的信息。最好讓他們自己選擇所需的信息。

　　不合適的情緒語氣

　　盡量不要使用感嘆號，如“終止”、“崩潰”之類的帶有激烈意味的詞語都應如此。

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