交叉测试
交叉测试
我原来的测试方案是由项目经理一个人写自动化测试代码（白盒测试），这种方案虽然功效很大，但PM的压力太大，可能出现迭代到期仍然无法完成测试代码的情况。交给其他队员却不放心，毕竟除了测试，自动化测试还附加了代码重构（提取公共类库）的任务。
交叉测试的过程
每个迭代阶段完成之后，团队成员互相检查别人的制品，并提交测试报表。制品包括系统模型、系统原型、代码（注释、代码风格）、数据表等。
交叉测试的优点
l 对模块的了解不只局限在一个开发人员身上，分担了项目的维护风险；
l 规范代码，至少在注释和代码风格方面能保障；
l 一个人思考问题难免会有遗漏或盲点，多一个人查漏补缺会避免不必要的返工；
l 通过编写白盒代码的自动化测试，能够确认功能真正完成了；
l 把编写自动化测试的工作分担到了每个人的身上，减轻了PM的压力；
交叉测试的缺点
l 交叉测试会占用开发时间，熟悉别人的代码和编写测试都要花不少的时间，我估计测试时间是开发时间的1/5至1/3；
l 队员水平参差不齐，编写者和测试者的代码质量无法保证；
l 不能保证每个人写的测试用例都全面覆盖了模块的业务；
l 虽然避免了一个模块只有一个人了解的情况，但两个人了解也无法实现代码重构的目的；
l 交叉测试会导致责任逃逸，通过测试的任务，最后出了bug没有责任人。
交叉测试条例
l 测试前先编写测试用例，由任务编写者和测试时共同制定测试用例，这样在编写的过程中，达到了业务讲解和理解的目的；
l 测试用例必须覆盖模块的所有任务；
l bug应该属于团队所有成员的，不应该由某个人来单独负责，bug也作为一项任务；
l 关键性模块才进行交叉测试，这样既避免了交叉测试占用太多的开发时间，又避免了核心业务的不稳定，我觉得交叉测试时间以一天内能完成为宜。
浙公网安备 33010602011771号