测试资源不够怎么办，我的第一次内测分享

一般几轮系统测试完后，会进行验收或用户测试，因为是自家产品，我这里就简称内测活动，主要对象是公司内部人员，大家可以借鉴讨论。

内测活动的由来

产品后端之前是PHP做的，由于发展后端需要换成Java，替换原有功能的同时，新增了很多功能，基本前后端重做，确认产品上线日期后，各方时间都很紧，按照最初的设计排期，测试组会有两周的时间进行测试（第一周完成一轮系统测试，第二周就进行回归，并会更早的介入测试），中途由于某些原因，提测时间后延了一周，加上产品上线时间不能改变，于是测试时间缩短一半（压力很大，也许这是测试的硬伤吧），事已至此，只有改变测试策略，一周的时间内让产品的质量基本能达到上线标准。

内测活动策略设计

目前产品前端包括安卓、IOS、微信小程序、WEB端。后台有两个，包括总后台和子系统后台。

●  测试范围：这次的内测范围是安卓和IOS端的全部功能，其他端已经进行过测试。产品主要包括A，B，C，D大功能模块，E通用功能模块，如登录注册，分享等。

●  测试资源：测试组，产品组，运营组，设计组，其他（开发、领导等）。

●  测试环境：主要体现在测试机型上面，包括安卓和IOS（测试机不够就用自己的手机，部分还使用了模拟器)。

●  测试目标：执行完成所有模块的测试用例。

●  其他：测试用例已经完成，并通过组内评审，其中A模块（439条），B模块（372条），C模块（92条），D模块（146条），E模块（300条）。

测试计划大概是我这边每日安排后一天的测试内容，测试人员按照测试用例进行测试，并记录测试的结果和缺陷；开发及时解决当天的问题，并每日提交一版本，我这边晚上再总结统计。

内测活动详细安排

 开发提交版本的时候，我们测试这边看了下，质量不咋地，于是为了避免其他组人员提交的问题过多，于是先由测试组测完一个模块，再用提测邮件的方式发送给对应人员。

 上面这个计划优点如下：

1，规定时间基本完成所有的功能覆盖，机型覆盖

2，各部门分工进行，最大程度避免重复bug

3，各部门都对安卓和ios进行测试，组合覆盖

4，测试先行，防止测试堵塞并避免低效bug

不足如下：

1，因为各部门要交叉测试，可能面对测试机不足的情况

2，测试先行验证，测试人力不足时，可能用例执行不完

3，依旧会存在重复bug，例如接口问题

4，每天的测试模块不同，后面新产生的问题可能会被逃逸掉

 不足之处中，1问题可以事先统计好，基本都是用自己的手机；2问题可以完成基本路径或重要流程；3问题可以早期进行接口测试，4问题后期需要回归测试验证。

内测活动过程解析

  1，应用安装

因为这是跨部门协作，涉及人数较多，可能需要简化安装流程，我们用的是蒲公英的下载二维码，扫码直接安装。PS：IOS有点限制，需要提前提供手机的UUID

  2，用例执行

测试用例虽然说面对所有用户，但为了执行顺利，这里最好提前开会培训一下。PS：用例是Excel，为了方便管理，用的是腾讯实时共享文档，虽然其中有很多坑

　　执行过程中注意：

　　　　●  用例执行结果：我们划分为通过，阻塞，未通过。其中阻塞需要备注清楚，未通过就是bug。

　　　　●  测试人：需要填写自己的名字，便于后续跟踪

　　可能存在的问题：

　　　　●  由于需求变动或其他原因，用例执行时可能会有用例编写错误的情况（我们采用的是错误标红，用例执行结果不填，意思就是未执行）

　　　　●  用例的预置条件或执行步骤难以执行，比如查看点赞数1万的显示（涉及测试数据准备，如果需要更专业的，我们采用的堵塞，后续由我们测试跟进）

  3，BUG跟踪

bug的跟踪管理也是难点，我们也用的腾讯共享文档，产品和运营各一份，再加上一份汇总文档，其中都包括各端，如安卓，IOS，小程序等。PS：统计到汇总文档时，腾讯实时共享文档中全部复制没有图片，只能单张的复制！！！最好用其他缺陷管理工具，维护文档很累的

　　执行过程中注意：

　　　　●  问题描述：描述清晰准确，必要时备注截图或对应的用例编号。（如果时间充裕，可作为强制要求）

　　　　●  问题状态：流程比较简易——新建的bug状态为激活，测试人员验证后指定对应开发，开发修复后为已解决，然后再由新建人验证后为已关闭，如果有其他情况，必须备注清楚。

　　　　●  问题类型：状态分3种状态——代码错误，指程序上的bug；优化建议——包括界面优化，性能之类的；设计缺陷——需求功能有误或不合理的地方。

　　可能存在的问题：

　　　　●  每个人的专业性不同，可能存在描述不清晰，难以理解的情况（必要的用例编号）

　　　　●  开发来不及修改，可能会提交重复问题（各部门的bug整理后放入bug汇总文档，可由测试负责）

　　　　●  文档不稳定性，每个人都可以在文档上修改，修改记录没有日志，这跟使用的缺陷管理工具有关（有禅道之类的，但感觉有点重，最近接触过bugtags，没具体用，感觉挺方便）

  4，统计总结

每天晚上先由各部门整理测试情况，再由我这边统一整理，包括用例执行，缺陷统计，缺陷修复情况等，最后的通过标准：用例执行完毕，包括阻塞的，已修复的bug状态必须为已关闭，且关闭人必须是新建人，其他状态需由相关项目人员知晓。

总结：统计当时做得很简单，最重要的是没有具体落实到责任人，这点是内测最重要也最容易忽视的点，也是整个内测活动最大不足之处。

PS：落实到责任人，说起简单，但做起来很难，暂时也没想到好的解决办法。可能跟出发点有关，大家打心底里认为是帮我们测试，所以做得不是很细致，实际上，内测活动既然大家要做，就得为每个结果负责。