其实任何事物都有其发展规律，就像是月缺了圆，花开了谢。测试也不外乎如此，时代就像是车轮，在拼命的进步着。我们只有两种选择，要么跟上，要么out。 看到很多的测试培训，其实不乏过时的理论，也不乏一些不太实用的工具。其实一直想要有机会为广大的测试同胞分享一下心得体会。可无奈工作略显繁忙，加上确实没有人给我提供合适的舞台。所以此事暂且搁浅。 不过今日，却想要借助51testing这个平台，开《测试新说》这个专题。目的就是革新一些过时的测试观念，纠正一下过时的测试工具，也希望大家能够听我啰嗦几句，然后好好思考，之后广泛交流，我始终相信只有大家都真正的解放思想，中国的测试业才会向前迈一大步。
闲话就倒这里，今天的话题——不破不立。那么我们有什么可破的呢？恕我大不敬，问一句“等价类划分，边界值测试方法指导下，发现的bug/case比高嘛？你用过几次决策表设计测试用例，时间来得及嘛？”其实一直有句话，叫做实事求是，测试更是一个实践重于理论的行业。传统方法日益过时的原因，我看来如下： 1)测试基础理论普及，绩效考核制度建立，促使研发同学一定程度上自测。
研发同学不是傻子，如果他们懂的一点测试方法，
那么最容易上手的就是等价类和边界值，不是吗？
如此一来，我们的吃饭家伙是否堪忧呢？
如果你回答公司的研发不自测，那么我说这样的公司还是自己辞职吧，
否则等你出来后一定会感慨，洞中方一日，世上已千年。
而移动互联网的一大特点，就是节奏快。
等您还在那苦心设计决策表的时候，人家好几个版本早已经发布上线.
也积攒了很多的用户。
但凡有点全局观的老大是不会允许这种现象存在太久。
以上是真真切切的现状。不过我还是要对那些传统的测试方法总结者表示深深的敬意，至少他们满足了那个时代的测试需求。可是就像我开头所说，一切都在发展。其实很多人都看到了这点。我看到过一本书，叫做探索式测试，也看到过咱们的一篇文章，叫做《错误猜测法》 初看下去，可谓别出心裁，可细想一下，难免觉得无章可循。或者流于传统。斗胆借用一下，我们知名文章中提到的一段话：
实例：测试**学院的课程搜索输入框
既然是用错误猜测法，那么我们首先列出可能导致搜索结果出错的情况，如下：
1 . 单个空格，多个空格
2 . 字符串前面有空格
3 . 字符串后面有空格
4 . 转义符 "\n"
5. Null
6. 特殊字符
7 . 通配符 *
8.空串，很长的字符串 以上是文章中提到的一个具体实例，慢慢分析下。
1)上述条目：1/4/5/6/7是纯纯正正的传统等价类划分，
而且很确定的属于无效等价类。
对一年经验的测试人员来说，这属于经典的无效等价类，
理论上是必测试。
空，特殊字符，转义符，这些用例不用猜测，也并非无章可循。
2）2/3则属于常规的测试用例组合吧，只是字符串和空格的组合情况。
按照决策表准确来说有六种：
只有空格/只有字符/空格在前/字符串在前/空格夹着字符串/字符串夹着空格
我们只是猜测其中的两种，实难有说服力。
且就我经验看，出错更多的往往是字符串夹着空格，或者空格夹着字符串
3）8条实在不属于规范的测试用例，很长是多长？
一个两个还是一万个字符？很难操作的。
且作者自己也提到所谓“错误猜测法”有三个要素：经验、知识、直觉。从字面意思不难看出，太多的主观性，也缺乏普及性，难免有点阳春白雪，曲高和寡的味道。
不过我仍然是佩服作者的，至少他敢于思考，敢于革新。怎边变的更好我们有的讨论。但没有革新的意识，那就真的没得谈了。不是吗？其实给测试方法请名字，我不太建议用“猜”这个词。因为显得有些轻率与不靠谱的成分。
其实，我一直有个想法，可以一起讨论下，叫做——痛点分析法。这个可谓老少皆宜，也少了主观的成分。 何为“痛点”前面的文章已多次提到，实不想在此赘述。 只是我不时想起一句话：假舆马者，非利足也，而致千里；假舟楫者，非能水也，而绝江河，君子生非异也，善假于物也。
痛点的把控也是建立在用户的反馈和竞品的经验学习之上。用户反馈的收集分析渠道很多，GP，appstore，各大论坛，和应用市场。我认为不管你做哪方面的测试，先学会知己知彼，仔细阅读用户反馈，它能给你无尽的灵感。如果能把这些反馈分类，整理，量化，过滤。那便更具有指导意义。 其实前辈已经总结了不少的经验，不要说你做的产品多么多么的创新，你说出任何一个产品，我都能在现有的产品中找到你的影子，进而找到相关的反馈。
回到实际的测试中，传统的测试还是需要有的，因为他直接影响覆盖率和基本功能，传统的测试就像是一张网，保证大面上过得去，这里你的边界值，和等价类就用的上，但是就像我之前所说，这是一个新的时代，传统的测试比重在测试这边要放低。而痛点测试，的比重要适当的放高。旨在于：
1）避免以前的反馈点，出现在即将发布的版本。
能做到“不二过”就真的很牛了。
2） 更高的境界是更上一层楼，站在用户的角度想问题。
尽量避免可能的痛点，防患未然。
回到那个具体的例子课程搜索输入框，根据类似有搜索框的产品的反馈积累，我认为除了传统测试之外。 测试的痛点在于：
1)课程搜索的查询效率。
夸张点，查一门课程几分钟，反正我是懒得用，很多事后不是查的准就行。
2)搜索框的模糊匹配智能程度。
比如我搜索"语"能否出来语文。
比如我索‘y’'呢？会出来“语文”还是“英语”
如果我们连这个都不知道，如何能说对产品质量良好的把控呢？
3)搜索框智能提示的舒适度
比如我输入“数”能否智能补全为“数学”
且是否有类似下拉列表的形式，展示其他的联想结果，供选择？
4)搜索框贴心的历史记录
很多时候我们关心的课程就那么几门，有点历史记录，是不是方便多了。
5)搜索框的美观性，交互性。
夸张点说，如果一个搜索框放在右下角，且小的和芝麻似得，你会用嘛？
如果搜索框是核功能，可以考虑居中，且适当的添加css效果。
……
当然涉及到不同形态的产品，有更具体的特点，这要靠大家来发挥了。我只是想说，有的时候我们需要思考下，我们究竟是为了“做出”一个产品而测试？还是为了“做好”一个产品而测试。
