sylan215 二麻子,听说你们公司还在写测试用例?

sylan215 · 2019年08月30日 · 最后由 sylan215 回复于 2019年09月09日 · 2867 次阅读

“二麻子,听说前几天你的文章《测试用例设计的两个基本方法》被人转发到微信群后,引起了一波激烈的讨论?”

“是滴呀,不过遗憾的是,大家讨论的不是我写的设计方法的问题,转而讨论测试用例是否真的有必要……”

“啊,怎么可以这样?具体都说了啥,说出来我们学习学习。”

“我大概看了一下,有这么三波的不同意见:
一种认为现在很多人对测试用例的意识淡薄,全靠随意点点点,因为他们只是为了份工作,而不是为了测试;
另一种则认为现在的互联网现状,已经不接受传统的测试用例了,因为软件工程的发展,项目过程中考虑效率、成本等因素,导致测试用例落地困难;
还有一种是坚守测试用例必须要写的,因为随便点点点,肯定是无法满足覆盖率要求,就算是高阶测试的探索性测试,也是有固定的测试用例设计思路在里面,并不等同于随意点点点,至于说因为项目周期导致不写用例,纯粹是借口。”

“看起来说的都对哈,但是我觉得关键点还是各自的想法而不是做法,只要想做其实都是可以做到的。”

“是滴是滴,想当年我们业务时间那么紧迫,我们还是用 excel 逐条整理测试用例,现在我们与时俱进开始用思维导图写测试点了,但是不管咋样,这个环节是肯定没有落下过,如果没有这个参照,我真的不知道自己到测了啥,啥还没覆盖。”

“看来你还是认为,测试用例有必要的咯。”

“那是必须的,作为专业的软件测试人员,测试用例就是我们能力输出的最好体现,不同意这点的,要么就是对测试本身的理解还不充分,要么就是给自己找借口。”

“哇,你这么说的这么肯定,可是会引来一波杠精的噢。”

“合理的发表自己的观点而已,可以讨论,但不争论。”

“嗯嗯,你说的这么认真,我马上都信了。”

“不过我再补充一点,上面说的测试用例并不一定是落地的形式上的用例,对于高阶测试人员来说,真的可以达到此时无招胜有招的境界,什么意思呢?就是没有写用例,但是他随意的点点点,已经都是用例的体现了,所以有的人会说,呀,时间这么紧写什么用例?人家不写用例也测试的很好呀,对,只是那些都是隔壁家的孩子。”

“噢,原来是这个样子呀,我复述下,你看我理解的对不对哈。也就是说测试用例设计方法是最基本的底层逻辑基础,一定要达到滚瓜烂熟的程度,至于怎么用,有的人是体现在用例上面了,有人是在自己的思路中体现了,有人拿来一个个方法的死抠着进行测试用例设计,有人进行灵活运用,比如作为测试覆盖率评估的标准等等,反正不管咋样,测试用例设计方法很重要,测试用例也很重要,至于要不要写成落地的测试用例文档,各家公司按照自己项目的情况自行判断即可,我们最终的目的是保证质量,用例只是这个环节中的一个重要手段。”

“大个子,几天没聊,功力大有长进呀,理解的不仅到位,而且还进行了补充完善,佩服佩服。”

“那可不是,技术在进步,咱也不能原地踏步不是?对了,关于上面讨论的测试用例的话题,你还有啥补充不?”

“嗯……其实还有一点可以补充下,测试用例是一回事,按测试策略的用例执行是另一回事。我之前在文章《测试用例设计过程中长期存在的两个问题》里提到过测试全面性和针对性的问题,当时觉得这是两个对立面,结合今天的讨论,我觉得这两个并不冲突,测试用例还是应该以覆盖率为主,执行时可以按照测试策略决定哪些用例要跑,哪些不用跑,哪些先跑,哪些后跑。如果回到上面问题的话,如果没有测试用例的参考,也就谈不上测试执行策略了,所以我们说的高阶测试,是把测试用例和执行策略全部都在脑海中进行了存储和运算,那是相当的厉害了。”

“嗯嗯,不写用例还能保证覆盖率和针对性,确实厉害,如果水平不够千万不要随意效仿。”

“你这么说就不合适了,谁会认为自己水平不够呢?三胖子会么?他肯定会为了证明自己水平足够,而故意不写用例,哈哈哈……嘘……”

“我说怎么老打喷嚏,果然有人在背后说我坏话,信不信我一屁股坐瘪你?”

” 信……哈哈哈……“二麻子和大个子不无默契的异口同声到。

