静态代码分析和Bug自动识别——阿里测试之道(21)

发表于:2022-5-26 09:17

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

 作者:阿里巴巴技术质量小组    来源:51Testing软件测试网原创

  1.8.2静态代码分析和Bug自动识别
  1.静态代码分析
  过去我们遇到了很多问题是很难通过测试发现的,但通过静态代码分析很容易发现和避免,例如:
  有业务语义的时间都应该从数据库获取,不可以取本地服务器的系统时间。
  从数据库获取时间必须使用selectnow(6),不可以用selectnow()。
  避免直接使用get(0)获取集合中的值,集合中元素顺序的改变可能引发问题。
  存入缓存的对象避免使用Map<String,Serializable>或Map<String,Object>类型,否则可能出现类型转换错误。
  总是使用Calendar.HOUR_OF_DAY,而避免使用Calendar.HOUR(除非有明确理由)。
  ORDERBY必须确保排序唯一。例如,当ORDERBYgmt_createASC存在多条记录gmt_create相等的时候,排序是不确定的。在ORDERBY语句中加入主键字段可以确保其排序是确定的,例如,ORDERBYgmt_create,detail_idASC中的
  detail_id为该表主键。
  getAmount().longValue()会丢失金额精度,不应使用。
  在for循环里,应避免出现RPC方法调用或事务方法。
  ThreadLocal要调用remove(),否则可能导致线程上下文错乱,引发问题。
  我们会把以上这些代码问题类型沉淀为静态代码分析规则,再结合代码规范,用FindBugs、PMD等工具在每次持续集成和使用代码门禁时都对变更代码进行扫描,在第一时间拦截可能有问题的代码。

  2.Bug自动识别
  如果从遇到的实际问题中不断总结积累经验,那么需要的时间比较长。我们希望有一种方法可以更高效地把过往代码历史中的Bug及其修复都提取出来,尽最大可能防止开发人员重蹈覆辙。
  采取的做法是对代码仓库的历史提交进行聚类和模板提取,如图1-16所示。
▲图1-16对代码仓库的历史提交进行聚类和模板提取

  (1)找到代码仓库中Bug(缺陷)修复型commit。
  (2)从这些Bug修复型commit中以文件级别提取删除内容和新增内容,即Bug修复对(DefectandPatchPair,DPPair)。
  (3)对代码进行格式化和降噪。
  (4)对代码进行归一化,解决两个相似的代码块由于变量名或对象名存在差异,而无法聚集到一起的问题。
  (5)对Bug修复对进行聚类,提取出DPPair模板,存入模板库。
  有了模板库,每次有新提交代码时,就能扫描代码中是否存在与模板库中的某个DPPair匹配的代码片段,并给出相应提示,也能根据DPPair模板给出Bug的修复建议。

  1.9本章小结
  很多测试团队都面临类似的问题:测试自动化难、测试结果噪声大、测试不充分、测试人员对自身成长的焦虑等。
  为了以更少的时间、更少的人力、更少的资源,得到更好的质量,测试团队的努力方向是:
  建立代码门禁,通过更好地持续集成和自动缩短反馈弧,以及“三斧子半”提升测试稳定性,减少测试结果的噪声。
  通过变异测试、线下质量红蓝攻防、报文注入等手段提升测试的有效性。
  采用多种手段自动生成用例,并对业务覆盖率进行多维度的度量,提升测试的充分性。
  推行防错设计,并通过静态代码分析和自动识别Bug等手段,做到“上工治未病”,实现“从测到不测”。

查看《阿里测试之道》全部连载章节
版权声明:51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号