用戶測試
用戶測試是由用戶進行的，不是由偽裝成用戶的測試人員進行的，不是由秘書或者執行者偽裝成測試人員、用戶進行的。用戶是使用最終產品的人。
用戶測試是由用戶或測試人員或其他人(有時甚至是顧客軟件合同中接受測試的律師)設計的。用戶測試的集合可能包括邊界值測試、壓力測試或任何其他類型的測試。
設計的有的用戶測試是只由用戶執行他們并報告程序是否通過這些測試的細節。如果你的目的是提供一個周密的、沒有任何顯示錯誤事件機會的系統腳本示例，那么這是設計測試的一個好方法。
如果你的目的是發現用戶在系統實際使用中會遇到的問題，那么你的工作就比較難了。 軟件測試
Beta測試通常是簡單的、有效的用戶測試，但是實際上它們是非常難管理的，并且不會產生大量的信息。關于beta測試的一些建議，請參見Kaner,Falk & Nguyen(1993).
一個好的用戶測試，在給用戶提供足夠的結構來報告結果的有效性時，必須給用戶的認知活動有足夠的余地(在某種程度上有助于讀者理解和解決問題)。
用戶測試中發現的故障一般是可靠的和有目的的。少數用戶會執行特別有力度的測試。但有些用戶會把程序放到復雜的情形下運行。
場景測試
一個場景就是描述了一個假設情況的故事。在測試上，檢查程序如何在這種假設環境下復現。
理想的場景測試是可靠的、有目的的、易于評估的、復雜的。
實際上，許多場景在這些特性中的至少一個上是微弱無力的，但人們依然稱之為場景。這種模式的關鍵信息是當你設計一個場景測試并試圖完成它時，你需要緊記這4個特性。
場景測試的一個重要變異是粗糙測試。故事中經常會有一個僅由普通用戶使用的序列或數據值。然而，他們會出現在用戶錯誤之外，或異常但似是而非的情形下，或敵對的用戶行為下。Hans Buwalda(2000a,2000b)稱之為“肥皂殺手”以區別于稱之為“肥皂劇”的正常情形。類似的情形在安全測試或其他形式的壓力測試下是普遍存在的。
在RUP(Rational Unified Process)中，場景出自使用用例。(Jacobson,Booch, & Rumbaugh,1999)。場景制定了參與者、角色、事務處理、參與者的目標、以及在試圖達到目的的過程中發生的事件。場景是使用用例的一個實例化。一個簡單的場景追溯了一個獨立使用用例的全過程，指定了數據值以及用例中的路徑。一個比較復雜的使用用例會首尾串聯若干個使用用例，來追蹤給定的任務。(參見Bittner & Spence,2003; Cockburn,2000; Collard,1999; Constantine & Lockwood,1999; Wiegers,1999.)警告性注意，請參見Berger(2001).
無論如何他們是繼承來的，好的場景測試在第一次運行時具有很大的力度。
不同團隊多久執行一個給定的場景測試。
有些團隊創建一個類似回歸測試的場景測試池。
其他團隊(像我)一次或在很短時間內執行一個場景測試，然后設計另外一個場景而不是堅持使用一個以前用過的。
通常，測試人員生成的場景能洞察到產品內部。這在測試初期以及稍后的再一次測試中是非常真實的(當產品已經穩定，測試人員試圖了解產品進一步的用途時。)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
