（我写了每晚的构建，但这只有在您进行每晚的构建时才有意义。我怀疑很多商店都没有。怀疑质量检查的执行方式差异很大，并且对其他处理方式的了解非常有限。）
#1 楼
是的，QA是否应该推动运行QA自动化测试的程序员？
是的，但是我还建议，如果程序员似乎不这样做，发现它可能会更有效率指出为什么要更努力。是什么在阻止他们？使用专有测试工具？难以在开发环境上轻松设置？结果不有意义或不易阅读？运行太慢了吗？太脆了吗？
QA是否应该坚持要求他们的所有自动化测试在
检入之前通过？但是如果测试套件要花15个小时才能运行，那么您就有点入门了。 />
是的。
#2 楼
以我的经验...执行，是的。维护NO。上下文以供我评论。我假设您的问题中的程序员=应用程序的开发人员，而不是具有编程技能的测试人员
我认为，测试人员（甚至是测试中的专用软件工程师）有一种固有的动机，即开发人员没有，也就是说，编写，运行和维护测试可以为测试人员的工作增添价值，例如，它可以减少他们的手动测试工作量，并且运行得越好，他们就越需要做其他“测试工作”。 >
对于程序员来说，这是阻止他们添加新功能的另一项任务。
理想情况下，您应该拥有经过培训的开发人员测试人员，这是一部分日常构建和测试过程中，您可以运行质量检查。
如果开发人员想要运行测试，那么他们当然可以，但是您的测试人员应负主要责任。
评论
我听到的一个反对观点是赞成程序员承担维护QA测试的责任，那就是，如果有人进行更改而破坏了很多现有测试，他们应该会感到有些痛苦。
– testerab
2011年5月5日23:30
我听说过，但我不相信它，如果测试是一个共享的框架，那么可以肯定，但是如果我们在QA驱动的测试环境中进行讨论，则开发人员不应该更新它们。如果更改是应该进行的更改，并且测试已经过时，则质量检查需要使用新信息进行更新。如果变化范围更大，则开发人员应修复并通过测试。
– MichaelF
2011年5月10日下午13:11
我同意@testerab自动化专家们不是超人，他们会为每个破坏测试的微小Pull Request继续修复300个测试。这是不可行的。
–阿尼鲁德（Anirudh）
17年7月21日在12:13
特别是当测试和应用程序使用相同的语言编写时，开发人员应该修复他们破坏的测试。
–阿尼鲁德（Anirudh）
17年7月21日在12:14
#3 楼
如果QA团队没有嵌入到开发团队中，我认为整个过程将无法顺利进行。这是因为开发对代码有更多的了解。我会让质量检查小组编写更多的功能测试脚本。#4 楼
我认为这取决于两个主要要素：测试人员是否嵌入到软件工程团队中？您的测试输出对工程师而言是否可理解且有用？
显然，认为工程师可以从没有关系的其他影子团队中进行测试是愚蠢的。但是，如果确实在同一团队中嵌入了工程师和测试人员，则很有可能让测试人员和工程师互相运行测试。
输出比测试本身更重要。如果输出对工程师没有用，那么您可能无法从运行测试的工程师那里获得巨大的价值。我为缩小差距所做的一件事是将测试标记到套件中，这些套件将对工程师有用。这样，他们可以运行与其特定工作相关的测试切片，而不必运行所有程序。
#5 楼
这取决于组织。在我工作过的地方，QA团队倾向于优先考虑广度而不是运行时或设置简单。 “ QA环境”可能需要对模拟对象，伪造数据等进行一些特殊的设置和配置。另一方面，开发人员更喜欢快速运行的测试，以便可以将其集成到其编辑/构建/运行周期中。 （例如，在每次构建或每天构建之后），并将结果提供给开发人员。#6 楼
我将使提交某种测试（例如通过触发器或最好是构建系统）的提交后自动进行。如果测试范围太广，则将提交后的测试缩回在合理的时间内运行（以便开发人员迅速获得反馈。）
如果longform测试（因为longform使它更好，是吗？）需要X个小时的运行时间，我建议运行它在2或3个不同的构建系统上每X / 2或X / 3个小时。这将为您全天提供一致的反馈。
挑选出各个测试的功能将非常有用。您运行长格式测试，发现测试15和29失败。现在，在提交之前，您可以只在15和29上运行。让它们运行，通过简单的测试，提交并运行。当然，您有可能打破了其他测试。通常您不会。
我当然不会阻止开发人员运行自动测试，甚至手动测试。老实说，如果他们能够在测试人员发现错误之前将其阻止，那就太好了。当您考虑到开发人员在报告最终从质量检查中返回时从他离开的地方开始提取的时间时，即使是简单的修复，也可以节省公司多达2个小时的时间。
评论
“如果测试过于广泛，则将提交后的测试按比例缩小以在合理的时间内运行（以便开发人员迅速获得反馈。）”这种类型的提交后测试的另一个好处是您的测试工程师知道他们可能拥有良好的身材。您不希望看到团队开始进行测试，只是发现构建中的一个小时很糟糕。登记入住时进行烟雾测试可以帮助防止这种情况。
– CKlein
2011年5月4日13:23
#7 楼
QA是否应该坚持所有自动化测试都必须在通过检入之前通过？每个），因此开发人员不可能将这些测试作为Smoke / tdd测试的一部分进行。其他一些测试无法自动执行，因为它们需要其他软件来模拟“内存不足”或“磁盘已满，请重试”方案。
每晚的构建过程是否应包括QA的自动化测试？
这很有道理。
#8 楼
许多公司将通过QA开发诸如硒之类的全功能自动化套装。这些可以用作自动烟雾测试，也可以与Build集成工具（如Hudson和maven）一起使用。每次开发人员向应用程序中添加新内容时，他们都可以触发诉讼并查看应用程序功能。这对于回归测试非常有用。因此，正如前面的帖子所建议的那样，如果质量检查开发网站功能完善，那么开发人员可以从中受益很多#9 楼
我想在没有成熟的测试自动化框架的商店中使用一小块，或者测试自动化花费的时间太长而无法在每晚上实际运行，或者需要手动设置。我不是可以肯定其他商店，但是我通常会在准备好应用程序代码之前完成测试自动化，以进行增强和错误修复，只是必须为几个变量添加值。故意修改的功能已经是一个福音，而且我不知道许多开发人员在要求升级到测试环境之前不愿意运行它。
#10 楼
是的，这将有助于在测试的早期阶段识别错误。开发团队可以处理代码的设计，开发和单元测试。如果使用SCRUM / TDD，恐怕它们是否有足够的带宽来执行集成/功能测试方案如果开发人员运行QA自动化代码，我们可以确定
-属于功能的明显错误
-在进行UI测试的情况下跨浏览器失败的问题
-在某些情况下任何边缘情况失败的情况
一个选择是开发人员和测试人员可以坐在一起进行一轮功能测试在开发阶段结束时。较早地检测到错误，降低了修复所需的成本
与识别/设置开发团队和测试团队之间的界限相比，这更像是一次思维转变>
#11 楼
自动化测试主要是编写并用于现有功能，或者在开发和交付新功能以进行测试时使用，这些测试已经在实际的自动化测试开始之前经过了多次手动测试。即主要为回归测试套件而写。开发人员可以在单元测试期间使用这种自动化测试，以确保新开发不会干扰现有功能。另一方面，自动化套件将涵盖对产品/应用程序消耗了合理的执行时间，可以被测试阶段接受。因此，当开发人员使用它时，将导致开发阶段的完成时间增加。因此，我建议开发人员在以下情况下使用QA编写的自动化测试套件：
a。复杂功能的开发，其中怀疑最终开发会影响应用程序的核心功能
b。提供了质量检查自动化测试套件，它包含有限的功能（不是很详细），但涵盖了所涵盖的主要功能区域
评论
如果测试需要15个小时，则为不良测试。 ;）
–德米特里·扎伊采夫（Dmitri Zaitsev）
15年4月17日在11:08