Unit testing 测试。。。专业人士如何做到这一点，以及哪些技术可以扩展到单人开发？

我写软件已经多年了，但从未掌握过测试的艺术。我的典型测试包括在我的机器上进行彻底的测试，然后通过VMware在各种操作系统中进行测试。主要是一个蛮力玩它，直到它打破或不接近。在可能的情况下，我在实际的硬件上工作，但这并不总是实用的

我的问题有两个：

• 中型专业开发公司如何进行测试
• 什么样的通用技术或过程（单元测试之外）可以应用于一个由一人组成的开发团队。我在寻找实用性

---

感谢您的时间和投入。

对于小型团队来说，单元测试或自动集成测试至关重要。因为没有人手和时间进行手动测试——自动化程度越高越好。这包括持续集成

设置一个单独的“测试版”环境，该环境尽可能靠近您的生产环境。在那里进行大部分测试—这样，您将获得“发布计划”中忘记的所有内容。

步骤1：单元测试 将您的软件划分为组件（可以是从单个函数到整个程序的任何组件），并对这些组件进行彻底的单元测试，尤其是与应用程序其余部分可以看到的API和行为相关的组件。（别忘了检查故障模式，但要注意不要过于仔细地绑定到故障的确切性质；它通常足以测试是否存在正确的异常类别，而不是它的确切消息。）确保这些测试通过；您正在根据组件应该做什么的规范来磨练它们。（自动化测试运行在这里很有帮助，CI系统也是如此。）这很重要，因为

步骤2：集成测试 测试组成应用程序工作的组件的组成（这是集成测试）。理想情况下，此时您只会在事物的规范中发现bug（哈哈！），无论您在哪里发现组件错误（尽管通过了单元测试），这都会告诉您存在bug。无论什么时候，尽管被告知要这样做，但事情还是无法协同工作，您的规范中可能有上一步的错误，因此您通常会通过向单元测试添加更多细节并修复组件直到它们工作为止来解决这些问题

请注意，为了实现良好的集成，您希望保持此阶段，以便集成本身足够简单，它位于程序的“显然没有bug”类中，而不是较大的“没有明显bug”类中。像Spring或脚本语言这样的集成框架在这方面会有很大帮助（尽管对于后者，您必须防止偷偷创建组件；如果您创建了一个组件，那么就承认它，并确保它有一个适当的使用契约和单元测试，以确保它符合契约）

在可能的情况下，您可以通过将其他组件组合在一起来制作组件；这些更高级别的组件需要进行单元测试，如上述步骤1所述。这听起来像是额外的工作——可能是这样——但它确实具有这样的优势，即您可以对程序的更大部分使用自动化测试。（唉，使用自动化测试工具进行所有集成测试比较困难；在进行单元测试时，如果您可以模拟出所有不相关的部分，这些事情往往会更好地工作。）但这并不能让您免于

步骤3：验收测试 这是对整个应用程序进行测试的地方，以查看它是否真正实现了所需的功能。这可能是自动化的，但通常不是。这是一个级别，您可以让用户看到事情是否符合他们的预期，尽管您可能希望先使用内部测试人员。这一切有多容易取决于应用程序的性质

还要注意的是，用户界面在这一步中花费的时间往往比其他步骤要多，这正是因为在算法中很难确定一个好的用户界面是什么（毕竟，它与人类心理的关系要大得多）

---

最后一点提示：我在这里写的内容听起来像是测试是一个费劲的过程，在项目结束时需要花费很多时间。它不是！您通常可以在其他部分之前完成应用程序的部分，对这些部分进行集成（对其他部分进行模拟），并测试该子应用程序的可接受性。当然，在这样做的时候，要注意阻止用户相信一切都已完成；一种方法是弹出对话框，上面写着“神奇的事情发生在这里”。愚蠢但有效。：-）

我的测试工具示例是基于Java的，但我将尝试推荐那些移植到多种语言或与语言无关的工具

使用单元测试工具，如junit（移植到多种语言）。这将允许您安全地重构代码。大多数代码错误都会导致添加或更正至少一个测试

使用修订控制，并设置自动生成环境，以检出代码并生成代码。然后它应该运行自动测试套件。如果应用程序使用数据库，则构建环境应该有自己的数据库。为生产（发布）和开发代码使用不同的代码

使用集成测试工具（如HTTPunit或Synergy）来测试web应用程序。这种类型的工具基本上与语言无关，但是您可能希望选择一种可以用您正在使用的语言进行扩展的工具。对于非web应用程序，可能没有适用于您的平台的等效工具。您可能还想使用JMeter之类的性能工具

这些工具有一些安装成本，但回报很快。如果不使用这些工具，总体开发时间可能相同或更少

验收测试通常不提供