一. 第一部分
涉及几个面试问题
- 什么是软件测试?
- 研发于测试的区别?
- 为社么要做软件测试?
- 作为一个测试人员应该具有哪有素质
- 什么是软件测试(目的):
- 找 bug
- 验证程序的正确性
- 结合学习经验、使用软件的体会、生活经验
看设计出的程序是否满足用户的期望
- 研发与测试的区别:
- 目的:
- 研发:完成任务的开发(负责把项目做完)
- 测试:验证研发的功能的正确性(负责把任务做好)
- 方法:
- 研发:
- 工具
- 发展方向
- 研发:架构师
- 测试:测试总监
研发与测开的区别:首先区分测试与测开的区别:测开要求有代码能力
- 为社么要做软件测试(3、4问一起答)
- 你具备了哪些做测试的素质(同第四问)(自己的素质 与 自身的经历 结合来说)(细心、沟通、耐心、组织协调能力)(逆向思维、扩展思维、发展性思维)
- 结合生活经验(自己用某款 app 的体验)
二. 概念
需求:面试不会问到
bug
测试用例
软件的生命周期
模型(研发模型和测试模型)
需求
符合正式文档规定的条件和权能,包括:用户需求和软件需求(软件需求:能指导开发人员进行设计、编码人员能编写测试用例)
bug
与需求(正确的)不一致或与用户期望(合理)不一致
测试用例:
向被测程序输入的一组集合,包括:测试环境、测试数据、测试步骤、预期结果、测试版本……
软件的生命周期(研发)
需求 - 计划 - 设计 - 编码 - 测试 - 运行维护
模型:
1. 研发模型:
- 瀑布模型:
- 特点:串行
- 适合项目:需求相对稳定、有类似的产品
- 优点:每个阶段都很明确
- 缺点:发现缺陷比较晚,修复成本高;测试环节靠后,让人认为测试不重要;研发中的经验,不能及时分享到其他项目
- 螺旋模型:
- 特点:渐进式
- 适合的项目:规格庞大、复杂度高、风险高
- 强调:风险
- 优点:对人员要求高、时间成本、影响项目的进度、总体的成本高
- 缺点:优点既是缺点
- 增量、迭代(两个一起学习)
- 目的:减少项目风险
- 增量:第一次发布,第二次发布不影响第二次发布的功能
- 迭代:第一次发布,后边发布的时候对第一次的发布是有影响的,后边的发布需要变动代码
- 敏捷模型
- 传统模型 与 敏捷模型的区别:宣言、轻文档、人与人之间的沟通、客户参与、拥抱变化
- 特点:对人员有要求,6-10人;站会:15分钟;迭代周期:1~4周
- 常见的敏捷模型:scrum:有三大角色 PO(产品负责人)SM(敏捷教练)team(团队)
- 敏捷的研发流程:PO整理USER STORY —— PO开会,确定迭代次数 —— 分配任务,并自己评估时间 —— 研发中 —— 研发完成 —— 测试中 —— 测试完成 —— 待发布 —— 发布上线
- 敏捷测试:1. 对文档的依赖低(靠沟通解决、思维导图写出测试点) 2. 迭代频繁(自动化回归、适应)
2. 测试模型:
- V模型
特点:串行
以编码为分割线,左边:研发线;右边:测试线。
优点:测试、研发等各个划分的很明确
缺点:bug发现的比较晚,误认为测试不重要
测试参与工作
1、用户需求:参与很少很少,只是了解,产品经理
2、需求分析与系统:参与:了解需求的范围,并制定测试计划;
3、概要设计:不参与
4、详细设计:不参与
5、编码:编写测试用例
6、单元测试:做测试工作,但传统测试人员不参与,由白盒(代码测代码)研发工程师、开发人员工作
7、集成测试:做测试工作,但传统测试人员不参与,由白盒+黑盒(测功能)研发人员工作,但只强调单元之间的功能
8、系统测试:花费工作最多的阶段,五项工作(搭建测试环境+数据准备+测试执行+缺陷管理+测试报告的输出)
9、验收测试:测试人员是用户,给用户培训软件的使用,收集用户的反馈和建议 - W 模型
一条研发线,一条测试线
开发、测试同时进行
1、用户需求:为验收测试做准备;
2、需求分析与设计:为系统测试做准备,了解需求的范围,并制定测试计划;
3、概要设计:为集成测试做准备,根据研发人员的设计文档,细化测试计划
4、详细设计:为单元测试准备,搭建测试用例的框架
5、单元测试:编写测试用例,并对功能的代码单元进行代码测试
6、集成测试:黑+白盒测试
7、系统测试:五项工作???
8、验收测试:用户测试
三. 基础篇
- 软件测试的生命周期
- 缺陷管理:缺陷描述、级别、状态及转换
- 如何发现更多的缺陷
- 提交一个缺陷研发人员不认可怎么办
- 如何开展第一次测试(了解)
软件测试的五个生命周期
需求分析 —— 测试计划 —— 软件测试、测试开发 —— 测试执行 —— 测试评估
缺陷管理
缺陷描述要素:
类比测试用例
测试环境、测试版本、测试数据、测试步骤、预期结果、实际结果、附件、级别、类型……
级别:
崩溃(A)、严重 ( B ) 、一般 ( C ) 、次要 ( D ) 、建议 ( E )
状态:
NEW、OPEN、FIXED、DELAY、REJECTED、CLOSED、REOPEN
状态转换
红色:new - open - 缺陷 - rejected - close new - open - close 为无效缺陷
如何发现更多的缺陷
- 二八原则
- 逆向思维、扩展、发散性思维
- 不要依赖需求和测试用例
- 测试人员尽早介入
提交一个缺陷研发人员不认可怎么办
- 自查
- 站在用户角度考虑
- 缺陷级别准确
- 提高自身的业务水平和技术能力
- 寻求第三方
编写测试用例
测试用例的设计方法
- 基于需求的分析
- 等价类
- 边界值
- 因果图
- 正交排列
- 场景设计法
- 错误猜测法
1. 基于需求:
学习需求,难点:看出需求以外的测试点
2、等价类:
- 只针对于输入;输入太多;对输入进行分类
- 思想:减少测试用例,解决输入无穷的问题
- 使用场景:输入,且输入无穷
- 概念:无穷的输入分成N个类,然后从类里面提取一个数据进行测试,只要这一个数据测试通过,我们就认为它所在的这一类的数据全部测试通过
3、边界值:
- 使用场景:输入 和 输出的“ 边界值 ”
- 取值规则:开区间(向内取值)、闭区间(向外取值)
[1,50] —— 0,1,50,51
(1,50] —— 1,2,50,51
等价类这种方法的一种补充方法,成对出现
4、因果图:
使用场景:输入(原因)和输出(结果)之间的关系。输出依赖我们的输入(多个)
第一步:
第二步:
5、正交分解:
7. 错误猜测法:
猜测的三个来源:
1、测试人员对项目测试时间长
A. 功能、业务复杂度特别了解
B. 对开发人员的能力了解
2、用户反馈
3、缺陷、故障库 (两个区别在 bug 发现的时间不同)
A. 缺陷 —— 还未发布时,测试人员发现的 bug
B. 故障 —— 生产环境 / 上线环境 出现的 bug
四. 软件测试方法
按开发阶段划分
重点重点
- 单元测试 / 模块测试
- 集成测试
- 系统测试
- 验收测试
单元测试
面试回答单元测试时,仅仅回答加粗部分内容
单元测试时对软件组成单元进行测试,其目的时检验软件基本组成单位的正确性。
- 测试阶段:编码后或编码前(TDD:测试驱动开发;研发人员依据测试用例写代码)
- 测试对象:软件设计的最小模块
- 测试人员:白盒测试工程师 或 开发工程师(不同项目的开发工程师相互测试)
- 测试依据:代码和注释 + 详细设计文档(在V模型中,测试线中的单元测试对应开发线中的详细设计)
- 测试方法:白盒测试 —— 对代码测试
- 测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
- 模块接口测试:模块之间的接口(模块之间传递的参数),测试模块间传递符合要求的接口,还有测试模块间传递不符合要求的接口
- 局部数据结构测试:对数据的作用域范围进行测试
- 路径测试:if语句的每个路径都进行测试,即符合条件或者不符合条件都要进行测试,for 循环中,加入循环了10次,就得进行10次的循环测试,还有判断该循环是否是真的循环了 10 次,10次是否全部进行了覆盖(判断for循环的for语句是否正确) 黑盒测试的错误猜测法
- 错误处理测试:验证代码的健壮性,判断每次出错的话
- 边界测试:假如循环 10 次,第一次循环的结果是多少,第10次循环的结果是多少 黑盒测试的错误猜测法
集成测试
两个及以上的模块
集成测试也称联合测试(联调)、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。
- 测试目的:
- 测试阶段:单元测试之后
- 测试对象:模块间的接口
- 测试人员:白盒测试工程师 / 开发工程师
- 测试依据:单元测试后的模块 + 概要设计文档
- 测试方法:黑盒测试 + 白盒测试
- 测试内容:模块之间的数据传输、 模块之间功能冲突、模块组中功能正确性、全局数据结构、单模块缺陷对系统的影响
- 模块之间的数据传输:两个模块之间的数据传输
- 模块之间的功能冲突:多个模块可能对一个功能都有处理,检查两个模块间对功能的处理是否一致
- 模块组装功能正确性:模块组装之后的功能的正确性
- 全局数据结构:
- 单模块缺陷对系统的影响:
系统测试
将软件系统看成是一个系统的测试。包括功能、性能以及软件所运行的软硬间环境进行测试。时间大部分在系统测试执行阶段,包括回归测试 和 冒烟测试
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明文档
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
先 冒烟测试 —— 再 系统测试 —— 后 回归测试
- 冒烟测试:
- 概念来源于硬件,在软件中,冒烟测试是对核心主干流程进行测试,
- 作用:通过冒烟测试,判断测试人员是否接收本次测试
- 回归测试:
- 回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
- 范围:跟测试的阶段相关(只回归bug或者跟本bug相关的一些功能点,在最后的测试阶段不仅要回归bug跟功能点还要回归整个系统 —— 在组后部分可以用脚本进行自动化测试)
验收测试:
测试方法、测试对象跟测试内容跟系统测试完全一致
- 测试阶段:系统测试通过之后
- 测试对象:整个系统(包括软硬件)
- 测试人员:主要是最终用户 或 需求方
- 测试依据:用户需求、验收标准
- 测试方法:黑盒测试
- 测试内容:同系统测试一样
按测试实施组织
不要求必须记忆
- Alpha
- Beta
- 第三方
a(Alpha) 和 b(Beta)区别:
- 测试人员不一样:
- a:公司内部(除本项目的研发人员和测试人员)的人员
- b:用户
- 环境不同:
- a:研发环境 或 预发布环境
测试环境 —— 预发布环境(与生产环境基本一致) —— 生产环境 - b:用户环境
- a:研发环境 或 预发布环境
- 先后顺序
- a 在 b 之前
- 时间长短
- a 时间短
- b 时间长
第三方:
- 软件评测机构
按是否运行划分
静态测试
静态测试是指不运行被测试程序,仅通过分析
测 文档 + 代码
测试内容:语法、此法、业务逻辑、正确性、完整性、一致性可读性
软件测试分为哪些?
答:软件测试按照不同的维度,有不同的划分。按照研发阶段划分,有单元测试、集成测试、系统测试、验收测试…………………………
动态测试
测代码,主要
按是否手工划分
手工测试
- 优点:可进行探索性测试,测试是主动的,自由测试
- 缺点:执行效率慢,量大易错。
自动化测试
- 把手工测试的步骤写成代码,让机器自动测试的工程。在回归测试中,若是要回归整个系统,则可以用自动化测试。
- 自动化测试包括 功能自动化、性能测试自动化、安全测试自动化
- 优点:提高效率、不容易出错
- 缺点:没有人的思想,不能进行探索性测试
手工测试和自动化测试是互补的,不存在谁能取代谁的言论
按是否查看代码划分
重点重点
黑盒测试
- 课件:黑盒测试也称功能测试。测试中把被测的软件对象当作一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据与输出数据
- 老师:黑盒测试就是功能测试,对软件进行一系统操作之后,看软件最后的结果是否与自己期望的是否一致。
- 自己:黑盒测试就是功能测试,不看软件的代码,只在对软件进行一系列操作之后,看软件是否能够得到自己期望的结果。例如,在淘宝购物的时候,测试点击付款是否能进入付款界面
白盒测试
- 老师:白盒测试就是对代码进行测试,测试代码里边的接口、数据结构、错误处理、路径覆盖、边界、业务逻辑等等。
- 接口测试也是白盒测试的一种,但是白盒测试不是接口测试。
灰盒测试
是介于白盒测试与黑盒测试之间的一种测试,既关注代码内部的处理又关注软件的功能,灰盒测试多用于集成测试阶段。
集成测试 —— 白盒测试 + 黑盒测试
按测试地域划分
本地化测试(中国)
国际化测试(非中国)
按测试对象划分
重点重点
- 功能测试
- 业务测试
- 界面测试
- 容错性测试
- 文档测试
- 兼容性测试
- 易用性测试
- 安装测试
- 安全测试
- 性能测试
- 内存泄漏测试
主要用于系统测试 和 验收测试
功能测试
业务测试
场景测试用例
测试所有不同的业务流程(不仅仅是主干流程),前提条件是对项目的需求特别了解
界面测试
测试软件的界面颜色、布局、按钮等是否能够满足大部分用户的体验、审美。
容错性测试
-
输入不符合规则的数据,看系统如何处理:与无效等价类有关但不全是,刻意地输入异常数据,看系统如何处理。
-
灾难恢复性测试:(例如服务器挂了,自动启动备灾服务器)自动启动、人工干预(数据库内容出错,必须人工手动修改数据库内容)不让用户感知系统发生崩溃
文档测试
在按是否运行划分中的静态测试中,也有文档测试
开发文件公有14种文件,可分为 3 大类:开发文件、用户文件、管理文件
文档测试的关注点:
- 文档的术语
- 文档的正确性
- 文档的完整性
- 文档的一致性(关于某一功能,文档前后不一致)
- 文档的易用性
兼容性测试
- 平台测试
- 浏览器测试
- 软件本身能否向前 或 向后兼容(软件更新后,它之前的功能还能否正常使用)
- 测试软件能否与其他相关的软件兼容
- 数据兼容性测试(例如:输入框输入的数据)
易用性测试
符合大部分用户的使用习惯即可。
安装测试
安装完成后是否会生成快捷方式
安装完成的文件大小、个数是否完整
注册表
安全测试
性能测试
分为 9 大类,后边具体学习
- 资源利用率(内存、处理机周期)
- 响应时间
- 日志时间(如中断、报错)
- 吞吐量(TPS,处理订单数量)
- 辅助存储区(例如缓冲区、工作区的大小等)
- 处理精度
内存泄漏测试
内存管理、使用不合理,具体常见引起内存泄漏的有以下几点:
-
分配完内存之后忘了回收
-
程序写法有问题,造成没办法回收
-
某些 API 函数的使用不正确,造成内存泄漏
-
没有及时释放
-
软件测试的流程:
一般包含五个流程,第一步需求分析,根据需求分析得出的需求,进行第二步测试计划,第三步根据测试计划点,编写测试用例,进行评审,对评审通过后的测试用例进行测试,最后在时间允许的情况下还可以交换测试,生成测试报告 -
编写测试用例思路
- 对正确概念进行验证
- 对容错性(错误推测法 和 等价类中的无效等价类)测试和异常测试(数据库、服务器、网络、特例、异常场景)(面试写测试用例得分点)
- 功能测试之外的测试类型,性能、安全、界面、易用、移植