我不是軟件測試人員，但他的任務是爲Web應用程序的某些長客戶註冊表單編寫手動用戶驗收測試用例。書寫Web表單測試用例
我們假設所有表單字段對應於每種表單類型的「there」，並且測試用例以檢查表單功能開始。輸入驗證等 或者，我應該編寫一個測試用例來檢查每個表單標識符是否正確，每個表單字段是否存在，每個下拉列表是否填充等等（我想當一個新的構建產生時，它可能會有一個表單元素/字段有錯誤 - 儘管不太可能）。
如果我要爲許多表單元素編寫測試用例，我可以使用多個斷言來節省時間， 「檢查標識符：text1，text2，text3等存在且正確。」或者它應該是表單中每個元素的一個測試用例。這些表格不可能隨着時間的推移而發生很大變化
我感覺這裏有兩種類型的測試 - 一種是表單正常工作，另一種是組件默認正確顯示。
謝謝。
這一切都取決於您正在使用的要求。
如果您可以確定所有要測試的字段都存在（或者如果這不是測試的目的，因爲有人正在測試此項），則不應該打擾測試它。
如果你正在測試整個事情，這意味着所有的a）工作和b）按預期工作，那麼我建議你將測試分成兩部分 - 只檢查頁面的形式，內容等，它是元素和第二部分，它考慮了一切，並測試它是否正常工作。然後第二部分將包含字段驗證，如「輸入無效的電子郵件」，「在電話號碼字段中輸入字母」，「將必填字段留空」等。
由於實際原因，我儘量保持測試儘可能短儘可能具體。這裏有幾個原因：
如果您發現錯誤，你的整個測試案例將以「失敗」，它更清晰以後找什麼工作，什麼不是，如果測試用例不測試的許多功能沒有緊密連接。如果你舉個例子，如果你在一次測試中測試了存在和你的字段的功能，並且一個步驟不起作用，那麼你的測試將會「失敗」，但是通過查看你的測試活動，你將無法知道哪個部分沒有更深入的細節並仔細檢查執行。
如果您在修復某些內容後必須重新測試某些內容，則無需經過幾十個步驟即可驗證修正。
人們往往會失去焦點，如果他們要執行一個很長的測試情況下，他們可能忘記了這是怎麼回事，等
當然，這在很大程度上取決於手頭的任務，有些東西需要更長/複雜的測試用例，其他測試用例可能非常簡單。
希望幫助
UAT，IME，應當包括完整的步驟，該應用程序的實際最終用戶將根據自己的情況下進行，從開始到結束，並且還包括在TCS預期和實際結果，例如
步驟1：打開瀏覽器/瀏覽器推出後，第2步轉到www.blah.com/blah.com裝載，步驟3單擊登錄字段（如果你需要得到具體的），然後輸入用戶名/字段被選中並輸入用戶名.....一直到你需要測試的結束路徑。
你應該運行UAT案件之前已對您的功能測試，所以你不必來驗證UAT TCS各個領域，但UAT之前，請確保您或您的團隊是煙/功能測試。
我也同意關於分裂測試用例到這當然取決於你在做什麼，究竟特定部分以前的海報。 TC1_導航到頁面TC2_Login TC3填寫個人信息（或通過表單部分）TC4_Fill IncomeInfo ... blahblah。
對於第一個之後的每個tc，您可以從最後一個tc的步驟開始繼續，您不必從「打開瀏覽器」開始＃1之後的每個測試用例，並將所有測試集中在一起作爲一個測試集其中將包括多個測試案例。
你可以寫這個任務兩種類型的測試（閔P.和Dobromir曼切夫的建議）和詳細的測試案例應該是多少，要看事實誰將會進行測試。
我個人更喜歡單獨檢查每個情況下，它更容易找出問題，並最終重新測試。
方案1：
測試01 - 用戶名字段 - 說明 - 預期
- 你測試位置，尺寸，顏色和像
測試02的東西 - 用戶名錯誤的數據 - 描述 - 預計
- 檢查這現場接受不支持的數據類型（長，短，特殊字符等）
測試03 - 用戶名輸入空 - 描述 - 預計
- 檢查現場支持空提交
測試04 - 用戶名正確的 - 說明 - 預期
- 最終，如果數據是正確的，它的行爲
測試05 - 電子郵件字段 - 說明 - 預期
- 你測試位置，尺寸，顏色以及類似的東西
測試06 - 電子郵件正確的形式 - 說明 - 預期
- 您檢查字段是否僅支持正確的電子郵件形式，如[email protected]，並正確處理名稱@郵件，名稱@郵件。等
測試07 - ...
方案2：
測試01 - 用戶名字段 - 說明 - 預期 - 反饋
測試02 - 電子郵件字段 - 說明 - 預期 - 反饋
測試03 - ..
至於描述，你可以填寫這個字段，或者用簡短的描述來描述什麼是測試用例目標，或者是非常全面的。在預期的領域中，你需要寫出準確預期的特定測試結果。在場景1中，它應該是簡單的任務（檢查這一點，結果），在場景2中，您將通常測試該場是否以任何方式正確並期望得到適當的反饋以解決問題。
第二種情況更容易編寫，但缺點是您希望得到來自其他人的精確信息和反饋（這可能總是會導致不滿意，不足或結果不一致）。
希望這有助於多一點。