51Testing软件测试论坛

标题: 做好测试计划和测试用例的工作的关键是什么？（08-05-30）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-5-30 18:19
标题: 做好测试计划和测试用例的工作的关键是什么？（08-05-30）（获奖名单已公布）
测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

感谢会员magic_zhu提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至6月6日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	godn_1981	当当购物卡50元	34#
二等奖	puchonghui	300论坛积分	11#
二等奖	清风随雨	300论坛积分	35#
三等奖	chengcai	100论坛积分	12#
	sunwenjuan		21#
	deanaa		36#

作者: 阿妮妲 时间: 2008-5-31 13:11
做好测试计划和测试用例的前提要很好的理解项目需求分析。编写测试计划和测试用例可以使测试流程更加清晰、规范，合理安排测试进度。更重要的是他们能够有效的完成测试覆盖率。

作者: liaohuaiyi 时间: 2008-5-31 15:31
标题: 做好测试计划和测试用例的工作的关键是什么？
做好测试计划和测试用例的工作的关键是什么？
首先要先理解测试计划和测试用例是干什么用的,然后才能讨论他们的关键是什么.
测试计划是一个描述测试目的,测试范围,测试方法以及测试需要多少资源的项目文档.它包括标题,软件版本,文档目的,软件概要,需求跟踪,项目组织结构,项目风险分析,测试范围,测试环境(数据环境与软硬件环境),测试方法以及附件等.
测试用例是描述如何进行测试的说明书,包括输入什么,做什么样的动作然后期待会有什么样的结果.据此判断软件程序是否工作正确.它包括用例标识符,名称,目的,条件,输入数据需求,执行步骤和期待结果等.
   个人觉得测试计划就是要在有限的资源下将测试工作做足,关键的就是把测试范围定好,保证各测试点我们都能测试一遍.这个测试范围是就是测试需求.
   测试用例关键觉得是要知道自己期待什么结果.以结果定步骤与数据输入.这样的用例覆盖软件需求才比较容易.
   至于说有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？我觉得如果是条件允许,我指的条件允许是说在完成常规执行后能时间做事,这样做也是可行的,只要他做的确实是软件试用者会如此做就无可厚非.

作者: Wutopia 时间: 2008-6-1 22:47
大部分的做法都是把测试计划放在项目开始阶段拟制和发布。之后由于种种原因导致项目进度与计划不一致，久而久之大家就忽视了计划，把计划留于形式。
其实测试计划是测试生命周期中的一部分，即每次展开测试前都应有计划。我们总是把测试生命周期宏观的来看，其实我们每个版本都可以是一个独立的测试生命周期。始于计划，终于实施。

作者: shptest 时间: 2008-6-2 10:30
标题: 回复 2# 的帖子
支持。

作者: zhsh1203 时间: 2008-6-2 11:51
标题: 做好测试计划和测试用例的工作的关键是什么？
做好测试计划和测试用例的工作的关键是什么？——>个人的看法是如下两点，具体分析请看附件，谢谢！
一、测试计划的有效性和全面性
二、测试用例在测试活动中的作用：

