AI测试电商项目

【黑马程序员AI测试电商项目零基础入门到通关全套视频课程，从黑盒测试到AI Agent自动生成用例，AI赋能实战电商项目全流程测试】https://www.bilibili.com/video/BV19Jc6zREyd?p=2&vd_source=b0ea651d3ca7dbb50ab7d09d807bb409

一、如何高效使用AI

1、常见AI工具选型

• 文档处理
  • 豆包:https://www.doubao.com/chat/
  • Deepseek: https://chat.deepseek.com/
  • Kimi: https://kimi.moonshot.cn/
• 代码处理
  • 通义千问:https://tongyi.aliyun.com/qianwen
  • 讯飞星火:https://xinghuo.xfyun.cn/desk

2、指令典型格式

• 角色(身份) : 你是谁? 比如:[你是测试工程师]
• 指示(任务) : 要干啥? 比如:[分析登录功能需求]
• 输入(要求) : 啥要求? 比如:[要求:账号:必填，已注册的合法手机号，密码:必填，和注册密码一致]
• 背景(当前状况，可选) : 比如:[当前用户对软件测试不熟悉]
• 输出(结果) : 想要啥? 比如:[将补充完善后的需求以md形式输出]
• 参考(示例，可选) : 模仿示例?[按照你提供的示例输出更贴近自己要求]

3、实例

1、提示词分析:

• 身份:你以资深导游的身份
• 任务:制定一份北京冬季旅游计划
• 要求:时间是3天，覆盖重要景点，住宿价格相对合理，路程占用时间较少，景点游玩时注意事项等输出:以md格式输出

2、提示词分析:

• 身份:你以软件开发者的身份
• 任务:使用Python语言实现“掷骰子”的游戏
• 要求:支持人机对战，回合数不限
• 输出:可执行的代码文档

4、个人实操

​个人实操

​

计科生每日学习计划.md

</details>

二、软件测试相关概念

part1 软件测试基础介绍

一.认识软件测试

• 软件测试: 通过技术手段运行软件是否满足需求过程
• 目的: 减少软件缺陷(bug)，保障软件质量！

二.软件测试技能

• 功能测试: 功能测试主要验证程序的功能是否满足需求
• 自动化测试: 使用代码或工具代替人工验证项目功能
• 接口测试 : 针对模块与模块或系统与系统之间数据交互的测试
• 性能测试 : 模拟多人使用软件，查找服务器缺陷就业方向该如何选择? 1.方向(一):功能测试+接口测试 2.方向(二):功能测试+UI自动化 3.方向(三):功能测试+性能测试 4.方向(四):功能测试+接口测试+性能测试 5.方向(五):功能+UI自动化+接口+性能测试

三.软件测试分类

应用场景 : 面试中被面试官问到或者提到

3.1按照阶段划分

• 单元测试 : 对于开发的源代码进行测试 [一般由开发做]
• 集成测试 : 也叫接口测试、组装测试,测试系统和系统,模块和模块之间数据交互(能否正常使用) [一般由测试人员做]
• 系统测试 : 也叫功能测试.测试整个软件产品的功能能否满足需求(包含兼容,文档等测试) [一般由测试人员做]
• 验收测试 : 模拟用户验证是否满足用户的需求(分为内测和公测) [一般由用户/用户代表做]
  • 内测：alpha测试 –> α
  • 公测：beta测试 –> β
  • 候选版：gamma测试 –> γ

3.2 按照代码可见度

• 黑盒测试 : 看不到源代码,进行功能级别的测试 （源代码不可见、UI功能可见、只关注数据输入结果输出）
• 灰盒测试 : 部分代码可见,相当于做接口测试 （部分代码可见，UI功能不可见、关注输入输出+部分代码逻辑）
• 白盒测试 : 通过源代码测试源代码(单元测试)（源代码可见、UI功能不可见、只关注代码本身语法逻辑）

3.3 其他测试

• 冒烟测试：对核心功能的验证
  • 作用：保障提测内容具备可测性
• 回归测试：
  • 1、对已修复bug/更新后bug再次测试验证
    • 作用：保证bug修复，符合预期结果
  • 2、已更新的新需求对已测过的功能没有负面影响
    • 作用：保证确保新功能对旧功能没有影响（无副作用）

四、质量模型

衡量一个优秀软件质量的框架 作用：确定测试覆盖的范围和重点

• 1.功能性:能不能
• 2.性能:响应快、占用资源少
• 3.兼容性:不同设备平台正常使用
• 4.易用性:用户体验好
• 5.安全性:敏感信息无泄密存储有保障
• 6.可靠性:持久运行无异常
• 7.可移植性:升级迁移方便
• 8.可维护性:出现异常易修复

part2 测试用例设计方法

一、等价类划分法

• 场景：表单类型的页面进行测试时使用，解决少量数据覆盖全量全部数据测试场景问题。
• 步骤：
  • 明确需求：目的、条件
  • 按每个条件划分等价类：有效、无效
  • 根据有效无效组合梳理测试点
