目录
44) 漏洞测试(Vulnerability Testing)
36) 完整性测试(Sanity Testing)
完整性测试用于确定一个新的软件版本是否可以开始进行正式的测试，如果一个应该在一开始使用时就崩溃，那么就说明系统还不够稳定，没有必要进行下一步测试。这种情况应该打回给开发，以免浪费时间
以我们公司为例:
- 在软件设计阶段，测试团队就会为编写冒烟测试用例;
- 开发团队在提交版本给测试之前会自己跑一下冒烟用例, 确保没有重大故障；
- 将版本提交给测试团队后，测试团队就会先跑一下完整性测试，检查一下有没有重大的，影响测试进程的bug，如果有则退回开发
- 如果通过了完整性测试, 则进行冒烟测试，如果冒烟测试没有通过也会立即打回开发。
- 顺利通过完整性测试和冒烟测试之后才会进入正式测试阶段。
这么做的目的之一就是为了降低测试团队的工作负担，因为他们要对接多个开发团队的测试任务。
37) 安全测试(Security Testing)
安全也是一个庞大的学科，而且知识每天都在更新，所以安全测试一般由特殊的安全团队执行，他们以各种黑客手段对系统进行渗透测试。
安全测试旨在确保应用或网站免受内部和外部威胁的侵害。这个测试包括预防恶意程序、病毒； 检验授权和身份验证过程的安全性。
它还会检查软件对任何黑客攻击和恶意程序的反应方式，以及在遭到黑客攻击后如何维护软件以保护数据安全
38) 冒烟测试(Smoke Testing)
冒烟测试，每当开发团队提交新的构建时，软件测试团队就会先验证构建, 并确保不存在重大问题, 如果存在重大问题会直接打回开发团队.
如何通俗地理解冒烟测试呢？这个属于来源于硬件行业，对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。举个例子，给三星Note7加电，如果没爆炸，就说明通过了‘冒烟测试’(感觉当手机测试者不容易，容易有生命危险😂)?
测试团队在确保构建稳定后才会进一步执行详细的测试。 冒烟检查会检查构建中是否存在中断缺陷(stopper defect, 即影响继续测试的缺陷)，这将阻止测试团队进一步详细测试。 即如果测试人员发现主要功能不能工作，他们会拒绝这次构建，并退回给开发团队。
冒烟测试一般在回归测试或其他详细测试之前进行
39) 静态测试(Static Testing)
静态测试有点类似于代码Review，在不执行任何代码的情况下执行(也就是不运行应用)，它涉及对可交付成果审查(inspection)、review和演练(walkthrough). 比如检查代码语法、命名约定、项目组织。
静态测试不仅适用于代码, 也适用于测试用例、测试计划和设计文档. 如果在静态测试阶段发现缺陷，可以将缺陷成本降到最低。比如在设计阶段就发现问题，相比到开发阶段甚至到生产环境出现问题要好解决
举前端的例子，静态测试可能包括:
- 使用Lint工具对程序进行规范检查，相关的工具有ESLint、TSLint、Stylint等, 甚至Typescript这些类型检查器也可以归到这个范畴
- 代码Review。有一些问题是无法通过Lint工具覆盖的，比如代码逻辑、异常捕获、项目组织、内存泄露等等，这些需要人工进行走查Review
- 检查代码是否与设计一致，是否符合软件需求、概要和详细设计，这不仅可以看出代码问题，也可以反过来更早发现需求或设计是否正确。
40) 压力测试(Stress Testing)
通过压力测试，模拟系统受到超出其规格的压力时失败的方式和时间, 找出系统的崩溃点. 这个测试在高负载情况下执行的，例如存取超过容量限制的数据、执行复杂的数据库查询、连续暴力输入到系统或加载到数据库。
41) 系统测试(System Testing)
系统测试在完整的集成系统上进行测试，也就是说系统测试一般在集成测试之后进行，集成测试之后系统成为了一个整体，系统测试在这个基础上、在真实的运行环境中验证系统是否符合业务需求。 这是一种黑盒型测试，基于总体需求规范，涵盖系统的所有组合部分。
系统测试其实不是一个具体的测试技术，而是一个测试阶段。 这个阶段会进行很多种测试，一般公司的测试团队的工作就集中在这一块。 一般包含:
- 功能测试: 即上面讲的，从系统的整体上测试是否符合业务需求
- 各种非功能测试：例如恢复测试、性能测试、压力测试、安全测试等等。
归纳一下系统测试的目的:
- 确保应用作为一个整体可以良好地运行.
- 确保应用符合业务需求
- 确保应用在真实的环境可以良好地运行。比如进行一些非功能测试，验证系统的健壮性
其实系统测试和上文说的端到端测试很像，它们要求系统作为一个整体进行测试。可以简单展开对比一下
| 系统测试 | 端到端测试 | |
|---|---|---|
| 测试范围 | 一般针对被测应用本身 | 一般针对被测应用以及其依赖的其他系统。正如其名，端到端，即从一端点到另一端点。重点关注前端、后端以及中间件之间的处理流程 |
| 测试类型 | 包含功能测试和非功能测试 | 一般涵盖所有源系统和目标系统之间的接口级别的测试 |
| 测试时机 | 一般在集成测试之后 | 一般在系统测试之后 |
42) 单元测试(Unit Testing)
测试独立的软件单元或模块称为单元测试。它通常由开发者完成，而不是由测试人员完成，因为它需要详细了解内部程序设计和代码。
单元测试是和我们开发者最密切相关的测试类型。它的测试对象是软件单元。软件单元可以是一个函数/方法、一个类或者一个GUI组件等。
这是一种白盒测试，所以要求由开发者自己进行，因为只有开发者才知道单元的内部实现。单元测试一般会使用测试覆盖率来验证单元测试的完成度.
前端常见的单元测试工具有Jest、Mocha、Jasmine等等. 下面是典型的BDD风格的单元测试组织:
43) 可用性测试(Usability Testing)
可用性测试用于检测应用的用户友好程度(User-friendliness). 它会验证新用户受可以轻松理解应用流程，如果用户陷入麻烦，测试人员要记录好并提供帮助。可以认为可用性测试是在检查系统的导航性(navigation)
44) 漏洞测试(Vulnerability Testing)
漏洞测试，涉及识别软件、硬件和网络中的漏洞。如果漏洞容易受到攻击，或者容易受到病毒和蠕虫感染，黑客或恶意程序就可以控制系统。
因此有必要在投入生产环境之前检查这些系统是否存在漏洞。
45) 容量测试(Volume Testing)
容量测试是由性能测试团队执行的一种非功能测试。容量测试会检查应用程序遇到大量的数据时的系统行为和响应时间。这种大量数据可能会影响系统的性能和处理时间的速度。
46) 白盒测试(White Box Testing)
白盒测试, 它也被称为玻璃盒测试、结构测试、逻辑驱动测试或基于代码的测试, 基于应用程序代码的内部逻辑。即测试人员应该知道内部软件和代码是如何工作的, 对所有的逻辑路径进行覆盖测试。上面提到的单元测试和静态测试就是典型的白盒测试, 基本上白盒测试可以等价于单元测试
逻辑路径包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等等.
总结
上面提到的软件测试类型只是测试中的一部分，实际有超过100种的测试类型，但是并非所有测试类型都会被所有项目使用，所以我这里只是列举一些比较常见的软件测试类型。
另外不同的组织中可能会有不同的定义或过程，但是基本概念在任何地方都是相同的。当项目、需求和范围发生变化时，这些测试类型、过程及其实现方法会不断演变
最后
俺叫小枫，一个成天想着一夜暴富的测试员
（1140267353）一起成长一起加油的伙伴群！软件测试，与你同行！
群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！
点赞关注不迷路！！！【三连ღ】，有问题也可私聊哟~(*╹▽╹*)
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
