标签：use 修复 三方登录 回顾 样式 指南 客服 使用手册 缓存
1.提前了解需求，在需求的业务基础和开发的架构基础上分析测试关键点，给出测试策略，甚至需要准备测试数据；
2.分析需求时不要受开发影响，要有自己的分析和判断，包括测试范围，测试时间；
3.在开始测试之前，根据之前的分析准备 qa checklist for every feature/promotion/bug fix，如果时间允许可以写scenario/checklist,甚至test case;
4.在开发提测后，先把整个业务最关键的逻辑测试一遍，然后报第一轮bug,目的有两个，一是发现关键issue，二是让开发有事去做，尽快处理，否则越晚发现会影响整个项目进度;
5.Checklist for Feature/Promotion/bug:
a. 验证页面样式跟Mockup一致;
b. 验证页面内容跟期望的一致，不能有inactive或expired的内容，还有特殊内容的缓存时间；
c. 验证页面调用老的功能,需要保证跟老版一致;
d. 如果某块功能做重构，该功能一定要做全面测试，比如重构测试第三方登录的时候，至少要保证所有的第三方都测试到；
e. 一些涉及前后台的功能,要验证前后是同步的,否则只是前台实现,后台没有控制,会有安全问题，比如sms(具体记不清了);
f. 验证登录前，登录后的功能/样式/内容；
g. 验证不同类型的用户登录后的功能/样式/内容;
h. 验证不同的语言下的功能/样式/内容；
i. 验证系统发的相关的邮件，尤其注意不同语言下的内容；
j. 验证页面性能，比如看是否使用Lazy loading；
k. 验证兼容性；
l. 如果有新的页面，添加seo相关的；
m. 验证PC版，Mobile版，APP版下以上所列的checklist；
n. 测试好了，在master通知相关负责人review，至少要通知Am，大的feature/promotion/bug的则一定要做测试分析评审；
o. 我们在测试过程中还要充当用户来做体验，当然现在Zo那边做得也不错，总归是用心点麻烦会少些。具体来说，抽到了CEO祝福的红包，提示用户‘联系客服‘，用户就有可能去联系客服，但是我们知道这就是个空的红包，没有必要联系客服;
p. 如果是promotion，上线前一定要让Ja那边了解如何添加和维护活动内容，保证上线后的内容和活动时间， 比如活动时间是2015年的，却设置成2014年的，看似简单，却很容易遗漏，绝对是个serious bug；
q. 如果是feature for CS，上线前告诉CS如何使用该功能；
r. 新的功能上线后，负责人要写使用手册；
如果上线有遗留bug或优化暂时不做,那么放到Later list, 并给我review，上线之后新建card放到bug board里，一定要确保Later list不能被遗忘;
s. 各人负责的东西，上了生产一定要验证和跟踪，有必要的话要监控生产数据是否是期望的，比如下单记录，注册记录；
6.Bug描述要清晰，问题定位的附件相对完整，问题描述语言要规范；影响大的bug，需要尽快升级修复，千万不能淹没在bug board里面。所报的bug尽量搞清楚如何重现，可以帮助开发快速定位问题，修好了之后也就知道了如何retest了。如果不能明确如何重现，开发修复了之后也要搞清楚root cause，然后才能更好的retest；一些很低优先级的bug也不要遗漏，推动开发在方便的时候修复掉，因为小细节体现了我们的产品品牌；
7.大的feature/promotion/bug的一定要按Template整理或者更新相关文档，是方便组内共享，也是方便以后给任何人KT，当然自己忘了也可以通过这些手册来回顾的;
测试指南(适用于Feature/promotion/bug)
标签：use 修复 三方登录 回顾 样式 指南 客服 使用手册 缓存
原文地址：http://www.cnblogs.com/meiling-ji/p/6389435.html