作者: 阳光_测试 时间: 2008-6-2 14:21
标题: 我对于这个问题的理解
1）测试计划
测试计划是测试阶段中的第一个阶段，首先将测试作为一个项目来看，应该有一个计划，那么既然是计划，一般解决的是5W（what、when、where、who、How）的问题，即：在什么时候由谁来完成什么样的任务；所以要做一个测试的计划首先要理解需求，需求又可以分为“用户需求”、“需求分析”、“测试需求”；那么我们根据做计划人能够接触的需求的不同（或者根据公司的具体情况进行分析）；通过需求的分析我们可以分析出What？我们要测试什么。然后我们去分析我们可以掉空的资源，资源不是无限的，需要我们去获取和合理利用；资源又分为人力资源、时间资源、设备资源等等，我们如何分配这些资源，如何合理利用这些资源是需要我们去规划，所以在这里就需要在测试计划中有时间进度安排，人力资源分配和测试环境的安排；通过这个分析分析出Who Where和When，另外需要完成测试这项活动，我们采用什么样的方法，也是必要的，所以在测试计划中需要有对于各项测试的方法的安排，这样分析就有了How。另外做任何一件事情都会存在着风险，所以在制定测试计划的时候需要包含风险，及其风险分析；
总这对于测试计划来说，我觉得需要对测试这项活动进行合理的安排，需要编写测试计划的人有一个清晰的逻辑、另外测试计划在编写之前的分析是很重要的，这些分析，包括了需求分析、用户或者开发人员的沟通、AUT（被测系统的分析）、测试方法的分析、等等
另外在编写这些文档的时候可以借鉴一些国际的标准，比如IEEE就有一个测试计划的标准化模板
2）测试用例
测试用例是属于测试的设计阶段，它是对于测试方案（test solution）的一个细化过程；在我们知道了测试什么（测试的具体功能点）后，来解决如何来测试的一个实现过程；测试用例的设计我觉得最终要是分析和实现，分析包括对于需求的分析和系统的分析，实现是在充分考虑了各种情况和足够的数据情况下，以文档方式对测试用例的实现。
本来还想说很多，但是忽然觉得没有什么可以说的了，欢迎大家讨论指正
blog:http://blog.csdn.net/Test_sunny

作者: typhoon 时间: 2008-6-2 14:49
标题: 做好测试计划和测试用例的工作的关键是什么？
赞成楼上的意见。补充以下观点：
两者前提：了解测试系统，明确测试需求
做好测试计�

作者: luckytom 时间: 2008-6-2 16:29
测试计划指明测试方向，就像文章的大纲。
测试用例是具体实施，就像文章的段落。

好处：重用性较高；可以随时了解测试进度、测试范围；尽量避免因个人当前状态影响测试的完整性

才疏学浅，只能说这么多了

作者: xxxxwjj 时间: 2008-6-2 17:02
测试计划的作用:
1.在测试过程中起指导作用（目标、方法、里程碑的时间……）
2.改善测试任务与测试过程的关系
3.提高测试的组织、规划和管理能力

计划文档中包括：
1.测试项目简介
2.测试项
3.需要测试的特征
4.不需要测试的特征
5.测试的方法（测试人员、测试工具、测试流程）
6.测试开始条件和结束条件
7.测试的准入和准出
8.里程碑时间
9.全部挂起、部分挂起条件，及恢复条件
10.测试提交的结果
11.测试环境（软件、硬件、网络）
12.测试者的任务、联系方式与培训
13.测试进度与跟踪方式
14.测试风险与解决方式
15.变更方式
………………………………
（实际中不同的公司详细程度也不相同）
做任何事都必需有个计划

为什么需要测试用例：
1.在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性；
2.测试用例的使用令软件测试的实施重点突出、目的明确；
3.根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；
4.减少回归测试的复杂程度
5.在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
6.功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升；
7.根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报告；
8.可以根据测试用例的执行等级，实施不同级别的测试；
9.为分析软件缺陷和程序模块质量提供依据；
10.便于大型软件测试项目外包测试指导基础；

现实工作中很多时候会遇到这中情况
需求在哪边？开发脑子里！
需求不明确，没有以文档的形式记录下来，不明确，更变态的是1天一小变，3天一大变（夸张了点o(∩_∩)o），在这种情况下用例的作用是什么？说不定花了好久写了一千条用例（1000条用例不算多的，基本一个超过半年的系统在保证测试覆盖率的情况下用例肯定超过4000条），需求一变，六百条需要维护，工作量之大~~~~
OK变了就维护吧~谁知道刚刚维护好，需求又变了，又有400-500条需要维护~~崩溃了吧
所以就取巧了，测试就不按照测试用例来了，monkey test 单纯的靠脑子想到哪边就测试下，我也这样做过，最后结果是测试很盲目；不知道哪些bug是已经提交过的；不知道还有哪些地方没有测试到；有的时候状态好，发现的bug就多一点，状态不好就完蛋了；最主要的是不知道什么时候可以测试结束（本来以为可以结束了，谁知道一兴奋多点了几下，哇靠bug一个个排队出来，后来又一直点到经理说结束才停止了这个噩梦）

