我觉得，测试用例应该有模版，要按一定的要求进行规范化，这样可以提高效率。

说一说我的看法，在有限的时间不可能写出的测试用例能够覆盖到所有的测试需求，即使全部覆盖到了，测试用例的粒度也一定达不到要求。个人觉得，凡是系统，都可以根据需求划分为关键功能点和非关键功能点，对关键功能点，要罗列出一系列关键项，就每个关键项要仔细深度地设计用例；而对非关键项，只需测试一般的常规功能即可。也就是说，测试用例的设计，要根据功能使用的优先级和重要程度决定。

1、对需要测试的项目分为几个模块，并且编号
2、针对每一个模块明确验收内容，预置条件，操作过程，接收标准
3、最后得出结论

前面的大侠更多都已经说了很多，我就不再分析题目，直接进主题
1、软件已经出来，也就是功能已经明确，那么功能模块划分的问题应该可以解决，功能模块之间的耦合问题等不讨论，但原则是尽量低
2、之后，就是我们测试原则中的一条起重大作用的时候，八二原则，说白了就是抓重点，怎么抓，不是这个问题的讨论点
3、重点抓到了，后面就是常规测试方法的应用，对显式的测试点用等价类、边界值等方法，对隐式的测试点（比如逻辑关联性等）用错误猜测等方法，除非需要，这个时候，因果图、决策表之类的方法大家还是悠着点用。
4、如果可以，或者条件满足，能够使用工具的地方尽量使用工具（如果使用工具比直接人力测试的效率还要低，还是选中人力测试，这里需要衡量分析）
5、加班

这个话题要拆分开来分析。
一、编写完整的测试用例
二、有效的测试用例
三、在有限的时间内
第一、个人认为，没有一个测试人员可以做到百分之百“完整”！何为“完整”？是测试路径覆盖率100%么？不是！即便覆盖了测试需求的全部功能，又如何保证100%的测试需求不变更、亦或满足了客户的需求呢？测试是保证软件产品的质量。而最“完整”的质量保障或者说测试覆盖，其实应该是满足了客户的当前需求。说白了，其他不是客户想要的质量，可以弱化点，要切入要点进行测试，从而在要害关卡编写测试用例。
第二、何为“有效”？是测试方法正确还是测试策略高深？不是！
1、是基本的测试规则。如同游戏一般需要定义规则，测试需要用标准规范来约束。没有良好的测试规则，恐怕难以称之为“有效”。我以为，从分析测试需求起，就可以同步建立测试模型/模式，开发有他们自己的模型/模式，测试当然也可以使用。譬如用UML来画流程图、活动图，理清测试步骤。或者用RUP的迭代测试，是否会比普通的模型要好些呢？
2、测试用例的根本是设计如何测试，不是测试什么。很多人仅简单把测试操作步骤记录在案，以为就是测试用例，那就错了。测试用例必须应用用例设计思路，保证其有效的结构性，可读性，渗透性。
3、依然是需求变更。倘若测试组无法从项目组及时获取到变更的信息，更有甚至连开发组织也没有对变更做出响应，那么用例肯定是无效的了。
4、测试用例必须进行交流评审。在开发组、测试组和项目总体组负责人员和相关分管岗位人员开会讨论后，最终拍板定案。
第三、时间限制。“有限时间内”这一说法，其实又得看具体情况。一周可以算有限时间，一天亦可以做有限时间结点。具体情况具体分析。通常的做法是：
1、测试管理。我们必须从测试管理机制上考虑，努力改善测试的环境，调整项目的管理流程，为有效的测试争取出时间。
2、工作效率。通过建立测试用例库来节省编写测试用例时间。现在都提倡复用的思想，不是仅代码可以复用、构件可以复用，公用测试用例的复用，可以极大程度，提高测试执行的效率。若把测试用例集应用于自动化工具中，这才是真正的会用工具，减少人工劳动力。
3、明确测试范围，严格按测试计划工作，利用有限的资源做有限的事情，使价值最大化。
4、规避风险。类似需求变更等是最大的风险，当然会影响工作效率，应该趁早定义清楚。

综上，要在有限的时间内编写完整有效的测试用例，所涉及到整个软件开发测试过程的方方面面，不是一两个知识点或者有些经验就可以定义的。而关键还是要明确需求，尽量减少需求变更，否则后续编写的用例，也只是做无功用罢了。

个人拙见，请指正。

