功能测试实战——TPshop开源商城

CHERISHGF

已于 2023-07-21 19:26:59 修改

阅读量8.5k

点赞数 26

分类专栏：测试学习笔记文章标签：功能测试

于 2023-07-21 19:25:06 首次发布

本文链接： https://blog.csdn.net/CHERISHGF/article/details/131813549

版权

测试学习笔记专栏收录该内容

28 篇文章 3 订阅

订阅专栏

熟悉项目

项目架构
业务模块，模块之间的关系
项目干了个啥

测试流程

需求评审
编写测试计划和测试方案
编写测试用例与评审
测试执行与BUG跟踪
编写测试报告

功能测试：理解需求，根据功能点编写测试用例

基本要求：覆盖需求，需求文档，产品原型图，UI设计图，以用户角度测试软件的可见功能

设计步骤：需求分析==》测试点==》测试用例

轮播图功能测试

需求说明与测试点

需求以需求文档为准，不同意见需要在需求评审的时候提出来

编写测试用例

编写测试用例没有对错之分，自己写着练习

ID：建用例编号
用例优先级
P0：一般为保证软件中最主要、重要的功能，最基本的流程能正常运行而设计
P1：次要功能、小功能
P2：UI、边界、错误的设置
P3：错误信息、较复杂的场景、不常用的场景
测试结果：pass、fail、block（由于有bug不能继续执行时填写）、NA（由于环境、资源缺失不能执行时填写）
测试版本号：当前测试任务所用的软件版本号
备注：
1. fail的用例问题描述和对应的bugID可填入此项中
2. block和NA的用例需要在此项填写原因
3. 对用例有疑问，或此用例需要更新也可以填写在此项中

执行测试用例并记录缺陷

ID：缺陷编号
问题描述：对应于“禅道”中bug标题，或问题简要描述
严重程度：
严重（S1）：主功能不可用、crash问题、闪退、不能启动
一般（S2）：次要功能不可用，边界、异常未进行处理等
微小（S3）：易用性问题、界面展示，小的性能问题等
建议（S4）：建议性问题
缺陷优先级：
Priority 0：必须在24小时之内被解决
Priority 1：产品发布前必须修复
Priority 2：可以在下一个版本中修复
缺陷状态：
New：新建
Open：打开
Fixed：修复
Rejected：拒绝
Postponed: 延期
Reopen：再次打开

购物车功能测试

需求说明与测试点

测试点尽量写的详细，后面测试用例编写的时候，可以酌情删减

测试点可以excel或者xmind的形式整理

确保需求文档里写的点都要被测到

编写测试用例

有个疑问的地方，设计测试用力的时候，感觉有些测试点可以合并成一条测试用例，不知道这时候是分开写多条测试用例还是写一条覆盖。

写多条，可以把其他的情况作为前置条件或者测试数据，在测试步骤中体现，预期结果只关注测试点的效果

测试步骤一致时，需要确认的东西都可以写在预期结果中

注册功能测试

需求说明与测试点

编写测试用例

等价类划分，测试用例尽量覆盖全部的有效等价类，每个无效等价类都需要一条测试用例

会员列表功能测试

需求说明与测试点

一些页面截图

抢购功能测试

需求说明与测试点

一些界面截图

优惠卷功能测试

需求说明与测试点

一些界面截图

非功能性测试

兼容性测试：不同平台，不同浏览器，不同操作系统，不同操作系统版本，不同网络情况
界面测试（UI）：布局、风格、按钮、参照UI设计图
易用性测试：用户群体、计算机水平、项目复杂性、快捷操作
性能测试：用户量大、并发测试、压力测试、负载测试
安全测试：输入数据、传输数据、输出数据、sql注入、渗透测试

业务流程测试

状态转移法

概念：基于系统中模块或节点之间的状态。来描绘状态与状态之间的关系，从而找到状态之间转化的路线设计测试用例的一种方法。

使用：

找出系统所有的节点
绘制状态迁移图
绘制状态迁移树
找出状态之间的转换路径

业务流程图

业务流程测试的关注点：
- 关注点在核心业务是否能够跑通
- 重点不是关注单个功能模块的细节点
业务流程测试的价值：
- 客户角度：对客户最有价值的是业务的实现，不是单功能模块的质量
- 测试人员角度：分配任务往往是针对功能模块划分，业务流程的测试容易遗漏
进行业务流程测试的时机
- 上线前进行业务流程测试的确认
- 单功能模块基本可用的情况下，尽早进行（冒烟测试）
业务流程测试用例设计
- 需求分析，明确流程
- 画出流程图
- 编写测试用例，一条路径对应一条测试用例
  - 路径较多时，根据业务设计优先级