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

测试阶段划分为哪几个阶段

现在测试要看是什么模型： 本着及早介入的原则 最早可以从需求分析介入 开始算起的话 1.验收测试计划 2.系统测试计划 3. 集成测试计划 4. 单元测试计划 5. 单元测试 6. 集成测试 7.系统测试 8.验收测试 测试阶段的划分有多种理论 但是一般都有 单元 -集成 - 系统 -验收 阶段~！

什么是测试策略？

测试策略描述测试工程的总体方法和目标。

描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。

测试策略的制定主要包含三个方面的内容： （1）确定测试过程要使用的测试技术和工具； （2）制定测试启动、停止、完成标准； （3）进行风险分析和应对方案。

例如测试与外部接口或者模拟物理损坏、安全性威胁。

测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。

扩展资料。

测试英文名Test、Measure;中文拼音cè shì;由中文"测"与中文"试"两个字组成的词语。

是动词、名词。

测试行为，一般发生于为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证，并最终得出特定的结果。

如何写一份靠谱的软件测试计划

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

可以看到在做软件测试工作的时候，最开始，就是要做好计划工作，也就是软件测试计划。

在软件测试计划里面应该包含哪些内容呢？ 包括这些： 1）测试开始时间 &测试结束时间 2）测试的内容模块定位（包含哪些内容测试点） 3）测试的参与人员以及任务分工 4）输出文档的规定以及存放 5）采用的测试方法以及测试工具的申请。

其实就总结起来，就是大家看见过的5W原则： When:什么时候开始做，什么时候结束测试，要在这段时间内做好一个规划与进度。

What：我们要做什么？要明确的罗列出来，好明确我们的测试方向和重点，并方便后期划分责任模块 Who：谁要参与这次项目的测试？具体负责哪个模块的功能测试？主要负责任务是？都是在这个里面进行明确的责任划分 How：如何测试，确定我们的测试方法：是白盒测试还是黑盒测试？我们要不要进行自动化测试要不要进行性能压力测试？要不要进行安全性测试，都需要在这个里面计划好。

Where：这个是说把文档放在哪里，就明确的包括了我们的输出文档有哪些：比如说测试用例？Bug列表？测试报告等等文档要存放的位置，作用就是规定输出文档以及输出文档的存放位置。

怎么样，这么一说，是不是觉得软件测试报告要很好理解了呢? 今天给大家分享了软件测试报告的编写！更多问题可以加群 333782754 小编每天都按时推送，关注我们打发你的琐碎时间。

如果你有别的见解，也非常欢迎留言！

软件测试计划怎么写?

展开全部 呵呵！这是测试计划模版 请拿 Wo XXX公司 文档编号 项目版本 密级 项目名称： 共14页 XXX项目测试计划 拟制： 日期： yyyy/mm/dd 审核： 日期： yyyy/mm/dd 批准： 日期： yyyy/mm/dd 修订记录 日期 修订版本 描述 作者 yyyy/mm/dd XX版本 初稿完成 XXX 目 录 1目标 6 2 概述 6 2.1 项目背景 6 2.2 范围 6 3 组织形式 6 4 测试对象 8 5 需求跟踪 9 6 测试通过/失败标准 9 7 测试挂起标准及恢复条件 9 8 测试任务安排 10 8.1 任务1 10 8.1.1方法和标准： 10 8.1.2 输入/输出： 10 8.1.3 时间安排： 10 8.1.4 资源 ： 10 8.1.5 风险和假设： 10 8.1.6 角色和职责： 10 8.2 任务2 11 8.2.1 方法和标准： 11 8.2.2 输入/输出： 11 8.2.3 时间安排： 11 8.2.4 资源 ： 11 8.2.5 风险和假设： 11 8.2.6 角色和职责： 11 8.3 任务3 11 8.3.1 方法和标准： 11 8.3.2 输入/输出： 11 8.3.3 时间安排： 11 8.3.4 资源 ： 12 8.3.5 风险和假设： 12 8.3.6 角色和职责： 12 8.4 任务4 12 8.4.1 方法和标准： 12 8.4.2 输入/输出： 12 8.4.3 时间安排： 12 8.4.4 资源 ： 12 8.4.5 风险和假设： 12 8.4.6 角色和职责： 12 9 应交付的测试工作产品 13 10 工作量估计 13 11 资源的分配 13 12 附录 14 XXX项目系统测试计划 关键词： 摘 要： 缩略语清单： 参考资料清单： 名称 作者 编号 发布日期 出版单位 1目标 所有测试需求都已被标识出来；测试的工作量已被正确估计并合理地分配了人力、物力资源；测试的进度安排是基于工作量估计的、适用的；测试启动、停止的准则已被标识；测试输出的工作产品是已标识的、受控的和适用的。

