其实我一向认为，测试用例应该从check list开始，因为很多的东西其实都是很公共的，比如增、删、改、查，这些用了，下次大部分还是这些东西，只是对应在具体的项目里面而已。这样就可以有一个公共的用例库，需要的时候，直接代入，这样其实大部分的基础性用例已经出来了。
最近才开始比较系统的接触测试,但是最近一直都在写用例,感触挺深的.
由于系统很大,但是写下来的过程中,自己和同事都发现一直在做重复
工作.比如每一张表都会有增、删、改这类的操作，每张表都写一次，浪费太多的时间。最后我们总结了两条：
一、先整理测试需求
整理测试需求其实只是将软需换种方式来表述。软需中一般描述的都是一个流程或是一个操作过程，而我们的测试点都是从其中支离出来。先整理测试需求其实就是先写出某个操作过程中需要考虑的测试点。这样的好处是产品经理可以直接看我们的测试需求，如果对需求理解有误，写出来的用例肯定也是错误的，自然也就业没有了查看的意义。同样这样做，对以后的测试结果有一定的指导意义，测试出现争议的部份，也许在需求中就是体现。
二、抽取测试模版
由于有很多的重复操作，例如表单的增、删、改，可能不同的只是每张表的字段要求不同，尽可能的将同样的操作写成用例模版，方便以后调用。不过这方面现在本人也遇到很多困难，不知道应该如何抽取共同操作组建模版才会更好。因为模版太范会使测试的覆盖率减低，但模版写的太细，就会调用变的复杂，不利于今后的用例维护等
其它操作。
望各位指点迷津！
不知道大家有没有听过一种说法，就是说向做开发一样的做测试，首先拿到一篇设计文档，所以从测试的角度就进行分快，对每块抽取测试点。。对每个测试点进行输入输出的抽取，再采取一些常用的设计方法，比如说正交分析，边界值等方法，如果确实是时间比较紧，则可以分大的功能模块，每个模块的测试点，及其每个测试点的相关输入输出组合，可以使用EXCEL表格进行分析。另外就是公司应该对一些常用的设计方法进行自动化。对于后来的测试人员只要分析出那些常用测试设计方法的输入即可。
。另外分析常用的测试逻辑进行固化。。以后还碰到这种类似的话，直接可以参考，只需要改具体的内容即可，姑且可以等同与开发的组件化。
如果要有限的时间内编写完整有效的测试用例
1）首先就要先具备丰富的测试用例编写经验
2）将一些公用的测试用例在这之前先写好，如Add/Delete/Edit/View等用例。再针对具体的测试对象进行适当的修改
3）针对软件需求进行测试需求的细化和提取，如果没有具体的需求文档，那只能够凭以往经验来提取测试需求了。每个测试需求点都要有对应的测试用例，覆盖正反面和异常面
4）编写完测试用例，进行简单的同行评审，保证全面性和完整性
前段时间我也写了一个项目的测试用例，我们面临的问题就是：时间紧。任务重。最郁闷的问题是，需求还没有正式定下来。等到代码提交开始测试的时侯，需求已经变动很大。导致我们的用例没有什么参考意义。对此我是感触颇深。下面谈一下我的认识：（不足之处多多指教）
第一，我个人觉得一个项目的核心主旨就是业务流程。只要业务流程弄明白了。界面的问题好解决。所以，时间比较紧张的情况下，首先把主要流程写清楚，每一个流程分支都走一遍。以便后来进入项目的同事，结合需求说明书和用例便能更快的进入到项目中来。
第二，还有就是那些公共的测试用例。比如：超链接测试、表的增删改查测试。系统登陆退出测试，等等。每个项目都会用到这些测试用例。不用每个项目都写。只要写好共性的用例。其他项目调用即可。
我个人认为，依目前国内的测试行业的情况来看，在国内一些中小企业，编写测试用例并不是一个必要的环节。测试用例的完整性和有效性在于它的指导意义。时间有限就把关键业务点写清楚。以后有时间再进一步细化。当然对于大公司来说，测试用例这个环节必不可少。但是大公司的公共测试用例早已经有了模版，我个人觉得还是业务流程最重要。呵呵。
确定软件的功能点
根据功能点确定功能点的测试点
根据测试点写测试用例
就像一个树型结构细化
测试用例是测试的向导
时间紧的话也不用写得很详细吧
个人的理解，因为没有经历过一个项目完后才进行测试，测试和开发是同时进行的，不足之处请多多指教
