一、为什么要对软件测试进⾏分类？

        软件测试是软件⽣命周期中的⼀个重要环节，具有较⾼的复杂性，对于软件测试，可以从不同的⻆度 加以分类，使开发者在软件开发过程中的不同层次、不同阶段对测试⼯作进⾏更好的执⾏和管理测试 的分类⽅法

        简单来说，很多测试的名称，需要了解每个测试是干什么的。

二、按照测试⽬标分类 

2.1 界面测试（UI测试）

⼀般包括如下内容：

• 验证界⾯内容显⽰的完整性，⼀致性，准确性，友好性。⽐如界⾯内容对屏幕⼤⼩的⾃适应，换

⾏，内容是否全部清晰展⽰；

• 验证整个界⾯布局和排版是否合理，不同板块字体的设计，图⽚的展⽰是否符合需求；

• 对界⾯不同控件的测试，⽐如，对话框，⽂本框，滚动条，选项按钮等是否可以正常使⽤，有效

和 ⽆效的状态是否设计合理；

• 界⾯的布局和⾊调符合当下时事的发展。（每个软件都有自己的风格和主色调，例如淘宝就是橙色、支付宝就是蓝色、美团就是黄色的）

界面自适应

例如：

正常情况的网页是这样

其他屏幕由于尺寸等原因，图片文字等被遮挡

对比设计图，界面有所差异也是bug

 例如原设计图

实际前端页面

有缺少的信息，或者图片大小比例不一致

2.2 功能测试

        根据产品特性、操作描述和⽤⼾⽅案，测试⼀个产品的特性和可操作⾏为以确定它们满⾜设计需求。

        为了确保程序以期望的⽅式运⾏⽽按功能要求对软件进⾏的测试，通过对⼀个系统的所有的特性和 功能都进⾏测试确保符合需求和规范

2.3 性能测试

        我们在使⽤软件的时候有时会碰到软件⽹⻚打开时越来越慢，查询数据时很⻓时间才显⽰列表，软件运⾏越来越慢等问题，这些问题都是系统的性能问题引起的。

例如从时间看，响应时间越短（毫秒内），性能越好

 2.3 可靠性测试

可靠性（Availability）即可⽤性，是指系统正常运⾏的能⼒或者程度，⼀般⽤正常向⽤⼾提供软件 服务 的时间占总时间的百分⽐表⽰。

可靠性 = 正常运⾏时间/（正常运⾏时间+⾮正常运⾏时间）*100%

例如：

让⽼王请吃饭，要求了⼗次，但是他只请了⼀次，那么我们说⽼王的可靠性是10%，那么我们称⽼ 王这⼈不可靠

可⽤性指标⼀般要求达到4个或5个“9”，即99.99%或者99.999%

        如果可⽤性达到 99.99% ，对于⼀个全年不间断（7*24的⽅式）运⾏的系统，意味着全年 正常工作时间约为525547min，不能正常⼯作的时间只有53min，不到⼀个⼩时。

        如果可⽤性达到 99.999% ，意味着全年不能正常⼯作的时间只有5min。

        不同的应⽤系统，可⽤性的要求是不⼀样的，⾮实时性的信息系统或⼀般⽹站要求都很低，99%和 99.5%就可以了，但是军事系统，要求则很⾼；

 

2.4 安全性测试

        安全性是指信息安全，是指计算机系统或⽹络保护⽤⼾数据隐私，完整，保护数据正常传输和抵御 ⿊ 客，病毒攻击的能⼒。

        一般安全测试由专门的网络安全人员进行测试。网络安全人员将模拟黑客的攻击方式，对网站进行攻击分析，找安全漏洞，提交安全测试报告。

安全性测试属于⾮功能性测试很重要的⼀个⽅⾯，系统常⻅的安全漏洞和威胁如下

• 输⼊域，如输⼊恶性或者带有病毒的脚本或⻓字符串；

• 代码中的安全性问题，如SQL/XML注⼊

• 不安全的数据存储或者传递

• 数据⽂件，邮件⽂件，系统配置⽂件等⾥⾯有危害系统的信息或者数据；