三胖子发现自己说错话了,赶紧又悄悄溜走了。

以上,针对微信群讨论的问题,二麻子和大个子私底下又做了一次深入的探讨,我通过对话的形式做了一下记录,不知道和你理解的是否一致,欢迎留言说说你的意见。

当然,如果你认可二麻子的观点,欢迎分享文章到朋友圈 + 点个「在看」让更多人看到,谢谢。

共收到 41 条回复 时间 点赞

有意思

有点《大话设计模式》的风格😂

大话设计模式

小狼崽 回复

你这么说我写的更带劲了😀

simple 回复

向前辈学习

谢谢支持💪

我问问 回复

站在巨人的肩上咱们可以看的更远😀

要保证产品质量就老老实实写用例,自动化的非自动化的都一样。😅

gggyy3 回复

你这么说,我可就当真了哈

0x88 回复

👍 👍 👍

功能点比较多,比较复杂的时候就很难把大脑当成电脑来用了,总会有忘掉的地方

王加 回复

是滴是滴,好记性比如烂笔头,我还是倾向要写测试用例的😀

我要跟老大说以后不要写用例了吗?哈哈哈哈

有时确实存在时间不足的问题,用例肯定是想写的,一个是可以想到测试点记录下来,二也是一个熟悉需求的过程,但肯定会遇到项目时间紧,没有时间写用例的情况,要想写就的整个团队死命加班才能搞定,就算你愿意加班其他人也不一定愿意,很矛盾。

猫星人 回复

说完记得告诉大家你老大的反应,哈哈哈哈哈哈哈哈

Night 回复

嗯,现在我们都是用脑图写测试点了,如果思路清晰,写起来还是很快的,另外注意下,如果 UI 特别多,优先写逻辑部分用例,UI 部分可以用截图代替。

有个东西叫测试用例与需求之间的双向可追溯性。。我觉得不管是什么形式的测试用例,只要能保证覆盖到需求就可以

看需求情况,简单的不需要写测试用例,复杂的逻辑如果自己不画图自己都屡不清楚,这时候不写用例是不可能的

他有他不写的理由,他也有他写的理由

王华 回复

嗯,分情况考虑的做法都是合理的,用例也是工具,更好的借助这个工具来保证测试覆盖率就是可行的。

MitnickEX 回复

大师总结的很有禅理👍 👍 👍

看到最后,有种公众号文章的味道😮

虽然是闲聊式的谈论,但最终还回到了闲聊。。。。。
其实有个点可以突出下 “如何更有效地落地用例”。
思维图,excel 之类但文档,在我看来明显不是有效的落地方式,关键的问题是 “你按照用例做了多少?” “怎么体现你做了多少?” ” 你真做了这么多吗?“

所以我的做法是,只写自动化测试用例 和 测试策略,其他都在脑子里过😌

膨化先生 回复

厉害呀,其实就是公众号首发,然后同步过来的😀

红薯 回复

我不 1,我 2,所以叫二麻子😀

chen 回复

为啥思维导图和 excel 不是好的落地方式?是因为看不出来执行人员是否真的执行了?它们都可以做结果标注的噢

泰斯特 回复

厉害呀,我的脑袋瓜子实在是不够用,不写下来就会漏点😓

Morris Li 回复

同意。用例只需要体现测试覆盖的功能点与需求,不需要把步骤、过程写得太详细,根本没有时间。

jade_chenyt 回复

同意 +1,如果能一眼就看明白的确实不用写,自己觉得可能有歧义的地方可以注明下,一切以实用为主

sylan215 回复

结果标注,可信度有多高?如何来追溯?

chen 回复

如果对人不信任,这个事情就很难办哈,前提肯定还是相信人,然后每个人执行结果是带上自己名字的,统一提交到 SVN 或者某一个存放文档的地方就可以回溯了。

如果比较复杂的功能,测试用例也不一定能完全覆盖的到,倒不如通过发散思维去测试,尝试探索性时间效率上不仅比写测试用例和执行用例的速度要快,而且检出的有效 bug 数会比有测试用例的高很多。 当然我不是不否认测试用例,测试用例只是我们的一个辅助性的工具,可以通过思维导图,或者自己的一些小笔记等来体现。

sylan215 回复

不是信任的问题,是人的记忆力不靠谱。最好的方式还是自动化代码和平时积累的 run log

企鹅 回复

嗯嗯,方式不固定,能达到效果就是最好的方法。

chen 回复

嗯嗯,找到适合自己的方式才是最好的,没找到自己的方式之前可以使用通用方式。

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册