问作为QA工程师，编写单元测试对我来说很困难吗？

EN

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

但IMHO (以及最佳实践表明)开发人员更适合编写单元测试--因为单元测试使用对应用程序对象和方法的内部调用--与开发人员已经知道如何使用应用程序工作的调用完全相同。因此，开发人员应该已经知道应用程序是如何工作的，以及预期的正确结果是什么(内部状态的更改(在UI中可能有或可能没有等效的结果)，并且可以为其编写单元测试，而无需付出太多额外的努力。如果QA编写单元测试，S/他需要学习所有这些。

此外，编写易于单元测试的代码是很好的实践--开发人员应该这样做，因为它迫使他们编写更好的代码(更容易测试的代码也更易于理解和维护)。理想情况下，在测试驱动开发中，单元测试是在代码之前编写的.

单元测试之所以是一个很好的实践，原因之一是单元测试检测的错误更接近其发生的源--不像系统级测试，后者经常在系统级测试严重混淆系统之后检测错误，并且可能需要复杂的检测工作才能找到检测到的问题的核心原因(是哪个代码单元导致的)。

您可以学习这些内部API并编写单元测试，但是使用selenium，您可以从“外部”测试应用程序:哪些用户操作将有哪些可见的结果。

你害怕让鸽子呆在一个角色里是对的。尽可能多地从邻近地区学习--但要确定你的核心技能是什么，并把注意力集中在这些技能上。我在某个地方读到，技能应该是T形的:覆盖很宽的区域，即使不是很浅(不是很深)，并且深入到那个区域的深处(你的核心专长)。

没有人能保证回答你的第二个问题，只有你自己。考虑当前的技能，你的兴趣，公司的需求，在你目前的公司和你所在地区的其他公司，整体市场，可能还有其他你想要或愿意搬迁的市场，提升你职业生涯的途径。

如果您想成为开发人员，并且您的公司愿意为您提供培训，甚至付费，那么为现有代码编写单元测试可能是从QA到开发的好方法。它将迫使您了解系统核心中的内部方法是如何工作的，编写测试是学习系统的安全方法，因为您的代码不能破坏现有功能。您的测试中的错误将是假阳性(这很容易检测和修复)，或者更糟的是，错误阴性-测试不会失败时，它应该。但是测试中的bug对面向用户的功能没有任何影响。

但是，如果您的公司认为QA测试人员应该编写单元测试(即使最佳实践说最好的方法是由开发人员来编写)，那么您可能需要寻找机会为更理智的公司工作(在那里，您可以更有效地提高您的核心QA技能)。

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

开发人员的透视图：

单元测试最好与它所测试的代码一起编写。它将在某种程度上塑造代码:编写测试的需要迫使代码易于测试，这就限制了一些代码的气味/反模式。例如，一个直接调用数据库以获取用户名的方法将很难进行单元测试，直到它被重写以依赖一个可模拟的接口来获取相同的信息。

编写单元测试作为黑匣子活动，在代码编写完毕后，如果没有开发技能，将是非常困难和非常有限的。你只能测试什么已经有了一个完美的API --很可能那不是错误所在。它还避免了单元测试的一个主要好处:鼓励开发人员编写体面的代码。

我认为编写一个好的测试通常比编写它所测试的代码更困难。

老实说，我曾多次看到QA在总线下被人们认为(A)自动化测试是一件好事，(B)开发人员太忙/懒得编写它们，(C)嘿，这是一个测试--所以QA可以处理它。我从没见过它起作用。

这就是坏消息。

好消息是，如果你感兴趣，有一个简单的解决方案/职业道路:学习编码。不要专注于测试--只要试着理解正在测试的代码，就可以选择几个Java (或其他语言)教程或类。你甚至可以推动谁有聪明的想法，在第一时间为它付钱。专注于重构(按羽毛查看“有效地使用遗产代码”)。在开发中找到一个合作伙伴，可以解释事情是如何工作的，她希望测试什么，并在编写测试时进行协作。此时，您不需要设计/架构技能--只需要代码如何工作，以及如何重构代码以有效地编写测试。

祝好运!

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

这取决于“单元测试”的定义。还有很多人称那些真正不是单元测试的东西为“单元测试”。

实单元测试测试小代码单元，通常每个测试只测试单个类的一部分，类包含多达200行代码。如果开发人员通过第一次编写单元测试(一种称为TDD的实践)编写一个新的类，那么他们会更加关注类的使用方式，因为Unit测试只是关于如何使用类以及预期的行为的文档。单元测试是关于设计和文档代码的能力。单元测试还有其他几个好处，但这是目前为止的主要优点。

从这个角度来看，如果测试人员擅长于代码的设计和文档化(也就是如果测试人员擅长编写单元测试)，那么就无关紧要了，因为从定义上来说，这就是开发人员要做的事情。

非单元测试的

单元测试

相当多的人和公司已经发展了他们自己对什么是单元测试的理解。有时，他们开始将用代码编写的每个测试称为“单元测试”，而在现实中，还有其他类型的自动化测试，如集成测试或验收测试--据我所知，这些测试的命名和范围没有单元测试的名称和范围那么明确。

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

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