我编写软件多年，但从未掌握测试的艺术。我的典型测试包括在我的机器上进行全面运行，然后通过 VMware 在各种操作系统中进行测试。主要是一种蛮力游戏，直到它打破或不接近。在可能的情况下，我会在实际硬件上工作，但这并不总是可行的。
我的问题有两个:
- 中型专业开发机构如何进行测试？
- 哪些通用技术或程序(单元测试之外)可以应用于一个开发团队。我正在寻找实用性。
感谢您的宝贵时间和意见。
最佳答案
第一步:单元测试
将您的软件分成组件(可以是从单个功能到整个程序的任何组件)并对这些组件进行彻底的单元测试，尤其是与应用程序其余部分可以看到的 API 和行为相关的组件。 (也不要忘记检查故障模式，但要注意不要过于小心地绑定(bind)到故障的确切性质；通常只测试是否存在正确的异常类而不是其确切消息就足够了。)确保那些测试通过；您正在根据组件应该 做什么的规范磨练他们。 (自动化测试运行在这里有所帮助，CI 系统也是如此。)这很重要，因为......
第二步:集成测试
测试组成应用程序的组件组合是否正常工作(这是集成 测试)。理想情况下，您只会在此时发现事物规范中的错误(哈!)，并且尽管通过了单元测试，但无论何时您发现组件错误，这都会告诉您存在错误。每当事情无法一起工作时，尽管被告知这样做，你的规范中可能存在上一步的错误，因此你通常通过向单元测试添加更多细节并修复组件直到它们工作来解决这些问题。
请注意，要进行良好的集成，您需要保留此阶段，以便集成本身足够简单，使其属于“明显没有错误”的程序类别，而不是更大的“无明显错误”类别。像 Spring 或脚本语言这样的集成框架在这里可以提供很多帮助(尽管对于后者你必须防止偷偷创建组件；如果你创建了一个组件然后承认它并确保它有一个正确的使用契约(Contract)和单元测试以确保其符合契约(Contract)规定)。
在可能的情况下，您可以通过将其他组件组合在一起来制作组件；这些更高级别的组件需要按照上面步骤 1 中的特征进行单元测试。这听起来像是额外的工作——它可能是——但它确实具有优势，这意味着您可以对程序的更大部分使用自动化测试。 (唉，用自动化测试工具做所有集成测试更难；这样的事情往往更适合做单元测试，你可以模拟出所有不相关的部分。)但这并不能使你免于......
第 3 步:验收测试
这是对整个应用程序进行测试的地方，以查看它是否确实按预期运行。这可能是自动化的，但通常不是。这是你引入用户让他们看到事情是否如他们所期望的那样的级别，尽管你可能想先使用一些内部测试人员。这一切有多容易取决于应用程序的性质。
另请注意，用户界面往往比其他步骤花费更多时间在这一步，正是因为什么是好的 UI 很难甚至不可能用算法来确定(毕竟它与人类心理有更多关系)。
最后一点:我在这里写的内容听起来像是测试是一个费力的过程，在项目结束时需要很长时间。 事实并非如此!您通常可以先完成应用程序的某些部分，对这些部分进行集成(对其他部分进行模拟)并测试该子应用程序的可接受程度真的是。当然，这样做时要注意不要让用户相信一切都已完成；一种方法是让对话框弹出并说出诸如“这里会发生魔法”之类的话。愚蠢但有效。 :-)
关于unit-testing - 测试......专业人士是如何做的，哪些技术可以扩展到单人开发？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3795955/