我目前正在使用 Quality Center 进行测试用例管理，它具有类似的结构。我发现在每个步骤的预期结果部分是写下一些您将在基本“操作完成且没有错误”之外寻找的项目的好地方。

当应用程序处于该状态时，您可以提及一些其他要问的问题。我认为它对于任何平台来说都是一个很好的模板，但如果我不相信它会有多大价值，我也没有问题将“预期结果”步骤留空。

我过去曾为此使用过 Excel，它的单元格限制是强制执行简洁描述和注释的一种方式，因此案例不会变得太大。它允许我们用案例制作一张工作表，并将它们拉到其他工作表中以用于场景，这样我们就可以在不同的条件下测试这些步骤。设置起来有点麻烦，但是一旦我们学会了这个系统，它就很容易做到，它还允许我们在 Excel 文档中汇总结果，然后将汇总汇总到涵盖所有案例的更高级别的文档中；该公司喜欢 Excel，所以我们使用了他们想要的东西。

当我们实现这个时，我们通常保持较小的预期结果，这个想法是只知道足以验证案例，而不是写下关于它的所有内容。尽管正如托德所说，如果您没有找到相关信息，请不要添加它。

是的，我已经根据需求和模块编写了Web应用程序，移动应用程序的测试用例。编写测试用例的格式不同，我们使用的格式不同，但是需要一些字段来编写测试用例。通常写测试用例我们可以使用excel。

见上面的测试用例图片，其中测试用例描述，预期结果，实际结果，前置条件字段应该是必需的。在测试用例中记住预期和实际结果应该相同。进入移动应用程序定义编写移动应用程序测试用例所需的所有字段。

我喜欢AAA 模式：

测试名称：

• 安排所有必要的先决条件和输入。
• 作用于被测对象或方法。
• 断言预期的结果已经发生。

虽然是为单元测试设计的。我认为它涵盖了手动测试用例所需的所有内容。为您的 Act 中的每个步骤创建断言似乎有点矫枉过正，尽管有时我想确定在 Arrange 之后某些东西处于某种状态，因此我确实在 Act 中添加了 Asserts。

保持你的测试小而短，并尽量保持最少的断言数量。尝试将 Act 步骤保持在最多 10 个或尝试在多个情况下拆分测试。

我认为不需要注释字段，因为这是缺陷跟踪器的用途。如果测试用例失败报告它！:)