手机软件测试模式-手机测试模式

前言

测试作为整个项目中的一环，在项目流程中起着不可或缺的作用。部分团队是缺少项目管理角色的，这个时候，测试对项目流程的推进、项目质量的保证显得尤为重要。

好的测试，能在整个项目流程中以 QA 角度做好项目管理和及时的风险预警，让项目如期上线且保障质量。

业界一直强调测试前置，那么测试在项目中，如何根据项目情况做前置工作推进项目流程，让大家都开心工作呢？

本文以自己所在的项目组为例讲述项目流程中的一些事，希望可以与大家一同探讨~

一、QA在项目中扮演的角色

【why】明确的目标是什么：

明确做这个项目的目标是什么，可适当根据目标对需求实现、项目质量、研发提测时间点等做一些调节。

【when】项目的 deadline：

考虑项目组的特殊性，我们需要知道项目需要什么时候上线，明确项目deadline，根据时间节点制定合适的测试计划。

【what】各阶段我们需要做什么：

可以重点关注项目流程中，QA 参与与输出的环节。有输入才会有输出，所以输出的环节往往是需要 QA 花费时间去思考的地方。

【how】遇到风险点时怎么做：

测试阶段，除了QA环节的风险点需要及时暴露和 push 外，这个阶段研发和产品也在做一些工作。在项目流程管理中，作为最下游的参与者，需要关注这些风险点，及时暴露和push解决。

【who】QA、RD、PM

二、我们面临的挑战

挑战点

1. 发版频率在排名第二，2021全年发版71次，相当于每周都有一个版本在进行迭代，快速迭代的节奏， 对人效和团队协同效率要求高。

2. 整个2021年，研发人均 bug 数100+，bug 较多，提测质量不高。为了不拉长项目周期， 保障较短的 bugfix 时间非常关键，同时要考虑如何提高提测质量。

3. 整个2021年，测试人均提bug量最多，在项目节奏紧张的情况下，发现和提bug的效率必须提升。

关于提测质量

针对上述挑战的内容，我们可以看到提测质量上，我们存在不足之处。我们之前做过提高冒烟用例比例、冒烟交叉执行、时间预估增加冒烟时间等尝试，最后发现收获的效果有限。主要原因如下：

基于以上原因，我们可以看到在质量与效率之间需要做一定的选择时，需要向项目效率倾斜，所以我们既然无法更好地改变提测质量，那就去改变我们能改变的。

三、面对这些挑战，QA可以做什么

QA 可以做什么让整个迭代周期变短，在bug很多的情况下还能快速迭代且线上问题较少呢？先来看下我们的项目流程：

从整个项目流程上看，可能与很多团队如出一辙。

在流程上，QA作为下游的一个部分，可以看到QA参与输出的内容其实有很多，这些部分就是我们可以尝试去改变提升的点。

那么我们从这些输出内容看下，面对上述挑战，QA 都做了哪些改变以及还有哪些困境。

项目排期计划

项目排期计划模板：

【when】项目排期一般是需求评审完后，根据需求拆分需求模块和开发模块。

排期计划中，QA 的工作：熟悉需求，拆分需求模块，制定测试计划

QA 同学加入进模块拆解，能更好的了解需求，拆分的开发模块也能更快的知道当有bug时，bug是属于哪个端的，提给哪位对应的开发。

根据各模块的提测时间和大致开发周期，QA同学也能制定对应的测试计划。

【what】-- QA具体需要做什么

1.协助开发拆分功能模块，确保每个模块都有对应的开发负责人

2.确认项目deadline、开发总预计时间和提测时间。

测试计划制定

项目测试计划模板：

【when】测试计划一般在项目排期给出后1天内提供，后续根据排期动态调整。

测试计划中，QA的工作：根据需求预估时间和人力，明确测试环境与策略，制定合理的测试计划，预估风险

【what】-- QA具体需要做什么

