TA的每日心情 | 擦汗 昨天 09:02 |
---|
签到天数: 1046 天 连续签到: 4 天 [LV.10]测试总司令
|
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)找到代码仓库中Bug(缺陷)修复型commit。
(2)从这些Bug修复型commit中以文件级别提取删除内容和新增内容,即Bug修复对(DefectandPatchPair,DPPair)。
(3)对代码进行格式化和降噪。
(4)对代码进行归一化,解决两个相似的代码块由于变量名或对象名存在差异,而无法聚集到一起的问题。
(5)对Bug修复对进行聚类,提取出DPPair模板,存入模板库。
有了模板库,每次有新提交代码时,就能扫描代码中是否存在与模板库中的某个DPPair匹配的代码片段,并给出相应提示,也能根据DPPair模板给出Bug的修复建议。
1.9本章小结
很多测试团队都面临类似的问题:测试自动化难、测试结果噪声大、测试不充分、测试人员对自身成长的焦虑等。
为了以更少的时间、更少的人力、更少的资源,得到更好的质量,测试团队的努力方向是:
建立代码门禁,通过更好地持续集成和自动缩短反馈弧,以及“三斧子半”提升测试稳定性,减少测试结果的噪声。
通过变异测试、线下质量红蓝攻防、报文注入等手段提升测试的有效性。
采用多种手段自动生成用例,并对业务覆盖率进行多维度的度量,提升测试的充分性。
推行防错设计,并通过静态代码分析和自动识别Bug等手段,做到“上工治未病”,实现“从测到不测”。
|
|