软件测试基础
软件测试基础
技术团队构成
项目经理
工作职责
软件测试基本概念
什么是软件测试
弄清楚实际结果和预期结果的差异
通过人工或自动化的手段来检测被测对象是否符合用户需求
软件测试的目的
保障产品符合用户需求，发现并解决问题，预估产品质量
降低产品失败的风险，提高用户对产品质量的信心
软件生命周期
怎样做好软件测试
掌握专业的测试技能
熟悉相关业务知识持续的学习能力沟通能力
责任心，自信心，细心，耐心，风险意识，总结、分析问题的能力，团队协作精神，抗压能力…….
开发模型
瀑布模型
内容
原型模型
螺旋模型
RUP模型
敏捷模型
测试模型
缺陷管理
缺陷的基本概念
什么是缺陷
所有不满足用户需求的都是缺陷
包含情景
- 遗漏：
用户要求的功能没有实现 - 错误：
用户要求的功能实现了，但是实现的功能有问题或者根本无法使用 - 冗余：
实现了用户需求中没有要求的功能 - 不满意：实现的功能都是符合用户需求的，但是用户就是不满意
软件测试原则
软件测试是为了证明缺陷的存在
不可能进行穷尽测试
- 不可能覆盖所有的测试场景
- 不可能将所有的bug都找出来
测试应该尽早的介入，尽早的启动
测试越早启动，越早进行测试，越早发现bug；修复bug的成本越低。
越往后定位bug越难，系统业务越来越复杂，修改代码的影响范围越广
越早的介入，越早了解需求，对需求的理解越深，对业务越熟悉，测试覆盖度越广，测试质量越高。
能够越早的了解到产品经理和开发人员的工作计划，从而能够更加合理的安排测试自己的工作计划。
缺陷群集现象
二八原则
80%的bug集中在20%的主要功能上面；
在测试的过程中发现某个缺陷存在bug，那么它周边的功能也可能会存在类似的bug
____在测试的过程中发现某个开发人员写的某个功能存在bug，那么由该开发负责编写的其他功能可能也存在类似的bug
杀虫剂悖论
不同的测试活动依赖于不同的测试背景
不存在缺陷的谬论
所有软件都存在缺陷
软件测试方法
是否关注代码的内部逻辑划分
- 白盒测试：单元测试阶段
在测试的过程中，关注代码的内部逻辑 - 灰盒测试：群集测试阶段
在测试的过程中，既关注代码的内部逻辑，也关注程序的输入和输出 - 黑盒测试
测试类型
功能测试
- 显性需求：需求规格说明书中明确要求的
- 隐性需求：需求规格说明书中没有明确的要求 但是程序在实现的过程中需要实现的功能
性能测试
- 并发测试：不同人在同一时间做同一件事（狭义上的并发）
- 负载测试：相关指标都没有出错的情况下 观察程序的运行情况
- 压力测试：运行相关指标出现错误 蚝尽服务器资源
- 容量测试：
- 稳定性测试：
性能的相关指标
- 并发用户数
- 最大用户数
- 响应时间
- 每秒点击数
- 服务器相关指标
- QPS
安全测试
渗透性测试工程师
兼容性测试
- Web项目：
不同浏览器：不同浏览器对JS和html标签的支持不太一样
不同操作系统，不同分辨率 - APP项目
不同操作系统，不同品牌，不同型号，不同版本
APP兼容性测试策略：真机+模拟器+云测 云测平台：mtc testin wetest
接口测试
接口：负责模块与模块之间数据的传输和交互
接口测试实际上就是没有界面的功能测试
接口测试可以越早发现问题 修复问题成本越低
前段传参不可信 接口层面会覆盖的更广，更安全
缩短测试时间：在系统测试之前进行接口测试，保障所有的接口都没有问题，这样在系统测试阶段发现的问题会减少，并且发现问题定位位问题的成本更低
接口测试工具：postman jmeter soupui httpclint fiddler
接口测试的依据
接口设计文档 数据库表结构设计文档 产品需求规格说明书
怎样评判接口没有问题
- 接口能否被正常调用
- 接口请求参数 返回传输以及数据的格式是否符合接口文档所声名
- 接口返回的数据是正确的
- 接口是否实现接口文档所声明的功能
- 接口设计是否满足实际的业务需求
文档测试
测试对象：
产品需求规格说明书 原型图 流程图 数据库表结构设计文档 接口设计文档 安装部署文档 软件运维手册 用户操作手册
测试内容
正确性 完整性 一致性 无二义性
界面（UI）测试 易用性测试（友好性测试） 安装卸载测试（C/S结构项目）
app专项测试：耗电 流量 温度 内存 cpu
测试标准：
和同类型的产品进行比较 和自己的上一代产品比较
- 其他测试类型
可用 可靠 可移植 可维护 可扩展性测试 - 不算测试类型的
确认测试：验证缺陷是否真正的得到解决
回归测试
防止研发人员在修复缺陷的时候，引入新的缺陷
回归测试策略
完全回归：执行所有的测试用例 覆盖所有的功能
选择性回归：执行上一轮失败的测试用例
测试确认：执行系统核心功能 主业务功能的测试用例
测试轮次
一般至少三轮
第一轮测试
覆盖测试 首先进行冒烟测试
测试系统核心功能 主业务流程功能
冒烟测试的目的是为了保障测试的代码质量满足基本的测试需要
冒烟测试通过 再进行覆盖测试：执行所有的测试用例
测试阶段(级别)
需求测试
测试对象
- 产品需求规格说明书
- 原型图
- 流程图
测试实施时间
需求设计完成之后、编码之前
测试内容
- 正确性
- 完整性
- 一致性
- 无二义性
测试实施人员
测试工测师
测试方法
黑盒 静态 手工
测试类型 文档测试
单元测试
测试对象：代码片断（方法 类 函数）“单元”是软件测试中最小的单位
测试实施时间：编码的过程中 测试内容：测试代码片段是否实现其所声明的功能
测试实施人员：开发工程师，白盒测试工程师
测试方法：白盒测试，动态测试，手工、自动化测试
测试类型：功能测试
集成测试
接口测试 测试对象：模块和模块之间数据传输和交互的正确性 各种接口
测试实施时间：模块开发完成、进行模块之间联调的时候、接口开发完成之后
测试内容：接口的功能、性能、安全
测试实施人员：测试工程师
测试方法：灰盒，动态、静态（测试接口文档、数据库表结构设计文档） 手工、自动化
测试类型：接口测试，功能测试，性能测试，安全测试，文档测试
系统测试
测试对象：完整功能的系统
测试实施时间：模块联调完成，所有功能开发完成之后
测试内容：需求规格说明书中声明的所有
测试实施人员：测试工程师
测试方法：出灰盒之外的其余所有测试方法
测试类型：除接口测试之外的其余所有测试类型
验收测试
测试对象：功能层面上讲，和系统测试一样
相比系统测试来说，多了一些过程文档验收
测试实施时间：系统测试完成之后，给用户安装部署前/后
测试内容：需求规格说明书中要求的所有功能
文档的正确性，完整性，一致性和无二义性
测试实施人员：测试工程师，甲方（甲方代表）
测试方法：几乎所有 具体的看甲方要求做哪些类型的测试
测试类型：几乎所有
验收测试的划分
阿尔法测试：在开发（测试，仿真）环境下进行的，开发人员一般在现场，发现问题后及时修复
贝塔测试：在用户真实环境下进行的，真正核心的区别在于测试使用的数据不一样
开发人员一般不在现场，发现问题后统一收集，统一反馈，统一修复
UAT测试：用户接受度测试
测试用例
测试用例的概念
测试执行的时候使用的一个例子，为了特定的目的（用例标题）而设计的一组输入（操作步骤和预置条件）和输出（预期结果）
测试用例的作用
不断加深对需求的理解，提高测试覆盖度
对需求理解越深，那么考虑的场景越多，测试用例 用例覆盖度越广，测试质量越高
指导测试执行，一定程度上反映测试进度，帮助后期分析测试质量
测试用例的内容
- 用例编号
每个公司有所差异
项目-测试阶段-模块-测试项-编号 - 所属项目
- 所需产品
- 所属模块
- 测试项
- 用例标题
一句话言简意赅的说明本条测试用例要用来测什么 - 预置条件
- 操作步骤
- 预期结果
- 优先级
- 用例属性
- 适用阶段
- 作者
测试用例设计原则
测试用例设计方法
测试用例评审
测试流程
