1、軟件黑盒測試之人機交互問題介紹人機交互，程序與操作者之間的通信與交流。這不是早些年的科幻電影，我們也許每天都在做，在取款機前，在自動售賣機前。1）遺漏信息你應該知道，所有的事都能從計算機屏幕上得到有效的消息。不要遺漏任何對于用戶而言至關重要的信息，即使這些信息對你而言毫無用處。沒有任何屏幕指令如何找到程序的名稱？如何退出程序？你應該怎么樣獲取幫助？如果程序使用了某種命令語言，如何才能得到命令列表？程序可能僅僅只在它啟動時顯示這些內容。當然你也可以從幫助手冊中獲取這些信息，但并不是必要的。沒有任何屏幕指令的程序可能會讓人受不了，查詢手冊的話需要花費的時間可能會更長，也可能就會讓用戶覺得軟件學習起

2、來太復雜了。假定打印出的文件隨時可得丟了用戶手冊怎么辦？有經驗的用戶不會非要依賴打印好的文檔，提供一份電子版的吧。無正式文字證明（說明）的功能特征如果大多數的功能特征或命令在屏幕上提供文字說明，那么所有的都應如此。僅略過幾個功能特征將會導致 UI 形式上的混亂。同樣，如果程序為很多命令描述其“特殊情況”下的行為，那么所有的命令都需要提供這類說明。這種情況在國人的軟件開發過程中時有發生，并不是不能，而是不想看起來不可能退出的狀態 如何取消一條命令或在一個深層菜單樹中進行備份？程序應該允許你可以避免那些你不希望遇到的情況。比如，在軟件安裝時，要求插入磁盤，如果不插入正確磁盤就不能退出安裝程序。沒有

3、告訴你如何避免就和發生災難時，沒有提 供一條逃生路徑一樣糟糕。沒有光標大多數用戶都依賴于光標。 一個光標可以讓用戶覺得計算機仍然在正常運轉 （盡管有時候死機也是如此），每個交互程序都應該顯示光標，當然，在關閉光標時別忘了提醒用戶注意。沒有對輸入做出響應每個程序都應該對輸入做出回應。如果沒有，呵呵，保管80以上的用戶產生疑問：怎么沒有響應？還要等多久？是不是我的電腦過時了？如果有以下幾種情況，一般視為正常：選擇一個菜單項時，如果你的按鍵操作沒有回應，只要下一個屏幕立刻出現并且此屏幕上的標題與菜單項一樣，就可以視為正常。如果程序忽視錯誤的命令或按鍵操作，當然可以不對其進行回應。如果你告訴程序不要對

4、輸入回應，它必須沉默，如果它進行了回應，應該立即告訴開發人員對其進行修改（可能是在忘記了繼續處理另一種情況）。如果輸入的是安全性代碼（如密碼等），那么程序決不應在屏幕上做出不恰當的回應（如顯示你輸入的密碼明文）。在長期延遲時沒有表示其活動給一段較長時間的程序延遲一個合適的響應，將是非常必要的舉動。相信這樣不需要再給用戶做出過多的解釋了。當某個改變即將生效時沒有給出建議一個程序可能會比你預計的更早或更晚執行一個命令，例如：刪除某些重要數據時，（而這個過程將持續一段時間），必要的提示是必須的。沒有對已經打開的文件進行檢查 這個錯誤是非常常見的，尤其對于那些輸入關鍵數據的程序而言。用戶可能不會注意，

5、但是在以后的工作中將發現略微的一絲更改就會引出大量的問題。你不能保證程序會對同一個文件在某個時刻做出不同修改所帶來的后果。所以，決不允許同一文件同時被打開兩次甚至更多，以確保程序輸出的唯一性。錯誤的、誤導的或令人迷惑的信息每個錯誤都會讓你對程序顯示的所有其他東西產生懷疑。使用戶做出虛假歸納的細小錯誤，如遺漏條件或是不適宜的類比會比清楚的事實錯誤更讓測試人員感到惱火因為更難對它們進行改正。簡單的事實錯誤在一個程序改變之后，更新屏幕顯示是低優先級任務，結果則是：屏幕上大量的信息過時。記?。簾o論何時程序發生改變，都要仔細檢查可能指示程序特征的每個消息，最簡單的辦法就是直接對更改后的屏幕進行刷新。拼寫

