做好测试计划和测试用例的工作的关键是什么？（08-05-30）（获奖名单已公布）

51testing · 发表于 2008-5-30 18:19: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:30

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

liaohuaiyi · 发表于 2008-5-31 15:31:03

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

Wutopia · 发表于 2008-6-1 22:47:34

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

shptest · 发表于 2008-6-2 10:30:34

支持。

zhsh1203 · 发表于 2008-6-2 11:51:30

做好测试计划和测试用例的工作的关键是什么？——>个人的看法是如下两点，具体分析请看附件，谢谢！
一、测试计划的有效性和全面性
二、测试用例在测试活动中的作用：

阳光_测试 · 发表于 2008-6-2 14:21:55

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:25

赞成楼上的意见。补充以下观点：
两者前提：了解测试系统，明确测试需求
做好测试计�

luckytom · 发表于 2008-6-2 16:29:58

测试计划指明测试方向，就像文章的大纲。
测试用例是具体实施，就像文章的段落。

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

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

xxxxwjj · 发表于 2008-6-2 17:02:33

测试计划的作用:
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:46

我不知道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:58

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

cyutao8405 · 发表于 2008-6-2 21:19:04

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

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

chengcai · 发表于 2008-6-2 21:20:02

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

灯火阑珊 · 发表于 2008-6-2 21:29:03

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

livehome2008 · 发表于 2008-6-2 22:06:26

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

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

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

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

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

贱王之王 · 发表于 2008-6-3 08:47:07

经验，熟悉业务

boymarco · 发表于 2008-6-3 11:06:57

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

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

wiwimeier · 发表于 2008-6-3 11:11:47

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

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

41173344 · 发表于 2008-6-3 14:10:45

最重要的是对需求的理解.

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

		自动登录	找回密码
密码			(注-册)加入51Testing

做好测试计划和测试用例的工作的关键是什么？（08-05-30）（获奖名单已公布）

相关帖子

做好测试计划和测试用例的工作的关键是什么？

回复 2# 的帖子

做好测试计划和测试用例的工作的关键是什么？

本帖子中包含更多资源

我对于这个问题的理解

做好测试计划和测试用例的工作的关键是什么？

回复 1# 的帖子

站长推荐 /1