谁应该编写测试？答案

【问题标题】：Who should write tests?谁应该编写测试？
【发布时间】：2011-07-06 11:28:20
【问题描述】：

如果一个人负责编写测试，另一个人负责完成测试，或者编码员和测试编写者应该是同一个人，那会更好吗？

【问题讨论】：

【解决方案1】：

单元测试是您在编写代码时所做的事情。此测试测试您对事物应该如何工作的看法（在类/方法/算法级别）并且它在开发时为您提供支持，因为您可以在进行更改之前和之后运行测试以查看事物仍然根据您进行的测试。将此视为将帮助程序员工作的东西。此外，测试还将提供一种方法，让查看代码的任何人了解某些东西应该如何工作。 TDD（测试驱动开发）并没有改变这个概念，而是强调一个编码需要首先考虑它应该如何工作以及期望什么。

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

对于其他类型的测试，如集成测试、功能测试甚至（系统）性能测试，最好让其他人这样做。尤其是如果您想自动执行此测试，则需要您知道如何做事，并且可能还需要对测试什么以及如何测试有更高水平的业务知识。

您的问题的答案还取决于文化和您的组织的运作方式，但是，我相信您在任何情况下都希望将单元测试作为开发代码的一部分。如果这导致问题，则可能是组织中存在其他问题或需要查看的其他内容。

更新

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

有些人可能不想编写单元测试；
有些人可能不知道如何编写好的单元测试，这可能会破坏这样做的好处，并且可能会被用作单元测试不好的“证据”；
组织可能不会让人们一起工作，而是有不同的职责，例如编码人员代码、测试人员测试等，这可能会迫使某人进行单元测试；
可能会雇用一些人来编写单元测试，因此如果不更改此角色，则与您在编写代码时编写单元测试相矛盾；
可能有一个非常小的组织，这可能暗示每个人都做每一件事；
整个组织不承认单元测试的好处，而是尽可能快地编写代码并在以后处理问题，
谁在推动进行单元测试？是一个人吗？开发商？管理层？
组织是否可以自行决定由谁进行单元测试？

如果同意进行单元测试，则可能需要处理上述问题，以使组织进入自然运行的状态。如果您有具有良好单元测试实践和经验的人，让他们领导带领团队的其他成员了解单元测试的魔力 >.

就个人而言，我相信如果人们看到单元测试的好处，可以编写好的单元测试，通过构建自动化它们，并且团队可以自行决定如何组织如何获取单元编写的测试将自然而然地到位，以便开发人员在开发代码时编写单元测试，任何人都可以在任何时候为他们正在查看的任何代码添加更多单元测试 .如果有测试人员，他们会专注于其他类型的测试，例如功能测试或探索性测试。

【讨论】：

单元测试是在单元中测试代码，孤立地测试功能原子。 “测试你的观点应该如何工作”可以适用于任何类型的测试。
好吧，这确实有点模糊，我假设我们知道这里的单元测试是什么。你想读什么？ :)
您能否举例说明可能出现的问题、可能出现的问题或需要查看的内容？
虽然这是一个经过深思熟虑的答案，但我认为最后一个更接近Agile 方法，其中没有角色。此外，如果每个人都对质量负责并且测试人员有一些编程知识，他们至少可以讨论/审查在单元测试中实现的测试用例。

【解决方案2】：

这个问题会引起许多不同的答案，有些是基于组织的工作方式，有些是基于规划和测试的资格。组织测试有很多不同的方法，尤其是因为组织规模不同，并且可能有也可能没有资源来雇用不同的团队。

有不同类型的测试：

单元测试
集成测试
功能测试
非功能测试 - 压力、渗透和许多其他类型
用户验收测试

根据我的经验：
单元测试（孤立的功能原子，例如单个控制器操作）和集成测试（这些原子一起工作，例如控制器工作对于域层对象，域层对象与数据层对象一起工作，）应由开发人员完成。

功能测试（系统功能如规范所述）应由单独的QA 团队完成。

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

UAT（系统适合目的）应由客户端完成。

这背后的原因是，由于自动化单元和集成测试是白盒（您可以在应用程序内部看到，例如代码），它们需要由开发人员完成（不一定是负责被测代码的开发人员）。
功能测试和 UAT 是黑盒（您看不到应用程序内部），因此更有可能由非技术人员完成，但擅长测试分析。
非功能测试可以是黑盒或白盒，具体取决于测试对象和整体策略。

请务必注意，通过测试他人的工作比测试自己的工作发现的缺陷更多。测试人员会有不同的想法，因此会寻找/尝试在开发过程中不会考虑的事情，人们自然会保护他们的代码（无论人们多么努力地保持客观）。

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

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

【讨论】：

+1，责任方与测试类型有关。软件测试不是一个单一的过程。
@mcyalcin，你能评论你的评论吗？ :-)
@Henno，不太适合评论，但是：单元测试与微模块有关，是开发人员的责任；集成测试可以是开发人员（复数）、架构师的；功能测试分析师或测试员（阅读具有领域知识但不是程序员的人）；非功能测试有不同的组成部分，有离散的专家，例如 f.e.安全分析师的安全性和系统测试人员的负载测试（阅读可以将功能测试移植到负载测试工具的人）。 UAT 基本上是由客户进行的最后两个。存在其他类型/级别..
@Henno，您的关注点：在小型团队的 TDD 中，您通常会关注单元和集成测试。单元测试应该由模块的开发者开发，集成测试最好由模块双方分别开发进行测试。由于各种原因，包括澄清定义、标准形式化和快速回归测试能力，使这些自动化至关重要。其他类型的测试最好不要由开发人员进行，因为它们是不相关的过程（开发人员需要大量的上下文切换）并且需要不同的技能。

【解决方案3】：

使用 TDD，开发单元（读取程序员或配对）应该编写测试。

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

对于 BDD/ATDD，QA/PO 应该参与其中。

BDD（行为驱动开发）和 ATDD（验收测试驱动开发）测试通常以较低粒度级别编写。更好的测试是在考虑利益相关者的情况下编写的。所以写这些的更好的人是QAs（质量保证），POs（产品所有者）或BAs（业务分析师）。这并不是说开发人员无法编写它们，您只需进入该角色即可。

结对工作的美妙之处在于，如果你的结对编写测试，则会在编写测试时自动检查它们的完整性。

【讨论】：

我对这个话题很好奇，但不知道术语。您愿意扩展“TDD”、“BDD”、“ATDD”、“QA”和“PO”吗？
@Delan - TDD 和 BDD 之间的区别：stackoverflow.com/questions/2509/…
@Delan Azabani：测试驱动开发、行为驱动开发、验收测试驱动开发、质量保证、产品负责人。

【解决方案4】：

我的开发团队的一个非正式政策是

每个人都会做任何事情。

也就是说，没有测试人员、程序员或架构师。每个人都应该参与所有的活动。

这是为了避免瀑布过程。如果一项活动是一个人的唯一保留，那么开发可能会变得有顺序，人们会处理下线的工作并且不知道他们做出的决定的全部后果。

这并不意味着每个人都同时处理每项任务。这意味着每个人在某个时间点从事每种任务

【讨论】：

这是一个不可扩展的解决方案。当您拥有一个由 10 人以上的开发人员组成的团队和一个大型应用程序（并非所有内容都是 Todo 列表示例应用程序）时，不仅建议而且需要进行工作分离。
@SSHThis 绝对。请注意，由于团队中有多人，沟通路径的数量会迅速失控：(n * (n - 1))/2。
不，通信路径的数量是O(N)，因为每个人都与SCM系统通信，而不是彼此。