软件测试之测试分类（沉淀中）

1. 为什么要对软件测试进⾏分类

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

2. 按照测试⽬标分类

2.1 界⾯测试

软件只是⼀种⼯具，软件与⼈的信息交流是通过界⾯来进⾏的，界⾯是软件与⽤⼾交流的最直层，界⾯的设计决定了⽤⼾对我们设计的软件的第⼀印象；界⾯如同⼈的⾯孔，具有吸引⽤⼾优势，设计合理的界⾯能给⽤⼾带来轻松愉悦的感受。
如果不严格按照设计图来进⾏界⾯测试，结果可能就会出现⼩岳岳版本~

界⾯测试（简称UI测试)，指按照界⾯的需求（⼀般是UI设计稿）和界⾯的设计规则，对我们软件界⾯所展⽰的全部内容进⾏测试和检查，⼀般包括如下内容：
• 验证界⾯内容显⽰的完整性，⼀致性，准确性，友好性。⽐如界⾯内容对屏幕⼤⼩的⾃适应，换⾏，内容是否全部清晰展⽰；
• 验证整个界⾯布局和排版是否合理，不同板块字体的设计，图⽚的展⽰是否符合需求；
• 对界⾯不同控件的测试，⽐如，对话框，⽂本框，滚动条，选项按钮等是否可以正常使⽤，有效和 ⽆效的状态是否设计合理；
• 界⾯的布局和⾊调符合当下时事的发展。
找茬~ 请你根据给定的设计图找出实现的⻚⾯有哪些界⾯问题~

只要跟设计图不符就可以提bug。

eg：
肉眼可见的任何元素都要进行测试；
按钮的点击，输入框输入文本，下拉框的选择，其他的交互等等。
前端开发在执行开发之前需要交互/设计人员给出的设计图。

2.2 功能测试

功能测试就是对产品的各功能进⾏验证，根据功能测试⽤例，逐项测试，检查产品是否达到⽤⼾要求的功能。
根据产品特性、操作描述和⽤⼾⽅案，测试⼀个产品的特性和可操作⾏为以确定它们满⾜设计需求。
本地化软件的功能测试，⽤于验证应⽤程序或⽹站对⽬标⽤⼾能正确⼯作。使⽤适当的平台、浏览器和测试脚本，以保证⽬标⽤⼾的体验将⾜够好，就像应⽤程序是专⻔为该市场开发的⼀样。功能测试是为了确保程序以期望的⽅式运⾏⽽按功能要求对软件进⾏的测试，通过对⼀个系统的所有的特性和功能都进⾏测试确保符合需求和规范。

如何进⾏功能测试？
设计功能测试⽤例，参考产品规格说明书进⾏⽤例的编写，具体的测试⽤例需要使⽤⿊盒设计测试⽤例的⽅法，如等价类、边界值、判定表法、正交法、场景法、错误猜测法等。

2.3 性能测试

我们在使⽤软件的时候有时会碰到软件⽹⻚打开时越来越慢，查询数据时很⻓时间才显⽰列表，软件运⾏越来越慢等问题，这些问题都是系统的性能问题引起的。
以博客系统为例，看看两种场景下哪种性能⽐较好

要进⾏软件产品的性能问题，要对产品的性能需求进⾏分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执⾏，最后要进⾏持续的性能调优。

2.4 可靠性测试

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

隔壁村有个⼈叫⽼王
让⽼王请吃饭，要求了⼗次，但是他只请了⼀次，那么我们说⽼王的可靠性是10%，那么我们称⽼王这⼈不可靠
如果让⽼王请吃饭，要求了⼗次，每次他都请客了，可靠性是100%，那么⽼王是个可靠的⼈（纯纯⼤冤种~~）

