我知道的有关测试用例的情况：
听一个在微软工作的朋友说，他们每天写完的代码，在晚上下班之前都要check到一起，执行一遍用例，当然都是自动执行的，那个地方出现了错误会红灯提示，所以这个用例一定是事先写好的。
听一个在比较大的公司（1000多人）的朋友说，他们公司经常后补用例的。
我一直在百十人的小公司工作，领导心绪来潮的时候要求写用例，可是多数情况是可写可不写的，而且对质量，形势也没有什么要求。
对于写用例的认识，我经历了这样一个过程，一开始是很形式化的，质量也很一般，回想一下跟现在的新人写的一样，所以觉得毫无用途，所以后来就不怎么写了。可是面对新项目的时候，问题出现了，无论在测试之前你多么的了解需求，业务，在提交测试的时候，很是会有覆盖不全的情况，我们的大脑毕竟不是电脑，我们在测试一个新系统的时候，不可能在到脑中勾画出每一个小功能，甚至每一个表单的所有分支，所以我开始写用例了，对任何一个小功能都是以流程的方式，每一步有多少个分支都清晰的列出来，我觉得效果非常好，按照这个测试完成之后，晚上睡觉都安稳多了，这是自己给自己的保证。这个用例可以说是一个很详细的用例了，只适合新项目的新版本测试，回归的时候就没有这个必要了，这样不符合性价比。那时候，我们的回归都是凭着大脑测试的，没有感觉到任何问题，只是在牵涉到流程性比较强的项目时才写一些流程用例（包括正常流程和常见异常流程）。可是现在，我在新的公司工作一年多了，问题出现了，项目特别多，差不多有十几二十个，由于测试的人少，每个项目都要测试，所以在回归测试的时候经常会搞不清状况，记不清业务要求等（也许是我老了，记忆力不好了：（）而且公司客户是比较强硬的那种，公司领导是认为测试过的东西就不应该有问题的那种，所以搞得自己经常提心吊胆，生怕给客户的东西出现问题。这时候，我发现了回归测试用例的重要性，以前没有写过，有个大概的概念就是写个简单的流程，回归的时候执行一下就行了，在一开始的实施过程中发现了问题，写的过于简单还是让我在回归的时候无从下手，在思考与实践中，我自认为自己找到了一种不错的编写方式：为了保证质量，回归在功能上要覆盖所有的功能按钮，这部分在写用例的时候要每个操作写一个用例（简单说excel的一行），操作结果中记录该操作应该返回的界面，一定要一个操作对应一个结果，这样才具有可操作性。在每条用例的后面设置“通过”和“不通过”的按钮，这样回归的时候就轻松了，过一个勾一个，在测试几乎没有改动的地方时，简直是休息，哈哈。当然也不要忽视业务流程，权限等方面的测试，可以另起文档，以自己比较喜欢的方式编辑就ok了！
