传统的那些测试都是狗屎！无能的人做测试只能采用那些苟且的做法V2！

andypeker

传统的测试，手段很多，但是基本思想只有一个，那就是弱智无能的：万箭齐发～

所有的测试动作，都是盲目的“覆盖”！这种做法实在太愚蠢啊～

测试的过程，基本是一个固定不变的傻逼流程，其中涉及各种文档、各种假动作、各种装模作样的会议，其实没有人懂自己在干什么！

这个傻逼流程之所以傻逼，是因为低效实在太低太低太低！

通常这个傻逼流程会以需求等表面东西为出发点，设计测试用例在需求等最表面的一层进行覆盖；同时妄想通过对这一层的覆盖达到对整个质量的保证，多么可爱又可笑啊，白日梦做了这么多年都醒不过来！岂不知质量的决定因素在最根本的代码那一层，而不在最表面的那一层！

测试用例的设计，也基本是上最原始最基本的等价类、边界值、正交组合等思想（这些思想很重要，都是来自数学和逻辑学的基础思想）；但是软件测试作为一项工程，直接使用这些最基本的思想和逻辑，这么多年了完全没有加入自己的东西，这太可悲了！

从“需求”等最表面一层出发，到代码层，中间的步骤复杂又曲折，也没有靠得住的对应关系！覆盖最表面的一层，覆盖最根本的一层，二者之间隔着一万个黄河和一万个长江，这也是传统的测试在常识和逻辑上的致命问题！

最简单的是手动测试，目的是覆盖～后来傻逼用例太多了，执行不了，就上自动化，指望代替人工提高效率，目的还是覆盖～太傻逼了！很多人搞了多年自动化，对自动化的目的的认识错得离谱～


归根结底，软件测试从业者的水平大多太低，甚至可以说大多数都是外行～


我从事软件测试9年，近两年来一直在思考软件测试的思想，摒弃和否定了很多东西～

现在只剩下一个想法：有的放矢～

如果有人对测试技术有兴趣，应该了解过探索式测试，我觉得探索式测试就是一种“有的放矢”的测试思想～


“有的放矢”的测试思想，要求测试人员对自己面前的系统、产品有深入的了解，包括但不限于架构、模式、代码、操作系统、网络、交互等各个方面；然后再通过各种手段，包括但不限于代码扫描、工具、代码走读和对比等方式，了解到哪里需要测试------换句话说就是找到“的”，这个步骤最困难也最重要！

所以“有的放矢”其实应该称为“找的放矢”！从“需求”等最表面一层出发到代码层中间有很多东西，都有可能是“的”，通过各种手段找到这些“的”，有些“的”可以在最表面的需求层，有些“的”会介于最表面层和代码层之间比如兼容问题、安全问题，有些“的”会在最根本代码的层，比如性能问题（算法问题）、稳定性问题（内存分配又没释放），等等。

核心思想就一个字：深入理解仔细思考灵活选择方法，找到位于不同层次的全部所有的“的”！

最后，选择合适的做法去执行测试，也就是“放矢”，包括但不限于手动测试、自动化、性能、兼容性、正交全组合、边界值和等价类等！


“有的放矢”的测试，不再有多的像傻逼那么多的测试用例，也不会有傻得像傻逼那样的莫名其妙的bug单，不会再有一千个用例需要回归测试时迫不得已想到自动化，不再像以前那种测试那样傻逼、低效、恶心、弱智、无能和苟且～


有人对我上面的话感兴趣吗？来聊聊～

yshuifejng

我汗呀，楼主的言论我竟然没有一个认同的，打字累，我先说一些。

1、传统的测试？都是盲目的“覆盖”？

目前应该大部分公司都认同测试尽早介入吧，项目组中测试部从原始需求介入，贯穿
原始需求->需求规格->测试需求->测试用例 ,实现需求的覆盖？ 何来盲目的覆盖？

2、傻逼流程？各种文档、各种假动作、各种装模作样的会议？

任何公司都会有适合自身的流程，确实很多公司存在上了一个大体量的流程，却没有真的QA在管控，我碰到过，可上有政策，
下有对策呀，实际的项目组内部还是会有自己一套很之有效的流程的吧。华为当年引进IPD时，也是花大量成本才在公司内推开的。
没有傻逼的流程，只有适不适合。 还有会议多的问题，那自能看会议召集人的组织管控能力了，会议目的，时间的管控很重要。

3、通常这个傻逼流程会以需求等表面东西为出发点，设计测试用例在需求等最表面的一层进行覆盖？同时妄想通过对这一层的覆盖达到对整个质量的保证？岂不知质量的决定因素在最根本的代码那一层？

