我继承了一个没有有用要求/规范，也没有测试的 Web 应用程序。我目前正在查看的页面设置应用程序的配置选项，包含 46 个选项。每个字段的测试验证、最小/最大/默认值等表明这一页需要数百次测试。
您将如何将其分解为更易于管理的内容？一个包含大量输入和预期结果的测试用例？数百个测试用例？介于两者之间？特别是如果大多数测试都是手动开始的......
更新：在 user246 的回复之后，这里有更多信息，否则会占用太多空间作为评论。
user246 的假设是正确的——我目前正在尝试研究如何记录和执行测试，而不是如何自动化它们，尽管这当然是最终目标。
应用程序本身相当老旧，使用 ASP.NET WebForms 编写并使用 DevExpress 控件库，因此验证例程应该是一致的，假设它们已由开发人员正确配置。应用程序和 DX 控件不适合轻松进行自动化测试（我尝试过 Watin 和 Selenium，但没有取得很大成功）。
我仍在试图弄清楚交互在哪里 - UI 当然不会暴露表单字段之间的任何连接，事实上，配置字段几乎按照它们添加到表单的顺序出现 - 没有太多迹象表明设计/规划。
大卫，
我已经对这个确切的问题进行了很多思考，并且我很乐观地能够帮助分享一些您认为有用的技巧。不幸的是，几段的解释可能不足以详细回答您的问题。如果你想谈，我很乐意今天通过 Skype 谈；我将通过 LinkedIn 向您发送我的 Skype 详细信息。
您所描述的是组合爆炸；当配置设置和用户操作以及输入的数据等导致无法测试所有内容时，您如何聪明地选择测试子集，以便在有限数量的测试中尽可能彻底地测试 SUT。
它与测试 Google 地图的测试人员所面临的一般组合爆炸类型非常相似（无论它最初看起来是否相似）。
适用于许多团队（用于 Web 测试或几乎任何类型的测试）的建议方法的缩写版本如下：
在您探索系统并对其进行测试以找出“弱点在哪里”时，您可能会发现尽可能多地改变事物是有用的，尽可能少地重复您的操作。无论您是在进行相对非正式的、记录较少的探索性测试还是记录较多的测试脚本，这些观点都是正确的。此外，由于大部分缺陷可以由两个测试输入的交互触发，如果你有时间，测试涉及两个测试输入的每一个可能的组合会很好；这就是allpairs、pairwise 和正交基于数组的测试用例优先级方法背后的基本原理。
我强烈建议您查看此处的 Google 地图测试计划示例：https ://app.hexawise.com/share/94JBFALL ，然后尝试为您的 SUT 设计一组类似的草稿测试。
您创建的草稿测试会很好，但并不完美。它们会在相对较少的测试中涵盖很多内容，但建议您添加其他类型的测试，而不是依赖任何一种特定的测试策略。
不幸的是，需要登录我们的测试设计工具才能详细查看该 Google 地图示例。因此，我在 david.keaveny@stackexchange.com 为您创建了一个免费帐户（我知道这不是您的真实地址，但我不得不使用一些东西）。我已通过 LinkedIn 将您帐户的密码发送给您。
要为自己重新创建一个类似的 - 非常早期的草案 - 计划，我建议通过以下步骤将相对少量的信息丰富的端到端测试放在一起：
单击“创建测试”按钮，您将立即获得一组非常漂亮的 DRAFT 入门级测试集。如果它们看起来比较有趣并且不会错过非常重要的东西，请开始非正式地执行它们，并且您一定会在处理系统的弱点时学到更多的东西，这些弱点会导致您回到那些DRAFT 测试并对其进行迭代以使它们更强大并覆盖更多。
不幸的是，这是一个相当“抽象”的例子，在本文中没有一个实际的例子。可以在 http://hexawise.com/case-studies/insurance 和 http://hexawise.com/case-studies/mortgage 找到一些可能使这种方法更加“真实”的示例。如果您有兴趣并且想多谈，我很乐意解释您如何尝试将此方法应用于您的特定 SUT。
我希望这有帮助。不过，同样，它可能会给您留下比答案更多的问题。如果您觉得它有用，我很乐意通过 Skype 交谈。
欢迎来到 SQA，大卫。我怀疑我们中的许多人都处于同样的位置——我当然有。
您没有就自动化什么征求建议，所以我假设您最感兴趣的是如何记录和执行这么多选项的测试。减少工作量的一种方法是调查 46 个选项是如何实施的。他们共享的代码越多，测试工作就越容易。例如，如果每个选项都有一个最小和最大数值，并且同一段代码对所有选项执行范围检查，则您可能不需要为每个选项测试范围检查逻辑。
就记录而言，我的目标是尽可能多地消除样板——正如你所说，你应该瞄准“一个巨大的输入和预期结果表”。如果一组选项属于同一类型，您应该描述一次测试该类型选项的过程，然后可能枚举该类型的选项。
我注意到您没有提到选项之间交互的任何测试。如果您需要查找仅在某些值组合出现时出现的错误，那么您的测试问题就会变得更大。幸运的是，有一些方法可以处理组合测试问题。参见示例测试选择技术，提供大量测试用例。
我会选择一个测试用例，再加上巨大的输入和预期结果表。
一个页面上的 46 个选项对我来说听起来像是一场 UI 噩梦。但是，如果您遇到这种情况，您可能需要考虑一些数据驱动的测试自动化。脚本非常适合从表中接受输入和预期输出，并快速驱动您的页面通过所有这些。
有时您可以直接通过自定义控件实现自动化，有时则不能。在后一种情况下，请尝试其他不太直接的方法，例如复制到剪贴板并从那里读取结果。只有在没有其他方法的情况下才使用图像比较。
你知道你的用户是如何使用它的吗？您能否获得真实的实时数据以查看是否使用了所有这些选项，或者帕累托数是否会影响 80% 的用户使用 20% 的选项？
你的测试目标是什么——为什么要求你这样做？它是活的和越野车吗？是否进行了改进？
它通常是固体还是片状？做一些探索性的测试并找出答案。您是否必须走测试用例路线，或者您可以设置一些章程并以这种方式进行测试（您知道章程吗？）