我有兴趣将一些手动测试用例放在一起，以验证特定 Web 应用程序的 BL 是否按预期运行。
不幸的是，UI 和 BL 层之间的耦合度足够高，如果我们想使用 Fitnesse 等工具执行任何自动化测试，我将需要花费相当多的时间，而且我不认为它是给定当前截止日期等的时间值(value)支出。
我的问题是，在上述场景中执行手动测试(测试定义为 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.
How detailed should the system tests be for the BL layer?
您的系统需要支持多长时间？发货后，是否有人需要再次对其进行回归测试？如果是这样，测试必须足够详细，以便他们能够根据文档运行测试。否则为什么还要费心把它们写下来？
使用正确的工具，即使您的 UI 和 BL 耦合在一起，您也可以通过 UI 自动执行黑盒测试。如果您的系统将存在多年并且回归成本很高，您应该考虑尝试通过 UI 自动化测试。可执行的测试用例比书面测试用例的文档更有值(value)。
In the case of general system tests and smoke tests, will designing
each test to cover a particular requirement be sufficient for
coverage?
至少您还需要进行探索性测试，并尝试在边缘情况下打破程序，以在手动测试时最大化您的投资返回率。与尝试在边缘情况下打破它相比，测试快乐路径产生的错误要少得多。
还要考虑要求中的任何遗漏。根据您的要求的抽象级别，可能会省略许多场景。
Anything else I should take into consideration when designing manual tests?
尽你所能自动设置测试夹具和运行系统。即使您不能在自动化测试中执行额外的步骤，如果您可以立即设置测试夹具，也可以节省大量时间。