目录
- 按照测试对象划分
- 界面测试 *
- 可靠性测试
- 如何进行可靠性测试
- 容错性测试
- 文档测试
- 兼容性测试 *
- 易用性测试 *
- 安装卸载测试 *
- 安全测试
- 性能测试
- 内存泄漏测试
- 按照是否查看代码划分
- 黑盒测试
- 白盒测试
- 灰盒测试
- 按照开发阶段划分
- 测试金字塔
- 单元测试
- 集成测试
- 系统测试
- 回归测试
- 冒烟测试
- 验收测试
- 按照测试实施组织划分
- α测试
- β测试
- α测试 和 β测试的区别
- 第三方测试
- 按是否运行划分
- 静态测试
- 动态测试
- 按是否手工划分
- 手工测试
- 自动化测试
- 手工测试 vs 自动化测试
- 按测试地域划分
- 国际化测试
- 本地化测试
按照测试对象划分
界面测试 *
用户肉眼直观的看到的都属于界面
- web站(通过浏览器打开的网站)
- APP
- 小程序
- 公众号
- …
界面的重要性:
用户和软件进行交互的时候,通常都是通过界面和软件进行沟通的
业界测试界面的时候,参考软件规格说明书,UI视觉稿
界面测试:
- 验证界面内容显示的完整性、一致性、准确性、友好性。比如界面内容对屏幕大小的自适应,换行,内容是否全部清晰展示。
- 验证界面的布局和排版是否合理
- 对界面的控件测试。比如对话框、文本框、滚动条、选项等。
- 界面的布局和色调是否符合当下实时
可靠性测试
可靠性即可用性,系统正常运行的能力。
一般指正常向用户提供软件服务发时间占总时间的百分比表示
可靠性=正常运行时间 / (正常运行时间 + 非正常运行时间)* 100%
系统非正常运行的时间,可能是由于硬件,软件,网络故障,任何其他因素(断电等)造成的,这些因素会让系统停止工作,或者连接中断不能被访问,或者性能急剧降低导致不能使用软件的现有服务。
如何进行可靠性测试
人为无法测试,借助工具
后续补充
容错性测试
容错性测试是指系统能够处理异常,用户的错误操作不至于导致系统崩溃,从而提高系统的可用性。
容错性测试包含:
- 输入异常数据或进行异常操作,以检测系统的保护性。
如果容错性较好,系统只给出提示或者内部消化掉异常,而不会导致系统出错甚至崩溃
比如:数据级测试,校验测试,环境容错性测试、界面容错性测试。 - 灾难恢复性测试
通过各种手段让软件强制发生故障,然后验证系统已保存的用户数据是否丢失,系统和数据能否尽快恢复
文档测试
- 开发文件
- 用户文件
- 管理文件
兼容性测试 *
明确测试的兼容环境,考虑软件和硬件的兼容
软件兼容主要考虑的几个方面:
- 系统自身版本的兼容,用户已有数据的兼容
- 测试与应用环境的兼容性。操作系统、应用平台、浏览器
- 测试与第三方系统以及第三方数据的兼容性
易用性测试 *
- 标准性和规范性
- 直观性
- 灵活性
- 舒适性
安装卸载测试 *
- 软件不同的安装和卸载方式
- 应用市场
- 浏览器
- 下载apk包
- 脚本/命令 下载/卸载
- 是否可以在不同的环境系统,版本下安装(安装兼容性)
- 安装或者卸载的过程中是否可以手动暂停/取消
- 安装空间不足系统是否会提示
- 是否可以正常的卸载,应用程序的各种卸载方式
- 卸载和安装时如果出现环境问题软件如何应对,比如死机,断电,断网
安全测试
性能测试
常见的性能测试:
- 资源泄漏
- 资源瓶颈
- 线程死锁,线程阻塞
- 查询速度慢或效率低
- 受外部系统影响越来越大
衡量一个系统性能好坏的关键性指标:用户响应时间、事务平均响应时间(TPS)、吞吐率、每秒点击次数、内存和CPU使用率等。
内存泄漏测试
按照是否查看代码划分
黑盒测试
黑盒测试是在完全不考虑程序逻辑和内部结构的情况下,检查系统功能是否按照需求规格说明书的规定正常使用、是否能够接收输入数据(黑盒测试用例设计方法),输出正确结果,满足规范需求。
优点:
- 不需要了解程序内部的代码以及实现,不关注软件内部的实现。对于测试人员代码的要求不高
- 从用户角度出发设计测试用例,锻炼测试人员的产品思维。
- 测试用例时基于软件需求开发文档,不容易一楼软件需求文档中需要测试的功能
缺点:
不可能覆盖所有的代码,代码覆盖率比较低
黑盒测试用到的测试方法:等价类、边界值、因果图、场景法、错误猜测法。
白盒测试
白盒测试又称为结构测试或逻辑测试。
用来分析程序的内部结构,针对程序的逻辑结构来设计测试用例进行测试。
白盒测试关注的是代码逻辑,对业务功能就有了一定的忽视
主要包含的6种测试方法:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
白盒测试
优点:代码覆盖率较高
缺点:业务功能覆盖率较低
灰盒测试
介于白盒测试和黑盒测试之间的一种测试。
灰盒测试多用于集成测试阶段,不仅关注输入输出的正确性,也关注程序内部的情况。
按照开发阶段划分
测试金字塔
单元测试
单元测试是对软件组成单元进行测试。目的是检测软件的基本组成单元的正确性。
测试的对象是软件设计的最小单位:模块。
单元测试又称为集成测试
- 测试阶段:编码后或者编码前(TDD)
- 测试对象:最小模块。在Java中是一个类方法,C语言中是函数。
- 测试人员:白盒测试工程师 或者 开发工程师
- 测试依据:代码、注释、详细设计文档
- 测试方法:白盒测试
- 测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。
Java进行单元测试:junit…
集成测试
集成测试的主要目的是检查软件单位之间的接口是否正确
- 测试阶段:一般在单元测试之后进行
- 测试对象**:模块间的接口**
- 测试人员:白盒测试工程师 或 开发工程师
- 测试依据:单元测试的模块、概要设计文档
- 测试方法:黑盒测试与白盒测试相结合
- 测试内容:模块之间的数据传输、模块之间的功能冲突、模块组装功能正确性,全局数据结构,单模块缺陷对系统的影响。
系统测试
**将软件系统看成是一个系统的测试。**包括对功能,性能以及软件所运行环境的软硬件进行测试
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软件、硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明书
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件的主要功能和核心流程正常,在正式进行系统测试之前执行。
冒烟测试的执行流程:
- 产品需求的讲解
- 梳理测试点(设计测试用例)
- 包含冒烟测试用例(测试点属于本次测试的主流程)
- 评审测试用例
- 确定了所有的测试用例(包含了冒烟测试)
- 测试
- 先执行冒烟测试用例,如果测试通过,此时进入正式测试;如果测试不通过,此时测试停止,让开发人员重新修复代码,直到冒烟测试通过。
- 项目上线
验收测试
验收测试是部署软件之前的最后一个测试操作,是产品上线之前最后一个测试流程,也称为交付测试。
目的是确保软件准备就绪。
- 测试阶段:在系统测试通过之后
- 测试对象:整个系统
- 测试人员:最终用户或需求方
- 测试依据:用户需求、验收标准
- 测试方法:黑盒测试
- 测试内容:同系统测试
按照测试实施组织划分
α测试
β测试
α测试 和 β测试的区别
- 环境
- α测试:在公司内部进行测试
- β测试:测试环境不确定
- 测试人员类型
- α测试:公司内部人员
- β测试:用户
- 测试人员数量
- α测试:数量较少
- β测试:数量较多
- 阶段
- α测试 是在 β测试 之前测试的
- 测试时间
- α测试:周期较短
- β测试:周期较长
第三方测试
介于开发方和用户方之间的组织的测试
按是否运行划分
静态测试
不实际运行被测软件,只是静态的检查程序代码、界面或文档中可能存在的错误的过程
动态测试
实际运行被测程序、输入相应的测试数据、检查实际输出结果和预期结果是否相符发过程。
大多数软件测试都属于动态测试
按是否手工划分
手工测试
人为的一个一个输入用例
自动化测试
自动化测试按照测试对象可以分为:
- 接口测试:产出投入比高
- UI测试
手工测试 vs 自动化测试
自动化测试不能不能完全代替手工测试,可以代替操作重复性比较高的测试操作。