您正在為網站開發功能。 這是一個簡單的登錄表格。 由於您是個精通軟件的超人，因此您決定先進行一些基本計劃，然後再進行開發。 至少，您要確定要構建的功能的某些方面。
這就是你的想法； 你需要：-
· 用戶名和密碼的輸入框
· 提交按鈕
· 一種通知用戶是否輸入了錯誤的詳細信息的方法
· 某種方法來恢復被遺忘的細節
· 如果他們還沒有帳戶，可以通過某種方式註冊
即使簡單的功能也可能難以設計。 您已經列出了要跟蹤的五件事。 也許它不止於此。 沒有適當的規劃就著急開發功能很瘋狂，但是您知道這一點，並且已經在上面編寫了清單。
那麼，夠了嗎？
好吧，如果您想編寫某種行為測試該怎麼辦？ 您如何將以上內容轉化為用戶步驟？ 這樣的"簡短標語"方法是否可以告訴您有關用戶實際如何執行這些操作的足夠信息？ 您是否考慮過用戶成功登錄後會發生什麼？ 這種方法是否鼓勵這種想法？
我們知道我們需要什麼，但是這如何轉化為精心設計的功能？
您可能猜到了答案：驗收標準。
什麼是驗收標準？
接受標準是一組步驟的不必要的模糊名稱，這些步驟可繪製出用戶可能如何與特定功能交互的信息。 它們以使用"給定"，"何時"和"然後"步驟的格式編寫，並映射到用戶操作。 因此，它們很容易轉換為行為測試。 以這種方式設計功能也是識別使該功能正常工作可能需要的其他好方法。
您的登錄表單的接受條件示例如下所示：
Given I have an account registered with
給定標識了該操作的某種先決條件。 什麼時候指定動作。 然後定義動作的結果。 我們還可以使用And通過添加額外條件來補充任何階段。 這種方法是邏輯，清晰和簡單的。 這些步驟中的每一個都準確解釋了該場景中預期發生的情況。
我們也可以輕鬆地為此編寫行為測試，因為我們確切知道涉及的設置，動作和結果。 我們有測試的前提條件：用戶必須擁有一個帳戶。 我們有一個動作：用戶單擊登錄按鈕。 我們得到的結果是：用戶已登錄並查看主頁。
該AC還為我們提供了一些額外的信息。 在編寫它時，我意識到我不知道用戶成功登錄後會怎樣。格式化這樣的要求迫使我不得不思考，從而推動了產品設計和用戶體驗。
最後，藉助格式，AC鼓勵您採用更合乎邏輯的思維方式，並且由於使用了"然後"，因此可以確保您仔細考慮用戶操作的結果。 它使您關心的是用戶可能會如何體驗您的應用程序，而不只是關注您想製作的所有有趣的東西。
我如何寫好的交流電？
因此，您在編寫這些東西時大受歡迎，但是您如何正確地做呢？ 上面的登錄功能非常簡單，但是更復雜的概念可能會導致AC混亂，因此請務必牢記以下幾點：
· 從用戶角度撰寫
這是規則編號。 接受標準與您作為開發人員如何與某些事物進行交互無關。 這與您如何希望某人與某物進行交互無關。 您必須假裝自己是地球上最無助和最令人討厭的事物：用戶。 因為那將是誰來處理您寶貴的登錄表單。
2.簡單性
AC應該很容易理解。 嘗試將每行映射到特定的用戶操作或先決條件，例如輸入正確的用戶詳細信息或已在應用程序中註冊。 試圖包含多個事物的冗長的AC可能會影響清晰度，從而否定上述許多好處。
3.樸素的語言
這一點與第2點有關，並直接影響它。 用簡單的語言寫AC。 這種方法的主要優點之一是非技術人員可以理解它。 能夠向任何人描述功能並同時推動實施/測試的工具非常寶貴。 複雜的語言會妥協。
4.避免實施細節
AC應該描述用戶如何與功能交互； 它不應描述該功能的外觀或其在幕後的操作方式。 您實現某些事情的方式會並且會比想法本身更頻繁地發展。 登錄是很常見的，但是提交按鈕的顏色或它使用的身份驗證提供程序的顏色與放屁一樣具體。
5.不要技術
同樣，這一點與上述內容有點相關。 不要提及算法或機器學習，也不要說線粒體是細胞的強大力量。 沒關係
交流本身是否足夠？
不，這只是起點。 它可以驅動您的設計，可以傳達您的願景並可以幫助您進行測試，但這不是萬能的。 您仍然應該編寫子任務，以更好地定義功能的更多技術方面，創建模型並編寫具體示例。 所有這些東西都是有效且有價值的，應該使用，但是寫得很好的接受標準是一個堅實的起點，並且如果正確完成，將始終會帶來質量更高的軟件。
除非您是Adobe，否則無論您做什麼都不重要，它仍然會變得很糟糕。
(本文翻譯自Lee McGowan的文章《Software Design: What is Acceptance Criteria and why do you need it?》，參考：https://medium.com/javascript-in-plain-english/software-design-how-to-write-good-acceptance-criteria-b4aed47b4ad7)
閱讀更多 聞數起舞 的文章
