编写测试用例带来的好处
1.避免漏测我们肯定都遇到过这样一种情况，有时你在做某事的时候，突然想起来一件事来，但没过几分钟你就又忘记了，后面你总是觉得好像要做什么，但就是想不起来是什么，这时最好的解决方法就是写下来，把当时的想法记下来，这种习惯特别是对工作特别有效。众所周知我们大脑脑容量无限，但能使用到的仅仅只有那么一点，在测试过程中若是没有一个依据，完全根据脑中想起来哪就测哪，百分之百会有漏测。
项目上线之后，一旦发生漏测，影响都是巨大的，无论这发现的线上bug是多小，对一个软件测试人员来说，都是相同的重要，虽然我们无法做到绝对，但我们需要尽量去避免出现漏测。
故：
在测试之前，根据理解到的需求编写测试用例，进行用例评审。
在测试之中，根据实际的测试情况记录测试结果、测试数据等，同时思维的扩大，也能增加新的场景。
在测试之后，回溯测试用例，检查场景是否全覆盖。
写用例最大的好处就是这个，这也是我们为什么一定要写的原因，主要就是为了避免漏测。
https://pic1.zhimg.com/80/v2-f3c3ca02ad75921b91967fcd1092c4ae_720w.png 2.常用常更新
大多数小伙伴做的项目都是在原来的版本上进行修改，故有很多功能或主要流程都要反复的回归。
针对这样的功能，写一份固定的测试用例，在测试时，拿这份测试用例出来用就行，不用在反复写，浪费时间。
编写测试用例，不仅是尽可能地避免漏测，同时也为了后面方便查阅。
项目上线之后，并不一定会立马就出现问题，有可能是运行一段时间之后才会出现，这时若出现线上bug，我们首先要立马解决线上bug，同时也要分析为什么测试过程中没有测试到，是场景没有覆盖到?还是测试环境数据不够或条件不足引起的?
要分析出原因来，就需要了解当时的测试情况，若当时没有记录，仅凭脑想，估计很难想出当时的测试全过程，若是有了测试用例，根据测试用例的执行测试轨迹，有很大可能找出当时为什么没有测试出来的原因。
分析为什么会出现的原因，有时并不是为了定责，而是为了下次相同的情况不在发生。
综上所述，建议所有小伙伴都不要因为很小的测试需求就放弃了编写测试用例，这样的测试用例不需要是正式的长篇大论，可以是在XMIND上列出的几点测试场景+需求，也可以是在本子上画出来的流程图，梳理出来的用例，形式不限，但不能没有。
页:
[1]