我是新手,可是我也写了很多用例,首先先写基本功能用例,然后在在基本功能用例上开拓就OK了!

手上项目不紧时，一般是详细设计出来后，或是界面设计出来后就可以开用例
前段时间才根据界面详细设计写了用例，因为没有涉及太多业务，主体上流程用例不多
针对如add,modify,delete,search等共用功能点，我是把它们放在这个项目的公共用例中，在公共用例中把这些全写全，实际用例中调用就行
个人觉得并不是每个页面都重复写，除非有特殊情况。

另外就是像界面详细设计，这个一般要求评审过后，也就是说这一块不会有大变化的情况下
要不然写的就全白费了
也就是在保证需要无大变化的情况下

什么是业务流程?

如何在有限的时间内编写完整有效的测试用例？   
    这是一个好问题,目前大多数中小型软件企业的测试部门都面临这样的问题.公司测试部门人力资源缺乏,同时又面临项目时间紧迫,项目质量又要求较高的问题.面对这样的项目,对我们测试部门来说,是一种严格的考验.这种考验,既是针对测试管理的考验又是针对测试方法和测试策略的考验.我个人认为,面临这样的问题,应从以下几个方面考虑应对方案.
   1、首先是人的问题。当然指测试部门的负责人或者是该项目的测试负责人。一个项目的测试工作做的好坏，除了和测试技术和测试人员素质有关之外，关键是这个项目的负责人的态度。作为项目或部门的负责人，针对一个项目应该从项目的整体去把握该项目的测试深度、测试精度、测试工作重点划分、测试工作阶段重点划分、项目的重点模块指定、测试策略的制定等等。前提条件是考虑该项目的外置环境，包括时间资源、客户要求、项目精度要求、人力资源分配等。
   2、其次是做好准备工作。个人认为，测试工作的计划性主要体现在对于测试的准备工作是否充分。包括针对需求管理的制定、测试关键路径的指定、测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。
   3、最后是测试用例的编写。编写测试用例也有一定的原则。其一，尽可能的利用以往其他项目的测试用例，既测试用例的可重用性的体现；其二，将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改；其三，按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。
   4、这点是我们公司现在正在使用的方法，不一定对，请大家给出评价。我们的测试工作在面临时间紧迫的时候，有时会压缩测试执行时间，并把压缩出来的时间用来编写测试用例。当然，有人会说这样测试执行的时间就不够了，测试就无法完成了。在这里我说明一下我的观点，测试工作的好坏起决定作用的是测试用例的质量高低，而不是测试执行阶段。因此，我们考虑扩充测试用例的编写阶段，同时调集技术支持以及办公室人员来执行测试用例。（因为测试计划中的测试执行是按照测试部成员来做的，我们这样做就可以把测试人员解放出来，调集更多的人手来做测试执行，因此，测试执行并没有被压缩，测试执行依然可以完成。）顺便说一下，BUG的提交还是测试人员来做，只不过测试人员提交BUG的依据变成对被调集人员的测试执行的BUG的重现而已。

测试用例编写要根据具体阶段和具体测试目标而定！如果软件开发很规范，按照软件工程要求在软件开发初期需求完成后就需要开始编写软件测试用例，当软件设计文档完成后，我们的用例也应该完成。这时测试用例的编写就可以根据软件文档和自己对软件的理解和软件有关的标准编写详尽，高覆盖率的测试用例。
    以上说的状况是开发过程比较规范的情况，但大部分公司和项目的测试都存在时间不充足的状况，下面就不同状况具体分析：
    1、根据测试任务所处的阶段：例如是针对某个已完成模块或功能进行单元测试阶段，还是系统测试、集成测试阶段或是回归测试阶段，根据不同测试阶段编写不同的测试用例。
    2、根据测试任务的测试目标：所谓目标是本次测试需要达到什么样的测试结果。如整个软件达到可以正常使用，没有致命和严重的错误出现或是要求某个性能必需达到某个规范或是用户要求等。根据测试目标有针对性的编写测试用例。
     如果出现阶段和目标都不明确，同时又要保证交付用户的质量，在有限的时间内要编写一个比较可行的测试用例那就需要像写开发中的概要设计那样：先划分测试模块，再详细列出测试模块中的测试项，然后尽可能比较全面的描写出每个测试项的测试点和每个测试点的预期结果。如果还有时间的化可以像写详细设计那样补充每个测试项的具体测试方法和步骤。
     以上方法是我多年来在测试工作中的经验总结和体会，本次的问题也是很多公司的一种不规范的做法，还是希望软件公司能够尽可能规范的按照软件开发流程进行开发测试工作，为测试人员提供充足的时间了解产品并进行比较全面和深入的软件测试，真正有效的保证软件质量。