系统⾮正常运⾏的时间可能是由于硬件，软件，⽹络故障或任何其他因素（如断电）造成的，这些因素 能让系统停⽌⼯作，或者连接中断不能被访问，或者性能急剧降低导致不能使⽤软件现有的服务等。
可⽤性指标⼀般要求达到4个或5个“9”，即99.99%或者99.999%
如果可⽤性达到99.99%，对于⼀个全年不间断（7*24的⽅式）运⾏的系统，意味着全年（252600min)不能 正常⼯作的时间只有52min，不到⼀个⼩时。
如果可⽤性达到99.999%，意味着全年不能正常⼯作的时间只有5min。
不同的应⽤系统，可⽤性的要求是不⼀样的，⾮实时性的信息系统或⼀般⽹站要求都很低，99%和99.5%就可以了，但是军事系统，要求则很⾼；

2.5 安全性测试

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

安全性测试属于⾮功能性测试很重要的⼀个⽅⾯，系统常⻅的安全漏洞和威胁如下：
• 输⼊域，如输⼊恶性或者带有病毒的脚本或⻓字符串；
• 代码中的安全性问题，如SQL/XML注⼊ /xss漏洞
• 不安全的数据存储或者传递
• 数据⽂件，邮件⽂件，系统配置⽂件等⾥⾯有危害系统的信息或者数据；
• 有问题的访问控制，权限分配等
• 假冒ID：⾝份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性
eg：
登录模块密码一般要加密显示
数据库：用户敏感性信息要加密。
接口返回值：不能返回用户的隐私数据。

安全性测试的⽅法有代码评审，渗透测试，安全运维等，常⽤的静态安全测试⼯具有，Coverity，IBM Appscan Source，HPFortify，常⽤的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安全测试是常⽤的安全性测试的⽅法。
安全如此重要，咱们的私⼈电脑需要安装杀毒软件吗…（铁汁多少有点抬举⾃⼰了嗷~）

2.6 易⽤性测试

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

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

1，标准性和规范性
对于现有的软件运⾏平台，通常其UI标准已经不知不觉地被确⽴了，成为⼤家的共识。多数⽤⼾已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。⽐如安装软件的界⾯的外观，在什么场合使⽤恰当的对话框等。

所以⽤⼾界⾯上的各中信息应该符合规范和习惯，否则⽤⼾使⽤起来会不舒适，并得不到⽤⼾的认可。
测试⼈员需要把与标准规范，习惯不⼀致的问题报告为缺陷
2，直观性
⽤⼾界⾯的直观性，要求软件功能特性易懂，清晰。⽤⼾界⾯布局合理，对操作的响应在⽤⼾的预期之中。⽐如数据统计结果⽤报表的形式（条形图，扇形图等）展⽰清晰直观；现在主流的很多搜索引擎和⽇历的设计也有直观性的特点；
3，灵活性
软件可以有不同的选项以满⾜不同使⽤习惯的⽤⼾来完成相同的功能。但是灵活性的设计要把握好度，
不然可能由于太多的⽤⼾状态和⽅式的选择，增加了软件设计的复杂性，和程序实现的难度。 例如⼿机键盘有九宫格和全键盘，还⽀持⼿写，满⾜了不同⽤⼾的需求
4，舒适性

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

3. 按照执⾏⽅式分类

3.1 静态测试

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

不以测试数据的执⾏⽽是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码⻛格和规格等来检查程序的正确性。
常⻅的静态测试⽅式有代码⾛查（肉眼检查代码是否存在问题，检查的主导通常为开发领导），代码扫描⼯具（sonnar）等。

3.2 动态测试

动态测试（dynamic testing），指的是实际运⾏被测程序，输⼊相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断⼀个测试属于动态测试还是静态的，唯⼀的标准就是看是否运⾏程序。
⼤多数软件测试⼯作都属于动态测试

4. 按照测试⽅法

4.1 ⽩盒测试

⽩盒测试⼜称为结构测试或逻辑测试，它⼀般⽤来分析程序的内部结构，针对程序的逻辑结构来设计测试⽤例进⾏测试。
⽩盒测试的测试⽬的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进⾏覆盖测试；在程序不同地⽅设⽴检查点，检查程序的状态，以确定实际运⾏状态与预期状态是否⼀致。

