基础知识
1、软件测试
为了发现错误而执行的程序过程。具体:根据软件开发各阶段的规格说明和内部结构设计测试用例,并使用测试用例去运行程序,发现错误。
2、软件测试目的
- 少花钱
- 发现软件潜在问题
- 提高软件质量
- 回避潜在风险
3、需求文档测试
- 测试需求是否存在逻辑矛盾
- 需求在技术上能否实现
4、设计文档测试
- 设计是否全部符合要求
- 设计是否合理
5、α测试
- 实际用户来测试,现场立即反馈给开发人员
- 开发环境下(公司内部)
- 不能由程序员或测试员完成
- 着重于产品功能、可使用性、可靠性、性能等
6、β测试
- 实际用户来测试,记录问题,定期向开发者报告
- 实际环境下
- 不能由程序员或测试员完成
- 着重于产品支持性
- 在α测试达到一定的可靠度后才进行
7、驱动模块和桩模块
驱动模块:又称主程序,它接收测试数据并将数据传递到被测模块。
桩模块:集成测试前要为被测模块编制一些模拟下级功能的“替身”模块,代替被测模块的接口,接受或传递被测模块的数据。
8、白盒测试与黑盒
1)白盒:又称逻辑驱动测试,结构测试。主要方法有:逻辑驱动,基路测试、边界值分析、循环测试、覆盖测试、数据流测试、变异测试。
- 知道产品内部工作过程
- 检测内部动作是否按照说明书进行
- 不管功能
- 白盒测试工具是对源代码进行测试
2)黑盒:又称功能测试或数据驱动测试。主要方法有:基于用户需求的测试,边界值测试,等价类划分,错误推测方法,因果图方法,判定表驱动分析。
- 在软件接口处进行
- 不考虑内部逻辑结构和内部特性
- 检查功能是否符合要求
9、动态、静态测试
- 动态:运行程序
- 静态:评审文档,阅读代码(例如:查找不匹配的参数,不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针等)
10、回归测试
在程序员修改后,保证功能被修复且不能带来新的bug。一般是在软件维护阶段进行。
11、软件缺陷分级
- 严重性分级:基于对客户的打分的影响程度。
1)致命:相关模块功能异常,死机
2)严重:本模块失常
3)一般:模块功能部分有问题
4)建议:不怎么好用 - 优先级分级:基于缺陷被修复的紧急程度。
1)立即:软件几乎不能用
2)紧急:比较严重
3)高优:缺陷严重,影响测试
4)正常:部分异常,不影响其他
5)低级:先不忙
12、软件测试阶段及各阶段要点
1)测试阶段
- 单元测试
- 集成测试
- 系统测试
- 验收测试
2)每个测试阶段分为以下步骤
- 测试计划
- 测试设计
- 用例设计
- 执行测试
- 测试文档
13、单元测试、集成测试、系统测试的侧重点
- 单元测试:测试其功能的正确性
- 集成测试:测试模块间的衔接及参数传递
- 系统测试:测试整个系统的运行及与其他软件的兼容
14、bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程
15、集成测试和系统测试的区别及应用场景
测试类型 | 区别 | 应用场景 |
---|---|---|
集成测试 | 概要设计阶段制定集成测试计划和用例(后);先执行集成测试;测试用例详细,重点在于接口部分;对测试人员编写脚本能力要求较高;测试方法为黑白结合 | 单元测试结束后,主要测试各模块接口是否一致,数据流和控制流是否按要求实现,结果的正确性 |
系统测试 | 需求阶段要制定系统测试计划和用例(先);后执行系统测试;一般使用黑盒测试 | 针对整个产品成品之后,包含性能测试、功能测试、健壮性、安全性测试等 |
16、测试开发知识及能力
1)知识
- 软件基础测试理论知识
- 基本编程语言
- 自动化测试工具
- 计算机基础知识
2)能力
- 业务分析能力
- 缺陷洞察能力
- 团队协作能力
- 专业技能
- 逻辑思维
- 问题解决
- 沟通表达
- 宏观把控
17、手动测试与自动化测试优缺点
测试方法 | 优点 | 缺点 |
---|---|---|
手工测试 | 测试员有经验,能够对一些错误进行猜测;测试员有审美和心理体验;测试员有是非判断和逻辑推理能力 | 重复的手工回归测试,代价昂贵,容易出错;过于依赖测试员的能力 |
自动化测试 | 回归测试方便,极易应付频繁修改程序的情况,且测试具有一致性和可重复性;可以运行繁琐的测试;能够执行手工测试困难或不可能进行的测试;更好地利用资源;增加软件信任度 | 工具本身无想象力;发现缺陷固定且较少;对测试质量地依赖性较大;不能提高有效性 |
18、软件测试的潜力和挑战
- 快速发展,充满挑战
- 自动化测试软件替代传统手工测试
- 自动化测试工具开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项仍需要大量具有专业技能和素养的测试人员
- 随着新技术的发展,传统测试技术还需要不断调整
19、软件测试的核心竞争力
测试人员的核心竞争力在于提早发现问题,尤其是别人无法发现的问题
- 如果需求未实现的时候发现漏洞,价值特别高
- 别人无法发现问题,而测试人员可以发现,说明了测试人员的不可替代性
20、测试和开发怎样结合才能使软件质量得到更好的保障
V模型:将测试过程加在开发过程的后半段,具体如图。缺点:忽略了测试对需求分析、系统设计的验证,需求阶段的缺陷可能到后期的验收才会发现,此时弥补将耗费大量的资源。
W模型:测试伴随软件开发周期,且测试对象不仅仅是程序,还有需求、设计等。测试与开发过程分别如两个V所示,具体如图。优点:尽早发现软件缺陷,降低软件开发成本;容易把握项目难度及风险,及早制定措施;减少总体测试时间,加快项目进度。
21、测试流程
- 需求测试
- 概要设计测试
- 详细设计测试
- 单元测试
- 集成测试
- 系统测试
- 验收测试
22、写测试用例注意事项
- 理解需求(基础)
- 参考类似需求的测试用例
- 了解输入、输出及其关系,理解需求的执行逻辑,通过等价类、边界值、判定表等找出大部分用例
- 找到需求相关特性,补充测试用例
- 根据经验分析遗漏测试场景
- 多加总结,书写清晰规范
23、测试具体工作
- 搭建测试环境
- 撰写测试用例
- 执行测试用例
- 撰写测试计划、测试报告
- 实施测试、提交报告
- 跟踪bug修改情况
- 执行自动化测试,编写脚本,执行,分析,报告
- 进行性能测试、压力测试等其他测试,执行,分析,报告
24、软件质量六个特征
- 功能特征
- 可靠性特征
- 易用特征
- 效率特征
- 可维护性特征
- 可移植性特征
25、bug周期及类型
1)周期
- 新的
- 已指派的(责任已经到人)
- 打开的(正在处理)
- 已修复的
- 待测试的
- 正在测试
- 关闭(已经解决)
- 再次打开
- 拒绝中(开发人员)
- 被拒绝的(项目组长根据产品要求和说明)
- 延期的
2)类型 - 代码错误
- 界面优化
- 设计缺陷
- 配置相关
- 安装部署
- 安全相关
- 性能问题
- 标准规范
- 测试脚本
- 其他
26、web测试和app测试
测试方法 | 系统架构方面 | 性能方法 | 兼容方面 | 专项测试 |
---|---|---|---|---|
web测试 | b/s架构,基于浏览器;web更新服务器端,客户端同步更新 | web主要关注响应时间 | web重点在于浏览器和电脑硬件、系统的兼容;不考虑卸载和安装 | |
app测试 | c/s架构,必须有客户端;需要同时更新客户端和服务器端 | app关注流量、电量、CPU、GPU、Memory等 | app看分辨率、屏幕尺寸,还有设备系统;必须考虑安装、更新、卸载;还有异常场景中断、弱网、安装后删除文件等 | 网络、适配性 |
27、测试分类
测试分类 | 包含 |
---|---|
功能测试 | 功能测试 |
非功能测试 | 性能、压力、容量、安全性、易用性、健壮性、恢复性、备份、协议、兼容性、GUI |
实例部分
1、用户登录测试
测试类型 | 测试内容 |
---|---|
功能测试 |
|
界面测试 |
|
性能测试 |
|
安全性测试 |
|
可用性测试 |
|
兼容性测试 |
|
2、杯子测试
测试类型 | 测试内容 |
---|---|
功能测试 |
|
界面测试 |
|
性能测试 |
|
安全性测试 |
|
易用性测试 |
|
震动测试 |
|