‘壹’ 软件测试方案怎么写
测试目标，测试范围，测试内容，测试使用的方法（黑盒，白盒，自动化等等），时间人员进度安排。
‘贰’ 软件测试计划中的测试策略怎么写
软件测试策略的确定过程通常经历 确定测试需求 、确定测试策略三个阶段组成。
‘叁’ 如何书写软件测试计划书
1引言
1.1编写目的
本测试计划的具体编写目的，指出预期的读者范围。
1.2背景
说明：
a． 测试计划所从属的软件系统的名称；
b． 该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2计划
2.1软件说明
提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。
2.2测试内容
列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。
2.3测试1（标识符）
给出这项测试内容的参与单位及被测试的部位。
2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准备输入数据等）。
2.3.2条件
陈述本项测试工作对资源的要求，包括：
a． 设备所用到的设备类型、数量和预定使用时间；
b． 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c． 人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。
2.3.3测试资料
列出本项测试所需的资料，如：
a． 有关本项任务的文件；
b． 被测试程序及其所在的媒体；
c． 测试的输入和输出举例；
d． 有关控制此项测试的方法、过程的图表。
2.3.4测试培训
说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。
2.4测试2（标识符）
用与本测试计划2.3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。
3测试设计说明
3.1测试1（标识符）
说明对第一项测试内容的测试设计考虑。
3.1.1控制
说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。
3.1.2输入
说明本项测试中所使用的输入数据及选择这些输入数据的策略。
3.1.3输出
说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。
3.1.4过程
说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。
3.2测试2（标识符）
用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。
4评价准则
4.1范围
说明所选择的测试用例能够接查的范围及其局限性。
4.2数据整理
陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。
4.3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。
‘肆’ 怎么编写软件测试计划书
测试计划
测试概述:
测试背景:
测试手段:
手工测试
测试范围:
功能测试 界面测试 接口测试 容错测试 安全测试 性能测试 稳定性测试 恢复测试 配置测试 安装测试 文档测试 可用性测试
测试环境:
软件环境
操作系统
被测软件 其他软件
硬件配置
PC 配置：CPU
内存 ：1G
外部设备
测试策略:
一．功能测试
1．菜单点击相应标题菜单，验证其功能是否能实现
2．工具栏 点击相应工具栏，验证其功能是否实现
3．按钮
4．快捷键
5.下拉框
6．单选按钮
7. 复选按钮
8.切换按钮
9.编辑按钮
10.触发键：
11．链接：
二 .界面测试 点击相应按钮是否满足UI设计
1登陆界面
2总界面
3 输入界面
4处理界面
5输出界面
6提示界面
三. 容测测试 是否满足数据库设计要求
主键容错
非空容错
四、接口测试 点击相应的菜单 按钮 工具栏按钮 弹出相应的接口界面，验证其功能是否能正确实现 模块之间的调用 是否满足概要设计的要求
1.内部接口
2.业务流程测试
3.外部接口
五、安全测试
1.应用级安全测试
2.系统级安全测试 点击相应菜单，验证其功能是否实现
六．性能侧试
七．负载测试
八.稳定性测试
九 .恢复测试
十.配置测试
十一. 安装测试
十二.文档测试
软件需求 概要设计 测试计划 测试用例 技术文档的 质量通过评审 来保障
在线帮助
安装手册
使用手册
七.测试进度安排
工作内容 开始时间 结束时间 责任人 提交的结果 备注
编写测试计划
设计发短信测试用例
设计资费测试用例
搭建测试环境
集成测试 执行发短信测试用例
执行资费测试用例
集成测试分析报告
系统测试 性能测试
恢复测试
配置测试
系统测试分析报告
‘伍’ 软件测试计划需要遵循什么文档写
1、测试方案(主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用列表)，
2、测试执行策略(可以主要包括哪些可以先测试，哪些可以放在一起测试之类的)，
3、测试用例(主要根据测试用例列表，写出每一个用例的操作步骤和紧急程度，和预置结果)，
4、BUG描述报告(主要可以包括，测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息)，
5、整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)。
‘陆’ 如何写一份靠谱的软件测试计划
所谓计划就是用来指导执行的，那么想要执行到尾就要考虑执行计划的人。如果计划忽略了人的因素就是“拍脑袋”了。
大致总结软件测试计划要符合的内容如下：
1、需求方的高层质量目标
这个是最重要的，多数情况下就是客户和直接发起领导的高层意图，比如速度快、界面美观、高质量等定性的指标，能够指示质量关注重点。
2、公司运营管理的总体要求
比如配合项目/产品需要多长时间完成、成本多少等等，这个通常是限制，要在这个大的限制下做好质控，不能说为了达到90%的测试覆盖率，而让项目成本超标，那就不是测试的本来目的了。
3、设计、开发的要求
要了解开发人员的工作习惯、使用的工具/平台/构架，有些事情是开发工具解决不了的问题，不要硬生生通过“文字”反馈给开发人员，应该先有个沟通，在形成一定共识的基础上设计测试计划，对于设计或构架等难于解决的问题，也要有渠道反馈给管理层，以做风险应对，而不要针锋相对非逼着研发人员修改，最后可能会出现拖延、误修复等更严重的问题。
4、测试的要求
了解公司的质量管理要求、策略、制度、流程，更重要的是了解执行测试的人员的实际能力和经验。如果这份测试计划包括了定义的测试操作（也即是测试用例），那这部分是不能因人而异的，如果说测试计划是为了指导测试人员开发测试用例并指明测试工作安排的，则可以考虑根据执行人员的经验水平进行繁简处理调整，如果都是初级人员，则测试计划就要写得细一些；如果都是高级人员，则可以把测试计划的执行主体部分写的宽泛一些。
5、实施的要求
这里包括项目/产品的实施人员、运维人员、销售人员的意见，比如项目后期的运维方式、系统的版本控制、自动更新、授权许可机制等。这些虽然不是软件的主体目标，但是却与公司运营息息相关，所以也必须在测试策略中予以考虑。
总之，要做出“一份靠谱的软件测试计划”在最开始的几次，需要付出大量的精力，一但这些内容了解了，并记住“重视人的因素”之后，以后都能够做出“靠谱的测试计划”了。
‘柒’ 软件测试计划怎么写求助...
软件测试计划是软件测试员与产品开发小组交流意图的主要方式。
包括的内容有
对高级期望、何为软件缺陷，进行定义。
确定测试人员，在哪里测试，确定资源要求以及如何获得他们。确定团队间的责任。
确定哪些需要测试，哪些不需要测试。
定义测试阶段，确定本次测试有多少阶段，定义每个阶段的开始、退出规则。
定义测试策略，确定使用黑盒还是白盒测试，用手工还是使用工具，如果使用工具，是自行开发还是购买已有商用解决方案。
测试员的任务分配。
定义测试进度。
风险评估。
‘捌’ 软件测试计划怎么写要包含哪些内容
软件压力测试计划实例
发布:
2010-12-21
10:08
|
作者:
不详
|
来源:
领测测试网采编
|
查看:
257次
|
进入软件测试论坛讨论
领测软件测试网
软件压力测试计划实例
软件测试利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。首先介绍一下实例中软件的项目背景，该软件是一个典型的三层c/s架构的mis系统(客户端/应用服务器/数据库管)，中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的orb(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。压力测试的详细计划如下：压力测试计划1、测试计划名称河北省公安交通管理信息系统压力测试计划。2、测试内容2.1背景本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间运行测试软件来测试被测系统的可靠性，同时还要测试被测系统的响应时间。用户的实际使用环境：◇由两台ibm
xseries250
pc
server组成的microsoft
cluster;◇数据库管理系统采用oracle8.1.6;◇应用服务器程序和数据库管理系统同时运行在microsoft
cluster上。◇有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。2.2测试项应用服务器的压力测试;2.3不被测试的特性◇系统的客户端应用程序的内部功能;◇数据库中的数据量对程序性能的影响。3、测试计划3.1测试强度估算测试压力估算时采用如下原则：◇全年的业务量集中在8个月完成，每个月20个工作日，每个工作日8个小时;◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成;测试压力的估算结果：
‘玖’ 如何写软件测试计划
1 软件测试计划的编写
基础知识已经分享的差不多了，之后就是我们的收尾工作，今天给大家讲讲我们做测试过程中会用到的一个文档：《软件测试计划》
在我们软件测试工作阶段，一共分为五个阶段：计划、设计、执行、评估、验收。
可以看到在做软件测试工作的时候，最开始，就是要做好计划工作，也就是软件测试计划。
在软件测试计划里面应该包含哪些内容呢？
包括这些：
1）测试开始时间 &测试结束时间
2）测试的内容模块定位（包含哪些内容测试点）
3）测试的参与人员以及任务分工
4）输出文档的规定以及存放
5）采用的测试方法以及测试工具的申请。
其实就总结起来，就是大家看见过的5W原则：
When:什么时候开始做，什么时候结束测试，要在这段时间内做好一个规划与进度。
What：我们要做什么？要明确的罗列出来，好明确我们的测试方向和重点，并方便后期划分责任模块
Who：谁要参与这次项目的测试？具体负责哪个模块的功能测试？主要负责任务是？都是在这个里面进行明确的责任划分
How：如何测试，确定我们的测试方法：是白盒测试还是黑盒测试？我们要不要进行自动化测试要不要进行性能压力测试？要不要进行安全性测试，都需要在这个里面计划好。
Where：这个是说把文档放在哪里，就明确的包括了我们的输出文档有哪些：比如说测试用例？Bug列表？测试报告等等文档要存放的位置，作用就是规定输出文档以及输出文档的存放位置。
怎么样，这么一说，是不是觉得软件测试报告要很好理解了呢?
今天给大家分享了软件测试报告的编写！更多问题可以加群 333782754 小编每天都按时推送，关注我们打发你的琐碎时间。如果你有别的见解，也非常欢迎留言！
‘拾’ 怎样有效编写软件测试计划
先说说啥是软件测试计划；
所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、测试任务、谁执行任务和风险控制等。
测试计划目的是管理测试活动，强调“做什么”，具体体现是组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等。
综上所述，想要列出一份有效可执行的测试计划，需要知道软件的项目计划、开发计划、设计方案、里程碑节点、测试资源情况，再根据实际的项目要求来调整。