对测试用例的看法

前一天去一个不是很想去的公司面试，想想好久没有面试了，去积累一下面试的经验，以便过几天不至于紧张。51Testing软件测试网fo;R#Kg(c t+T^

$I;i!lX_A&y0d%J0开始的几个问题回答的还不错，记不清是第几个了问题了，

“有三年的测试经验了，对测试用例这块有没有自己的见解”51Testing软件测试网5Y(qB}"`

Pqz{6y$L0一时间我似乎蒙了，不知道该怎么回答，回答一些理论上的知识吗？那些又不是我自己的看法，人家问的是我的见解。三年了，前两年的公司基本没有什么测试流程，更不用提测试用例的编写了，写不写都可以，那时候当然就是偷懒不写了，或者是计划上写了，自己也象征性的写了些测试用例，可是真正到测试的时候也不会去按照自己写的去跑。正是因为这样，我选择了离开。到了现在这家公司，流程上面很成熟，没有测试用例是不行的，但是因为是外包而且组也是刚刚成立，也因为项目的业务流程很复杂，所以进一年来我们都是做回归测试，这样可以更好的了解业务上面的知识，即使快接触1年了也会有不知道的东西，不会跑的case。可想业务的复杂程度。编写case的机会也不是没有，但只是小小的一个功能。或许是因为自己的心虚，所以坦白说自己没怎么编写过case，这样一来，面试官觉得我虽然有3年的工作经验，但是还不能是个senior的tester，所以匆匆的就结束了面试。51Testing软件测试网 mK[(T Ccb

回来后，我仔细想了想，3年虽然写case的机会不是很多，但是自己也是有些对case的看法的。51Testing软件测试网c%K E]
|/]-XQ

]'T)u(j5l7jZ \0首先从整体上面看，测试用例是必须要有的，虽然可能刚开始建立的时候会难些，有时候我会想如果我再回去原来的公司，我应该怎样做，我想我首先要做的就是针对产品建立测试用例库。不要说case没有用什么的，或者写起来很乏味之类的，对于原来的公司或者说很多公司都是这样的，产品不是release一个版本就finish了，而是会不断的有升级，不断的要维护，所以建议测试用例库是不要的，一旦有了用例库，这样以后涉及到的版本的升级测试就显的容易，case主要针对新功能就可以，版本发布后执行之前的case进行回归测试就可以。相反如果没有，自己都不清楚该测什么，不清楚哪里没有测，是件可怕的事情。都说不能被一块石头绊倒两次，如果有了用例库，那么平时出现的一些刁钻的条件下产生的问题都被记录在案，下一个版本，或者下一个产品就不会被同类的bug造成经济上的损失。所以说测试用例不仅是保证测试覆盖率的很好的工具而且也是个知识积累的过程。此为一，测试用例一定要有。51Testing软件测试网!?1g }oR8|9ec6?

7o/\nrg ? i/G F`0第二点呢，有了测试用例还不够，要对测试用例进行分级。一些case是保证基本功能的，在验收测试（acceptance test）时执行的，一些case是基本功能的扩展的，一些是用户很少用到的，但是如果出错也会影响公司的形象的。有了这样的分级就可以确定什么时候用哪些case。如果项目的时间很紧张，也可以选出基本的case执行。保证基本的功能。现在做得项目就是这样的，case分了4个级别，在验收测试的时候只要跑0，1级别的就可以。51Testing软件测试网(r an-@a_5d[

`_xY?Z#Qq%xa0e0第三点，case可以有不同的版本，这个就是针对产品的升级。产品升级case当然也要跟着升级。51Testing软件测试网e9PlFa|'^\4P5[

5cb~O y+jxX1K0第四点，不要care太多case的管理工具，都可以。excel有时候就可以，不要在测试管理工具的选择上面花太多的时间。

Y GT)K^R.]N0第五，在具体case的编写上面，可以利用黑盒测试用例编写方法进行编写，只要参考对象是Spec。保证测试的覆盖率。case可以写的简单些，只要执行的人明白即可。现在公司的那些case有时候就是一句话。当然这个一句话是有上下case的背景的。也可以一个case包含很多的具体的小case。51Testing软件测试网Xi~d6IHt&~2X

暂时想到这么多，希望看过这篇文章的可以提供更多的内容。我一会不断更新。