結構化UAT方法

Question

作爲開發人員，我經常發佈不同版本的應用程序，我希望用戶通過測試來識別錯誤並確認要求得到滿足。

我給用戶一個粗略的想法，說明我已經改變了什麼，或者需要測試的新功能，但是這看起來有點麻煩，而且結構也不是很好。

我想知道在迭代開發過程中，在詢問UAT時，其他方法或程序。

謝謝。

Answer 1

通常，我在excel中爲每個功能列表和「預期結果」和「實際結果」列創建一個腳本，預期結果列中填寫了應該發生的內容。爲了我自己的用途，我加入了一個欄目，即項目的ID。這與Team System的任務ID或創建的項目計劃中的WSB相對應

Answer 2

我發現編寫測試腳本耗時耗時，通常比將修補程序置於其位置所用的時間要長。由於我們在這裏所做的大量工作，我們沒有時間創建有效的測試腳本。

隨着我們的變化，我們通過兩個層面的測試，應用支持和業務接受度。我們希望通過技術方法和業務方法來對變革的大部分方面進行測試。爲了讓他們知道他們應該測試什麼，我們附上一個由更改（添加產品，刪除產品，編輯產品）所影響的操作列表。

在我看來，這與單元測試方法相結合是高容量環境的最佳方法。

Answer 3

用戶故事或用例可能是您正在查找的內容，您是如何決定首先進行更改的，以及您是如何指定它的。如果你寫了一個小故事，或者更大的一個實際的結構化用例，你可以用它作爲你的改變規範，然後用戶可以測試這個故事，看看實現是否與描述相匹配。

Answer 4

您正在尋求一種有效且有效的方式來以結構化的方式進行UAT。我強烈建議使用成對或組合測試設計方法。我已經在超過二十個概念驗證項目中使用了這種方法，並發現與傳統的手動識別測試案例的方法相比，這種方法始終導致每個測試者小時發現更多的缺陷。實際上，正如我在最近的IEEE計算機article中報告的平均情況一樣，我們發現平均每臺測試儀小時的誤差爲2.4×X，平均爲。

該方法在視頻here中描述。道歉，如果這似乎是一個「使用我的工具」插件。我不是這個意思。這是方法，這將帶來巨大的好處，而不是您選擇用來設計測試的特定工具。 James Bach還在其satisfice.com網站上提供名爲AllPairs的免費工具。我的觀點是，使用任何這樣的工具將產生顯着優異的結果，因爲這些工具旨在以最少數量的測試產生最大覆蓋率。他們避免重複;此外，他們還可以自動識別並消除手動測試案例識別方法無法關閉的覆蓋範圍中的潛在差距。

儘管像Hexawise這樣的工具能夠識別（以秒爲單位）UAT測試用例應該比測試人員能夠識別和記錄（在幾天內）更好地運行，儘管如此。自己嘗試一下。讓團隊中的一名UAT測試人員執行由Hexawise創建的20個端到端「黑匣子」或「灰盒子」測試，並讓其他測試人員測試他們通常會進行的測試。我敢打賭，測試人員執行20個Hexawise測試會在每個測試小時中發現更多的缺陷（並且會發現「重要」以及「不重要」缺陷）。

這些類型的方法在相對複雜的測試人員羣體之外，在測試社區中並不是很出名，他們花時間閱讀了Lee Copeland關於測試設計方法的書籍。成對和組合方法一致地工作，它們在效率和有效性方面提供了巨大的改進，而且測試團隊很容易立即開始使用它們。

賈斯汀（Hexawise的創始人）