51Testing软件测试论坛

标题: 传统的那些测试都是狗屎！无能的人做测试只能采用那些苟且的做法！ [打印本页]

作者: andypeker 时间: 2015-5-13 13:03
标题: 传统的那些测试都是狗屎！无能的人做测试只能采用那些苟且的做法！

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

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

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

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

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

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

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

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

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

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

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

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

作者: yiyun525 时间: 2015-5-13 13:25
但是现在企业都是走的传统测试啊。

如果要做到你说的 ‘有的放矢’ ，是需要一个测试者长期学习才能达到你说的这种境界吧。

哈哈，我测试经验不多，所以可能说的不对，你别介意

作者: Miss_love 时间: 2015-5-13 13:45
呵呵、、、、

作者: andypeker 时间: 2015-5-13 14:00

Miss_love 发表于 2015-5-13 13:45
呵呵、、、、

来聊聊嘛～

作者: andypeker 时间: 2015-5-13 14:02
大家都来聊聊嘛～我上面说的，肯定会得罪一些人，因为我否定的东西正是那些人以为是财富和价值的东西～

作者: gaha 时间: 2015-5-13 14:38
这件事儿的根源，就好像高校扩招一样，量上去了，质下来了，缺乏研究型人才，不管是理论方面还是技术深度，还有一些外包公司，只要是思维正常的生物个体他就能用，每天不需要思考的重复劳动。总之，行业处于一种非常浮躁的情况下，很多不切实际的东西。

作者: gaha 时间: 2015-5-13 14:41
我觉得，做测试应该是累脑子的活儿，不是累体力的活儿，可是现在有多少人是在从事体力劳动。不会投机取巧的工程师不是好人才。

作者: ntgecm 时间: 2015-5-13 15:11
迷信自动化是不可取的，测试是研究性活动和行为，需要探索精神。从有知找未知，武学的最高境界是内功心法，其他兵器（测试工具）都可以变成神兵。

作者: andypeker 时间: 2015-5-13 15:58

gaha 发表于 2015-5-13 14:38
这件事儿的根源，就好像高校扩招一样，量上去了，质下来了，缺乏研究型人才，不管是理论方面还是技术深度， ...

我对你的说法很有兴趣，我们好好聊聊，让我了解到你的看法和思考，可以吗？请教～

作者: andypeker 时间: 2015-5-13 16:00

ntgecm 发表于 2015-5-13 15:11
迷信自动化是不可取的，测试是研究性活动和行为，需要探索精神。从有知找未知，武学的最高境界是内功心法， ...

我以前在tx工作时，听技术大牛说话，就讲到了“道”和“术”；“道”的层面有了，“术”就简单了，很多人在钻研“术”并且钻研的很辛苦，却忘了问题不是“术”本身有难度而在于“道”的缺乏。我想跟你好好聊聊，赏脸回复一下吧～

作者: bug在哪里 时间: 2015-5-13 16:02
每种测试方法，其实就是应用一种测试的思维，探索式测试是很不错的，个人也觉得每个测试人员都应该学习。学过的过程勿急躁，慢慢积累沉淀吧。国内的测试环境是一般，测试人员缺少了点测试的激情，说白了不是喜欢测试才来做测试的。

作者: andypeker 时间: 2015-5-13 16:26

bug在哪里发表于 2015-5-13 16:02
每种测试方法，其实就是应用一种测试的思维，探索式测试是很不错的，个人也觉得每个测试人员都应该学习。学 ...

如果每种测试方法都能对应用一种测试思维？测试方法那么多，岂不是对应了很多测试思维了。请告诉我你认为的测试的思维，列举几个或者如果愿意的话举几个例子，请教～谢谢～

作者: gaha 时间: 2015-5-13 16:28
LZ是什么情况？要写论文吗？

作者: andypeker 时间: 2015-5-13 16:35

gaha 发表于 2015-5-13 16:28
LZ是什么情况？要写论文吗？

我是一个做测试九年的人，近两年非常怀疑一些东西，希望能有同行一起讨论一些问题。

作者: bug在哪里 时间: 2015-5-13 17:39

andypeker 发表于 2015-5-13 16:26
如果每种测试方法都能对应用一种测试思维？测试方法那么多，岂不是对应了很多测试思维了。请告诉我你认为 ...