⽩盒测试主要分为静态测试和动态测试两种。静态测试常⻅于桌⾯检查、代码审查、代码⾛查、代码扫描⼯具
动态测试⽅法主要包含六种测试⽅法**：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。**
给出简单的案例，接下来了解⼀下⽩盒测试⽅法的概念和使⽤

4.1.1 语句覆盖

每个语句⾄少执⾏⼀次。
针对A and B：A为T且B为T
针对C or D：C为T或者D为T
得出⽤例：
⽤例1：A为T，B为T，C为T，D为F
（任选择一个只要能达到每个语句至少执行一次的目的就行了）

4.1.2 判定覆盖

结论：每个判断都要覆盖到为真和为假两种情况

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 条件覆盖

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 判定条件覆盖

判定覆盖：if条件中既要满足为真的情况也要有测试为假的情况。
条件覆盖:表达式既要满足为真的情况也要满足测试为假的情况。

这结合判定覆盖和条件覆盖。
得出⽤例：
⽤例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 F
F T ∣ F T
F F ∣ F F
每⾏就可以是⼀个⽤例，⼀共四个⽤例

4.1.6 路径覆盖

判定条件定义如下：
1）if(x>0 && y>0)判定：记为P1
（2）if(z < 0)判定：记为P2
（3）x > 0：记为C1
（4）y > 0：记为C2
（5）z < 0：记为C3
测试⽤例设计：

总结：
• ⽩盒测试主要应⽤于单元测试阶段
• 先执⾏静态设计⽤例的⽅法，再执⾏动态设计测试⽤例的⽅法
• 设计⽤例⼀般使⽤路径测试，重点模块追加使⽤逻辑覆盖⽅法

4.2 ⿊盒测试

⿊盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使⽤、是否能适当的接收输⼊数据⽽输出正确的结果，满⾜规范需求。
所以，⿊盒测试⼜称之为数据驱动测试，只注重软件的功能 ⿊盒测试的优点
不需要了解程序内部的代码以及实现，不关注软件内部的实现。
从⽤⼾⻆度出发设计测试⽤例，很容易的知道⽤⼾会⽤到哪些功能，会遇到哪些问题，锻炼测试⼈员的产品思维
测试⽤例是基于软件需求开发⽂档，不容易遗漏软件需求⽂档中需要测试的功能。
⿊盒测试的缺点是不可能覆盖所有代码。
⿊盒测试⽤到的测试⽅法有，等价类，边界值，因果图，场景法，错误猜测法等

4.3 灰盒测试

灰盒测试，是介于⽩盒测试与⿊盒测试之间的⼀种测试，灰盒测试多⽤于集成测试阶段，不仅关注输出、输⼊的正确性，同时也关注程序内部的情况。
但是，灰盒测试没有⽩盒测试详细和完整，⿊盒测试是覆盖产品范围最⼴的测试，因此灰盒测试基本是不能够替代⿊盒测试，否则需要很⼤的代价，设计⾮常多的⽤例。

常⻅⾯试题：你知道的测试⽅法有哪些？哪种⽤的⽐较多？
常⻅的测试⽅法有⿊盒测试，⽩盒测试和灰盒测试。
开发⼈员主要⽤⽩盒测试和灰盒测试，测试⼈员主要⽤⽩盒测试和⿊盒测试。对于测试⼈员来说，相较于⽩盒测试，⿊盒测试⽤的更多⼀些。

5. 按照测试阶段分类

5.1 单元测试

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

人为规定的最小单元：方法，接口，功能等都可以称为单元。

