目录[-]

目录：

  1. 一个全新的项目，如何开展测试工作
  2. 测试用例的设计方法
  3. 实战应用：登录功能测试用例设计
  4. 实战应用：微信支付功能测试用例设计
  5. 实战示例：真实项目的测试方法

——————————————————————————————————

1.一个全新的项目，如何开展测试工作？

接触到一个新项目，以前完全没有接触过的项目，那么测试人员如何上手？

 

答：测试需要对系统有一个整体认识，遵守：一个核心、四个阶段来进行测试工作

一个核心：业务需求（主）、用户体验

四个阶段：信息收集——》测试计划——》测试执行——》报告复盘

————

第一阶段：信息收集与分析

1.了解项目背景：

  • 这是什么类型的网站（电商、社交、企业官网、后台系统、SAAS服务）确定重点
  • 项目核心业务是什么？比如电商是“成功下单支付”、后台是正确查询和配置功能权限等
  • 目标用户是谁？测试以什么角度来看待项目，体验类问题是否受到重视等

2.获取需求文档：

  • 理想情况下，产品经理提供需求文档（详细解释每一项功能的作用）、UI提供UI设计图
  • 如果没有文档，而我又是新到这个项目组，需要找到做过这个项目测试的人员问清楚这个项目以前是怎么测试的，就算没有需求文档，也应该存在测试文档，不太可能出现“口口相传”的功能
  • 如果存在测试用例，则需要对照用例执行，熟悉项目

3.测试环境了解：

  • 是否需要测试部署测试环境，以前是怎么部署的？是测试拷代码后自己搭服务器验证还是有成熟的打版系统？数据库地址和对应账号密码等
  • 测试网址/app应用下载地址、安装方式等
  • 查看后端log的地址，软件finder可查看后台接口log
  • 测试账号获取
  • bug系统了解，是bugfree（bugzilla）、禅道、Jira，提交bug的规则是什么，比如按照什么格式书写等

4.技术栈了解：

  • 当前项目的前端框架如（Vue、React）、后端技术框架（Spring boot）、是否前后端分离、浏览器是否有要求、是否配置k8s、grafana等、存在几个环境等

————

第二阶段：测试计划于设计

基于收集到的信息，指定测试策略，规划测试范围和方法。

1.确定测试范围：

  • 分清主次，明确当前的重点是什么（比如，本次迭代更新一个订单流程，那么像登录、企业信息、余额查询等模块就处于次要位置）
  • 上下游关联，当前这个功能涉及到哪些模块，需测试它的上游功能

2.设计测试用例：

  • 等价类划分&边界值分析：常用的就是注册登录、搜索框查询等功能
  • 场景法：模拟用户真实操作流程（如：用户登录—》搜索商品—》加入购物车—》下单—》支付）
  • 因果图/判定表：处理复杂业务逻辑组合，如不同优惠券叠加等
  • 区分用途，主要是功能测试用例，当项目进行到中后期时，如果满足自动化条件，可逐步开始设计，再设计性能、安全、兼容性等测试用例

————

第三阶段：测试执行与探索

结构化测试（执行测试用例）和探索性测试结合。

1.功能测试：

  • 核心业务流程：主要功能
  • 其他业务功能：次要业务功能
  • 页面级测试：
    • UI/布局：对照UI设计图，检查布局、字体、颜色、对齐
    • 交互元素：如按钮、链接、下拉框、表单、弹窗、提示信息等
  • 接口测试：通过抓包工具，模拟接口请求，验证后台健壮性，比如越权访问、支付相关，这个可以发现深层BUG

2.兼容性测试：

  • 不同内核的浏览器（Chrome、Firefox、Safari、Edge）、不同分辨率测试

3.易用性/用户体验测试：

  • 操作流程是否易理解？
  • 引导、提示是否清晰
  • 是否存在不必要步骤
  • 整体是否友好，比如要做一件事情需要用户自己做20步才能让流程结束

4.初步性能与安全冒烟测试：

  • 性能：
    • 简单关注页面加载时间、图片资源大小、滚动、翻页、切换企业等是否卡顿
  • 安全：
    • 修改URL参数尝试越权，比如当前自己的订单路由是：/order/123，改成其他数字，能否访问他人订单
    • 涉及金额的方面，比如余额提现，尝试提现大于余额的数字

