1

我不是软件测试员，但我的任务是为 Web 应用程序的一些长客户注册表单编写手动用户接受测试用例。

我们假设所有表单字段对于每种类型的表单都是“存在”的，并且测试用例从检查表单功能开始，例如输入验证等。或者，我应该编写一个测试用例来检查每个表单吗？表单标识符是正确的，每个表单字段都存在，每个下拉菜单都被填充等（我猜当生成新版本时，表单元素/字段可能会出错 - 尽管不太可能）。

如果我要为大量表单元素编写测试用例，我是否可以使用多个断言来节省时间，例如“检查标识符：text1、text2、text3 等是否存在且正确”。或者它应该是表单每个元素的一个测试用例。随着时间的推移，表格不太可能发生太大变化。

我觉得这里有两种类型的测试——一种是表单功能正确，另一种是默认情况下组件部分实际上是正确显示的。

谢谢你。

4

3 回答 3

4

您可以为此任务编写两种类型的测试（如 Min P. 和 Dobromir Manchev 建议的那样），以及测试用例的详细程度取决于谁将执行您的测试。

我个人更喜欢分别检查每个案例，这样更容易查明问题并最终重新测试。

场景 1：
测试 01 - 用户名字段 - 描述 - 预期
- 您测试位置、尺寸、颜色和类似的东西
测试 02 - 用户名错误数据 - 描述 - 预期
- 检查此字段是否接受不支持的数据类型（长，短，特殊字符等）
测试 03 - 用户名空白输入 - 描述 - 预期
- 检查字段是否支持空提交
测试 04 - 用户名正确 - 描述 - 预期
- 最终如果数据正确以及它的行为方式
测试 05 - 电子邮件字段 - 描述- 预期
- 您测试位置、尺寸、颜色和类似的东西
测试 06 - 通过电子邮件发送正确的表格 - 描述 - 预期
- 您检查字段是否仅支持正确的电子邮件形式，如 name@mail.com 并正确处理 name@mail、name@mail。等等
测试 07 - ...

场景 2：
测试 01 - 用户名字段 - 描述 - 预期 - 反馈
测试 02 - 电子邮件字段 - 描述 - 预期 - 反馈
测试 03 - ...

至于描述，您可以填写此字段，或者使用简短描述，您将在其中描述测试用例目标是什么，或者非常彻底。在预期字段中，您需要编写该特定测试的确切预期结果。在场景 1 中，它应该是一个简单的任务（检查这个，结果），在场景 2 中，您通常会测试该字段是否以任何方式正确，并期待适当的反馈以解决问题。

第二种情况更容易编写，但缺陷是您期望从其他人那里获得准确的信息和反馈（这总是会带来不满意、不足或不同的结果）。

希望这会有所帮助。

于 2017-05-18T11:37:42.797 回答
1

UAT，ime，应该包括应用程序的实际最终用户将根据您的场景执行的完整步骤，从开始到结束，还包括 tcs 中的预期和实际结果，例如

步骤 1. 打开浏览器/浏览器启动，步骤 2. 加载 www.blah.com/blah.com，步骤 3. 点击登录字段（如果您需要特定）并输入用户名/字段被选中并输入用户名......一直到您需要测试的结束路径。

您应该在运行 UAT 案例之前执行功能测试，因此您不必验证 UAT tcs 中的每个字段，但确保您或您的团队在 UAT 之前进行冒烟/功能测试。

我也同意之前的海报关于将您的测试用例拆分为特定部分的观点，这当然取决于您正在做什么。TC1_Navigate to Page TC2_Login TC3 Fill PersonalInfo（或按表格部分）TC4_Fill IncomeInfo...blahblah。

对于第一个 tc 之后的每个 tc，您可以从最后一个 tc 步骤继续，您不必从“打开浏览器”开始 #1 之后的每个测试用例，并将所有测试一起作为一个测试集包含在内的多个测试用例。

于 2017-05-03T11:15:42.910 回答
1

这一切都取决于您正在处理的要求。

如果您可以确定所有要测试的字段都在那里（或者如果这不是您测试的重点，因为其他人正在测试它），您不应该费心测试它。

如果您正在测试整个事情，这意味着一切 a) 工作和 b) 按预期工作，那么我建议您将测试分成两部分 - 一部分只是检查页面的表单、内容等以及它的元素和一部分两个考虑一切都在那里并测试它是否正常运行。第二部分将包含字段验证，例如“输入无效电子邮件”、“在电话号码字段中输入字母”、“将必填字段留空”等。

出于实际原因，我尽量让我的测试尽可能简短和具体。这里有几个原因：

  • 如果你发现了一个错误，你的整个测试用例将“失败”，如果测试用例没有测试许多没有紧密连接的功能，那么以后会更清楚地发现什么是有效的，什么是无效的。如果您以您的需求为例，如果您在一个测试中测试字段的存在性和功能并且一步不起作用，您的测试将“失败”，但通过查看您的测试活动，您将无法无需深入研究并详细检查执行，即可知道哪个部分有错误。

  • 如果您在修复后必须回来重新测试某些东西，您无需经过数十个步骤即可验证更正。

  • 如果必须执行很长的测试用例，人们往往会失去注意力，他们可能会忘记发生了什么等等。

当然，这在很大程度上取决于手头的任务，有些事情需要更长/更复杂的测试用例，而另一些则非常简单。

希望有帮助

于 2017-04-13T13:31:30.363 回答