功能测试核心流程标准化

功能测试流程标准化

一、需求评审

1.1 理解需求

1）来龙去脉

这个需求是干嘛的？
解决了什么问题？
为什么有这个需求？
比如为什么有了老版本的公告后台，还要搞个“组织自运营”？

这个是最先要弄清楚的，明确要做的事，知其然且知其所以然，这是根源。

2）宏观流程

需求的完整运转，需要哪些环节？哪些平台？
比如租户平台、公告发送后台、公告审批的平台、涉及的端

3）微观细节

看需求文档

结合 上对应的平台和端上实操下，实践出真知

1.2 评审需求

1）未明确的点

明确需求中未明确下来的细节点

2）缺陷、风险

缺陷和风险越早发现越好。
可以有多早？在评审需求阶段就发现！

如果把流程形象化 从左到右 > ，那这一步也叫“缺陷左移” <
能在上游、来源解决问题的话，那下游最轻松。

二、评估工时

在需求评审完后，就需要评估工时了。
工时的基本单位是 人日，即 一个人干一天，一天按8小时算。

2.1 新功能需求

一般为：该需求的所有开发工时累加 / 3 = 测试工时

2.2 回归类需求

这类需求的来源：
● 开发修复了前面迭代later下来的bug
● 开发进行了优化（性能优化、代码结构优化等）

这类需求一般不需要设计新用例，根据以往经验评估：
回归完需求涉及的用例范围需要的工时
2.3 适配修正
工时要根据适配范围进行适当修正

三、测试分析 => 测试方案设计

3.1 用例设计的局限性

1）不直观

这个阶段，新功能都还在开发中未提测，测试对“待测物”没有一个直观的感受。
哪怕需求PRD文档写的再详细，那也是站在产品的视角进行的描绘，且是静态无交互的，遗失大量细节。

2）表达偏差、理解偏差

而且可能还存在一些偏差：
● 产品的“理解偏差”、“表达偏差”
● 开发的“理解偏差”、“编码偏差”
● 测试的“理解偏差”、“测试偏差”
导致上下游整体存在比较大的偏差。

这时去设计步骤和期望都明确的用例不太现实，没什么意义，后面大概率要进行修正、徒增测试的无效劳动。

3.2 能做什么？XMind测试分析

测试分析需要梳理以下几方面
● 新功能点
● 细化适配范围
● 测试资源准备
● 在梳理的过程中，很可能还会产生新的问题
在这几方面梳理好后，就形成了基本的 测试方案 了

四、测试方案评审

4.1 测试团队内评

● 让大家都了解新功能，便于后面的交叉测试
● 集思广益查漏补缺
● 整理好大家的问题

4.2 产品开发外评

● 修正测试团队的理解偏差
● 进一步 集思广益查漏补缺
● 问题答疑

4.3 设计冒烟用例、交给开发

● 作为开发提测前自测的冒烟用例
● 也是测试进行冒烟打回的用例依据

五、关注开发提测情况

5.1 测试明确“预计提测时间”

每个aone需求都有对应的“预计提测时间”，如果没有，则让这个需求的负责人补充。

需求的负责人一般为指派人

这个“预计提测时间”很重要，因为后续的所有环节排期都是根据这个来排的。

5.2 开发提测现状

按“预计提测时间”，可以分三种情况：
● 提前提测
○ 新功能型需求基本不太可能，目前还未见到
○ 因为大部分需求都是一环扣一环，“木桶原理”，如果其中一环慢了，别的环节开发好了也用不了，只能等最慢的那一环也开发好了、联调通过后，才能将这个需求整体上线
● 准点提测
○ 一般为该天下午或晚上提测，当天基本也没什么测试时间了。一般为次日开始进行冒烟测试
● 延期提测
○ 真实的提测时间以定坤上的提测单日期为准
○ 由于开发提测delay，测试的周期也整体等额顺延

