编写软件测试用例并非一劳永逸

发表于:2010-07-23来源:作者:点击数: 标签:软件测试一劳永逸编写
编写 测试用例 并非一劳永逸 软件测试 如果问一些测试朋友是不是写一次测试用例就ok呢?多数人都会回答,不是.因为要根据 需求 不断完善,评审阶段也要继续修改. 若再问,评审后进入集成测试阶段,你依然在不断地把执行中的实际情况反应到用例中吗?可能坚定回

  编写测试用例并非一劳永逸软件测试

  如果问一些测试朋友是不是写一次测试用例就ok呢?多数人都会回答,不是.因为要根据需求不断完善,评审阶段也要继续修改.

  若再问,评审后进入集成测试阶段,你依然在不断地把执行中的实际情况反应到用例中吗?可能坚定回答yes的人就少了;我承认,我就是不敢说yes的一员。

  集成测试时间紧张;实现与用例描述稍有不同;逻辑判断层级有些许改动……可能都会成为我们不持续更新用例的借口。往往大的功能点的改动,我们都会认真记录在用例中,保证更新,而小的改动点则是最容易被我们忽视的,因为不伤大雅。

  但是之前跟师傅葵儿做一个日常,文案有变动,在执行的时候,师傅都严格把用例修改过,很有触动,认真要如此;最近做项目,也经常去查看参考之前项目的用例,用例中没有反应最正确的实现,就成了我最头疼的事情。

  往往危害到自己利益,给自己造成不变的时候,才知道当初举手之劳是多么重要。我们的用例是一笔极大的财富,项目结束都会把用例入库。但入库并不是永世封存,其意义是给后来需要参考的人提供帮助,如果不能保证用例的正确性,会误导之后引用的同学,不仅无用,反而有害。而且在用例执行阶段,交叉测试也会给执行自己这部分用例的同学造成困扰。

  所以保证我们提供给其他人看的用例,是对项目实现最正确的反映,不论项目中,还是项目后,这都是我们义不容辞的责任。之后日常的完善,虽然不会在项目用例基础上修改,但最好也可以跟功能点关联起来,方便查看功能变更引起用例的变化。现在我们日常跟项目的用例是分开来写的,也许按照功能点关联起来,能起到更大的参考作用。

  

原文转自:http://www.ltesting.net