近些天得到学员面试的一些反馈，还有自己的一些亲身感受。写了一篇关于如何设计测试用例，在实际的工作中设计测试用例的时候，我们更加要关注的点在那里以及在面试的时候实际到测试用例这块内容你怎样回答才能是面试官满意。

　　今天学员田*给我说了一道面试题目：

　　收银员把所收的钱将会填写到文本框中，请对此文本框编写测试用例。

　　对一个文本框进行测试，书上学过：如果是非数字的输入框需要考虑等价类，有效的等价类和无效的等价类。如果是数字的输入框，要考虑边界值。当时面试官对学员田*说：几乎北大青鸟出来都是这个答案。为什么呢？因为我们书上就是这样写的！！

　　当时对田*说：你是不是应该考虑输入的时候应该是半角还是全角呢？还有对于输入的字符你是输入一个字符就检查一次还是等输入完整个串再做检查呢？

　　书上写的当然没有问题，可面试官为什么不满意呢？感觉学员太理论化呢？结合我的自身经历，很大一部分原因是在设计测试用例的时候我们考虑的焦点是所要测试的功能点本身，比如说让你测试一个文本框，你只关注文本框本身应该如何测，因为书上有现成的故障模型我们记过去就可以了，但在实际工作中更重要的是测试是有目标和范围的。

　　最近和一个项目经理交流有关测试的一些事情，他给我的说了这样一件事情启发非常深，是关于测试用例的：

　　1.测试任何功能点，在测试用例中首先体现的是你的测试目标，如果你连目标都没有，就像没头的苍蝇乱飞。目标必须明确，假如我上班的时候只给你说你去中关村，你就纳闷了，我做测试去中关村干嘛。但你还是照做了，中关村地方大了，我怎么去中关村，到什么地方呢？去了做什么呢？你很多的疑问，很多的费解，当然也有很多的工作量在里面，可能我就是让你中关村做一次技术支持，但没有告诉你做事情的目标。如果我们设计的测试用例都没有测试的目标的话，可能就会有很多不必要的工作要做，测试用例写了半天还不知道干嘛的。但这也是我们工作中常犯的错误，对一个功能点写了5篇的用例文档，但问你为什么写这5篇，是为了找出软件的Bug，这不废话吗？测试工程师的本职不就是找Bug吗？换句话说你这5篇测试用例实现了什么测试目标呢？这个是你应当清楚的。

　　2.测试范围。对于设计测试用例，如果你测试的时候关注的范围不同，你写的用例将会截然不同。举个例子：如果你测试一个浏览器，假设是IE,如果你只关注客户端IE的话，你设计的测试用例可能如下：

　　输入www.126.com点击确定按钮

　　预期结果：能够打开126的主页

　　实际结果：

　　而如果你的关注范围还有服务器的话：

　　你应该这样设计的测试用例：

　　1.输入www.126.com点击确定按钮

　　2.浏览器自动连接服务器，服务器接到请求后，响应请求。

　　预期结果：能够打开126的主页。

　　实际结果：

　　大家可以看到如果同样是测试IE，预期结果都是能够正确的打开网页，但你关注的范围不同，体现在你设计的测试用例当中也会有所不同。

　　所以我们知道实际的设计测试用例是尽量的模拟用户的操作，但是除了模拟用户的操作以外，我们要对每个用例的目标和范围有所界定，只有这样设计测试用例我们才能真正解决实际中的问题。

　　有了我们以前的故障模型加上上面两个实际的例子还有心得体会，希望大家下次再面试遇到这块内容的时候都能够从容面对。