软件测试计划

1、软件测试计划1总论1）项目背景本次的被测项目，是一个基于B/S结构的Web博客系统。该系统可以实现用户注册，以及好友的搜索增添，基本的文章发布，照片上传等功能。用户可选择关注的好友还可以设置博客访问权限：公开、好友可见，仅自己可见。2）编写目的测试Web博客系统中的各个功能模块是否满足用户要求，并测试是否存bug。预期达到能够使系统进行快速的改进和系统的提高。为了在软件投入生产性运行之前，尽可能多地发现软件的错误。3）系统模块图4）参考资料软件测试技术（本学期的课本）清华大学出版社2. 测试策略1）总体策略软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一级错误（大于等于1）、二级

2、错误（大于等于2）暂停测试返回开发。软件系统经过单元、集成、确认、系统、安装、验收测试，分别达到单元、集成、确认、系统、安装、验收测试停止标准。软件系统通过验收测试，并已得出验收测试结论。软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据2）测试范围1.响应时间我把"响应时间"的概念确定为“对请求作出响应所需要的时间”，把响应时间作'为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。2. 并发用户数我把“并发用

3、户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数”前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（

4、不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。3. 吞吐量我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：（1）用来协助设计性能测试场景

5、，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。(2)用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。4. 性能计数器性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOW来说使用内存数、CPU使用率、进程时间等都是常见的计数器。对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使

6、用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。5. 思考时间我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HPLoadRuner和IBMRationalPerformaneeTester的方式

7、就完全不同。3)风险分析存在风险：由于测试组成员之前都没有过软件测试的经验，只有一些基础的理论知识。所以测试准备做得不是很充分。可能会有部分测试用时过长，或者某个人的测试工作不能按时完成。会造成对整体时间以及测试进度的影响。风险处理：必要的简化测试内容，尽量简化的达到测试目的。完成任务的人员给予尚未解决问题的组员以帮助，尽量短时间完成各自的任务。3. 测试方法1)里程碑技术因为测试项目是Web程序，所以我们更加注重程序的集成测试，以及对系统进行抗压测试。制定负载测试计划1 分析应用程序2 确定测试目标3 计划怎样执行quicktestprofessional2) 测试用例设计主要是进行用户试用

8、来进行用例设计。3) 测试实施过程用户层：主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的性。主要包括：用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。用户界面测试:在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。可维护性测试:可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来影响。例如：对支持远程维护系统的功

9、能或工具的测试。安全性测试:这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统;核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统;应用层：针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。系统性能测试：针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源

10、争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。系统可靠性、稳定性测试：一定负荷的长期使用环境下，系统可靠性、稳定性。系统兼容性测试：系统中软件与各种硬件设备兼容性，与兼容性、与支撑软件的兼容性。系统测试：组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。系统安装升级测试：安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安

11、装手册、安装脚本等也需要关注。4. 测试组织1）测试团队结构测试组织：杨国梁测试人员：闫坚，何鹏飞报告攥写：李永俊2）功能划分工作量（单位：人时）测试任务名称总工作量（人时）测试数据1准备测试环境/数据1执行测试，填写测试数据1整理测试数据，编写测试报告15. 资源需求1)培训需求本次测试运用黑盒测试方法，对拼车系统进行测试。首先，进行对功能模块进行划分，明确功能测试的人员负责情况。其次对各个模块进行测试。黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下

12、，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。黑盒测试着力于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2)硬件需求本次测试用的电脑，都是Win7系统，内存2G,硬盘

13、320G不等。3) 软件需求测试工作所必须的软件，以及老师拷贝给的软件。4) 办公室空间需求本次的测试实验，我们用到四台电脑，在宿舍进行。5) 相关信息保存位置本次试验随时生成测试文档，以word文档的形式保存。6. 时间进度安排1. 根据工作内容和项目任务对包括测试设计的工作量、测试执行和测试总结的工作量，以人月或人日计，并详细注释测试设计、测试执行和测试总结工作所占的比重。软件测试工作量应为开发工作量的30%-40%为宜。工作阶段所需工作曰占项目的比例测试规划阶段115%测试设计阶段115%测试实施阶段120%测试执行阶段120%测试总结阶段115%2. 本次测试实验的总时间为五天。我们具体的时间安排以及进度分配如下：项目里程碑开始时间结束时间输出要求/备注测试规划日14时日21时初步测试计划书测试设计7.3日8时日12时测试计划书测试设计实施日14时日12时测试用例测试执行日14时日21时测试结果测试总结日8时日12时测试报告书7.附录：项目任务以下是一些与测试有关的任务：制定测试计划 确定测试需求 评估风险 制