到底怎么才算“最⼩单元”呢，最⼩单元实际是认为定义的，⼀个⽅法，⼀个类都可以理解为“最⼩单元”。
• 测试阶段：编码后或者编码前（TDD） 测试驱动开发（test dirven development）
• 测试对象：最⼩模块
• 测试⼈员：⽩盒测试⼯程师或开发⼯程师
• 测试依据：代码和注释+详细设计⽂档
• 测试⽅法：⽩盒测试
• 测试内容：模块接⼝测试、局部数据结构测试、路径测试、错误处理测试、边界测试
针对上⾯给出的冒泡排序，我们尝试实现⼀个简单的单元测试。

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;
}
}
}
}
public static void main(String[] args) {
// 排序⽆序数组
Test01();
// 排序有序数组
Test02();
// 排序空数组
Test03();
// 排序有重复数组数组
Test04();
}
private static void Test04() {
int[] act_array1= {1, 1, 29, 12, 12, 9, 9};
int[] expect_array1 = {1, 1, 9, 9, 12, 12, 29};
//排序⽆序数组
bubbleSort(act_array1);
boolean isSame = Arrays.equals(act_array1, expect_array1);//判断两个数组内容是不是⼀样
if(isSame == false) {
System.out.println("测试不通过");
} else {
System.out.println("测试通过");
}
}
private static void Test03() {
int[] act_array1= {};
int[] expect_array1 = {};
//排序⽆序数组
bubbleSort(act_array1);
boolean isSame = Arrays.equals(act_array1, expect_array1);//判断两个数组内容是不是⼀样
if(isSame == false) {
System.out.println("测试不通过");
} else {
System.out.println("测试通过");
}
}
private static void Test02() {
int[] act_array1= {1, 2, 3, 4, 5};
int[] expect_array1 = {1, 2, 3, 4, 5};
//排序⽆序数组
bubbleSort(act_array1);
boolean isSame = Arrays.equals(act_array1, expect_array1);//判断两个数组
内容是不是⼀样
if(isSame == false) {
System.out.println("测试不通过");
} else {
System.out.println("测试通过");
}
}
private static void Test01() {
int[] act_array1= {64, 34, 25, 12, 22, 11, 90};
int[] expect_array1 = {11, 12, 22, 25, 34, 64, 90};
//排序⽆序数组
bubbleSort(act_array1);
boolean isSame = Arrays.equals(act_array1, expect_array1);//判断两个数组内容是不是⼀样
if(isSame == false) {
System.out.println("测试不通过");
} else {
System.out.println("测试通过");
}
}
}

java中也有很多单元测试框架，如Junit，Junit提供了⾮常多注解和断⾔函数，有效提升开发单元测试
脚本的效率~

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertArrayEquals;
public class BubbleSortTest {
@Test
public void testBubbleSort() {
// 测试⽤例：正常情况下的冒泡排序
int[] arr = {5, 3, 9, 1, 7};
int[] expected = {1, 3, 5, 7, 9};
BubbleSort.bubbleSort(arr);
assertArrayEquals(expected, arr);
}
@Test
public void testBubbleSortEmptyArray() {
// 测试⽤例：空数组的冒泡排序
int[] arr = {};
int[] expected = {};
BubbleSort.bubbleSort(arr);
assertArrayEquals(expected, arr);
}
@Test
public void testBubbleSortAlreadySorted() {
// 测试⽤例：已经有序的数组，排序后应该保持不变
int[] arr = {1, 2, 3, 4, 5};
int[] expected = {1, 2, 3, 4, 5};
BubbleSort.bubbleSort(arr);
assertArrayEquals(expected, arr);
}
@Test
public void testBubbleSortWithDuplicates() {
// 测试⽤例：包含重复元素的数组
int[] arr = {4, 2, 4, 1, 3, 2};
int[] expected = {1, 2, 2, 3, 4, 4};
BubbleSort.bubbleSort(arr);
assertArrayEquals(expected, arr);
}
}

5.2 集成测试

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

• 测试阶段：⼀般单元测试之后进⾏
• 测试对象：模块间的接⼝
• 测试⼈员：⽩盒测试⼯程师或开发⼯程师
• 测试依据：单元测试的模块+概要设计⽂档
• 测试⽅法：⿊盒测试与⽩盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

