软件测试的基本类型

软件测试类型

功能测试

功能测试的目的是为了暴露程序的错误以及与规格说明不一致之处，而不是为了证明程序符合其外部规格说明。

功能测试是一种黑盒测试，功能测试常用步骤有：根据需求来细分功能点，根据功能点派生测试需求，根据测试需求设计功能测试用例。

单元测试

单元测试并不是对整个程序进行测试，而是对构成程序的较小模块进行测试。单元测试减小了调试的难度（一旦某个错误被发现出来，我们就知道它在哪个具体的模块中）；单元测试提供了同时测试多个模块的可能，将并行工程引入软件测试中。

对V模型编码

单元测试总体上是面向白盒测试的，因此，单元测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

集成测试

自顶向下集成和自底向上集成。对系统的接口进行正确性检验的测试工作。集成测试是在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。

对应详细设计

系统测试

是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。

对应概要设计

系统测试的目的是为了证明程序不能实现其目标，系统测试的测试用例设计有以下14种类型：

1. 能力测试：是判断目标文档提及的每一项能力（或功能）是否都确实已经实现。
2. 容量测试：使程序经受大容量数据的检验。容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量。
3. 强度测试：使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。
4. 易用性测试：试图发现人为因素或易用性的问题。
5. 安全性测试：设计测试用例来突破程序安全检查的过程。举例来说，我们可以设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制。
6. 性能测试：很多软件都有特定的性能或效率目标，这终特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。
7. 存储测试：
8. 配置测试：
9. 兼容性测试。
10. 安装测试：有些类型的软件系统安装过程非常复杂，测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这尤其重要。安装程序如果出现故障，会影响用户对软件的成功体验。
11. 可靠性测试：所有类型的测试都是为了提高软件的可靠性，但是如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。
12. 可恢复性测试：诸如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统测试的一个目标是证明这些恢复机制不能够正确发挥作用。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复。
13. 适用性测试
14. 文档测试：检查用户文档的正确性。用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。

验收测试：

**α测试：**是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试：是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

γ测试：通常是产品型软件正式上市发布前的最后一轮测试。不依赖测试用例和文档。

静态测试：

不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。

动态测试：

是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。

回归测试：

​ 就是以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug。

​ 验证bug有没有修复完成，如果修复完成，则关闭bug，没有修改还，重新指派。

冒烟测试：

在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。为了验证开发提测的版本没有质量问题，是否堵塞测试、一般做的第一个版本测试，用例优先级高、数量少（业务流程性测试用例）

全量测试：

就是对系统所有的功能进行测试，所有的测试用例执行一遍。

交叉测试：

交换模块执行测试

自动化测试：

自动化测试：以程序测试程序、以代码代替思维、以脚本运行代替手工测试。

• 回归测试更方便、可靠。由于回归测试的业务流程操作和测试用例是预先设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。
• 可运行更多更繁琐的测试，且快速高效。
• 可执行一些对于手工测试来说相当困难或根本做不到的测试。比如，对大量用户的并发测试等。
• 具有一致性和可重复性的特点。
• 自动化测试脚本完全具有复用性。由于自动化测试通常以脚本的方式实现，这样在不同的版本之间，就可能只需要做少量的维护甚至不做任何修改，实现在不同的测试版本中使用相同的测试脚本执行相同的测试用例。

自动化测试的劣势

• 永远不可能完全取代手工测试。自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合转换成自动化测试用例的。
• 无法保证测试的正确性。测试脚本本身也可能存在缺陷。
• 手工测试能发现的缺陷远比自动化测试多。自动化测试几乎是无法发现新缺陷。
• 自动化测试工具是死的，它本身没有任何想象力。
• 自动化测试对测试工程师来说必须有一定的开发技术背景。

引入自动化测试的时机

• 项目周期长，系统版本不断。主要在于回归测试。
• 需求变更不频繁。
• 系统中的测试对象基本可以正常识别，不存在大批量第三方控件。
• 需要反复测试，如可靠性测试需要进行上千次的系统测试。