定义/说明：
我来自哪里，当我们准备好新功能后，质量检查人员对核心功能进行了30分钟的快速基本接受测试。 “如果此功能被破坏，我们将被下沉，公司将关闭，我们都将失去工作”，这是进行此内部验收测试的决定因素。
我现在在哪里，当我到达时在这里，他们将构建，并且没有人重新测试核心功能。因此，我去了（非常有耐心的）经理，并每周x进行一次内部验收测试，把他卖了。 （由于构建是连续进行的，因此每次推送新构建都不现实）。我很高兴！发现了许多重要的错误！
设计此测试时，我努力将其保持30分钟。随着时间的流逝，已添加了越来越多的功能。我们必须在3个版本上测试1个平台，并且，正如我们通常会发现的错误一样，这种验收测试已经变得很容易在糟糕的一天花费2个小时。我们需要验证客户和质量检查错误的正常工作流程，但我担心它花费的时间太长-可能由于执行时间太长而无法完成。
我的问题是：我应该保持30分钟吗？那是我当时唯一要经过的例子。
预先感谢。
#1 楼
听起来这是您对现有功能所做的唯一回归测试，对吗？听起来您在测试中发现了有价值的错误，并且您的经理很欣赏它的价值。这听起来也像您与执行此测试有冲突的其他工作一样。
“我们必须在3个版本上测试1个平台，并且由于我们通常会发现错误，因此在糟糕的一天中，这种接受测试已变得很容易花费2个小时。”
这也是重要的一点：如果您要查找和报告错误，则可以节省测试时间。足够了，这样您实际上可能只花了30分钟进行测试，而其余时间则报告了您发现的错误。
我认为解决难题的方法不一定在于计算多长时间应进行验收测试。听起来您的工作还有很多潜在的工作要做，而不是您当时拥有的工作：鉴于测试本质上是一种提供信息的角色，因此，由您的涉众决定哪些信息对他们最有价值。
我的建议是您尝试两件事：
错误分析：
尝试分析关键类型（由您的涉众判断） ）您遇到的错误-不必过于担心准确地对每个错误进行分类，因为这会浪费大量的时间。取而代之的是，尝试对大多数错误似乎来自哪里建立一个非常广泛的概图，足以使您可以去找经理，说：“我们似乎收到了很多这种特定类型的错误，这需要花费大量的时间。寻找和报告大量的测试时间可能值得研究是否可以采取任何措施来减少这种性质的错误首先被引入的可能性，或者降低查找和修复它们的成本。 “
对测试进行优先排序：
在验收测试期间，检查要测试的区域。回到您开始时，所有这些都是“如果失败的话我们会下沉”的测试。这些测试是否仍然同样重要，或者在那段时间对业务重要的事情有变化吗？从那以后潜入的所有内容都同样重要吗？复习这些内容可能会发现，虽然有很好的测试，但是它们却不如您要做的其他工作那么重要。
如果您能够获得要测试的领域按优先级的高低顺序排列，您可能建议您尝试对接受测试进行时间限制：一旦达到商定的时限（包括在错误报告上花费的时间！），便会停止。如果您对通常要查看的领域有优先顺序，那么您就会知道，首先要考虑对利益相关者最重要的领域。
考虑到您的时间有限并且您不可能做任何事情，这也使他们更容易决定哪些信息对他们最有价值，当您停下来时，请转到经理说：“这些区域尚未经过测试。您现在是否愿意让我们停下来，还是应该对我们已有的一些客户错误进行搁置/推迟测试，以便继续进行？我们达到目的是让您对发布感到自在吗？“
#2 楼
听起来好像是在指烟雾测试，所以我将以此为参照。烟雾测试的时间长短取决于您的产品，组织的风险厌恶程度以及可用于烟雾测试的资源。在我的第一份质量检查工作中，冒烟测试可能会占用一个人的整个上午，但是在冒烟测试期间检测出灾难性缺陷可以节省整个质量检查和开发团队的许多倍，因此值得进行投资。
只有您和您的团队才能决定如何权衡冒烟测试时间，并冒着使用带有“如果此功能被破坏，我们就被沉没”的缺陷的风险。您应该随心所欲地更改烟雾测试，具体取决于哪些功能是应用程序其余部分的瓶颈，哪些功能进行的更改最多，以及使用这些功能的开发人员的历史缺陷率。 />这里有一些需要考虑的问题：可以自动执行部分烟雾测试吗？在我的第一份质量检查工作中，安装产品可能需要几个小时。我们找到了一种使过程自动化的方法，这使烟气测试仪的工作变得更加轻松，而不会招致任何重大风险。
#3 楼
验证构建所需的时间因各种因素而异。确定场景中最佳时间的一种方法是输入以下各项的数字：
否。测试人员数量
没有的功能
平均。每个测试人员每个功能花费的时间
（您的情况）要测试的版本号
一旦有了这些数字，请提出1个测试人员测试所有功能所花费的时间1个版本（假设其他2个版本具有相同数量的功能）。然后对所需的总时间进行所需的数学运算。
在我们的项目中，我们观察到，由2位测试人员对大约100个功能部件进行验收（烟）测试所花费的总时间为4 - 6小时。
#4 楼
如果应用程序从未获得新功能，则完全回归验收测试实际上只能是一个静态值。添加新功能（包括对新的Web浏览器，新的操作系统等的支持）之后，您需要添加测试以涵盖该新功能。说需要将其限制为30分钟是不现实的。如果这不起作用”，那么您需要花时间进行范围控制。添加新功能后，您需要问：“这是掉落物品吗？”？如果是，那么下一个问题是：“值得延长此产品的时间，还是取代现有产品？”如果是前者，则您的时间会延长以测试新功能。如果是后者，则要找出哪些现有项目不再具有较高的优先级，请将其删除并重新配置测试。归结为整套回归测试之间的区别所有功能，以及对那些“掉落”的基本物品进行“烟熏测试”。完全回归可能仅限于每周一次。但是就其性质而言，冒烟测试可以每天进行一次，如果时间不太长，甚至每个构建可以进行一次。
#5 楼
任何时间都可以，只要可以为您节省更多的时间即可。因此，如果测试需要运行一个小时以防止30个测试人员在创建新部署时五个小时内测试不良构建，就可以了。我会认真地尝试投资自动化以获取时间尽量减少。自动化的自动化几乎可以像运行手动测试一样麻烦，但是通常这是一个很大的胜利。
如果您的产品无法实现自动化，则可能是架构问题。尝试说服团队让新功能通过设计可测试的自动化。
评论
我绝对喜欢这个答案。为了进一步说明错误分析，我建议Laura（和其他任何人）阅读Gerry Weinberg的“软件为什么会遇到麻烦”（smashwords.com/books/view/25884）。
– Lyndon Vrooman
2011年5月12日23:51
您和其他人一样给了我很多思考的空间。我的经理一直乐于变革和改进，但他是唯一的经理。我和其他所有人（其他经理和同事）一样遇到障碍。听起来我需要更改此方法。最初作为核心功能的快速基准，实际上已经变成了迷你回归套件。当然，这不是我的第一选择，当然也不是行业标准，但这是我面临的现实。我将整理这些建议，并阅读@Lyndon的建议电子书。谢谢大家！
–劳拉·亨斯利（Laura Hensley）
2011年5月13日14:19