软件测试规范.docx_第1页
软件测试规范.docx_第2页
软件测试规范.docx_第3页
软件测试规范.docx_第4页
软件测试规范.docx_第5页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试规范软件测试,通过检查,发现软件系统的缺陷。它的目的是验证确保系统按照设计的功能完成,并且在软件和特定硬件集成的环境下,各个模块部分能一起良好的协作运行。 软件测试内容,包括各个模块的功能测试,也称为单元测试。各个模块完成功能测试的基础上,对模块间做集成联调测试,验证子系统间以及模块间的接口调用是否有效、数据流是否正确、业务功能是否完全等。 1 软件测试的流程软件测试贯穿软件生命周期的整个过程。包括以下几个过程: 制定配置管理计划 由测试组长与编译管理员一起制定 制定测试计划 由测试组长制定 需求审查 测试组长 / 部分测试人员参加 静态测试 设计审查 测试组长 / 部分测试人员参加 静态测试 测试设计 根据模板设计测试方案。测试组 成员 测试开发 根据方案开发必要的测试程序 测试执行 动态测试。测试组成员结果评估 测试报告。测试组长发布 内部测试结束的里程碑工程支持 由原测试组部分成员负责1.1 测试计划测试计划通常在总体设计完成后,由测试leader负责制定。测试计划中包括总体的测试需求分析、测试因素考虑、确定必须的测试类型、测试环境、工作分工、日程安排、阶段目标(bug数)、风险及规避办法考虑。测试组成员将按照测试计划执行有关的测试任务,此计划作为测试team对项目组的承诺,应同时发送项目组全体。测试leader需要及时跟踪和督促测试计划的执行,并根据实际情况,对计划进行变更。2 测试类型2.1 单元测试单元测试是对最小开发单元的测试,如java的类。单元测试重点是测试程序的内部处理逻辑,主要使用白盒测试方法,通常由开发人员负责。单元测试结束后,开发人员将程序check到cvs的rm分支,由版本控制工程师做build。2.2 集成测试 集成测试是将系统的各个模块组装在一起,确认功能是否正确实现,验证是否满足需求。集成测试由独立测试组织ITO负责,测试过程中发现的问题入QCS 系统进行跟踪。集成测试需要测试的范围包括:P 以功能模块为最小单元,确认每个功能模块是否正确实现需求和设计P 对模块进行组装,确认组装模块的接口功能是否正确P 对整个系统进行集成,以完整的业务流为主线,确认系统的业务功能是否正确实现2.3 回归测试回归测试是对某些已经测试过的测试集合重新测试。这些测试集合包括因软件变更(如fix bug、新增功能、系统优化)引起的数据流程发生变化,控制逻辑发生变化,接口发生变化,对变化所对应的测试集合,需要进行回归测试,以确认变化后的功能是否正确。由于软件变化可能造成有关联关系的未修改程序不能正常工作。因此在做回归测试的时候,除了测试直接变更的程序正确性外,必须找出有相关关系的程序,按照数据流、业务流的方式进行回归测试,防止缺陷逃逸。在以下请情况下,需要进行回归测试。P 当软件发生变更(如fix bug、新增功能、系统优化)P 当系统环境发生变更(如操作系统版本、数据库版本、测试环境、软件配置信息)P 目标程序被重新build回归测试在集成测试中进行。2.4 性能/压力测试 性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。通常性能测试和压力测试会合在一起进行。性能测试的目的为:目的要解答的问题度量最终用户响应时间多长时间可以完成业务流程确定可选择的硬件配置哪种配置可以得到最佳性能监控稳定性多大压力,多长时间内,系统可以稳定工作查找硬件、软件的改良方向如何改良有助于提升性能和稳定性评估新产品你将选择哪种硬件或软件度量系统吞吐量多大的负载压力可以造成系统性能的下降确定瓶颈哪些环节响应时间最慢2.5 接口测试在模块组装测试中,很多问题出现在接口部分。单个模块的功能实现了,但组装在一起,就无法正常工作。接口测试要包括两部分的测试:P 根据设计文档,构造测试数据,验证接口是否正确P 将接口关联的模块组装在一起进行连调测试。接口测试可以同时检查设计文档的正确性。2.6 确认测试 产品release前,需要对所有的Feature进行确认,未解决问题中没有1、2级的问题遗留,如有遗留的需求或1、2级问题,需要经过开发测试经理的授权。release前需要经过确认测试。确认测试方案在测试case设计时完成。有时也会放到测试中后期完成。确认测试以Feature为依据,是针对系统基本功能的流程测试。release测试还包括客户文档的测试,保证客户文档与产品一致。确认测试环节是产品从研发到现场的最后一个关卡,在这个阶段发现的任何微小问题都不能错过。确认测试重点在以下几个方面:P release包应该是由BM从cvs库中重新打包出来的。保证发布版本与cvs中源代码一致。P 测试环境是“干净”的。不受以往测试环境的影响P 根据安装使用手册,在全新环境中进行release包的安装、初始化、配置测试。验证手册与软件是否一致,安装包是否完整正确。P 对根据Fature编写的确认测试方案进行测试,验证feature是否正确实现。P 对QCS系统中未确认的bug进行回归测试2.7 系统测试系统测试是将软件系统与硬件环境、网络环境等集成在一起进行的测试。系统测试通常在产品发布后的实际运行环境中进行。系统测试要确认的是软件适应性问题,在内部测试环境运行正常的系统,一个实际运行系统中,由于软、硬件环境、网络环境、对外接口的设备不同,可能出现软件无法正常工作的问题,这种情况下,不能就简单的确定是软件问题。有可能是外部接口不符合标准

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论