• 有问题的访问控制，权限分配等

• 假冒ID：⾝份欺骗

• 篡改，对数据的恶意修改，破坏数据的完整性

 2.4.1 SQL注入

        sql注入本质上是在对数据库进行攻击。程序员对用户输入数据的合法性没有判断和处理，导致攻击者可以在 Web 应用程序中事先定义好的 SQL 语句中添加额外的 SQL 语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步获取到数据信息。

例如万能的sql注入语句：

' or 1=1 --、' or '1'='1、" or 1=1 --

例如用户登录

        正常情况应该是在用户名的输入框中 输入用户id，然后数据库查询是否有这个用户，再进行下一步判断。

        但是这个用户故意输入 1'or'1=1

用户点击提交，发送请求后，后端会将1'or'1=1拼接到查询语句select * from user where userId ='用户id'这里面。

结果，将整个数据库的user表的数据返回了。这造成了严重的数据泄漏，非常危险。

 2.4.1 XSS攻击

XSS攻击（Cross Site Scripting）中文名称为：跨站脚本攻击 

        XSS的重点不在于跨站点，而在于脚本的执行。

        XSS的原理是：
        恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。

        XSS攻击最主要有如下分类：反射型、存储型、及 DOM-based型。 反射性和DOM-baseed型可以归类为非持久性XSS攻击。存储型可以归类为持久性XSS攻击

常见的xss攻击比方说：恶意链接、alert()弹窗

1. 攻击者在url后面的参数中加入恶意攻击代码。
2. 当用户打开带有恶意代码的URL的时候，网站服务端将恶意代码从URL中取出，拼接在html中并且返回给浏览器端。
3. 用户浏览器接收到响应后执行解析，其中的恶意代码也会被执行到。
4. 攻击者通过恶意代码来窃取到用户数据并发送到攻击者的网站。攻击者会获取到比如cookie等信息，然后使用该信息来冒充合法用户
的行为，调用目标网站接口执行攻击等操作。 

2.4.2 越权

越权：垂直越权、水平越权

垂直越权：超过当前用户本身的权限。

        例如：员工的上级老板。员工看到的公司的页面，和老板看到的页面就不一样。老板可以对员工的调动、增加删除进行操作。而员工就不行。如果员工有这个权限了，就是垂直越权。 

水平越权：同级别的用户的权限之间越权。

        例如：很多员工，员工1、员工2等，每个员工的个人信息（身份证号、薪资等）应该只有自己能看到，加入员工1 的信息其他员工也能看到，那么就是水平越权了。

 

2.5 易用性测试

        许多产品都应⽤⼈体⼯程学的研究成果，是产品在使⽤起来更加灵活和，舒适。软件产品也始终关注 ⽤⼾体验，让⽤⼾获得舒适，易⽤的体验，针对软件这⽅⾯的测试称之为易⽤性测试。

        易⽤性在ISO25020标准中指容易发现，容易学习和容易使⽤。易⽤性包含七个要素：符合标准和规范，直观性，⼀致性，灵活性，舒适性，正确性和实⽤性。

1.标准性和规范性

        对于现有的软件运⾏平台，通常其UI标准已经不知不觉地被确⽴了，成为⼤家的共识。多数⽤⼾已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。

        ⽐如安装软件的 界⾯的外观，在什么场合使⽤恰当的对话框等。

        所以⽤⼾界⾯上的各中信息应该符合规范和习惯，否则⽤⼾使⽤起来会不舒适，并得不到⽤⼾的认可。

        测试⼈员需要把与标准规范，习惯不⼀致的问题报告为缺陷

2，直观性

        ⽤⼾界⾯的直观性，要求软件功能特性易懂，清晰。⽤⼾界⾯布局合理，对操作的响应在⽤⼾的预期之中。

        ⽐如数据统计结果⽤报表的形式（条形图，扇形图等）展⽰清晰直观；现在主流的很多搜索引擎和⽇历的设计也有直观性的特点；

