该产品的许多新功能开发都是由客户驱动的，因为客户提交了具有要求的变更请求，并根据这些要求进行了开发。但是，在对变更单的那些要求中，对于客户现有的配置并不总是透明的，因此对于那些非标准配置的风险因素也不是很清楚。因为一旦发布了新功能，这些新功能便按照当前的维护合同发布给了所有现有客户，则风险管理要求我们将大部分时间和精力集中在那些常用的配置上。
我遇到过许多非标准配置严重咬我们的情况。实际上，要知道这些的唯一方法是拥有客户端当前配置的精确副本。但是，由于有数百个客户端的客户群，每个客户端都有不同的配置，因此为了进行任何开发工作，通过所有客户端数据运行测试似乎不切实际。
因此，有时需要在测试过程中使用客户端数据。但是，还需要优先考虑对大多数客户产生最广泛影响的测试用例。这些似乎部分是相互矛盾的需求。
然后的问题是：软件开发组织如何构建和修改如此高度复杂的项目，从而确定何时在预发布测试过程中使用客户数据，同时仍然保持必要的时间风险评估交货期限？
#1 楼
在我的团队中，过程很简单。我们没有自动化测试，因此，我们获得的几乎所有东西都是使用现实世界的数据，通常是一周，一个月或更旧的数据。当有人将其拧紧或需要说明生活中发生的事情时，它会刷新。您尝试在一直使用的系统上重现它。
如果不能访问该目录，则可以找到有关其设置的更多信息，然后转到具有该配置的系统。
如果仍然无法复制该文件，我们要求刷新
如果我们仍然不能从实时配置中复制它，那么我们假设用户在撒谎（实际上已经发生了！），或者他们真的不理解该过程。 / error / scenario，只认为有问题。这是罕见的，因为分析师通常在将这些“错误”提交给开发人员之前就将其压缩。
最重要的是，您需要一种很好的方法来导出其配置并将其加载到您的配置中。您还没有一个。您还需要一种很好的方法来查找哪些配置标志可能会在它们声称错误所在的区域中引起问题。然后，您不必使用它们的确切配置，而可以在使用很多。
分析非标准配置的最受欢迎和最有问题的组合将为您带来很多帮助。不要测试每个项目（否则您将永远不会完成一个项目），但是获得相当普遍的项目或有导致问题的历史的测试项目将为您带来巨大的成果。
评论
我最喜欢这个答案，尽管@ user246的答案很不错。本质上，似乎在这样一个高度复杂的系统中，您总是会遇到这种情况，即可能需要使用客户数据，但客户数据并非总是正确的答案。
– TristaanOgre
2011年6月21日14:01
好吧，这是双重的。如果数据存在并且说明有问题，则说明您有问题，必须解决。但另一方面，您还必须考虑到，如果您无法重现该问题，则没有很大的机会真正解决该问题。很多时候，这翻译成“好了，只要写一些代码就可以解决它”，这意味着他们没有找到问题的真正原因，所以他们并不真正知道还有什么被破坏。
–corsiKa♦
2011年6月21日在16:14
#2 楼
我曾经研究过具有大量配置设置的金融服务产品，也许与发问者所描述的一样多。我们有很多客户，每个客户都有自己的配置。所有客户都用完了我们在数据中心托管的同一产品安装。我们的数据库包含每个客户的配置设置及其所有数据，因此我们对产品的使用方式了解很多。针对每个客户的配置测试每个功能都是不可行的。但是，在我们的产品中，产品功能永远不会依赖于每个配置设置。我研究了每个功能，以提供该功能所依赖的配置设置列表。该列表可能并不完美-我可能不时地省略了一些内容或不必要地包含了一些内容-但它很接近。我分析了这些设置的可变性，以找出实际使用了哪些配置，以及哪些配置未被未使用的支持。
鉴于这些列表，我编写了自动测试，针对高优先级功能针对产品的交叉产品进行了测试。这些设置，或者，当这不可行时，我尝试使用成对配置。
这种方法并不完美，但它使我们摆脱了决定哪些公司配置最重要的陷阱。自动化测试发现了错误，看来我们的质量有所提高。
#3 楼
配置测试是常见的软件测试挑战。配置矩阵可以帮助概述常见的客户配置，甚至可能帮助确定一些“有趣的”组合。对于高度复杂的配置，好的方法是使用成对或其他n路分析的组合测试方法。关于可能的配置设置。
我建议您查看PICT工具文档，其中提供了丰富的配置测试示例。 http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi
评论
我无法告诉您我从某人那里获得了多少规格，在代码中查看并发现其功能已经存在，他们只需要打开它即可。我听到了，@ glow ...问题经常出现：“嗯，是的，它存在，但是你也可以把它煮成咖啡吗？”
一时兴起，我只是看了看控制标志：我们使用的系统控制表上有301种“逻辑”类型，并且这不算我们曾经拥有布尔值的“单长度字符串”，但是需要第三个选择。公平地说，这意味着它每年仅添加约12-16个标志：)