软件测试分类篇

按照测试对象划分

1.1 界面

用户是通过界面和软件进行交互的，界面设计的好坏直接决定了用户对软件的印象【界面测试==UI测试】

1. 测试软件界面的完整性，正确性，一致性【UI设计稿】
2. 软件界面排版布局合理，字体和颜色
3. 测试界面的自适应性，界面自适应不同的页面大小（文字没有重叠消失，功能都在，可以正常使用，图片清晰排版合理）
4. 对面空间功能正常，滚动条，按钮的有效状态和失效状态可以区分【有效高亮、失效置灰不能点亮】
5. 界面设计（颜色，布局）考虑当下的事

界面常见的错误

1. 快捷键的不合理，重复
2. 文字的丢失，截断，未对齐，重叠，自动换行

1.2 可靠性

概念： 软件正常运行的能力，软件正常运行的时间占总体运行时间的百分比
可靠性 = 正常运行时间/(非正常运行时间+正常运行时间)
影响软件可靠性的因素：网络，软件环境（安装），硬件环境，软件自身

即使软件本身正常但是运行环境的异常都会使得软件运行异常，因此也计入非正常运行时间

如何测试可靠性？

计算软件一周或者一天内的运行时间

1.3 容错性

概念： 系统发生一个异常或者由于一个错误的操作导致软件系统内部的发生错误，软件能够自我消化掉，或者进行修改，不让客户感知到

常见的容错性

1. 数据容错性：取款机输入小于 100 的金额的温馨提示；25时61分；年月日中2月30天
2. 校验容错性：前后空格（自动化过滤）；检验大小写字母（验证码自动转换大小写）；同一个表哥或者文件前后信息交验（身份证，学号，自动前后交验）
3. 界面容错性：复杂操作的警告提示；危险操作的警告提示；危险按钮的屏蔽
4. 环境容错性：软件所在的环境发生故障，软件有备用方案，可以让用户无感知的切换【电，网络，硬件环境，软件部署的软件环境】
5. 灾难恢复性测试：人为让系统发生故障，看系统自身对于用户数据的存储和恢复是否快速

1.4 文档测试

软件开发相关文档的测试

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

1.5 兼容性测试

1. 软件自身的兼容性：软件前后的兼容性。新功能不影响之前的旧功能的使用，不能够影响后续功能的开发
2. 软件对于数据的兼容性（用户数据）：设计功能的时候要考虑用户已有的数据
3. 软件对应用平台的兼容性：安装的软件环境，硬件环境，APP，浏览器。【APP在IOS和Android；Web不同的浏览器，浏览器在不同的设备商】
4. 软件对于第三方软件或者第三方软件数据的兼容性（相关软件）【淘宝，支付宝，第三方登录】

1.6 易用性测试

1. 用户体验测试
2. 符合标准和规范【安装软件的界面标识】
3. 直观性：用户期望的操作在可见范围之内
4. 灵活性：键盘（九宫格，全键盘，手写，拼音）
5. 舒适性
6. 实用性

1.7 安装卸载

1. 考虑不同的安装卸载途径，安装卸载软件正常
2. 安装和卸载过程中是否可以暂停，暂停之后是否可以寄继续正常安装和卸载
3. 安装过程中空间不足有提示
4. 正常卸载软件，如果取消了，那么软件可以正常使用（数据恢复）
5. 安装卸载过程中出现异常，软件可以正常处理（断电，断网，连接异常等）

1.8 安全性

1. 信息安全：软件保护用数据安全，隐私以及数据传输过程中的安全性，防止病毒和黑客入侵攻击
2. 输入域能够检测带病毒的字符串或者文件
3. 防止SQL注入，XSS注入，输入注入
4. 权限分配要合理
5. 传输文件/数据要防止拦截
6. 防止爬虫，怕去信息
7. 防止黑客攻击

安全性检测：代码走读，工具检测

1.9 性能

性能问题的表现： 资源泄漏，资源分配不均衡，线程死锁，查询速度越来越慢，响应越来越慢
性能指标： TPS（Transaction Per Second：每秒事务处理量），每秒HTTP请求次数，点击率，吞吐量，响应时间，CPU和资源的利用率

1.10 内存泄漏

内存泄漏产生的原因： 程序中写的有问题，API函数使用不正确，分配内存后忘记回收

检查代码资源是否泄漏：人工检查，工具检查

1.11 弱网测试

1. Fiddler打开弱网设置
   
2. 打开设置弱网的脚本
   

上图中的数据代表的是：上行延时0.3s、下行延时0.15s

3. 如何设置2G、3G、4G、5G网络速率
   
   通信行业：1B[Byte]=8b[bit]

• 2G
  • 上行：2.7K
  • 下行：9.6K
  • 上行：$[1÷(2.7÷8)]\times 1000\approx 2962ms$
  • 下行：$[1÷(9.6÷8)]\times 1000\approx 833ms$

然后以此推算即可

按照是否检查代码划分

2.1 黑盒测试

