51Testing软件测试论坛

标题: 静态代码分析和Bug自动识别——阿里测试之道 [打印本页]

作者: lsekfe 时间: 2022-5-26 10:05
标题: 静态代码分析和Bug自动识别——阿里测试之道
　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所示。
[attach]138198[/attach]
（1）找到代码仓库中Bug（缺陷）修复型commit。
　　（2）从这些Bug修复型commit中以文件级别提取删除内容和新增内容，即Bug修复对（DefectandPatchPair，DPPair）。
　　（3）对代码进行格式化和降噪。
　　（4）对代码进行归一化，解决两个相似的代码块由于变量名或对象名存在差异，而无法聚集到一起的问题。
　　（5）对Bug修复对进行聚类，提取出DPPair模板，存入模板库。
　　有了模板库，每次有新提交代码时，就能扫描代码中是否存在与模板库中的某个DPPair匹配的代码片段，并给出相应提示，也能根据DPPair模板给出Bug的修复建议。

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)