现在还没有想到最好的办法解决
个人觉得需求不明确的时候（测试介入比较晚，介入时界面可以看到，软件基本完成），测试人员应该多于开发沟通，因为开发是最了解需求的人。然后开始“玩”软件，慢慢的了解系统，一段时间后针对一些比较稳定的模块进行写用例进行测试。需求还不稳定的，先进行随即测试，找出的bug记录下来，分析原因，找到bug多发点，将一些严重的bug以用例形式记录下来。慢慢模块稳定后，需求不再大变动的时候，开始编写用例，将以前一些问题也写在用例中，bug多发的地方更全面的覆盖到…………具体编写用例方法就不说了

PS:用例最好不要使用word，excel，很难管理很难管理~~~~而且维护起来真TMD难受；密密麻麻的字和蚂蚁一样；不能测试结果的追踪（大问题啊）

还有测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。

作者: puchonghui 时间: 2008-6-2 21:16
我不知道lz说的做好测试计划中的“做好”两字具体指的是什么
对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已
所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括：进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）
写好测试计划的关键在于：
1 充分了解你的团队的整体实力和团队中每个成员的特点
2 充分理解为当前软件制订的整个研发活动过程
带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：
1 有一个合理的测试计划
2 熟悉相关业务
3 深入体会用户的实际需求
这个不想多解释了，不难理解。

至于测试用例
看到上面不少朋友认为关键在于理解用户需求
其实理解用户实际需求是一切的根本
并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切
当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。
所以我的看法是：
1 对业务理解的深入程度
2 经验
3 有自己的文档
前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动
项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差）

[ 本帖最后由 puchonghui 于 2008-6-2 21:20 编辑 ]

作者: chengcai 时间: 2008-6-2 21:16
做好测试计划和测试用例的关键
   CMMI中测试计划始于项目立项阶段的项目计划。因为在项目计划中包括需求调研、需求开发、设计、编码、测试等一系列阶段的实施预估，在这里制定计划就是要和其他工作相辅相成，相互关联，避免出现孤立测试，盲目测试的情况，从这点上保证了测试目的更接近于问题所在。所以如果希望测试能更有效更有重点的实施开展，测试计划一定要做的非常的详细，通过点线图形来进行项目测试的阶段和里程碑的制定，通过测试用例的编写来保证所测试的内容是100%的覆盖客户的需求，才能保证测试出来的产品是符合客户的口味，才能保证项目顺利的验收。
   那么要做好这些工作关键是以下几点：
1、测试计划的制定
   测试计划是来自于项目计划，那么如果要把测试计划做的详细且符合实际情况，并能更有效的使用各项资源的话，首先要充分反讲项目计划，与项目经理以及相关干系人进行充分的沟通和交流，并把测试计划进行评审，大家一致认同后方可进行实施计划。这点是保证了测试计划的制定这里用比较常用的词语就是合法性要得到充分的展现和认可。
2、测试计划的执行
   有了一个好的测试计划，那么执行起来应该是比较简单的，按部就班的做，当然这是在没有风险没有特殊情况下的，那么在发生特殊情况下比如前期其他工作因为延误导致你的测试计划无法正常执行的时候，该怎么做。个人认为要果断的进行调整自己的测试计划，这里需要说明的是，好的测试计划是有风险预估的，在风险预估的时候就需要考虑到万一别人的计划不能如期完成我们的计划该怎么做，一般是有后备方案，当然也有的是在实际过程中进行迅速依照别人的工作进行调整。并把调整后的工作计划进行通知项目中的所有人，以便你后面工作的人能及时调整他们的计划。不至于影响整个项目的进度。