拆分功能模块，模块明确好对应的测试。（包含用例编写安排、一、二轮测试安排和兼容测试安排）。预估好项目的总体测试时间和各轮次的测试时间。一轮接近尾声时，与开发明确好上预发时间；二轮接近尾声时，与开发明确好上online环境的时间。如有数据配置项，二轮测试开始前与产品明确好配置所需内容和完成时间节点.

以上1、2两点尽早提供，其余可在对应时间点给出。当然，如遇到需求变更、人力变更等需要及时提出和调整。

【how】-- 具体怎么做

根据开发排期，动态制定和调整合理测试的计划。

· 根据提测时间，决定用例执行顺序与分配：

如下图拆分的测试计划，后台配置（星火）与用户端提测时间不一致，结合两个提测时间点，我们利用用户端提测前的时间，先执行后台配置的用例，这样即使是分步提测，我们也能确保每次提测时测试资源能跟上。

· 根据功能制定测试轮次：

对于主干功能：需要多次执行测试用例，一般制定三轮的测试，一轮在测试环境，二轮预发环境，三轮线上环境。

对于对内的、不影响用户使用的功能：制定一轮测试，在测试环境测一轮。比如星火等配置后台是给运营使用的，做一轮测试，上预发后产品走查验证+配置内容即可。

活动类的功能：依据活动的复杂程度和使用频次，制定测试轮次。比如新年活动，是一次性的活动且活动时间紧，评估后我们在预发做了一轮测试就上线了，上线质量也一样较好。具体测试流程：活动类测试流程尝试。

· 按照模块、用例量与难度划分，制定每人每天用例执行目标

一轮测试模块划分根据用例编写与熟悉度划分

· 实行交叉测试，避免因不熟悉导致遗漏或效率降低

二轮进测试进行交叉，利用TC平台的任务指派，也可以清楚看到组员的任务数量与完成情况。

如下图，测试计划的拆解与人员分配，细致划分到每人每日的工作目标，且各模块的分配会进行交叉，一轮测试人员发现用例不完善或测试不方便的地方也提供了文档以便二轮人员尽快上手测试。

[小结]：

我们可以看到，调整测试计划的4种方式，主要目的都是通过这些办法去更高效地去完成测试任务，保障项目如期上线；更完善、全面地去发现bug，提升项目质量。

测试计划的合理调整分配，是面对项目过程中各种挑战的有效方式之一。

jira 定制化流程

1. 定制化的 jira 项目流程：

【小结】：

1.定制化的流程，让流程更加统一规范和智能化。

2.关键信息的及时同步，能减少每日站会、信息同步会等重复会议，节约了时间。

各团队之前的协作更加顺畅，那团队协同效率和人效也就自然而然能进一步提高。

2. QA 高效提bug、研发快速修bug秘诀：

2021Q1 效率工具的需求收集提效讨论中，提bug流程的优化建议一一实现了，每个人提bug 的速度大幅提升，主要汇总如下：

项目流程复盘中，我们约定 p1bug 当天需要fix，p2bug 原则上 fix 周期不超过 T+1 天，验收不超过 T+2 天。如下图，就是根据形成的规范自动提醒研发、测试的内容：

【小结】：

即使是预置的一些提bug信息和界面优化，也让测试更“优雅”地工作，提bug和验bug也更有劲儿了。T+1修复周期的约定与消息推送，给了研发一个心理预期，正如我们根据项目情况调整测试策略一般，研发也根据我们给的预期调整了工作模式，从而使研发fix bug周期保障到最短，高效且有质量地修复了bug。

工作流程的调整与满满预期的加持，让整个团队的工作效率极大提高。

测试报告

1. 测试日报

【when】一般项目提测后，需要每日下班前发送日报

【what】-- QA具体需要做什么

汇总其他QA的进度，根据项目情况发送日报or周报。

日报中风险项一环节可根据项目情况修改，同步计划、提醒事项等都可以写入。

