是单元测试开发还是测试？

我与测试经理讨论了单元测试和集成测试的作用。她要求开发人员报告他们已对单元和集成进行了什么测试以及如何进行测试。我的观点是，单元测试和集成测试是开发过程的一部分，而不是测试过程。除了语义之外，我的意思是，单元和集成测试不应包含在测试报告中，并且系统测试人员不应对此感到担忧。我的推理是基于两件事。

1. 总是根据接口和合同计划和执行单元和集成测试。无论您是否使用正式合同，您都仍在测试应该执行的方法，例如合同。

   在集成测试中，您将测试两个不同模块之间的接口。接口和合同确定测试何时通过。但是，您始终只能测试整个系统的有限部分。另一方面，系统测试是根据系统规范计划和执行的。规格确定测试何时通过。

2. 在将单元测试和集成测试的广度和深度传达给（系统）测试器时，我看不到任何价值。假设我写了一份报告，列出了在特定业务层类上执行哪种单元测试。他/她应该从中学到什么？

   从此判断应该测试和不应该测试的内容是一个错误的结论，因为即使所有单元测试和集成测试都通过了，系统仍可能无法按照规范要求的方式运行。

这看起来似乎是没有用的学术讨论，但是如果您像我一样在严格的正式环境中工作，那么对于确定我们的工作方式实际上很重要。无论如何，我完全错了吗？

编写自动化测试是开发人员的工作。测试是代码库的一部分，应被视为项目的一部分-测试应与项目的其余部分一样受到相同的代码审查，编码标准，源代码控制准则等的约束。

运行上述测试的原因有两个：首先，作为指导开发人员的工具。您运行测试以验证您刚刚编写的代码是否符合预期的用途，并将它们用作其他文档，并验证所做的更改不会破坏任何现有功能。如果您进行的是真正的TDD，则测试也是技术规范的权威来源。使用测试的第二个原因是在质量检查和部署期间。运行所有自动化测试应该是每一轮测试的第一步。运行自动化测试很便宜（几乎不需要人工），并且如果自动化测试失败，则进行手动测试没有多大意义。

这意味着责任应该是这样的：

• 开发人员编写自动化测试
• 开发人员根据需要运行单独的自动化测试，这是其开发工作流程的一部分
• 质量检查将所有自动化测试作为测试的第一阶段之一进行

如果您有构建服务器，则QA的任务（关于自动化测试）可以归结为“打开构建服务器的报告并确认所有内容都是绿色的”。

我认为对您来说最重要的是弄清她为什么需要该报告。

可能有不同的解释（如若干答案所建议），这需要非常不同的策略。

• 如果她是一个理性的人，只是想获得帮助她的测试团队工作的信息，就可以达成共识，并制定出适合你们双方的解决方案。您可以与她讨论单元测试的性质以及单元与功能/系统/验收测试之间的根本区别。希望您能使她理解这些工作在非常不同的层次上进行，并且两者都无法替代。
• 如果她是一个控制狂或官僚，只是为了报告而要求一份报告，则可以用最少的精力（例如@Doc建议：-）生成一些东西来满足她的想法。
• 如果她参加过一些强力游戏，您可能会质疑她是否有权要求开发人员提供报告。以我的经验，开发人员通常不应该向质量检查部门报告。

我认为质量保证和开发的角色以及相互影响在组织之间可能有很大的不同。但是总的来说，在我的团队中，我告诉加入的成员要假装成没有质量检查团队，这意味着他们要对要推动生产的变更负责。反过来，我们的质量检查小组对开发人员测试的要求不高，并且对系统作为一个功能整体进行了大量测试。

因此，我们的质量检查团队在开始测试之前并不十分在意什么是单元测试和没有单元测试。

我认为对于QA团队来说，从较高的层次理解单元测试的功能和不包括的内容是有帮助的，这样我们可以共同努力找出差距和可能需要更严格的领域。因此，也许您的同事是在进行高级别的总结，而不是去了解细节。