3、测试用例的制定
每个阶段的测试用例都是根据不同阶段的时候制定。单元测试用例是在详细设计文档进行评审之后，集成测试用例是在概要设计文档评审之后，系统测试用例是在用户规格说明书评审之后，验收测试用例是在用户需求说明书评审之后，所以如果要制定测试用例，那么首先要充分的反讲这些文档，你的测试用例要时刻贴近需求，要100%的覆盖需求，只有测试用例覆盖面全，才能保证执行测试的时候能测试出客户关注的部分的问题。这里还有种情况就是客户的需求变更，那么测试用例是需要做相应的修改，而这些修改是需要记录到需求跟踪矩阵种进而进行跟踪的。
4、测试用例的执行
   测试用例毫无疑问是需要进行100%的执行，但是这里需要说明的是除非是所有的计划都是按照计划书中进行的，但是就像前面所说的，也有特殊情况，前面的工作延误，而总的验收日期不能改这个时候我们需要对我们的测试用例进行分优先级，根据实际情况来进行执行哪些级别的测试用例，以便在最短的时候内发现更多客户关注的功能中存在的问题。
以上针对测试计划，测试用例，关键是抓住制定和执行两个部分重点，这个才是关键。

作者: cyutao8405 时间: 2008-6-2 21:19

原帖由 51testing 于 2008-5-30 18:19 发表
测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东 ...

做好测试计划的关键:1、目的：明确测试目标，增加测试计划的适用性
               2、坚持“5W”原则，明确测试内容和过程
               3、采用评审和更新的机制，保证测试计划能满足用户需求
               创建测试计划和需求说明书、测试用例
做好测试用例的关键：覆盖到测试点为基本
                  开发的组织能力和测试对象的特点

作者: chengcai 时间: 2008-6-2 21:20
补充一下：
所有的计划是需要QA人员进行跟踪和督促，时常进行检查，发现不一致的，要发不一致报告给相关测试人员以及项目经理，并且跟踪进行纠正，直到问题解决，保证计划在实施过程种出现的问题能及时调整和修正，才能更进一部的进行控制进度。

作者: 灯火阑珊 时间: 2008-6-2 21:29
标题: 回复 1# 的帖子
在计划中要制定测试的目标,测试范围,测试的工作进度.还有如果在测试中遇到大的问题如何解决,比如说,大部分的基本功能没有实现,那么这时候就要考虑测试的挂起了.
测试用例的设计不仅要把需求规格说明书中所有的显示功能覆盖到还要站在用户的角度充分的考虑隐试需求.

作者: livehome2008 时间: 2008-6-2 22:06
我觉得做好测试计划和测试用例的工作的关键是要重视！
不仅测试人员本人要重视，也要想办法让该项目所有相关人员都重视测试这个行业，只有真正让大家对软件测试都重视了，测试人员说的话作的事才会有份量，这样下回测试人员在写测试计划和编写测试用例时可能就不只是一天了.

您想想，一天时间做出来的测试，他的结果能好吗？

不知您有没有这样的经验，今天刚考完试，有一题没做出来，晚上回家想了老半天，也没想出来；到了第二天早上坐车或者走路的时候，想出来了。

你说这一天能想的东西毕竟有限，多一天，结果会更好！

[ 本帖最后由 livehome2008 于 2008-6-2 22:12 编辑 ]

作者: 贱王之王 时间: 2008-6-3 08:47
经验，熟悉业务

作者: boymarco 时间: 2008-6-3 11:06
做好测试计划和测试用例的工作的关键是什么？
我认为做好测试计划工作的关键分为两个方面：
1、对整个项目的测试过程的总体把握；
重点在于对测试过程时间的分析和项目所需要测试功能的分解。
2、对测试风险的预计和规避；
对测试中可能遇到的风险进行预估并和项目负责人进行讨论，使得测试过程能够比较顺畅的进行。

测试用例工作的关键：
对需求和概要设计的了解和分析。

作者: wiwimeier 时间: 2008-6-3 11:11
做好测试计划的关键除了要对项目的需求非常了解之外还应该了解公司的开发过程、测试流程及所测产品的特点，当然像编写的测试计划所必须的这些内容：背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、常用术语、提交文档、风险分析等都是必不可少的。
做好一个测试计划需要：
1. 明确测试的目标，增强测试计划的实用性
　　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