push开发fix bug：p1 修复周期不超过T+1天，bug数量较多时手机软件测试模式，可根据测试情况适当催开发修改（比如一轮测试接近尾声，还有很多服务端前端bug，就需要催一下了）

【how】-- 具体怎么做

在galaxy平台工具上，实现了日报自动生成工具，每日可自动生成日报内容，方便大家看进度，且日报中还有当前bug状态和链接，研发也能更快找到自己的bug。

日报一键生成效果如下：

日报的自动生成，节省了测试每日汇总进度的时间，更是直接大幅减少了关键信息的沟通同步成本，是人效和团队协同效率提升的又一次加成buff。

2. 质量报告（测试报告）

【when】项目上线后，对项目进行总结梳理

【how】-- 具体怎么做

结合 jira 的使用流程，可一键生成测试报告并同步质量平台。

生成的测试报告示例：

项目复盘

【when】项目上线后的一周内，小型项目如有必要可合并组织

【why】复盘的目的：针对项目中不足之处，共同讨论对策，争取下次做得更好

【what】-- QA具体需要做什么

数据文档准备：形式其实不做限制，需要的数据、文档等准备好即可，也可以与开发轮流组织。会议上形成的todo list需要进行跟进处理

【how】-- 具体怎么做

复盘例子：

复盘提效 jira 看板：如下图

（ps：催 bug 或者发日报的时候也可以使用，比较清晰）

【小结】：定期做项目复盘，让团队意识到我们当前存在的问题，推进项目流程一次比一次做得更好。

【不足】：

当然，在复盘过程中，各团队虽然达成一些共识共同改进，也遇到了一系列问题。

问题一：项目节奏已经很紧张的情况下，大家可能都在赶项目进度，没有余力去做复盘总结工作，追求效率从而忽视了质量。

问题二：复盘形成的todolist也没时间去跟进，导致复盘的总结内容最后不了了之，复盘失去意义。

问题三：一些复盘改进点，往往由于各种特殊原因而不能按规定执行 。

基于以上原因，复盘收获的效果是比较有限的，也是我们今后需要探讨与改进的一个命题。

四、项目风险

风险评估

项目流程中，我们关注各个阶段需要做什么事的同时也会做项目管理与把控，关注项目风险，守住 deadline。

风险可以分为两类：质量风险和进度风险

举个例子：

用例编写的时间不够，影响测试时间和上线时间，我们称之为进度风险；而用例编写时，编写用例人员不熟该功能，用例覆盖不足，我们可以称之为质量风险。

这里我们主要关注的是项目进度，所以着重关注进度风险一项。进度风险，就是在项目进度中出现的风险从而影响了整个项目的时间点。

在测试计中，我们设计了风险一栏放于第一位，目的就是让QA在项目流程中，及时从测试角度去观测和记录风险。

比如：

风险对策

面对风险出现时，需要 case by case 讨论。在进度风险出现时，首要原则就是及时暴露风险、寻找方法去尽可能降低风险。

项目组很多项目因与其他部门配合，有固定deadline并且允许有部分已知问题带上线，那么我们一般从测试开发角度去商议的解决办法如下：

以上方案如果还不能守住 deadline，就要考虑项目延期。

结语

上述内容是作者所在项目组结合已有的测试流程，针对项目遇到的挑战进行流程推进以及推进后的总结介绍。

鉴于不同项目组的特殊和差异性，文中提到的方法和手段可能只是冰山一角，不一定完全适用各类项目。根据项目情况做前置工作推进项目流程手机软件测试模式，其实是一个很大的命题，不同项目组有时存在的问题也不尽相同，测试在项目流程中还能做哪些更 nice 的事，还是需要靠大家在现有情况下去进行探索和总结。

最后，关于软件测试学习，offer选择等等，都可以通过后台私信交流。需要学习资料或者帮忙修改简历也可以私信！！也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”，里面涵盖很多精彩免费视频或干货知识