育才学习网1. 我需要写一个网站前后台的软件测试计划,要怎么写
软件压力测试计划实例 发布： 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小时内完成； 测试压力的估算结果： 软件测试计划编写的几点注意 发布： 2010-7-15 09:54 | 作者： 不详 | 来源： 领测国际采编 | 查看： 274次 | 进入软件测试论坛讨论 领测软件测试网 软件测试计划编写的几点注意 软件测试 软件测试是有组织的活动，软件测试之前必须做计划。
《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”
由此可见软件测试计划的重要性 做好软件的测试计划不是一件容易的事情，需要综合考虑各种影响测试的因素。为了做好软件测试计划，需要注意以下几个方面。
1.分别创建测试计划与测试详细规格、测试用例 编写软件测试计划要避免一种不良倾向是测试计划的“大而全”，无所不包，篇幅冗长，长篇大论，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。
2. 坚持“5W”规则，明确内容与过程 “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
为了使“5W”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。
3. 采用评审和更新机制，保证测试计划满足实际需求 测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
2. 加入一个测试经理对一个网站进行测试,都需要做什么
（一） 先说测试计划吧 一个好的测试计划是用来计划测试的，指导整个测试过程。
所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。作为一个测试计划来讲，核心的三个要素是时间，资源，范围。
（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。除以上提到的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去沟通，可惜一般没有这条件-_-）任何。
3. 软件测试的测试用例怎么写
● 测试用例编号
◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
◇ 约定：
系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX
● 测试项目
◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
◇ 约定：
系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话
集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口
单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)
● 测试标题
规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
● 重要级别
规则
高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
● 预置条件
规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
● 输入
规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
● 操作步骤
规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。
● 预期输出
规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等
4. 百度网页如何写测试用例
测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例编写准备
1
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2
根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。