测试经验的总结

发表于:2014-7-17 11:08

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

 作者:chenmin4767    来源:51Testing软件测试网博客

  软件职业生涯总结
  项目一:MTK应用软件测试
  产品流程为:产品立项---产品定义--产品设计开发---提交产品---开发人员测试(开发部有一人专测)----产品部验证产品(转下)
  1)有BUG转到开发部门进行修复,修改后再次验证,验证通过转到第2点
  2)无BUG直接与中间件通讯进行资费测试
  项目二:智能视频监控软件测试(C/S   B/S 版测试)
  产品流程为:产品立项----产品设计开发---提交产品---测试人员根据实现功能进行测试--BUG提交---BUG修复---BUG关闭
  测试内部流程: 编写测试方案---编写测试用例--提交新版本执行用例---BUG提交与跟踪---BUG的修复与验证----测试回归测试(回归只针对修改部分进行详细测试,其它未改动部分正常功能测试)--多个基线回归测试---后期使用手册的编写
  项目三:APP应用
  产品流程:产品市场调研---产品需求定义---产品设计开发---测试----回归测试----测试报告---上线
  测试内部流程:熟悉需求---编写测试用例---执行测试用例---回归测试---编写简洁测试报告---产品上线测试
  以上为本人所在公司的一些工作流程,个人以为都不太完善。因为都是一些小公司很多流程就省略了,都说一些大公司的流程比较规范,各位大侠一起分享哟!
  以下为个人对流程的一些想法,请多多指教!
  软件生命周期:
  产品产项---产品定义---产品需求----需求评审(个人觉得测试很有必要参加这个评审会议)---确定需求---产品设计---产品编码----产品成型----测试---回归测试---测试报告---维护
  (产品成型后如若能安排时间与测试人员互动,让测试人员了解开发的一些设计逻辑或业务流程对测试人员那是相当的有帮助,目前所有公司软件的业务流程都是测试人员一个个去问的,想深度发现BUG一定要了解业务流程,否则只能发现一些表面的问题)
  IOS应用测试流程一:
  第一步:遍历自己模块,查看大的功能点是否已实现
  1)未实现   拒绝测试转给开发人员内测
  2)已实现   转到正常流程测试,转第二步
  第二步:执行所有的测试用例
  1)优先执行正常功能的用例
  2)执行异常的用例
  3)按模块执行用例,即正常的异常的一起执行
  此不知各位觉得哪个好些呢,我们实际操作都是按的3来的,每次时间都觉得很紧的?
  第三步:BUG的提交与跟踪
  提交的BUG即使告知开发人员,功能BUG直接描述,对于一些涉及到UI的问题截图加附件以便开发人员知道具体的现象。
  第四步:提交新的基线测试
  1)验证上一轮BUG修复情况,未修复转给开发人员;已修复关闭BUG
  2)验证BUG完毕后进行正常功能的验证,时间允许的话执行正常功能用例
  第五步:重复第四步,执到所有BUG均已修复,或大部分BUG已修复
  第六步:遍历所有模块的正常功能测试(测试环境),提交测试环境测试报告
  第七步:生产环境的测试(所有正常功能的测试),提交生产环境测试报告
  第八步: 产品上线后的验证测试
版权声明:本文出自 chenmin4767 的51Testing软件测试博客:http://www.51testing.com/?356213
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号