作为质量检查工程师，编写单元测试对我来说很难吗？

#1 楼

编写单元测试并不困难-俗话说，这是简单的编程问题:-)因此，如果您是一名合格的程序员，并且愿意学习必要的技能和模式，则可以作为QA工程师来完成。

但是恕我直言，IMHO（最好的做法是说）开发人员更适合编写单元测试-因为单元测试使用对应用程序对象和方法的内部调用-与开发人员已经知道如何使用应用程序正常工作的调用相同。因此，开发人员已经应该知道应用程序的工作方式以及任何内部方法/过程调用的预期正确结果（内部状态的更改，UI可能相同或不相同），并且可以为其编写单元测试，而无需过多花费努力。如果QA编写单元测试，则他/她需要学习所有这些知识。

此外，编写易于进行单元测试的代码也是一种好习惯-开发人员应该这样做，因为这会迫使他们编写代码更好的代码（更易于测试的代码也更易于理解和维护）。理想情况下，在测试驱动的开发中，单元测试是在代码之前编写的。

单元测试是一种良好实践的原因之一是，单元测试可以检测到更接近源代码的错误-与系统级不同测试，它通常会在系统严重混乱之后检测到错误，并且可能需要进行复杂的侦查工作才能找到所检测到的问题的根本原因（由哪个代码单元引起）。

您可以学习这些内部API并编写单元测试，但是使用硒，您可以从“外部”测试应用程序：哪些用户操作将产生哪些可见的结果。 。从相邻的领域中学习尽可能多的知识-但要确定自己的核心技能，并专注于这些技能。我读过某个地方的技能需要呈T形：即使是浅层（不是很深）也要覆盖很大的区域，而该区域的一部分要深一些（您的核心专业知识）。

没有人可以给您第二个问题的肯定答案，只有您自己可以。考虑当前的技能，您的兴趣，公司需求，在当前公司和您所在地区的其他公司中发展职业的途径，整体市场，以及您想要或愿意搬迁的其他市场。

如果您想成为开发人员，并且您的公司愿意为您提供培训，甚至愿意为此付费，那么为现有代码编写单元测试可能是从质量保证过渡到开发的一种好方法。这将迫使您学习系统核心内部方法的工作方式，并且编写测试是学习系统的安全方法，因为您的代码不会破坏现有功能。测试中的错误将为假阳性（易于检测和修复），或更糟糕的是，假阴性-测试在应有的时候不会失败。但是测试中的错误对面向用户的功能没有影响。

但是，如果您的公司认为QA测试人员应该编写单元测试（即使最佳实践表明这样做更好，您也不能反对）开发人员），也许您需要寻找机会在更精明的公司工作（可以更有效地提高您的核心质量检查技能）。

此外，如果您公司中的开发人员不编写和使用单元测试，他们可能会忽略其他最佳实践，并且您将在其他公司中更快地提高自己的技能（因此，您可以考虑寻找机会为更聪明的公司工作）。或者，您可以尝试向您的开发人员解释为什么单元测试也对开发人员也有好处，因此他们应该编写单元测试（因为这将有助于THEM编写更好的代码，从而更安全地重构和改进）。

#2 楼

开发人员的观点：

单元测试最好与它所测试的代码一起编写。它将在某种程度上改变代码的形状：编写测试的需求迫使代码易于测试，从而限制了某些代码的气味/反模式。例如，直接重写数据库以获取用户名的方法将很难进行单元测试，直到对其进行重写以依赖可模拟的接口来获取相同的信息为止。在已经编写代码之后，如果没有开发技能，将很难进行包装活动。您只能测试已经具有完善的API的东西-可能不是错误所在。它还避开了单元测试的主要好处：鼓励开发人员编写体面的代码。

我认为编写好的测试通常比编写要测试的代码更难。

坦率地说，我已经看到很多人认为QA下了总线，因为他们认为（A）自动化测试是一件好事，（B）开发人员太忙/懒惰而无法编写它们，（C）嘿，这是一个测试-质量检查可以解决这个问题。我从未见过它能起作用。

所以这是个坏消息。它：学习编码。不要只专注于测试-只是尝试了解您正在测试的代码，学习一些Java（或其他语言）教程或课程。您甚至可以将具有绝妙想法的人推到第一位。专注于重构（请参阅Feathers的“使用旧版代码有效工作”）。在开发中寻找一个可以解释事情如何工作，她想要测试什么的合作伙伴，并在编写测试时进行合作。您现在不需要设计/架构技能，只需了解代码的工作方式以及如何重构代码即可有效地编写测试。

