先贴本文的重点图：
简单说吧，你们对设计测试用例有什么看法和新的补充嚒？
测试用例的设计这个问题，现在好多时候我们在面对一个功能，比如说一个帮派列表，问我们自己应该怎么测，怎么测试用例的时候你们怎么想？
直接想到的是：测试点->用例
是的，测试点->用例是传统的做法。
你们有没有想过测试点之上其实还能归类呢？或者说至少在测试点同一等级的概念里应该划分一些典型类型来进行测试。
还是拿那个帮派列表来说，所谓的帮派列表。
就是一个面板包含所需列举信息的一个列表。
“我的测试用例都是简单随意的。老毛病”这是近来我经常听到的一句话，测试员A经常唠叨。
1、界面显示是否正常，各种浏览器、分辨率，文字是否显示正常
2、这个数据是否和数据库一致
3、按钮是否正常使用
4、上一页下一页按钮是否正常，能不能正常翻页
5、列表标题是否支持排序，排序功能是否正常
就是比较散乱的测试条例，写得很随意
所以这是个问题，在我看来，测试点这种东西过于偏重了具体测试环境和测试对象，而这个是容易造成测试人员毫无积累的窘境，或者说我们理解的只是狭义的测试点。
列举一下，这也是我最早在以前的博文中提到的基础方法：
传统做法是这样分，功能和数据，首先测功能，各个按钮的功能是否正确，其次看数据。
你们有没有想过测试点之上其实还能归类呢？或者说至少在测试点同一等级的概念里应该划分一些典型类型来进行测试——特别是我们带新人，或者说跳槽去其他公司再次面试（别说没有可能），遇到这种帮会列表问题的测试题目时，我们应该怎么去面试回答呢？
测试点之上或者说跟测试点平等的地位，应该还有一种关系我们是忽略了的（至少现在还没有非常重视），那就是测试类型。
比如：界面测试用例，功能测试用例，大数据测试用例
再比如：正常测试用例，异常测试用例
再比如：异常测试用例里面要有单独的一类测试用例，专门处理各个测试点里的掉线，顶号登陆，下线，离线，这种情况如果我们只是单纯的区分功能和数据，首先测功能，各个按钮的功能是否正确，其次看数据，这种思路很泛，我的意思是这是大道理，并不能由理论转化成实际操作，并不能直接由说转化成如何做，欠缺了些中间的借鉴意义，所以我觉得这方面的话测试类型划分意义更准确些。
希望对大家有所帮助。
延伸阅读——《探索式软件测试》
里面作者在说到测试就用旅游来比喻，他将我们测试的系统分为商业区，娱乐区，破旧区，历史区等，针对不同的区域有着不同的测试方法，思想就和我上面提到的差不多。
各个区域：商业区，历史区，旅游区，娱乐区，旅馆区，破旧区
商业区测试类型：
指南测试法 要求测试人员通过阅读用户手册并严格遵照手册的建议执行操作。
卖点测试法 找到那些最能卖钱的特性进行测试
地标测试法 先选择地标，然后在软件中执行类似于在森林中地标间跳跃的动作
极限测试法 向软件提出很多难以回答的问题。如何使软件发挥到最大程度？哪个特性会使软件运行到其设计极限？哪些输入和数据会耗费软件最多的运算能力？哪些输入可能欺骗它的错误检测例程？如果软件用于产生某些特定输出时，使用哪些输入和内部数据可以不断挑战软件的这种能力？
快递测试法 专注于数据，确认哪些被存储起来的输入数据并“跟随”它们走遍软件。
我这里是粘贴了一部分，毕竟那本书提到的测试法很多，有些就像我说的异常测试，和软件对着干，希望得到更多进步的你可以去看看那本书。
他把我们测试软件比做去一个城市旅游，于是这个测试又叫做漫游测试。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
