『壹』 我需要写一个网站前后台的软件测试计划，要怎么写急！
软件压力测试计划实例 发布: 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。测试计划标识符
2。目录表
3。参考文献
4。词汇表
5。介绍
6。测试项
7。待测特征
8。不予测试的特征
9。方法
10。测试项通过/失败准则
11。挂起准则和恢复需求
12。测试交付物
13。测试任务
14。环境需求
15。职责
16。人员安排与培训需求
17。进度表
18。计划风险与应急措施
19。审批
『叁』 求电子商务系统的测试计划.....急
我也需要啊。
『肆』 iwebshop测试计划怎么写
商城名称：您的iWebShop商城的名字
商城logo：设置商城首页头部的logo图片
商城标题：站点的名称，也叫网站的标题，设置后将显示在位于浏览器左上角的标题栏位置。
商城关键字：iWebShop站点的关键字，便于引擎查找，当输入多个时，需要用逗，地或者逗|地分隔。例如：shop|iweb。
商城描述：iWebShop站点的重点描述信息，便于引擎查找，让网站用户清楚地了解网站概要。
公司名称：iWebShop商城所属的公司名字。
版权信息：iWebShop站点版权信息。
ICP备案号：信息产业部所颁发的备案信息。
流量统计代码：iWebShop网站管理员可以将流量统计代码添加到此处的文本输入框中。
是否关闭注册：（下拉列表框）选择开启或关闭，关闭注册后，此时任何人都无法进行注册。
是否关闭注册：（文本输入框）填写当选择关闭会员注册时，访客所看到的提示性信息。
注册同意条款：用户注册时所需要同意的服务条款。
支持html代码格式:换行；加粗。
『伍』 加入一个测试经理对一个网站进行测试，都需要做什么做测试计划、用例、总结等等都有什么需要注意的
（一） 先说测试计划吧
一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。
作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。
除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。
要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：
a. 上面提到的三要素不能少
b. 测试策略一定要交待清楚，就是大概怎么测试
c. 需要其他人员（部门）协调的，要交待清楚
d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数
e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚
f. 测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check
g. 一定要有风险控制，要不然计划缺乏可执行性
h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审
i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的
（二） 再说测试用例
和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。
下面我就个人体会谈谈做好测试用例的关键。
首先，在做用例之前，要做两件事情。
第一， 透彻了解程序（需求和架构）。
第二， 做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）
一般来说，设计一个比较实用的测试用例，注意如下几个方面：
a. 选用好的用例管理工具（这个很重要，千万不要用word，excel）
b. 用例一定要及时更新（补充新的想法，删除过时的需求）
c. 做好用例分级
d. 做好用例评审，写用例之前可以征询相关人员的意见
e. 可以考虑结对编写，这个是不错的主意
f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
g. 注意把握适当的颗粒度
OK，以上是我个人总结的一些心得，希望对您有些帮助.
-----------------------------------------------------------------------------------------
我不知道lz说的做好测试计划中的“做好”两字具体指的是什么
对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已
所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用
这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）
测试计划中最重要的内容包括：进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）
写好测试计划的关键在于：
1 充分了解你的团队的整体实力和团队中每个成员的特点
2 充分理解为当前软件制订的整个研发活动过程
带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。
写好测试方案的关键在于：
1 有一个合理的测试计划
2 熟悉相关业务
3 深入体会用户的实际需求
这个不想多解释了，不难理解。
至于测试用例
看到上面不少朋友认为关键在于理解用户需求
其实理解用户实际需求是一切的根本
并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切
当然，如果有一份好的需求和设计文档的话，什么事情都解决了。 可是现实往往是不存在这样的文档的。
所以我的看法是：
1 对业务理解的深入程度
2 经验
3 有自己的文档
前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。
『陆』 求软件测试计划的详细案例
测试计划
测试概述:
测试背景:
测试手段:
手工测试
测试范围:
功能测试 界面测试 接口测试 容错测试 安全测试 性能测试 稳定性测试 恢复测试 配置测试 安装测试 文档测试 可用性测试
测试环境:
软件环境
操作系统
被测软件 其他软件
硬件配置
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.系统级安全测试 点击相应菜单，验证其功能是否实现
六．性能侧试
七．负载测试
八.稳定性测试
九 .恢复测试
十.配置测试
十一. 安装测试
十二.文档测试
软件需求 概要设计 测试计划 测试用例 技术文档的 质量通过评审 来保障
在线帮助
安装手册
使用手册
七.测试进度安排
工作内容 开始时间 结束时间 责任人 提交的结果 备注
编写测试计划
设计发短信测试用例
设计资费测试用例
搭建测试环境
集成测试 执行发短信测试用例
执行资费测试用例
集成测试分析报告
系统测试 性能测试
恢复测试
配置测试
系统测试分析报告