TPshop（项目介绍，测试活动开展：需求评审，测试计划，用例设计，用例评审，用例执行，缺陷管理，测试报告）

hyhrosewind

于 2025-04-16 15:56:48 发布

阅读量869

点赞数 7

CC 4.0 BY-SA版权

分类专栏： 01-测试基础文章标签： tpshop项目和项目介绍测试活动开展需求评审测试计划用例设计和用例评审用例执行和缺陷管理测试报告

本文链接：https://blog.youkuaiyun.com/hyh12261998/article/details/147278571

01-测试基础专栏收录该内容

7 篇文章

订阅专栏

TPshop项目介绍

Tpshop是一个类似于淘宝、京东一样的B2C商务平台，简称电商。

B2C（企业到消费者）：

B（Business）意思是企业
2是to的谐音
C（Customer）意思是消费者

电商平台的主要用户：卖家和买家。

买家和卖家的功能：

技术栈（在软件开发或系统构建过程中，为了满足特定需求而选择组合的一组技术和工具的集合）：

开发语言：PHP
应用服务器：Nginx/Apache
数据库：MySQL

TPshop测试活动开展

需求评审

基本测试流程：

需求评审>测试计划>用例设计>用例评审>用例执行>缺陷管理>测试报告

需求评审（确保各部门的需求理解一致）：