5.记录Bug：

  • 发现bug的通用记录方法
    • 标题：描述bug现象
    • 环境：什么环境发现的（测试/生产）
    • 步骤：清晰、可复现、详细具体
    • 预期结果、实际结果
    • 附件：截图、日志、视频等证据
    • 严重等级&优先级
      • 默认从A到D，A最重要，比如主流程阻碍测试、没有调用支付功能、下单失败等

6.里程碑记录：

  • 使用甘特图记录测试进度，如果多人协作更需要记录每个人正在进行什么操作、已经完成什么测试、下一步要做什么测试、当前遇到的阻碍等，便于统筹规划

————

第四阶段：报告与复盘

1.测试报告：

  • 在一轮测试结束后，编写测试报告、总结测试进度、Bug数量、遗留问题、风险评估和建议（如当前质量是否满足发布版本）

2.回归测试：

  • bug修复后，回归已有功能，不止是当前bug，在上线前，需对整体流程再做一次回归测试

3.复盘总结：

  • 本轮测试可优化的地方，哪些地方Bug最多，哪个开发的功能不稳定，后续如何改进测试策略。

————————————————————————————————————

2.测试用例的设计方法

在设计具体测试用例前，脑子里需要有这些理论基础，它们是生成测试用例的“武器库”。

1.等价类划分

  • 概念：将输入数据分为若干组，同一组的数据在测试中是等价的，只需选取有代表性的一组作为输入。
  • 示例：用户名长度规定在6-18位
    • 有效等价类：【6-18】位的任意一个长度，如12位
    • 无效等价类：长度<6，长度>18，特殊值：0

2.边界值分析

  • 概念：对输入或输出的边界值测试
  • 示例：
    • 最关键的：长度=6、长度=18
    • 次要关键的：长度=5、7、17、19，其中5和19，是无效等价类，其余是有效等价类

3.因果图/判定表

  • 概念：适用于处理多种输入条件组合对应不同输出结果的逻辑
  • 示例：登录功能中，“记住密码”复选框、“自动登录”复选框的不同组合，浏览器通常会在用户输入账号密码登录时，提示保存密码，这里要注意，需要删掉浏览器存储的账号密码再进行测试，否则每次使用的是浏览器的表单，另外，需清除缓存测试

4.场景法

  • 概念：模拟用户真实操作流程，关注主流程和异常场景
  • 示例：
    • 主流程：输入账号—》输入密码—》点击勾选用户协议—》点击登录—》成功登录
    • 异常场景：输入账号—》点击登录—》提示：请输入密码/账号密码不能为空

5.错误推断法

  • 概念：基于经验推测程序可能出错的位置
  • 示例：
    • 输入密码时复制粘贴
    • 输入账号密码时首尾带空格
    • 连点登录按钮

————

3.实战应用：登录功能测试用例设计

综合运用以上方法，从不同维度设计用例。

1.UI界面测试

  • 布局、字体、颜色、对其方式，是否符合设计原型
  • 输入框：placeholder 文字是否正确
  • 按钮默认勾选状态、选中状态是否正确
  • 不同浏览器的兼容性是否正常

2.功能测试-输入框校验（等待类+边界值）

  • 用户名/邮箱框：
    • 输入已注册的有效用户名/邮箱+正确密码——》登录成功
    • 输入未注册的用户名/邮箱——》提示：用户名/密码输入错误
    • 输入超长字符串——》前端限制可输入长度，如果未限制，就是bug
    • 输入为空——》提示：用户名/密码输入错误
  • 密码框：
    • 输入正确密码——》显示为星号
    • 输入错误密码——》提示：用户名/密码输入错误
    • 输入为空——》提示：用户名/密码输入错误
    • 点击“显示密码”图标，密码从密文变成明文显示

3.功能测试 - 主要功能与交互（场景法+判定表）

  • 核心成功场景：输入正确用户名和密码，点击登录—》跳转到指定页面（如首页）
  • 核心失败场景：输入错误用户名或密码，点击登录—》提示错误信息
  • “记住我”功能：
    • 勾选后登录成功，关闭浏览器再打开，用户名/密码是否自动填充
    • 不勾选后登录成功，关闭浏览器再打开，用户名/密码是否为空
  • “忘记密码”链接：点击后，是否正确跳转到密码重置页面
  • 并发与网络：
    • 快速连续点击登录按钮—》系统只处理一次请求（防连点）
    • 登录过程中断网—》请求超时/网络异常提示