她坚持要求开发人员报告他们已对单元和集成进行了什么测试以及如何进行测试。

她真的是在争论这种测试是否真正在“开发”领域，还是只是想弄清楚单元测试覆盖了代码的程度？仅仅通过查看您所提供的信息，似乎她只是想知道代码的哪些部分以及她应该集中精力于团队的工作。

在升任开发职位之前，我刚离开学校就曾在一个测试团队工作过，我可以看到这对她和她的团队有何价值。

我认为这并不重要。

如果您没有将他们提供给QA / Testing，并且他们没有进行适当的测试，并且在生产中失败了，那是他们的过错，就是让它通过QA进入生产而不验证其是否按指定的方式工作。

如果您确实将它们提供给QA / Testing，而他们没有进行适当的测试...则与没有提供它们的结果相同。

但是，如果您提供它们，他们也可以将它们与规范进行比较，并且/或者建议哪些测试可能存在缺陷，或者因为发现错误而需要更改。

确实，在提供它们方面我没有看到太多的缺点。它仍在质量保证/测试中，以根据规格进行验证。如果他们采取偷懒的态度，并仅仅因为您全部通过测试而认为您的测试足够好，那就是他们的工作失败了。只要它们仍然具有规范，单元/集成测试的结果就只是虚假的，不应以一种或另一种方式伤害您。这就是我们拥有开发人员和质量检查人员的原因。应用程序按指定执行多次检查。

开发人员会犯错误，质量检查人员会犯错误，理想情况下，他们都不会在同一项目上犯错误……如果他们犯了错误……则可能是分析师放弃编写了不清楚的规范。

单元测试是开发人员的责任，即测试对于了解代码片段如何独立工作很有用。有些人可能将此视为一种文档形式，因此具有一定的价值，尽管如果定期更改单元测试可能会产生开销。

通过测试的另一个价值是，这可以避免在确保基本功能方面可能多余的测试增加一倍。

由于最终用户可能对系统的运行方式有自己的了解，因此还有一些与所有这些测试分开的用户接受测试。

如果您的公司具有确定的方法来确保其产品质量（如果它们符合SOX要求，或者正试图提高其CMMI水平，则可能这样做），则产品必须能够经受审核以表明流程被跟从。

通常，定义的过程包括单元测试（这是一件好事）。不幸的是，这还意味着您必须记录单元测试并证明它们已经运行才能经受审核。因此，这意味着您需要一种报告单元测试的方法。

看一下类似Sonar的工具可以为您提供帮助-它会报告代码覆盖率和单元测试运行结果。

这确实取决于公司，但是根据我的经验，既作为传统方法的系统测试员，又作为CD模型的敏捷团队的测试员，知道已经过单元和集成测试的内容非常有用。

质量是团队的责任-开发人员，测试人员和产品管理人员，共同努力是确保质量的最佳方法。

因此，测试经理想知道已对单元和集成进行了什么测试，这对开发人员来说是额外的工作，但可以节省项目的整体工作！通过将信息提供给测试经理，他们可以将测试团队的工作重点放在至关重要的方面。如前所述，如果未对代码区域进行单元测试，则与经过严格测试的区域相比，团队可以将精力集中在那里-为什么要重复工作？你们都在朝着及时发布更高质量软件的最终目标而努力。

我认为提供这种类型的东西将是有益的。单元测试的覆盖范围应该是开发和测试所熟知的，以便他们可以解释。

显然，无论如何，您都必须测试关键业务。无论是否有大量的单元测试范围，您都必须对常用功能进行艰苦的测试。让他们知道单元测试还覆盖了其他地方，这并没有什么坏处。在这个小控件中，代码是否已经检查了边缘情况？这种东西有助于在业务的各个方面了解。

值得一提的是“ Google如何测试软件”一书中讨论的方法：测试和质量控制是每个人的责任，并且标准严格。

传统上称为“测试”部门的真正角色实际上是开发人员的生产力。即自动化，以使组织能够经济地达到所需的严格水平。