评审之前：阅读需求，记录疑问点，方便在评审会上确认
评审形式：一般以会议的形式展开(参会人员：产品经理、项目经理、开发人员、测试工程师等）
评审目的：
1. 明确测试范围
2. 站在不同角度对需求进行查漏补缺
3. 各部门对需求理解一致
评审产出：
1. 各部门的工作内容
2. 评审通过的需求文档

TPshop需求说明书：

TPshop全部业务功能

明确TPshop测试范围

红色为业务：下单流程，发货流程，退款流程，退货流程，换货流程
灰色为单功能：登录，搜索，购物车，支付，个人中心，发货页，退货退款，商品添加，抢购，优惠券

测试计划

基本测试流程：

需求评审>测试计划>用例设计>用例评审>用例执行>缺陷管理>测试报告

测试计划：

提前规划测试活动，指导测试组成员进行工作
让测试组以外的项目成员了解测试的会进行哪些工作。

测试计划的编写：项目测试负责人（比如：测试经理）

测试计划有：

针对项目的测试总计划
针对测试成员的个人执行计划（个人自己制定）

项目的测试总计划包含的核心内容：

测试对象和测试范围
测试进度安排（需要的工时，涉及到的测试资源和人员）
准入准出标准
1. 准入标准：软件达成什么样的情况，才能交给测试人员进行测试（达到测试的标准-即提测标准-提测标准是冒烟测试通过）
2. 准出标准：最终对软件的测试达到什么样的标准，才可以中止测试，进行后续工作；bug修复到什么程度就可以上线了(比如：bug修复率达到95%，且没有（含）中级以上的未修复bug）；发现重大设计问题，重大需求问题暂停测试，通知相关领导，并立即组织讨论

TPshop的测试计划

测试计划目录：

用例设计

基本测试流程：

需求评审>测试计划>用例设计>用例评审>用例执行>缺陷管理>测试报告

一般地，先进行业务流程测试，然后才是单功能的测试。所以要先对业务流程设计测试用例，执行测试；在业务流程测试完毕后，再对单功能设计测试用例，执行测试...

业务流程测试

业务流程：客户使用软件的过程中，为了达成自身的所想要的目的，按照指定的顺序去操作软件的功能，这样的操作过程叫业务流程。
业务流程测试范围：核心业务流程
业务流程的来源：一般由产品提供，特殊情况由测试自己画业务流程
业务流程-测试用例设计方法：比如流程图法

单功能测试

单功能测试范围：

功能
非功能
1. UI界面（结合产品原型图所绘制的效果，检查实际UI界面是否一致）
2. 兼容性（Web兼容各种浏览器以及不同浏览器版本，比如：谷歌，火狐，IE等）
3. 易用性（站在用户的角度，测试软件易上手）
4. 性能
5. 安全
6. ……

单功能测试步骤：

熟悉需求
1. 需求来源：
  1. 需求文档
  2. UI/UE设计稿
  3. 已存在的软件界面（不一定有）
2. 熟悉需求的方式：
  1. 能够看懂理解文档描述
  2. 操作已存在的软件界面，能够构造除对应场景
3. 熟悉需求的程度：
  1. 能梳理出用户该功能，能够做哪些操作
  2. 能列出各模块下的功能点
用例设计（先提取测试点，后编写测试用例）

可以画思维导图分析测试点，同时利用测试用例设计方法，使测试点更完善

1. 测试点提取：
  1. 功能显示
  2. 功能操作
  3. 业务规则
2. 测试点设计
  1. 逐个分析测试点是否需要使用测试用例设计方法
  2. 用思维导图整理测试点
测试用例评审（查漏补缺，完善测试用例）
1. 评审的目的：
  1. 查漏补缺测试用例
  2. 与开发人员实现方案保持同步
2. 评审形式：
  1. 会议（一般由测试负责人发起）
  2. 交叉评审
3. 评审结果：项目组内一致认可的测试用例，将成为测试执行的最终版本
执行测试用例
1. 执行的时机：
  1. 在冒烟测试通过后
  2. 按照测试计划约定的时间
  3. 测试环境已经准备就绪
2. 执行用例方式：
  1. 逐条执行
  2. 按优先级执行（高的先执行）
  3. 按照模块重要性逐条执行
3. 执行结果记录：
  1. 测试通过-Pass
  2. 测试失败-Fail
  3. 测试阻塞-Block
  4. 功能缺失：N/A
记录缺陷，跟踪管理缺陷
1. 记录缺陷的要点：
  1. 缺陷要保证能够复现
  2. 一个缺陷对应一个Bug描述，不要出现重复
2. 跟进缺陷的要点：
  1. 每日跟进【缺陷管理工具】上的缺陷情况
  2. 优先级较高的缺陷要及时督促开发修复
  3. 目标：缺陷的修复速度，不能影响测试进度和上线时间
3. 回归缺陷：
  1. 对于【缺陷管理工具】上，缺陷的状态为已解决的缺陷，要进行再次测试验证
  2. 回归测试时，要保证测试环境是已提交的回归待测版本（已对缺陷进行整改过）

单功能-测试用例设计方法：比如等价类划分法，边界值分析法，判定表法，正交分析法等等...

用例编写的注意点：

1个测试用例尽可能多的覆盖多个正向测试点；
1个测试用例只能覆盖1个逆向测试点
用例编号：项目_模块_编号（注意：不要出现中文）
用例标题：测试目的-测试点（预期结果_测试点）
模块/项目：所属项目/模块
优先级：表示用例的重要性或影响力（P0~P4）
1. 业务场景-正向，P0
2. 业务场景-逆向，P1
3. 单功能-正向，p2
4. 单功能-逆向，p3
5. 其他，P4
前置条件：要执行此条用例，有哪些前置操作
测试步骤：描述操作步骤
测试数据：操作的数据，没有的话可以使用/表示空
预期结果：期望达到的结果

测试用例模板：

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

注意：

用例标题为：测试目的-测试点

先用流程图法设计测试用例（业务流程）

首先开展业务流程测试（业务流程对用户来说，是重要的）

注意：流程图法不需要深入功能内部进行详细测试，主要测试业务流程。

对于TPshop项目，有如下业务流程：

用户下单流程
商家发货流程
订单售后流程
……

商家发货流程，如下：

查看流程图，一共有3个判定节点，总路径数=3+1=4

画出思维导图，提取测试点

4条路径对应4条测试用例，测试用例如下：

用例编号	用例标题	模块	优先级	前置条件	测试步骤	测试数据	预期结果
TPshop_deliver_001	发货成功	发货	P0	1.存在待发货的订单001	1.卖家登录账户成功 2.订单审核同意 3.物流信息填写成功	卖家账号：xxx 卖家密码：xxx 订单号：001 审核：通过物流单号：xxxxx	提示发货成功；卖家订单列表，显示该订单已发货；买家订单列表显示该订单已发货
TPshop_deliver_002	发货失败-审核失败	发货	P1	1.存在待发货的订单002	1.卖家登录账户成功 2.订单审核失败	卖家账号：xxx 卖家密码：xxx 订单号：002 审核：不通过	发货失败；卖家订单列表，该订单显示已取消；买家订单列表，显示已取消
TPshop_deliver_003	发货失败-物流信息填写失败	发货	P1	1.存在待发货的订单003	1.卖家登录账户成功 2.订单审核同意 3.物流信息填写失败	卖家账号：xxx 卖家密码：xxx 订单号：001 审核：通过物流单号：空	发货失败；提示：订单物流号不能为空！
TPshop_deliver_004	发货失败-登录失败	发货	P1	1.存在待发货的订单004	1.卖家输入正确账号 2.输入错误密码 3.点击登录	卖家账号：xxxx 卖家密码：xxxxx(错误)	发货失败；请填写正确的用户名和密码！