2 概述 2.1 项目背景 简要描述项目背景及所要求达到的目标，如项目的主要功能特征、体系结构及简要历史等。

（开发者、架构、主要运行环境、主要功能、目标用户。

） 2.2 范围 指明该计划的适用对象及范围。

3 组织形式 描述参加系统测试的各测试项目组的组织结构（可以图的形式），通过文字形式来描述各组织在系统测试中的职责和组织间关系，也可以描述测试项目组内部的结构，和各组成员的职责。

描述本软件组织中关于系统测试过程和开发过程、项目管理过程、质量保证过程、配置管理过程等过程相关联的部分。

明确测试组和开发组、配置管理组、质量保证组等相关组的沟通渠道，保证系统测试过程中的问题能技术沟通和解决，保证系统测试工作的顺利进行；同时要从组织上明确测试人员发现问题和监督问题解决的权利，保证测试人员的工作积极性，使得软件质量能从组织上得到保证；另外还要明确测试工作产品输出的权利，即由谁来签发《系统测试计划》、《系统测试方案》等测试文档和最终的《系统测试报告》，一般软件组织已经对此有了明确定义，如果没有，做计划时需要明确下来。

举例： 1）测试组内部组织结构 2）测试组与其它部门之间的关系 3）沟通渠道 测试组组长： 1、制订本组测试计划； 2、给测试分析员分配任务并依据制定的计划指导和监控他们的工作； 3、给测试员分配任务并依据制定的计划指导和监控他们的工作； 4、与开发组保持联系和沟通，例如确定版本发布日期、沟通版本质量进展、缺陷发展趋势； 5、组织本组测试文档的设计、写作和评审； 6、组织本组进行相关需求跟踪； 7、组织本组进行缺陷分析等质量活动； 8、向测试主管等高层领导汇报本组工作 测试分析员： 测试员： 4 测试对象 这里列出系统测试计划活动中分析确定的所有功能测试项目和非功能测试项目；还要列出测试项目中的哪些特性和特性组合将不被测试，并说明不被测试的原因。

在这里所列的测试项仅仅是为了表达应测试什么，至于如何测试可以在测试方案中进行描述。

举例： 1）业务功能 业务流程 数据库事务 域值合法性 …... 2）用户界面 对象状态 窗口模式 菜单 标准尺寸的控件/文字 …... 3）性能 在3秒内对用户登陆请求给出响应 当系统内存低于32M的情况下运行应用程序，考察其性能指标 为设计规定是 1,000,000 条记录的系统增加 1,000,001条记录 …... 4）配置 在windows 98系统下进行配置测试 在Unix系统下进行配置测试 …... 5）安装 新安装（典型安装、定制安装） 光盘升级安装 网络升级安装 …... 5 需求跟踪 建立测试需求跟踪矩阵表 举例： 需求标识 需求描述 系统测试项标识 系统测试项描述 Router_V100_SRS_001 路由增加 Router_V100_ST_AddRoute 路由增加 6 测试通过/失败标准 本节描述系统测试计划活动中确定的系统测试通过/ 失败标准，这是判断测试过程通过或失败的标准，而不是被测对象通过或失败的标准。

举例： 1）达到100％需求覆盖； 2）所有1级、2级用例被执行，3级、4级用例执行率达到60％； 3）测试过程中缺陷率达到公司系统测试质量标准 7 测试挂起标准及恢复条件 描述系统测试计划活动中确定的系统测试挂起标准/恢复条件 举例： 系统测试挂起标准举例： 1）基本功能测试不能通过； 2）出现致命问题导致30％用例被堵塞，测试无法执行下去 。

。

。

。

。

。

系统测试恢复条件举例： 1）导致测试堵塞的问题被修复，并通过了回归测试； 。

。

。

。

。

