为业务逻辑层（烟雾，回归等）设计手动测试用例？

Question

我有兴趣整理一些手动测试用例，以验证特定Web应用程序的BL是否按预期运行。

不幸的是，UI和BL层之间的耦合足够高，如果我们想要使用像Fitnesse等工具执行任何自动化测试，我需要花费相当长的时间，我不认为它是在当前截止日期等的时间价值支出

我的问题是，在上述情况下执行手动测试（测试将按照定义here）是否合理，如果是这样的话：

• 系统测试BL层的详细程度如何？
• 在一般系统测试和烟雾测试的情况下，设计每个测试以满足特定要求是否足以覆盖？

示例：

REQUIREMENT: If a user provides two cost entries for the same type of
       item, the application will take the higher of the two costs, and zero
       the second.
TEST: Add two cost entries, both for vehicle use, submit the ticket. 
      Verify that the invoice for the ticket only shows the higher of the two.

• 在设计手动测试时我还应该考虑其他什么？

Answer 1

  

系统测试BL层的详细程度如何？

您的系统需要支持多长时间？你发货后，任何人都需要再次回归测试吗？如果是这样，测试必须足够详细，以便他们能够根据文档运行测试。否则为什么还要打扰他们呢？

使用正确的工具，即使您的UI和BL耦合，也可以通过UI自动执行黑盒测试。如果您的系统存在多年并且回归成本很高，您应该考虑尝试通过UI自动化测试。可执行测试用例比书面测试用例文档更有价值。

  

在一般系统测试和烟雾测试的情况下，将进行设计   每项测试以满足特定要求即可   覆盖？

至少，您还需要进行探索性测试并尝试在边缘情况下破解程序，以便在手动测试时最大化您的投资回报率。测试快乐路径会产生比在边缘情况下破坏它更少的错误。

还要考虑要求中的任何遗漏。根据您的需求的抽象级别，可能会遗漏许多场景。

Anything else I should take into consideration when designing manual tests?

尽你所能自动设置测试装置和锻炼系统。即使您不能在自动化测试中增加额外的步骤，如果您可以立即设置测试夹具，也可以节省大量时间。