1.如何写好测试计划

如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。因为我们可以从软件的开发进度中获得开始时间，但很难确定测试的结束的时间。下面有一个预估的办法，是大多数测试工程师的经验所得，我们拿到评审后的需求分析可以用下面的方法预估。

1、计算需求分析的页数，得出测试用例的页数，需求分许页数：测试用例页数 ≈ 1:1

2、由测试用例页数计算编写系统测试用例时间：编写系统测试用例时间 ≈ 系统测试用例页数*1小时

3、计算执行测试用例时间：编写测试用例用时：执行系统测试用时 ≈ 1:2

4、计算回归测试包含的时间：系统测试用时：回归测试用时≈ 2:1

以上的方法可能根据测试人员对项目熟悉程度和测试经验的不同而有所差别，大家可以根据自己的经验做出调整。计算出测试用例、执行测试和回归测试的时间后，根据软件项目的开发进度就可以编写出一个软件测试的时间表了。

不过从目前国内软件公司的现状来说，测试时间一般都不够，所以我们只能延长我们的工作时间，提高我们的工作效率。程序员说他们处于最底层，用户说要改什么，他们就要实现什么，没人关心他们的工作难度和工作时间。（发点牢骚，大家就当没看见，呵呵）

2.如何写软件测试计划

1、软件测试计划是引导控制测试工作按照计划执行的指南针。软件测试计划应该包含的元素有：测试所需资源、测试策略、测试风险预测等

2、前言

1.需要写明本文当编写的目的，是给那些人看的，能起到怎样的作用。

2.本文档中出现的专业术语需要有个解释，非软件测试的人员能看懂。

3.参考资料，也是我们编写测试计划的依据，说明你这个测试计划不是凭空而来。

4.测试模块的优先级别，可以从这里看出系统功能模块的重要性。

3、资源需求

1.需要写明测试所需资源，包括：软件资源、硬件资源、人力资源，有了这些具备的条件，测试工作才能展开。

4、测试详述

1.确定测试范围，超出这个范围的不进行测试，如果不规定测试范围，那么会造成测试范围蔓延，会导致测试时间不够、测试质量下滑、引起交付时间延后等问题。

2.规定完成测试的指标，满足测试完成的必须达到这些指标，测试才算结束。

3.根据目前所了解的信息，仔细预测测试中可能出现的风险，提前预测出来以便做好应对。

4.测试周期约束，每一个测试周期的时间起始点都要写明，以便测试进度如期进行。

5、测试策略

1.纵观整个软件系统，预测需要使用到的测试策略

2.整个系统中需要用到的测试类型需要标注出来，用于指导测试设计用例

3.本次设计的系统测试是否需要自动化测试、性能测试还是只需要功能测试，这里需要提前预测。

6、测试完成后需要提交哪些文档（部分文档会进行评审后封存到SVN库中）。

7、测试完成后要达到的质量目标。

8、测试计划审核后，需要移交相关部门人员审核，经过他们审核签字后，测试计划正式生效，部门的测试工作就按照这个计划执行。

3.如何写测试计划

我3天前就看到您的提问了，但是写到一半就都删掉了。主要是你的这个问题有点大，不好回答，又担心回答了对您没有什么帮助。

……今天还是简要的说下我的体会吧。

测试计划可以是一本书那么多，也可以是几张纸那么少。起决定性作用的是各个公司的实际情况不同。不过一份测试计划应该包括以下内容：

1项目简介

2测试环境

3测试策略

4风险分析

5人员安排

6资源分配

……

不过说实话，目前的软件测试行业，或者说整个中国IT业，也有很多都是“变化比计划快、准”，很少有严格按照计划来的，更有甚者计划都是后补。

这个我们个人之力是没有办法的，只能自己努力，等咱也到制定计划的角色上之后，希望我们能用好计划就行了。

至于每一项里面都要写什么，还是你自己去百度下吧，这里就不给你Copy了。

我的团队【测试我知道】，可以进来，有问题大家一起分享。

就这些吧，祝早成！

4.测试计划如何编写

首先，去网上找一个测试计划的模版。

切记，只找一个先，不要被百度出来的大大小小的给弄花了眼，反而不知道用什么。然后，把这个模版打开先看一下，根据自己公司的要求（最好是有公司以前的测试计划），删减下章节，留下章节名和常用图表。

这个时候再去百度上看个四五个别人写的，看看会不会突然间有灵感，需要增加补充哪些东西。将章节名留下。

