我们究竟需要他具备什么样的测试思维

    在面试中（无论是别人面试我还是我面试别人）常常都会给出一些具体的情况要求对方写出测试用例

 

    比如说一个标准的登录框及注册，基本的用例思路是这样的：

    1.从字符的有否考虑：正确错误的用户名密码，有无用户名密码，空格过滤等

    2.从字符的长度考虑：利用边界值的方法尝试过短及过长的用户名密码等

    3.从字符有效性考虑：特殊字符如/,/等，中文用户名及繁体字用户名等

    4.从安全性考虑：注入式BUG，是否明文传递参数，DDOS防护，访问控制等

    5.从附加功能考虑：保存密码功能等

 

    实施上，在面试中可以将面试官给出的测试案例的方方面面全部回答出来的人并不多，特别是，如果题目并非如上题这种常见的例题而是一个更直接的内容，因为过往的工作经历，应答者的思考多少有些局限性。

    我常常和同事讨论，当我们拿如此这般的题目去询问一个面试者，我们固然是希望借此判断对方的测试思路，但究竟我们期望得到的是一个什么样的答案呢？

    是不是我们一定要面试者在回答中绞尽脑汁给出所有的答案呢？

 

    答案是否定的。

 

    比如上文所提到的测试题，若是一个经验并不充足的人，可能只能想到前3点。而后两点，则更有赖于灵光或是他人的指点。

    一个测试团队的进步，除了测试人员本身的素质高低，更多的依赖于团队本身的合作和集思广益。并不需要强求某个人员一定要想到所有的方方面面，而应该更多的通过管理的手段，将彼此的测试思想扩散出去。

    为此，笔者所在的团队使用的是以下两种方法“

    1、建立通用测试用例库

         根据常见的测试类型及模块，建立长期有效的通用测试用例库，并在实际的使用中不定期更新，如上文所提到的登录框功能，在笔者所在的团队中原本的测试用例只有寥寥数条，但随着时间的发展和各种实际运用，已由不同的人员不断扩充发展至数十个方面。

    2、不定期开展用例设计头脑风暴

         不定期将一些典型的测试案例提炼出来，作为题目发放给各位同事要求做答，事后再开一个小会，将彼此的答案公开讨论。通过此种方法，观察和学习他人的测试思路，也能在会议中产生新的想法和思路。

 

    一个人的想法毕竟是有限的，更重要的是将大家的想法保存和复制，要建立一个高效的测试团队，除了严格要求各个测试人员本身的素质，更重要的还是要将整个团队融合起来，使得彼此经验能够更好的分享和传播。

    回到最初的问题，对于一个新加入团队的员工，给出一道题目，到底需要什么答案，需要什么样的开阔性思维呢？

    其实答案还是举一反三，但并不是你提示他可以尝试字符有效性，对方便能想到DDOS攻击。事实上，我认为一个测试人员，特别是对于一个你并不了解其实际能力的测试人员，对于用例的设计思路，只要他能够习惯性的利用等价，边界，正反呼唤的原则去思考，就已经是一种合格的思路。

    如果你提示他，不妨试试过短的字符串，他便能反映到，过长的字符串也是一种方法

    如果你提示他，不妨考虑一下过小的数字，他便能想到，过大的数字也是一种错误

    至于其他的思路，权限控制也好，破坏性测试也好，他只是一时没转过弯来，一时没有看到罢了。

    只要你告诉他一条新的路，还怕他走不下去吗？