🤗 ApiHug × {Postman|Swagger|Api...} = 快↑ 准√ 省↓

1. GitHub - apihug/apihug.com: All abou the Apihug   
2. apihug.com: 有爱，有温度，有质量，有信任
3. ApiHug - API design Copilot - IntelliJ IDEs Plugin | Marketplace

写在前面

在进行下一章节前可以问问自己这几个问题：

1. 什么是软件测试？
2. 开发人员和软件测试是否有关？还是只有QA组同学彩盒测试有关？
3. 写过测试？
4. 传统行业如何进行质量保证？
5. 测试重要否？
6. 测试是否耽误事？

测试7大原则

1. Testing shows the presence of defects
2. Exhaustive Testing is not possible
3. Early Testing
4. Defect Clustering
5. Pesticide Paradox
6. Testing is context-dependent
7. Absence of errors fallacy

#测试显示bug的存在

测试应用程序只能显示在应用程序中存在一个或多个缺陷，但是，仅仅通过测试并不能证明应用程序没有错误。因此，设计测试用例使其尽可能多的找到缺陷是很重要的。

#穷举测试不可能

除非受测试应用（UAT）具有非常简单的逻辑结构和有限的输入，进行所有测试数据和场景的组合是不可能的事。出于这个原因，风险评估和优先级被用于集中测试最重要的方面。

#尽早测试

我们越早开始测试活动，就越可以更好的利用可用的时间。当最初的产品，例如要求或设计文件完成后，我们就可以开始测试。测试阶段常会在开发周期的最后部分也就是开发完成之后遭到时间压缩。因此，尽早开始测试，我们可以针对开发生命周期的每个阶段进行测试的准备。

另一个关于尽早测试的重要的一点是，当缺陷在生命周期中更早的被发现时，它们更容易解决而且成本更低。改变不正确的要求比起必须改变一个大型系统中没有按照要求或设计来工作的功能要成本低得多！

#缺陷群

在测试过程中，可以观察到，大多数报告的缺陷都与少数几个系统内的模块有关。即少量模块包含了系统中大部分的缺陷。这也是帕雷托法则（二八定律）在软件测试方面的实际应用：约80％的问题被发现在20%的模块中。

#杀虫剂悖论

如果持续运行同一套测试一遍又一遍，有可能那些测试用例就无法发现新的缺陷。因为随着系统的发展，许多以前报道的缺陷将会被修好，旧的测试用例就不再适用了。每当修复完缺陷或添加了新的功能后，我们需要做回归测试，以确保新更改的软件不破坏该软件的任何其他部分。然而，这些回归测试用例也需要根据软件本身的变化作出改变，使其能够更加适用并找到新的缺陷。

#测试是上下文相关的

不同的测试方法，测试技术和测试类型是根据应用程序的类型和性质来决定的。例如，运用于医疗设备上的软件应用程序相比游戏软件需要进行更多的测试。更重要的是医疗设备软件需要基于风险测试，需要符合医疗行业监管以及可能的特殊测试设计技术。出于同样的原因，一个非常受欢迎的网站，需要经过严格的性能试验，以及功能性的测试，以确保性能不受服务器上的负载的影响。

#无错谬误

只是因为测试没有发现软件中的任何缺陷，并不意味着该软件是随时可以发布的。被执行的测试，是否真的找到了大多数缺陷？或者，他们是否根据顾客需求设计检查软件是否满足要求？在发布软件之前，还需要考虑

#其他因素

其他原则需要注意的是：

1. 测试必须由独立的一方来完成。
2. 测试不应由该开发软件的人或者团队来执行，因为它们趋向于维护程序的正确性。
3. 最佳人员配置: 于测试需要高度的创造性和责任感，需要将人员正确地分配到各个设计，实施和分析测试案例， 测试数据和测试结果的岗位上去。
4. 除了有效条件之外，也要对无效的和意想不到的输入条件进行测试。
5. 程序应该在无效情况下产生正确的消息并在有效情况下产生正确的结果。
6. 保持测试过程中软件的静态。
7. 在对程序进行测试用例集的执行过程不能对程序进行修改。
8. 尽可能提供预期的测试结果。
9. 测试文档的必要组成部分包括了预期结果的说明，即使提供这样的结果可能是不切实际的。

我们