首选软件质量的控制是贯穿真个软件生命周期了，通俗点说包括了各个过程的质量，一般由QA控制，然后就是测试过程中的测试质量，有QC控制，一般我们常说的测试用例一般指系统测试中的用例，QC负责执行。原始需求->需求规格->测试需求->测试用例，这个覆盖链不要存在任何疑问，这是测试基本，说是灵魂都不为过。楼主说用例在需求的最表面进行了覆盖？那我简单说下过程，分析原始需求，明白客户要这个产品干嘛，是为了解决什么问题，这样才能提出相应的解决方案，即一些抽象的业务模型，然后按业务模型拆解成一个个功能，为了实现这些功能，就衍生应该设计一个什么样的软件系统。也就是一般的SRS = 功能需求+非功能需求+系统需求+（行业规范） 。作为测试部的分析人员，必须了解需求分析，重点明白SRS中需求的描述必须可测试、无歧义。在做测试需求分析时，一般结合McCall模型和常用测试类型来提取测试点，然后在按不同的测试方法来设计用例。这是软件测试行业里的经验产物，怎么能说是无用的呢？

ps:楼主啊，9年工作经验怎么说出这么儿戏的言论，误导新人，在我认为说出这样话的人，一般是1~2工作经验，且基本是干测试执行工作，如果是测试组长或者测试经理说出这样的话，那这个团队就完了。或者楼主的文章是探索性测试的软文？

授客

每个人都绝对自己是对的，开发觉得自己是对， 按他自己的想法做，你觉得你的想法是对的，按你自己的想法做，，某某也觉得他自己是对的，也要按他自己的做法做，，，，每个人走要按自己的来，结果会咋样呢？？？？

现在会过来想想，测试效率低下的原因是不是只是楼猪说的那样呢？楼猪的说法是不是欠妥呢？

huangsong2

黑猫白猫，能测出潜在问题的方法就是好方法。

bug在哪里

为何不开发自己的测试技术

andypeker

授客 发表于 2015-5-15 21:53
每个人都绝对自己是对的，开发觉得自己是对， 按他自己的想法做，你觉得你的想法是对的，按你自己的想法做 ...

在你眼里，恐怕任何一个说法都会“欠妥”，你先说说上面的话有没有一点道理吧

andypeker

bug在哪里 发表于 2015-5-17 13:38
为何不开发自己的测试技术

你说的是开发一个测试工具吗？这个我用不不少，还是觉得思维方式最重要，思路错了或者歪了，写测试代码毫无价值------用户永远用不到那些测试代码！

Miss_love

有的放矢？你怎么做的。??

andypeker

Miss_love 发表于 2015-5-18 08:24
有的放矢？你怎么做的。??

通过各种手段，包括但不限于代码扫描、工具、代码走读和对比等方式，了解到哪里需要测试------换句话说就是找到“的”。------ 总之，凭借对被测试对象的全面而深入的了解，利用自己的大脑或者工具去分析，分析出bug的可能位置、形态和影响。本质的思维是，通过收集已有的信息缩小测试范围，然后在局部做深度研究。

没有固定的套路，世界上也根本不存在“梦想中的”固定的并且有有用的套路，只有传统的测试流程可以算是一个固定的东西，通过固定的过程控制，加上重复、冗余和过量的劳动来换取测试效果。
我上面说的侧重点不在于给别人一个“包打天下的”固定套路（因为那种固定的套路根本不存在），而是给大家一个不一样的思维来面对测试。

Miss_love

很片面

咩咩叫的狼

楼主说得有道理，其实就是探索性测试的核心，多多学习吧，对测试人员能力要求相对比较高~~

hhyghr

如果我手下有10个9年工作经验的测试团队，那么我绝不会让他们按部就班的去写用例，去执行。
测试的依据仅仅是需求？？呵呵

Wei测试

工作九年，经验应该丰富，不过不能要求测试人员有这么多经验。探索性测试，适合有丰富经验的测试人员，不然就容易抓瞎，无从下手。测试，方方面面很多，单点拿出来讲，都不成气候，但集合到一起就有得讲了。但能把测试讲清楚的人，凤毛菱角。

buzhi45

我认同“探索测试”，这个我最早是听吴老在yy上讲的，很有道理，感觉应该是未来流行测试的样子，你讲的大同小异，话糙理不糙。但是个人觉得“探索测试”无法应用到甲方乙方的项目中，毕竟有些东西要拿给别人看，划分责任。流程的东西繁琐但是不是在哪都能省略。但是要是自己公司的项目，自己写用例自己执行这种事简直就是耍流氓

herrykb

探索式测试确实能发现很多测试用例无法发现的问题，最近在看James A.Whitaker的探索式软件测试，对测试有了新的认识。

小白Y

好帖，好文，顶一个