软件测试计划和测试用例的不同之处

1. 软件测试计划和测试用例的不同之处

做好测试计划和测试用例的工作的关键是什么？ 
  
 首先要先理解测试计划和测试用例是干什么用的，然后才能讨论他们的关键是什么。
  
 　　测试计划是一个描述测试目的，测试范围，测试方法以及测试需要多少资源的项目文档。它包括标题，软件版本，文档目的，软件概要，需求跟踪，项目组织结构，项目风险分析，测试范围，测试环境（数据环境与软硬件环境），测试方法以及附件等。
  
 　　测试用例是描述如何进行测试的说明书，包括输入什么，做什么样的动作然后期待会有什么样的结果。据此判断软件程序是否工作正确。它包括用例标识符，名称，目的，条件，输入数据需求，执行步骤和期待结果等欢迎加入测试交流群（1017539290），可以与大牛在线随时讨论自己感兴趣的话题，让自己用最少的时间学到最多的东西。。
  
 　　个人觉得测试计划是要在有限的资源下将测试工作做足，关键的是把测试范围定好，保证各测试点我们都能测试一遍。这个测试范围是是测试需求。
  
 　　测试用例关键觉得是要知道自己期待什么结果，以结果定步骤与数据输入。这样的用例覆盖软件需求才比较容易。
  
 　　至于说有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？我觉得如果是条件允许，我指的条件允许是说在完成常规执行后能时间做事，这样做也是可行的，只要他做的确实是软件试用者会如此做无可厚非。
  
 
  
                                          
 　　1）测试计划
  
 　　测试计划是测试阶段中的第一个阶段，首先将测试作为一个项目来看，应该有一个计划，那么既然是计划，一般解决的是5W（what、when、where、who、How）的问题，即：在什么时候由谁来完成什么样的任务；所以要做一个测试的计划首先要理解需求，需求又可以分为“用户需求”、“需求分析”、“测试需求”；那么我们根据做计划人能够接触的需求的不同（或者根据公司的具体情况进行分析）；通过需求的分析我们可以分析出What？我们要测试什么。然后我们去分析我们可以掉空的资源，资源不是无限的，需要我们去获取和合理利用；资源又分为人力资源、时间资源、设备资源等等，我们如何分配这些资源，如何合理利用这些资源是需要我们去规划，所以在这里需要在测试计划中有时间进度安排，人力资源分配和测试环境的安排；通过这个分析分析出WhoWhere和When，另外需要完成测试这项活动，我们采用什么样的方法，也是必要的，所以在测试计划中需要有对于各项测试的方法的安排，这样分析有了How。另外做任何一件事情都会存在着风险，所以在制定测试计划的时候需要包含风险，及其风险分析；欢迎加入测试交流群（1017539290），可以与大牛在线随时讨论自己感兴趣的话题，让自己用最少的时间学到最多的东西。
  
 　　总这对于测试计划来说，我觉得需要对测试这项活动进行合理的安排，需要编写测试计划的人有一个清晰的逻辑、另外测试计划在编写之前的分析是很重要的，这些分析，包括了需求分析、用户或者开发人员的沟通、AUT（被测系统的分析）、测试方法的分析、等等。
  
 　　另外在编写这些文档的时候可以借鉴一些国际的标准，比如IEEE有一个测试计划的标准化模板。
  
 
  
                                          
 　　2）测试用例
  
 　　测试用例是属于测试的设计阶段，它是对于测试方案（testsolution）的一个细化过程；在我们知道了测试什么（测试的具体功能点）后，来解决如何来测试的一个实现过程；测试用例的设计我觉得终要是分析和实现，分析包括对于需求的分析和系统的分析，实现是在充分考虑了各种情况和足够的数据情况下，以文档方式对测试用例的实现。

2. 软件测试中，测试计划是什么？

测试计划就是在编写测试用例前制定的一个计划，主要包括确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
 测试计划编写6要素（5W1H）