6、錯誤（錯別字）我相信，這絕對不是設計上的問題，我也相信開發人員可能會不以為然。Oh，但是客戶會在乎，會抱怨這些的 - 還是改正它們吧。不準確的簡化在保持一個特征的描述盡可能簡單的愿望中，一條消息的創作者可能只覆蓋特征行為的最簡單方面，而忽略了重要條件。舉例來說，這種情況可能會引發歧義，比如說關閉（到底是關閉文件還是關閉程序？）。作為一個測試人員，需要你足夠仔細的研究可能會出現問題的任何一個微不足道的細節。寧可錯殺，不能放過?。m然要極力避免錯殺的情況。）無效的比喻（圖標之類可以指示功能（特征）的事物）例如：回收站的圖標可能不是一個好的比喻；對于文件一旦移除就永久消失的 情況來說，碎紙機的圖標可

7、能來得更好一些。令人迷惑不解的特征（功能）名稱如果一個命令名稱在計算機領域中或語言中有一個標準含義，就必須與其含義 一致。別指望著胳膊能擰得過大腿，確定現行的標準是可靠的。同一特征（功能）具有多個名稱相同的功能特征只要一個名稱就夠了一一只要能表述清楚；用戶可不一定有時 間玩同義詞的游戲。另外，這種情況對軟件在用戶面前顯示的復雜度也有影響。 信息超載不要讓你的文檔和幫助屏幕看起來太過專業一一太多技術細節了。用戶會不耐 煩的，況且效果也不好。如果實在需要，可以把他們另外列出。盡量使用直白, 用戶能理解的話表述這些信息。另外，信息超載的另一個意義意味著煩瑣冗長 的語句，那是要極力避免的。數據何時得到

8、保存假設你輸入了一些程序需要保存的信息。當你進行切換或程序退出時，當你需 要每隔一段時間進行保存時，它是否會把數據按照你想的方式進行保存呢？何 時完成呢？如果你對答案感到困惑，那就意味著可能有問題出現了。曾經在同 事的項目中發現過很多次這樣的情況：每次修改后直接關閉程序，卻不提示用 戶保存一一我只知道，修改信息在關閉時也消失了。在對某個模塊進行修改時， 你應密切注意這個問題。很差的外部模塊性外部模塊性指的是程序從外部看起來產品的模塊化程度（如同程序是可分割的 實體）。你如何容易地理解模塊組件？很差的外部模塊會耗費大量的時間來學習產品，還會嚇跑新用戶 - 它看上去太復雜了！盡可能讓信息獨立展示出

9、來，對任何特定任務而言，你需要知道的越少越好。2）幫助文本和錯誤信息幫助文本和錯誤信息通常被認為是產品的次要部分。它們可能是由初級程序員編寫的（比如我）或是作者編寫，對其進行更新的工作可能被賦予低優先級。然而，作為產品而言，這又是必不可少的部分，一份看上去賞心悅目的幫助文檔可以“主觀 ”的降低軟件的學習難度和用戶的使用興趣。當你感到困惑或是有麻煩時，尋求幫助或傾向于使用錯誤處理程序將是一個明智的選擇。你可能會覺得不爽，更多的時候是不耐煩。而如果其中有信息誤導了你，那么無異于火上澆油。以下列出的是我以往在審核幫助文檔及錯誤信息時碰到的一些常見問題。不合適的閱讀層次在計算機終端上，人們不能很好的進