5.3 系统测试

对通过集成测试的系统进⾏整体测试，验证系统功能性和⾮功能性需求的实现。
• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试⼈员：⿊盒测试⼯程师
• 测试依据：需求规格说明⽂档
• 测试⽅法：⿊盒测试
• 测试内容：功能、界⾯、可靠性、易⽤性、性能、兼容性、安全性等

5.3.1 冒烟测试

这⼀术语源⾃硬件⾏业。对⼀个硬件或硬件组件进⾏更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这⼀术语描述的是在将代码更改嵌⼊到产品的源树中之前对这些更改进⾏验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的⽅法。冒烟测试设计⽤于确认代码中的更改会按预期运⾏，且不会破坏整个版本的稳定性。

冒烟测试的对象是每⼀个新编译的需要正式测试的软件版本，⽬的是确认软件主要功能和核⼼流程正常，在正式进⾏系统测试之前执⾏。冒烟测试⼀般在开发⼈员开发完毕后提交给测试⼈员来进⾏测试时，先进⾏冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试⼈员开始进⾏正式的系统测试，如果不通过，则测试⼈员可以让开发⼈员重新修复代码直到冒烟测试通过，再开始进⾏系统测试。
在⽣活中，
购买⼀个电视，⾸先会通电，查看电视是否能够运⾏。
购买⼀个⽔杯，⾸先会灌⽔，查看⽔杯是否漏⽔。
在⼯作中，假如有⼀个博客系统项⽬提测了，冒烟测试即只需要测试系统是否能够成功打开，主流程是否可以⾛通即可。

5.3.2 回归测试

回归测试是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。
在整个软件测试过程中占有很⼤的⼯作量⽐重，软件开发的各个阶段都会进⾏多次回归测试。随着系统的庞⼤，回归测试的成本越来越⼤，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试主要由⼈⼯测试和⾃动化测试进⾏。
在实际⼯作中，回归测试需要反复进⾏，当测试者⼀次⼜⼀次地完成相同的测试时，这些回归测试将变得⾮常令⼈厌烦，⽽在⼤多数回归测试需要⼿⼯完成的时候尤其如此，因此，需要通过⾃动测试来实现重复的和⼀致的回归测试。通过测试⾃动化可以提⾼回归测试效率。为了⽀持多种回归测试策略，⾃动测试⼯具应该是通⽤的和灵活的，以便满⾜达到不同回归测试⽬标的要求。

整体回归测试一下；
自动化测试解决了回归测试的难点。

5.4 验收测试

针对⽤⼾需求，对通过系统测试的软件进⾏交付性测试，以确定系统是否满⾜验收标准，由⽤⼾或其他授权机构决定是否接受系统。验收测试是部署软件之前的最后⼀个测试操作。它是技术测试的最后⼀个阶段，也称为交付测试。验收测试的⽬的是确保软件准备就绪，按照项⽬合同、任务书、双⽅约定的验收依据⽂档，向软件购买都展⽰该软件系统满⾜原始需求。
• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）。
• 测试⼈员：主要是最终⽤⼾或者需求⽅。
• 测试依据：⽤⼾需求、验收标准
• 测试⽅法：⿊盒测试
• 测试内容：同系统测试(功能…各类⽂档等)
单元测试，集成测试，系统测试，回归测试之间的关系：
eg：
关于⻋企⽣产⻋到客⼾开上⼩汽⻋的过程中~

造⻋需要原材料，如⻋轮、发动机等零部件不是⻋企⾃⼰制造出来的，⽽是通过购买零部件来造⻋。对买来的零部件进⾏检查，零部件是否符合造⻋标准**（单元测试）**
零件确认完毕，接下来就是复杂的造⻋⼯艺，将零部件集成起来构成了⼀辆⻋，并初步检查拼⻋的⻋是否能正常运作**（集成测试）**
⼀辆⻋成型之后并不意味着就可以直接销售给客⼾了，需要⻋企专业的测试⼈员进⾏详细⽽完整的测试。（系统测试)

