测试跨部门协同记录（内测活动）

百瓶 2.0版本内测活动总结

这两天有时间，整理了之前的博客，为类似测试场景的同行提供参考。

本文记录了百瓶2.0版本测试过程中内测活动的任务分解、执行安排及跨部门协作的实践经历。面对紧迫的2周测试时间、有限的人手以及不断变化的需求，各方通过明确的任务策略与严谨的执行流程，有效降低了测试风险并确保了版本顺利上线。

---

项目背景

当时面临百瓶2.0版本上线，需要测试APP两端、小程序、管理后台。当时测试组只有4人，仅APP两端就有2千条用例，预计总共2周的测试时间，其中APP测试只预留了1周，测试团队面临“测试用例执行不完但上线时间已定”的两难局面。
为此，决定在第一周APP陆续提测功能，让测试提前介入；并在第二周之前，要求APP需全部提测，并让产品、运营、设计部门协助测试。
由于开发延期，第一周APP未能如期提测（仅管理后台先行测试，小程序延后测试），实际仅剩一周6天（加班1天）进行测试，风险随之增大，思考后制定以下攻坚计划，并开会与相关人员同步。

---

任务策略

• 功能布局：
  APP整体功能划分为4个大模块，总计约1千条用例，APP需分安卓/iOS两端进行测试。
• 测试分工：
  测试组4人每天对一个模块按优先级（P0）进行覆盖测试，2人/端，开发当天快速修复问题（防止阻塞）。
• 部门协作：
  次日由运营、产品介入并执行前一日模块的用例，设计同时验证模块UI，测试负责整理对应端的各部门反馈表。

---

任务安排

• 测试共计6天：
  • 前4天测试人员完成整个APP的初步测试。
  • 产品、运营、设计部门介入4天（第2-第5天），联合执行APP两端的测试用例，并记录执行情况与问题反馈。
  • 最后2天再由测试人员进行回归验证，确保问题得到闭环解决。

---

任务资源

• 人员安排：
  • 产品、运营各4人，由各部门负责人提供人员。
  • 设计2人。
  • 测试4人。
• 设备配置：
  安卓与iOS各4部测试机，其他人员的测试设备表。

---

执行过程

1. 文档管理
   新建各端Bug反馈表，每日统计各部门需要执行的用例并上传至腾讯文档，临时又做了交叉测试（如今天产品测试安卓，运营测试iOS，则明天调换）。

2. 进度通知
   次日早上通过邮件通知当天进度，贴上各部门每日执行的用例链接，部门负责人分配用例到具体人员，具体人员执行时间自主把控。

3. 用例执行及问题记录
   用例执行人员需详细填写：

   • Bug反馈表，Bug状态、类型（代码错误、设计缺陷、界面优化）。
   • 用例执行表，用例执行人，测试用例执行结果（通过、不通过、阻塞）。

4. 日报总结
   每天晚上汇总各部门执行的用例情况（包括通过、不通过、阻塞），统计缺陷情况并补充相关注意事项，回复到当天通知邮件。

5. 反馈修改
   开发人员及时跟进测试Bug表与反馈表问题，修复后更改Bug状态，要求当天Bug清零。

---

问题与解决

1. 用例记录缺失
   部分用例未填写实际结果和测试人信息，由我协调分派到各部门负责人。

2. Bug统计工作量大
   将个人统计与整理Bug的工作分摊至对应部门，规定8点前统计，9点前上交。

3. 用例疑问处理
   对用例有疑问者主动咨询对应测试负责人，邮件附上用例测试负责人。

4. 问题反馈不够准确清晰
   邮件提醒:举例说明，需反复确认后，再描述清楚，便于问题定位和解决。

5. Bug文档查找不便
   汇合各部门的反馈表到反馈总表，并去重。

6. 在线文档协作风险
   邮件提醒：各成员注意在线文档操作可能影响他人数据，避免误操作。

额外措施：
在最后两天，要求各部门执行人员在反馈汇总表中，针对阻塞用例和自身提交的Bug进行关闭操作，强调问题提交人和测试才有关闭的权限。

• 测试对所有问题进行筛选，标注“激活”、“待确认”、“已关闭”，并注明备注、自己名字及日期；
• 开发对激活问题进行查看和标注“已解决”，并注明备注、自己名字及日期(前端先确认，再通知后端)；
• 产品对待确认问题进行确认，标注为“激活”或“已关闭”，并注明备注、自己名字及日期；
• 最终确保自己提交的问题均检查到位，问题状态最终均为“已关闭”，备注人必须为本人；

---

总结

1. 由于各执行人的业务熟悉情况、Bug理解情况、表达能力等存在差异，以及测试数据的构造难度不一，导致整体内测效果较差，后续花了很多时间去跟踪反馈表
2. 俗话说，共苦造就信任，大家一起加班，有个明显的好处是，为后续顺畅的团队协作打下了基础
3. 体会到，作为管理者，不要钻于具体细节，要做好角色与责任分配

---