3，灵活性

        软件可以有不同的选项以满⾜不同使⽤习惯的⽤⼾来完成相同的功能。但是灵活性的设计要把握好度，不然可能由于太多的⽤⼾状态和⽅式的选择，增加了软件设计的复杂性，和程序实现的难度。

        例如 ：⼿机键盘有九宫格和全键盘，还⽀持⼿写，满⾜了不同⽤⼾的需求

4，舒适性

舒适性主要强调界⾯友好，美观，操作过程顺畅，⾊彩⽤运恰当，按钮的⽴体感等。

        例如左⼿⿏标的 设 置给习惯⽤左⼿的⼈带来了便利，也为右⼿⼗分劳累时提供了另⼀种途径；

三、按照执⾏⽅式 

3.1 静态测试

        所谓静态测试（static testing）就是不实际运⾏被测软件，⽽只是静态地检查程序代码、界⾯或⽂档 中可能存在的错误的过程。（火眼金睛找问题所在~）

        

        不以测试数据的执⾏⽽是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻 辑、代码⻛格和规格等来检查程序的正确性。

        常⻅的静态测试⽅式有代码⾛查，代码扫描⼯具等

        SonarQube 很多企业都在用的静态扫描工具，检查变量命名、函数命名、输入输出方法、内存泄漏。

3.2 动态测试

        动态测试（dynamic testing），指的是实际运⾏被测程序，输⼊相应的测试数据，检查实际输出结果和预期结果是否相符的过程。

        所以判断⼀个测试属于动态测试还是静态的，唯⼀的标准就是看是否运⾏程序。

        ⼤多数软件测试⼯作都属于动态测试。

 动态测试⽅法主要包含六种测试⽅法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖

        （动态测试这六种方法在下面的 白盒测试 中具体说明）

四、按照测试⽅法 

4.1 ⽩盒测试

        ⽩盒测试⼜称为结构测试或逻辑测试，它⼀般⽤来分析程序的内部结构，针对程序的逻辑结构来设计测试⽤例进⾏测试。

        ⽩盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进⾏覆盖测试；在程序不同地⽅设⽴检查点，检查程序的状态，以确定实际运⾏状态与预期状态是否⼀致。

        

⽩盒测试主要分为：静态测试和动态测试

         静态测试 常⻅于桌⾯检查、代码审查、代码⾛查、代 码扫描⼯具

         动态测试 ⽅法主要包含六种测试⽅法： 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖

 

4.1.1  语句覆盖

每个语句至少被执行一次。（都执行一遍，看看是否能执行到）

例如：这两个语句如果都要执行到

4.1.2  判定覆盖 

就是if语句，整个if语句 既要判断为 true真的情况，又要判断为 false假的情况

 

判定覆盖

A and B 这个语句要为T => A=T B=T ①

A and B 这个语句要为F => A=T B=F 或者A=F B=T或者 A=F B=F②

C or D   这个语句要为T => C=T D=T/F 或者 C=T/F D=T③

C or D   这个语句要为F => C=F D=F ④

得出⽤例：

⽤例1：A=T B=T C=T D=F 满⾜①③

⽤例2：A=T B=F C=F D=F 满⾜②④

4.1.3  条件覆盖  

同样是if语句，if语句里由很多个条件，单独拿出条件，每种条件有 true 和 false两种结果，覆盖所有条件为真和假的情况

条件覆盖

A ：T F

B ：T F

C ：T F

D ：T F

      ⑤ ⑥

得出⽤例：

⽤例1：A=T B=T C=T D=T

⽤例2：A=F B=F C=F D=F

 

4.1.4  判定条件覆盖   

结合判定覆盖 和 条件覆盖来设计测试用例 ，用例既可以覆盖到 判定，也可以覆盖到条件。

判定覆盖

得出⽤例：

⽤例1：A=T B=T C=T D=F 满⾜①③

（A=T B=T）这个语句为 T ,( C=T D=F) 这个语句为 T

⽤例2：A=T B=F C=F D=F 满⾜②④

（A=T B=F）这个语句为 F ,( C=F D=F) 这个语句为 F

条件覆盖

得出⽤例：

⽤例1：A=T B=T C=T D=T