• 注意事项：
  • 有效：所有条件都有效【测试点数看单条件有效的最大数】
  • 无效：只要有一个条件/一个项无效即可【测试点数就是每个无效类的和】
• 案例：1:验证QQ登录功能 要求: 1.账号:6~10位自然数且已注册(非空) ​ 有效：已注册账号 无效：小于6位、大于10位、非自然数、未注册、空 2.密码:正确/错误/空 ​ 有效：正确 无效：错误、空

二、边界值分析法

• 场景：针对边界范围的数据进行测试时使用
• 步骤：
  • 明确需求：目的、条件
  • 按每个条件划分等价类：有效、无效
  • 确定边界范围值：上点、离点、内点【和步骤2合并】
  • 根据有效无效组合梳理测试点
• 注意事项：
  • 需要有边界范围
  • 离点可以优化【开区间选择内部离点测试、闭区间选择外部离点测试】
• 案例：
  • 需求:计算器功能测试，如果输入的数字大于等于-99同时小于等于99整数时，求和成功;

三、判定表

判定表的介绍 定义:是一种以表格形式梳理多条件组合逻辑判断的工具。作用:理清复杂逻辑，解决条件组合测试的混乱问题。

• 组成:
  • 条件(桩):列出问题中的所有条件，列出条件的次序无关紧要。
  • 动作(桩):列出问题中可能采取的操作(可以有多个)，操作的排列顺序没有约束。
  • 条件(项):列出条件对应的取值，所有可能情况下的真假值。
  • 动作(项):列出条件项的、各种取值情况下应该采取的动作结果。
• 应用场景:针对规则的验证
  • 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约/因果)关系
  • 适用条件个数不宜过多(不超过4个，如果超过建议使:用因果图法)
• 使用步骤
  • 1、明确需求
  • 2、画出判定表
    • 1)、列出条件(条件桩)和结果(动作桩)
    • 2)、填写条件真假取值(条件项)，并进行全组合
    • 3)、根据每组取值确定组合结果(动作项)
  • 3、根据规则编写测试点

四、流程图

• 说明：用流程图表示业务流程，测试每条路径。
  • 业务：指软件为满足用户特定的业务员需求而设计并实现的一系列功能（组合）
  • 示例：电商app下单业务（登录→搜索→添加购物车→下单→支付）

part3 测试执行入门与进阶

一、测试用例

1、什么是用例

• 用户使用的操作案例（手机验收）
  • 是否能开机、验证内存、验证屏幕、检查运行速度

2、什么是测试用例

• 为特定测试目的而设计编写详细的可执行文档

3、为什么要写测试用例？

• 防止漏测
• 规范实施测试过程，提升效率
• 测试人员工作量化的一种体现

4、测试用例编写内容说明

• 用例编号：项目模块编号（英文简称）
• 用例标题：测试点（覆盖某个特定目的功能点概述）
• 模块/项目：所属项目或模块
• 优先级：表示用例的重要程度或者影响力p0~p4（p0最高，为最核心用例）
• 前置条件:(没有它无法进行)要执行此条用例，右哪些前置操作（非必填）
• 测试步骤：描述操作步骤（怎么执行的过程）
• 测试数据：操作的数据，没有可为空
• 预期结果：期望达到的结果（对应标题结果）

5、如何编写测试用例

• 1、分析需求明确测试目的（要验证什么/干什么？条件有哪些？）
• 2、基于需求条件覆盖各种可能场景（梳理测试点）
• 3、按照用例模板编写文档（转测试用例）
  • 人工编写（首次）
  • AI生成
    • 使用智能体直接生成用例【比大模型更直接简单】 https://www.coze.cn/store/agent/7566286095323807794?from=bots_card&bid=6iq4k71g07g0r

二、用例执行准备

• 说明:软件测试需要通过技术手段运行软件找出软件缺陷的过程
• 执行步骤:
  • 搭建测试环境(测试/预生产环境)
  • 执行冒烟测试(验证主流程)
  • 按照用例步骤执行，并记录实际结果
• 环境扩展
  • 测试环境:被测项目运行所需要的硬件和软件的集合
  • 环境分类:开发环境(开发用)、测试测试(测试用)、生产(用户用)
  • 环境搭建人员:一般是运维、开发，最后才是测试人员
  • 如何搭建:需要按照环境搭建文档进行安装及配置(一般服务器涉及Linux操作系统应用)
• 执行准备
  • 已完成测试用例
  • 已经有可运行的测试环境【运维搭建】—> 测试是否具备搭建环境的能力？
  • 先进行核心业务流程的冒烟测试【正向用例】
  • 再进行其他功能模块及业务的用例执行，做好记录
    • 执行结果：pass（通过）、fail（失败）
• 扩展：测试环境
  • 本地测试环境：测试人员自己用
  • 预生产环境：所有测试人员上线前都能使用

三、测试执行

part4 软件的缺陷及管理

1、缺陷(bug)的定义

• 软件在使用过程中存在的任何异常问题都叫软件的缺陷，简称bug。
• 软件的缺陷导致软件无法正常运行，无法满足用户需求或产生不符合预期结果的情况。