最后，根据实际的计划完成一分好的测试计划。我的回答只提供给肯自己再动点脑筋的人，所谓授之与鱼，不如授之与渔。

不过仍然希望能我说的帮得上你。

5.软件测试计划怎么写

呵呵！这是测试计划模版 请拿Wo XXX公司 文档编号 项目版本 密级项目名称： 共14页XXX项目测试计划拟制： 日期： yyyy/mm/dd审核： 日期： yyyy/mm/dd批准： 日期： yyyy/mm/dd修订记录日期 修订版本 描述 作者yyyy/mm/dd XX版本 初稿完成 XXX目 录1目标 62 概述 62.1 项目背景 62.2 范围 63 组织形式 64 测试对象 85 需求跟踪 96 测试通过/失败标准 97 测试挂起标准及恢复条件 98 测试任务安排 108.1 任务1 108.1.1方法和标准： 108.1.2 输入/输出： 108.1.3 时间安排： 108.1.4 资源 ： 108.1.5 风险和假设： 108.1.6 角色和职责： 108.2 任务2 118.2.1 方法和标准： 118.2.2 输入/输出： 118.2.3 时间安排： 118.2.4 资源 ： 118.2.5 风险和假设： 118.2.6 角色和职责： 118.3 任务3 118.3.1 方法和标准： 118.3.2 输入/输出： 118.3.3 时间安排： 118.3.4 资源 ： 128.3.5 风险和假设： 128.3.6 角色和职责： 128.4 任务4 128.4.1 方法和标准： 128.4.2 输入/输出： 128.4.3 时间安排： 128.4.4 资源 ： 128.4.5 风险和假设： 128.4.6 角色和职责： 129 应交付的测试工作产品 1310 工作量估计 1311 资源的分配 1312 附录 14XXX项目系统测试计划关键词：摘 要：缩略语清单：参考资料清单：名称 作者 编号 发布日期 出版单位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 任务18.1.1方法和标准： 指明执行该任务时，应采用的方法以及所应遵循的标准8.1.2 输入/输出： 给出该任务所必需的输入及输出8.1.3 时间安排： 给出任务的起。

6.写测试计划的步骤是什么

1、确定工程

收集下列信息

文档 已创建（是/否） 版本/日期 需求详述 功能详述 项目计划 设计详述 原型 用户手册 定义新的工程，Adminà New Project。

确定软件的结构，用Assetsà Software Structure选项定义软件结构。

2、定义测试策略

测试策略项 例子 测试阶段 系统测试 测试类型 功能测试 测试技术 75%用SQA Suite自动测试，25%手工测试 完成标准 95%测试用例通过并且最高级缺陷全部解决 特殊考虑 测试必须在上午进行

3、分解软件，写测试需求

分析各种信息

反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行：

1、确定软件提供的主要商业任务

2、对每个商业任务，确定完成该任务所要进行的交易。

3、确定从数据库信息引出的计算结果。

4、对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

5、确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率

6、确定应用需要处理的数据量。

7、确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

8、确定其他与应用软件没有直接关系的商业交易。包括：

管理功能，如启动和推出程序

配置功能，如设置打印机

操作员的爱好，如字体、颜色

应用功能，如访问email或者显示时间和日期。

9、确定安装过程，包括定置从哪安装、定制安装、升级安装。

10、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。

把需求组织成层次图

4、估计测试工作量

∑（每个测试的时间*每个需求的测试的数目*测试需求的的数目）

（测试设计、开发、….）

5、确定资源

人力资源

职位 姓名 特殊责任/说明 测试经理 测试工程师

设计/开发（可以多人） 测试工程师

测试执行（可以多人） 测试系统管理员

系统资源

系统 名称/类型 数据库服务器 网络/子网

服务器名称

数据库名称

SQA 测试存储库 网络/子网

服务器名称

客户测试机 包括专门的配置需求 列表 测试开发的PC机 列表

6、创建工程调度表

任务

相关工作量（天）

整个SQA过程

7.测试策略怎么写

测试策略

Test Strategy;test policy;testing strategy

例句：

文章主要讨论了编码完成后的方法的测试和类的测试，并分别给出了测试策略。

This paper discusses both the method testing and the class testing after finishing the coding.

而后，测试策略也将必须遵循测试管理框架。

Following this, the testing strategy will also have to follow the test management framework.

有了决策表，我们就可以根据测试策略轻松的添加和删除条件。

With a decision table, it is easy to add and remove conditions, depending on the test strategy.