祝您好运！

#3 楼

tl; dr不，测试人员不会为开发人员开发的代码编写单元测试，但是某些开发人员/测试人员会编写非单元测试的自动化测试。


这取决于“单元测试”。仍然有很多人称真正不是单元测试的东西称为“单元测试”。

真正的单元测试只能测试少量的代码单元，通常每个测试只测试单个代码的一部分。 class，该类最多包含200行代码。如果开发人员通过首先编写单元测试（一种称为TDD的做法）来编写新类，则他们会更加关注类的使用方式，因为单元测试只是有关如何使用类以及行为的文档是期待。单元测试是关于设计和编写代码的能力。单元测试还有其他优点，但这是到目前为止的主要优点。

从这个角度来看，测试人员是否擅长设计和记录代码（又称测试人员擅长编写单元测试），因为按照定义，这就是雇用开发人员要做的事情。

不是单元测试的单元测试

人们和公司已经对什么是单元测试有了自己的理解。有时他们开始将用代码编写的每个测试称为“单元测试”，而实际上还有其他类型的自动化测试，例如集成测试或验收测试-据我所知，这些测试的名称和范围还不清楚定义为单元测试。

这些自动化测试是一件好事。但是错误地称它们为单元测试会造成不必要的混乱。

但是谁应该编写这些自动化测试呢？知道如何编码和测试的人。这些人需要寻找或培训，并且通常是从开发人员或测试人员中招募的。有时，该职位被广告宣传为“测试中的开发人员”。

#4 楼

大多数情况下，我们听说过并阅读过白盒测试可以由Developer而不是Tester完成。这是因为开发人员具有更多而深入的编码知识。

但是，如果您在站点/软件构建方面具有丰富的编码经验和特定的编程语言知识，则可以进行白盒测试。

第二点问题是取决于市场。测试人员不必一定具有白盒测试方面的专业知识。如果您在使用自动化工具进行黑盒测试方面表现出色，那么对于职业发展而言确实不错。

#5 楼

困难吗？


这很大程度上取决于您的开发技能，但是由于单元测试通常来自TDD周期，因此我认为在工作之后创建测试是做起来很难。最好先编写测试，然后编写代码。

我建议您开始阅读“ Test Driven”一书（它使用Java），这将使您了解TDD循环的工作原理，以及给出实际的例子。它还包含一章有关“使用遗留代码”的一章，也称为未在TDD周期中编写的代码。


我有点担心自己的未来。


总是有自动进行端到端2和/或自动UI测试的地方，但是如果您看一下测试金字塔，则它是您希望在代码上生成测试覆盖率的最小部分。

我坚信软件测试的未来是自动化测试。随着越来越多的团队从手动测试切换到自动化测试，我认为在您构建测试的任何级别上都可以工作，直到我们可以自动化创建测试用例为止：)

请记住，实施这些测试可能会更多地转移到开发人员的角色，但是肯定会有设计测试的空间。

#6 楼

除非您学习如何编程，否则这很难。 :)如果您已经在使用Java和Selenium，那么您就会知道如何编程。您将必须学习所测试的代码的工作方式，还需要学习如何编写单元测试。

#7 楼

质量检查通常会进行与功能测试等高级测试相关的工作。
单元测试应由开发人员来完成，因为他们更了解开发环境。项目上有很多时间，验证或什至帮助进行那些单元测试非常有帮助，因为您可以为应该在这种测试中测试的内容添加新的观点。当然，您应该对开发人员使用的单元测试框架有足够的了解，通常与用于功能测试的单元测试框架不同。

#8 楼

如Peter所说，恕我直言，单元测试最好由开发人员完成。这些测试确实为他们带来了最大的好处，因为它可以帮助他们确保其代码在最细粒度的级别上按预期工作，并且有助于防止将来对代码进行更改时出现错误。

如果您的公司希望您编写这些测试，但是您目前没有所需的技能，那么我们要做的一件事就是将开发人员与质量检查人员配对，并让该质量检查人员经历好的测试场景，然后让开发人员编写测试（这在“测试驱动设计”中最有效）。这使双方都可以发挥自己的优势，同时也可以洞悉对方的思维方式和技巧。