目的:确保软件测试技术能项目的生命周期内得到顺利实施,并产生预期的效果。
一、测试管理大纲
需求分析
确定软件功能
系统设计
确认测试大纲
项目进度
测试计划
开发阶段
根据模块实现功能性测试
2
、版本的管理
模块开发初期,两周提交一次版本;
模块开发中期:一周提交一次版本;
模块开发后期:
2
到
3
天提交一次版本;
提交版本时必须提供本次版本中实现的需求,复杂操作必须提供简单说明,存在约束的功能必须说明,并确定下次提交版本的时间。
提交版本前,必须确保类文件在
CVS
上是最新的。数据库脚本需要更新时,必须明确提示,并尽可能提供不清空数据的替代方法。
3
、需求变更
的处理
当需求规约或者系统设计发生变更时,开发人员应及时用邮件通知相关的测试人员和测试经理,并提交到
CVS
上,在邮件内要指明需求变更的版本号。
同时不允许开发人员自动修改需求。
模块开发中后期,已确定无需求改动后,由测试小组成员参与测试,并提交模块质量评估确认是否可以开始进行大规模的测试。
二、项目初期测试工作
确定软件功能-―明确产品最终是要实现的功能。
确认测试大纲――根据提供的系统设计说明书确定所有的功能以及功能实现的流程,同时确定功能性测试用例。(
测试用例不但可以保证软件的质量,还会大大缩短需求完成后的测试时间。因此,测试用例必须写,而且是在模块需求规约确定后,在开发第一次提交版本前完成。执行过程中,如有需求变更,测试用例规约也要更新。)
确定测试计划――根据项目进度计划书制定,确保有足够的时间进行测试。
主要是排出各项测试的时间进度及人员安排,如有变动时应做相应调整。
项目负人需提供项目内各个模块的负责人或者相应的开发人员,便于沟通。
三、项目中期测试工作
需求以及系统设计完成之后,在需求变更不太大的情况下,根据需实现的功能完善功能性测试用例。
了解客户的工作环境,确定测试环境。
研究自动化测试工具的使用,确定能够使用那种工具或者协议进行测试,可以提高测试效率。
四、项目后期测试工作
主要进行黑盒测试,以手工测试为主,在项目后期进行简单的性能测试(可以考虑利用工具实现部分测试)。
开发小组提交版本后,有专门负责相应模块的测试工程师进行初步测试,在开发小组提交新版本前的一到两天,测试工程师须提供测试用例的执行情况,模块的关联情况。
Daily Build
的意义:
模块得以及时整合
要求程序员及时把最新代码放入代码库
版本基本固定后,开始考虑使用自动化测试工具,为后来的回归测试做准备。
根据测试计划及时停止测试工作,提交测试版本号,监督制作安装程序。安装完成后,再次进行复查。
项目例会-阶段测试结束后第二天召开小组会议,时间为
1
到
2
小时,包含内容为小组成员小结,新版本的对应的测试计划,测试用例及预期执行时间。(最好建立每日报告
Excel
格式,确定每天的工作成果。见附件)
确保发现的缺陷(错误)已经被开发人员纠正或处理过,并且没有引入新的缺陷(错误)。当测试通过各种途径发现了存在的缺陷或错误以后,并不是交一份测试报告就草草了事,而是在递交报告以后继续督促开发人员及时关闭已知缺陷或错误。
开发团队对已知的缺陷或者错误修改完成后,测试人员进行回归测试,验证开发人员在修改
bug
后没有引入新的错误。回归测试如发现问题,继续报开发人员,直至回归测试最终通过。
完成测试报告,及总结。
结束工作:建设测试资源库和培训。
建设测试资源库:总结积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序,上传到
CVS
内,防止以后测试团队在实际测试过程中少走弯路,有效地避免测试脚本或规格文档的重复开发。
培训工作是通过技术讲座、正式或非正式团队会议等形式进行,提高团队成员的技能。
posted on 2006-08-28 13:15
aaaa 阅读(172)
评论(0) 编辑 收藏 所属分类:
测试