如何体现一个人设计测试用例的水平
今天碰到一个做测试2，3年的人。本来是想考察一下设计测试用例的水平的，但想着想着，不知道怎么去体现。。。。
刚做测试的时候，也经常碰到一些面试官问怎么测试笔啊，怎么测试杯子啊什么的，
但是现在觉得对一个不是入门级的人员，幼稚了点，毕竟测试更贴近于所作的项目。。。
再说现在这些东西网上一抓一大把。。。
反向思考自己，如果去面试，怎么体现设计测试用例的水平呢（因为自己不怎么想做流程方面，觉得编写测试用例也挺不错的）
有想法的人请讲讲呗，拜谢，呵呵 我想的是，如果招聘有经验的测试人员，应该是已经做过的项目和公司雷同。
那应该让面试的人自己选一个曾经的功能模块或需求点，先介绍一下，然后讲一下测试的思路
可惜的是今天面试的时候，是被临时抽过去的，看简历上也没看到雷同的项目。。。
不晓得项目经理啥意图。。。 1、考察他对曾经做过的测试项目熟悉程度：最好能考察到代码级。
2、测试经验考察：一个项目的成功考虑的问题是多方面的，就你作为考官熟悉的方面由浅入深的提一些问题：如自动化案例的设计、安全性测试的关注点是否与软件自身设计特点有所侧重等。
3、考人先考自己，自己先来思考一下提出的问题。看看能考察到那些是必须掌握的知识，那些是熟悉的知识，那些是了解的知识。对应的提出问题，也可以考察面试人员是否对工作有积极性，如果不积极是不会主动学习项目关联知识的。
也就想到这些吧。版主心里应该有谱，只不过想的太多思维就打乱了。::ybaojc::: 俺不打算考察别人的，考察别人也是种学问，还不很懂，
俺是被拉去也是充数的
但是很认同考人先考自己，所以自己模拟考考自己，呵呵 能真正做到自己模拟考自己的人，是很难得的，因为他不容易把握自己的水准，只有当一个人能衡量出自己真正的能力时，他才是真的牛人！ 感觉写用例最主要的是把握需求，把需求细化了，不管是别人提了的还是潜在的，事前尽量挖掘出来。业务逻辑先理清。其次框架及模版很重要，有时候开发对需求把握不好，就会出现设计上的频繁改动，你的用例得随着改，有恩一个合理的框架，就不会在频繁的改动中迷失方向，导致覆盖遗漏。个人认为，写用例的另一个作用是估算工作量，可以从项目拿时间，保证执行阶段的顺利。
页:
[1]
