如果是单元测试，那么开发人员应该负责除单元测试之外的其他测试吗？

我目前正在从事一个相当大的项目，并且我已经使用JUnit和EasyMock相当广泛地进行了单元测试功能。我现在对我应该担心的其他类型的测试感兴趣。作为开发人员，我有责任担心诸如功能测试或回归测试之类的事情吗？是否有很好的方法将这些以可用的方式集成到Maven / Ant / Gradle等工具中？这些是否更适合测试人员或BA？我还缺少其他有用的测试类型吗？

努力交付无缺陷的代码是您的责任。您应该编写，帮助编写或确保编写或执行测试，以使您对所交付的代码充满信心。

注意：我并不是说您必须提供无缺陷的代码。相反，您应该尝试针对给定的要求编写最好的代码。能够做到这一点部分意味着应该对代码进行测试。

这是否意味着您个人负责功能和回归测试，很大程度上取决于公司的组织方式。我认识的所有最熟练的程序员都不问自己“编写X型测试是我的责任吗？”。相反，他们问自己“我该怎么做才能确保我的代码得到正确测试？”。答案可能是编写单元测试，或将测试添加到回归中，或者可能意味着与QA专业人员交谈并帮助他们了解需要编写哪些测试。但是，在所有情况下，这意味着他们对所编写的代码足够在意，以确保对其进行了正确的测试。

底线：您应该负责提供高质量的代码。如果那意味着您需要编写一些功能测试或回归测试，请执行此操作。

这可能对您有帮助：

Q1由开发人员编写。

第2季度由开发人员自动化，并与业务和/或测试人员协作编写。

我还缺少其他有用的测试类型吗？

我推荐使用Gherkin语言的 BDD样式框架进行验收测试：JBehave（Java），Cucumber（Ruby），Behat（PHP）等。这种类型的测试相对于单元测试具有一些优势：

• 非开发人员易于阅读测试，因此您可以向客户展示测试
• 测试清楚地描述了业务流程，而没有涉及实现细节（我并不意味着实现并不重要-可以肯定-但是将业务需求与代码本身分开会更好）
• 测试执行用户将使用您的应用程序执行的操作
• 它们更易于编写（恕我直言，可能取决于语言和框架）：无需嘲笑，技术细节较少

功能测试可以像单元测试一样自动进行，对于测试项目的不同组件如何协同工作以及系统如何反映业务规则非常有用。

此外，此自动化测试还可以作为回归和验收测试套件，用于对软件进行的任何主要（或次要）更改（错误修复，重构，业务更改，新功能等）。这使开发人员更有信心这样做。

有几种用于此类测试的框架，我们使用的fitnesse效果非常好。拥有一个非常好的用于测试网页的库（我们将其用于测试我们的Web应用程序和我们的Web服务），并且它与Maven和Jenkins集成得很好。

我们还曾经在开发人员之间进行“跨功能测试”，但是这种测试不是“可重复的”，因此其用途受到限制。

作为一名开发人员，我认为自己有责任对我所有的代码进行单元测试，并尽最大可能保证它没有缺陷。这就是为什么我们有很多工具可供使用，例如模拟。在测试中创建模拟对象的目的恰恰是试图将您的代码与“外部”世界隔离开来，并确保其工作正常，并且如果出现任何故障，“这不是您的错”。

话虽这么说，尽管事实上这不是您的错，并且您的代码按预期运行，但这并不意味着您无法在其余测试中提供帮助。我相信，将您的工作与他人所做的工作相结合和帮助也是您的责任。IT开发团队每次都应像注油机一样工作，并与其他部门（例如QA）作为更大的团队一起工作，以提供可靠的软件。

但这是团队的工作，而不仅仅是您的。

显然是集成测试 ; 它们比单元测试更重要，更难编写。就像盖房子一样。通过单元测试，您只能确保砖是坚固的，并且可以承受压力，温度，湿度和其他条件。但是，您不知道这房子的外观和砖块拼在一起的行为。

大型项目（尤其是驻留在容器中的Java项目）的问题是集成测试很困难。因此，为了促进大型项目中的系统集成测试，需要一个专门针对项目而设计的测试框架，这是开发人员对其进行编码的工作。最近，该领域已经取得了很大的进步，诸如Arquillian之类的平台极大地简化了测试框架的编写（甚​​至替代了它）。

在现实世界中，您只负责团队/老板使您负责。如果您不知疲倦地被薪水或契约辛劳，找到每一个角落和缝隙，并跳到老板（或更糟糕的市场营销）对业务逻辑错误的解释的兴起，那么您就应该对所有事情负责。

因此，换句话说，请执行提供给您的范围所要求的操作。从某种常识出发，或者看到其他人使用您正在构建的产品来获得用例和可能要解决的问题的感觉，这是一个不错的选择，但是在“修复”之前，请您的团队或老板来解决。这包括您选择的工具。您的所有努力应该是每个人都参与的工作。

如果您的问题涉及有用的错误跟踪，那么在通信系统方面，我喜欢bugzilla，google docs，zendesk或basecamp。

我认为这还没有解决-如果错过了，抱歉。

一个问题是有效利用开发人员时间。

开发人员通常缺乏擅长某些类型测试的技能。部分地，这是自然的。这就是作者拥有编辑的原因。如果距离太近，很难看到某处的缺陷。但这也关乎不同的技能和不同的专业。

在这种情况下，花费时间测试的开发人员在成本：收益方面很差。开发人员在做其他事情时会更有效率，而专业的测试人员在进行测试时会更有效率。

当然，这是在做出各种不一定有效的假设。例如，在一家小公司中，雇用专门从事测试的人员可能没有任何意义。尽管雇用额外的支持人员并让他们进行一些测试，或者至少让人们测试他们自己没有编写的代码可能更有意义。

我相信，在发布进行质量检查之前，包括所有可能的测试场景是我们（也是开发人员）的责任。质量检查的目的是验证软件。另外，为错误编写自己的代码将总是使您在质量检查时看起来不错。

谁比开发人员更好地知道哪些测试案例最相关。开发人员应负责进行所有的单元测试，并在可能的情况下帮助编写和执行测试脚本。由于在大型项目中很少这样做，因此应该给开发人员一些时间来审查所有测试用例。此外，开发人员应具有知识并使用各种可用的自动化测试工具。

在我的开发生涯中，我发现，如果开发团队和测试团队之间紧密集成，则项目最终会获得更好的结果。

每个小组中至少应有一名成员参加其他计划和实施会议。