10、行閱讀。幫助文本和錯誤信息應該盡量措辭簡單明了，多用主動語態，盡量少使用技術術語，即便用戶中有計算機經驗也是如此。冗長避免你的幫助文檔和錯誤信息變成裹腳布。大多數用戶在需要更多信息時，會選擇通過菜單獲得進一步的信息。最好讓他們自己選擇所需的信息。不合適的情緒語氣盡量不要使用感嘆號，如“終止”、“崩潰”之類的帶有激烈意味的詞語都應如此。事實錯誤記得測試時需要測試那些更新過的功能，在舊的幫助上的方法可能在新軟件中是行不通的。這個時候開發人員的代碼更新日志就顯得很必要了，你不必對每項功能進行檢查，完全可以把這類回歸測試交給自動化測試工具完成，而你只需要關注其新內容即可。上下文錯誤 不要把上下文之間的

11、關系搞錯了，這會帶來閱讀時的不便。比較清晰的方法是 首先列出上下文關聯列表，并按照操作順序的先后進行組織。沒有識別出錯誤來源 通常，一個好的錯誤信息不僅可以指出是什么情況，而且還要指出為什么有些 東西出了錯，以及如何處理此類錯誤的方法。在過往的項目中，常常有很多這 樣的問題：如“打印錯誤”、“保存錯誤”等等含糊的說明。如果用戶在獲得 了錯誤信息后，還是一臉茫然，那就應該認真考慮一下錯誤說明的編寫方式是 否可以再改進一些了。不能立刻重現的錯誤很可能是個大問題 沒有說明原因就禁止一個資源 如果程序嘗試使用打印機、內存控件等資源，卻做不到，錯誤信息應當包含的 不僅僅是宣布失敗，還需要說明原因。報告說

12、沒有錯誤 首先，還是先承認這種情況是不太可能會出現的；錯誤信息只能由錯誤狀態出 發，如果大部分是通常情況的調試消息，或者是少部分并不一定由某個缺陷引 起的事件報告，那么，你可能就會忽略所有的錯誤信息。3）顯示上的（問題）缺陷 這是一個比較客觀的問題，至少表面上看上去是這樣的。任何可見的錯誤都會 產生讓人不快的感覺（盡管這些問題不一定很嚴重），用戶就不一定會相信或者購買該產品?？赡苁且驗榇祟愬e誤大多都是屬于低級錯誤，通常并不受到開發人員和項目經理的重視，但是我們必須重視它一一它就是問題（Bug）,它就是我們要找的東西之一。另外提一點：總是拘泥于這類Bug-一放過重要的功能需求，“吹毛求疵”一一可

13、能會使測試失去意義，它可能是造成開發人員和項目經理不重視測試的一個借口。盡管如此，我們還是要提出這類問題，但并不是說可以遺漏重要的功能需求。數據寫到了錯誤的屏幕位置光標提示在正確的位置，但是數據卻顯示在屏幕錯誤的位置（張冠李戴）。這類錯誤對開發人員而言，不應該是個很棘手的問題，但對用戶來說，那是致命的。未能清除部分屏幕一條信息在屏幕上顯示了幾秒鐘，接著卻只有一部分被擦除了；或者你對前一問題的回應仍然留在屏幕上，我們固然可以以計算機整體性能為借口，但也不能排除技術因素。 為了輸入一些新東西， 不得不在提示或不相關的回應上輸入，這是令人頭疼而且迷惑不解的。在以前測試的項目中，就曾經出現過由于屏幕未

14、正確刷新導致的清屏不完整及無故彈出不相關提示的問題這種問題比較普遍，需要多加注意。未能突出顯示部分屏幕如果程序常常需要突出顯示某個特定類別的項目，例如提示或者在激活窗口中的所有文本，那么它就必須一直這么做。未能清除突出顯示 屏幕位置的屬性與顯示的文本分開儲存時這是很普遍的。程序員刪除了突出顯示的文本，但是忘記了從屏幕的那一區域清除突出顯示。這類問題一般都和數據刷新有關系，無論是界面上的處理還是系統底層的處理。顯示的字符串錯誤或不完整顯示的消息可能是毫無價值的文本，一個冗長的信息的一個片斷或是一條應該顯示在其他時間出現的完整信息。這其中任何一條都可能反映出程序邏輯上，用來發現消息文本的指針的值或

