测试指南(适用于Feature/promotion/bug)

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,当然自己忘了也可以通过这些手册来回顾的;

转载于:https://www.cnblogs.com/meiling-ji/p/6389435.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值