记得刚从事软件测试的第一份工作，是在一家做生物识别技术的公司，当时测试的主要是考勤机系统，那时工作内容就是每天跟着固定的用例进行测试不同的机型，如果按照测试用例严格的准备来说不能称之为用例，它就是一条条功能，测试完成之后就在后面打上√，我们都是以相同的用例去测试每一款机型，所以根本不用写用例，那时刚入行对用例也没有概念，可以说是不知道什么是测试用例。
操作步骤：
1.依次点击菜单栏个人中心-》我的信息
2.选中昵称，点击“修改”
3.点击昵称输入框
4.输入昵称，“王豆豆”
5.点击“确定”
以上只是操作步骤，就要按照实际操作的步骤一步一步地写清楚，写完善，不仅是用例写得很详细，用例的测试点也需要写得很详细，修改昵称为5个中文，4个中文，1个中文、英文字符、特殊字符…………就这样一个项目的用例也可以写上好多天，那时创下了我写用例的最高记录，每天能写三百多条用例，每天写用例都能写出内伤来，可以如果快速写测试用例也是开始锻炼出来的。
后来换到另一个项目，这个项目就不要求写用例，每天拿到提交的功能就不管三七二十一开始测试，执行测试的动作完全就是行云流水，不受束缚，思维也如脱缰的野马不受控制，最终三下五去二的搞定。
再后来、再后来做了一个有一个的项目，有很庞大的也有很小的，有复杂的也很简单的，踩过无数坑之后，慢慢地王豆豆都始终养成了一种习惯，无论多小的功能都在把测试点梳理一下，测试场景写一下，这些就变成了王豆豆现在的测试用例。
所以，软件测试人员真的有必要写测试用例么？
毋庸置疑，王豆豆的答案是非常有必要。
在写测试用例的过程中，不仅是对测试点的梳理，同时也是对测试思维的梳理。通过写用例能够将一些边边角角的测试点记录下来，对一些难以理解的需求通过用例使用单元维度进行拆分后变得很详细，测试思维也更立体。
总结起来，写测试用例有二个好处：
1.避免漏测
我们肯定都遇到过这样一种情况，有时你在做某事的时候，突然想起来一件事来，但没过几分钟你就又忘记了，后面你总是觉得好像要做什么，但就是想不起来是什么，这时最好的解决方法就是写下来，把当时的想法记下来，这种习惯特别是对工作特别有效。众所周知我们大脑脑容量无限，但能使用到的仅仅只有那么一点，在测试过程中若是没有一个依据，完全根据脑中想起来哪就测哪，百分之百会有漏测。
项目上线之后，一旦发生漏测，影响都是巨大的，无论这发现的线上bug是多小，对一个软件测试人员来说，都是相同的重要，虽然我们无法做到绝对，但我们需要尽量去避免出现漏测。
故：
在测试之前，根据理解到的需求编写测试用例，进行用例评审。
在测试之中，根据实际的测试情况记录测试结果、测试数据等，同时思维的扩大，也能增加新的场景。
在测试之后，回溯测试用例，检查场景是否全覆盖。
写用例最大的好处就是这个，这也是我们为什么一定要写的原因，主要就是为了避免漏测。
2.常用常更新
大多数小伙伴做的项目都是在原来的版本上进行修改，故有很多功能或主要流程都要反复的回归。
针对这样的功能，写一份固定的测试用例，在测试时，拿这份测试用例出来用就行，不用在反复写，浪费时间。
编写测试用例，不仅是尽可能地避免漏测，同时也为了后面方便查阅。
项目上线之后，并不一定会立马就出现问题，有可能是运行一段时间之后才会出现，这时若出现线上bug，我们首先要立马解决线上bug，同时也要分析为什么测试过程中没有测试到，是场景没有覆盖到？还是测试环境数据不够或条件不足引起的？
要分析出原因来，就需要了解当时的测试情况，若当时没有记录，仅凭脑想，估计很难想出当时的测试全过程，若是有了测试用例，根据测试用例的执行测试轨迹，有很大可能找出当时为什么没有测试出来的原因。
分析为什么会出现的原因，有时并不是为了定责，而是为了下次相同的情况不在发生。
综上所述，建议所有小伙伴都不要因为很小的测试需求就放弃了编写测试用例，这样的测试用例不需要是正式的长篇大论，可以是在XMIND上列出的几点测试场景+需求，也可以是在本子上画出来的流程图，梳理出来的用例，形式不限，但不能没有。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
