起源
可用性最早來源於人因工程（human factors）。人因工程又稱工效學（ergonomics），起源於二戰時期，設計人員研發新式武器時研究如何使用機器、人的能力限度和特性，從而誕生了工效學，這是一門涉及多個領域的學科，包括心理學、人體測量學、環境醫學、工程學、統計學、工業設計、計算機等。
歷史發展
第一次有記錄的可用性測試出現在1981年。當時施樂公司下屬的帕羅奧多研究中心的一個員工記錄了該公司在Xerox Star工作站（Xerox 8010 Information System）的開發過程中引入了可用性測試的經過。不過由於一共只有大約25,000套左右的銷售成績，Xerox Star系統被認為是一個典型的商業失敗案例。
1984年，美國財務軟體公司Intuit Inc.在其個人財務管理軟體Quicken的開發過程中引入了可用性測試的環節。Suzanne E. Taylor在其2003年的業界暢銷書《Inside Intuit》中提到“在第一次可用性測試實例中，該做法後來已成為行業慣例，LeFevre從街上召集了一些人來同時試用Quicken進行測試，每次測試之後程式設計師都能夠對軟體加以改進。”Intuit Inc.公司的創立者之一的Scott Cook也曾經表示“我們在1984年做了可用性測試，比其他的人早了5年的時間。進行可用性測試和在已售人群中進行可用性測試是不大一樣的，而且例行公事的去進行和把它作為核心設計流程中的一環也是很不一樣的”。
經過二十多年的發展和套用，可用性測試已經成為產品（服務）設計開發和改進維護各個階段必不可少的重要環節。它的價值在於初期及早的發現產品（服務）中可能會存在的問題，在開發或投產之前提供改進方案，從而節約設計開發成本。而在產品（服務）的銷售疲軟或是使用過程中出現問題卻無法及時精確的找到問題關鍵時，可用性測試可以在很大程度上的提高解決問題的效率。通過可用性測試不但可以獲知用戶對產品（服務）的認可程度，還可以獲知一些隱含的用戶行為規律。
國際標準
ISO/IEC 9126-1將可用性定義為“在特定使用情景下，軟體產品能夠被用戶理解、學習、使用、能夠吸引用戶的能力” 【ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model[S]. International Standards Organization,2001.】。 ISO/IEC 9126-1闡述了在產品開發過程中軟體質量的六個方面（見下圖），依次為功能性（functionality）、可靠性（reliability）、可用性（usability）、有效性（efficiency）、維護性（maintainability）、移植性（portability）。ISO/IEC 9126-1將“使用質量（Quality in use）”作為廣義的目標：滿足目標用戶和支持用戶的使用質量，功能性、可靠性、有效性和可用性決定著目標用戶在特定情景中的使用質量，支持用戶則關心維護性和移植性方面的質量。目前ISO/IEC 9126-1有兩個作用，首先是作為具體軟體設計活動的一部分（可用性定義），其次是提供軟體滿足用戶需求的最終目標。
國際標準ISO 9241-11將可用性定義為“特定的用戶在特定的使用情景下，有效、有效率、滿意的使用產品達到特定的目標”【ISO9241-11. Ergonomic requirements for office work with visual display terminals (VDT's) – Part 11: Guidance on usability[S]. International Standards Organization,1998.】。ISO 9241-11將可用性概括為三方面：有效性（effectiveness），用戶使用系統完成各種任務所達到的精度（accuracy）和完整性（completeness）；效率（efficiency），用戶按照精度和完整度完成任務所耗費的資源，資源包括智力、體力、時間、材料或經濟資源；滿意度（satisfaction），用戶使用該系統的主觀反應，描述了使用產品的舒適度和認可程度。
Nielsen（1994）認為實用性（utility）和可用性（usability）構成了系統能否用來達到特定目標的因素，稱為有用性（usefulness）【Nielsen J．可用性工程[M]．劉正捷等譯．北京：機械工業出版社，2004：16-24．】。可用性定義為“用戶能否很好地使用系統的功能”，分為五個因素：可學習性（learnability），用戶可以在短時間內使用系統完成相關任務；效率（efficiency），用戶學會使用系統後，能夠高效率地使用系統；可記憶性（memorability），用戶在一段時間沒有使用系統後，仍然能夠使用系統；出錯（errors），用戶使用系統時能夠少出錯，系統必須防止災難性錯誤發生；滿意度（satisfaction），用戶使用系統主觀上感到滿意。
Shackel（1991）將可用性定義為“按照人的功能特性，系統很容易、有效地被特定用戶群使用，經過特定培訓和用戶支持，在特定的環境情景中，完成特定範圍的任務”，並將可用性分為四個因素：有效性（effectiveness）、可學性（learnability）、靈活性（flexibility）、態度（attitude）。
測試的方法
所謂可用性評估，即是對軟體“可用性”進行評估，檢驗其是否達到可用性標準。目前的可用性評估方法超過20種，按照參與可用性評估的人員劃分，可以分為專家評估和用戶評估；按照評估所處於的軟體開發階段，可以將可用性評估劃分為形成性評估和總結性評估。形成性評估是指在軟體開發或改進過程中，請用戶對產品或原型進行測試，通過測試後收集的數據來改進產品或設計直至達到所要求的可用性目標。形成性評估的目標是發現儘可能多的可用性問題，通過修復可用性問題實現軟體可用性的提高，總結性評估的目的是橫向評估多個版本或者多個產品，輸出評估數據進行對比。網站可用性測試包含的步驟有：定義明確的目標和目的,安裝測試環境，選擇合適的客群，進行測試和報告結果。
評估方法
認知預演
（Cognitive Walkthroughs）是由Wharton等（1990）提出的，該方法首先要定義目標用戶、代表性的測試任務、每個任務正確的行動順序、用戶界面，然後進行行動預演並不斷地提出問題，包括用戶能否建立達到任務目的，用戶能否獲得有效的行動計畫，用戶能否採用適當的操作步驟，用戶能否根據系統的反饋信息評價是否完成任務，最後進行評論，諸如要達到什麼效果，某個行動是否有效，某個行動是否恰當，某個狀況是否良好。該方法優點在於能夠使用任何低保真原型，包括紙原型。該方法缺點在於：評價人不是真實的用戶，不能很好地代表用戶。
啟發式評估
（Heuristic Evaluation）由Nielsen和Molich（1990）提出，由多位評價人（通常4至6人）根據可用性原則反覆瀏覽系統各個界面，獨立評估系統，允許各位評價人在獨立完成評估之後討論各自的發現，共同找出可用性問題。該方法的優點在於專家決斷比較快、使用資源少，能夠提供綜合評價，評價機動性好，但是也存在不足之處：一是會受到專家的主觀影響，二是沒有規定任務，會造成專家評估的不一致，三是評價後期階段由於評價人的原因造成信度降低，四是專家評估與用戶的期待存在差距，所發現的問題僅能代表專家的意思。
用戶測試法
（User Test）就是讓用戶真正地使用軟體系統，由實驗人員對實驗過程進行觀察、記錄和測量。這種方法可以準確地反饋用戶的使用表現、反映用戶的需求，是一種非常有效的方法。用戶測試可分為實驗室測試和現場測試。實驗室測試是在可用性測試實驗室里進行的，而現場測試是由可用性測試人員到用戶的實際使用現場進行觀察和測試。
用戶測試之後評估人員需要彙編和總結測試中獲得的數據，例如完成時間的平均值、中間值、範圍和標準偏差，用戶成功完成任務的百分比，對於單個互動，用戶做出各種不同傾向性懸著的直方圖表示等。然後對數據進行分析，並根據問題的嚴重程度和緊急程度排序撰寫最終測試報告。
注意事項
你測試的是產品，而不是使用者
對一些用戶而言， "測試"有負面的涵義。我們要努力確保他們不認為測試是針對他們。我們要讓他們明白，他們正在幫助我們測試原型或網站。事實上，我們可以不使用“測試”這個術語。相反，我們是邀請參加者為我們提供幫助， "勇於嘗試原型" 。 當用戶難以完成任務時，我們應該改變網站，而不是改變用戶。同時我們還應該思考該網站能在多大程度上符合那些典型用戶的的目標，而不是關注用戶在這個任務做的多好。
更多地依靠用戶的表現，而不是他們的偏好
通過測試我們可以測量到用戶的表現，以及他們的偏好。用戶的表現包括是否成功完成，所用時間，產生的錯誤等等。偏好包括用戶自我報告的滿意度和舒適度 。 一些設計人員認為，如果他們的設計能迎合用戶的喜好，用戶在該網站上就會有良好的表現。但證據並不支持這一點。事實上，用戶的表現以及他們對產品的偏好並非一一對應。一項研究發現，約有百分之七十的用戶同意表現和喜好有聯繫。也就是說，他們在喜愛的網站上表現良好，在不喜歡的網站上表現欠佳。 然而，還有相對比較大比例的人（ 30 % ）認為 ，用戶的表現以及他們對產品的偏好並非一一對應。他們在不喜愛的網站上可能表現良好，在喜歡的網站上也可能表現不佳。 關於人們為什麼會對自己表現欠佳的網站給出較高的評價有多種解釋。他們可能會把表現不佳歸結到自己，而不是網站。或者說，他們可能擔心給一個較低的評價會傷害網站設計者，也就是我們的感情。或者說，他們可能並沒有完成任務，卻自認為成功完成了，他們並沒有意識到問題所在。基於所有這些理由，我們建議你：更多地依靠用戶的表現，而不是他們的偏好。
把你掌握的測試結果套用起來
可用性測試不僅僅是用於核對項目進度的一個里程碑，你要知道，當最後一個參與者完成任務的時候，可用性測試還沒有結束。整個團隊必須仔細研究結果，設定優先次序，基於結果對或者網站原型進行修改。
基於用戶體驗，找出問題的最佳解決方法
製造任何產品，包括大部分網站和軟體，需要考慮許多不同的用戶的工作方式、體驗、問題以及需要。大多數項目，包括設計或修改網站，都要處理時間、預算和資源等方面的限制。平衡各個方面對大部分項目來說都是一個重大的挑戰。 在你權衡利弊時，最好優先開發那些能使最多用戶完成任務的網站或軟體。有研究表明，產品推出後，用於支持失敗客戶的花費遠遠高於開發時對產品修正所付出的花費。 你需要認真考慮假定用戶、使用場景以及可用性測試的結果，試圖找出針對不同客戶需求的理想解決方法。找不到最好的解決方法，用戶就不能夠順暢地完成任務。有證據表明，即使用戶延長使用時間在一個不太完美的產品界面完成任務，也遠不及在一個更好的產品界面帶來的成功感。
實用性
無論使用正式的或非正式的設備你都可以做可用性測試。使用任何類型的設備，你都可以採用各種正式或非正式的方法。
可用性測試的地點
使用下述任何一種設定，你都可以進行有效的可用性測試：
* 兩室或三室的固定實驗室，配備視聽設備
* 會議室，用戶的家或工作室，配備攜帶型錄音設備
* 會議室，用戶的家或工作室，沒有錄音設備也可以用人眼觀察和筆記來代替
* 當用戶在不同地點可以遠程控制
因此，即使你沒有或沒法找到一個固定的實驗室，你也應該進行可用性測試。不要說，“因為我們沒有一個可用性實驗室，所以我們沒法做可用性測試。" 只要去做！在任何空間你都可以完成。
可用性測試需要多少人參與
看情況。一個典型的測試需要8至16個人（每用戶組）。如果每個用戶將花費一小時，就意味著每個用戶組的測試需要一到兩個工作日。 當你的項目處在： * 紙上原型或早期開發階段 * 計畫通過幾輪測試整個開發 * 有相當一致的用戶群 如果只要人幫忙找出嚴重問題，你可能只需要4到6人。 * 如果您有不同的潛在用戶群組（例如醫生、病人、研究人員），你需要所有這些群體的用戶代表。如果你對用戶的電腦操作或網路經驗有要求，還需要包括經驗較少的和經驗較多的用戶。 * 如果你要對你的產品或系統進行正式的定量測試，你將需要更多的人以獲得統計上有意義的結果。對於診斷型的可用性測試，6至8個用戶通常是不足以揭露產品的大部分問題的。 * 如果在網站開發過程中你一直在做疊代（重複）的可用性測試，就會有許多用戶參加其中一個或另一個版本的網站測試。因此，儘管每個可用性測試只有少於10名的測試參予者，但在網站推出前你可能需要15到30人參加測試。
做可用性測試需要多少費用？ 成本要看網站的大小，你的測試量，預期的用戶類型數目，以及你期望這個測試正規到什麼程度。 如果你已經有一個標準的測試程式和可用的材料設備，可用性測試將進行地很快很便宜。如果你或你的用戶招聘公司擁有一個用戶資料庫，用於招募的時間就可以大量節約，因此，花費會更少。
可用性測試的預算
應該考慮這些因素：
* 計畫所用的時間：確定測試的主要問題，需要測試的用戶類型，招聘的用戶的篩選問卷以及測試場景。
* 招聘的花費：公司人員的時間，給招聘公司（通常是一個很好的選擇）的花費，可用性專家需要花時間熟悉網站及其製作團隊，設計相應的測試場景，如果你需要錄製測試過程，還需要花費實驗室或攜帶型攝錄設備的租金。
* 團隊觀察用戶（進行測試）花費的時間
* 付給測試參與者的報酬或禮物
* 分析視聽資料，查找存在的問題以及推薦解決辦法所用的時間
* 和開發人員討論變動和修改方案，撰寫調查結果和建議報告所用的時間。
記住，預算分析要包含多個可用性測試。打造一個網站（或產品）的可用性是一個反覆疊代的過程。你會發現，用在在開發過程中幾個小測試的預算比起在項目末期只做一個大型測試要有價值的多。網站可用性測試是為了實現跨形式的視覺一致性，包括測試螢幕解析度改變時的顯示，邊距和列布局，表單的顏色和大小，標籤使用的字型，按鈕的大小，所使用的熱踺或快捷鍵，使用的動畫/圖形，按鈕等控制項的標籤，同一欄位的文本框的長度，日期和時間欄位的格式。
