精准测试

2017-12-28

“精准测试”是什么?

所有测试人员最怕听到的就是”全面回归”,实际可能仅是几行代码的改动.每次的”全回归”都是一次劳民伤财的活动,在项目体量越来越大的情况下,测试重点不清楚的情况时有发生,导致测试重心没有放在本次代码变更上,从而测试效果不理想.

精准测试,换一种说法,”恰到好处”的测试,哪种测试才叫”恰到好处”呢?众所周知的是,不存在”充分测试”这种说法,测试是否充分永远是相对的.在成本有限的前提下,花最适当的成本完成最有价值的测试工作,是精准测试努力的方向.

精准测试的意义

对于我们目前大量的维护性系统而言,大部分开发工作都是在原有基础上进行变更,可能会改动原有的模块.如果有一种比较好的办法能够快速给我们定位出本次变动可能影响的范围,从而确定测试范围,将大大提升我们的测试准度,让测试工作真正做到有的放矢,减少”全回归”的情况.

代码覆盖

基于代码的测试中才会涉及到代码覆盖这个概念,例如单元测试.覆盖度越高不代表质量一定得到了保证,但是如果有部分代码未覆盖,起码表示这部分代码可能存在风险.

任何一种类型的测试都可以理解为基于风险的测试,即有风险就需要测试,无风险的部分其实是不需要测试的.基于这个理论,代码覆盖情况可以体现出当前代码中质量存在风险的部分,这部分代码我们希望通过各种测试手段达到覆盖,从而消除风险.这其实就是我们的单元测试工作中最常听到的单元测试分支覆盖率的要求.

常听到一种说法说代码覆盖率越高不代表代码质量就一定好,这种说法本身没错,但是如果用这个说法来否定强调单元测试分支覆盖的意义,我觉得有点矫枉过正了.这就好比由于功能测试中对需求文档覆盖率越高的不一定最终质量好,所以没必要要求对需求文档的覆盖程度是一样的.覆盖率越高,即出问题的风险越低,无论哪种测试,其实最终测试都是为了降低风险,增强质量信心.

根据代码覆盖情况确定测试范围

基于以上,我们借助代码覆盖情况来为我们提供可能存在风险的代码范围,从而根据存在风险的代码范围,确定我们的测试范围.以以下代码片段为例:

/**
 * 员工业务层
 * @author DevilChen
 *
 */
@Service
public class EmployeeService {
	
	@Autowired
	EmployeeMapper employeeMapper;
	
	/**员工删除
	 * 
	 * @param id
	 */
	public void deleteEmp(Integer id) {
		// TODO Auto-generated method stub
		employeeMapper.deleteByPrimaryKey(id);
	}
}

以上业务实现类中只有一个方法,即根据员工id删除员工记录,若某次变更,我们新增了一个需求,即批量删除,如下示例:

/**
 * 员工业务层
 * @author DevilChen
 *
 */
@Service
public class EmployeeService {
	
	@Autowired
	EmployeeMapper employeeMapper;
	
	/**员工删除
	 * 
	 * @param id
	 */
	public void deleteEmp(Integer id) {
		// TODO Auto-generated method stub
		employeeMapper.deleteByPrimaryKey(id);
	}
    /**批量删除
	 * 
	 * @param id
	 */
    public void deleteBatch(List<Integer> ids) {
		// TODO Auto-generated method stu
		EmployeeExample example = new EmployeeExample();
		Criteria criteria = example.createCriteria();
		//delete from xxx where emp_id in(1,2,3) 
		criteria.andEmpIdIn(ids);
		employeeMapper.deleteByExample(example);
		
	}
}

我们可以预见的是,若执行原有用例,则肯定无法覆盖deleteBatch方法,根据覆盖情况,我们需要新增测试来覆盖新增代码.

以上仅描述了一种新增需求的情况,另外可能还存在的使用场景包括,若一个业务实现存在多个分支,则可根据分支覆盖情况完善测试用例,确保每条分支的处理结果均正常.