1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
根据上面的条目写不会有问题的。

3. 软件测试计划的测试要求

软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。依据特定的项目，在一个测试计划中可能包括下面项目：1、标题；2、软件标识，包括版本/发布版本号；3、目录；4、文档的目的和阅读人群；5、测试的对象；6、软件产品概述；7、相关文档列表，例如需求规格、设计文档和其它测试计划等；8、有关的标准和法规；9、可追溯的需求；10、有关的命名约定和标识约定；11、软件项目的相关的所有部门和成员/联系信息/职责；12、测试项目组和人员/联系信息/职责；13、假设和依赖；14、项目风险分析；15、测试优先级和重点；16、范围和测试限制；17、测试描述－根据测试类型、特征、功能、过程、系统、模块等分类；18、输入等价类分类描述、边界值分析、错误分类；19、测试环境－软、硬件、操作系统、其它需要的软件、数据配置、与其它系统的接口；20、测试环境有效性分析－测试环境的不同和产品系统对测试有效性的影响；21、测试环境建立和配置问题；22、软件移植性考虑；23、软件配置管理过程；24、测试数据建立需求；25、系统日志描述/错误日志/其它的能力和工具，例如屏幕捕获工具、这对于描述bug和报告bug是很有用的；26、讨论任何测试人员用来发现bug或跟踪bug的硬件、软件工具；27、测试自动化－采用的理由和描述；28、采用的测试工具、包括版本、补丁等；29、测试脚本/测试代码维护过程和版本控制；30、跟踪和解决－工具和步骤31、用于项目的测试度量标准；32、报告需求和测试交付产品；33、软件入口和出口标准；34、初期确定的测试周期和标准；35、测试暂停和重启标准；36、人员分配；37、人员岗前培训；38、测试地点/场所；39、测试项目组之外可用的资源和他们的作用、职责、交付、联系人和协调等问题；40、与所有权相关的级别、分类、安全和许可问题；41、公开的一些问题。

4. 软件测试计划的测试作用

一个好的测试计划可以起到如下作用：1、使测试工作和整个开发工作融合起来；2、资源和变更事先作为一个可控制的风险。

5. 如何制定软件测试计划

