如果说代码对于程序员来说,是剑士手中的剑,只有剑才能体现他的价值;那么,测试用例对于测试人员而言,就是剑士手上的剑谱,拿着很有用,不拿也在心中有个大概.
测试用例是指导测试执行的关键,越是详细明了的用例,越能找出更多的bug.写测试用例几乎是每个测试人员必须做的事,因为他着实有用,同时,大多数测试人员也讨厌写用例,麻烦且耗时,宁愿多花点时间执行测试,也不情愿写多几条用例.
也有部分原因是,一些软件项目版本迭代快速,给测试的时间经常是压缩再压缩,有时多个项目同时交付测试,测试人员只能忙中求快,无暇顾及用例的编写.
还有个可恨的地方,就是阅读别人写的用例.正如程序员阅读其他人的代码时生不如死的感觉,测试人员看其他同事写的乱七八糟的用例也是一头雾水,有时根本找不到用例的重点在哪,心里暗忖,这测的什么鬼,意义在哪.
光说写用例的烦心事,是不公平的.测试用例的作用不用多说,就是提供清晰的逻辑,详细的方法,以免在测试中遗漏重要的用例.相信不少人都会踩过坑,不编写测试用例直接执行测试,产品上线之后突然发现漏测用例,导致出现了bug,只能讪讪的告诉领导,等着挨批.
用例是非写不可的.打个不好听的比方,测试人员在执行用例的时候就是个瞎子,没有用例这根拐杖,磕磕碰碰是在所难免的.
不可抗拒的事情,做起来也不用那么委屈.
测试用例的形式很多,word,excel,testlink,思维导图等,各有优势,可根据测试时间,软件功能类型等灵活编写.时间紧迫,功能流程性比较强,先用思维导图理清思路,尽量把所有的流程都走一遍;时间宽裕,功能之间相关性不强,则在用例管理系统(如testlink)仔仔细细的思考每一种可能性,把用例描述清楚,既方便当下的测试,也能让其他人需要了解时快速的理解其中意义.
测试时间再少,也得挤出时间在脑海中过一遍所有能想到的可能性.先把关键点记录下来,不求描述的多详细明白,但也要面面俱到,保证一般用例都包含在里面.详情可等到以后测试完毕,有时间再去补充.这是件小事,豆丁大的小事,但请要求自己做好,正是这样的小事,能让你免于遭受大部分用例漏测的困扰.
上面吐槽过看其他测试人员的测试用例是件糟心事,这里面也涉及到测试管理的问题.好的测试团队理应在测试用例的格式和内容上做明确的要求,至于用例规范的粒度做到多细,取决于测试人员对其他人员用例的容忍度多高.规范的执行力度也很重要,团队越是按要求执行用例编写的规范,用例执行的效率自然更高,用例也更易于后期维护.
如果说你的团队并不做用例编写的规范,你也想写好用例,但大家都很随意应付,完全达不到想要的效果,那自己做好不也没多大意思?不然,这恰恰是给了你一个体现价值的机会.
小事情里面见真章.测试理论、测试工具、测试技术,五花八门的内容,任何一样都可以吹得天花乱坠,但若连测试用例这样的小事都没做好,谁也没资格说自己是个优秀的测试人员.
