编写测试用例的必要性

发表于:2009-03-10来源:作者:点击数: 标签:编写
我知道的有关 测试用例 情况: 听一个在微软工作的朋友说,他们每天写完的代码,在晚上下班之前都要check到一起,执行一遍用例,当然都是自动执行的,那个地方出现了错误会红灯提示,所以这个用例一定是事先写好的。 听一个在比较大的公司(1000多人)的朋友
我知道的有关测试用例情况:

  听一个在微软工作的朋友说,他们每天写完的代码,在晚上下班之前都要check到一起,执行一遍用例,当然都是自动执行的,那个地方出现了错误会红灯提示,所以这个用例一定是事先写好的。

  听一个在比较大的公司(1000多人)的朋友说,他们公司经常后补用例的。

  我一直在百十人的小公司工作,领导心绪来潮的时候要求写用例,可是多数情况是可写可不写的,而且对质量,形势也没有什么要求。

  对于写用例的认识,我经历了这样一个过程,一开始是很形式化的,质量也很一般,回想一下跟现在的新人写的一样,所以觉得毫无用途,所以后来就不怎么写了。可是面对新项目的时候,问题出现了,无论在测试之前你多么的了解需求,业务,在提交测试的时候,很是会有覆盖不全的情况,我们的大脑毕竟不是电脑,我们在测试一个新系统的时候,不可能在到脑中勾画出每一个小功能,甚至每一个表单的所有分支,所以我开始写用例了,对任何一个小功能都是以流程的方式,每一步有多少个分支都清晰的列出来,我觉得效果非常好,按照这个测试完成之后,晚上睡觉都安稳多了,这是自己给自己的保证。这个用例可以说是一个很详细的用例了,只适合新项目的新版本测试,回归的时候就没有这个必要了,这样不符合性价比。那时候,我们的回归都是凭着大脑测试的,没有感觉到任何问题,只是在牵涉到流程性比较强的项目时才写一些流程用例(包括正常流程和常见异常流程)。可是现在,我在新的公司工作一年多了,问题出现了,项目特别多,差不多有十几二十个,由于测试的人少,每个项目都要测试,所以在回归测试的时候经常会搞不清状况,记不清业务要求等(也许是我老了,记忆力不好了:()而且公司客户是比较强硬的那种,公司领导是认为测试过的东西就不应该有问题的那种,所以搞得自己经常提心吊胆,生怕给客户的东西出现问题。这时候,我发现了回归测试用例的重要性,以前没有写过,有个大概的概念就是写个简单的流程,回归的时候执行一下就行了,在一开始的实施过程中发现了问题,写的过于简单还是让我在回归的时候无从下手,在思考与实践中,我自认为自己找到了一种不错的编写方式:为了保证质量,回归在功能上要覆盖所有的功能按钮,这部分在写用例的时候要每个操作写一个用例(简单说excel的一行),操作结果中记录该操作应该返回的界面,一定要一个操作对应一个结果,这样才具有可操作性。在每条用例的后面设置“通过”和“不通过”的按钮,这样回归的时候就轻松了,过一个勾一个,在测试几乎没有改动的地方时,简直是休息,哈哈。当然也不要忽视业务流程,权限等方面的测试,可以另起文档,以自己比较喜欢的方式编辑就ok了!

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