（A=T B=T）这个语句为 T ,( C=T D=T) 这个语句为 T

⽤例2：A=F B=F C=F D=F

（A=F B=F）这个语句为 F ,( C=F D=F) 这个语句为 F

可以发现在条件覆盖的用例里，对整个语句判定的结果，与判定覆盖的结果一致。

说明这个 条件覆盖的用例 ，本身包含了 判定覆盖 ，这就是 判定条件覆盖

判定条件覆盖

得出⽤例：

⽤例1：A=T B=T C=T D=T 满⾜①③⑤

⽤例2：A=F B=F C=F D=F 满⾜②④⑥

4.1.5  条件组合覆盖    

A B ∣ C D

T T ∣ T T  ①

T F ∣ T T  ②

F T ∣ T T  ③

F F ∣ T T  ④

每⾏就可以是⼀个⽤例，⼀共四个⽤例。

4.1.5  路径覆盖     

这里的所有路径都要覆盖到

需要覆盖的测试路径：

1）3,12

2）3,4,3,12

3）3,4,5,4,3,12

4）3,4,5,678,4,3,12

 总结

• ⽩盒测试主要应⽤于单元测试阶段

• 先执⾏静态设计⽤例的⽅法，再执⾏动态设计测试⽤例的⽅法

• 设计⽤例⼀般使⽤路径测试，重点模块追加使⽤逻辑覆盖⽅法

4.2 黑盒测试 

         ⿊盒测试 就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使⽤、是否能适当的接收输⼊数据⽽输出正确的结果，满⾜规范需求。

        所以，⿊盒测试⼜称之为数据驱动测试，只注重软件的功能，覆盖产品所有功能。

        从⽤⼾⻆度出发设计测试⽤例，很容易的知道⽤⼾会⽤到哪些功能，会遇到哪些问题，锻炼测试⼈员的产品思维。

        测试⽤例是基于软件需求开发⽂档，不容易遗漏软件需求⽂档中需要测试的功能。

优点：

        不需要了解程序内部的代码以及实现，不关注软件内部的实现。

缺点：

        不可能覆盖所有代码。

⿊盒测试⽤到的测试⽅法有， 等价类，边界值，因果图，场景法，错误猜测法 等

4.2 灰盒测试  

         灰盒测试 ，是介于⽩盒测试与⿊盒测试之间的⼀种测试，灰盒测试多⽤于 集成测试 阶段，不仅关注输出、输⼊的正确性，同时也关注程序内部的情况。

        但是，灰盒测试没有⽩盒测试详细和完整，⿊盒测试是覆盖产品范围最⼴的测试，因此灰盒测试基本是不能够替代⿊盒测试（只测试主要的功能，不能覆盖所有功能），否则需要很⼤的代价，设计⾮常多的⽤例。

常⻅⾯试题：你知道的测试⽅法有哪些？哪种⽤的⽐较多？

        常⻅的测试⽅法有⿊盒测试，⽩盒测试和灰盒测试。

        开发⼈员主要⽤⽩盒测试和灰盒测试。

        测试⼈员主要⽤⽩盒测试和⿊盒测试。对于测试⼈员来说，相较于⽩盒测试，黑盒测试用的更多。

 

五、按照测试阶段分类  

5.1 单元测试

        与编码同步进⾏，针对软件最⼩组成单元进⾏测试，主要采⽤⽩盒测试⽅法，从被测对象的内部结 构出发设计测试⽤例

        这个最小单元可以是：一个方法、一个类、一个接口等

例如：对冒泡排序这个方法进行测试

public class Main {
 public static void bubbleSort(int[] arr) {
     int n = arr.length;
     for (int i = 0; i < n; i++) {
     // 每轮遍历将最⼤的数移到末尾
         for (int j = 0; j < n - i - 1; j++) {
             if (arr[j] > arr[j+1]) {
                 int temp = arr[j];
                 arr[j] = arr[j+1];
                 arr[j+1] = temp;
             }
             }
     }
 }

那么测试数据：

1.空数组

2.有序数组

3.无序数组

4.有重复数据的数组

 

单元测试框架 ：例如Java常用的 JUnit 

Junit提供了⾮常多注解和断⾔函数，有效提升开发单元测试脚本的效率

5.2 集成测试

