近期参加了一个大型活动的测试工作哈，结果是美好的，但过程是纠结的。但我们要追求除了结果是美好的，也希望过程是流畅和美好的。

　　这个大型活动，偶是中途才参与进来的，没有能够参见需求以及方案的评审阶段，虽然如此，也还是有很多值得我们总结和后面引以为戒的地方。

　　1、一定要明确各个部门接口人。大型活动往往都是跨部门合作的，在确定需求的时候，一定要明确各个接口人，并且向当事人进行确认。这样做一方面可以避免在测试过程中需要联调或者其他问题确认缺查不到对应的处理同学，浪费时间成本增加风险；另外一方面，也可以使相关同学们更加明确自己的职责。

　　2、做好约定。活动在开发过程中，随着功能以及阅览人群范围的扩大，都会不断的进行版本的变更，但是一般大型的活动，都会预先向用户进行宣传，因此一定要按预订的发布时间上线，这样有很大的风险在里面。因此在前期评审和计划过程中，一定要做好基础版本（及测试通过，功能可以保证）的预订，比如在发布前，锁死一个基础版本的可用版本，该版本不再接受任何的需求变动，只允许bug修复，等这个版本完全稳定之后，做为保底版本，打另外一个分支来做新的需求变更，这样技能保证发布时间点，也能保证活动的功能和质量。偶在测试这次大型活动的时候，出现这样的问题，在需求前期，前面的同学没有做好这方面的约定，导致活动第二天都要发布了，很多问题还没修复的情况下，还有需求点在不断的变动，特别是本次涉及到flash，稍加改动，会导致功能上面的影响明。后强烈建议下，和PD沟通之后，锁死版本，先做一个基础版本，正是这个基础版本保证了活动能够如期上线。

　　3、如果有第三方短暂合作方资源参与，质量和测试时间方面要注意，直接影响产品的质量和修复效率。

　　4、另外还有几个测试过程中，测试同学一定要注意的几个点。测试同学要专业，并不一定体现在项目中，类是这样的活动，不会走项目，也一般不会走日常，但这并不代表我们可以不专业。

　　a）每天要反馈测试进度，抛出存在的问题，便于相关同学了解整个进度以及状况。

　　b）bug一定要录入相关同学都可视的管理工具中，如QC当，这样做不仅仅是为了便于bug的跟踪，另一方面其他相关同学如pd才能了解具体的现状。

　　c）在提交bug时，一定要注意定义bug的严重程度和优先级。因为这个的定义，直接影响到开发同学修复bug的顺序和紧急程度，特别是问题很多的时候。如果不定义都默认为3-Medium，开发同学一看全是3-Medium的问题，从头到尾开始修复，结果会出现，一直在修复bug，但是主流程确一直走不通。另外一个层面，老大以及pd等其它同学看到目前的bug都是3-Normal，都不严重，也不会引起重视。但是这一点往往容易被同学们该忽略。