1. 引言
1.1 目标
软件产品在发布前,如果能够经过全面的测试过程,可以有效控制软件缺陷最后遗留给用户,从而减少软件质量事故发生的概率,减少返工修复成本,增加用户对产品的信赖程度,提高产品在市场上的竞争力,这已经是不争的事实。因此软件测试过程应该与整个软件开发过程是平行进行的,测试计划应该在需求分析阶段就已经开始制定了,随后的工作则会伴随着软件开发的过程逐步展开。
性能测试 测试软件是否易用,主观性比较强。一般要根据很多用户的测试反馈信息,才能评价易用性。
冒烟测试 是指在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性,冒烟测试通常由测试人员或开发人员完成。
回归测试 2. 测试体系完善
1. 项目情况 a. 由公司的市场部或产品部下达项目开发任务后,确定了项目情况后,项目的主要角色b. 2.1 项目启动
2. 测试职责
a. 良好的开端对项目的成败有重要影响,要做好测试项目的工作,就不能忽视项目启动的一些情况,测试人员应该首选关注以下情况:
b. 弄清项目背景,抓住项目的要素。
c. 深刻认识项目需求,评估以前是否有一定知识储备,弄清项目开发团队成员,便于后期的沟通交流。
d. 分析和弄清测试工作量是否可以保证项目的高质量发布,在项目启动会议上应该和项目负责人做充分彻底的交流。
e. 项目启动后,目前的测试资源是否能满足测试需要,如果不满足,需求在项目启动后,多长时间能到位。
3. 职能流程
2.2 测试计划
1. 测试人员
a. 测试计划是一个过程,而不仅仅是一个文档,制定测试计划的目的有利于测试范围、测试时间和测试资源的调配和充分利用。测试计划是整个项目开发计划的一个组成部分,是对项目计划的分解和提炼。
b. 测试计划中应该明确规定项目在整个开发周期内各个阶段的测试任务,并确定测试任务的所属测试人员,在整个测试项目,除非特殊情况,一般规定测试人员应该做到专职专用,保证测试的连贯性和高效率。
c. 测试计划中测试测试风险应该加以标注和说明,比如人员的变动、测试人员对项目的熟悉程度、需求的频繁变动等等不可控因素加以说明。
d. 测试计划中应该对阶段测试任务有明确的工作量,一方面是对个项目的工作量的分解,同时能起到对测试人员在测试过程中做到自我管理的作用。
2. 职能流程
2.3 需求分析
1. 开发人员
a. 需求编写是将软件产品需求以结构化、共享的可管理的形式编写成文档的过程,需求分析和编写需求文档的过程关乎后续诸多操作,这是至关重要的一个过程,有道是“魔刀不误砍柴工”,由此引申到软件工程上,需求阶段应该花一些力气和时间,为后面的编码、测试打下良好的基础。
b. 需求的分层主要分为业务需求、用户需求、功能需求,开发人员不光要重点关注功能需求的实现,同时也要关注下业务需求和用户需求。
d. 开发人员应在需求分析完成后,完成《概要设计文档》、《详细设计文档》文档,这作为整个项目开发阶段的重要参考文档,需求的确立是一个渐进和不断迭代的过程,不可控因素较多,所以,在需求的设计上,应有足够的可调控余地。
2. 测试人员
a. 在一个全新的项目中,对需求的了解程度通常要求是测试人员应该高于开发人员,这样,我们测试人员才能在测试过程中对业务方面不会有漏洞和瑕疵,以基础知识为内力,以测试方法和测试理论为核心力,以业务知识为动力,从而出色的完成项目整体测试过程。
c. 测试人员在需求分析后,应该配合开发人员完成《原型设计书》,一方面可以通过编写文档的方式更直接熟悉项目,同时也为后续测试文档的设计、测试的执行打下良好的基础。
3. 职能流程
2.4 测试设计
1. 开发人员
a. 测试设计是环境是整个测试执行的重要环节,良好的测试设计可以看做是基石,只有基石牢固才有可能使测试任务和测试质量高效而优质,有作为开发人员也应该配合和关注测试设计这一环节,可能不是义务,但至少应该做到协助。
b. 有可能测试人员在使用自动化测试工具过程中用到脚本,而测试人员在编写脚本的时候,可以请教开发人员,开发人员应该在不影响自己工作前提下,可以积极协助解决,毕竟在代码的编写和熟练程度上,开发人员应该优于测试测试人员,这是不争的事实。
c. 有一些项目在测试过程中,可能会用到第三方平台,而第三方可能需要写模拟程序来协助测试我们的项目,这个模拟程度就需要开发人员来提供,目的是更好的配合完成我们项目的测试工作。
d. 在测试设计过程中,可能有需求的变动或功能的增删,作为开发人员应该有义务将变更或增加的地方职能流程
2.5 测试执行
1. 开发人员
a. 测试人员在测试过程中,对测试出来不能确定的问题可能会和开发人员做进一步确认,作为开发人员应该和测试人员积极沟通配合。
b. 开发人员对给分配解决的c. 开发人员在测试执行过程中对分配给自己的2.6 测试记录
1. 测试人员 a. 测试记录主要包括记录测试结果和测试过程,测试结果是指针对测试发现的2.7 缺陷跟踪
1. 开发人员 a. bug的整个生命周期离不开开发人员的参于,当项目经理分配给属于自己的对bug 解决后,首先应该自己测试,保证测试没有问题后再提交到版本上,避免未经自测就直接提交,导致解决bug的时间周期延长。 c. 开发人员在解决bug的过程中,有可能出现按描述的步骤根本复现不了该bug,这种情况完全有可能,因为bug的出现不但是操作的问题,还涉及测试环境、输入数据、数据的累积等原因,所以,遇到不能复现的问题,应该和测试人员积极沟通,不要将bug直接就No bug。 2. 测试人员 a. 测试人员在提交bug后,应该对该bug全程跟踪,bug从提交到Closed整个生命周期的各个阶段,测试人员一定要实事求是、严谨细致的认真对待。 b. 测试人员在提交bug中,应该明确标明bug的严重级别程度、优先解决顺序、测试步骤、预期结果、实际结果、项目版本、bug出现的概率等重要属性,便于bug的解决优先级和项目的总结统计。 c. 在验证bug时,发现bug已经解决,应该在不bugd的note中注明bug解决的当前版本,如果验证问题还存在,需要将bug状态重新置为reopen,并和解决bug的开发人员做主动积极沟通。 d. 在测试中,可能会发现有些bug出现的概率很小,复现的机会也非常小,但又确实存在,对这类bug应该先记录整理下来,并告知项目负责人,申请做长时间观察测试时间,因为这类bug可以需要长时间的测试才能复现,一旦复现应该将测试数据、日志、抓图等信息都保存下来。 3. 职能流程 1. 测试人员 a. 测试结束后,首先需要将最后测试的版本发送到FTP服务器上,同时告诉项目经理,将版本控制工具上的版本流做lock操作,将版本流冻结,禁止操作人员随意提交代码到项目上。 b. 测试完成后,需要将测试的情况整理成 告,发送给参与项目的全部人员和相关领导, 告中应该重点体现测试的信息,比如测试轮数、发现的bug总数量、遗留bug的处理意见、性能指标等必要参考信息。 c. 测试结束后,对测试文档也要做整理并归档提交到服务器做备份保存,比如在测试过程中发现测试用例的不完善,测试过程中需求的微调等都需要同步到测试文档中有体现。 d. 测试结束是代表一个阶段的结束,应该给参与测试人员几天自由支配的时间,调节下状态。 2. 职能流程 1. 测试人员 a. 一个项目测试完成后,应该就近抽半天时间大家一起座下来做个测试总结,总结时间不能和项目结束时间相差太久,因为刚测试完项目大家一定有很多想法,时间一长,很可能就会遗忘,而且时间长了,大家可能又有新的测试任务,所以,测试总结应该尽快完成。 b. 没有总结,就不能认识自我,就不知成功在哪里,失败和不足在哪里。只有经过思考,才能提高的更快,进步的更大。所以说,总结很有必要,在总结上,大家可以各抒己见,发表自己在测试中的困惑和困难,同时也应该分享自己在测试项目中一些经验。 c. 总结过程中,可以适当邀请项目负责人和开发人员代表,听听他们对我们测试的一些建议和看法,这样也有利于以后更好的配合工作,测试其实就是一种服务,测试应该怀着这样的心态去测试。 d. 总结完成后,应该形成文档化并保存下来,作为测试体系改进和完善的重要内容,同时也可以为部门、公司的流程体系建设完善提供一些参考信息。 2. 职能流程 a. 测试任务:根据测试计划确定当前项目的测试人员,对测试人员做充分的沟通了解,涉及和所负责的有关项目评审会议都应参加,对制定的测试计划能确保测试人员知悉并能保持跟进状态。对重点项目和紧急项目,要求测试人员在经验和人员数量有适当倾斜,保证按时、高质量完成任务。 b. 测试沟通:测试中作为测试人员应该做到积极和有效的沟通,对不懂和不明白的问题,提倡自己通过多种方式尝试解决至少4. 测试工具使用
功能描述 工具名称 使用阶段 获取方式 使用情况 测试计划定制 MS Project 2010 计划阶段 试用版本 熟悉 原型图设计 MS Visio 2010 需求阶段 破解版本 熟悉 测试方案编写 MS Word 2007 设计阶段 破解版本 熟悉 测试用例编写 测试文档评审 MS Excel 2007 评审阶段 破解版本 熟悉 测试文档管理 SVN 、 测试阶段 开源、商业 熟悉 性能测试工具 Jme ter、 开源、商业 熟悉、了解 生成测试数据 TestDataBuilder、 Dbmonster 开源、开源 熟悉、了解 缺陷管理工具 Mantis、Seleniu、Robot 商业 了解 测试 告 MS Word 2007 结束阶段 破解版本 熟悉 测试总结 备注:对上表格“使用情况”一列中标注的熟悉、了解的说明: 了解:指在以前工作使用很少用或在工作之余研究过该工具,可能还未在项目中实际使用过。 1. 软件测试方法指南:对测试人员在进行各类测试时进行规范化的要求,通过规范的制定,可以制定。 3. 测试用例测试规范:包括测试用例的模板以及测试用例的测试要求。 4. 缺陷提交规范:用于规范测试人员的5. 测试 告规范:包括测试 告模板及对测试 告的要求。限定和指明测试 告应该包括哪些内容。 6. 测试工具使用规范:指出测试人员在测试阶段应该使用哪些测试工具,工具的获取途径和使用细则。 7. 其他规范:缺陷的分类规范、测试人员的测试流程规范、测试人员的培训制度规定等。 声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!2.8 测试结束
2.9 测试总结
3. 测试管理规划
3.1 测试人员
5. 测试规范建立