① 软件测试计划怎么写要包含哪些内容
软件压力测试计划实例
发布:
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.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尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。
③ 软件测试计划怎么写求助...
软件测试计划是软件测试员与产品开发小组交流意图的主要方式。
包括的内容有
对高级期望、何为软件缺陷，进行定义。
确定测试人员，在哪里测试，确定资源要求以及如何获得他们。确定团队间的责任。
确定哪些需要测试，哪些不需要测试。
定义测试阶段，确定本次测试有多少阶段，定义每个阶段的开始、退出规则。
定义测试策略，确定使用黑盒还是白盒测试，用手工还是使用工具，如果使用工具，是自行开发还是购买已有商用解决方案。
测试员的任务分配。
定义测试进度。
风险评估。
④ 软件测试计划怎么写
1．引言
1．1项目背景
1．2参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）
1．3测试术语
1．4有关项目人员组成以及联系方式（开发人员／版本控制人员／测试人员／软、硬、结构、营销人员等）
2．任务概述
2．1测试范围
2．2测试目标
2．3广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等
⑤ 如何写一份靠谱的软件测试计划
所谓计划就是用来指导执行的，那么想要执行到尾就要考虑执行计划的人。如果计划忽略了人的因素就是“拍脑袋”了。
大致总结软件测试计划要符合的内容如下：
1、需求方的高层质量目标
这个是最重要的，多数情况下就是客户和直接发起领导的高层意图，比如速度快、界面美观、高质量等定性的指标，能够指示质量关注重点。
2、公司运营管理的总体要求
比如配合项目/产品需要多长时间完成、成本多少等等，这个通常是限制，要在这个大的限制下做好质控，不能说为了达到90%的测试覆盖率，而让项目成本超标，那就不是测试的本来目的了。
3、设计、开发的要求
要了解开发人员的工作习惯、使用的工具/平台/构架，有些事情是开发工具解决不了的问题，不要硬生生通过“文字”反馈给开发人员，应该先有个沟通，在形成一定共识的基础上设计测试计划，对于设计或构架等难于解决的问题，也要有渠道反馈给管理层，以做风险应对，而不要针锋相对非逼着研发人员修改，最后可能会出现拖延、误修复等更严重的问题。
4、测试的要求
了解公司的质量管理要求、策略、制度、流程，更重要的是了解执行测试的人员的实际能力和经验。如果这份测试计划包括了定义的测试操作（也即是测试用例），那这部分是不能因人而异的，如果说测试计划是为了指导测试人员开发测试用例并指明测试工作安排的，则可以考虑根据执行人员的经验水平进行繁简处理调整，如果都是初级人员，则测试计划就要写得细一些；如果都是高级人员，则可以把测试计划的执行主体部分写的宽泛一些。
5、实施的要求
这里包括项目/产品的实施人员、运维人员、销售人员的意见，比如项目后期的运维方式、系统的版本控制、自动更新、授权许可机制等。这些虽然不是软件的主体目标，但是却与公司运营息息相关，所以也必须在测试策略中予以考虑。
总之，要做出“一份靠谱的软件测试计划”在最开始的几次，需要付出大量的精力，一但这些内容了解了，并记住“重视人的因素”之后，以后都能够做出“靠谱的测试计划”了。