8 测试任务安排 8.1 任务1 8.1.1方法和标准： 指明执行该任务时，应采用的方法以及所应遵循的标准 8.1.2 输入/输出： 给出该任务所必需的输入及输出 8.1.3 时间安排： 给出任务的起始及持续的时间，为方便文档维护，建议采用相对时间，即任务的起始时 间是相对于某一里程碑或阶段的相对时间 8.1.4 资源 ： 给出任务所需要的人力和物力资源，工作量应明确到“人天” 8.1.5 风险和假设： 指明启动该任务应满足的假设以及任务执行可能存在的风险 8.1.6 角色和职责： 指明由谁负责该任务的组织和执行，以及谁将担负怎样的职责 8.2 任务2 8.2.1 方法和标准： 8.2.2 输入/输出： 8.2.3 时间安排： 8.2.4 资源 ： 8.2.5 风险和假设： 8.2.6 角色和职责： 8.3 任务3 8.3.1 方法和标准： 8.3.2 输入/输出： 8.3.3 时间安排： 8.3.4 资源 ： 8.3.5 风险和假设： 8.3.6 角色和职责： 8.4 任务4 8.4.1 方法和标准： 8.4.2 输入/输出： 8.4.3 时间安排： 8.4.4 资源 ： 8.4.5 风险和假设： 8.4.6 角色和职责： 9 应交付的测试工作产品 本节描述系统测试计划活动中确定的测试完成后应交付的测试文档、测试代码及测试工具等测试工作产品。

举例： ? 系统测试计划 ? 系统测试方案 ? 系统测试用例 ? 系统测试规程 ? 系统测试日志 ? 系统测试报告 ? 。

。

。

。

。

。

10 工作量估计 根据前面安排的任务，估计各任务的工作量，具体到人天 举例： 序号 任务名称 负责人 工作量（人天） 1 计划测试 张三 1人天 2 设计测试 李四 2人天 3 实现测试 王五 3人天 4 执行测试 赵六 4人天 … … … … … … … … 总计: 11 资源的分配 本节汇总所有任务中所需要的资源 举例： 1）人员及培训需求： 依据角色及职责和测试任务安排”中的资源，确定所需人员及培训要求，应指明人员与角色之间的映射关系 2）测试环境、测试工具： 依据测试任务安排中的资源，确定所需的测试环境及测试工具 3）测试仪器或材料： 确定所需测试仪器和设备的要求。

指定仪表仅需写型号即可，非指定仪表需给出测量精度要求等。

仪表需给出足够的信息，如测试中使用AM8e，则表示如下： 呼叫分析仪 + Ameritec + AM8e 功能名称 生产厂家 仪器型号 生产厂家如有缩略语，则用缩略语表示，如HP，W&G等。

4）其他需求： 确定需要的特殊工具，确定其他任何测试需要（如，办公室空间需要等），确定对测试小组来说目前还没有但是必需的需求的来源。

12 附录

测试计划包括哪些内容

测试计划内容： （1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

（3）开发有效的测试模型，能正确地验证正在开发的软件系统。

（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。

（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。

（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

扩展资料： 测试计划的作用： 测试计划通常分内部作用和外部作用，内部作用有以下3种： （1）作为测试计划的结果，让相关人员和开发人员来评审。

（2）存储计划执行的细节，让测试人员进行同行评审。

（3）存储计划进度表、测试环境等更多的信息。

测试计划的外部作用是为顾客提供一种信心，通常向顾客交代有关测试过程、人员的技能、资源、使用的工具等信息。

参考资料来源：搜狗百科-测试计划

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

问题三：变更的控制 　　测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。

在这种情况下，测试计划中强调对变更的控制显得尤为重要。

　　变更来源于以下几个方面 　　1． 项目计划的变更 　　2． 需求的变更 　　3． 测试产品版本的变更 　　4． 测试资源的变更 　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。

要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。

　　对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。

项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。

在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。

由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。

调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。

其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。

　　第二：项目进行过程中最不可避免的就是需求的变更。

那么，测试计划中就不能进行控制和约束的吗？答案是未必。

当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。

许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。

在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。

值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。

　　对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。

众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。

合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。

例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。

测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。

　　最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。

没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。

为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。

规避风险的办法可能有： 　　一，项目组的需求和实施人员参与系统测试； 　　二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员； 　　三，组织客户方进行确认测试或发布β版本。

　　尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。

一份计划投入再多的时间去做也不能保证按照这份计划进行实施。

好的测试计划是成功的一半，另一半是对测试计划的执行。

对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。

另外，计划也是“动态的”！不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标――保证项目最终产品的质量！