淘宝商城(天猫)高级技术专家.3年研发+3年性能测试调优/系统测试+4年团队管理与测试架构、研发系统实践. 新舞台新气象, 深化测试基础架构及研发架构,希望能在某个技术领域成为真正的技术大牛。欢迎荐才http://bbs.51testing.com/viewthread.php?tid=120496&extra=&page=1 .邮件: jianzhao.liangjz@alibaba-inc.com,MSN:liangjianzhao@163.com.微博:http://t.sina.com.cn/1674816524

在测试效率和质量间寻找平衡支点

上一篇 / 下一篇  2009-09-09 00:39:27 / 个人分类:测试管理技巧

 

 测试当中,当系统隐Bug含的少于一定的数量时候,每发现一个bug付出的时间成本远高于系统刚提交QA测试的时刻.
怎么判断这个拐点落在何处呢? 如果有合适工具,度量判断成本如何?适用范围是否足够? 误差有多大? 这些问题都是需要寻求答案的.
 
 那我们是否可从另外一些维度考虑?
  
 1) 降低产品发布标准. 比如允许最低级别的Bug< 一定数量时可以上线, 或者降低测试覆盖率.
 2) 提高线上故障的容忍度. 比如定义最低级别的1类故障容忍逃逸.

 上述都可能影响用户体验.

 从比较正面的角度出发考虑,
 
 1) 全方位的自动化测试, 包括web ui自动化/接口测试自动化/后台linux shell自动化/模块级自动化. 再结合cruisecontrol/continumm/ buildbot等持续集成工具
 实施持续集成,快速弹出bug ,大幅度提高测试效率.
 
 由于性能调优过程职责不够明晰,优先完成性能测试过程优化.
 
 2)回归测试范围有效界定, 比如研发出判断回归影响范围以及路径的工具, 回归测试不必整体软件全部回归
 3)针对sqa的质量月报,针对当月最影响测试效率的点重点突破
 4)分工精细化,不必每一个人都是全能型选手 ,降低学习成本. 初步划分为 linux  c++/java自动化/,持续集成,缺陷预防与故障分析, 性能测试,api用例设计等子领域
 5)知识库系统补充,充分应用wiki/svn ,bocked的时候可以第一时间搜索到答案
 6) 不断提高研发提交QA 测试门槛,比如代码覆盖率>50%并且过程持续保持水准

 7) 长期致力于测试开发方面的架构和前沿方法探索
 ..)


TAG: 质量 测试 持续集成 效率

引用 删除 wendyjiangyue   /   2009-09-25 04:23:23
个人觉得,回归测试范围上,除了研发出判断回归影响范围以及路径的工具, 回归测试不必整体软件全部回归外,qa自己可以根据测试过程中发现的bug的分布情况,找出出问题最多的模块,在回归时适当扩大些回归范围,在临界边缘外,可能会找出更多的隐藏问题。
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar