关于测试用例库我有几点想法:
1.首先我们代码库的代码经常是非常丑的(所以我才需要不断的重构)。
2.每次测试时如果我们能够保存一个测试用例将是非常好的一个习惯。首先从代码上看,应该说每个测试用例对应了代码的一处地方。
因此实际上就将代码与测试用例关联起来了。
3.如果我们坚持构建测试用例库,好处如下:
a.测试用例库对所有的组内成员开放,所以,不单是测试人员能够做测试。
开发人员每次添加一个特性,可以利用测试用例库自己先做一次单元测试。
b.使我们做测试更有条理-能够知道现在为止做了哪些测试,哪些没有测试,并且对应到代码上实际体现了代码的覆盖率。
c.可能的话我们可以开发自动测试脚本,如此,可以简化每次的测试(尤其是在新特性加入或者改BUG时)。
测试用例库应该随着项目的发展而不断的充实,才能真正形成公司内部的积累,当然有时随着项目的产品的改动,有些测试用例可能变得过时,此时可以剔除。
实际上,国外有人靠卖测试用例挣钱的。不过,这种眼光不是每个公司都能看到的,很多公司,很多leader不一定能看到这一点。
1.首先我们代码库的代码经常是非常丑的(所以我才需要不断的重构)。
2.每次测试时如果我们能够保存一个测试用例将是非常好的一个习惯。首先从代码上看,应该说每个测试用例对应了代码的一处地方。
因此实际上就将代码与测试用例关联起来了。
3.如果我们坚持构建测试用例库,好处如下:
a.测试用例库对所有的组内成员开放,所以,不单是测试人员能够做测试。
开发人员每次添加一个特性,可以利用测试用例库自己先做一次单元测试。
b.使我们做测试更有条理-能够知道现在为止做了哪些测试,哪些没有测试,并且对应到代码上实际体现了代码的覆盖率。
c.可能的话我们可以开发自动测试脚本,如此,可以简化每次的测试(尤其是在新特性加入或者改BUG时)。
测试用例库应该随着项目的发展而不断的充实,才能真正形成公司内部的积累,当然有时随着项目的产品的改动,有些测试用例可能变得过时,此时可以剔除。
实际上,国外有人靠卖测试用例挣钱的。不过,这种眼光不是每个公司都能看到的,很多公司,很多leader不一定能看到这一点。