做好测试用例的关键，我觉得在白盒测试用例设计中是以较少的用例覆盖尽可能多的内部程序逻辑结果。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。设计测试用例时需要注意的是，除了对整体流程及功能注意外，还要注意强度测试、性能测试、压力测试、边界值测试、稳定性测试、安全性测试等多方面。（测试用例需要考虑的四个基本要素是输入、输出、操作和测试环境；另外，测试用例需要考虑的是测试类型、功能、性能、安全……，此外，还需要考虑用例的重要性和优先级）

作者: 41173344 时间: 2008-6-3 14:10
最重要的是对需求的理解.

通过了解需求,可以制定相应的测试计划: 测试时间,测试步骤,测试环境等等.
通过对需求的深入了解，才能写出好的测试用例以及正确的覆盖范围。

作者: sunwenjuan 时间: 2008-6-3 14:42
就这个问题，我谈一些拙见，我做测试时间不长，有不当之处请指教

测试计划作为测试过程的指导文档，在项目立项阶段就应该和项目计划一起出来，并通过评审

我觉得要写出比较好的测试计划，前提首先要了解项目的整体安排（各个里程碑点或者说关键时间点），这样可以对测试活动的时间安排做一个参考；其次要充分了解被测系统，一旦了解了系统之后，就能够确定出测试范围，测试方法，测试工具，测试所需的工作量，而这些点也正是测试计划的核心；另外还依赖一定的测试经验，这样可以预估到测试过程中存在什么风险，怎么样去规避
在完成测试计划并评审通过之后，并不意味此项工作已经完成，订立计划的目的就是要有人去遵守，去执行，所以就需要对测试计划进行跟踪和维护

对于设计好的测试用例的关键，我觉得最主要还是对业务的熟悉程度，和对被测系统的了解程度，另外也依赖一定的测试经验。虽然说各个测试阶段都有它依据的文档，例如说需求，设计什么的，但是就现实而言，能够真正详细，准确的描述系统实现的文档还是很少的，所以此时就需要更充分的沟通。测试用例设计完成之后，还是评审

作者: bobo45123 时间: 2008-6-3 16:30
做好测试计划和测试用例的工作的关键是什么?

1.弄清楚产品定义书和需求说明文档;
2.在测试计划中应该有比较详细的测试策略和风险评估分析;
3.及时与研发人员沟通,以及时更新测试用例
4.在设计测试用例过程中，可以用purecoverage等覆盖率工具来提高测试用例的有效性

作者: suhuabo 时间: 2008-6-3 16:47
做好测试计划和测试用例的工作的关键是什么？

看了很多人回答，觉得很不错。不过增加点我的意见。
做测试计划和测试用例时要考虑项目组织情况，看了很多大侠的回答觉得都是适合大项目的，需要将文档做好，利于整个项目组的沟通交流。
对于小项目，比如只有2－3开发人员的那种，个人觉得做好测试计划和测试用例的工作的关键是测试人员自身能力和对需求的理解，不需要太多的文档。在这种情况下要注意培养项目团体内的良好交流氛围，文档可以粗点，但关键点必须有。

作者: guoqing423 时间: 2008-6-4 11:01
标题: 个人认为
个人观点：有了好的测试计划才能更好的展开以下的工作，需求分析、测试计划以及测试用例都是为了更好的使工作人员去验证软件，它们一环嵌着一环，需要从根本做起！关键就是客户给的需求规格+自己针对功能点的需求分析！

作者: godn_1981 时间: 2008-6-4 12:17
标题: 继续等~~~~~~

咋就没一个够水准的回答呢？

作者: hjjlearning 时间: 2008-6-4 13:14
呵呵，第一次来回答每周一问题目，一直没时间，这里给出我做项目过程中得出的一些理解，也也欢迎大家来的我的博客探讨软件测试：http://www.51testing.com/?18049

