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

　　――過?；蚨嘤嗟谋匦栊畔?/p>

　　過剩和多余的必需信息就像我們身上的贅肉一樣討厭。有些程序會請求他們從來不會使用或者只會用來在屏幕上顯示一次的信息，或者會要求你重新輸入你已經輸入過的數據――并非是為了驗證，僅僅只是重新獲取一次數據，這對時間的浪費是非常驚人的。

　　――不必要的步驟重復

　　如果你在輸入一個較長的命令步驟或數據時犯了一個錯誤，有些程序就不管青紅皂白讓你重新輸入;有的程序則強迫你重新輸入或確定可能有錯誤的任何命令。為了某些任務，你甚至可能需要確認每個步驟。相信我：不必要的重復或確認都是浪費時間。

　　――不必要的限制

　　為什么要把一個數據庫限定為如此多的字段或記錄，或限制一個電子表格僅使用數字，把一個項目經理限制在如此多的任務中，一個字處理程序限制在如此多的字符呢?對性能或可靠性而言并非必要的限制不應該成為約束條件。

　　6、性能

　　許多有經驗的用戶認為性能是最重要的可用性因素：使用一個快速程序，他們感到更能集中精神工作，而且更多的東西處在掌握之中。在極少出現異常的情況下，程序越快越好。

　　性能有很多定義，大致來說主要有如下的感性認識：

　　程序速度：執行標準任務的速度有多快?

　　用戶吞吐量：你能使用程序執行標準任務的速度有多快?

　　感覺到的性能：在用戶看來，該程序速度有多塊?它是否令你滿意?

　　無論如何定義，程序速度總是一個關鍵因素。但是一個界面設計拙劣的快速程序無論怎么看都要比它實際的運行和處理速度要慢得多。

　　1)降低程序速度

　　很多設計和代碼錯誤會降低一個程序的執行錯誤。程序可能會執行很多不必要的工作，如對一個在讀前會被重寫的內存區域進行初始化;也可能會對工作進行 不必要的重復，如在一個在循環中執行的任務可以在循環外完成;設計的決策也會影響到程序的速度，而且通常要比明顯錯誤導致的慢速情況更加嚴重。

　　2)緩慢回應

　　程序應立即對輸入做出響應，如果在你輸入一個字母的時刻和你看到這個字母的時刻有延遲，顯然，程序就太慢了?？焖俜答亴θ魏屋斎胧录急仨毷怯行Ф沂潜匾?，它包括：鼠標，鍵盤，軌跡球，鍵盤等等。

　　3)如何減少用戶吞吐量

　　一個閃電般快的程序執行任務時可能比蝸牛還要慢。這包括：

　　任何可能使用戶錯誤更可能發生的事情。(培訓不周，用戶習慣，程序風格等等)

　　緩慢的錯誤恢復。如：在輸入一長串字符后發現錯誤卻必須要重新輸入。

　　任何使你感到迷惑，卻得不到幫助文檔或手冊提供資料的事情。

　　輸入很多，卻做得很少的程序――這不是一個好程序。如：把一個簡單任務劃分成很小的子任務，要求對所有事情進行確認等等。

　　在測試時，使用比較性測試是個有效的方法：即把開發中的產品與競爭對手的產品進行比較，如果人們使用你的產品花費的時間要更長，那么發現這個問題就是有意義的。

　　4)反應拙劣

　　我曾經測試過一個產品，在輸入第一條數據后，居然花了將近一分鐘才從數據庫中將數據取回。這不能不說是一個反應很慢的程序。一份表單做下來將近 300條數據，按此速度計算，我將花上至少半天才能完成輸入。這種情況是不能允許的。迅速地對輸入做出回應是一個程序最最基本的功能。一個反應迅速的程序 不會強迫你在提交下一個命令之前讓你持續等待，而是讓你繼續做其他事。

　　5)沒有提前輸入

　　一個允許提前輸入的程序會讓你在它從事其他工作的時候仍然可以鍵入，它會記住輸入內容，加以顯示并在稍后進行處理。你不應該等著輸入下一個命令。

　　6)沒有給出某個操作會花很長時間的警告

　　如果程度需要超過幾秒鐘的時間來進行某事，程序應該告知用戶。對于較長時間的任務，它應該給你一個大概的時間印象而不是讓你干等著它結束。給出大致需要完成的時間或是進度條是處理此類問題一般的方法。

　　7)程序太多提示和詢問

　　提示，警告以及詢問可能很有用，不過如果它們出現得太頻繁，就會讓人很窩火。

　　8)盡量使用簡單命令和提示

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