测试计划作为测试过程的指导文档，在项目立项阶段就应该和项目计划一起出来，并通过评审
我觉得要写出比较好的测试计划，前提首先要了解项目的整体安排（各个里程碑点或者说关键时间点），这样可以对测试活动的时间安排做一个参考；其次要充分了解被测系统，一旦了解了系统之后，就能够确定出测试范围，测试方法，测试工具，测试所需的工作量，而这些点也正是测试计划的核心；另外还依赖一定的测试经验，这样可以预估到测试过程中存在什么风险，怎么样去规避
在完成测试计划并评审通过之后，并不意味此项工作已经完成，订立计划的目的就是要有人去遵守，去执行，所以就需要对测试计划进行跟踪和维护
对于设计好的测试用例的关键，我觉得最主要还是对业务的熟悉程度，和对被测系统的了解程度，另外也依赖一定的测试经验。虽然说各个测试阶段都有它依据的文档，例如说需求，设计什么的，但是就现实而言，能够真正详细，准确的描述系统实现的文档还是很少的，所以此时就需要更充分的沟通。测试用例设计完成之后，还是评审 做好测试计划和测试用例的工作的关键是什么?
1.弄清楚产品定义书和需求说明文档;
2.在测试计划中应该有比较详细的测试策略和风险评估分析;
3.及时与研发人员沟通,以及时更新测试用例
4.在设计测试用例过程中，可以用purecoverage等覆盖率工具来提高测试用例的有效性 做好测试计划和测试用例的工作的关键是什么？
看了很多人回答，觉得很不错。 不过增加点我的意见。
做测试计划和测试用例时要考虑项目组织情况，看了很多大侠的回答觉得都是适合大项目的，需要将文档做好，利于整个项目组的沟通交流。
对于小项目，比如只有2－3开发人员的那种，个人觉得做好测试计划和测试用例的工作的关键是测试人员自身能力和对需求的理解，不需要太多的文档。 在这种情况下要注意培养项目团体内的良好交流氛围， 文档可以粗点，但关键点必须有。
个人认为
个人观点：有了好的测试计划才能更好的展开以下的工作，需求分析、测试计划以及测试用例都是为了更好的使工作人员去验证软件，它们一环嵌着一环，需要从根本做起！关键就是客户给的需求规格+自己针对功能点的需求分析！继续等~~~~~~
:lol :lol 咋就没一个够水准的回答呢？ 呵呵，第一次来回答每周一问题目，一直没时间，这里给出我做项目过程中得出的一些理解，也也欢迎大家来的我的博客探讨软件测试：http://www.51testing.com/?18049我想做好测试计划和测试用例的工作的关键并不能单单从测试计划和测试用例的功能上来考虑，要从公司角度，测试组织和项目周期进行综合起来。下面谈谈我的看法。
1、公司层面
如果一个公司对测试部门，对测试不重视，那即使你测试计划写的多好，测试用例设计的多完美，测试工作也不可能做的多好，因为公司没有人支持你，没有人重视你，为了赶项目，赶时间，不可能让你那么多时间进行按照测试计划实施测试，按照测试用例进行测试。测试还是靠有经验的测试人员进行支撑，所以第一点，关键是测试工作要获得公司高层的支持
2、项目周期
做一个项目，公司的目的都是为了盈利，有时候为了节约成本可能会缩短项目周期，导致项目进度紧张，在这种情况下不可能写详细的测试计划，详细的测试用例，然后完全按照测试计划进行测试，这种时候可能只能简单写一个测试计划，测试用例也是只是粗写，这个时候可能有经验的测试人员就会起到大作用，其实目前很多中小企业都是这种情况。所以第二点，测试的实施要根据项目的周期进行设计
3、测试部门领导
当你的公司重视测试，而且项目的周期合理时，这种情况下，测试部门领导的才能就显的很重要了，他不但要对项目的需求非常清楚，而且要根据研发的开发计划来制定详细的测试计划，在制定计划中，对部门的每个人的测试任务分配显的至关重要，把不同的人分配到合适的位置上才能发挥巨大的能量。做好了测试计划后，并不能一成不变，要不然测试计划就是白纸一张了，测试经理要时刻根据项目情况对测试计划进行调整，并通知到项目测试人员，而且要时刻关注项目测试情况，做到对项目的整体测试进度进行掌控。对于测试用例，可以在编写完成后进行评审，交流不同的意见，最后进行修改。所以第三点是，测试经理要对测试项目做到时刻掌控
4、需求文档与测试人员
当你的公司既重视测试，又有一个合理的项目周期，以及一个出色的测试领导时。这个项目的测试就完成了一大半了，后续就是考虑需求文档的完善，按照需求进行提取测试需求，使得编写测试用例人员能够对需求有很好的认识，可以写出出色的测试用例，这方面和测试人员的经验还是有很大关系。虽然说，测试用例可以进行评审，但是关键还是看个人经验，这点还是很重要。所以第四点是，需求文档要完善，而且测试人员要理解清楚需求，测试人员有点经验最好。
5、测试人员态度
最后一点，有了好需求，好计划，好用例，好领导。但如果测试人员的态度不好，不用心写测试用例，不按照测试计划执行测试，评审过的用例不进行修改，测试的时候不认真，随意性测试。拿测试计划和测试用例肯定是白纸了。所以第五点是，测试人员要对项目负责，要对自己的态度负责。 同意楼上的，很多地方很难做到面面具到的.这是个问题,但至今我没想如何解决这些矛盾。 测试计划应该是根据整个项目的进度和项目的上线时间来定的吧～～（个人看法） 来了～怎么又是测试用例……
发现这两周提问都提用例方面的，感觉有些小重复了哦，别拍砖，咔咔:P
计划制定是为保障工作有序的执行。所以，如同其他职业工作者一样，测试人员理应要制定自己工作计划。“做好计划”关键在于：
一、计划的前置条件
根据需求规约，趁早介入测试需求的分析，理清主要测试基本点；
二、计划的合理性
根据测试需求，分析主要测试点和备选测试点，合理安排人力、时间、设备资源等；
三、计划的严谨性
合理安排测试环境及相关资源后，对于整个计划做风险分析，看是否有细节疏忽或者偏离之处；
四、计划的评审
制定计划完成后，要测试负责人或者项目负责人进行评审，通过该计划，方能日后实施；
五、计划的后置条件
重中之重——测试过程保障。计划只有良好贯彻执行，才能有意义。否则，一切都是纸上谈兵。
关于“做好测试计划”就谈这些，至于“测试用例”，个人感觉不必详谈了……
请参阅以前讨论过的两个帖子：
1.http://bbs.51testing.com/thread-110874-1-1.html
2.http://bbs.51testing.com/thread-115662-1-1.html 关键在于规范...
规范化的需求、功能、概要及详细设计等文档，规范化的管理及开发，规范化的评审制度...好的计划可以很好的指导测试活动，尤其是用例的设计。
好的测试用例同时反作用于测试活动，使测试更容易控制，避免盲目测试。
时间越紧张就越要规范化，规范并不是浪费时间而是节省时间。
如果没有规范，那么计划和用例估计就会像楼主说得那样了...测了等于白测，都不知道测了什么。 我说，怎么有人在那儿看白戏啊？多看 伤眼睛啊！
回复：做好测试计划和测试用例的工作的关键是什么
个人谈点想法，觉得测试计划对于客户无休止的需求变更，而项目又不能很有效的做需求变更来说，测试计划其实是空的，而对于频繁的发版本，测试更是没有计划可以讲测试用例也只能在测试过程中不断修改
说白了，觉得关键是和项目的整个规范流程来走:)
回复 1# 的帖子
1、测试计划是对整个测试活动的分析，通过它可以明确地知道我们整个测试活动的安排。因此个人觉得测试计划的关键是有效地指导后续测试。2、测试用例的关键在于有效指导执行测试的方向并防止测试的遗漏。脱离用例的测试也是必要的，有时进行的随机测试往往会发现意想不到的错误。
轻轻的，我来了，带上我的答案
我觉得以上有不少人回答的很不多，不过我觉得还是有必要补充一些东西。本人的回答就是实践心得，欢迎大家来看看。
答案地址：http://www.51testing.com/?1592/action_viewspace_itemid_84145.html
欢迎大家常来我的博客，相信你不会感觉白来~~~
回答：做好测试计划和测试用例的工作的关键是什么？
测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？个人认为做好测试计划的编写工作应该从以下几个方面考虑问题：
1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。
编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。
2、要坚持“5W1H”的原则，明确测试内容与过程。
明确测试的范围和内容（WHAT）；
明确测试的目的（WHY）；
明确测试的开始和结束日期（WHEN）；
明确给出测试文档和软件册存放位置（WHERE）；
明确测试人员的任务分配（WHO）；
明确指出测试的方法和测试工具（HOW）。
3、采用评审和更新机制，确保测试计划满足实际需求。
因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。
之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。
4、测试策略要作为测试的重点进行描述。
测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，
而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。
打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出！=实际输出
的情况下，您会认为这样的测试合格么？
至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的
地位和作用主要体现在以下几个方面：
1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；
2、测试用例是团队内部交流以及交叉测试的依据；
3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；
4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；
5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；
6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，
那么，我们就来讨论一下如何有效的保证测试用例的质量。
1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。
2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。
3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。
4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。
以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解，如有不同意见，请大家及时指出和补充。 我是一个菜鸟，接触测试时间也不长，根据自己的实践说说我浅薄的理解。
分两部分来说我的感受吧。
首先是做计划，我觉得以下几点是做计划的时候需要关注的。
1.对项目基本情况的了解。基本情况主要是指整个项目或产品的范围，包括时间，成本（资源）和质量要求。作为Test Leader，需要首先和PM沟通的也是这几点。需求分析，设计，开发，测试，发布，这些都是为项目的最终成功服务的。书本上我们学到的是怎么做一个理论上理想状态下的测试计划，但是在现实中不可能有这种理论状态出现的。时间，成本和质量本身是一个互相制约的三角关系，在制定测试计划之前我们一定要很清楚项目的范围和目标，只有在这个前提下我们才可能定出一个满足项目要求的合理的测试计划。
2.风险评估和准备。测试阶段是整个软件开发生命周期中相对靠后的一个阶段，也是对其他阶段的依赖性最高的一个阶段。测试工作本身的成功与否，与前面几个阶段的质量密切相关；而测试阶段又是一个项目最终能否成功的决定性阶段。风险的控制在测试阶段就显得尤为重要。我个人认为风险的评估和准备是否充分合理，是衡量一个测试计划质量高低的关键因素。
3.重视人的作用。我们在计划中，都以人月或人日来标示工作量，而忽略了人与人之间的差异性。在我看来，这是计划过程中一个很容易被忽略的一个风险。我一般通过标示团队中成员的一个能力因子来把每个人的能力差异反应出来。
接下来说说写测试用例时需要关注的东西。版上大牛多多，像覆盖率啊这些最基本的东西我这里就不细说了，说一下大家可能会忽略或者我在实践中认为比较有用的几点。
1.提前介入。我们以前的做法是开发人员开始编码的时候我们也开始写case，但是发现效果不好，而且受需求分析的质量影响很大。后来我们在另一个项目中，BA写好一个需求文档我们就开始写case，同时BA保证对测试团队的支持。这样我们有效的提高了case的有效性，同时在完成需求分析阶段后测试团队就成为了除了BA外对需求最熟悉的团队。
2.避免开发人员的影响。测试团队要尽量避免因为开发过程中的原因修改case，除非BA或者客户同意进行需求变更。
3.变更控制。我们一般要求测试用例在开发阶段前基线化。之后的变更要严格遵循变更管理的流程，对于测试用例来讲，一定要保持和需求文档的同步。需求文档变化，相应的测试用例也要变化，反之，没有需求的变化，测试用例就不能变，除非是测试用例本身的缺陷。
以上是我的一些感受~~~~ 如果能都变成office文档就好了 我现在就属于拿到东西就测，用例在脑海里，用完了再参考前辈的用例。
测来测去，总觉得在老地方上打转转，没有总体的全面的进行测试，也可能是时间不够的原因。
看了大家的讨论，对测试的理解清晰多了，我一定会多做这方面的工作，再次感谢大家。
[ 本帖最后由 achong252159676 于 2009-7-22 19:20 编辑 ] 收益颇深:) :)