专业的测试⼈员对企业测试完毕，通过测试的汽⻋将会在⻋展或者4S店进⾏展⽰，供⽤⼾进⾏选择和购买。⽤⼾在选择汽⻋的过程中也会对⻋外观以及性能等⽅⾯进⾏校验**（验收测试）**
除了以上阶段外，还有两个⾮常重要，在⼯作中经常会听到：冒烟测试和回归测试

6. 按照是否⼿⼯测试

6.1 ⼿⼯测试(Manual testing)

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

6.2 ⾃动化测试(Automation Testing)

就是在预设条件下运⾏系统或应⽤程序，评估运⾏结果，预先条件应包括正常条件和异常条件。简单说 ⾃动化测试是把以⼈为驱动的测试⾏为转化为机器执⾏的⼀种过程。 ⾃动化测试⽐如功能测试⾃动化、性能测试⾃动化、安全测试⾃动化。 ⾃动化测试按照测试对象来分，还可以分为接⼝测试、UI测试等。接⼝测试的ROI（产出投⼊⽐）要⽐UI测试⾼。

6.3 ⾃动化测试和⼿⼯测试优缺点

	自动化测试	手工测试
优点	• 节省成本 • 提⾼测试⼈员执⾏⼯作效率 • 保障软件的质量	• 对测试⼈员技术要求没有⾃动化技术要求⾼（现在要求测试人员的手工能力也要很强） • 可以进⾏发散性测试
缺点	• 对测试⼈员技术要求较⾼ • 不能发散性测试	·效率低·人员，时间成本比起自动化测试都比较高

7. 按照实施组织划分

⼤型通⽤软件，在正式发布前，通常需要执⾏Alpha和Beta测试

7.1 α测试(Alpha Testing)

α测试⼜叫内测或者叫a测，其实都是⼀个涵义
α测试通常是公司内部的⽤⼾在模拟实际操作环境下进⾏的测试。α测试的⽬的是评价软件产品的FLURPS(即功能、可使⽤性、可靠性、性能和⽀持)。 α测试不能由程序员或测试员完成。

7.2 β测试(Beta Testing)

β测试⼜叫公测或者叫b测
β测试由软件的最终⽤⼾们在⼀个或多个场所进⾏，这⾥就可以理解为，β测试是正式⽤⼾中的⼀部
分，他们在任意的场合来使⽤软件，⽬的是为了发现软件是否存在⼀系列的问题
通常会发送⼀些邀请码，来邀请⽤⼾参与项⽬测试

α测试与β测试的区别

测试的场所不同	α测试是在公司内部进⾏测试的,但是β测试是在⽤⼾环境下进⾏测试的 α测试的环境是受开发⽅控制的,⽤⼾的数量相对⽐较少,时间⽐较集中 β测试的环境是不受开发⽅控制的,⽤⼾数量相对⽐较多,时间不集中
测试执⾏时机不同	通常是α测试通过后，在进⾏β测试
测试持续时间⻓短不同	α测试时间没有β测试持续时间⻓

7.3 第三⽅测试

第三⽅软件测试是指由独⽴的第三⽅公司或组织进⾏的软件测试活动
https://www.zmtests.com/

通过第三⽅测试，可以确保软件的质量，节省成本，确保软件尽快上线

8. 按照测试地域划分

按照测试地域划分，⼀般会将测试划分为国际化测试和本地测试

8.1 国际化测试

简⾔之，测试⼈员需要测试软件在不同语⾔和地区是否能正常⼯作

国际化测试需要关注软件的哪些特性：
• 布局
• 时间
• ⽇期
• 数字格式
• 货币
• 机器型号
• …

8.2 本地测试

在这之前写的测试博客都属于本地测试。

总结

以上就是软件测试之测试分类（沉淀中）的全部内容了，内容很详细，大家可以反复阅读！！！