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

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

如何制定软件测试计划~

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

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

测试计划活动的输出是一份测试计划，它是一份或多份文档，应该由测试团队、开发团队和项目管理层复查。测试计划确定了测试产品所需的资源，确定了我们将测试什么，测试将怎样进行，测试将得到怎样的输出或提交产物。我们一直使用日事清来做软件测试工作。日事清帮你来做软件测试工作计划：一是有明确的目标；二是有详细的计划；三是立刻采取行动；四是修复自己的行动。以上四点是高效完成测试工作的四个基本条件。首先把自己的软件测试计划通通列出来，清空大脑，做一个软件测试计划前的行动。根据自己的轻重缓急来分配软件测试任务。
一是确定测试策略。测试策略一般描述软件测试活动的一般方法和目标。其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。确定测试需求：明确测试的工作范围，需要测试的对象、达到的指标等。可以来源于软件需求，个人经验，以前发生的错误等。
二是确定测试系统。确定测试环境。确定测试工具。确定配置情况。确定测试资源。测试人力资源。测试非人力资源（计算机、工具等）
三是确定测试任务。根据本阶段测试需求，细化测试任务。划分任务优先级，和主要任务关联关系。确定辅助任务清单（如培训等）。确定资源情况。
四是评估和确定测试工作量。目前没有任何一种方法能准确的评估出软件测试工作的工作量，要想更有效的做出估算，必须持之以恒的统计和分析历史数据。主要的估算方法为：分析以前的同类项目、同行专家判断、分解细化项目、经验主意预估模型（代码行(LOC)和功能点(FP)估算法等）。
五是确定时间进度。收集与进度相关的信息：总体工作量估算、人员数量、关键资源、项目时间安排等。确定各阶段任务安排和资源分配，确定里程碑。依据项目总体时间安排，形成进度计划。确定时间段。为每个测试目标规定合理的测试起始/中止时间。通常情况下，功能性需求和非功能性需求的测试存在先后顺序，能并行。
六是评估风险。风险分析、对测试计划中所有要执行的内容进行潜在的风险分析并给出规避措施、确定项目中可能会出问题的地方、如测试人员没有接受必要的培训、测试人员不足、需求变化过快、自动测试技术的采用等、评估风险的发生概率、如风险发生后可能的影响程度、如何降低风险乃至避免风险的方法。
七是确定测试过程评估方法。确定测试过程评估方法、评估内容：测试工作进展/缺陷分布/质量评估、评估间隔：每天/周/月、评估人员/报告原则。

如何写软件测试计划
答：1、软件测试计划是引导控制测试工作按照计划执行的指南针。软件测试计划应该包含的元素有：测试所需资源、测试策略、测试风险预测等 2、前言 1.需要写明本文当编写的目的，是给那些人看的，能起到怎样的作用。2.本文档中出现的专业术语需要有个解释，非软件测试的人员能看懂。3.参考资料，也是我们编写...

如何写软件测试计划
答：1 软件测试计划的编写 基础知识已经分享的差不多了，之后就是我们的收尾工作，今天给大家讲讲我们做测试过程中会用到的一个文档：《软件测试计划》在我们软件测试工作阶段，一共分为五个阶段：计划、设计、执行、评估、验收。可以看到在做软件测试工作的时候，最开始，就是要做好计划工作，也就是软件...

软件测试计划中应该包括什么内容?
答：测试计划的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：1、 测试目标：对测试目标进行简要的描述。2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点...

软件测试六大阶段,你了解吗?
答：本文将为你详细介绍这六个阶段,帮助你更好地了解软件测试流程。明确测试需求首先,我们需要明确测试项目的需求和规格,这样才能有明确的测试目标。主要工作包括深入了解产品特性和用户需求,制定《可测试性需求说明书》和《测试规格》。制定测试计划接下来,我们需要根据测试需求来规划整个测试流程。这个阶段的主要任务...

软件测试中,测试计划是什么?
答：测试计划编写6要素（5W1H）1）why——为什么要进行这些测试；2) what—测试哪些方面，不同阶段的工作内容；3) when—测试不同阶段的起止时间；4) where—相应文档，缺陷的存放位置，测试环境等；5) who—项目有关人员组成，安排哪些测试人员进行测试 6) how—如何去做，使用哪些测试工具以及测试方法...

如何编写测试计划?
答：如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。因为我们可以从软件的开发进度中获得开始...

如何制定软件项目测试计划
答：在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗？答案是未必。当制定计划时，如果项目需求处于动态变化时，...

如何做好测试计划和测试用例工作
答：明确测试的范围和内容（WHAT）；明确测试的目的（WHY）；明确测试的开始和结束日期（WHEN）；明确给出测试文档和软件册存放位置（WHERE）；明确测试人员的任务分配（WHO）；明确指出测试的方法和测试工具（HOW）。3、采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可...

测试计划包括哪些内容
答：1、为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。2、为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。3、开发有效的测试模型，能正确地验证正在开发的软件系统。4、确定测试所需要的时间和资源，以保证其可获得性、有效性...

怎样有效编写软件测试计划
答：测试计划目的是管理测试活动，强调“做什么”，具体体现是组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等。综上所述，想要列出一份有效可执行的测试计划，需要知道软件的项目计划、开发计划、设计方案、里程碑节点、测试资源情况，再根据实际的项目...