你说应该没错，一种方法其实就是一种思考问题的方式，例如等价类划分，常用吧，就是基于需求，基于数学理论讲用户输入的数据进行基本数学的等价类划分。每一种方法可以理解为一种思维方式，每种思维都会有它的本身的局限性。例如，等价类划分，需求写着能输入1到100的两位小数，等价类划分会把浮点数和整数区分吧？原因可不是基本数学理论划分出来的，是有浮点和没浮点在机械码的角度，二进制就是不一样。测试就是要结合多角度的思维来分析被测系统可能存在的问题，可以是方方面面的思维，不一定存在于编码领域，哦，还有，测试工作不仅仅在于寻找bug,而是在于帮助设计和编码人员发现他们的不足，从而多角度的提升软件的质量和生产力。

作者: andypeker 时间: 2015-5-13 18:00

bug在哪里发表于 2015-5-13 17:39
你说应该没错，一种方法其实就是一种思考问题的方式，例如等价类划分，常用吧，就是基于需求，基于数学理 ...

寻找bug不是全部目标，提高整体质量和效率更有意义，这个我非常同意你！

除了上面说的等价类、边界值等思想，还有其他测试思想呢？

谢谢回复！

作者: bug在哪里 时间: 2015-5-13 19:10

andypeker 发表于 2015-5-13 18:00
寻找bug不是全部目标，提高整体质量和效率更有意义，这个我非常同意你！

除了上面说的等价类、边界值 ...

说说探索式测试吧，探索式测试其实可以分为单人测试和多人测试模式，单人测试下，可以单一角度的思维探索软件，如深度变量、广度变量、输入和导航、事件源重复、时间/持续时间、功能共存和切换、软件共存、场景（环境切换）干扰等等思维来分析数据、设计用例。但探索式测试更讲究是更加多元化的思维来分析软件，不要停留在“软件”和“用户”层面，单人模型下例如“引喻测试”，如果把被测系统比作一个旅游城市，我们要测的模块是“红灯区”，请问什么时候该区最繁忙？如果是商业区呢？这就就探索里面的“旅游指南测试”。这样引喻来测试，往往可以发现更多隐藏在功能背后的性能问题，甚至于安全性问题。多人模式，就是多个测试人员（或者非测试）一起测试，模拟一个场景，头脑风暴提出可能出现问题的地方，编写测试章程，测试。以上每一种方式都是一种思维，不同的思维考虑的角度不一样,才能找出隐藏得更深的bug,测试要做好，需要的是多角度的思维能力。

作者: bug在哪里 时间: 2015-5-13 19:33
LZ有这些问题，我觉得和你们公司测试架构是有一定关系的，目前我们的测试架构无非3大类，类google,类微软，还有建立敏捷团队。个人是觉得敏捷比较符合现在市场对软件的选择。测试因为依据软件研发过程，紧跟开发的步骤，快节奏持续集成，尽早发布，才能使软件具有良好的市场优势。有些时候吧，我们还有得市场意识。

作者: andypeker 时间: 2015-5-14 11:27

bug在哪里发表于 2015-5-13 19:10
说说探索式测试吧，探索式测试其实可以分为单人测试和多人测试模式，单人测试下，可以单一角度的思维探索 ...

设定一个场景，再加上对被测对象的深入了解，框定测试范围，这个暗合我的“有的放矢”的路子～谢谢～

作者: andypeker 时间: 2015-5-14 11:30

bug在哪里发表于 2015-5-13 19:33
LZ有这些问题，我觉得和你们公司测试架构是有一定关系的，目前我们的测试架构无非3大类，类google,类微软， ...

兄台在哪里高就，你们公司探索式测试开展的怎么样？

作者: bug在哪里 时间: 2015-5-14 20:05

andypeker 发表于 2015-5-14 11:30
兄台在哪里高就，你们公司探索式测试开展的怎么样？

测试新手。学生。待业。

