质量保证工程师进行单元测试

Question

正如我从一些Q＆amp; A会议（参见this和this）所理解的那样，单元测试应由开发人员编写。

在我之前的工作场所，我们试图将这项任务交给QA工程师，但它没有用。可能是因为它已经是一个项目的中间部分，他没有机会进行重要的代码覆盖，或者可能是因为另一个原因。

您是否认为让开发人员以这种方式编写单元测试是一个坏主意？

Answer 1

一般来说，我认为这是一个坏主意。单元测试指导开发人员编写模块化（因此有用，可重用）代码，因为他们的代码需要与生产系统和测试代码一起使用。

Answer 2

单元测试和QA测试的意图之间存在微妙但重要的区别： QA测试验证功能;单元测试验证设计。也就是说，外观与产品的内部视图形成对比。

QA人员不熟悉产品的内部设计，这是有意的，因为他们必须模仿用户的视角。另一方面，开发人员非常了解内部工作原理，对他们来说，验证设计的机制是有意义的，如果有的话。

因此，开发人员而非QA人员编写单元测试是绝对自然的。

Answer 3

这取决于您计划如何实施测试工作流程。

<强>为：

开发人员编写他的代码，然后另一个人尝试添加单元测试来测试此代码。这里的问题是开发人员不会关心编写易于测试的代码。可能花费很多时间来尝试使单元测试适应可严格测试的代码，或者通过重构原始代码来浪费时间以便更好地测试。

不可

开发人员之外的另一个人编写了单元测试，开发人员随后编写了他的代码，试图将所有这些测试都设置为绿色。这可能有点尴尬，因为一些基本接口必须存在才能实现测试，但基本接口应该在设计文档中定义，因此开发人员可以为测试开发人员准备接口。优点是，测试开发人员试图编写他能想到的尽可能多的测试而不依赖于实际实现，而原始开发人员会根据代码的内部编写测试，而不是想象其他问题。否则，他已经在实施过程中对他们进行了反击。

“好”方法在我的两个项目中运行良好，但是我们使用了一种无类型语言（Smalltalk），我们只需要同意类名来运行测试。在Java中，您必须至少实现一个接口，以便调用函数。

Answer 4

是

开发人员编写unittest te确保“单位”执行它想要做的事情。质量保证人员测试整个申请。

此外，单元测试是代码，开发人员编写代码。大多数时候，QA工程师都不会编写代码。

Answer 5

开发人员必须编写单元测试。 否则就像开发者不必关心质量。 此外，单元测试可以帮助开发人员编写更好的代码。

也许你听说过TDD？ “测试驱动开发”是一个非常好的开发实践。它的主要目的是在编写实际代码之前开发单元测试（这很奇怪，当我们开始使用TDD时，我承认）......

Answer 6

有一个人专注于团队中的单元测试，乍一看似乎很有趣;因为他将审查所有代码。这也可以减轻一个开发人员在生产代码和单元测试中产生相同错误的风险。

但是，为了进行单元测试，代码必须是可测试的;当它收到的代码不可测试时，他能做些什么？重写它？重构它？没有单元测试？

简而言之，我认为这不是一个好主意。

Answer 7

我工作的地方都是单元测试，但不是你自己的代码。您仍然可以编写可测试的代码，并仍将重点放在质量上。开发人员越来越熟悉他们没有使用的软件领域。每个人都知道代码库，可以接管其他开发人员。

对于非软件开发人员编写单元测试我同意所有其他答案。这是一个坏主意。

在你的问题中，你说你有一个人在进行单元测试。良好的单元测试需要付出很多努力，具体取决于所需的测试覆盖率。它是开发团队努力程度的50％到100％。一个人测试很多开发人员代码将完全不堪重负。

Answer 8

我认为这不会很糟糕，我只是觉得不可能。如果代码没有首先编写测试，则可能无法测试。

QA人员是否正在重构代码以使其可测试？

如果是这样，那很好，我不在乎他们的头衔是什么。如果他们不是，那么我怀疑他们会成功。

Answer 9

我认为QA编写单元测试通常是不好的。单元测试是代码，它们与构造开发代码的方式密切相关。出于这个原因，开发人员最了解哪些测试最有意义。

另一方面，我认为QA应该尽可能接近单元测试。 QA需要与开发人员保持良好的关系并尝试理解代码设计。为什么？当开发人员编写单元测试时，重点仍然是开发，而不是测试。你不能相信（不是在坏的意义上）开发人员提出最好的测试用例并且她有很好的覆盖率。由于QA专门用于测试，因此在单元测试期间保持QA和dev尽可能接近可能是一个好主意。

Answer 10

开发人员或同事开发人员（代码审查人员）应记录单元测试用例，其中应以某种方式基于所开发的代码或技术设计。但是，QA测试用例应由功能测试人员编写，该测试用例应基于功能设计。

这里的根本区别在于UT涵盖了逻辑，内部流程，性能和优化，而QA涵盖了模仿用户体验的功能流程。