一、按照是否手工执行划分
1. 手工测试
- 概念:对于“手工”测试,就是人工进行输入测试用例,通过观察结果,进行实现测试的步骤;与机器测试相比,方法比较原始,但却也是必须要进行的步骤之一
- 测试人员:由专门的测试人员站在用户的角度分析判断软件是否达到设计的要求
- 测试范围:适合针对深度的测试和强调主观判断的测试
- 优点:比较灵活,很好地可以进行发散性测试,永远无法被替代
- 缺点:量大容易出错,执行效率低
2. 自动化测试
-
概念:根据预设的条件去执行软件,手动测试结果,预设的条件设置有正常条件和异常条件。本质是,将人为需要测试的内容,让机器执行一遍的过程
-
测试人员:在设计测试用例并通过评审之后,由测试人员根据用例的描述步骤进行遍历测试,再将得到的实际结果与预期结果进行比较
-
断言: 为了表示与验证软件开发者预期的结果——当程序执行到断言的位置时,对应的断言应该为真。若断言不为真时,程序会中止执行,并给出错误信息
-
测试分类
功能测试自动化(一般情况所指):Unified Functional Testing (UFT)、IBM RFT
性能测试自动化:loaderrunner
安全测试自动化:Firefox Tamper Data、Zed Attack Proxy
UI 界面自动化:selenium,unit test,ddt,HTMLRequestRepport
接口测试自动化:jmeter、postman -
测试前提:项目的功能要相对稳定,脚本可以重复使用
-
测试价值:脚本的重复使用率(利用率)越高,自动化越有价值
-
优点
a. 基于回放的高校自动化回归测试,提高测试效率
b. 将测试人员从重复性高的工作中解放出来(节省人力资源)
c. 保证每次测试的一致性和可重复性
d. 克服手工测试的局限性 -
缺点
a. 机器不具备发散思维,必须实现准备手工 case 的执行
b. 维护成本较高(尤其对于 UI 和业务需求不稳定的项目)
c. 受开发技术、业务、成本、工具框架的限制
二、按照测试对象划分
1. 性能测试
检验系统是否满足需求规格说明书中的性能要求,通常表现为:
- 资源泄露
- 执行间隔
- 资源瓶颈
- 线程阻塞
- 数据库查询慢、效率低
- 吞吐量TPS 每秒事务处理量
- 响应时间 点击率
- 资源利用率(CPU 宽带 硬盘等)
2. 安全测试
- 数据泄露,黑客攻击(模仿攻击手段),SQL 注入,XSS注入,病毒乳清等方面
- 登录、注册等操作密码安全
- 下载、上传等操作
3. 兼容性测试
-
应用平台测试
IOS 不同版本的苹果手机,不同的IOS系统 Android 不同版本的 Android 系统,在不同品牌的手机上进行测试 不同的网络运用商(电信、移动、联通)WiFi 移动网络 Windows系统 塞班系统 软件向前向后的兼容性 软件和其他相关软件的兼容性 数据的兼容性
-
PC 端
不同位:64位,32位 不同系统的不同版本(Windows,Mac,Unix,Ubuntu)
-
web 系统
浏览器的兼容性,不同浏览器的不同版本
-
软件本身能否向前或向后
-
软件能否与其他相关软件兼容
4. 文档测试
- 完整性:系统功能和文档相对应
- 术语要专业,不可以说白话
- 准确性:功能文档需要把功能描述准确,不可产生二义性
- 一致性:文档上有的系统上也应该实现
- 易用性:应该让所有第三方看清楚理解
- 用户文档的作用
a. 改善安装性
b. 改善软件的易学性与易用性
c. 改善软件可靠性
d. 降低技术支持成本
5. 易用性测试(用户体验测试)
-
遵循标准(行业标准)
弹框信息提示、警告信息提示、严重信息提示
-
直观性 —— 更直观,一目了然
-
灵活性(可能引发复杂性)
-
舒适性 —— 长传、下载、压缩、进度条等)
-
实用性 —— 微信朋友圈的评论,可以发收藏的表情
6. 业务测试
-
业务是把不同孤立的功能点串联起来形成一个整体的场景
-
业务测试关注需求和用户
-
使用场景法进行业务测试
-
作为一个刚入职的新人,如何快速了解你负责的系统的业务?
了解系统文档(需求文档,系统设计文档); 询问开发人员
采购系统,向供应商采购产品,供应商发货后,需要给供应商打款。 打款逻辑,收到货物后延迟15天打款 问:公司仓库9.20收到货物,但是15天后供应商没有收到货款,问原因? 答:15天后,是10.5,国庆节,无人上班
7. 界面测试
1.一个系统,先由 UI 设计师画图完成,测试人员根据 UI 设计稿完成布局
2. 要保证完整性、准确性、一致性、易用性
3. 布局/排版:字体、图像、间距
4. 控件:对话框、文本框、按钮、滚动条、CheckBox
5. 不同页面大小的自适应测试:
- 页面由大变小,文字与突破是否消失重叠
- 页面由大变小,功能是否消失
- 页面由大变小,功能是否可以正常使用
- 页面由大变小,过程衔接是否丝滑、顺畅
8. 容错性测试
- 当系统由于外界异常环境或者人为错误操作引起系统的错误,系统可以自我消化掉,而不把这些错误或者异常直接展示给用户
- 数据级别:比如以小时为单位的 —— Linux时间戳
- 校验级别:验证码,前后信息的一致性,同一个系统
- 输入异常数据或进行异常操作,以检验系统的保护性。(如果系统容错性好,系统只给出提示或内部消化掉,而不会导致系统出错甚至崩溃。)
- 灾难恢复性测试。通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复。
- 失效恢复性测试
9. 安装测试
程序的安装、卸载
参考:软件测试之黑盒测试方法介绍及测试用例练习
10. 内存泄漏测试
-
引起原因:
分配完内存之后忘了回收
分配到内存没有释放;
使用API函数的时候不正确;
代码写得有问题,导致最终无法释放内存 -
静态代码测试:代码评审;工具测试
三、按照测试地域划分
1. 本地化测试
- 概念:将一个软件产品按特定国家/地区或语言市场的需要进行加工,使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。
- 测试方面:
- 功能性测试,所有基本功能、安装、升级等测试;
- 翻译测试,包括语言完整性、术语准确性等的检查;
- 可用性测试,包括用户界面、度量衡和时区等;
- 兼容性调试,包括硬件兼容性、版本兼容性等测试;
- 当地文化、宗教、喜好、习俗等适用性测试
- 手册验证,包括联机文件、在线帮助、PDF文件等测试
2. 国际化测试
- 概念:开发软件的时候使用的一种工程技术,使得软件可以适用不同国家的语言、文化和风俗习惯,可以不用修改源码,这种工程技术叫做软件国际化。
- 测试方面
- 在不同的屏幕分辨率下界面是否正常显示
- 日期、数字格式、货币等是否能适应不同国家的习作风俗
- 在不同国家的度量单位,软件是否能够自适应和转换
- 排序的方式是否考虑了不同语言的特点。例如:中文按照第一个字的汉语拼音顺序排序
- 软件是否能在不同类型的硬件上正常运行,特别时在当前市场上比较流行的
软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。
它要求测试人员具备一定的翻译能力、语言文化,同时具备测试人员的基本技能。
四、测试金字塔模型
1. 概述
- 从下到上三层测试,投入相同的时间、人力资源等,回报率(产出)越来越低
- 从下到上三层测试,测试的效率越来越低
- 从下到上三层测试,定位问题越来越难
2. 上层 —— UI 界面层(UI)
- 用于集成测试:从用户的角度验证产品功能的正确性,测的是端到端的流程,并且加入用户场景和数据,验证整个业务流。集成测试的业务价值最高,它验证的是一个完整的流程,但因为需要验证完整流程,在环境部署、准备用例及实施等方面成本较高,实施起来并不容易。
- 功能验证测试、兼容性与用户测试
3. 中层 —— 业务逻辑层(Service)
- 用于接口测试:针对业务接口进行的测试,主要测试内部接口功能实现是否完整。如主要业务流是否能走通,异常处理是否正确,数据为空时校验等等。
- 接口测试的主要价值在于接口定义相对稳定,不像界面或底层代码会经常发生变化,所以接口测试比较容易编写,用例的维护成本也相对较低。在接口层面准备测试的性价比相对较高。
- 客户端模拟测试、内外接口测试
- SDK 接口测试 —— 软件工程师特定的软件包建立的开发工具集合
4. 下层 —— 数据处理层(Unit)
- 用于单元测试:针对代码单元(通常是类/方法)的测试,单元测试的价值在于能提供最快的反馈,在开发过程中就可以对逻辑单元进行验证。
- 建议尽量要求开发做单元测试,并作为考核项之一。单元测试阶段发现问题到修改问题,成本较低。
- 尽量提早介入测试,发现问题,并对重点功能模块摸底测试。
越往上,越接近QA、业务和最终用户,发现问题后解决问题的成本会越高。
5. 分层的优势
-
尽量测试前移,在开发前期发现问题解决问题,开发成本会迅速下降。
-
不同时间段关注不同,分重点测试,层层防护。
-
容易定位问题,测的哪一层,出现问题,就是哪一层的问题,很明确;
-
分层测试在用例设计和执行测试的时候,更具有针对性,思维更加清晰,不容易遗漏
-
加强测试对代码实现的理解;可以更好的进行测试技能拓展