作者: 278306549 时间: 2015-7-5 17:59
你能说出你上面的话，相信你对测试行业现状有一定了解，但是现状整体软件行业的现状如何，这个我们不能逃避，目前国内测试多数的确比较传统，软件测试从业人员的水平导致软件测试的地位在许多项目中得不到重视，缺乏优秀的测试创新和管理人员；缺乏创新。
“有的放矢”，也要有条件来放，探索式测试不同的项目不一定适合，任何项目对测试都是有要求和期望的，首先，对传统覆盖的理解可能不同，传统的覆盖也要看是如何实现的，如果是根据软件整体的需求及业务流程、逻辑流程及功能进行的覆盖，怎么会没有必要能，如果没有这些覆盖，如何全面的验证这些实现？也许你原来经历的覆盖太过繁琐，甚至有大量冗余，只能说明这个覆盖和发现系统问题的过程效率需要提高，如果都用有的放矢，各类人员的测试水平真的能比传统覆盖对提高软件整体质量更有效吗？有的放矢的探索性测试可以作为整体测试的一各分支来进行，但是无法替代整体的传统覆盖，要想提高一个软件系统的整体质量，最大程度的发现和暴漏问题，真是项目中探索性测试只能多为测试中的一种方法进行应用，多有测试方法的目的都是尽可能提高软件整体的质量，发现更多的问题；以上观点只是个人的见解。

作者: zzz2016 时间: 2015-7-8 15:35
我想说这个也要一分而二的看，质量不仅仅是测试人员的事，是从需求、设计、代码、研发流程等等，是团队每一个人的都应该关注和有责任去做的事。比如说GOOGLE他们有开发人员，还有测试开发人员，测试开发人员写的测试代码比开发代码还要早，还要多，那么等到测试人员（我理解类似我们现在的角色的测试人员哈）拿到软件时的质量是不是比我们拿到的软件的质量要高的多，他们测试人员的精力可以仅关注他们关注的那一块，这样是不是更有效。。。。
其实我想说中国的测试人员管了太多不该管的事，所以才会让用例越来越多，越来越庞大，哈哈。。。
当然不可否认我们的测试人员的测试能力和技术也是有待提高，毕竟人家发展了那么多年，我们还要加油努力。

作者: prettyfool 时间: 2015-7-8 20:20
我也很奇怪，很多用例都没什么意义，结果还是要去写它，而且还理直气壮的说，为了测试更全面

作者: prettyfool 时间: 2015-7-8 20:29
等价类和边界值应该不算有错吧，如果给一个输入限定一个范围，然后让一个从不懂测试的人去测试，他也会自然而然的用到边界，这更应该是一个人的基本思维习惯，把它叫做等价类和边界值，只是起个学术性的名字而已

作者: loveok_56 时间: 2015-8-18 13:30
有啥好说的，，，不管黑猫白猫，抓住老鼠就是好猫，，，至于采用什么样的测试方法，要根据公司和项目的实际情况来决定。产品的属性是多方面的，也就决定了测试方法的多样性，一味地认为哪个好，哪个坏也是不可取的

作者: cooltom 时间: 2015-8-22 16:31
最近看了一本书。软件测试实战，史亮写的，很受启发。建议做测试的都看看。

作者: 小蝶 时间: 2015-8-31 18:09
目前的测试现状是有点不乐观，对于测试的发展，其实还是要看公司的重视程度和管理模型，如果是非职能式管理，那每天都是重复式的工作，没有太多的创新，因为每天都有完不成的项目发布，根本就没时间去研究新的测试技术。
对于探索测试，个人比较喜欢，也尝试过几个项目，效果不错。

作者: samhehe 时间: 2015-8-31 22:17
菜鸟我虽然看不懂，但是好像很牛逼的样子，能讲讲具体的东西吗

作者: tiemuzhen 时间: 2015-9-15 17:05
很感兴趣，可惜真正思考的人太少

作者: han80119 时间: 2015-10-9 14:46
做重复工作做多了,有此想法很正常,测试本来就包含很多的枯燥的重复工作.但不能因此看轻传统的做法和工作,就像大厨,不能看轻配菜工一样,各有各的职能和作用,无分贵贱.

作者: sagesmoke 时间: 2015-10-13 15:28
现在才看到这个贴子，我觉得楼主这些想法是这么多年来对测试工作的一个理解，大部分观点我比较赞同。
我个人对于测试目前的想法是如何提升测试的价值，或者说如何将测试更多的隐性价值转成显性价值

作者: hujiaerxiaojie 时间: 2015-12-11 18:03
要在有经验丰富的前提下，这个方法是可行的，对于很多经验不足的人来说，这个要求太高了，很多人连系统都不熟悉，更别说知道要测试什么了