[ 本帖最后由 happybbh2008 于 2008-4-14 08:42 编辑 ]

如何在有限的时间内编写完整有效的测试用例？ 我的经验是：
1，确定测试用例的优先级，首先编写优先级高的测试用例。这类的测试用例有：用户使用频率比较高的功能、客户比较关注的地方和对系统的性能、功能起重要影响作用的地方，还有一些关键路径等。 作为一个系统，需要测试的地方有很多，在有限的时间内编写出所有的测试用例不太可能，也不现实。首先编写优先级高的测试用例可以起到事半功倍的效果。
2，对于一个系统的新Build的测试用例，对于那些没有发生变化的地方，我们可以借鉴以前的测试用例。这样我们只需编写新的功能测试、性能测试等需要的测试用例，同时修改那些发生了变化的用例。

[ 本帖最后由 walker1020 于 2008-4-11 14:17 编辑 ]

有一年多没有做测试了，有以下几点愚见：
1、测试在需求阶段就介入，测试用例编写者必须对业务需求和产品需求的理解达到一定深度，然后完成测试用例初稿，即罗列出基本的测试点
2、详细设计出来后，补充测试用例，即细化测试用例的过程，当然细化程度得看时间上是否许可
3、具体测试开展后，还可以随时对测试用例进行补充

（假定一个测试团队中测试工程师级别不一，用例撰写所需的文档已有，而且测试人员对模块的流程已掌握）
1、高级测试工程师根据特性文档划分模块并评估每个模块所需测试用例数，撰写用例时需用例的用例设计方法，然后评审；

2、高级、中级工程师定义测试用例模板、撰写每个模块的测试用例点（即不撰写测试步骤、预期结果、测试环境等，只写测试标题，定义测试级别），同时，初级工程师并行根据测试用例点展开测试用例撰写；

3、撰写完测试用例点后，高级、中级测试工程师开始着手撰写测试用例和评审测试用例。

PS：用例撰写是一个长期的、迭加的工作，需不定期更新、维护。

如果是我，在收到一个要求编写测试用例的工作要求后，首先通过和程序员沟通，了解尽可能多的程序执行逻辑，并制定出主干流程图，然后根据主干流程图对测试部分进行测试层次划分（主路径测试，烟雾测试，基本功能测试，详细功能测试），接着对需要测试的所有需求进行等价类划分（避免进行重复的测试），最后在流程图主干的基础上，按照测试层次设计出经过等价类划分的代表性功能点编写测试用例
偶是新人，么要笑偶

首先需要在有限的时间内尽量了解所要测试的软件规格以及使用场景，如果有详细的文档是最理想的；如果没有，那就需要和系统组、开发组相关人员进行确认，哪些功能点需要进行完备的测试，需要准备完备的测试用例，哪些功能点只需要基本功能可用就行了，是否需要做性能测试等；

然后，尽量在一个用例内实现功能点的多方面覆盖，比如：管理员的审批操作，我们可以测试管理员审批一个成员、两个成员或者多个成员的情况，而成员又可以申请不同的业务，有可能来自不同的地区，如果时间确实不够，我们可以这样设计用例：
管理员审批多个成员，每个成员来自不同的地区，而各自又申请了不同的业务，管理员审批，查看日志以及数据表检查测试结果是否符合预期

q11111111

1、作需求分析，将测试的点总结出来
2、对集成部分要划逻辑流程图，标识接口信息
3、先设计功能测试用例
4、根据时间要求，编写ui测试用例或是编写ui标准文档来代替ui部分的测试用例
5、用例先执行功能测试用例，然后执行ui部分的测试

我经历了两家公司,都是按照CMMI 5流程管理项目的,关于写用例这一块,我觉得做产品软件和项目软件差别还是很大的.
按照规范流程,用例应该是在详细设计评审结束之后开始写,写完之后要进行同行评审才开始测试.
用例写完整很困难的,不过在同行评审过程中,对用例的完整和正确性,还是很重要的.
还有就是测试肯定要进行很多轮的,每一轮测试过程中,发现用例不完整的也可以补充.
针对需求变更,要及时更改用例,特别是产品软件,是长期测试的依据.

刚刚接触测试，感觉要学的真是不少啊！