全文预览已结束
下载本文档
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
详细的描述一个测试活动完整的过程。1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后进入项目,开始进行统计和跟踪2. 开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。3. 测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。4. 测试用例完成后,测试和开发需要进行评审。5. 测试人员搭建环境6. 开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现bug后提交给bugzilla。7. 开发提交第二个版本,包括bug fix以及增加了部分功能,测试人员进行测试。8. 重复上面的工作,一般是3-4个版本后bug数量减少,达到出货的要求。9. 如果有客户反馈的问题,需要测试人员协助重现以及回归测试。一般测试流程:1.需求分析阶段:只要就是对业务的学习,分析需求点。2.测试计划阶段:测试组长就要根据SOW(工作说明书)开始编写测试计划,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容。3.测试设计阶段:测试方案一般由对需求很熟的高资深的测试工程师设计,测试方案要求根据 SRS上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。测试方案编写完成后也需要进行评审。4.测试方案阶段:主要是对测试用例和规程的设计。测试用例是根据测试方案来编写的,通过测试方案阶段,测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案,而测试方案又覆盖了测试需求点,这样才能保证客户需求不遗漏。同样,测试用例也需要评审。5.测试执行阶段:执行测试用例,及时提交有质量的Bug和测试日报,测试报告等相关文档。流程:需求分析测试计划测试设计测试环境搭建测试执行测试记录缺陷管理软件评估出货。. 12.软件测试活动的生命周期测试周期分为计划、设计、实现、执行、总结。其中:计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;设计:完成测试方案,从技术层面上对测试进行规划;实现:进行测试用例和测试规程设计;执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。总结:记录测试结果,进行测试分析,完成测试报告。减少冗余的测试白盒测试与黑盒测试的方式虽然不同,但往往有“异曲同工”之妙。在很多地方,白盒测试黑盒测试会产生一模一样的效果(或者能推理出来),这样的测试是冗余的。在集成测试、系统测试阶段,可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余,应当设法剔除不必要的重复测试工作。减少无价值的测试无价值的测试通常是由于不懂得测试技术引起的。例如功能测试,在等价区间之中,本来只要测试一个典型的输入就行了,如果有人在此区间测试了100次,那么其中99次就是无价值的。如何“偷工减料”有一些“短、平、快”的项目,经费本来就少,用户对质量要求也马马虎虎。为了能多挣一点钱,开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠,否则软件拿不出手。基本方法是找出软件中需要优先测试的部分(见下表),其它次要部分可以忽略或将来再测试。“偷工减料”方法的测试优先级:哪些功能是软件的特色?哪些功能是用户最常用的?如果系统可以分块卖的话,哪些功能块在销售时最昂贵?哪些功能出错将导致用户不满或索赔?哪些程序是最复杂、最容易出错的?哪些程序是相对独立,应当提前测试的?哪些程序最容易扩散错误?哪些程序是全系统的性能瓶颈所在?哪些程序是开发者最没有信心的?测试计划的目的是什么?软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义?答:测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。大体上来说可分为单元测试,集成测试系统测试验收测试每个阶段又分为以下五个步骤:测试计划,测试设计,用例设计,执行结果,测试报告初始测试集中在每个模块上,保证源代码的正确性,该阶段成为单元测试,主要用白盒测试方法。接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。主要采用黑盒测试方法,辅之以白盒测试方法。软件集成后,需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。单元测试单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。集成测试集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。系统测试系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。验收测试验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集回归测试回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。针对缺陷采取怎么样的管理措施只是对缺陷的生命周期进行管理和跟踪,Bugzilla或者TD已经足够了,1.要更好的管理缺陷,必须引入缺陷管理工具,商用的或者开源的都可。2.根据缺陷的生命周期,考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。3.所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交到缺陷管理工具中,这是缺陷提交的管理。4.缺陷提交后,需要即时的指派给相应的开发人员,提交缺陷的人需要密切注意缺陷的状态,帮助缺陷的尽快解决。
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
评论
0/150
提交评论