问开发人员能为他实现的特性进行自动化测试吗？

EN

根据我的经验，答案是肯定的，也是否定的。

显然，开发人员可以为他/她实现的特性编写自动化测试。开发人员是否应该编写这些测试是另一个论点，它取决于所编写的自动化测试的类型、开发风格、更好地利用开发时间来执行哪项任务，当然还有办公室政治(唉，这是无法逃脱的)。

根据我的经验，在以下情况下，开发人员应该为其特性编写自动测试：

• 他们正在进行测试驱动的开发，并在编写实现之前编写单元测试。
• 他们在写单元测试，句号。
• 自动化测试需要了解测试人员可能无法访问/使用的应用程序代码的内部工作方式。
• 自动化测试将作为构建过程的一部分进行编译和运行。

在以下情况下，开发人员可能不是为其特性编写自动化测试的最佳人选：

• 测试处于函数级、API级或GUI级，不需要内部代码知识。
• 时间限制正将它们推向不同的特性开发(一旦开发人员开始进行新项目，对代码的深入熟悉的优势就会迅速消失，一个月左右的时间就几乎完全消失了)

不管是谁编写的自动化测试：

• 他们应该由其他人审查代码质量。
• 他们应该由其他人审查错过的情景。

开发人员“不能”测试他们自己的代码的论点源于注意盲，在这种情况下，通过开发熟悉代码会导致潜在的问题被忽略。其他人审查他们的测试将减少影响，在一个不同的项目工作了一段时间后会返回到一些东西。

所以，是的，程序员在为他们开发的特性创建自动化测试时会有注意力盲目性，但这并不意味着他们绝对不应该创建这些测试。它们可能仍然是创建它们的最佳人选(例如，如果开发团队的其余部分完全被占用，测试团队主要是手动测试人员，那么编写自动化的最佳人选就是编写该特性的开发人员)。

我工作过的产品质量最高，产品缺陷最少，没有QA团队。开发人员负责端到端的服务，质量期望是明确的。当未经充分验证而匆忙通过更改时，无论是QA还是Dev，都会出现问题。

开发人员通常处于自动化测试的最佳位置，并且还可以对实现进行小的更改，以使测试更容易。基于这些原因，我建议最好的实践是让测试人员协助识别哪些测试用例提供了最大的价值并指定它们的参数。然后，开发人员可以实现这些测试用例。

开发人员不应该针对自己的代码进行的活动实际上是测试设计，而不是测试执行或测试自动化。如果开发人员正在进行他们自己的测试设计，那么根据定义，任何开发人员忘记想到的东西都不会被测试；单独的测试人员可以想到开发人员没有想到的事情。

如果开发人员正在自动化由其他人编写的测试用例，则不涉及冲突。