我想做好测试计划和测试用例的工作的关键并不能单单从测试计划和测试用例的功能上来考虑，要从公司角度，测试组织和项目周期进行综合起来。下面谈谈我的看法。
1、公司层面
如果一个公司对测试部门，对测试不重视，那即使你测试计划写的多好，测试用例设计的多完美，测试工作也不可能做的多好，因为公司没有人支持你，没有人重视你，为了赶项目，赶时间，不可能让你那么多时间进行按照测试计划实施测试，按照测试用例进行测试。测试还是靠有经验的测试人员进行支撑，所以第一点，关键是测试工作要获得公司高层的支持
2、项目周期
做一个项目，公司的目的都是为了盈利，有时候为了节约成本可能会缩短项目周期，导致项目进度紧张，在这种情况下不可能写详细的测试计划，详细的测试用例，然后完全按照测试计划进行测试，这种时候可能只能简单写一个测试计划，测试用例也是只是粗写，这个时候可能有经验的测试人员就会起到大作用，其实目前很多中小企业都是这种情况。所以第二点，测试的实施要根据项目的周期进行设计
3、测试部门领导
当你的公司重视测试，而且项目的周期合理时，这种情况下，测试部门领导的才能就显的很重要了，他不但要对项目的需求非常清楚，而且要根据研发的开发计划来制定详细的测试计划，在制定计划中，对部门的每个人的测试任务分配显的至关重要，把不同的人分配到合适的位置上才能发挥巨大的能量。做好了测试计划后，并不能一成不变，要不然测试计划就是白纸一张了，测试经理要时刻根据项目情况对测试计划进行调整，并通知到项目测试人员，而且要时刻关注项目测试情况，做到对项目的整体测试进度进行掌控。对于测试用例，可以在编写完成后进行评审，交流不同的意见，最后进行修改。所以第三点是，测试经理要对测试项目做到时刻掌控
4、需求文档与测试人员
当你的公司既重视测试，又有一个合理的项目周期，以及一个出色的测试领导时。这个项目的测试就完成了一大半了，后续就是考虑需求文档的完善，按照需求进行提取测试需求，使得编写测试用例人员能够对需求有很好的认识，可以写出出色的测试用例，这方面和测试人员的经验还是有很大关系。虽然说，测试用例可以进行评审，但是关键还是看个人经验，这点还是很重要。所以第四点是，需求文档要完善，而且测试人员要理解清楚需求，测试人员有点经验最好。
5、测试人员态度
最后一点，有了好需求，好计划，好用例，好领导。但如果测试人员的态度不好，不用心写测试用例，不按照测试计划执行测试，评审过的用例不进行修改，测试的时候不认真，随意性测试。拿测试计划和测试用例肯定是白纸了。所以第五点是，测试人员要对项目负责，要对自己的态度负责。

作者: 追寻浮华 时间: 2008-6-4 13:54
同意楼上的，很多地方很难做到面面具到的.这是个问题,但至今我没想如何解决这些矛盾。

作者: vxiaoqiangs 时间: 2008-6-4 14:22
测试计划应该是根据整个项目的进度和项目的上线时间来定的吧～～（个人看法）

作者: 土土的豆豆 时间: 2008-6-4 15:38
来了～怎么又是测试用例……
发现这两周提问都提用例方面的，感觉有些小重复了哦，别拍砖，咔咔

计划制定是为保障工作有序的执行。所以，如同其他职业工作者一样，测试人员理应要制定自己工作计划。“做好计划”关键在于：
一、计划的前置条件
根据需求规约，趁早介入测试需求的分析，理清主要测试基本点；
二、计划的合理性
根据测试需求，分析主要测试点和备选测试点，合理安排人力、时间、设备资源等；
三、计划的严谨性
合理安排测试环境及相关资源后，对于整个计划做风险分析，看是否有细节疏忽或者偏离之处；
四、计划的评审
制定计划完成后，要测试负责人或者项目负责人进行评审，通过该计划，方能日后实施；
五、计划的后置条件
重中之重——测试过程保障。计划只有良好贯彻执行，才能有意义。否则，一切都是纸上谈兵。

关于“做好测试计划”就谈这些，至于“测试用例”，个人感觉不必详谈了……
请参阅以前讨论过的两个帖子：
1.http://bbs.51testing.com/thread-110874-1-1.html
2.http://bbs.51testing.com/thread-115662-1-1.html

