谁应该编写测试？

Question

如果一个人负责编写测试，另一个人负责完成测试，或者理想情况下，程序员和测试编写者应该是同一个人，是不是更好？

Answer 1

单元测试是您在编写代码时所做的事情。这个测试是测试你的视图应该如何工作(在类/方法/算法的级别上)，它支持你在开发时，因为你可以在进行更改之前和之后运行测试，以查看事情仍然是根据你已有的测试进行的。当程序员工作时，将会帮助他/她。此外，这些测试还将提供一种方法，以了解任何查看代码的人应该如何工作。测试驱动开发(Test-Driven Development)并没有改变这个概念，而是强调编码需要首先考虑它应该如何工作以及预期会发生什么。

如果没有看到自己的问题，可以尝试结对编程、代码审查或其他方式，用更多的眼睛和大脑来看待问题。尽管如此，我仍然坚信单元测试是程序员使用的工具，而不是其他任何人所做的事情。

至于其他类型的测试，比如集成测试，功能测试，甚至(系统) performance testing，让other people来做这件事可能是件好事。特别是如果你想自动化这个测试，它需要你知道如何做事情，而且可能还需要更高水平的业务知识来测试什么和如何测试。

你的问题的答案也取决于文化和你的组织是如何运作的，然而，我相信你在所有情况下都希望将单元测试作为开发代码的一部分。如果这导致了问题，可能是组织中的其他东西被破坏了，或者需要检查一下。

更新

以下是我在组织中看到的一些影响单元测试实践的事情：

• 有些人可能不想写单元测试；
• 有些人可能不知道如何写好的单元测试，这可能会破坏做单元测试的好处，这可能会被用作单元测试不好的“证据”；
• 组织可能不会让人们一起工作，而是有不同的责任，比如程序员代码，测试人员测试等等，这可能会迫使someone;
• some上的人编写单元测试，所以如果这个角色不改变，它就会在编写单元测试时与编写单元测试相矛盾；可能有一个非常小的组织，这可以隐含地意味着每个人都做了一点everything;
• the组织作为一个整体不承认单元测试的好处，而是code-as-quick-as-possible-and-deal-with-problems-later，
• 谁在推动做单元测试的努力？是一个人吗？开发人员？Management?
• is组织可以自由决定谁来做单元测试？

如果有一个关于进行单元测试的协议，上面的事情可能是需要处理的问题，以便将组织带入一种自然工作的状态。如果你有好的单元测试实践和经验的人员，让他们领导things ，让团队的其他成员来看看单元测试的魔力。

我个人认为，如果人们看到了单元测试的好处，可以编写好的单元测试，用构建自动化它们，如果团队能够自己决定如何组织如何编写单元测试，那么就会自然而然地落到适当的位置，这样开发人员在开发代码时就可以编写单元测试，任何人都可以在任何时候为他们正在查看的任何代码添加更多的单元测试。如果有testers，他们会专注于其他类型的测试，如功能测试或探索性测试。

Answer 2

这个问题将邀请许多不同的答案，一些基于组织如何工作，一些基于规划和测试的资格。有许多不同的方法来组织测试，特别是因为组织规模不同，可能有资源也可能没有资源来雇用不同的团队。

有不同类型的测试：

• 用户验收测试-压力、渗透和许多其他类型
• User Acceptance

根据我的经验：

单元测试(孤立的功能原子，例如单个控制器操作)和集成测试(一起工作的原子，例如使用域层对象的控制器，使用数据层对象的域层对象)应该由developer完成。

功能测试(规范规定的系统功能)应由单独的QA team完成。

非功能测试可以由QA团队或架构师/技术主管完成。

应由client执行UAT (系统适用于此目的)。

这背后的原因是，由于自动化单元和集成测试是白盒(您可以在应用程序内部看到，例如代码)，它们将需要由开发人员完成(不一定是负责测试代码的开发人员)。

功能测试和UAT是黑盒(你看不到应用程序内部)，因此更有可能是由非技术人员完成的，但在测试分析方面却很熟练。

非功能测试可以是黑盒测试，也可以是白盒测试，这取决于测试内容和总体策略。

值得注意的是，测试别人的工作比测试自己的工作会发现更多的缺陷。测试人员会有不同的想法，因此寻找/尝试在开发过程中不会被考虑的事情，人们自然会保护他们的代码(无论人们如何努力做到客观)。

如果没有单独的测试团队，最好让开发人员测试彼此的代码。

为了更多地回答您的问题，当我是一名测试人员时，我负责测试分析(决定测试规范需要哪些功能测试)，并编写测试脚本并手动执行测试。一旦编写了这些脚本，任何测试人员都可以执行它们，但重要的是，测试分析要与开发人员在应用程序上的工作分开进行。

Answer 3

使用TDD，开发单元(读一位程序员或一对程序员)应该编写测试。

测试驱动开发( TDD ) -unit测试通常处于技术层面。开发单元应该在它们实现类时编写它们。如果其他人编写测试，您可能会遇到的问题是，外力将影响设计。当开发人员进行设计时，TDD工作得很好。

对于BDD/ATDD，应包括QA/PO。

BDD(行为驱动开发)和ATDD(验收测试驱动开发)测试通常是在较小的粒度级别编写的。更好的测试是在考虑利益相关者的情况下编写的。因此，更适合写这些的人是QAs (质量保证)、POs(产品负责人)或BAs (业务分析师)。这并不是说开发人员不能编写它们，您只需进入该角色即可。

成对工作的美妙之处在于，如果你们两个一起编写测试，那么在编写测试时，会自动对测试进行健全性检查。