其实，测试用例不是必须的。如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例，如果我是Test Manager的话，就会让你做一个Ad-hoc Tester，因为我已经觉得你足够好了，不需要测试用例来指导你了，因为你很有想法，有自己的测试思路。就像陈宏刚博士在Microsoft公司做Tester的时候，就是一个Ad-hoc Tester，因为他有自己的测试思路，他每天找到的Bug比他们小组其他所有Tester测试出来的Bug总和还要多，所以Test manager 根本就不管他，也不给他什么要求，就让他每天测好了。 
            
        但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。

        1. 你工作不主动，你需要测试用例来催着你去工作；

        2. 你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏；

        3. 在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。

        4. 你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。

        5. 测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。

        6. 测试用例可以记录你的灵感。如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。

        7. 测试用例有助于不断的改进工作。因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。

        以上几条如果还不能推动你写测试用例的话，那么只有通过时间来证明了。我现在已经习惯在测试之前写测试用例了，如果测试之前没有测试用例的话，反而觉得不习惯。当然在不同的情况下（比如时间紧迫和有充足的时间的情况），测试用例的写法是不一样的。