《关于测试工作流程及工具使用》由会员分享，可在线阅读，更多相关《关于测试工作流程及工具使用（12页珍藏版）》请在金锄头文库上搜索。
1、1前言本文档仅作用于公司内部人员使用参考，主要概括的是开发组与测试组的工作流程及工作衔接内容， 该文档由测试组人员内部制定，若有考虑不周之处请给出建议！编写此流程的主要目的是规范测试，提高开发组与测试组的工作效率，尽可能早地找到BUG，并保证得以修复。2测试流程简介2.1 测试工作总体流程立项测试计划、测试设计系统测试验收测试结项2.1.1 测试计划用例设计根据技术规范说明书设计测试计划、测试用例设计小组审核审核通过下一阶段审核不通过测试计划1、根据项目规范说明书确定机顶盒需求及潜在需求；2、定义机顶盒测试策略与方法；3、制定进入、退出测试准则；4、安排测试人员、测试时间、测试资源。测试设计1
2、、将测试计划整理的机顶盒需求细化分解为独立的功能点；2、为每个功能点设计测试用例；2.1.1.1 执行环境1、 项目立项后，项目组讨论项目实施过程后执行此流程；2、 前提是须有项目技术规范说明书，若客户未提供可从其它途径获取客户需求（如以前项目文档，样机获取等）；3、 与开发组的程序设计阶段同步，即开发设计项目实施时测试组同步进行测试设计，此过程为测试执行做准备工作；4、 立项项目经理把技术规范说明书共享给开发、测试组开发组人员解析说明书并设计代码、 测试组根据说明书作出测试计划、测试用例此阶段完成 （此过程中开发组和测试组进行功能规格沟通）。2.1.1.2 执行细则测试计划测试负责人根据项目
3、的需求，制定测试计划， 明确目标与测试任务以及测试人员的安排。测试计划分复杂文档型和简单实用型，综合我司目前情况，比较适用后者即简单实用型，引用 Microsoft Project 来计划分配项目任务，把项目细分为各个阶段、阶段再细分为各个任务，任务精确到具体时间、负责人，测试计划的主要要素包括：项目名称、任务名称、工期、开始时间、完成时间、资源名称等，如下图。测试用例依据已引用的用例模板，进行用例设计，挖掘用户潜在需求并结合到用例设计，与需求接口人沟通获取更直观的用户要求；若项目时间充足，测试用例可提供给开发人员，以便开发人员结合代码设计思路给出建议，使测试用例达到更高的可执行效果；测试用例
4、由测试组相应测试人员设计。2.1.2 系统测试上一阶段测试方案测试（用例）执行BUG 记录BUG版本提交开发人员提供新版本回归测试通过与否达到需求标准测试报告进入下一阶段1、对机顶盒作指标、性能测试；2、在软件接口处进行一系列仿真错误操作或者其他潜在的错误测试；3、记录测试结果作为历史记录或其它项目参考对象；4、尽可能多的模拟测试场景以覆盖所有功能点；1、结合开发组进度，使用TestDirector对BUG测试记录的版本进行控制针对上个版本的测试记录进行测试是否备注： 测试阶段分为单元测试、集成测试、系统测试、验收测试，单元测试由开发人员根据代码进行测试，集成测试即分模块单独测试（此阶段跳过）
5、，系统测试即集成后的版本测试（我司主要以此阶段作为测试的重心），验收测试即模拟用户进行使用测试（发布前的版本） 。结合公司环境，目前测试执行（测试执行区别于测试设计，测试设计主要是方法、过程的设计，测试执行是执行已设计好的方法及过程）包括系统测试、 回归测试、验收测试三大步骤。2.1.2.1 执行环境1、 执行前提是“测试计划用例设计”阶段完成；2、 此阶段开发组须集成可测版本提供给测试组执行测试，测试组先进行冒烟测试，冒烟测试不通过则须返回开发组再集成可测版本；（在此说明，冒烟测试即机顶盒常用功能都可正常执行操作，可理解为机顶盒的基本功能测试）3、 完成测试文档前期准备工作；2.1.2.2
6、执行细则测试人员针对独立的测试任务进行方案设计（可自定义）测试人员执行测试用例实时提交发现的BUG 至 TestDirector、开发人员实时访问刷新BUG 页面跟踪并修复BUG开发人员提供新版本测试人员回归测试检测已修复BUG 、 提交新 BUG重复蓝色标记步骤直至所有BUG 通过测试人员编写测试报告。2.1.3 验收测试设计验收测试方案验收测试测试人员对BUG进行记录提交 BUG 记录开发组提供修改后版本测试总结1、主要依据是客户提供的技术规范说明书；2、尽可能模拟用例的使用环境进行验收测试；N验收测试不通过符合技术规范说明书标准验收测试通过Y2.1.3.1 执行环境1、 执行前提是“系统
7、测试”阶段完成；2、 开发组提供最新版本，要求所有BUG 都已修复并经过测试人员确认完；3、 确认 TestDirector 上严重、比较严重、非常严重级别的BUG 都关闭（ Closed） ，Low 状态的大部分BUG 都关闭（ Closed） ；4、 得出前期测试报告结果。2.1.3.2 执行细则验收模拟用户使用环境及常惯执行测试记录验收过程及结果通过则制定测试总结报告并结束、不通过则进入下一步实时提交发现的BUG 至 TestDirector、开发人员实时访问刷新BUG 页面跟踪并修复BUG开发人员提供新版本测试人员回归测试检测已修复BUG、提交新BUG重复蓝色标记步骤直至所有BUG 通
8、过。下面简单的介绍两种通常情况下的项目流程，藉此说明一下开发与测试在整个项目中的协同工作， 其实测试活动并不是等到项目编码完成之后才开始，从一开始就是和开发并行进行的项目活动，以下两个流程图可以得到例证：2.2 项目简易流程1（单个项目运行）启动有无需求需求文档共享制定需求文档设计编码阶段完善功能点执行测试回归测试验收测试文档归类整理修复缺陷阶段结项发布开发测试设计测试用例1、跟踪 TD上的缺陷；1、执行测试用例 /功能点；2、提交缺陷到 TD，跟踪修复缺陷；1、根据验收标准执行测试；2、编写测试报告；对项目文档进行归档通过不通过项目基本流程2.3 项目简易流程2（多个项目运行）研发小组 1测
9、试方案设计编码文档软件开发修复 BUG测试计划及设计用例版本发布版本升级执行测试及提交BUG需求分析开发人员测试人员工程项目研发小组 2设计编码文档测试方案测试计划及设计用例软件开发修复 BUG执行测试及提交BUG版本发布版本升级需求分析测试人员开发人员修改 Bug修改 Bug项目管理项目分配计划确定功能点捕获产品样图撰写说明书市场校验发布质量评估技术认证文件归档质量评估技术认证3TestDirector工具使用说明TestDirector ( 简称 TD) 提供并集成了测试需求管理、测试计划和用例管理、测试日程控制、测试执行和缺陷跟踪等功能，目前公司主要引用的模块为缺陷跟踪，作为主导的BUG
10、管理工具。3.1 操作说明3.1.1 登陆打开 IE，在地址栏中输入http:/sxjs/TDBIN/default.htm，就可以打开TD 主页面（首次登陆会提示要求安装插件，点击“是”选择安装）安装插件后就可以打开TD 主页面，如下图：点击页面左上角TestDirector 进入：3.1.2 增加缺陷（ Bug）-程序员 |测试员注释：并不是只有测试人员才能提交BUG ，开发人员发现了问题一样可以提交，当然此处的提交并不是开发期的缺陷，而是项目已集成后的缺陷，开发人员提交的问题可作为今后其它项目的参考范例，便于整理公司产品的“综合症”。窗口介绍：在此我们工作过程中主要引用到的是缺陷管理模块
11、，在以上选项中选择即打开缺陷窗口，如上图，可选择下的更改密码进行用户密码修改操作。登记缺陷：3.1.3 修改缺陷（ Bug）状态测试发现BUG提交BUG 状态（New ）项目组长或QC 组长确认是否为BUGBug 状态更改为CLOSEBug 状态更改为Open开发人员修复Bug 后更改状态FixedBug 状态更改为CloseBug 状态更改为Reopen测试人员回归确认是否修复否是否是在栏，根据实际情况修改Bug 的状态， Bug 的状态有五种： New 、 Open、 Reopen 、Rejected、 Fixed、 Close。希望大家不会觉得以上的操作过于繁琐！3.2 TestDirector（TD）的优点1、TestDirector能让测试人员、开发人员通过一个中央数据仓库（服务器），在不同客户端就能互通测试信息。及时的获取到项目出现的问题，并修改缺陷或测试回归确认；2、TestDirector将测试过程流水作业，从提交缺陷中间缺陷修复过程缺陷关闭，整个过程都可以得到直观的了解。3、方便最后缺陷分析及归档，通过 TD 的导出功能可以直接导出为Excel 、word 文档形式；
