Unit testing 谁应该编写测试？

如果一个人负责编写测试，另一个人负责完成测试，或者编码员和测试编写员最好是同一个人？

对于TDD，开发单元（读程序员或成对程序员）应该编写测试

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

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

BDD（行为驱动开发）和ATDD（验收测试驱动开发）测试通常是在粒度较小的级别编写的。编写更好的测试时要考虑利益相关者。所以写这些的人最好是QAs（质量保证）、POs（产品所有者）或BAs（业务分析师）。这并不是说开发人员不能编写它们，你只需要进入这个角色

---

两人一组工作的好处在于，如果你的两人都在写测试，那么在写测试时，会自动检查测试的合理性。

这个问题会有很多不同的答案，有些答案基于组织的工作方式，有些则基于计划和测试的资格。有许多不同的方法来组织测试，特别是因为组织规模不同，可能有也可能没有资源雇佣不同的团队

有不同类型的测试：

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

以我的经验：
单元测试（独立的功能原子，如单个控制器动作）和集成测试（协同工作的原子，如控制器与域层对象、域层对象与数据层对象）应由开发人员完成

功能测试（系统功能如规范所述）应由单独的质量保证团队进行

非功能测试可以由质量保证团队或架构师/技术负责人进行

UAT（系统适合使用）应由客户完成

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

需要注意的是，通过测试他人的作品发现的缺陷比测试自己的作品发现的缺陷要多。 测试人员会有不同的想法，因此会寻找/尝试在开发过程中没有考虑到的东西，人们自然会保护他们的代码（无论人们如何努力做到客观）

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

---

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

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

每个人都做每件事

也就是说，没有测试人员、程序员或架构师。每个人都要做一点所有的活动

这是为了避免瀑布过程。如果一项活动是一个人的专属领域，那么发展就会变得有序化，人们在工作过程中始终不知道自己所做决定的全部后果

---

这并不意味着每个人都同时完成每项任务。这意味着每个人都会在某个时间点处理各种任务，单元测试是您在编写代码时要做的事情。此测试是测试您的视图（在类/方法/算法级别上）应该如何工作，它在开发时为您提供支持，因为您可以在进行更改之前和之后运行测试，以确保事情仍然符合您现有的测试。将此视为有助于程序员工作的东西。此外，这些测试还将提供一种方法，让查看代码的任何人都可以看到某些东西是如何工作的TDD（测试驱动开发）并没有改变这一概念，而是强调了编码需要首先考虑它应该如何工作以及期望得到什么

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

至于其他类型的测试，如集成测试、功能测试甚至（系统）性能测试，让其他人这样做可能会更好。特别是如果您想自动化此测试，它需要您知道如何做事情，并且可能需要更高级别的业务知识来测试什么和如何测试

你的问题的答案也取决于你的组织的文化和运作方式，然而，我相信你在一个