测试用例设计笔试题，就可以区分菜鸟和大神

 相信不少朋友在笔试的时候都遇到过测试用例设计的笔试题。通常是一个登陆页面，上面有用户名，密码的输入框，再多一点的有个验证码。

不过要是你见到的是以下的这道测试用例设计笔试题，不用问，面试官一定是看过《Google软件测试之道》的。

出题：
在一个Web测试页面上，有一个输入框，一个计数器（count）按钮，用于计算一个文本字符串中字母a出现的个数。这里的问题是，请设计一系列测试用例来测试这个Web页面。

 

 

 

很多朋友可能拿到这道题的时候已经开始写下1.2.3.了，不过根据经验上来说，追求数量而非质量的倾向，是一种低效的工作方式。

 

特别在有面试官在旁边看到你答题的时候，请保持沉思者状保持10-15秒。

能够针对题目提出一些问题来的候选者会被认为更有潜质来做测试人员，比如大写还是小写？只是英语吗？计算完成后文本会被清除吗？多次按下按钮会发生什么事情？诸如此类。

 

通常说来，我们考虑一个测试对象的时候至少从以下六方面来考虑：

• 功能性

• 易用性

• 可靠性

• 性能

• 安全

• 兼容性

 

如果你是一个测试菜鸟，从功能性出发，你可能会列出以下一个典型的列表：

• “banana”：3（一个合法的英文字）。

• “A” 和“a”：1（一个简单有正常结果的合法输入）。

• “”：0（一个简单的结果为0的合法输入）。

• Null：0（简单的错误输入）。

• “AA” 和“aa”：2（个数大于1并且所有字符都为a/A的输入）。

• “b”：0（一个简单的非空合法输入，结果为0）。

• “aba”：2（目标字符出现在开头和结尾，以寻找循环边界错误）。

• “bab”：1（目标字符出现在中间）。

• space/tabs：N（空白字符与N个a的混合）。

• 不包含a的长字符串：N（N大于0）。

• 包含a的长字符串：N（N是a的倍数，试试龙妈的名字）。

 

 

更优秀的测试工程师，会开始考虑后面五个方面，设计以下用例

• 质疑界面的外观、调色板和对比度（这与相关应用风格一致么？）

• 文本框太小了，建议加长以便显示更长的输入字符串

• 这个应用能否在同一台服务器上运行多个实例，多个用户同时使用是否会有问题。

• 是否会根据用户的输入自动匹配内容？

• 建议使用真实的数据，如从词典或书中选择输入内容。

• 提出疑问：“输入的数据是否会被保存”，输入字符串可能包含地址或其他身份信息。

• 输入HTML和JavaScrip，看是否会破坏页面渲染。

• 尝试复制/粘贴字符串。

• 提出疑问：“计算足够快么？在大并发下使用”。

• 提出疑问：“用户怎么找到该页面？”

• 提出疑问：“有快捷键的设置么？比如输完字符后敲入回车键而不是点击提交按钮”

 

 

还有一些测试点，只有经验丰富的测试工程师才会想到

意识到计算会通过URL-encodedHTTP GET请求传递到服务器，字符串可能会在网络传输时被截断，因此，无法保证支持多长的URL。

• 建议将此功能参数化，为什么只对字母a计算呢？

• 考虑计算其它语言中的a（α，Alpha）。

• 考虑到该应用是否应该国际化。

• 考虑到输入法全角输入和半角输入是否相同。

• 考虑编写脚本或者手工采样来探知字符串长度的上限，然后确保在此区间内功能正常。

• 考虑背后的实现和代码。也许已经有一个计数器遍历该字符串。

• 提出疑问：“HTTP POST方法和参数会被黑掉码？也许有安全漏洞？”

• 用脚本创建各种有趣的排列组合和字符串特性，如长度、a的个数等，自动生成测试输入和验证。

   

相信很多看完上面列表的朋友，内心是这样的：

 

不要尝试去背上面的列表；好吧，就算你背住，也希望你是在理解的基础上背完上面的列表的。其实，最好的方式就是自己拿一张白纸，先写下题目中自己考虑的答案再对比以上列表，有遗漏的地方会记得更牢固的。