一个成功软件测试项目的经验[2]

发表于:2010-01-20来源:作者:点击数: 标签:软件测试项目经验
一个成功软件测试项目的经验[2] 项目管理 产品成熟期积极的测试 随着产品的不断成熟,主要功能的实现已经趋于完善,关键路径的测试已经不成问题。此时的 程序员 们,压力已经大大减轻,他们的工作重点也从“构建”转移到了“修复 Bug ”,这个阶段程序人员对

  一个成功软件测试项目的经验[2]   项目管理 

    产品成熟期积极的测试

  随着产品的不断成熟,主要功能的实现已经趋于完善,关键路径的测试已经不成问题。此时的程序员们,压力已经大大减轻,他们的工作重点也从“构建”转移到了“修复Bug”,这个阶段程序人员对于Bug的接受程度是最高的,对Bug的修复和反馈也非常积极。于是,此时的测试工作应对整个产品的细节和所有路径进行覆盖测试,保证测试的全面性,层层深入地测试产品值得测试的各个部分,尽可能多的发现并报告Bug。

  产品稳定期多样的测试   软件测试 

   在这个阶段,可以尽情的向开发人员报告产品易用性和界面的Bug;可以充分发挥每个测试人员的想象力,根据以往的测试经验来搭建测试场景,构造测试数据;可以通过不同业务场景的不同操作,通过特殊的测试数据,以及相对复杂的集群测试环境来进行多样化测试。为什么?因为此时必须测试得更加深入,才能发现更深层次的Bug,于是多样性的测试、探索式的测试必不可少。产品发布期谨慎的测试在临近产品发布的日子,包括测试在那的很多工作都变得谨慎起来:代码的提交权限受到了控制,只保留开发经理一个入口;测试的重点更加具有防御性,要仔细测试每个变更,还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量,首当其冲地就是应该有专业的测试团队。在很多小的软件项目中,往往没有专门的测试团队。这样一来,到了代码基本完成之时,就只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作,测试质量难以保证。我们则会尽早规划测试团队的人员结构,完善测试团队的配置。每个测试人员的特点和强项常常不尽相同,例如,擅长测试数据质量的测试员,未必能胜任系统环境配置复杂的测试任务。总之,对测试经经理而言,做到知人善任非常重要。同时,在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统,要求测试人员不仅应掌握一定的工作流业务知识,还需要有较强的逻辑思维能力。而在此项目测试过程中,笔者发现一位测试人员对功能的细节过分关注,而对整个工作流程总是理解不到位。显然,其设计出的测试用例不能适应工作流测试的要求。于是,立即进行人员分工和测试任务的调整,保证了测试工作顺利进行。坚持立场,规范流程我们公司有严格的测试流程,所有提交测试的软件版本,在提交之前,都要完成必需的冒烟测试(Smoking Test)。冒烟测试是一种测试包,其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的,如果该版本没有通过冒烟测试,则就可以说明该版本不太稳定,不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中,为了保证每个可测试版本的冒烟测试质量,是由开发人员负责完成的。他们知道,如果程序不能通过冒烟测试,测试小组就会拒绝该版本。因此,他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中,不仅会明确版本号,修改或新增的功能详细说明,还会给测试人员提供此版本的测试重点,以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。

  在项目测试过程中,我们也出现过打回某个版本的情况,拒绝测试。总结起来,基本上有以下几种情况:

  ● 由于任务查询的技术难度比较大,开发进度已经延期了5天,测试人员正在焦急的等待这部分的功能测试。可是,新提交的可测试版本中,这个功能根本就不能使用,如果进一步测试就是浪费时间,我们立即打回了这个测试版本。

  ● 新增了代办的功能,可是以往的代理功能中的增加代理人功能却不能正常使用,而增加代理人功能又是代办功能的基础,也就是说,在这个版本中,及时代办功能完全能够测试,可离开了增加代理人功能,代办测试是没有意义的。

  ● 在回归测试阶段,可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本,如果此时测试人员并不急需更换版本,并且得知另一个版本会在几个小时之后就会完成,我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段,测试人员积极与开发人员配合:

  ● 负责提供冒烟测试案例

  ● 如果测试人员处于版本等待阶段,主动和开发人员一起做冒烟测试。开展有效测试,提高测试效率有效的测试用例是软件测试成功的关键,有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中,我们从测试模型(Test Model)入手,结合丰富的测试经验和专业知识,从繁多的测试用例中挑选出有效的用例,用尽可能少的测试输入,覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型,并结合了正交设计技术和组合覆盖技术,完成了对整个系统的测试设计。知己知彼,合力制胜提供服务使测试人员有机会赢得程序员的信任,同时也有机会展示自己的才能。同时,带来的回报是得到了开发人员对我们的帮助。在整个项目过程中,我们获得了很好的回报,比如:开发人员讲解设计思路、算法流程;和测试人员一起构造测试数据;积极参加每日测试例会,主动解决问题等。这样良好的合作状态与测试人员的主动努力是分不开的,主要体现在:

  ● 获取程序员信任,及时沟通不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息,比如他们的计划、设计文档的早期草案和早期原型等,测试工作会更加有效。越早与程序员接触,情况就越好。尽早提出你的意见和反馈,了解程序员提交前完成的工作。

  ● 主动出击,提供服务 ○ 在测试前期,直接向开发人员提供服务;这不仅可以建立信任,而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务:○ 对工作流的运算逻辑?构件进行了测试,方便了后期开发工作流客户端应用的使用。○ 对内部版本和原?型进行测试。○ 对需求文档的可测试性进行评审。开发人员和测试人员一样,对模棱两可的要求很头疼,他们非常希望测试人员的介入。○ 帮助程序员建立测试环境,方便程序员进行测试。

  ● 耳目作用

  在项目过程中,测试人员有机会能够发现很多存在的问题,比如:需求和设计以及开发的不一致性,项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身,及时验证和发现项目环节中的问题。

  总之,测试项目能否成功,与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色,要乐于接受这种角色,只有这样,才能得到被服务的人的帮助和支持,以及认可。

原文转自:http://www.ltesting.net