作者: dabeixiong 时间: 2008-6-4 17:54
关键在于规范...
规范化的需求、功能、概要及详细设计等文档，规范化的管理及开发，规范化的评审制度...好的计划可以很好的指导测试活动，尤其是用例的设计。
好的测试用例同时反作用于测试活动，使测试更容易控制，避免盲目测试。
时间越紧张就越要规范化，规范并不是浪费时间而是节省时间。
如果没有规范，那么计划和用例估计就会像楼主说得那样了...测了等于白测，都不知道测了什么。

作者: livehome2008 时间: 2008-6-4 22:14
我说，怎么有人在那儿看白戏啊？多看伤眼睛啊！

作者: huozheba 时间: 2008-6-4 23:14
标题: 回复：做好测试计划和测试用例的工作的关键是什么
个人谈点想法，觉得测试计划对于客户无休止的需求变更，而项目又不能很有效的做需求变更来说，测试计划其实是空的，而对于频繁的发版本，测试更是没有计划可以讲
测试用例也只能在测试过程中不断修改
说白了，觉得关键是和项目的整个规范流程来走

作者: huihuike 时间: 2008-6-4 23:43
标题: 回复 1# 的帖子
1、测试计划是对整个测试活动的分析，通过它可以明确地知道我们整个测试活动的安排。因此个人觉得测试计划的关键是有效地指导后续测试。
2、测试用例的关键在于有效指导执行测试的方向并防止测试的遗漏。脱离用例的测试也是必要的，有时进行的随机测试往往会发现意想不到的错误。

作者: godn_1981 时间: 2008-6-6 00:14
标题: 轻轻的，我来了，带上我的答案
我觉得以上有不少人回答的很不多，不过我觉得还是有必要补充一些东西。
本人的回答就是实践心得，欢迎大家来看看。
答案地址：http://www.51testing.com/?1592/action_viewspace_itemid_84145.html
欢迎大家常来我的博客，相信你不会感觉白来~~~

作者: 清风随雨 时间: 2008-6-6 14:50
标题: 回答：做好测试计划和测试用例的工作的关键是什么？
测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？
个人认为做好测试计划的编写工作应该从以下几个方面考虑问题：
1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。
   编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。
2、要坚持“5W1H”的原则，明确测试内容与过程。
   明确测试的范围和内容（WHAT）；
   明确测试的目的（WHY）；
   明确测试的开始和结束日期（WHEN）；
   明确给出测试文档和软件册存放位置（WHERE）；
   明确测试人员的任务分配（WHO）；
   明确指出测试的方法和测试工具（HOW）。
3、采用评审和更新机制，确保测试计划满足实际需求。
   因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。
之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。
4、测试策略要作为测试的重点进行描述。
   测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，
而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。
打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出！=实际输出
的情况下，您会认为这样的测试合格么？
至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的
地位和作用主要体现在以下几个方面：
1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；
2、测试用例是团队内部交流以及交叉测试的依据；
3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；
4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；
5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；
6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，
那么，我们就来讨论一下如何有效的保证测试用例的质量。
1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。
2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。
3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。
4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。
以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解，如有不同意见，请大家及时指出和补充。

作者: deanaa 时间: 2008-6-6 16:36
我是一个菜鸟，接触测试时间也不长，根据自己的实践说说我浅薄的理解。
分两部分来说我的感受吧。
首先是做计划，我觉得以下几点是做计划的时候需要关注的。
1.对项目基本情况的了解。基本情况主要是指整个项目或产品的范围，包括时间，成本（资源）和质量要求。作为Test Leader，需要首先和PM沟通的也是这几点。需求分析，设计，开发，测试，发布，这些都是为项目的最终成功服务的。书本上我们学到的是怎么做一个理论上理想状态下的测试计划，但是在现实中不可能有这种理论状态出现的。时间，成本和质量本身是一个互相制约的三角关系，在制定测试计划之前我们一定要很清楚项目的范围和目标，只有在这个前提下我们才可能定出一个满足项目要求的合理的测试计划。
2.风险评估和准备。测试阶段是整个软件开发生命周期中相对靠后的一个阶段，也是对其他阶段的依赖性最高的一个阶段。测试工作本身的成功与否，与前面几个阶段的质量密切相关；而测试阶段又是一个项目最终能否成功的决定性阶段。风险的控制在测试阶段就显得尤为重要。我个人认为风险的评估和准备是否充分合理，是衡量一个测试计划质量高低的关键因素。
3.重视人的作用。我们在计划中，都以人月或人日来标示工作量，而忽略了人与人之间的差异性。在我看来，这是计划过程中一个很容易被忽略的一个风险。我一般通过标示团队中成员的一个能力因子来把每个人的能力差异反应出来。

