项目测试经验总结.docx
《项目测试经验总结.docx》由会员分享，可在线阅读，更多相关《项目测试经验总结.docx（13页珍藏版）》请在冰豆网上搜索。
项目测试经验总结
项目测试经验总结
说明：
以下项目测试经验是我在原来公司工作中的实际经验，拿出来和大家一起交流。
我相信之前的项目测试工作中有不少可以改进的地方，还希望大家多多交流。
项目测试经验
——JudyShen
本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及交流。
1 测试团队介绍
在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。
我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。
测试团队有6个人，从图一可以看出来，一个人可以参与多个处于不同阶段的项目测试工作。
图一测试团队组织架构
参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。
每个测试组有一个测试组长负责项目测试工作。
项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。
测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。
如图二所示：
图二项目组织架构（旧）
上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。
这里的测试外包模式是指，测试组不进入项目，而是由项目组将测试工作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。
这个模式还在探索中，如图三所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。
这种模式需要进行独立核算，包括成本估算、预算、结算等。
但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。
后面提到的内容，如果没有特殊说明，都是在旧的模式下进行的。
图三项目组织架构（测试外包方式）
我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？
不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。
有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！
有着样的说法：
“软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。
只有两条腿的健壮差不多，走路才稳当。
”出于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。
例如：
● 技术方向：
⏹ 功能自动化测试
⏹ 性能测试
⏹ 单元测试
⏹ 测试管理
● 业务方向：
⏹ 物流业务
⏹ 智能交通
⏹ 知识管理
但这种方式在工作开展上有些困难。
如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要挤出时间学习业务知识，在操作上是比较困难的。
在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作（如部门制度建设）。
当时公司允许我们团队有30%的工作量投入部门建设上。
将部门建设工作分开，主要是用于统计部门成本和测试成本用的。
前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。
在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种，如表一所示。
在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。
角色
职责
测试管理员
负责测试项目的管理
测试过程问题的处理与反馈
系统/性能测试组织和计划
测试过程状态报告
测试设计员
测试需求的描述
系统/性能测试用例的设计
测试工具、方法的引入
测试执行员
根据需要开发测试脚本
按照测试用例、测试脚本执行测试
项目测试工作指导
测试监督与度量员
测试度量
测试过程问题的汇总与反馈
开发产品的质量抽检与评定
表一测试角色划分
了解了原来测试团队的分工之后，下面介绍一下测试团队的工作内容。
原来的测试团队承接的工作内容包括：
● 承担系统测试、用户测试、性能测试；
● 进行测试技术研究及培训
其中，测试技术研究，属于提高团队工作技能的工作，在整个部门范围内进行，这里属于部门建设工作；对于项目中的测试人员有可能需要进行，如果项目采用新的测试技术或者测试工具，那么就需要项目测试组成员研究测试技术了，这部分属于项目测试工作。
培训，是指把内部研究的成果在团队内使用，在适当的时机在公司内传播。
我们测试团队在2004年开展了21次内部培训，7次公司级培训。
因为每个人各有研究重点，所以我们每个人都是团队内部培训的讲师。
说到测试工程师的工作内容，那么就涉及到测试工程师该做的和不该做的。
当然这和公司对测试人员定位有关，这里仅指以前的组织。
要说该做的，那么我们需要先明确为什么我们要测试？
这是因为存在“系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景。
在这样的背景下，产生了测试，但是又因为开发人员自己测试自己的东西，难免测试不全面，所以产生了测试工程师这个角色。
因此，测试人员他该做的，就是测试软件产品和用户需求不一致的地方，并尽可能多的发现缺陷，能够向项目经理汇报软件质量状态。
但是在实际工作中，测试人员经常主动或被动的去做了一些不该做的事情。
例如说，测试人员认为自己或者测试能够保证软件的质量，以及有意识或无意识的接受了决定软件是否发布的这个权利。
为什么测试无法保证软件的质量，是因为项目的质量，需要项目组的所有成员共同努力，才能达到质量保证的目的。
单纯靠测试工程师的力量，是无法实现软件质量保证的目的。
为什么测试人员不适合承担决定软件是否发布的权利，是因为软件的发布，是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后，由项目经理（或者与会者）做出是否发布的决定。
在这个过程中，测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。
当然，我知道这两点会有很多人不认同，但是没有关系的。
我接触的同行中对两点经常有争论。
但是，有一些质量大师等权威人士还是全部或部分赞同这两个观点的，如：
菲利普.克劳士比曾在他的书中提到软件质量的保证需要全员努力，需要过程的控制的，而不是某个英雄可以保证软件质量的等。
2 项目测试工作
做了背景介绍后，下面我介绍之前项目如何开展测试工作的。
因为测试过程是整个测试工作的一个纲要，所以首先得从测试过程讲起。
2.1 测试过程
测试过程，我们包括四个环节：
测试计划、测试设计、测试执行、测试分析。
图四测试过程
2.1.1 测试计划
测试计划主要是进行描述测试需求、分析制定测试计划工作。
在制定测试计划时，经常有人认为测试计划是在整个项目计划制定之后才开始进行测试计划的，事实上并不是这样的。
测试计划和项目计划是互相影响的。
举个例子。
假设项目有进行性能测试的需求，但是测试工具又需要学习，那么我们在测试计划中就需要预留这部分的时间，还有，测试用例的评审，也需要预留时间。
或者，如果某部分比较复杂，可能测试需要的时间会较多，或者需要测试的次数会比较多，那么可能要求开发组先安排这个核心模块的开发，这样需要调整开发计划的顺序。
所以，测试计划和项目计划是互相影响的。
在测试计划环节还包括测试需求的描述，主要是确认需求是可测试的，并将需求细化为具体的可测试点，保证测试设计时可以根据测试需求编写测试用例，而避免遗漏测试点。
我们的测试需求需要得到业务分析人员的评审，测试计划要得到项目经理的审批认可。
对于测试计划，还需要说明的是，在具体的每个测试阶段工作计划中，我们需要定义本阶段测试需要进行的次数。
每一轮测试是一个完整的测试周期，按照这里介绍的测试过程进行。
通常我们是一天一轮测试，最多是两天一轮测试。
通过这种方式，减少了测试和开发之间的空挡时间，即测试等开发，开发等测试。
例子如图五所示：
图五测试迭代例子
肯定会有人疑问，如果一个系统很庞大的话，怎么能在一两天内完成测试呢？
是的，如果系统比较大的话，确实没法在一两天内完成所有测试点的全面测试，有可能需要一周或更长的时间，但是这样的话，就出现了测试、开发互相等待的情况了。
所以，在我们制定的测试阶段计划时，需要指明本次测试的测试重点，测试范围。
我可以这一轮测试进行A、B模块基本功能测试，第二轮测试进行C、D模块基本功能测试，第三轮测试，进行主要业务流程测试，第四轮测试，关注负面测试。
在我之前的实践中，发现这种方法还是比较有效的。
可能大家也注意到了，这个例子是另一个项目的。
没错，在今天提到的移动的这个项目中我们没有按照这种策略进行测试，弄得当时我们测试小组工作很累，很被动，经常是开发说测试我们就要马上开始测试，而缺乏计划。
实施这种方法后，测试的计划性就比较强，测试不用总是被打扰。
2.1.2 测试设计
测试设计，主要是根据需求、设计文档进行的测试用例设计工作。
如何从需求导出测试用例并设计测试用例，是整个测试过程中很重要的一部分工作，关系到测试执行效果。
但是在刚开始时，系统没有界面，所以我们只能根据系统用例搭建测试用例的初步框架，能写多少写多少。
随着对系统的理解深入，加上后面也开发了系统原型，我们就可以不断完善测试用例。
即使是在测试阶段，我们仍不断修改测试用例。
测试用例我们分为两种，一种是内部测试用例，项目组内部使用；一种是验收测试用例，偏重于业务，供客户使用。
项目组内部用的测试用例例子如图六所示：
图六测试用例例子（项目内用）
从图中大家也可以感觉到项目组内部使用的测试用例在维护上比较不方便。
因为我们的需求并没有做到很细，加上需求本身就是变化的，所以我们的测试需求经常修改，一旦测试需求新增、修改、删除时，测试用例要相应进行调整。
这就造成了1）定位测试用例比较不方便，2）测试用例编号修改不方便，3）阅读、执行测试用例不方便。
所以，我在2004年底开始准备在团队内自主开发一个测试用例管理系统。
2.1.3 测试执行
在测试执行阶段，主要进行测试的执行工作。
如果项目有需要编写或录制测试脚本的话，那么也在这个阶段进行。
测试执行结果是在原有测试用例的副本上编写实际执行结果而形成。
在东南融通，它是把这个活动单独为“测试实施”环节。
2.1.4 测试分析
在测试执行结束后，我们开始对测试执行结果进行测试分析并编写测试报告。
测试报告的编写上，主要的内容在于对投入的资源、测试结果、缺陷进行分析，并对整体测试情况进行总结分析。
对于资源的分析，包括各个测试任务投入的人力情况、实际工作量与计划工作量的对比，并进行分析。
测试结果分析，可以通过对测试需求的覆盖情况、测试用例的覆盖情况及测试用例执行结果情况进行统计，并进行分析。
缺陷分析，可以通过对严重性、优先级、模块缺陷数、缺陷修复情况等方面进行统计，并分析。
例如，对系统缺陷进行统计后，发现存在比较多的可用性问题，如修改操作员所属的组后，无法登录系统等。
整体情况的总结可以从测试充分性、软件质量情况、测试活动情况、经验教训等方面进行总结。
测试分析中有个很重要的活动是对测试活动和测试过程进行经验教训的总结。
因为测试经验教训是很重要的，所以我们团队有专人负责对每个项目测试报告中的经验教训进行汇总，目的是让后面项目测试工作可以吸取前面项目测试的经验，避免犯前面项目测试工作同样的错误。
注：
本测试过程对于每个阶段的测试活动、每一轮测试活动、测试团队承接的各种测试类型均适用。
也就是说，每一轮测试之前，测试组组长都需要准备测试计划，确定测试执行重点、目标、测试内容等，选取测试用例，并按照预先选取的测试用例执行测试，测试执行结束，需要进行测试汇报。
2.1.5 测试准则
在测试过程中有个很重要的内容是：
测试准则。
在实际执行中，我们不难碰到以下类似情况：
提交测试的系统经常在测试执行初期，就出现页面访问失败或者正常功能失效的情况；测试人员不知道提交测试的版本改了什么内容或者新增了什么功能，改了哪些缺陷，导致经常碰到开发人员说测试人员提交的某些缺陷所对应的功能不属于本版本集成内容等等。
存在这些情况的很大一部分的原因是因为在项目策划阶段时，测试组未就测试准则和项目组达成一致意见，或者已经达成一致，但是并没有严格执行。
我们今天要讲的测试准则，主要是针对前者，后者属于管理层面问题，不在我们的考虑范围内。
设置测试准时需要注重实用性。
测试准则，通常包括测试进入、暂停、恢复、退出准则。
这些测试准则的例子如表二所示：
进入准则
暂停准则
恢复准则
退出准则
含义
描述开始执行测试的时机
描述系统在什么情况下暂停全部或部分测试工作。
描述系统恢复测试的必要条件。
描述测试退出的条件，有正常退出，也有非正常或意外的退出。
集成测试
测试环境已经准备好；
已经完成提交测试的模块内容；
主要功能无页面点击错误；
测试所需的文档资料已经完整。
测试环境被破坏；
主要功能页面点击错误。
测试环境重新搭建好；
主要功能不会出现页面点击错误的情况。
完成已提交内容所能完成的测试
系统测试
测试环境已经准备好；
系统基本业务流程能走通
无任何功能的页面点击错误；
测试所需的文档资料已经完整。
测试环境被破坏；
系统基本业务流程不通；
任何功能的页面点击错误。
测试环境重新搭建好；
系统基本业务流程可以走通；
页面点击错误问题解决。
测试内容已经完成；
阻塞测试的内容（即测试暂停的产生原因）在短时间内无法解决。
内部确认测试/UAT
测试环境已经准备好；
系统正常功能已正确实现；
业务流程能走通。
测试环境被破坏；
系统业务流程不通；
正常功能未正确实现；
用户很容易重现的严重缺陷产生。
测试环境重新搭建好；
系统业务流程能走通；
正常功能实现；
需要解决的缺陷解决。
测试内容已经全部完成；
PM根据测试报告，认为系统可以满足客户的要求；
PM要求修改的缺陷已经全部修复；
到了时间，系统必须发布。
验收测试
测试环境已经准备好；
客户要求的功能都已经完成。
业务流程可以走通。
测试环境被破坏；
发现需要修改的缺陷。
测试环境重新搭建好；
修改完需要修改的缺陷。
所有要求的测试用例和测试程序都已经执行，并且没有发现新的必须修改的缺陷
性能测试
测试环境已经准备好；
系统的功能正常实现；
不存在影响系统流程的缺陷。
测试环境被破坏；
系统流程存在缺陷；
被测试功能存在缺陷；
程序的版本更新，存在影响系统功能实现的缺陷。
测试环境重新搭建好；
解决影响性能测试的缺陷。
所有要求的测试用例和测试脚本都已执行；
完成性能分析工作。
表二测试准则例子
恢复测试时，一般是需要把前面测试内容重新进行测试，因为会花费较大的工作量，所以测试组长在决定暂停测试时需要很慎重。
在表二显示的集成测试的退出准则中写到“完成已提交测试内容所能完成的测试”，这里的“所能完成的测试”是指，在当前版本所能进行的测试内容，如在系统刚集成时，可进行界面测试，基本模块的基本功能的测试。
上面的测试准则的例子，也不是很恰当及规范，至少缺少了数据度量部分，这里只是拿出来和大家一起交流。
这部分内容我一直认为是很重要的，如果做的不好，测试组的负担会很重。
需要注意的一点是：
测试准则，是在制定测试计划时沟通确定的，它需要和相关人沟通，且得到项目经理审批通过的。
测试准则是固定的，实际处理方式是灵活的。
在实际测试过程中碰到同样的问题，是否继续测试，或者需要暂停测试，处理方式不是一成不变的，这是需要根据项目所处阶段来具体情况具体分析的。
下面举个例子，这个例子是经常性的一种情况。
假设在测试过程中，我们发现了一个阻塞性错误（流程无法继续往下走等类似情况），是否继续进行测试呢？
● 在项目初期，进行单个或多个模块的测试时：
因为可以执行界面测试及熟悉系统，我们可以接受该版本，继续进行测试。
这就属于已提交测试内容所能完成的测试。
在项目测试初期，要求不可过于严格。
● 系统测试：
基本流程必须走通。
如果基本业务流程（主干）不能走通，则需要根据实际情况来灵活处理。
（是否暂停测试或继续测试？
）如果是整个流程的初始节点失效，没有这个节点的数据，后面所有节点均无法进行，那么这种情况下就只能暂停测试。
如果说是分支流程出现阻塞，那么可以考虑继续测试，然后在测试报告中说明该分支未测试。
此时不暂停测试，主要是考虑重新集成一个版本的性价比，也就是是否值得重新集成。
● 发布前的确认测试：
一旦有阻塞性缺陷，马上停止测试。
2.2 测试实施过程
上面说的是测试过程。
下面简单介绍一下我们实际的测试工作。
我们的测试组一般是在项目启动时进入项目组的。
在项目立项时，项目经理会向测试部经理申请测试资源。
经过评估衡量后，测试部经理会安排一个测试人员作为项目测试组长。
当项目启动时，测试组长进入项目，开始了解项目用户需求，起草项目测试计划。
在到了一定阶段，例如测试设计阶段，测试部经理会根据项目规模，项目在公司的重要性以及团队其他人员工作负荷情况，安排其他人进入项目组。
一般来说，我们一个项目是2~3名测试人员。
在项目进入维护阶段时，则是一个测试人员跟进项目。
测试组长根据项目情况及项目阶段计划，定义项目本阶段测试次数。
项目经理参考测试组长提供的测试次数建议，以及项目开发的情况，和项目组各个小组负责人沟通后，定义了系统本阶段版本集成时间。
在我们的项目里，有一个开发人员兼职做集成人员。
在指定的版本集成时间之前的一段时间，各个开发人员将他们的程序提交配置库，由集成人员进行集成（不同语言有不同的集成方式）。
集成后，集成人员会进行简单的自测，验证是否集成成功。
如果集成成功，就在服务器上给该版本程序打上标签。
如果集成不成功，那么返工给相应开发人员修改并重新集成，如此反复直至集成成功。
集成成功后，集成人员会提交一份集成说明给测试组长。
集成说明内容包括：
集成版本路径、版本标签、修改内容、新增内容等。
测试组长则根据预先准备好的测试计划开始测试。
在开始测试时测试组长会通知项目组，告诉他们测试开始，请勿更新测试环境。
测试结束后，也会通知项目组测试结束。
这里要很注意一点的是，对于数据库的更新也需要采用同样的管理，即数据库维护也是需要进行统一管理，避免出现客户环境和测试环境不一致的情况。
在正常情况下，开发组是在预定的集成日期的当天晚上集成，测试组第二天上班后开始测试。
如果遇到特殊情况需要当天集成当天测试的话，我们的开发人员会等到测试组发出测试结束的通知后，才离岗。
如果在完成计划的测试次数后，系统质量仍不稳定或没有达到预期目标的话，那么测试组长将和项目经理沟通，相应增加测试次数。
关于测试用例的执行，我不知道公司现在是采用怎样的一种方式的。
在我原来的团队中，测试用例的主要作用是保证系统功能的测试覆盖率，避免某些功能因为测试周期长而导致测试遗漏。
但是我们也采用经验法、试探法、转换思维的方式进行测试，所以，我们一般使用测试用例执行3~4次测试。
这可能和我们的测试用例设计能力有关。
在缺陷管理上，整体流程基本类似，但是在缺陷分配上，我们测试人员是直接分配给项目缺陷分配专员，缺陷分配专员一般是由业务分析员担任。
缺陷分配专员对缺陷进行分析后，再进行缺陷的再分配。
对于缺陷分配专员处理为不修改的缺陷，测试人员需要进行确认。
如果测试人员不认可缺陷分配专员的处理意见，可以同他进行沟通，或向相关人员（如项目经理）提出自己的意见，最终以项目经理的意见为准。
在系统阶段确认测试前的2~3天，测试组长会将系统未解决的缺陷清单给项目经理确认，并要求项目经理提供缺陷应对方案。
缺陷应对方案在系统发布时，作为项目发布说明的附件。
我们是采用公司自主开发的缺陷管理系统进行缺陷管理的，使用excel、word进行其他测试工件的编写的。
3 如何搭建一个高效的测试团队
俗话说“工欲善其事，必先利其器”，要做好测试工作，首先需要建立并维护一个高效的测试团队。
然而，许多小型软件企业却将测试作为产品面临发布时的一个小“插曲”，往往临时抽调几名程序员对产品的功能粗略测试一下即交付客户（甚至在进度和成本不足时首先砍掉这一块）。
这种仓促完成的产品通常质量问题很多，所以我们首先应抛弃小企业惯常的思维模式，不计较一时一地之利益，立足长远，着手组建高效测试团队。
第一步：
招募测试人员
在国内的软件企业中有一种普遍做法，那就是把那些刚涉足软件行业的技术新手或业绩不突出的开发人员安排去做测试工作。
笔者认为这绝对是一种欠妥当的行为。
事实上，对一个系统进行有效测试所需要的技能绝对不比进行软件开发所需要的技能少，测试从业者甚至可能面对许多开发人员都不会遇到的技术难题。
那么，测试团队需要招募什么样的成员呢？
这里，笔者总结了以下两点：
首先，测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神。
其次，测试组成员应具备良好的专业技能或者技术学习能力。
当然，新招募的测试人员不可能像上面说的那么理想。
关键是他们是否热爱测试这项工作，对相关的工作内容是否感兴趣以及他们的学习能力如何。
第二步：
测试团队制度建设
良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。
相反,则很有可能导致人心涣散，滋长负面风气。
建设良好的测试团队制度，可以考虑以下几个方面：
● 汇报制度团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。
● 工作总结制度成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。
● 奖惩制度对于贡献突出的成员予以奖励，对于业绩差的提出批评，有效地保持测试团队的工作热情。
● 测试件审核制度对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。
● 会议制度定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习平台。
目前，已有不少软件企业推行给测试人员区分级别的制度，奖优罚劣。
这无疑是一个好的做法，但成员业绩的具体考评办法，目前尚无可供参考的标准文件，所以笔者建议应尽量做到公正客观，以免挫伤团队成员的工作积极性。
第三步：
测试团队内部的职责分工
明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学
升级会员 