目录
对软件系统能够做基本的功能测试
一、认识软件测试
-
软件测试:通过技术手段验证软件是否满足需求过程
-
目的:用最少的人力、物力、财力、找到软件中的问题并修复,从而降低商业风险
最终目的:保障软件产品质量–>确保软件系统没有漏洞/没有质量问题
二、软件测试技能
- 功能测试:功能测试主要验证程序的功能是否满足需求
- 自动化测试:使用代码或工具代替人工验证项目功能
- 接口测试:针对模块与模块或系统与系统之间数据交互的测试
- 性能测试:模拟多人使用软件,查找服务器缺陷
三、软件测试分类
应用场景:面试中被面试官问到或者提到
3.1按照阶段划分
- 单元测试:对于开发的源代码进行测试[一般由开发做]
- 集成测试:也叫接口测试,测试系统和系统,模块和模块之间数据交互(能否正常使用)[一般由测试人员做]
- 系统测试:也叫功能测试,测试整个软件产品的功能能否满足需求(包含兼容,文档等测试)[一般由测试人员做]
- 验收测试:模拟用户验证是否满足用户的需求(分为内测和公测)[一般由用户/用户代表做]
- 内测:alpha测试
- 公测:beta测试
3.2按照代码可见度划分
- 黑盒测试:看不到源代码,进行功能级别的测试
- 灰盒测试:部分代码可见,相当于做接口测试
- 白盒测试:通过源代码测试源代码(单元测试)
3.3测试策略
-
冒烟测试:对软件系统做基本的功能测试,目的保证基本功能能走通⭐️
常见问题:
- 你们开始进行测试的标准是什么? —冒烟测试通过之后【一般测试做】
- 开发提测的标准?
-
回归测试:对于已经发现的问题(bug),开发修复后,再次进行验证测试的过程⭐️
常见问题:回归测试怎么做?–手工做,自动化方式做
注意事项:回归测试主要是验证当前的bug是否修复?回归测试还需要验证当前的bug有没有带来新的问题
-
随机测试:对于重点功能进行复测(随机抽取一部分用例测试)
-
探索性测试:要求测试设计和执行同步进行,边用边学测试过程
四、模型
4.1质量模型
作用:给测试设计人员提供一个思考的方向【被测软件产品质量的思考方向】
4.2测试模型【W模型】
作用:描述公司中测试开发产品等部门人员如何协同工作
- 优点
- 测试介入早,能及早发现问题,降低修复成功
- 测试伴随整个产品开发周期
- 缺点
- 复杂(测试设计方面)
五、软件测试流程⭐️
作用:指导测试在实际工作中如何具体开展测试活动
面试:在公司中你们是如何开展测试工作的?你是如何做测试的?
- 需求分析
- 目的:产品 开发 测试对于需求理解一致,查漏补缺
- 结论:确定好需求
- 测试计划与方案
- 目的:保障测试工作有效有序的进行下去
- 结论:测试什么 测多少 谁来测 怎么测试
- 测试设计
- 目的:确保测试工作全面无遗漏
- 结论:按照需求文档编写操作文档(测试用例)
- 测试执行
- 目的:验证软件能否满足需求
- 结论:测试满足需求(通过),测试不满足需求(失败)
- 缺陷管理
- 目的:和开发确认沟通确保问题被解决
- 结论:对于发现的bug进行跟踪验证直到修复(通过)
- 测试报告
- 目的:对于软件质量结果说明
- 结论:测试活动结束标志
六、测试用例⭐️
6.1测试用例
-
概念:为了测试设计编写的执行文档
-
作用
根据产品的需求文档转化为可验证的测试用例文档,方便后续测试验
-
- 防止漏测
- 测试实施的标准
6.2测试用例的构成要素
- 用例编号
- 作用:表示用例的唯一性
- 构成:项目_ 模块 _数字序号
- 用例标题
- 作用:表示测试目的(干什么?)
- 构成:预期结果+测试条件
- 模块/项目
- 作用:测试范围(不清楚可以不写)
- 构成:根据需求文档简写模块名/项目名
- 优先级
- 作用:该用例的重要程度
- 构成:P0(最高)~P4(最低)
- 预置条件
- 作用:执行的时候需要的前提是什么(没有可以不写)
- 构成:文字描述前提条件
- 测试步骤
- 作用:描述测试执行的过程
- 构成:按照序号编写操作过程
- 测试数据
- 作用:测试执行过程中需要输入的数据(没有可以不写)
- 构成:有直接输入具体数据
- 预期结果
- 作用:描述是否和需求一致的结果
- 构成:根据需求文字描述即可(结论+现象)