非度测试流程规范(初稿)_第1页
非度测试流程规范(初稿)_第2页
非度测试流程规范(初稿)_第3页
非度测试流程规范(初稿)_第4页
非度测试流程规范(初稿)_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

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

文档简介

1、合肥非度信息技术有限公司(Friendone Co.Ltd) 测试文档非度测试流程规范作者时间摘要王云峰2010-12-20初稿1 文档目的阐述公司的测试流程,包括工作流、测试基线、测试控制、缺陷跟踪和测试报告。2 文档对象所有测试人员、相关开发人员和管理人员3 文档背景3.1 原型化软件开发模型。3.2 快速小型化项目开发。4 文档参考非度项目流程图,见附一5 测试流程5.1 测试进入和测试退出标准5.1.1 进入标准:项目启动后,项目经理指定具体的测试人员,即标志测试进入5.1.2 退出标准:操作手册验收完成5.2 流程图5.3 流程图说明5.3.1 测试进入和测试计划。接到测试

2、通知,测试进入。学习项目需求,根据项目规划,制定测试计划,测试策略。测试计划包括测试进度、内容和控制点,测试策略包括各测试项:单元测试,功能测试,系统测试,性能测试,UI测试,压力测试等。(应由专职的测试人员完成)5.3.2 编写系统测试用例。取得概要设计之后,设计系统测试用例。系统测试用例用来验证系统在所支持的运行环境中的各种功能指标是否实现,强调产品的整体性和兼容性。用例设计根据具体的测试策略进行设计(应由专职的测试人员完成)5.3.3 测试计划与测试用例评审。在以上两步完成的基础上,对其进行评审。评审人员包括项目经理,所有参与测试人员,最好包括一名技术领导小组成员。此处归档测试计划测试策

3、略和系统测试用例5.3.4 模块分析与功能测试用例编写。取得开发人员的详细设计文档,测试人员进行模块分析,并设计功能测试用例。功能测试用例用来遍历一个或者几个子功能项的所有功能点(也可能包含部分业务流)。即黑盒测试的最小功能单元验证。用例设计一般采用等价类和边界值。(可复用开发人员以测试的角色进行用例设计,设计时遵守测试用例设计规范)5.3.5 功能测试。在开发人员编码进行期间,同步执行功能测试。发现缺陷进入缺陷跟踪流程。此处注意,任何缺陷,在修改前都应填写Bug单,以获得产品质量的基础数据。(此处的测试需要一定的测试理论和测试方法作为支撑,应由测试人员完成;避免开发人员自我测试,最其次,开发

4、人员要交互测试)5.3.6 系统测试。在开发人员完成(一般应完成单元测试)后,测试人员取得完整的测试产品,根据先前审定的系统测试用例进行测试,发现缺陷进入缺陷跟踪流程。(此处可复用人事财务等各职位人员依据测试用例进行测试,注意:要严格按照测试用例执行测试,包括测试环境,测试步骤,尤其是测试预期)5.3.7 回归测试。同步第5和6项,执行回归测试。回归测试有两个任务:a.旧的缺陷是否修改,b.是否引发新的缺陷。(应有专职测试人员完成)5.3.8 测试报告。在执行完毕功能测试、系统测试和回归测试之后,对测试用例执行的结果和发现的产品缺陷进行统计分析,形成对当前产品的完整测试报告,并提交项目经理,取

5、得修改意见。(可由测试人员,项目经理或其它管理人员完成)5.3.9 操作手册。编写操作手册时,应注意用户的语言习惯和阅读习惯,避免使用过多的专业术语等。必要时可同步完成用户的培训文档。5.3.10 验收和测试退出。将编写好的测试报告和操作手册提交项目经理验收。验收通过,测试退出。6 测试分类及工作流6.1 静态测试6.1.1 文档审查6.1.1.1 检查产品说明书是否符合用户的语言习惯,是否存在错误6.1.1.2 检查部署配置文档是否存在错误6.1.1.3 检查培训文档是否存在错误6.1.2 代码走读待定6.2 动态测试6.2.1 单元测试待定。6.2.2 模块功能测试指对一个或几个最小功能项

6、(卡片)的测试6.2.3 系统测试系统集成后,为检验系统功能和整体运行状态而进行的测试。6.2.4 回归测试回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。一般来说,凡是进行过代码改动的地方都应该进行回归测试。6.2.5 性能测试6.2.6 压力测试6.2.7 负载测试6.2.8 安全性测试7 测试基线7.1 需求文档和系统设计,产生于项目初期,由技术领导小组完成。从测试角度,作为测试计划和测试策略的制定依据。7.2 概要设计和数据库设计,产生于立项之后,由技术领导小组完成。从测试角度,作为系统测试用例的设计依据。7.3 详细设计,产生于项目启动之后,有开发人员完成。从测试角度

7、,作为模块功能的测试分析和测试用例设计依据。注意:由于中小型项目的快速开发特性,和需要及时响应用户的需求变更,测试基线可能会经常有小部分或者偶尔有大部分的变更,而这些变更需要以基线标准的方式体现在测试过程中。8 测试控制8.1 需求控制需求控制点为需求文档需求变更控制指的是一旦需求文档发生变更,那么就要体现在整个测试流程中,包括计划,策略,用例等。8.2 进度控制8.2.1 确保尽早开始测试。早发现问题,早解决,可以有效地提高测试质量和产品质量。8.2.2 2/8原则。20%的模块集中80%的缺陷,测试过程中,一定做好测试分析,把握测试重点。9 缺陷跟踪缺陷流程按照缺陷流程图执行,注意以下事项:9.1 确保缺陷单和用例的对应,每一个缺陷要对应一个用例。9.2 一般确保缺陷可以重现9.3 确保缺陷单的关闭由测试人员执行9.4 对返回给测试人员的,标明是重复性的缺陷,测试人员在关闭以前,一定要确认重复缺陷单的编号, 并注明在关闭原因中。表明不是缺陷的,也要说明提交和关闭的原因。9.5 缺陷跟踪图10

温馨提示

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

最新文档

评论

0/150

提交评论