15、者已儲存的文本副本中的錯誤。顯示信息過長或者不夠長消息在屏幕上顯示的時間應該足夠長，至少應該保持到能讓用戶讀到結束為止。如果對同一條消息有時顯示時間長，有時顯示時間短則需要注意，這可能預示著外部資源之間的競爭條件（比如對內存資源的爭奪），往往這些條件是在我們考慮之外的，需要認真對待。4）界面布局的顯示屏幕看上去應該是很有條理的，別讓它看起來像是一個亂糟糟的房間。不同類別的對象應該在可預知的區域分開顯示。你可以參考一些關于 UI 布局的文章，但歸結起來說：顯示布局應該很容易讓你在屏幕上找到你要的東西。從美學角度看屏幕布局很拙劣屏幕可能是不平衡的，大多數情況下是這樣子，行或者列不對齊，或者只是看起

16、來很“糟糕”。好好利用你的鑒賞力，如果沒有信心，可以問問別人的意見，參考一些界面設計很合理的軟件。如果對你而言它的布局的確看起來很糟，相信你的直覺，肯定有什么東西錯了，盡管現在你還沒有發現。菜單布局錯誤這是最常見的問題之一了：我們有時候會發現在編輯菜單下突然冒出了一個文件關閉的選項，而一般它是放在文件一欄下的。在很多的參考文獻中，已經對這方面的內容做了比較詳實的說明，我想強調的是以下一些問題：相似的或從概念上相關的菜單選擇應該分組，或者應該在屏幕上說明。選擇一個菜單項通常應該獨立。為了獲得一個獨立的結果，用戶不應該必須在不同的菜單上做出兩個或更多的選擇（這可絕對“難”用）。通過鍵入其首字母來選

17、擇菜單項通常要比使用數字來得好。當然，你要留神不要給菜單項過于奇怪的名稱；另外，還要注意不要在同一欄下面不要出項重復的字母。對話框布局錯誤對話框應該一致。如：他們應該一致使用大小寫，字體和文本對齊規則。對話框標題應當占據某個一致的位置，并與用來調用該對話框的命令名相符合。相同的快捷方式在不同對話框之間應該起相同作用一一如<ESC不應取消某些對話框，而在其他類似情況下完成其他的任務。對話框中的控件布局必須合理安排。應使用必要的間隔把組隔開。選擇和錄入區域應該垂直和水平排列，這樣用戶就可以以直線模式操作光標的運動（為了方便）。留意對話框之間的相互依賴性。如果某個對話框中的選擇將最終決定另一個

18、對話框的選項將是令人困惑的。如果程序不得不這樣做，務必要求開發人員給出具體提示。模糊不清的指示你應該總是知道去哪里查找以找出下一步。如果屏幕排得很滿，總是應該為命令和消息留出一塊空間。使用氣泡顯示信息也是一個不錯得選擇。閃爍的誤用 閃爍的圖片或文本很引人注意，不過記得不要太多閃爍。太多的閃爍會讓人覺 得不舒服。你應該每次最多只讓一個目標進行閃爍而且頻率不能太高。顏色的誤用不要太多顏色，它會讓我們的眼睛很疲勞。顏色不應該使我們分散注意力，也不能使屏幕看上去雜亂無章，盡量使用統一風格的顏色，如果程序的顏色組合看上去很難看，抗議吧，沒有人會愿意買毫無美感的產品的。過于依賴顏色如果程序在項之間使用顏色為唯一分隔符，那么它將限制使用者的范圍，對于一些特殊的產品，需要考慮到例如色盲之類對顏色不敏感的人群或是使用