制定计划
　　1. 分析产品
　　分析什么
　　用户(他们是谁，他们做什么的)
　　操作(这个操作是干什么用的)
　　产品结构(代码，文件，等)
　　产品功能(这些功能是干什么用的)
　　产品数据(输入的，输出的，状态，等)
　　平台(外部的硬件和软件)
　　怎么分析
　　走一下产品/原型的主要流程
　　评审产品和项目文档
　　咨询设计人员和用户
　　与类似的产品做比较
　　可能的工作产出
　　产品的功能范围概要
　　注释性的文档
　　产品的问题列表
　　执行状态检查
　　设计人员有没有确认以及批准了产品的功能范围概要?
　　设计人员有没有认为你已经正确理解了这个产品?
　　你能不能将这个产品形象化并且预测正确的行为?
　　你能不能造出产品的测试数据(输入和结果)?
　　你能不能配置和操作这个产品?
　　你有没有理解这个产品是怎么样被使用的?
　　你有没有注意到设计中的漏洞或不一致的地方?
　　关于这个产品你还有没有未解决的问题?
　　2. 分析产品的风险
　　分析什么
　　产品受到的威胁
　　产品的易受攻击的地方
　　失败的方式
　　失败后的影响
　　怎么分析
　　评审需求和规格说明书
　　评审出现问题的一些事件
　　咨询设计人员和用户
　　通过探索性风险分析和质量判据列表来评审产品
　　识别基本的错误/失败方式
　　可能的工作产出
　　组件风险列表矩阵
　　失败模型概要
　　执行状态检查
　　设计人员和用户有没有对风险分析达成一致?
　　你有没有发现所有的重要的问题，而这些问题是否在测试过程出现呢?
　　你是否知道在哪些地方要集中测试精力并获得最大的效率呢?
　　设计人员有没有做一些事情使得重要的问题更容易的发现，或减少其发生的概率呢?
　　如果你的风险分析是正确的，你是怎么发现的呢?
　　3. 设计测试策略
　　基本策略
　　Domain testing(包括边界值)
　　用户测试
　　压力测试
　　回归测试
　　Sequence testing
　　State testing
　　基于文档的测试
　　结构化测试(单元测试等)
　　怎么计划
　　对于风险和产品功能匹配策略
　　将特殊的和实际的策略形象化
　　分析是否可用自动化的机会
　　使用原型去测试probes和harnesses
　　不要强加计划，让测试人员自己决定
　　可能的工作产出
　　各个类型的报告怎样应用的测试策略文档
　　风险/任务的matrix
　　已选择的策略中存在的问题或挑战列表
　　对产品覆盖比较少的部分提供的建议
　　测试用例(如果是必须的)
　　执行状态检查
　　设计人员对这个测试策略达成一致了吗?
　　这个策略对于项目每个参与人员以及协助人员都有用吗?
　　这个测试策略是否很基本了?是否也容易的应用到这个产品中?
　　这个测试策略是否透露了所以的重要的问题
　　4. 计划安排
　　安排的内容
　　测试时间的评估和计划
　　易测性的工程分析
　　测试团队人员(详细的能力)
　　测试人员的培训和监督
　　测试人员的任务的指定
　　产品开发信息的收集和管理
　　项目会议，沟通，协调的方式
　　与其他已存在的功能之间的关系，包括开发过程中
　　测试平台的认购和配置
　　测试工具盒自动化
　　需要用到的测试桩和mock
　　测试套的管理和维护
　　建立和输出协议约定
　　测试周期管理
　　问题报告系统和约定
　　测试状态报告的约定
　　代码冻结和增量测试
　　测试后期的压力管理
　　项目阶段输出协议约定
　　测试效率的预估
　　可能的工作产出
　　问题列表
　　项目风险分析
　　任务和责任matrix
　　测试时间表
　　与开发之间的约定和协议
　　执行状态检查
　　这个项目所列的安排是否支持测试策略?
　　是否存在一些问题会阻碍测试的执行?
　　在可见性的问题面前，这些安排和策略是否适合?
　　你现在是否开始测试还是以后整理剩下的问题?
　　5. 分享计划
　　分享的方式
　　让设计人员和股东都参与到整个测试计划的制定过程中
　　更主动的获取关于测试计划的意见
　　尽最大可能帮助开发人员保持进度
　　帮助开发人员理解他们做什么会影响测试
　　与技术支持和写技术文档的人分享产品质量信息
　　让设计人员和开发人员评审并且批准所以相关的文档
　　记录并加强与开发之间的约定
　　让参与人员评审测试计划的细节
　   在测试计划中尽量减少没必要的信息以增加评审的效率
　
   　目标
　　对于测试过程达到一致的理解

来自：领测软件测试网。我本人觉得挺赞的。

6. 软件测试计划怎么写?

1．引言

1．1项目背景

1．2参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）

1．3测试术语

1．4有关项目人员组成以及联系方式（开发人员／版本控制人员／测试人员／软、硬、结构、营销人员等）

2．任务概述

2．1测试范围

2．2测试目标

2．3广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等

7. 如何做好测试计划和测试用例工作

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

8. 如何制定软件项目测试计划

　　问题三：变更的控制
　　测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
　　变更来源于以下几个方面
　　1． 项目计划的变更
　　2． 需求的变更
　　3． 测试产品版本的变更
　　4． 测试资源的变更
　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。
　　对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。
　　第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗？答案是未必。当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。
　　对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。
　　最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。规避风险的办法可能有：
　　一，项目组的需求和实施人员参与系统测试；
　　二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员；
　　三，组织客户方进行确认测试或发布β版本。
　　尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”！不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标――保证项目最终产品的质量！