测试计划软件测试的测试计划是如何计算测试时间

写测试计划的步骤是什么

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过程

测试计划怎么评审

我支持模板害死人的说，单不支持模板害死人的做法。

模板是长期实践，总结出来的一套解决问题的方法，有的你是实用的有的未必你就能用的到，一个项目计划要从特定项目的特点出发思考如何一步步的开展测试工作；测试计划不是一成不变的，在测试计划的执行过程中会随着外界条件或者某些因素的掺杂而做出相应的变动和调节！这个是必然的。

如果说做了一份计划到项目测试完毕了都没有动过或者很好的按照计划中的各个指标，策略，资源等测试完成了，这说明两个问题：第一你的计划就是一张废纸，第二你的计划做的太好了，对整个项目的把控，奉献预测和预防测试都做到极致了注重项目质量要从领导开始！

软件测试计划的简介

软件 项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。

对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。

它非常有用但是测试项目组之外的人却很少去读它。

软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。

在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。

测试计划因此也成为测试工作的赖于展开的基础。

《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。

它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。

”软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。

借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

如何编写测试计划，如何评估测试时间和人员安排。

首先你要明白你是白盒测试还是黑盒测试，然后根据环境，配置相应的测试环境，准备相应的测试数据，制定测试流程。

评估测试时间要用测试工具最好，搞个压力测试，看看瓶颈在哪里。

如何写好测试计划

如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。

以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。

因为我们可以从软件的开发进度中获得开始时间，但很难确定测试的结束的时间。

下面有一个预估的办法，是大多数测试工程师的经验所得，我们拿到评审后的需求分析可以用下面的方法预估。

1、计算需求分析的页数，得出测试用例的页数，需求分许页数：测试用例页数 ≈ 1：1 2、由测试用例页数计算编写系统测试用例时间：编写系统测试用例时间 ≈ 系统测试用例页数×1小时 3、计算执行测试用例时间：编写测试用例用时：执行系统测试用时 ≈ 1：2 4、计算回归测试包含的时间：系统测试用时：回归测试用时≈ 2：1 以上的方法可能根据测试人员对项目熟悉程度和测试经验的不同而有所差别，大家可以根据自己的经验做出调整。

计算出测试用例、执行测试和回归测试的时间后，根据软件项目的开发进度就可以编写出一个软件测试的时间表了。

不过从目前国内软件公司的现状来说，测试时间一般都不够，所以我们只能延长我们的工作时间，提高我们的工作效率。

程序员说他们处于最底层，用户说要改什么，他们就要实现什么，没人关心他们的工作难度和工作时间。

（发点牢骚，大家就当没看见，呵呵）

软件测试的测试计划是如何计算测试时间

估算测试时间一般要包含几种任务的时间来综合考虑。

首先你要根据被测模块的大小，估计你设计test case的工作量。

在实际跑case的阶段，一般执行每条测试的时间都是相对固定的一个量，可以跑几条难度一般的case来取平均值来获得这个时间。

然后每条case所需时间乘以你的case条数就能获得你在测试用例执行阶段所需要的时间，当然你可以加上一些buffer用于报bug。

测试设计和测试执行的时间得出来后，基本上90%以上的测试时间就出来了。

然后还计划一些时间来进行测试分析和报告总结，这个可以依据项目情况看，可多可少，一般是1到2天。

以上全部加起来，就是测试计划中的测试时间啦。

当然由于测试用例的可重用性，所以一般在第二轮执行用例的时候，会减去你设计测试用例的时间，但其他都不变。