软件测试
概念
什么是软件测试
-
软件测试 : 验证软件产品特性是否满足用户的需求
-
软件测试的特点 : 软件测试只是一个样本试验,具有不可穷尽性
软件测试和调试的区别
- 目的不同
- 调试(Debug):确保程序 做了程序员想它做的事情
- 测试(Testing):确保程序 解决了它该解决的问题
- 参与角色不同
- 测试由测试人员和开发人员来执行,黑盒测试主要由测试人员完成、部分白盒 / 系统测试由开发人员执行
- 调试由开发人员完成。
- 阶段不同
- 测试 贯穿整个软件开发生命周期
- 调试 一般在开发阶段。
优秀测试人员所具备的素质
- 技能
- 设计测试用例 能力
- 编程 能力(编写测试工具 , 自动化测试用例)
- 技术快速学习能力
- 业务快速学习能力
- 非技能
- 沟通合作能力
- 文字表达能力(测试用例 , 描述BUG)
- 抗压能力 (测试时间短)
- 责任感
测试用例 (Case)
测试用例(Test Case)是为了实施测试 , 向被测试的系统提供的一组集合,
要素:测试环境、操作步骤、测试数据、预期结果
测试用例解决了两大问题:测什么,怎么测。
测试过程中可能会遇到以下问题:
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
测试用例的产生就是为了解决上述的问题
- 测试用例的好处
- 提高测试效率 , 节约测试时间
- 测试用例是自动化测试用例的前提
软件的生命周期
需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护
软件测试的生命周期
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估(报告)
需求
什么是需求
- 用户需求:可以简单理解为甲方提出的需求,如果没有甲方,那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
- 软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。
大多数公司在进行软件开发的时候会把用户需求转化为软件需求,开发人员和测试人员工作的直接依据就是软件需求
测试人员眼里的需求
需求是测试人员开展软件测试工作的依据。
测试工程师应在需求分析和设计阶段就开始介入
在具体设计测试用例的时候,首先需要搞清楚每一个业务需求对应的多个软件功能需求点,然后分析出每个软件功能需求点对应的多个测试需求点,然后针对每个测试需求点设计测试用例。
业务需求—>软件功能需求点—>测试需求点—>测试用例
开发模型
瀑布模型
- 优点 : 每个阶段做什么 , 产出什么都非常清晰 .
- 缺点 : 风险往往后期才被发现 , 因而失去及早纠正机会
- 适用 : 小型项目
螺旋模型
- 优点 : –强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下去
- 缺点 : 对风险管理要求很高 , 需要大量人力财力时间投入
- 适用 : 风险较多的大型项目
敏捷
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
(拥抱变化 , 轻流程 , 重交付 , 轻文档 , 重交互)
每对比对中,后者并非全无价值,但我们更看重前者
- scrum
scrum 由 PO(产品经理) 、SM(项目经理) 和 team(研发团队) 组成
scrum 将产品的开发分解为若干个 小sprint(迭代) 。
每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
流程 :
测试模型
- V模型
单元和集成测试 应检测程序的执行是否满足软件设计的要求;
系统测试 应检测系统功能、性能的质量特性是否达到系统要求的指标;
验收测试 确定软件的实现是否满足用户需要或合同的要求
.
优点 : 测试被划分为许多类型
缺点 : 测试人员介入太晚 , 发现问题太晚
- W模型 ( 双V模型 )
优点 : 测试人员尽早介入了需求
局限 : 一定程度上还是线性的 , 无法支持敏捷开发模式
BUG
软件错误(BUG)
当且仅当 ( 规格说明是存在的并且正确 ) ,程序与规格说明之间的不匹配才是错误。
当需求 ( 规格说明书没有提到的功能 ) ,判断标准以最终用户为准:
当程序没有实现其最终用户合理预期的功能要求时,就是软件错误
如何描述一个bug (重点)
1. 发现问题的版本
开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2. 问题出现的环境
环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3. 错误重现的步骤
描述问题重现的最短步骤。
4. 预期行为的描述
要让开发人员指导怎么样才是正确的,尤其要以用户的角度来描述程序的行为是怎样的。
如果是依据需求提出的故障,能写明需求的来源是最好的。
5. 错误行为的描述
描述错误的现象。crash等可以上传log,UI问题可以有截图。
6. 不要把多个bug放到一起
在无法确认是同一段代码造成的故障时,不要将bug放在一起提交
7. 其他
某些公司会有一些其他的要求,例如故障的分类:功能故障,界面故障,兼容性故障等。
有些有优先级的分类,严重影响测试需要开发人员优先修改的,可以设置优先级为高。
BUG 的级别
因公司而异
- Blocker(崩溃)
- Critical(严重)
- Major(一般)
- Minor(次要)
bug的生命周期
因公司而异
测试
产生争执
作为一名测试人员,一般会遇到以下几种情况:
- 这不是bug
- 这个bug的级别太高了
- bug影响不大,暂不修改
解决方案
前提 : 一定不能吵架
- 确保操作没有问题 , 确保自己对需求理解没有问题
- 好好沟通
- 站在用户角度考虑问题
- 提出解决方案
- 开第三方会议
开会之前 : 明确问题产生原因 , 解决方案是什么
开会之中 : 问题要不要解决 , 什么时候 , 谁解决
开始测试
- 充分理解需求
文档 (产品文档 + 技术文档)
()项目功能问题问产品 , 模块底层实现问开发) - 确定测试计划
- 执行测试
( BUG )开发修复之后一定要验收 - 项目上线 + 维护