2、缺陷如何判定(判定标准)

• 软件未实现需求功能->少功能
  • 例如:某社交APP不支持文字信息的发送
• 软件实现了超出需求范围的功能->多功能
  • 例如:某社交APP除了消息发送功能，还有数学计算功能
• 软件实现了错误的功能->功能错误
  • 例如:某电商APP下单时，对于有折扣的商品价格并没有按照折扣价计算
• 软件未实现隐形功能->隐性功能错误
  • 例如:某社交APP输入消息时，只支持九宫格输入法，不支持手写输入
• 软件的用户粘性不好->体验不好
  • 例如:某社交APP运行特别缓慢，并且发送消息操作过程复杂，用户使用感到迷茫

注意事项:

• 标准1、3严重，标准4中等级别，
• 标准2、5中下级别，标准2几乎不出现

3、缺陷报告标准

1、（前置）用例执行步骤

• 待测用例：准备待测试用例，最后添加一列执行结果
• 待测软件：开发提测后，运行待测软件
• 判断结果：判断实际结果是否和预期一致，一致测试通过（pass），不一致提交缺陷报告

2、缺陷报告构成核心要素

• 缺陷的标题
  • 描述缺陷的核心问题测试条件+实际结果（预期结果）
• 缺陷的预置条件
  • 缺陷产生的前提
  • 和用例预置条件一致
• 缺陷的复现步骤
  • 浮现缺陷的过程
  • 测试步骤+测试数据
• 缺陷的预期结果
  • 希望得到的结果
  • 和用例预期结果一致
• 缺陷的实际结果
  • 实际得到的结果
  • 和用例预期结果不一致
• 缺陷的必要附件
  • 图片、日志等信息（证据）
  • 该项可选

3、缺陷的其他要素

• 缺陷标号：
  • 缺陷唯一标记
  • 工具提交自动生成
• 严重级（S）：
  • 阻塞(Blocker):功能无法使用
  • 致命(Critical):致命的，核心功能无法使用
  • 严重(Major):严重的，部分功能不可用
  • 一般(Normal):一般问题，影响不大
  • 微小(Trivial):微小问题，不影响使用，体验不好
• 优先级（P）：
  • P0:2小时内修复
  • P1:当日内修复
  • P2:3天内修复
  • P3:周内/本版本内修复
  • P4:后续版本修复
• Bug类型：
  • 功能问题:代码错误、逻辑异常、设计缺陷、数据问题等
  • 兼容性问题:部分载体有异常
  • 性能问题:并发、压力、负载异常等
  • 易用性问题:体验不好
  • 其他问题:架构、环境等
• 缺陷状态：
  • 新建(new)
  • 打开(open)
  • 已修复(fixed)
  • 已关闭(closed)
  • 延迟 (delayed)

4、缺陷的跟踪流程

目的:搞清楚工作中如何和开发协同处理bug，直到bug清除(关闭)

5、缺陷报告编写规范

• 准确
  • 描述的信息是正确的。
• 简洁易懂
  • 描述简单容易理解。
• 具体
  • 有细节且是真实特定的。
• 次序清晰
  • 描述缺陷过程有条件，有先后顺序。

6、提交缺陷注意事项

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

4、【扩展】缺陷(bug)不可复现怎么办?

• 1、从严重级出发，严重级低，暂时可以不考虑(后续尝试复现);严重级高，需要分析排查
• 2、思考自己测试过程，是否和设计步骤，思考测试环境
• 3、寻求协助:测试老员工，开发协助(记录出现问题的时间，查询对应时段的日志，分析日志)
• 4、如果没有日志，需要开发给一个有调试日志的版本，后续连续跟踪三个版本后，再未复现，此时放弃
• 5、后续版本再次出现，直接转/提正式bug，详细描述你的复现过程

三、项目实践

1、测试设计

参考课堂xmind

• 核心业务：基于业务流程图设计
• 单模块前提：需求/UI原型
  • 功能：显示+操作
  • 非功能：兼容、易用、性能、安全

2、测试报告

标志：测试活动结束

作用：对于产品质量的详细的说明和总结（评估）

编写人：领导给模板，其他测试人员填写内容 （可借助于AI）

借助于AI生成，参考指令（提示词）如下：

• 示例你以软件测试工程师的身份，帮我编写电商项目的测试报告
  要求：
  1.报告内容：项目概述、过程回顾、统计分析、结果确认、总结改进
  2.项目概述：基于B/S架构的电商项目，主要用户有普通用户、商家、管理员等；其中核心业务包含下单购买业务、商家发货业务、用户售后业务等；包含的核心模块有登录、搜索、购物车、下单、支付、发货等
  3.过程回顾：总共3个测试人员，持续时间3个月，电脑3台，手机若干；主要负责测试功能
  4.统计分析：总共编写800条用例，发现bug 24条，其中中等级别占比约70%
  5.结果确认：能否正常发布，是否符合上线条件
  6.总结改进：过程中好的地方保留，不好的地方改进
  输出一份md格式的文档