         集成测试 也称联合测试（联调）、组装测试，将程序模块采⽤适当的集成策略组装起来，对系统的接⼝及集成后的功能进⾏正确性检测的测试⼯作。集成主要⽬的是检查软件单位之间的接⼝是否正确。

例如：上面的单元测试的排序方法，放入整个排序模块里面

        排序系统：获取用户输入的数据，进行排序，输出数据结果..

        会包含很多方法，把这些方法，也就是很多小的单元集成组装在一起，进行测试，就是集成测试

• 测试阶段：⼀般单元测试之后进⾏

• 测试对象：模块间的接⼝

• 测试⼈员：⽩盒测试⼯程师或开发⼯程师

• 测试依据：单元测试的模块+概要设计⽂档

• 测试⽅法：⿊盒测试与⽩盒测试相结合

• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

5.3 系统测试

对通过集成测试的系统进⾏整体测试，验证系统功能性和⾮功能性需求的实现。

• 测试阶段：集成测试通过之后

• 测试对象：整个系统（软、硬件）

• 测试⼈员：⿊盒测试⼯程师

• 测试依据：需求规格说明⽂档

• 测试⽅法：⿊盒测试

• 测试内容：功能、界⾯、可靠性、易⽤性、性能、兼容性、安全性等

回归测试和冒烟测试都属于系统测试。

5.3.1 冒烟测试

        冒烟测试的对象是每⼀个新编译的需要正式测试的软件版本，⽬的是确认软件主要功能和核⼼流程正常，在正式进⾏系统测试之前执⾏。

        冒烟测试⼀般在开发⼈员开发完毕后提交给测试⼈员来进⾏测试时，先进⾏冒烟测试，保证基本功能正常，不阻碍后续的测试。

        如果冒烟测试通过，则测试⼈员开始进⾏正式的系统测试，如果不通过，则测试⼈员可以让开发⼈员重新修复代码直到冒烟测试通过，再开始进⾏系统测试。

例如：天太热了，买回来空调降降温。

        结果刚插电源，空调就呼呼的响，还冒烟，这就说明冒烟测试没通过，打电话给客服，退货！！

5.3.2 回归测试

         回归测试 是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错 误。

        在整个软件测试过程中占有很⼤的⼯作量⽐重，软件开发的各个阶段都会进⾏多次回归测试。随着系 统的庞⼤，回归测试的成本越来越⼤，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的.

例如 ：博客系统有 登录页面、首页、博客编辑页、博客详情页...

        单元测试、集成测试这种，我们单一的去看每个页面的每个具体的功能和细节，而回归测试就是更加整体的测试。比如页面之间跳转是否正常，没有登录之前不能看博客详情页..

总结

1. 冒烟测试（Smoke Testing）：

◦ 阶段： 通常在软件开发的早期阶段进⾏，主要⽤于验证基本功能是否正常⼯作。

◦ ⽬的： 确保软件的主要功能能够基本运⾏，以便在后续的详细测试阶段发现更深层次的问

题。

2. 回归测试（Regression Testing）：

◦ 阶段： 在软件开发的后期，通常在每次代码修改或新增功能后执⾏。

◦ ⽬的： 确保已有的功能仍然正常⼯作，并且新的更改没有引⼊新的错误。⽬的是防⽌已有功 能因为代码修改⽽出现问题。

        虽然它们都属于系统测试，但冒烟测试注重最基本的功能，⽽回归测试关注全⾯的功能，包括已 有功能和新添加的功能。这两种测试类型在测试策略中起到了不同的作⽤，帮助确保软件质量和稳定性。

5.4 验收测试

        针对⽤⼾需求，对通过系统测试的软件进⾏交付性测试，以确定系统是否满⾜验收标准，由⽤⼾或其他授权机构决定是否接受系统。验收测试是部署软件之前的最后⼀个测试操作。它是技术测试的

