测试基础 测试用例很基础,但是否真的重要?

企鹅 · 2020年03月03日 · 最后由 混泥土瞬间移动工程师 回复于 2020年03月20日 · 210 次阅读

相信这篇文章有很多人觉得是很无聊的,因为是最没有 “含金量的” 手工测试相关的内容。有那么一部分人还是认为手工测试就是点、点、点。我说你没说错,手工测试就是点,哪里不对点哪里,哪里出错点哪里。
我们都知道测试这一行,测试用例是一切的基础,是根基。但往往越简单的问题,却越难。最近在一些技术群,抛出之后。讨论异常活跃。虽然看似一个简单的问题,平时也都用到的技能,值得我们去讨论和深思。
什么是好用例, 好用例的标准是什么?如果说对测试的业务的相对熟悉,用脑图串一些测试点或者场景是否更合适;细化当然好,但问题是细化到那种程度?其次用例的维护,不维护测试用例,维护用例的成本如何? 一次性用例的是否有必要? 写一份覆盖全且不啰嗦不冗余的用例按理来说应该是挺难的。看过@sylan215 以及邰晓梅老师《海盗派测试分析》
让我不断的思考,测试用例的是否真的有必要,?而且一些在一些相对复杂的场景,测试用例也不一定能完全覆盖的到,倒不如通过发散思维去测试,尝试探索性时间效率上不仅比写测试用例和执行用例的速度要快,而且检出的有效 bug 数会比有测试用例的高很多。 当然我不是不否认测试用例,测试用例只是我们的一个辅助性的工具,可以通过思维导图,或者自己的一些小笔记等来体现。这一段仅仅是我的个人观点。不喜勿喷。

共收到 19 条回复 时间 点赞

如何确保测试的深度与广度,怎样去提升??一个好的用例是否能很好的体现??

测试用例的重要性,其实多年未变!

他是要用测试用例来保障基本质量的,至于发散思维 场景法等,其实多数都是考虑的异常,就是在基本质量的基础上进行优化,保证更好的体验!

很重要啊,之前有个帖子,测试用例重要到公司还要根据测试用例数考核
😅 😅 😓

先回答:重要。抛开业务覆盖率谈测试用例都是耍大刀,好的测试用例可以让你用更有限的资源去实现产品质量最大化的提升,测试本身就是一项有风险的软件活动,所以要和你的测试的业务需求挂钩,核心业务还要细细咀嚼,发现其隐形的测试需要,如:人员,环境等。现在有的公司敏捷大行其道,只写测试导图不写测试用例,其默认参与到敏捷的测试人员本身素质是很高的,是业务上的专家,而且可以充当万金油的角色:项目管理,研发内部调节,需要明确与改进,自动化/性能开发等。这也是我等测试人员的价值体现。我有见过把整个 UI 扒下来遍历控件写用例的公司,那用例数很酸爽。

谢谢点名。

什么是好的测试用例?对于质量的角度来说,覆盖率越全的越好,但是对于回归用例来说,我推荐能发现 bug 的用例就是好用例。

你质疑用例的有效性问题,我理解的是用例设计不到位,才会导致很多 bug 不是通过用例发现的,那么除了发现 bug 外,我们更应该提升我们的用例设计能力,毕竟谁也不会做一辈子执行,不执行就发现不了 bug(保证不了质量),这说不过去吧?

更详细的观点请参考:
到底要不要写测试用例看这篇
通过 bug 来完善自己测试用例设计思路看这篇
怎么体现测试用例的深度看这篇

我的观点:
测试其实是门艺术。
测试用例只是方式方法,测试真正要做好,技术,产品理解,场景,人缺一不可。

楼主可以分享分享几次线上事故带来的反思,讨论也会比较热烈

测试用例的作用,我觉得重要的地方有三个:
1、可以说明一轮测试的结束,如果一直发散,那么你永远没办法说测试完成,永远没有上线的时间
2、更早的发现需求设计漏洞,我相信在写用例的时候一定会发现需求设计漏洞
3、测试发散思维的基点,先脑图,在写用例,相信写用例的时候会有很多补充,所以在用例的基础上发散,会扩散的更远。

测试一切的基础,重中之重。

更多是是领导量化统计你的工作而已 不然没人知道你干了多少活 或者现在测试进度是多少了 。

其实很多小公司都是上手直接点点点。包括我在最近的一个公司也是如此。但是测试用例个人觉得依然重要。它可以体现测试人员的工作输出。可以监督测试人员的测试执行,避免漏场景,不至于后面出现问题跟开发扯皮落入下风。
至于用例如何写得好,这个实在是个大学问。以至于每次面试我都害怕面试官问我用例设计。每次觉得用例不久那样,点着点那,看实际结果跟预期结果对不对。但是面试的时候,你总会被问得怀疑人生,为什么我之前没考虑得这么多。。。

工具类和功能测试本来就相辅相配合的,工具类完成了多少标记给功能测试,让功能测试时间投入更重要事情上去。
自动化和接口的用例依据也是根据功能测试用例去写,两者如果分开和水中捞月一样。

重要 测试过程有个依据 以后跟踪起来也方便。 还有一个更重要的功能,甩锅,出现了问题 用例里没有就是测试的锅,就算是咖啡厅里跟老板要炒米粉然后咖啡厅爆炸了的操作,也是测试没测到。

测试用例很重要,但是在形式上不能太重了。目前情况下,大部分公司的迭代都是比较快的,维护测试用例的成本显得就比较高了。个人认为,除了核心功能和较大迭代需要维护测试用例,其他小的功能和优化迭代只要准备测试点或一两条功能用例进行维护就可以了。

企鹅 #16 · 2020年03月08日 Author
冰薄荷 回复

嗯嗯,这个我认同,目前好多都是形式化,反而真正操作确是探索性的

编写测试用例的同时,也是熟悉需求的过程,这个过程可以发现需求中遗留、不合理的地方

测试用例是基础,每个测试都需要先打好基础。。。当打好基础以后,再结合 case 和 bug 的发生规律,会有一些感想,未来的路上,找 bug 的速度会变的相当快~(也就是说,可以做到,几乎知道 bug 在哪里)

人是比较健忘的,用测试用例来执行主要是不会重复劳作

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册