完善的测试用例往往能提高单元测试的效果,但并不能以此作为单元测试好坏的依据。相应的复杂臃肿的测试用例并不能证明此次测试效果优秀,简陋的测试用例却能直接表明测试工作的欠缺
并不建议以此作为度量单元测试效果,纯粹的bug数纬度会引起团队内部的过度竞争和信息封锁。因为测试模块本身的难易和不稳定性,导致测试不同模块产生的bug也不同,难以甄别其有效性
测试人员可能会专注于执行更容易通过的测试,从而提高通过率,亦或者团队可以将一个长时间的测试分解成许多小的测试,人为地提高百分比的通过率,百分比通过率的测试效果易于操纵
代码覆盖是另一个常用的度量指标,代码覆盖率 = 代码的覆盖程度,测试覆盖率仅仅能够告诉团队什么没有被测试,根本就回答不了软件是否经过了有效测试
语句覆盖(StatementCoverage):又称行覆盖(LineCoverage),段覆盖(SegmentCoverage),基本块覆盖(BasicBlockCoverage),这是最常用也是最常见的一种覆盖方式,就是度量被测代码中每个可执行语句是否被执行到
判定覆盖(DecisionCoverage):又称分支覆盖(BranchCoverage),所有边界覆盖(All-EdgesCoverage),基本路径覆盖(BasicPathCoverage),判定路径覆盖(Decision-Decision-Path)。它度量程序中每一个判定的分支是否都被测试到了
路径覆盖(PathCoverage):又称断言覆盖(PredicateCoverage)。它度量了是否函数的每一个分支都被执行了,测试路径随着分支的数量指数级别增加.对于比较简单的小程序来说,实现路径覆盖是可能的,但是如果程序中出现了多个判断和多个循环,可能的路径数目将会急剧增长,以致实现路径覆盖是几乎不可能的
它度量是否对循环体执行了零次,一次和多余一次循环
计算标准:方法覆盖行/方法行
计算标准:方法传参 a,b 对a或者b其中一个参数做边界值测试等,则异常值测试率为50% 覆盖参数/总参数
计算标准: if switch 的判定条件true false case等是否都测试到,对方法中出现的if-else做统计 覆盖的if-else代码块/总if-else代码块 覆盖的if-else数/总if-else数
计算标准: if(a|b) a、b条件是否都测试到 ,如果a b只测试了一个则为50%,三目运算等计算同理 覆盖的表达书/总表达式
计算标准: 代码中出现while、递归的方法,则该while 递归的代码必须做到 行覆盖、判定覆盖、条件覆盖 100%
计算标准: 覆盖的执行路径/总执行路径 路径的覆盖计算过于复杂,暂时不强制要求
ctl service util等,不需要测试dao层
测试报告只能导出需要测试的文件并打包上传到需求单补丁单中(不允许打全量)
压缩包名:实际表单标题