        最后⼀个阶段，也称为交付测试。验收测试的⽬的是确保软件准备就绪，按照项⽬合同、任务书、 双⽅约定的验收依据⽂档，向软件购买都展⽰该软件系统满⾜原始需求。

• 测试阶段：系统测试通过之后

• 测试对象：整个系统（包括软硬件）。

• 测试⼈员：主要是最终⽤⼾或者需求⽅。

• 测试依据：⽤⼾需求、验收标准

• 测试⽅法：⿊盒测试

• 测试内容：同系统测试(功能...各类⽂档等)

单元测试，集成测试，系统测试，回归测试之间的关系

总结

用造车举例

        造⻋需要原材料，如⻋轮、发动机等零部件不是⻋企⾃⼰制造出来的，⽽是通过购买零部件来造⻋。

        对买来的零部件进⾏检查，零部件是否符合造⻋标准（ 单元测试 ）

        零件确认完毕，接下来就是复杂的造⻋⼯艺，将零部件集成起来构成了⼀辆⻋，并初步检查拼⻋的⻋是否能正常运作（ 集成测试 ）

        ⼀辆⻋成型之后并不意味着就可以直接销售给客⼾了，需要⻋企专业的测试⼈员进⾏详细⽽完整的测试。（ 系统测试 ）

        专业的测试⼈员对企业测试完毕，通过测试的汽⻋将会在⻋展或者4S店进⾏展⽰，供⽤⼾进⾏选择和购买。⽤⼾在选择汽⻋的过程中也会对⻋外观以及性能等⽅⾯进⾏校验（ 验收测试 ）

        除了以上阶段外，还有两个⾮常重要，在⼯作中经常会听到：冒烟测试 和 回归测试

六、按照是否⼿⼯测试

6.1 ⼿⼯测试(Manual testing)

        ⼿⼯测试就是由⼈去⼀个⼀个的输⼊⽤例，然后观察结果，和机器测试相对应，属于⽐较原始但是必须的⼀个步骤。

优点

        • 对测试⼈员技术要求没有⾃动化技术要求⾼

        • 可以进⾏发散性测试

缺点

        • 效率低

        • ⼈员，时间成本⽐起⾃动化测试都⽐较⾼

6.2 ⾃动化测试(Automation Testing)

        就是在预设条件下运⾏系统或应⽤程序，评估运⾏结果，预先条件应包括正常条件和异常条件。

        简单说 ⾃动化测试是把以⼈为驱动的测试⾏为转化为机器执⾏的⼀种过程。 ⾃动化测试⽐如功能测试⾃动化、性能测试⾃动化、安全测试⾃动化。 ⾃动化测试按照测试对象来分，还可以分为接⼝测试、 UI测试等。接⼝测试的ROI（产出投⼊⽐）要⽐UI测试⾼。

优点

        • 节省成本

        • 提⾼测试⼈员执⾏⼯作效率

        • 保障软件的质量

缺点

        • 对测试⼈员技术要求较⾼

        • 不能发散性测试

七、按照实施组织划分

7.1 α测试(Alpha Testing)

         α测试 ⼜叫 内测 或者叫 a测 ，其实都是⼀个涵义

        α测试通常是公司内部的⽤⼾在模拟实际操作环境下进⾏的测试（线下公司内部人员进行测试）。α测试的⽬的是评价软件产品的 FLURPS(即功能、可使⽤性、可靠性、性能和⽀持)。

         α测试不能由程序员或测试员完成 。

7.2 β测试(Beta Testing)

         β测试 ⼜叫 公测 或者叫 b测

        β测试由软件的最终⽤⼾们在⼀个或多个场所进⾏，这⾥就可以理解为，β测试是正式⽤⼾中的⼀部分（线上真实用户），他们在任意的场合来使⽤软件，⽬的是为了发现软件是否存在⼀系列的问题

通常会发送⼀些邀请码，来邀请⽤⼾参与项⽬测试

 7.3 a测和b测区别

7.4 第三方测试

第三⽅软件测试是指由独⽴的第三⽅公司或组织进⾏的软件测试活动