测试篇(四)：测试用例的分类、按测试对象划分、按是否查看代码划分、你平时哪种测试方法用的多？、按照开发阶段划分

一、按测试对象划分

1.1 界面测试

界面测试简称UI测试，指按照测面的需求(一般是UI设计稿)，和界面设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

• 验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
• 验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
• 对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
• 界面的布局和色调符合当下时事的发展。

1.2 可靠性测试

可靠性即可用性，指系统正常运行的能力或程度，一般用正常用户提供软件服务的时间占用总时间的百分比表示。

可靠性=正常运行时间/(正常运行时间+非正常运行时间)*100%

系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。

可用性指标一般达到99.99%或99.999%；

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

1.3 容测性测试

容测性测试是指系统能够处理异常，用户错误的操作而不至于系统崩溃，从而能够提高系统的可用性。

容错性包含以下方面：

• 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。 比如数据级测试，校验测试，环境容错性测试，界面容错性测试
• 灾难恢复性测试。 通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

【区分容错性和可靠性】

假如一辆汽车有四个引擎，但有一天其中一个引擎坏了(不可靠性的表现)，但是汽车仍然能够正常运行和驾驶(容错性的表现)

1.4 文档测试

计算机软件开发文件编制指南中共有14种文件，分为3大类：
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。
文档测试的关注点：

• 文档的术语
• 文档的正确性
• 文档的完整性
• 文档的一致性
• 文档的易用性

1.5 兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

• 系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的
• 测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
• 测试与第三方系统以及第三方数据的兼容性

对于环境（操作系统，应用平台）兼容性的测试不仅仅局限在操作系统，浏览器这两个因素，还包括以下，32位，64位CPU；手机平台Android
，iOS，Windows Phone；支持不同的Internet连接速度。
对于iOS和Android两个平台，还要区分手机和平板电脑，考虑不同的型号（屏幕尺寸，分辨率等）

1.6 易用性测试

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

1.7 安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

• 软件不同的安装和卸载方式；
• 应用是否可以在不同的环系统，版本下安装（安装兼容性）
• 安装或者卸载过程中是否可以手动暂停，或者取消
• 安装空不足的时候系统是否有提示
• 是否可以正常的卸载，以及应用软件的各种卸载方式
• 卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

1.8 安全测试

安全性是指信息安全，计算机系统或网络保护用户数据隐私完整，保护数据正常传输和抵御黑客或病毒攻击能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下：

• 输入域，如输入恶性或者带有病毒的脚本或长字符串；
• 代码中的安全性问题，如SQL/XML注入
• 不安全的数据存储或者传递
• 数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
• 有问题的访问控制，权限分配等
• 假冒ID：身份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性

1.9 性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。
要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：

• 资源泄露
• 资源瓶颈
• 线程死锁，线程阻塞
• 查询速度慢或效率低
• 受外部系统影响越来越大

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

1.10 内存泄露测试

造成内存泄露的原因有很多，最常见的有以下几种：

• 分配完内存后忘记回收
• 程序写法有问题，造成没办法回收(死循环等)
• 某些API函数使用的不正确，造成内存泄露

内存泄露的检测方法：

• 人工静态法：人工查找代码未被回收的内存
• 自动工具法：借助相应测试内存泄露的工具，如Visual Leak Detector，记录每次的内存分配，清楚的告诉用户内存是如何泄露的

1.11 弱网测试

实施弱网测试，需要借助Fiddler，具体步骤：
（1）打开弱网测试选项

（2）打开弱网测试的脚本

对于2G/3G对应的上行和下行速率，可以直接百度

二、按是否查看代码划分

2.1 黑盒测试

黑盒测试也叫做纯功能测试，在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用，是否能适当的接收输入数据而输出正确的结果，满足规范需求。
例如，要对开发出的一款计算器程序进行测试，当输入后1+1后，我们只关心输出结果是不是2，而不关心程序的内部代码实现

【黑盒测试的优点和缺点】

黑盒测试的优点

• 不需要了解程序内部的代码以及实现，不关注软件内部的实现。
• 从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
• 测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点是不可能覆盖所有代码。

黑盒测试用到的设计方法有：等价类、边界值、因果图、场景法、错误猜测法

黑盒测试主要用在系统测试阶段

2.2 白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

白盒测试主要用在单元测试阶段

2.4 灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
但是灰盒测试没有白盒测试那么详尽，没有黑盒测试覆盖产品的广度大，所以灰盒不能代替黑白盒

灰盒测试主要使用在集成测试阶段

三、面试题：你平时哪种测试方法用的多？

【面试题：你平时哪种测试方法(黑白灰盒)用的多？】

黑盒测试和白盒测试测试人员都会使用到，在工作根据具体情况来结合白盒测试和黑盒测试。通常情况下对于测试人员来说，使用黑盒测试相对要多一些.

四、按照开发阶段划分

4.1 单元测试

单元测试是对软件组成的最小单元进行测试，目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块
测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

4.2 集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

4.3 系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

4.4 回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的，也可借助自动化来进行回归测试

自动化也是测试人员写的，自动化测试是有局限性的，只是协助测试人员进行测试的一个工具。

自动化测试不能取代人工测试

4.5 冒烟测试

开发人员完成开发之后，交给测试人员进行测试的第一步，就是冒烟测试，评估软件/系统是否具备可测试的条件
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试

4.6 验收测试

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。

测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能…各类文档等)