测试入门基础知识笔记

最新推荐文章于 2024-10-16 10:11:29 发布

zhuzi36988

最新推荐文章于 2024-10-16 10:11:29 发布

阅读量677

点赞数

文章标签：功能测试测试用例

本文链接：https://blog.csdn.net/m0_59235722/article/details/131767795

版权

本文详细介绍了软件测试中的关键环节，包括测试用例设计（等价类、边界值、判定表、场景法），缺陷管理的流程，以及抓包工具在测试中的应用。同时，强调了数据库操作和环境部署在测试中的重要性，并提出项目实战的经验总结，强调测试对于软件质量保障的关键作用。

摘要由CSDN通过智能技术生成

学习路径：

测试用例设计
缺陷管理
抓包管理
数据库操作
环境部署
项目实战

一、测试用例设计

1、测试怎么做？

分析需求——明确需求，梳理规则
针对需求设计测试点——测试点可以根据设计方式进行高效设计
针对测试点编写测试用例
执行测试用例——根据用例文档测试步骤执行，对比预期结果，来决定用例执行是否通过
缺陷管理——提交缺陷、跟踪缺陷、验证缺陷
总结测试报告——统计缺陷，总结本次测试执行为下次测试积累经验

流程如下：

需求（分析需求）--> 测试点（针对需求设计测试点）--> 用例（针对测试点编写用例）--> 执行（根据用例执行测试）--> 缺陷（针对缺陷进行管理）--> 报告（总结测试报告）

2、用例八大要素

用例编号：区分用例的唯一编号；格式：项目名称_模块_数字编号 qq_login_001
用例标题：本条用例测试点；格式：预期结果(测试点)
模块/项目：用例所属模块；格式：模块名
前置条件：执行本条用例的前置操作
优先级：本条用例优先级；P0-P4 P0最高
测试步骤：执行用例操作步骤
测试数据：执行本条用例使用的测试数据
预期结果：本条用例执行期望结果
实际结果(额外)：失败/通过

用例描述格式：

用例编号、用例标题、模块/项目、前置条件、优先级、测试步骤、测试数据、预期结果、实际结果

3、需求设计方法

3-1、等价类设计方法

分类：有效等价、无效等价
步骤：明确需求 --> 确定有效等价和无效等价 --> 提取数据设计用例
适用场景：适用于需要有大量数据测试输入，但是没法穷举测试的地方；典型代表有输入框、下拉列表、单选复选框

3-2、边界值设计方法

说明：边界范围节点选取正好等于、刚好大于、刚好小于边界的值作为测试数据（上点、离点、内点）
优化：上点、内点必选；离点开内闭外
步骤：明确需求 --> 确定有效和无效等价类 --> 确定边界值 --> 提取数据编写用例
适用场景：在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)；常见词：大小、尺寸、重量、最大、最新、至多、至少等；典型代表有有边界范围的输入框

3-3、判定表设计方法

说明：等价类边界值分析法主要是关注单个输入类条件的测试；并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试
定义：判定表是一种以表格形式表达多条件逻辑判断的工具，由条件桩、动作桩、条件项、动作项组成
规则：判定表中贯穿条件和动作项的一列就是一条规则；假设有n个条件。每个条件的取值就有两个(0,1)，全组合有2的n次方种规则
步骤：明确需求 --> 画出判定表 --> 根据规则编写用例
适用场景：有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系；判定表一般适用于条件组合数量较少的情况(比如4个条件以下)

3-4、场景法设计方法

说明：也叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程图路径来设计测试用例
意义：用户使用角度用户平时使用的不是单个功能，而是多个功能组合起来进行使用；测试人员角度平时测试的都是单个功能点，容易忽略多个功能的组合测试
适用场景：根据实际的应用场景来测试业务用例，可采用场景法

4、用例执行

当执行结果和预期结果不一致，为缺陷
发现缺陷需要进行缺陷管理（提交 --> 开发修复 --> 测试验证 --> 关闭缺陷）

二、缺陷管理

1、缺陷介绍

1-1、定义：软件在使用过程中存在的问题都叫做软件的缺陷，简称Bug

1-2、评判的标准：少功能、功能错误、多功能、隐形功能错误、不易使用

1-3、产生的原因：需求 --> 设计 --> 编码 --> 运行

需求阶段：需求描述不易理解，有歧义，有错误等
设计阶段：设计文档存在错误或缺陷
编码阶段：代码出现错误
运行系统：软硬件系统本身故障导致软件缺陷

1-4、生命周期：需求规格说明 --> 设计 --> 编码 --> 测试 --> 故障分类 --> 故障隔离 --> 故障解决

1-5、类型：功能错误、界面UI错误、兼容性、数据、易用性、改进建议、架构

2、缺陷编写

核心内容

标题：描述缺陷的核心问题
预置条件：缺陷产生的前提
复现过程：复现缺陷的过程
预期结果：希望得到的结果
实际结果：实际得到的结果
必要条件：图片、日志等信息证据

缺陷描述格式：

缺陷ID、缺陷标题、缺陷状态、严重程度、优先级、所属模块、缺陷描述、附件
缺陷ID、缺陷标题、所属模块、预置条件、严重程度、预期结果、实际结果、复现步骤、附件

3、跟踪流程

提交缺陷(测试) --> 分配缺陷(缺陷提谁) --> 处理缺陷(开发) --> 回归测试(测试) --> 关闭缺陷(测试)
填写缺陷 --> 修改缺陷 --> 回归测试

4、提交流程

提交缺陷 --> 分派缺陷 --> 是否重复 & 是否bug --> 关闭缺陷/是否推迟处理 --> 处理缺陷/后续版本 --> 回归测试 --> 是否验证通过 --> 关闭缺陷/重新打开 --> 分派缺陷

4-1、提交要素

缺陷报告编号：缺陷的唯一性标志
严重程度：严重S1、一般S2、微小S3、建议S4
优先级：Priority0(24小时之内解决)、Priority1(发布前必须修复)、Priority2(可以在下一版本中修复)
缺陷类型：代码错误、兼容性问题、设计缺陷、性能问题
缺陷状态：New新增、Open打开、Closed关闭、Postponed延期

4-2、注意事项

可重现：缺陷可以复现
唯一性：一个缺陷上报一个问题
规范性：符合公司或项目要求

5、缺陷管理工具(禅道)

测试人员：撰写用例、执行用例、提交bug、验证bug、关闭bug
用例使用流程：管理用例 --> 创建用例 --> 评审用例 --> 执行用例
缺陷使用流程：管理缺陷 --> 缺陷创建 --> 缺陷跟踪 --> 缺陷验证

三、抓包管理

1、抓包原因

1-1、说明：通过工具抓取前端与后端的通信内容；使用工具获取客户端和服务器的请求及响应数据

1-2、原因

跳过前台验证，测试后台业务逻辑处理；功能测试时跳过ui界面验证，验证后端程序处理能力；(如，请求支付100元，通过抓包修改请求价格0.1，查看后端程序是否能正常处理)
定位bug是前台或后台；分析前端还是后端bug；(如：ui显示数据错误，提交bug时需要指定提交给前端还是后端开发)
弱网测试；(如：app应用模拟4G、3G网络)
接口测试时，缺乏接口描述文档，需要抓包获取；(如：查看支付宝请求信息)