qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

测试经验的总结

  软件职业生涯总结
  项目一: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已修复
  第六步:遍历所有模块的正常功能测试(测试环境),提交测试环境测试报告
  第七步:生产环境的测试(所有正常功能的测试),提交生产环境测试报告
  第八步: 产品上线后的验证测试

posted on 2014-07-18 09:58 顺其自然EVO 阅读(206) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