作者: 上古tia 时间: 2016-5-13 11:48
楼主的想法有一定道理，但前提是培养和留住那样的人才是有较大难度的，另外你说的那种测试方式属于逻辑性测试，或者接近白盒测试需要了解产品内部信息。而你不要忘了还有一种叫做黑盒测试的东西，不需要了解代码和内部逻辑。

个人观点，测试5年。

作者: 天机 时间: 2016-5-18 16:57
测试的关键不是按部就班的测试，而是怎么测试。很多人觉得测试按照模板来写案例，之后按着案例执行就ok了，但是事实上这样会做很多无用功。测试的基础是业务，有的人说是需求，对，需求也没错，但是你也不能盲目的相信需求，而是结合实际的业务，抱着审核性的思想来理解需求。根据业务来分析测试的关键，重点。

作者: macg1987 时间: 2016-6-14 12:46
这个帖子几乎就是指着鼻子骂煞笔了。现在测试都是通过界面分析需求，其实设计想法都不知道。测试员可以不懂代码，可以不懂自动化，性能，接口，安全。但是只通过界面来分析和测试就活该没发展前途了。其实我看不惯动辄要求大量用例和盲目覆盖。只停留在界面去分析，永远找不到哪些地方是产品薄弱环节。

作者: ntgecm 时间: 2016-7-13 11:54

andypeker 发表于 2015-5-13 16:00
我以前在tx工作时，听技术大牛说话，就讲到了“道”和“术”；“道”的层面有了，“术”就简单了，很多人 ...

QQ:250883438

作者: hotivy 时间: 2016-12-1 17:41
挖个坟，这哥们现在什么想法？

作者: yafengwang 时间: 2016-12-12 11:45
一个思想万箭齐发---导出有的放矢认为目前的覆盖测试是傻逼，这个有点过。我人为有的放矢是好的，是有效的，高效的，但我也不认为万箭齐发是错误的，是傻逼的。说这些并不是走中间派，而是有原因的。
1、开发水平导致一些很小的问题出现，各个负责的模块有各式各样的问题；
2、不断的功能叠加，导致一些前后矛盾的出现；
3、时间紧张的无聊的迭代导致问题不断被发现，重复；
4、。。。。。。

作者: liulinzhu 时间: 2017-1-4 10:43
测试也是有僵化->固化->优化的过程，不同测试阶段的人，要求不同，但的确现在有不少公司，还处于僵化阶段。
经常听到开发说的一句话：“这些BUG，客户那会触发吗？”很欣赏楼主的直言直语。

测试7年，已转行。

作者: wgl 时间: 2017-1-4 15:34
不知道楼主有没有看过《测试之美》这本书，我相信你能在里面找到答案的。现在的测试如此状况，跟大环境有关吧。在微软公司，测试人员比开发人员要多的多。
至于前面有人说到探索式测试，测试之美里面可以很好的体现这一思想。

作者: wgl 时间: 2017-1-4 15:37
本帖最后由 wgl 于 2017-1-4 15:52 编辑

楼主

作者: hust330hugh 时间: 2017-1-19 09:24
楼主说的有些偏激了:我认为你说的那些传统只是测试基础，如果作为一个测试人员这些基础都不了解才是shit。其中有几点我比较有同感的:第一点是工程的思想，这点我在做验收测试时很有感触，几个人的验收团队，怼几十上百号人的测试团队，还要保证验收质量和全面，没有系统工程方法是不行的，第二点是探索研究新的测试方法和流程，这个我是在接触到Istqb之后，有了这方面想法，ISTQB中对测试的理论还是很系统，可以按照这个回顾梳理自己的经验，然后提炼总结出适合自己的。

作者: yuanliushuai 时间: 2022-8-8 15:09
难道不看开发水平么

作者: eagle_yd 时间: 2023-3-6 16:39
做了9年测试还分不清测试设计和测试执行，把两者前后不分混合起来吐槽，严重怀疑楼主分析问题的能力。
自动化本身有什么问题呢？自动化是帮助团队提效，提高覆盖率的，这是自动化的基本思想，但是提高哪些环节、哪些场景的覆盖率是测试设计和测试策略的事情，自动化只是解决重复劳动的问题
还有是否采用高覆盖、或者使用探索测试、这要综合考虑多种因素去做决定，不是任何时候都适合的
可能楼主做了这么多年测试，对业务很熟悉，测试技术也很牛，那么可能楼主就能把探索测试做得很好，但是换个人来，可能就不行了。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)