由遗漏bug引发的思考

发表于:2014-4-22 09:00

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:爱菱    来源:51Testing软件测试网原创

分享:
  来淘宝已经五年多了,做多大大小小的项目日常已经自己也数不过来了。虽然在项目日常中,我总是竭尽全力去保证质量,但是无可避免,也会遗漏bug,想对以前遗漏的bug和自己知道的其他人遗漏的bug做一个总结,反思总结才能让自己进步,不要范相同的错误。
  (1)  不一致问题。
  (2)  紧急情况。
  (3)  性能问题。
  (4)  兼容性问题。
  (5)  并发问题。
  (6)  交互问题。
  (7)  沟通问题。
  (8)  特殊场景。
  (9)  未通知回归。
  (10) 需求遗漏。
  (11) 浏览器测试不全面。
  (12) 关联的问题。
  (13) 用户体验问题。
  (14) 应用发布顺序有问题。
  (15) 需求"搭车"发布导致问题。
  (16) 优化代码导致错误。
  一、需求阶段
  1. 沟通问题。双方理解不一致,最后导致实现的需求不一致。这个问题需要有一个牵头人,组织相关人员碰头,进行评审,把需求明确,并把会议纪要以邮件的形式发给相关人员。实例:一个需求需要两个团队合作完成,需求评审时,没有沟通清楚,大家都按照自己理解的需求来开发,最后的判断原则却两边相反的,多么可怕。
 ......
   查看全文请点击下载:http://www.51testing.com/html/15/n-860515.html
  三、开发阶段
  1. 紧急需求。时间紧,考虑也不够全面,有些模块修改了,另外模板没有修改;有些应用修改,另外的应用没有修改。就会出现问题。紧急需求更需要进行代码review并提交给测试同学测试,并通知回归。(紧急需求,流程可以特殊,流程短,测试能尽快响应测试)。实例:特殊节日,要做活动,有deadline,开发在没有评审、,没有代码review、甚至没有测试的情况下紧急上线。
  2. 优化代码。影响到非优化的模块,而又未回归,导致出错。首先优化代码不能私自优化,需要走正常流程,测试通过并全网回归通过后才能发布。实例:优化重构,开发修改了代码,把其他非优化的模块的代码修改错了,但是测试没有回归被修改的模块,全网回归也没有覆盖该功能点的脚本,就导致bug遗漏了。
  3. 未通知关联应用回归。关联紧密的应用,其中一个应用修改功能,若不通知其他应用修改、回归,会导致关联应用都出现问题。比如底层应用修改,上游的应用都需要修改或者回归测试,这种情况就不必须要通知,邮件通知是一种形式,但是必须要确认大家是否都测试完成。如果发生这种情况就属于责任心的问题。实例:应用出现问题,排查了很久才知道底层应用升级了,但是完全没是收到通知。
......
   查看全文请点击下载:http://www.51testing.com/html/15/n-860515.html
  版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号