业务测试活动总结.doc

业务测试活动总结 业务测试活动总结篇一：项目测试经验总结 项目测试经验总结 说明：以下项目测试经验是我在原来公司工作中的实际经验，拿出来和大家一起交流。我相信之前的项目测试工作中有不少可以改进的地方，还希望大家多多交流。 项目测试经验 Judy Shen 本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及交流。 1测试团队介绍 在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。 我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。测试团队有6个人，从图一可以看出来，一个人可以参与多个处于不同阶段的项目测试工作。 图一 测试团队组织架构 参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。如图二所示： 图二 项目组织架构（旧） 上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测试组不进入项目，而是由项目组将测试工作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。 这个模式还在探索中，如图三所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。这种模式需要进行独立核算，包括成本估算、预算、结算等。但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面提到的内容，如果没有特殊说明，都是在旧的模式下进行的。 图三 项目组织架构（测试外包方式） 我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！ 有着样的说法：“软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。只有两条腿的健壮差不多，走路才稳当。”出于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。例如： ?技术方向： ?功能自动化测试 ?性能测试 ?单元测试 ?测试管理 ?业务方向： ?物流业务 ?智能交通 ?知识管理 但这种方式在工作开展上有些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要挤出时间学习业务知识，在操作上是比较困难的。在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作（如部门制度建设）。当时公司允许我们团队有30%的工作量投入部门建设上。将部门建设工作分开，主要是用于统计部门成本和测试成本用的。 前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种，如表一所示。在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。 角色 职责测试管理员 负责测试项目的管理 测试过程问题的处理与反馈 系统/性能测试组织和计划 测试过程状态报告 测试设计员 测试需求的描述 系统/性能测试用例的设计 测试工具、方法的引入 测试执行员 根据需要开发测试脚本 按照测试用例、测试脚本执行测试 项目测试工作指导 测试监督与度量员 测试度量 测试过程问题的汇总与反馈 开发产品的质量抽检与评定 表一 测试角色划分 了解了原来测试团队的分工之后，下面介绍一下测试团队的工作内容。原来的测试团队承接的工作内容包括： ? 承担系统测试、用户测试、性能测试； ? 进行测试技术研究及培训 其中，测试技术研究，属于提高团队工作技能的工作，在整个部门范围内进行，这里属于部门建设工作；对于项目中的测试人员有可能需要进行，如果项目采用新的测试技术或者测试工具，那么就需要项目测试组成员研究测试技术了，这部分属于项目测试工作。 培训，是指把内部研究的成果在团队内使用，在适当的时机在公司内传播。我们测试团队在2004年开展了21次内部培训，7次公司级培训。因为每个人各有研究重点，所以我们每个人都是团队内部培训的讲师。 说到测试工程师的工作内容，那么就涉及到测试工程师该做的和不该做的。当然这和公司对测试人员定位有关，这里仅指以前的组织。要说该做的，那么我们需要先明确为什么我们要测试？这是因为存在“系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景。在这样的背景下，产生了测试，但是又因为开发人员自己测试自己的东西，难免测试不全面，所以产生了测试工程师这个角色。因此，测试人员他该做的，就是测试软件产品和用户需求不一致的地方，并尽可能多的发现缺陷，能够向项目经理汇报软件质量状态。但是在实际工作中，测试人员经常主动或被动的去做了一些不该做的事情。例如说，测试人员认为自己或者测试能够保证软件的质量，以及有意识或无意识的接受了决定软件是否发布的这个权利。 为什么测试无法保证软件的质量，是因为项目的质量，需要项目组的所有成员共同努力，才能达到质量保证的目的。单纯靠测试工程师的力量，是无法实现软件质量保证的目的。 为什么测试人员不适合承担决定软件是否发布的权利，是因为软件的发布，是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后，由项目经理（或者与会者）做出是否发布的决定。在这个过程中，测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。当然，我知道这两点会有很多人不认同，但是没有关系的。我接触的同行中对两点经常有争论。但是，有一些质量大师等权威人士还是全部或部分赞同这两个观点的，如：菲利普.克劳士比曾在他的书中提到软件质量的保证需要全员努力，需要过程的控制的，而不是某个英雄可以保证软件质量的等。 2项目测试工作 做了背景介绍后，下面我介绍之前项目如何开展测试工作的。 因为测试过程是整个测试工作的一个纲要，所以首先得从测试过程讲起。 2.1 测试过程 测试过程，我们包括四个环节：测试计划、测试设计、测试执行、测试分析。 图四 测试过程 2.1.1测试计划 测试计划主要是进行描述测试需求、分析制定测试计划工作。在制定测试计划时，经常有人认为测试计划是在整(来自:WWw.xMsjoB.com 厦门 培训考试 网:业务测试活动总结)个项目计划制定之后才开始进行测试计划的，事实上并不是这样的。测试计划和项目计划是互相影响的。举个例子。假设项目有进行性能测试的需求，但是测试工具又需要学习，那么我们在测试计划中就需要预留这部分的时间，还有，测试用例的评审，也需要预留时间。或者，如果某部分比较复杂，可能测试需要的时间会较多，或者需要测试的次数会比较多，那么可能要求开发组先安排这个核心模块的开发，这样需要调整开发计划的顺序。所以，测试计划和项目计划是互相影响的。在测试计划环节还包括测试需求的描述，主要是确认需求是可测试的，并将需求细化为具体的可测试点，保证测试设计时可以根据测试需求编写测试用例，而避免遗漏测试点。我们的测试需求需要得到业务分析人员的评审，测试计划要得到项目经理的审批认可。 对于测试计划，还需要说明的是，在具体的每个测试阶段工作计划中，我们需要定义本阶段测试需要进行的次数。每一轮测试是一个完整的测试周期，按照这里介绍的测试过程进行。通常我们是一天一轮测试，最多是两天一轮测试。通过这种方式，减少了测试和开发之间的空挡时间，即测试等开发，开发等测试。例子如图五所示： 图五 测试迭代例子肯定会有人疑问，如果一个系统很庞大的话，怎么能在一两天内完成测试呢？是的，如果系统比较大的话，确实没法在一两天内完成所有测试点的全面测试，有可能需要一周或更长的时间，但是这样的话，就出现了测试、开发互相等待的情况了。所以，在我们制定的测试阶段计划时，需要指明本次测试的测试重点，测试范围。我可以这一轮测试进行A、B模块基本功能测试，第二轮测试进行C、D模块基本功能测试，第三轮测试，进行主要业务流程测试，第四轮测试，关注负面测试。在我之前的实践中，发现这种方法还是比较有效的。可能大家也注意到了，这个例子是另一个项目的。没错，在今天提到的移动的这个项目中我们没有按照这种策略进行测试，弄得当时我们测试小组工作很累，很被动，经常是开发说测试我们就要马上开始测试，而缺乏计划。实施这种方法后，测试的计划性就比较强，测试不用总是被打扰。 2.1.2测试设计 测试设计，主要是根据需求、设计进行的测试用例设计工作。如何从需求导出测试用例并设计测试用例，是整个测试过程中很重要的一部分工作，关系到测试执行效果。但是在刚开始时，系统没有界面，所以我们只能根据系统用例搭建测试用例的初步框架，能写多少写多少。随着对系统的理解深入，加上后面也开发了系统原型，我们就可以不断完善测试用例。即使是在测试阶段，我们仍不断修改测试用例。测试用例我们分为两种，一种是内部测试用例，项目组内部使用；一种是验收测试用例，偏重于业务，供客户使用。项目组内部用的测试用例例子如图六所示： 图六 测试用例例子（项目内用） 从图中大家也可以感觉到项目组内部使用的测试用例在维护上比较不方便。因为我们的需求并没有做到很细，加上需求本身就是变化的，所以我们的测试需求经常修改，一旦测试需求新增、修改、删除时，测试用例要相应进行调整。这就造成了1)定位测试用例比较不方便，2)测试用例编号修改不方便，3)阅读、执行测试用例不方便。所以，我在2004年底开始准备在团队内自主开发一个测试用例管理系统。 2.1.3测试执行 在测试执行阶段，主要进行测试的执行工作。如果项目有需要编写或录制测试脚本的话，那么也在这个阶段进行。测试执行结果是在原有测试用例的副本上编写实际执行结果而形成。在东南融通，它是把这个活动单独为“测试实施”环节。 2.1.4测试分析业务测试活动篇二：业务技能考试总结 业务技能考试总结 在开展“文明收费，优质服务100天”活动以来，XX站基于提高职工业务技能，培养综合素质的目的，同时也是为今年管理公司组织的点钞技能竞赛选拔参赛人员，根据站务会研究决定，每次每班来上班期间，都要考试一次，具体时间是上第二个夜班的白天，并实行考试成绩第一加绩效考核分，考试成绩倒数第一扣除绩效考核分的奖惩办法。本本办法实施以来，极大的提高了员工对业务知识，业务技能的学习热情，提升了服务员的业务能力。根据各次的考试成绩统计，发现收费员的成绩都在逐步的提高，考试平均分已经达到95分以上的可喜成绩。 总结，XX站通过开展“文明收费，优质服务100天”文明服务专项治理活动、业务知识、点钞技能专项培训活动、评优评先活动，鼓励了全站员工坚持文明服务，优质服务的服务态度，树立了XX站文明窗口形象，树立了“文明收费、礼貌待人，优质服务、方便司乘”服务理念，增强服务了意识、转变服务了观念、强化服务了措施，全站人员共同努力营造了一个“舒适、温馨、平安、快捷、优美、和谐”的收费服务环境。业务测试活动总结篇三：2014测试工作个人年终总结 工作总结 转眼间来公司已经一年多了，在这一年多的时间里做了很多工作，也学到了很多知识与道理。下面针对2014年的工作情况，进行简单的阐述。希望各位领导和同事能对我的总结进行批评指正。 一、工作职责 我的工作职责主要有以下几方面： 1、功能测试。 2、性能测试。 3、配置管理。 4、培训、带领新人。 二、工作总结 2014年我主要完成了以下几方面的工作： 1、测试工作 各项测试的主要内容分别为理解需求、分析业务，编写测试、测试用例，执行测试，记录缺陷，编写测试。测试过程中与开发人员、系统集成人员以及客户等多方进行沟通工作。 2、配置管理工作 负责将每次测试的交付物、培训文档、测试模版等整理并上传到SVN上。 3、培训管理工作 2014年下半年，由于工作较为繁忙，测试团队在不断壮大，我负责带领指导3个新人。负责培训测试技巧，指导书写文档等工作。 三、经验分享 从多次测试任务中，总结出以下两点： 1、测试任务开始前，将测试范围、深度、文档书写规范等规则统一制定好，减少返工的工作量。 2、编写测试用例前，将所有情况简单列举出来，与开发人员或需求提出人员确认无误后，再具体形成文档。 四、对部门建设的建议 在部门建设上，我想可以从以下几方面逐步开展部门建设工作： 1、强化制度建设。例如：系统上线后新增bug的责任划分、任务延迟时需说明原因等。 2、争取能让开发人员了解测试过程。如果能让开发人员了解测试过程，可以让测试工作更好开展，以及获得更好的配合。 3、加强部门测试成果的积累与沉淀。每次测试完成后，相关测试人员要进行业务总结，写成文档上传SVN，以便知识共享。4、除了将已有测试成果进行有效管理外，还需要将