4.安全性测试：

  • SQL注入：在用户名输入 ' or 1=1 --   查看系统是否被攻破
  • XSS攻击：在输入框输入 ''   查看提交后脚本是否被执行
  • 密码传输：抓包工具检查密码是否加密传输（不能明文传输，需要是HTTPS请求）
  • 接口返回：关键用户信息需加密回显，如账号名、手机号、密码等
  • 错误信息提示：提示信息是否过于详细，如：用户名错误/密码错误，应统一提示“用户名/密码错误”，防止黑客枚举用户名
  • 登录次数限制：一段时间连续输错5次密码后，账号是否锁定一段时间

5.兼容性和性能

  • 兼容性：在不同浏览器（Chrome、Firefox、Safari、Edge）和不同设备上测试登录功能
  • 性能：登录接口的响应时间应在合理范围内（如<2秒），首页加载时间（如<5秒）

—————————————————————————————————————

4.实战应用：微信支付功能测试用例设计

支付功能调用第三方应用接口，测试需更加严谨，核心功能是流程和状态

1.核心正向流程（场景法）

  • 正常支付成功：用户扫码—》输入密码—》支付成功—》页面跳转—》订单状态更新为“已支付”—》用户端提示支付成功页面
    • 关键检查点：金额一致、状态同步、通知及时

2.异常和边界流程（场景法+错误推断法）

  • 支付中断：
    • 扫码后，在输入密码前杀进程/断网—》重新查询订单，订单仍处于“未支付”状态，可重新支付
    • 输入密码后，等待回调时杀进程—》通过查询机制确认最终状态，并更新本地和客户端
  • 支付失败：
    • 余额不足—》支付失败
    • 输入错误密码—》提示密码错误，支付失败
    • 支付超时（给本地网络添加延迟和丢包）—》支付成功后查询状态变化
  • 金融边界：
    • 支付 0.01 元（最小单位）
    • 支付最大金额（如企业付款/提现上限）
    • 支付金额带小数（如 100.99 元）
  • 重复操作：
    • 保存支付二维码，成功扫码支付一次后，再次扫描二维码—》提示订单已支付完成，不可以重复支付
    • 连点问题，支付时，连续点击付款/支付/提交按钮—》只能支付1次

3.状态一致性测试（核心）

支付测试的重点，要验证在任何异常情况下，用户、商户、微信支付平台，三方的数据状态保持一致。

  • 网络超时/中断模拟：使用抓包工具如 Charles 模拟弱网、断网、丢包场景，在支付的各个阶段，如：生成订单、发起支付、输入密码、等待回调，进行干扰，检查后续订单一致性
  • 回调处理：
    • 模拟成功回调：实际未付款，向商户服务器发送一个伪造的成功通知，查看是否更新状态（安全漏洞）
    • 模拟回调失败：微信服务器通知商户失败后，是否有重试机制

4.安全测试

  • 金额篡改：抓包并修改支付请求中的金额（如将100元，改成1元），查看后端是否校验最终支付金额的一致性
  • 订单信息篡改：篡改订单号，支付A订单的请求去支付B订单
  • 反洗钱：测试大额支付，是否有人工审核或风控拦截

5.兼容性与性能

  • 兼容性：在不同手机型号、操作系统版本上，测试微信支付SDK调起、显示和支付流程
  • 性能：在并发场景下（如秒杀），支付接口的响应时间和成功率

总结：

对于登录，测试重点是输入校验、安全性和交互。

对于支付，测试重点是状态、流程、数据的一致性。

————————————————————————————————————

5.实战示例：真实项目的测试方法

现在有一个web网站，url是：https://management.airtimes.com.cn/

前提条件：

  1. 清空浏览器缓存，使用“360极速浏览器”打开网站
  2. 使用windows系统，计算机配置是标准的8G内存，50G硬盘，4核CPU
  3. 本地网络下载速度，大约1MB/S
  4. 没有任何测试需求文档，没有任何测试用例

