有不少的从业者私下询问笔者，说在公司闲时闲死、忙时忙死。项目测的时候没有测试用例，等测完了再补文档，应付质量管理体系的审查，觉得前途灰暗，纷纷想转行！通过沟通才知道，这些从业者大多没有什么测试基础，公司其他人也不怎么了解测试，这不懂加上外行，工作就糊了。最关键的是还不知道糊在哪！他们对测试的理解就是点点点。
笔者实在是忍不住要吐槽一下，隔行如隔山，不懂别瞎说！
前两天中午吃饭就遇到一个外行，边吃边对旁边的新人说测试简单，就是点点点，现在都在用自动化工具了，测试工程师都快被淘汰了！随手在网上查了一下职友集的职位趋势报告，近四个月软件测试工程师招聘增长了33.77倍，而软件测试开发工程师则增长了28.8倍！是梁女士给他的勇气说出这些话的？
如果你想学习自动化测试，我这边给你推荐一套视频，这个视频可以说是B站播放全网第一的自动化测试教程，同时在线人数到达1000人，并且还有笔记可以领取及各路大神技术交流：798478386
https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337.search-card.all.click在测试时到底需要写测试用例吗？写测试用例有什么用？
测试用例的定义：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
操作和输入数据是对被测系统的使用方法，而预期结果则是这种方法应该产生的结果。执行测试用例就是对着操作和数据来使用软件，然后拿实际结果与预期结果做比对，从而判断被测系统是否正确。说白了，测试用例就是被测系统的答案。哪里有考完试根据答卷来决定答案的，这不是笑话吗！
测试用例的好处有以下几点：
核实需求
设计测试用例要有依据，这个依据就是《软件需求规格说明书》，通过分解软件需求，从而得到测试需求，然后设计测试用例。这个过程既是对测试工作的细化，同时也是对软件需求的反向核实，往往能发现很多需求不详细、不清晰的问题。
功能覆盖、防止遗漏
在测试用例中要写清楚这个用例所测试的测试需求是哪个(测试需求项)，这样通过信息关联，就可知道还有哪些测试需求没有写测试用例，防止漏测的发生。
监督过程
中小公司内往往是谁设计的测试用例，那么就由谁来执行测试用例。而在大公司或外包公司中，往往是由测试工程师设计测试用例，由测试员来执行测试用例。此时，测试用例中的测试步骤和测试数据，既是对测试员实施测试的指导，也是对测试员的测试行为的约束，通过每一条用例的执行记录来监督测试员的测试过程。
测试确认、评估结果
每一条用例都要有预期结果，所以必然也会有执行结果。这二者的比对就是测试行为的确认，同时也得知所涉及的测试需求项是否通过了测试。
准确回归
有了测试用例，回归测试时将主要的、重点的、与业务相关的测试用例拿出来执行就好了，操作步骤和输入的数据都写好了，直接用可以，回归测试简单了！
提高效率
不写测试用例，则无法确认是否做了充分的测试，只能不停地去测，结束时领导问：“产品能上线了吧？”，一群人回答的都很心虚！
写了测试用例，就可以准确的知道还有哪些需求没有测试，从而在保证测试质量的同时还提高了工作效率。
重复性
设计测试用例会很辛苦，但只要写好一版的测试用例，后续版本开发时，测试方只要对当前的用例进行调整就可快速使用，两个版本间的重复度甚至能达到90%以上。这就大大降低了测试工程师的工作强度！
跟踪性
有了测试用例，就可以追踪测试用例的执行人、执行时间、执行结果、缺陷的修复情况等，从而向管理者提供大量有用的管理数据，避免管理上的缺失。
如果不写测试用例，上述的好处都没有，测试工作会一团糟，辛苦工作还被领导骂，还敢不写测试用例？
最后，笔者回答大家常问的两个问题：
1.什么时候写测试用例？
前面提到从业者说工作是“闲时闲死“，仅这四个字我就知道他们压根就没搞明白测试该怎么工作！
就拿测试用例说，开发花费大量的时间写代码时，测试工程师就应该在此阶段写完测试用例！最理想的情况就是开发写好代码的那一刻，测试刚好把测试用例写好，谁都不耽误，立即进入测试的实施阶段，开始动手测！
但不会做的情况就是开发忙死、测试闲死，开发闲死、测试忙死，最后老板心疼死。
开发写好代码交付测试，此时测试方才考虑开始工作，结果发现时间很短，那就不写测试用例了，根据大家的经验和对被测系统的了解，开始测试，等测完了把测试用例补上就好了。
这么工作，测试全面了吗？是否覆盖所有需求？有没有漏测？后续版本也这么干？
答得上来吗？
2.自动化工具会替代测试工程师吗？
自动化测试的目标是将测试实施的过程使用工具软件来完成，这提高了测试实施的工作效率和准确性，但测试设计工作则无法使用某种工具替代人来完成。即便是当前火爆的AI，也只是人工智能从0到1的突破，想在现实世界里替代人，还遥遥无期呢！
2910
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
