欢迎进入北大青鸟(广州网耀)全国IT职业教育示范中心

学历不是敲门砖,技术才是硬道理

咨询热线:4006-1122-06

软件测试质量分析

发布时间: 2015-02-07 09:43:43   作者:本站编辑   来源: 本站原创   浏览次数:

摘要: 在测试完成一个特性模块后,对测试过的进行总结分析,可以有效帮助我们总体掌握软件的质量情况,产出后续工作的思路和重点。
  在测试完成一个特性模块后,对测试过的进行总结分析,可以有效帮助我们总体掌握软件的质量情况,产出后续工作的思路和重点。
 
  针对一个模块特性的质量分析,个人有几点心得:
 
  1、测试用例覆盖
 
  主要看无覆盖的用例主要分布,当前发现的bug是不是通过用例测试出来的,有多少不是通过用例测试出来的。
 
  这些通过用例测试不出来,需要分析是不是测试用例质量问题?需求遗漏?历史遗留问题?其他等等
 
  通过用例的覆盖程度,分析是不是用例存在较大的问题,是否需要补充评审分析用例的覆盖和添加用例,以及后续是否需要加强测试。
 
  2、bug缺陷分析
 
  通过发现的bug分析,缺陷分布在哪一方面。
 
  一方面分析得软件处理比较薄弱的地方,进行加强测试;一方面通过分析得出一些缺陷预防的思路,避免以后也会犯同样的错误。
 
  最后看看,bug的产生原因。(低级问题?应该在那个阶段被发现?)可以从另一个侧面反映开发的水平。
 
  3、测试人员的执行质量(执行力)
 
  测试人员的业务知识(行业知识:如金融,通讯设备,互联网等都有各自的业务知识)和软件的设计原理有没有理解清楚;
 
  如果是新手那么需要相应的措施(检查,考评等)确保是否能达到期望。
 
  4、改动大小,改动引发bug,bug回归
 
  这个主要是后期需求变更或者修复bug改动引起的风险。如果有自动化的话,这个就比较简单。
 
  虽然在回归bug的时候,会对改动的地方进行验证和测试,但是bug改动较多的时候难免会有可能引人风险。
 
  5、代码覆盖率
 
  代码覆盖率跟用例覆盖率关联比较大,用例覆盖的全面代码覆盖的也就全面。当然单单从黑盒角度的用例在覆盖全部代码,多数情况是覆盖不全面的。
 
  这个时候需要开发参与,分析当前测试过的点是否还要那些地方没有覆盖到,通过白盒灰盒角度考虑进行补充覆盖。
 
  代码覆盖率也可以通过工具帮助分析,这些方法我暂时还不清楚实现原理。
 
  6、与历史数据的对比
 
  一般对比下历史的数据,比如说bug数量,可以有一定的参考性。如历史版本一般能发现100个左右bug,而当前版本只发现50个,
 
  那么就需要全面分析这到底是还有较多bug没有测试出来,还是版本质量稳定。
 
  7、代码检视
 
  这个我没有做过,但是往往代码检视做的好的话往往能发现一些隐患。这些隐患可能不会立即带来bug,但是可能对于后续扩展性后续维护不利等,这些一般是有经验的开发进行代码检视。测试跟踪代码检视后续修改的地方,进行补充测试。以防止改出问题。
分享到:
我来说两句
评论内容:
验  证  码:
 
(网友评论仅供其表达个人看法,并不表明本站同意其观点或证实其描述。)
评论列表
已有 0 条评论(查看更多评论)