开发提测会有以下几种异常情况：
● 开发到了“预计提测时间”还未开发好，也就是上面说的“延期提测”。
● 开发人员已经开发好了，但是不清楚提测流程或者忘记了提测。
● 开发提测了，但提测单未指派全测试，或者提测单指派的测试指派错了。

5.3 测试应对

在新迭代开启后
● 在 “预计提测时间” 之前
○ 每天刷新一次定坤提测单，查看是否有指派给自己的提测单
● 在 “预计提测时间” 当天 及 之后
○ 同上（之前）
○ 如果还是没提测，提醒开发
○ 如果提测了，但由于提测不规范导致测试查不到提测单，则反馈开发按规范来补充正确的提测单
■ 例如“公告”和“工作通知”相关的提测单按规范是要提给
● 特殊场景
○ 某个需求提测涉及多个模块，但是开发只提测给我们部分模块的测试同学
■ 收到提测单的同学需要同步下别的涉及模块测试负责人

六、提测后，集成测试前

6.1 冒烟测试

1）核心链路冒烟
特点：
● 快
● 核心链路
○ 先不关心边边角角的细节
○ 先不测反向“骚”操作，只测正向链路
● 提测准入标准
2）冒烟是否通过
标准：
● 核心链路是否能走通、是否阻塞测试
● 可参考发给开发的冒烟用例

综合考量：
● 冒烟打回
○ 在流程上对测试稍显繁琐
○ 可能对开发的绩效不利
● 如果提测质量太差、符合冒烟打回标准，但不打回
○ 加大测试负担
○ 变相压缩了测试周期
3）冒烟结果及处理流程
● 冒烟通过
○ 定坤提测单冒烟状态改成“通过”
○ 进入“新功能测试”阶段
● 冒烟不通过
○ 先反馈开发，测试阻塞了，需尽快解决！
■ 同时Aone上报bug，作为后续冒烟打回的事实依据
■ 缺陷标准（含缺陷状态标准）
○ 如果开发解决了阻塞问题，让测试能在1天内完成冒烟测试，则“冒烟通过”，后续处理同上
○ 如果开发无法及时解决阻塞问题，让测试在1天内完不成冒烟测试，则“冒烟失败”
■ 冒烟打回，定坤提测单冒烟状态改成“失败”
■ 发冒烟失败的邮件给对应的交付、产品以及开发，说明详细情况

6.2 新功能测试

这个阶段的重点、要保质保量完成：
● 全面测试新功能
● XMind测试方案 => TC(测试用例)
● 这个阶段千万不要做过多的回归，没意义。要把有限的精力花在“刀刃”上

1）新功能摸底、发散、修正

过程：
● 以XMind测试方案上所列的新功能为核心
○ 优先测试核心功能，边界发散性的操作次之
● 进行系统性发散
○ 借鉴移动端测试角度、打开测试思路
● 修正对新功能的理解
○ 纠正部分错误认知
○ 扩大细节认知

结果：
● 上面3点为过程，结果记录(/修正)在XMind测试方案中，作为用例化的依据
● 测试期间发现的bug及时在Aone上按标准记录

2）测试方案用例化

边测边XMind用例化：
● 建议将原XMind测试方案（新功能概要）保留，单独新建一份用例化XMind
● 将测试期间的必要操作步骤、相应期望结果，尽可能详细地记录在用例化XMind中
○ 关于期望结果，不要只关注单个端或单个平台，需要以完整的链路角度将平台和端串联起来看
○ 请务必将步骤和期望写的详细点，特别是花了大量时间成本反复沟通、评审后才弄清楚的模糊点、细节点，此刻不记，以后忘得一干二净将之前的努力付诸东流，多可惜～ 而且没测过的同学就更不清楚了，还怎么交叉测试、在节奏紧的情况下如何让别人支援你测试？
● 用例化XMind编写标准参考

3）XMind用例导入Aone

在新功能测完且XMind用例编写完后，要将XMind用例导入到Aone.

如果对XMind用例导入Aone不熟（怕破坏现有用例集结构），可以先在下面这个Aone下练练手：
“测试aone本身的功能用法”这个aone项目可以随便折腾研究增删改操作～

具体导入到《004.迭代版本增量用例》中，例如：

建议导入后，仍将XMind用例保留（作为一种备份）

4）用例维护，持续不间断！

在XMind用例导入到Aone后，可能还会有小幅维护。
从维护类型划分，有 增（补充用例/步骤/期望）/删（合并/无效）/改（描述）。
从维护来源划分，有 自己维护/他人维护。

维护：
● 所以从协同角度看，维护阶段建议直接在Aone上维护《004.迭代版本增量用例》。
○ 需要考虑他人贡献的用例
● 在迭代交付后，进行归档，将《004.迭代版本增量用例》中的用例全量复制合并进《001.回归测试checklist》。
○ 这样只需要维护一处《004.迭代版本增量用例》，不用同时动态维护第二处《001.回归测试checklist》
● 其他文件夹不需要维护，减轻负担，比如《000.全量用例》。
○ 意义不大的事不用做，优化掉
● review Aone上现有的缺陷列表，进行用例补充
○ 有些缺陷很可能还是靠纯发散测出来的，并不是根据用例测出来的，对于这类缺陷需要反向补充用例

意义：
● 《004.迭代版本增量用例》是补齐版的来源依据
● 《004.迭代版本增量用例》+《001.回归测试checklist》是交叉测试、集成回归测试的来源依据
● 用例是测试资产、是将测试期间发散出来的宝贵探索及时记录下来，按用例测可以保障不漏测的情况下尽可能提高测试效率
○ 提高测试效率：纯发散的测需要花时间重新思考
○ 提高测试覆盖率：纯发散的测不一定测的全
○ 降低同学间业务学习成本：用例相当于是个产品简易操作文档

6.3 少量 适配 + 交叉

秉持缺陷左移、尽早发现的思想，在进集成测试前，还需要进行适当的适配测试和交叉测试。
● 适配测试按测试方案中涉及的适配范围来
○ 主要按现有用例来测，加快适配速度
● 交叉测试就是让别的同学来测，以便更好的发散，挖掘前一位同学的思维死角
○ 可以适当的脱离用例束缚来更好的发散
○ 如果发散期间测出bug，且该发散操作没有对应用例，则需要反向补充用例
● 记得现有缺陷的推进
○ 已修复的及时验证掉
○ 未修复的推进
○ 有风险则报风险

七、集成测试

7.1 概要

这个阶段重点是 回归 + 适配：
● 先把现有的缺陷再验证下，该Close的Close、该Reopen的Reopen，剩下的缺陷如果没动静则提醒开发去修复或推动下
● 各端都用最新的集成包来测
● 全量功能回归 = 本轮迭代的新功能 + 老功能
● 适配测试比较耗精力，尽量将测试方案中的适配范围都覆盖到，最低要求：核心功能要走一遍

理论依据：
● 集成测试前做的是单元测试（单测），单元测试都通过不代表集成测试也都通过。
○ 就像汽车每个零部件都检测OK，但是组装在一起，这辆车不一定能正常跑起来一样～
○ 这里的零部件就像一个个单独提测的子需求，这辆车就像集成了所有子需求后的完整版专有钉V2.8.0
● 而且，开发在修复bug的过程中，可能会引发新的bug，导致之前原本正常的功能出问题！

7.2 兜底：按测试计划回归

到了集成测试阶段，Aone上的新功能用例理论上应该已经都整理的差不多了。
这个时候就需要在Aone上建测试计划来回归：
● 这是一种规范，也叫兜底，起码可以保证执行过的用例所覆盖的功能是要OK的
● Aone上建测试计划来执行用例参考

7.3 创新：时刻保持找问题的心态

● 发散
○ 大家交叉测试
○ 自己再琢磨下一些未尝试过的场景组合 或 骚操作
● 扩大适配
○ 也许你换台机型或换个端换个系统，又能轻松的发现一堆适配型bug