用敏捷方法编写测试用例

Question

我用传统的方法开发测试用例，方法是为每个测试单元定义以下内容：

1. 测试用例名称。“查看当前事务”
2. 前提条件。
   • 有效“用户名和密码”
   • 系统已经启动并运行。

3. 测试用例步骤
   • 登录到系统。
   • 点击“管理帐户”
   • 点击“查看当前事务”

4. 预期结果
   • 系统应从最近的事务开始显示用户事务。

我必须为任何异常情况创建单独的测试用例，例如:当事务失败时，事务需要批准等…。。

上面的方法会很好地工作，但是它需要大量的时间，测试用例文档将非常大(取决于课程的项目规模)。那么，这是记录测试用例的正确方法吗？还是有一种更灵活的方法，导致同样的结果，但在较少的时间和努力？谢谢

Answer 1

我认为敏捷测试人员应该帮助他们的产品负责人在用户故事中编写验收标准。如果用格尔金编写场景，则可以创建与测试的四个条件相匹配的手动测试用例。

  Scenario: Some action (1. Name)
    Give I am logged in (2. Pre-condition)
     And I setup something else
    When I do some action (3. Test case steps)
     And I click somewhere
    Then I get some result (4. Expected results)
     And I verify there are no errors

就我个人而言，我喜欢Cucumber框架，因为您可以将您的案例作为自动化测试重用，请参阅http://cukes.info/或阅读Cucumber图书中的starters http://pragprog.com/book/hwcuc/the-cucumber-book。

编写场景的前期(开发前)的主要原因是让反馈回路尽快启动。通过写下高层次的案例，您的产品负责人不得不考虑它的用户故事。虽然我看到了手动测试套件的附加价值，但我会推动自动化测试套件，因为您希望尽快得到反馈，并且团队不希望等待QA团队完成测试。

问问自己，我(作为一个测试人员)如何帮助团队在迭代中完成和交付PBI，而不是在开发团队完成之后进行测试，并在几天或几周后给出反馈。

其他内容如下：

• https://less.works/less/technical-excellence/specification-by-example.html

Answer 2

取决于项目的质量要求及其用户故事的成熟度。如果测试必须由编写测试用例的同一个人完成一次，那么记录测试用例步骤将不是必要的，也不是不可忽视的。另一方面，一个需要在很长一段时间内进行不同阶段的回归测试的项目--特别是涉及多个测试人员的频繁交付--需要您的方法。每个bug都链接到其测试用例，该测试用例与其相应的用户故事相链接。根据测试用例结果及其链接错误，可以得出用户故事的状态，以确定它是否可移植。测试用例还记录了产品的行为，以便在引入更改要求时很容易检查各种场景。因此，测试套件的努力和质量取决于产品的质量是和应该投入多少。