测试步骤：

  1. 功能测试，设计测试用例
    1. 页签title，显示：艾尔企业管理
    2. 缓存为空时，默认显示：手机号码、密码输入框是空的
    3. placeholder显示，手机号码输入框，显示：请输入手机号码；密码输入框，显示：请输入密码
    4. 红字提示：手机号码输入框未输入时，提示“请输入正确的电话/手机”；密码输入框未输入时，提示“请输入密码”
    5. 手机号输入框，输入10、12位纯数字，提示“请输入正确的电话”
    6. 手机号输入框，输入11位纯数字，没有红字提示
    7. 密码输入框，输入任意位数任意字符，没有红字提示
    8. 密码输入框，输入时默认显示密文形式
    9. 明文密文切换按钮，点击后，将密文显示成明文；如果当前是明文，点击后，显示成密文
    10. 输入11位手机号，任意位数密码，点击登录，提示：账号或密码输入错误，请检查后重新输入
    11. 输入正确的11位手机号、密码，点击登录，提示：登录成功，页面跳转到首页
    12. 点击右上角二维码图标，切换到“二维码登录”页面
    13. 二维码登录页面，查看扫描二维码后，能否通过APP进入页面
    14. 二维码登录页面，二维码有效期、倒计时相关测试，二维码状态每隔5秒校验一次有效性，当倒计时结束，不再校验二维码准确性，当前二维码失效，点击刷新按钮后，二维码切换并重新倒计时
  2. UI测试与兼容性：
    1. 浏览器100%分辨率，查看整体UI显示是否正确
    2. 调整浏览器分辨率，如90%、120%等，查看UI缩放放大等情况
    3. 打开F12，查看footer文字显示
    4. 使用不同浏览器，查看UI样式问题

总结bug

  1. 手机号输入框：红字提示错误，现在提示的是“请输入正确的电话/手机号”，电话和手机号是完全不同的两回事，这个系统只能识别11位中国手机号，小于11位、大于11位都会给出错误提示，那么这个提示语就是错的
  2. 手机号输入框：前端未做长度校验，现在可以输入大于11位的手机号；前端未做可输入字符限制，不论是纯数字、字母、标点符号都可以输入，非常不严谨
  3. 密码输入框：前端未做长度校验，现在可以输入超过50位的密码，不合理
  4. 文字的一致性bug：文字title显示“账号密码登录”，但是输入框却显示“手机号码”，现在这个输入框已经有3个称谓了“电话、手机号、账号”
  5. 缩放bug：当分辨率小于/大于100%时，背景图片缩放问题，没有填充整个页面，如图，一看就不正常
  6. 页面拉伸bug：当打开F12后，页面footer文字没有等比例缩放，而是往上占用拉伸了，如下图
  7. 使用不同浏览器，就是使用100%分辨率， 兼容性也是有问题的
  8. 性能bug：清空缓存到加载DOM结构，用了整整36s之多，下面详细解释这个bug

DOMContentLoaded：2.1分钟，用户将要在2分多钟面对这个大白页，缺少loding。这个指标，意思是：浏览器花费了2分多钟才完成HTML文档的解析和同步脚本的执行。

加载时间：2.1分钟，在2.1分钟时，页面上的初始资源如图片等才加载好，用户才可以操作，页面刚刚可用。

完成时间：所有后台任务（数据分析、异步请求）最终完成的时间。

————

做一个比较，打开厦门航空网址：https://www.xiamenair.com/zh-cn/，对照加载时间

厦门航空这个DOMContentLoaded时长是8.23秒，也就是说，用户在等待8秒就可以进行交互，其他的静态资源、懒加载的脚本如广告、埋点统计等可以慢慢加载，核心功能已经可以使用了。那么问题来了，你这个后台应用管理的登录页面，是怎么做到比航空加载还要慢的。

        10.接口bug：进入页面时，会发现一直在调用status接口，这个是二维码轮询接口，问题是，默认进入的是“账号密码登录”页面，为什么要加载二维码登录相关的接口？触发时机不对，应该是用户切换到二维码登录时（按钮触发事件）

      11.安全bug：登录接口入参，明显没有将密码做成密文，这样会造成密码泄露

        12.footer位置的“用户服务协议”、“隐私政策”，是文字显示的，并没有点击跳转功能（不是文字超链接），很明显不符合一个企业级应用的规则。

        13.使用微信、浏览器扫描二维码，返回一串字符串，缺少友好的提示（使用对应APP扫描可以成功登录）

 

END