概念： 不用考虑代码的内部结构，不去查看代码，只考虑输入输出（相当于把软件的内部屏蔽掉）【不用关心软件内部实现，站在用户角度设计测试用例，比较容易培养产品思维，软件测试用例是根据需求设计的，不容易遗漏需求】

黑盒测试方法

1. 等价类
2. 边界值
3. 场景法
4. 正交排列
5. 因果
6. 错误猜测

2.2 白盒测试

概念： 去分析代码的逻辑结构，查看代码是否规范，代码的风格是否和公司设计的一致，对代码进行测试看是否实现了需求【单元测试 --> 白盒测试】

白盒测试方法

1. 语句覆盖：代码的执行
2. 路径覆盖：if的代码判断
3. 逻辑覆盖
4. 判定覆盖
5. 条件覆盖
6. 判定组合覆盖
7. 判定和条件覆盖
8. 条件和条件组合覆盖

2.3 灰盒测试

介于黑白盒之间的测试。
为何不能用会和测试取代黑白盒测试？
灰盒测试既没有白盒测试那么详尽又没有黑盒测试覆盖产品的广度大，所以不能替代
哪种测试方法用的多？
黑盒测试和白盒测试都会使用到，在工作中根据具体情况来结合测试方法，通常情况下对于测试人来说使用黑盒测试相对要多一些

3. 按开发阶段划分

3.1 冒烟测试

概念： 在我们的软件开发完成时候，要对软件的基础功能和核心流程进行测试的第一步；如果测试不通过，测试人员有权利打回让开发人员重新修改，直到冒烟成功【准入原则】

3.2 单元测试阶段

概念： 指的是对软件最小组成单元进行测试，查看测试单元的功能是否正常

1. 测试前【TDD：Test Driver Development】，测试后
2. 测试方法：白盒测试
3. 测试人员：白盒测试工程师，开发人员
4. 测试依据：详细设计文档
5. 测试内容：接口测试，局部数据结构测试，局部变量测试，路径测试，边界测试（for，while），循环测试，错误处理测试（try…catch…finally）

3.3 集成测试

概念： 按照一定的逻辑和策略把单元模块组合在一起形成一个具有完整功能的大模块

1. 测试阶段：单元测试
2. 测试方法：灰盒测试
3. 测试人员：黑盒测试工程师，白盒测试工程师
4. 测试依据：概要设计文档
5. 测试内容：模块功能正确性，组成模块单元之间的接口测试，全局数据结构测试，单个模块的功能缺陷对整个模块的影响

3.4 系统测试

概念： 对系统进行全面的功能和非公能测试

1. 测试阶段：集成测试之后
2. 测试对象：整个软件系统
3. 测试方法：黑盒测试
4. 测试人员：黑盒测试工程师
5. 测试依据：需求设计文档
6. 测试内容：系统的功能，界面，可靠性，容错性，易用性，兼容性，安全性，性能，安装卸载

3.5 回归测试

概念： 当系统引入新的代码时候，测试人员往往需要验证新的代码对旧功能的影响

3.6 验收测试

概念： 软件在上线前最后的一次测试，也称之为交付测试

1. 测试阶段：系统测试之后
2. 测试对象：整个系统
3. 测试方法：黑盒测试
4. 测试人员：用户
5. 测试依据：用户需求
6. 测试内容：同系统测试（文档测试），可用性分析文档，需求设计文档，软件设计文档，软件开发文档，功能手册，用户手册

按照实施组织划分

3.1 α测试

概念： 在ß测试之前，把用户或者非测试和开发人员请到现场进行的测试

1. 测试环境：开发现场
2. 测试人员：用户或者非开发和测试人员

3.2 ß测试

概念： 让实际用户在实际环境中进行测试，测试完成后对问题统一汇总反馈【相当于app的内测用户】

α和ß测试区别

测试环境不同，测试时间集中程度不同
α优先于ß测试

3.3 第三方测试

第三方测评机构，按照软件行业的标准规范对软件进行测试【国外较多，国内较少】

按照是否运行代码划分

4.1 静态测试

概念： 不运行代码，通过检查代码风格，格式是否符合公司的标准规范，检查代码的逻辑结构是否满足需求要实现的功能

4.2 动态测试

概念： 运行代码，给程序相应的输入看是否得到希望的输出

按是否手工划分

5.1 手工测试

概念： 按照测试用例，手工测试系统的功能

• 优点：进行探索性测试，比较灵活
• 缺点：两大容易出错；效率低；有些极端情况无法测试到【但无法被自动化测试替代】

5.2 自动测试

概念： 机器按照人为设定好的程序去执行，这些预测包括正常的异常，去检查软件系统有没有符合设定的条件

自动化测试把手工测试转化为脚本执行

按照地域划分

6.1 国际测试

软件国际化概念： 进行软件开发和测试的时候，使用一种工程技术，使得软件在转化为不同国家语言的时候不用修改代码得到适应不同国家的效果

1. 外观界面不缺失，正常使用。是否适应这个国家的使用习惯，风俗习惯，日期，文字，度量单位，货币
2. 不同分辨率下，软件的正常使用和展示
3. 不同的硬件设备

6.2 本地测试

概念： 具体到某一个国家