接下来说说写测试用例时需要关注的东西。版上大牛多多，像覆盖率啊这些最基本的东西我这里就不细说了，说一下大家可能会忽略或者我在实践中认为比较有用的几点。
1.提前介入。我们以前的做法是开发人员开始编码的时候我们也开始写case，但是发现效果不好，而且受需求分析的质量影响很大。后来我们在另一个项目中，BA写好一个需求文档我们就开始写case，同时BA保证对测试团队的支持。这样我们有效的提高了case的有效性，同时在完成需求分析阶段后测试团队就成为了除了BA外对需求最熟悉的团队。
2.避免开发人员的影响。测试团队要尽量避免因为开发过程中的原因修改case，除非BA或者客户同意进行需求变更。
3.变更控制。我们一般要求测试用例在开发阶段前基线化。之后的变更要严格遵循变更管理的流程，对于测试用例来讲，一定要保持和需求文档的同步。需求文档变化，相应的测试用例也要变化，反之，没有需求的变化，测试用例就不能变，除非是测试用例本身的缺陷。

以上是我的一些感受~~~~

作者: lyl419 时间: 2009-7-22 13:34
如果能都变成office文档就好了

作者: achong252159676 时间: 2009-7-22 18:22
我现在就属于拿到东西就测，用例在脑海里，用完了再参考前辈的用例。
测来测去，总觉得在老地方上打转转，没有总体的全面的进行测试，也可能是时间不够的原因。
看了大家的讨论，对测试的理解清晰多了，我一定会多做这方面的工作，再次感谢大家。

[ 本帖最后由 achong252159676 于 2009-7-22 19:20 编辑 ]

作者: yaojinyf 时间: 2009-11-25 16:38
收益颇深

作者: 19801106 时间: 2010-10-18 12:27

作者: whathowhy 时间: 2010-12-6 23:07

我是一个菜鸟，接触测试时间也不长，根据自己的实践说说我浅薄的理解。
分两部分来说我的感受吧。
首先是 ...
deanaa 发表于 2008-6-6 16:36

重视风险评估及人的作用，这两点我比较认同。我比较感兴趣的是，你的变更控制如何做？需求的变更传递到测试人员要多久？测试人员闭环落实修改要多久？估一个？

作者: whathowhy 时间: 2010-12-6 23:13

我觉得以上有不少人回答的很不多，不过我觉得还是有必要补充一些东西。
本人的回答就是实践心得，欢迎大家 ...
godn_1981 发表于 2008-6-6 00:14

可推荐的测试用例管理工具有哪些啊？

作者: zhangnanguozi 时间: 2010-12-14 13:52
我这边没有leader就我一个人怎么办啊之前公司也没有测试文档

作者: alanzhuwei 时间: 2012-4-13 17:54
大侠就是大侠啊

作者: dvvwn 时间: 2012-5-4 18:53
顶......叹为观止.....

作者: 话说我爱你 时间: 2012-11-23 09:57
回复 3# liaohuaiyi
我感觉你关于测试计划中说的比较重要一点你没有提到就是时间点的控制，如果一份好的测试计划会有一个很好的时间控制，其他你说的几项信息业不会也会明确，如果目的、范围、方法、需求都做的特别的好的话，没有一个好的时间点的控制，这个计划还是失败的（个人观点）

作者: 夜猫子诺诺 时间: 2014-2-20 00:22
谢谢

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)