我不是软件测试人员，但他的任务是为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中，您将通常测试该场是否以任何方式正确并期望得到适当的反馈以解决问题。
第二种情况更容易编写，但缺点是您希望得到来自其他人的精确信息和反馈（这可能总是会导致不满意，不足或结果不一致）。
希望这有助于多一点。