我对其他人如何组织他们的测试脚本很感兴趣，或者在他们工作过的任何地方都看到过很好的测试脚本。此外，这些测试脚本的详细程度如何。这特别涉及为手动测试创建的测试脚本，而不是为任何自动化测试目的创建的测试脚本。
我看到的问题是，测试脚本有很多复杂性，但没有受益于组织复杂或大型代码库所使用的原则。您需要能够指定一段代码应该做什么，但又不会让某人在阅读它时感到无聊至死。
此外，您如何布局测试脚本，我不热衷于创建适合由数据输入类型运行的完全指定的脚本，因为这不是我们拥有的团队并且维护它们的开销似乎太高了。此外，在我看来，如此详细地指定流程可以免除实际进行产品质量测试的人的责任。人们是否指定每个按钮单击和要输入的值？如果不是，则指定详细程度。
由人类执行的测试应该处于非常高的抽象级别。
例如 stackoverflow 注册的测试用例：
好的：
具有现有 OpenId 帐户的站点访问者注册为 stackoverflow 用户并发布答案。
坏的：
1) 导航到 http://stackoverflow.com 2) 点击登录链接 3) 等等...
这很重要，原因如下：
a) 它使测试保持可维护性。因此，您不必在每次重新标记导航元素时都更新您的测试脚本（例如，“登录”更改为“登录”）。
b) 它使您的测试人员免于因繁琐的细节而发疯。
c) 编写详细的手动测试脚本是对有限测试资源的不良使用。
详细的手动测试脚本将转移您的测试人员为较小的文档问题编写错误。您想利用您的时间来找出会影响客户的真正错误。
测试可以按优先级分组。BVT/烟雾测试可能具有最高优先级，而功能、集成、回归、本地化、压力和性能具有较低优先级。根据您的测试通过，您将选择一个优先级并运行具有该优先级或更高优先级的所有测试。您需要做的就是确定特定测试的优先级。
我尝试让手动测试适应自动化结构——你可以两者兼得。
自动化测试使用的组织方案（例如，xUnit 框架）对我有用。事实上，它们可用于半自动化测试，方法是停止并调用手动测试运行，或输入输入，或检查 GUI。该方案通常是镜像生产代码的目录结构，或者将测试包含在生产代码中，有时作为内部类。单元级别以上的测试通常可以放入更高级别的目录中（假设您有足够深的目录树）。这些更高级别的测试可以进入（镜像）没有生产代码但出于组织目的的目录。
详细程度——嗯，这取决于，对吧？
在一般情况下，马特安德森提供了很好的答案，但在某些情况下，你不能那样做。例如，当您处理经过验证的应用程序时，它必须符合 FDA 等其他方的法规，并且它经过非常密集的审核、审查、签字，而不是您的示例需要 2 个答案。尽管在这种情况下我会选择使用 HP QuickTestPro 或 IBM RationaRobot 实现自动化。
Maybe you should try with some tests repository? There are again tools from HP QualityCenter and IBM products, but this can expensive. You could find some cheaper, that will let you organize them into tree structures, by requirement/feature, assign them priorities, group them into test suits for releases, group them into regression testing suits etc...