测试项目总结

2024-05-04

测试项目总结（精选8篇）

篇1：测试项目总结

项目测试经验总结

说明：以下项目测试经验是我在原来公司工作中的实际经验，拿出来和大家一起交流。我相信之前的项目测试工作中有不少可以改进的地方，还希望大家多多交流。

项目测试经验

——Judy Shen

本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及交流。测试团队介绍

在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。

我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。测试团队有6个人，从图一可以看出来，一个人可以参与多个处于不同阶段的项目测试工作。

图一测试团队组织架构

参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。如图二所示：

图二项目组织架构（旧）

上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测试组不进入项目，而是由项目组将测试工作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。

这个模式还在探索中，如图三所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。这种模式需要进行独立核算，包括成本估算、预算、结算等。但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面提到的内容，如果没有特殊说明，都是在旧的模式下进行的。

图三项目组织架构（测试外包方式）

我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！

有着样的说法：“软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。只有两条腿的健壮差不多，走路才稳当。”出于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。例如：

 技术方向：

 功能自动化测试  性能测试  单元测试  测试管理  业务方向：

 物流业务  智能交通  知识管理

但这种方式在工作开展上有些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要挤出时间学习业务知识，在操作上是比较困难的。在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作（如部门制度建设）。当时公司允许我们团队有30%的工作量投入部门建设上。将部门建设工作分开，主要是用于统计部门成本和测试成本用的。

前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种，如表一所示。在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。

角色职责测试管理员

负责测试项目的管理测试过程问题的处理与反馈系统/性能测试组织和计划测试过程状态报告测试设计员测试需求的描述

系统/性能测试用例的设计测试工具、方法的引入测试执行员

根据需要开发测试脚本

按照测试用例、测试脚本执行测试项目测试工作指导测试监督与度量员测试度量

测试过程问题的汇总与反馈开发产品的质量抽检与评定

表一测试角色划分

了解了原来测试团队的分工之后，下面介绍一下测试团队的工作内容。原来的测试团队承接的工作内容包括：

 承担系统测试、用户测试、性能测试；

 进行测试技术研究及培训

其中，测试技术研究，属于提高团队工作技能的工作，在整个部门范围内进行，这里属于部门建设工作；对于项目中的测试人员有可能需要进行，如果项目采用新的测试技术或者测试工具，那么就需要项目测试组成员研究测试技术了，这部分属于项目测试工作。

培训，是指把内部研究的成果在团队内使用，在适当的时机在公司内传播。我们测试团队在2004年开展了21次内部培训，7次公司级培训。因为每个人各有研究重点，所以我们每个人都是团队内部培训的讲师。

说到测试工程师的工作内容，那么就涉及到测试工程师该做的和不该做的。当然这和公司对测试人员定位有关，这里仅指以前的组织。要说该做的，那么我们需要先明确为什么我们要测试？这是因为存在“系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景。在这样的背景下，产生了测试，但是又因为开发人员自己测试自己的东西，难免测试不全面，所以产生了测试工程师这个角色。因此，测试人员他该做的，就是测试软件产品和用户需求不一致的地方，并尽可能多的发现缺陷，能够向项目经理汇报软件质量状态。但是在实际工作中，测试人员经常主动或被动的去做了一些不该做的事情。例如说，测试人员认为自己或者测试能够保证软件的质量，以及有意识或无意识的接受了决定软件是否发布的这个权利。

为什么测试无法保证软件的质量，是因为项目的质量，需要项目组的所有成员共同努力，才能达到质量保证的目的。单纯靠测试工程师的力量，是无法实现软件质量保证的目的。

为什么测试人员不适合承担决定软件是否发布的权利，是因为软件的发布，是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后，由项目经理（或者与会者）做出是否发布的决定。在这个过程中，测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。当然，我知道这两点会有很多人不认同，但是没有关系的。我接触的同行中对两点经常有争论。但是，有一些质量大师等权威人士还是全部或部分赞同这两个观点的，如：菲利普.克劳士比曾在他的书中提到软件质量的保证需要全员努力，需要过程的控制的，而不是某个英雄可以保证软件质量的等。项目测试工作

做了背景介绍后，下面我介绍之前项目如何开展测试工作的。

因为测试过程是整个测试工作的一个纲要，所以首先得从测试过程讲起。

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进行其他测试工件的编写的。

如何搭建一个高效的测试团队

俗话说“工欲善其事，必先利其器”，要做好测试工作，首先需要建立并维护一个高效的测试团队。然而，许多小型软件企业却将测试作为产品面临发布时的一个小“插曲”，往往临时抽调几名程序员对产品的功能粗略测试一下即交付客户（甚至在进度和成本不足时首先砍掉这一块）。这种仓促完成的产品通常质量问题很多，所以我们首先应抛弃小企业惯常的思维模式，不计较一时一地之利益，立足长远，着手组建高效测试团队。

第一步：招募测试人员

在国内的软件企业中有一种普遍做法，那就是把那些刚涉足软件行业的技术新手或业绩不突出的开发人员安排去做测试工作。笔者认为这绝对是一种欠妥当的行为。事实上，对一个系统进行有效测试所需要的技能绝对不比进行软件开发所需要的技能少，测试从业者甚至可能面对许多开发人员都不会遇到的技术难题。那么，测试团队需要招募什么样的成员呢？这里，笔者总结了以下两点：

首先，测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神。

其次，测试组成员应具备良好的专业技能或者技术学习能力。

当然，新招募的测试人员不可能像上面说的那么理想。关键是他们是否热爱测试这项工作，对相关的工作内容是否感兴趣以及他们的学习能力如何。

第二步：测试团队制度建设

良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。相反,则很有可能导致人心涣散，滋长负面风气。建设良好的测试团队制度，可以考虑以下几个方面：

 汇报制度团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。

 工作总结制度成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。

 奖惩制度对于贡献突出的成员予以奖励，对于业绩差的提出批评，有效地保持测试团队的工作热情。

 测试件审核制度对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。

 会议制度定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习的平台。

目前，已有不少软件企业推行给测试人员区分级别的制度，奖优罚劣。这无疑是一个好的做法，但成员业绩的具体考评办法，目前尚无可供参考的标准文件，所以笔者建议应尽量做到公正客观，以免挫伤团队成员的工作积极性。

第三步：测试团队内部的职责分工

明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学，真正做到“用其所长，避其所短”。

第四步：测试流程建设

我们可以通过以下步骤来建立适合本单位的测试流程：

1.测试团队负责人员根据对公司现有测试状况的了解，及个人的测试经验，起草测试流程及相关的模板；

2.通过一到两个项目的实践，记录测试流程草稿中的问题及不足之处； 3.根据实施经验，完善测试流程，得到测试流程初稿，并起草相关实施指南； 4.选择一个到多个项目，实践上述测试流程初稿及实施指南，记录实践过程中出现的问题；

5.根据上述实践工作的反馈，组织修改测试流程初稿及实施指南，并把修改后的测试流程继续应用到项目实践中去，根据反馈进一步完善成熟；

6.测试流程及其相关文件基本趋于稳定状态时，可以考虑发布测试流程（含测试流程、模板、表格、指南），并在以后的实践中不断改进和完善。第五步：团队成员能力的逐步提高

有了明确、合理的职责分工后，需要针对这些分工对团队成员进行有意识的引导，稳步提升团队成员的技能。测试团队负责人需要负起监督和促进员工能力提升的任务。监督和促进测试团队成员能力提高，主要做好如下三个方面的工作:

一是，提倡资深测试人员在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。二是，测试团队应充分利用好测试件知识库，对于纳入到测试团队知识库的测试件应充分消化和学习，在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见。

三是，测试人员除了需要注重自身的测试技能提升，在条件许可的情况还应适度开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。

篇2：测试项目总结

一、项目时间点及各阶段工作

二、测试总结

严重性缺陷占到整个缺陷数量的百分之四十，从实际测试工作来看，代表性大致可分为以下几类：点击“新增”报错、查询报错、保存报错等直观的缺陷。在这里建议研发人员在单元测试发现此类缺陷，在今后项目中，减少缺陷数量，提高软件质量。

中间业务平台管理系统上线阶段：

在管理系统上线阶段共发现6个问题其中有代表性问题分类如下：

1、需求问题：

系统维护->账户维护新增时，账户类型字段是从数据库配置，联社方想通过页面控制此字段。此问题在集成测试时，熬民就提出要从系统页面上新增，当时认为需求没提出此功能忽略了隐性需求导致后期东北农电项目上线需要从数据库大量配置通讯配置表。

教训：今后测试不止测试功能是否实现，需要考虑和结合系统与系统之间的关联关系，眼光放得在长远些。

2、技术实现问题：

篇3：测试项目总结

2014年《国家学生体质健康标准》修订版被誉为“史上最严”, 普通高中、中等职业学校和普通高等学校学生毕业时, 测试成绩达不到50分者按结业或肄业处理。2014年新标准取消沙包、毽子、实心球等上肢腰腹爆发力选测项目, 视力、握力、台阶测试没有纳入评价指标。新标准在身体机能、速度、灵敏协调、柔韧、耐力、力量素质中的项目分配均衡, 测试上肢力量从初中开始男生测引体向上, 而女生仅专注于测腰腹肌肉群协调及爆发力的仰卧起坐, 下肢力量男女共测的为立定跳远。

二、测试项目分析及现场测试注意事项

1.坐位体前屈

分析:坐位体前屈继续保持较高的权重, 从笔者参与的体测现场看, 小学生柔韧度较差, 而高年级的分数有较大增进, 提升柔韧性的好处在于加大人体关节的活动范围和增强灵活性。可以减少或减轻在日常生活中由于动作幅度加大、扭转过猛而产生的肌肉和关节的损伤, 提高生活质量。

注意事项:现场体测的时候, 小学生往往不明白如何使用仪器和规范动作, 需配置绑腿的绷带保持双腿伸直, 同时必须有教师在旁边监督提示。

2.跳绳

分析:跳绳权重在小学阶段比例增加, 作为中国传统的运动项目, 近年来在国际风靡, 它能有效训练个人的反应和耐力, 前苏联研究过跳绳可促进青少年身体发育和骨骼生长, 对心肺系统等各种脏器、协调性、姿态、减肥等都有相当大的帮助。各地体育中考项目中, 实际课程训练比重较高。

注意事项:测试时, 跳绳与仰卧起坐均采用1分钟计时, 在大规模人群测试中, 提升效率的最好办法是10人以上同时测试, 仪器可容许多种跳绳方法为成功次数, 如双飞、交叉跳等, 并且能有效防止作弊行为。

3.短跑、中长跑

从国民体质健康监测的数据看, 中青年猝死增加, 心脏病发、脑溢血、免疫力降低。跑步项目不仅可锻炼耐力, 对心脏循环系统产生有益的影响, 并能提高能量基础代谢, 改善了细胞的营养吸收状况, 使免疫系统得以发挥更好的作用。新标准中所有年级保持高权重不变的为50米跑20分, 初中到大学的中长跑20分, 可见通过长年的数据观测, 跑步对学生体质有极大的提升作用。“恒康佳业”研发的阳光体育健康跑系统, 不仅可统计日常跑步数据, 同时还可以马上计算出心率和耗脂情况, 实现体育课内教学与课外锻炼一体化的全程数字化管理, 充分调动学生参加体育锻炼的积极性。

4.肺活量测试

分析:目前医学界已将肺活量作为监测人体衰老的首选项目, 肺活量检测数值低, 说明机体摄氧能力和排出废气的能力差, 从而导致诸如头痛、头晕、胸闷、精神萎靡、记忆力下降等不良反映, 因此, 肺活量项目可有效的监测人体发育程度, 为制订适当的锻炼量提供依据。

注意事项:在测试时, 为了最精确的反应个体呼吸机能, 测试仪器需要高精度压差传感器和排水功能, 设计要小巧便携, 才能方便小学生使用。

5.男生上肢力量

分析:引体向上基本已经成为多数男生的噩梦, 大多数男生难以达到合格, 引体向上可锻炼握力、上肢和肩带力量, 掌握更多的运动技能, 同时必须克服自身体重, 因此超重的人锻炼这个项目更加困难。可见保持身高体重测试项目、取消握力有一定的道理。

注意事项:在实际测试过程中, 配备监测头部过杠的感应探头与计算空间角度的臂表, 能够有效防止作弊, 也可引领学生朝着目标运动。

三、政策走向

篇4：粉盒品质控制项目与测试方法

设计功能品质控制

1.开盒力测试

开盒力是指消费者打开粉盒的力度，其大致分为两种：一种是打开带有前钮、卡笋、按钮结构粉盒的力，用推力表示；另一种是打开无前钮类、盖底直接卡合粉盒的力，用拉力表示。一般，开盒力主要取决于配合钩子的过盈配合量，配合钩子的角度是影响开盒力的重要因素，当然开盒力也与粉盒的材质有相当大的关系。

测试仪器：推（拉）力机。

测试方法：将粉盒固定在推（拉）力机的平台上，以一定速度施力，直至粉盒打开，此时的数值即为开盒力。不同地区和国家对开盒力的要求也不同，欧美地区要求拉力以2.94～11.76N为宜，推力以4.90～19.60N为宜；而亚洲人用力相对较小，拉力以1.96～9.80N为宜，推力以2.94～4.90为宜。

2.跌落测试

一般情况下，根据粉盒的材质或大小设定跌落高度，硬性、易碎材质的粉盒，以70cm高度垂直跌落至坚硬地面且无部件分离和破裂现象为合格（粉盒打开视为正常现象）。跌落测试与产品及模具设计有密切关系，要注意避免产生应力；部件的牢固度则与所选材质有关。

由于塑胶材质的粉盒性能会随温度变化而改变，因此，此类材质的粉盒在进行跌落测试之前应先进行温湿度循环，即先在高温（55±5℃）环境下放置至少16小时，再在低温（-20±1℃）环境下放置至少16小时，最后在室温（21±2℃）环境下放置8小时。

3.抗压测试

抗压测试主要检测粉盒在关盒状态下的抗压能力，与所选材质的韧性和产品结构有关。

测试方法：粉盒经温湿度循环后，将一块直径为20mm的平板固定在推力机的作用头上，将另一块直径为20mm的平板固定在推力机的中心位置，然后将粉盒正面朝上居中置于推力机上，最后推力机以100mm/min的速度施加压力到规定值，以粉盒到达规定负载时没有破损为合格。

4.后钮（绞链）强度

后钮（绞链）强度是指粉盒在打开状态时，后钮部位能够承受的最大力度，与后钮钉周围的塑胶厚度、应力有较大关系。

测试方法：粉盒经温湿度循环后，将其打开并固定在固定装置上，并置于推力机的平台上（如图1所示），然后推力机以100mm/min的速度冲击粉盒后钮，直至粉盒后钮破裂，此时的数值即为后钮（绞链）强度。

5.后钮（绞链）松紧度

后钮（绞链）松紧度是指粉盒打开时后钮部位的顺畅程度，以及镜盖能否在使用角度内停留。其与粉盒后钮钉的直径、材质，以及部件组装针孔大小有直接关系。从设计上应考虑钉与孔的过盈量，以保证后钮（绞链）松紧度适宜。

测试方法：将粉盒在实验室温度下放置8小时后置于水平检测台上，打开镜盖，并停留在45°的角度，以镜盖在规定时间内不关盒为合格；再将粉盒模拟开盒200次，观察粉盒后钮钉是否存在移位、磨出粉末等不良现象。

6.部件组装牢固度

部件组装牢固度是指两件式组装（超音焊接或卡合）的粉盒经运输及消费者使用后，仍能保持正常状态。

测试方法：粉盒经温湿度循环后，将粉盒其中一个部件固定在拉力机的平台上，另一个部件用吸盘、无弹性细绳或胶带固定在拉力机的钩子上，然后以165mm/min的速度使拉力机平台下降，直至粉盒达到所需拉力或部件分离。

因结构因素而无法采用上述方法测试的粉盒，可将其从1m高处自由跌落至坚硬地面1～3次，以验证其部件组装牢固度是否足够。

装饰性能品质控制

为了达到吸引消费者眼球的目的，大多数中高档粉盒会使用不同的工艺进行装饰，常见工艺有印刷、电镀、烫金等，这些工艺的性能测试备受包装企业的关注。

1.装饰附着性

装饰附着性是为了确保装饰层经运输和使用后不会发生退色现象。

测试方法：将完成装饰的粉盒放置24小时后，用6齿梳子划出25个1mm2的小方格，将测试胶带（3M或NICHIBAN）平贴于小方格上，抚平并停留1min，再将测试胶带以45°～90°的角度大力拉起，以剥离面积小于规定值（根据所选材质和工艺的不同而定）为合格。

剥离面积的计算方法：1个小方格剥离，即剥离面积为1/25（4%）；3个小方格剥离，即剥离面积为3/25（12%），以此类推。

2.耐磨损测试

耐磨损测试是指模拟随机的摩擦现象以及发生在消费者手提包中的机械振动现象。

测试方法：将粉盒放入滚筒（如图2所示）中，按每个粉盒加入20±0.5g铁质填充物的比例，将滚筒动作时间设置为5min，完成动作后取出粉盒，用细小水流将其表面清洗干净，再用软纸巾擦拭干净，然后小心地将测试胶带贴在装饰部位，并用手指压平，1min后将测试胶带以45°～90°的角度大力拉起，将剥离程度与规定剥离限度的样品进行比较，剥离程度小于预定限度为合格。

3.耐光测试

耐光测试是指将粉盒暴露在模拟辐射光源下或存放在展示柜的日光灯反射光源下，粉盒的颜色变化不超过规定的颜色要求。

测试方法：将粉盒置于耐光测试设备（设备结构如图3所示）中24小时，与未经耐光测试的粉盒进行比较，其颜色变化不能超过预定限度为合格。

4.气味测试

使用表面装饰涂料、油墨等材料的粉盒，一旦固化不彻底，容易在热作用下产生难闻气味。

测试方法：将烤箱温度设定为37±2℃，然后将粉盒放入一个5L的密闭玻璃容器（或适合产品尺寸的容器）内，盖紧盖子，在烤箱中放置24小时后，从烤箱中拿出粉盒，并立即打开盖子，尽可能快地闻气味，通常是与以前同类产品测试结果进行比较，气味在可接受范围内即可。

抵御物流环境的品质控制

物流环境是在粉盒开发设计阶段普遍被忽略的因素，如果粉盒结构设计强度与运输包装材料的抗环境冲击力小于物流环境因素的作用力，粉盒就会受到破坏；反之，可能会导致粉盒过度包装。为了达到实际操作上的平衡点，建议根据物流环境因素来分析。

物流环境因素主要包括两大方面：一是运输过程中的跌落冲击，陆（空）运过程中的振动，存储时的堆叠，长距离运输过程中的环境温湿度和压力变化等；二是高低温环境对粉盒尤其是塑胶粉盒性能产生的影响。

根据上述物流环境因素，给合实际案例，可将以下几项测试项目作为开发新产品的参考依据。

1.温度测试

测试方法：以出口欧美市场、采用海运时最高温度为57.3℃为例，在该运输温度条件下，产品的基本性能（如部件组装牢固度等）是否下降。

2.振动测试

测试仪器：振动测试仪、带有水平侧边的振动平台、满足旋转或垂直水平负载运动的机构、可调整速度/频率的振动发动机。

测试方法：将产品包装箱以正常的运输方位置于振动平台上，并将振动速度设定在250rpm或等同的9.8m/s2加速，持续振动1小时；在没有测试仪器的情况下，可进行模拟运输测试，以江浙沪公路状况为例，要保证不低于200公里的运输路程。

3.跌落测试

测试仪器：跌落测试仪。

测试方法：从0.76m高处跌落至坚硬地面，分别对产品包装箱的底平面、顶平面、长侧面、短侧面、胶黏结处的底角、短底边进行跌落测试。

4.产品变量测试

从粉盒成品下线到消费者实际使用，受各种物流环境因素的影响，粉盒相应的功能性品质会产生一定变化，我们称之为“变量”。

测试方法：在温度为60℃、湿度为70%的环境下，在面积为0.25m2测试平台上放满粉盒测试样品，并在10kg的重量下加压48小时。

实际上，对粉盒品质控制项目的选择，一般都会按照不同的结构和加工工艺来确定。总之，包装企业应以消费者的舒适度为宗旨，对粉盒进行合理的品质控制，并确定相应的品质控制项目，这样才能找到粉盒品质和成本之间的平衡点。

篇5：XXXX项目个人测试总结大纲

1.1 非错问题分析 1.2 交叉测试遗漏问题

1.2.1 逐一分析

重点为第三轮

其他测试人员提出自己的模块的问题

1.3 测试用例

1.3.1 没有直接关联BUG的测试用例分析

1.3.2 测试用例执行遇到的问题

1.4 Keep 1.5 Problem 1.6 Try 2 项目总结

篇6：测试项目总结

[ 实验日期 ] 年月日

[ 实验目的 ]

测试程序，总结缺陷数据。

[ 实验内容 ]

填写测试表，填写缺陷分析表

[ 实验原理和步骤 ] 按等价类+边界值设计测试数据，并记录测试结果；填写缺陷分析表并按类型排序.[ 实验报告要求 ]

《学生填写》测试表《学生填写》缺陷分析表

[注意事项]

[ 实验总结 ]

① 对重点实验结果进行分析；比如自己常出哪种错误

② 实验中的问题和提高：对老师或自己的编码进行评价，指出合理和不足之处，提出改进的方案。

③ 收获与体会：

《学生填写》实验总结

附录一：测试表

篇7：银行性能测试项目小结

本次性能测试的系统是X银行营销服务系统总行版，该系统使用的数据库服务器、应用服务器均布署在总行机房，各地分行通过 WEB 方式登录访问本系统。系统上线后的总用户数（包括各分行、支行主管，客户经理等）在 5000 左右。

该系统采用 DB2 数据库、WebLogic 应用服务器。

本次性能测试进入的条件是系统的代码已经基本完成并经过功能测试。

2、测试计划

在确定了本次性能测试的要点后，我们初步拟定一份性能测试计划，提交给客户，并获得了客户的认可。在本文中不列出项目测试计划中的所有内容，仅就主要问题进行说明。

测试范围：在真实业务局域网测试环境下，对系统实施并发性能测试的同时，监控 Web 服务器和数据库服务器的系统资源，以及数据库资源的使用情况。

测试内容：并发性能测试、系统资源监控。

测试方法与工具：采用自动测试与人工测试相结合的测试方法，测试工具使用 LoadRunner。

测试资源：测试环境及测试数据准备。

3、测试用例

确定了测试计划，我们针对该系统的特点，从中挑选出三个有代表性的功能点，作为本次性能测试的用例。我们认为作为银行的营销服务系统，最常使用且对于系统的整体性能有着较大影响的是“客户信息查询”和“客户对账单查询”两个模块。因此，我们设计了三个单交易性能测试用例，分别是：“用户签到 / 签退”、“客户信息查询”、“客户对账单查询”。然而客户却对此提出异议，他们认为我们设计的测试用例数量太少，要求我们的测试用例应包含更多的功能模块。经过会议讨论，最终我们根据客户给出的一份性能测试大纲，针对其中提出的测试内容、测试策略，以及测试目标，将单交易测试用例增加到十四个。

测试用例采用以下格式：

要求清晰地描述出详细的操作步骤。

4、测试数据

针对以上设计的测试用例，需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境，所有的业务数据均来自兴业银行的真实核心系统（通过 ETL 转换），数据量已经能满足测试的需要。

由于测试用例中要求执行并发操作的时候使用不同身份的用户登录系统，因此在测试开始前需要准备一批具有不同身份的用户名（包括各分支行的主管以及客户经理），并且要有相应的操作权限。

对于“积分转移”、“积分兑换”、“礼品兑换”等等交易，则需要提供一批卡上有足够积分的客户理财卡号。

以上测试数据由兴业银行负责提供，在性能测试执行之前提供给我们。

5、测试脚本

使用性能测试工具 LoadRunner 录制并调试测试脚本，对相关的输入项进行参数化。

6、测试实施

在 LoadRunner 中执行测试脚本，实施性能测试。对于每个单交易测试脚本各执行一轮测试，并按一定的用户比例设计出一个混合交易场景，令其自动持续运行五小时左右，观察系统的性能表现。每次执行的结果文件均保存下来，待测试完成后连同性能测试报告一并交付客户确认。在此过程中，需要监视相关的系统资源使用情况，包括：应用服务器和数据库服务器的所有系统资源指标，所有数据库资源指标。

7、测试结果

经过本次性能测试，发现了系统五个主要的性能问题。我们与程序开发人员一同分析问题产生的原因，并给出改进建议，一起记录到测试报告中。其中的一个问题在性能测试报告提交客户之前已经过优化，得到显著改进。

8、测试结论

测试结果显示，系统性能能满足测试目标，交易并发数达到或超过30个，批量交易（查询记录50条以上的交易）并发数也能达到或超过10个，交易平均响应时间在2－12秒内，90％平均响应时间在2－15秒间完成。

混合交易案例持续运行 5 小时，运行结果正常，系统没有报任何错误，系统稳定，可用率应达到100％。

另外如在ETL批处理期间运行营销服务系统，系统性能明显下降，建议ETL批处理在夜间处理，避免影响系统的正常运行。

9、经验

在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：

问题一

在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史” 这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于 LoadRunner 不提供像 WinRunner 或 QTP 一样识别页面对象的功能，如果在 Vugen 中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可（因为我们关注的只是系统的性能，不是功能），而不必像功能测试那样，按部就班地重现每一步操作。

问题二

在测试过程中，我们发现有一个查询交易的系统响应速度特别慢，无论是在 Controller 中使用单个虚拟用户执行脚本，还是在 Vuser 中直接运行，情况均是如此，然而当我们用手工进行同样操作的时候，响应时间却明显地小于工具统计出来的时间，也就是说，在 LoadRunner 中模拟操作的结果与真实操作的结果明显不一致。经过反复尝试与观察，我们才终于找到问题的原因所在：该查询交易是通过客户的证件号码查询客户信息，当用户输入客户的证件号码时，如果没

有选择证件类型，系统会自动将证件类型设置为默认值“身份证”。按“证件类型 + 证件号码”为组合索引查询客户信息表，查询速度极快，而在我们录制脚本时，忽视了“证件类型”这项输入，只有“证件号码”，因此查询的效率大为降低。解决办法：只需在测试脚本中，对 CertType（“证件类型”）一项赋值为“ A ”（“身份证”），此时在 LoadRunner 中重新运行该脚本，响应速度提高，统计结果与实际完全一致！

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们在测试脚本中组装发送到服务器端的报文时，注意一定要和实际操作时的发送报文完全一致，这样才能保证测试的结果与真实情况相吻合。这就要求在测试正式开始执行时，要对测试脚本进行反复的调试，通常的做法是：在 Vugen 中执行一遍脚本，统计执行某个事务的时间，再用手工实际做一遍同样的操作，大体上比较一下，确保与实际估算的时间没有太大出入后，再逐渐增加并发用户数，正式开始性能测试。

问题三

在我们的每个测试脚本中的 init 部分，都录制了登录系统的操作，并且对登录的用户名进行了参数化，使用各种不同身份的用户（分行主管、支行主管、客户经理等）进行相同的操作。在并发测试过程中发现对某些查询交易测试的结果波动较大，系统响应时间从零点几秒到几十秒不等。经检查后发现原因在于：使用不同身份的用户登录系统后，在输入查询条件后，点击查询按钮后会将根据该用户的身份，将其所属的分行机构号、支行机构号、客户经理编号等一并提交，因此在脚本中，就必须根据不同的用户身份，分别将其对应的分支行机构号等也运用参数提交，否则在执行脚本时就会出现查询不到记录或查询速度变慢等各种问题。解决方法有三个： 1、修改脚本，使其能够依据用户的身份分别传送相应参数，2、针对不同类型的用户使用不同的脚本分别测试。3、输入参数使用统一的用户类型。在实际中，我们为了简化脚本的复杂度，节省对脚本编程的时间，采取的是第三种方法。

结论：由于 LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，因此它会跳过在应用程序前台进行的校验，所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制，以保证发送报文的正确性（如操作权限的控制等）。

问题四

测试多用户并发登录系统的时候，从虚拟用户图和事务图上发现，总有一部分用户在登录的时候要等待很长时间，用户登录的最小时间与最大时间相差非常大。于是我们在让脚本自动运行的同时，手工再登录一个用户，发现无论如何都不会发生等待的情况，多次试验的结果均是如此，也就是说 LoadRunner 测试的结果与实际结果再次发生了偏差！经过反复的调试，以及与程序开发人员沟通，我们终于发现问题的原因所在：在用户登录系统的时候，系统会自动记录登录用户的信息，并产生一个登录 ID，以此 ID 做为主键，向数据库插入记录。因此当大量用户在极短的时间内同时登录时，就有可能出现生成相同的登录 ID 的情况，此时便会造成数据库中的主键冲突，导致用户等待很长时间或登录失败。而我们手工测试时却无法做到在很短的时间内同时登录，因此很难用手工重现此种

情况。通过 LoadRunner 的模拟表现出来的状况，正是我们测试出程序存在的性能问题，并非与实际结果的偏差。

还有一个例子，在第二轮性能测试中，同样发生了类似的情况。在本系统中，如果同一个用户登录后，未正常退出超过 5 次，系统将会把该用户锁住，使其无法再次登录，而我们用于参数化的用户名个数有限，因此当脚本使用大量用户同时登录时，很容易造成同样的用户登录系统而未签退的情况发生（脚本正在执行，还未能退出），此时将会造成许多用户操作的失败。

结论：使用 LoadRunner 可以模拟出大量用户同时对系统操作的情况，而这些情况通过手工往往是很难重现出来的。例如大量用户在同时对系统做某些操作时，很容易造成数据库的死锁、锁等待、主键冲突、数据混乱等等问题，因此在做性能测试的同时，也常常可以连带测试出系统的一些隐蔽的“缺陷”。在本次性能测试中，这种例子是很多的。对待此类“缺陷”，应具体情况具体分析。有些确实是程序的 BUG，需要修正，而有些可能只是很极端的情况，只有在做压力测试时才有可能发生，可不必深究。

问题五

此问题发生在第二轮测试（即回归测试）中。在第一轮测试中发现的性能问题，经程序员修正后，我们对系统进行了第二轮性能测试，以验证其性能改进的效果。在前一轮测试中，我们发现通过选择客户级别为“未评级”时，查询的速度极慢，经过改进后，速度应有较大提高。然而在回归测试中，却依然很慢。经过对测试脚本和程序的仔细检查，才发现原来在程序中已将“未评级”这个选项去除，而我们的测试脚本的参数文件中仍然保留有该选项，因此测试的结果与前次没有区别。在参数文件中将该选项去掉后，测试结果正常，查询效率有所提高。

结论：使用录制好的测试脚本进行回归测试之前，一定要先仔细检查、了解程序的改动，对原先的测试脚本做必要的修改后，才可以重新测试，否则只是在做无用功。

10、教训

在本次测试过程中，由于经验不足，我们也得到了一些教训。前事不忘，后事之师，现总结出来与大家分享。

l 与客户的沟通做得不够，客户要求我们做的性能测试用例数量太多，我们未能据理力争，最后导致工作量过大。

l 按照原定的项目计划，我们要在系统的功能测试即将结束前进驻项目组，准备并进行性能测试。然而由于客户在功能测试的后期仍然不断的提出新需求，导致开发人员疲于奔命，系统的性能难以稳定下来，性能测试的前期准备工作也受到很大影响，不能正常开展，浪费了很多人力物力。

l 由于客户无法提供一个单独的性能测试环境，我们的性能测试工作与业务组的功能测试在同一个环境下进行，而系统的功能测试迟迟未能完成，加上 ETL（数据转换）小组对数据库资源的占用，因此我们的性能测试只能在夜间才能进行。导致时间上的浪费，使项目的成本增加。

l 没有将性能测试中发现的缺陷记录到缺陷管理工具中加以跟踪，而仅仅体现在最后的测试报告上，个人认为这是比较不规范的做法。

l 性能测试前的数据准备不够充分。客户提供测试的系统用户、身份数量有限，导致许多案例的测试只能使用少量数据进行参数化，由此带来许多本可以避免的问题。

l 测试计划及测试报告的书写格式缺乏规范，尤其测试计划书未能包含本应包含的所有内容。

l 在我们将 LoadRunner 的测试结果文件全部提交给客户的前提下，客户仍然要求我们在测试报告中将每一次测试的数据均以表格的形式填至测试报告中，此项工作的工作量十分巨大，个人认为这样做并无必要。

篇8：测试项目总结

目前, 第一批将加入电磁兼容测试要求的广播电视行业标准如下:

GY/T 229.1-2008《地面数字电视广播单频网适配器技术要求和测量方法》

GY/T 229.2-2008《地面数字电视广播激励器技术要求和测量方法》

GY/T XXXX-2008《地面数字电视广播发射机技术要求和测量方法》

其中规定了五类电磁环境, 这五种类别的电磁环境描述如下:

E1:住宅区 (包括:IEC 1000-2-5中的区域类型等级1和等级2)

E2:商业区和轻工业区 (例如剧场等)

E3:市区户外 (基于IEC 1000-2-5中区域类型等级6的定义)

E4:受控EMC环境 (例如专业广播站或录音棚等) 和农村户外环境 (远离铁路、发射机、架空输电线等)

注释:一些演播室环境相应于E2。

E5:重工业区 (参见EN 50081-2) ;如广播发射机附近的环境

一般认为诸如广播电视演播室、各地广播电视中心机房属于E4级别, 而放置有放大器、发射机的广播电视塔站的机房属于E5级别, 对运用于各类环境中的广播电视行业专用设备, 不同环境级别所对应的限值集也有所不同, 详细参数见表2及表4。

2 广播电视行业专用设备EMC测试标准

广播电视行业专用设备的EMC测试标准制订过程中, 着重参考了文献[1][2], 其测试方法引用了国际标准对应的国家标准, 如GB 9254、GB 17625系列标准与GB/T 17626系列标准[14,23]。广播电视行业专用设备EMI与EMS的具体测试项目、测试方法、限值集或性能评定等参见表1～4, 其中E1～E5分别对应第1小节中的不同环境分级, “说明”中注明了该项测试是否将作为入网测试中的必选项。

需要说明的是, 截至本文发稿时, 相关标准的制订尚未最终完成, 广播电视规划院电磁兼容与安全检测实验室正在就测试项目、方法和限值做实际的测试评估, 根据这些测试结果和评估, 最终标准中的测试项目、限值可能会有所变化, 一切以最终的标准内容为准。

2.1 EMI测试项目、测试方法及限值

对于广播电视行业专用设备, 各端口的EMI现象可分为以下10种:

a) 外壳端口:射频电磁场, 30MHz～1000MHz;

b) 外壳端口:磁场, 50Hz～50kHz, 在距离10cm处测量 (机柜设备) ;

c) 外壳端口:磁场, 50Hz～50kHz, 在距离1m处测量 (非机柜设备) ;

d) 交流电源端口:传导发射;0Hz～2kHz谐波电流;

e) 交流电源端口:传导发射;受设备电源影响的电压波动;

f) 交流电源端口:传导发射;0.15MHz～30MHz;

g) 交流电源端口:传导发射;不连续干扰, “咔哒声”0.15MHz～30MHz;

h) 交流电源端口:传导发射;瞬间电流;

i) 广播、无线电设备和电视接收机天线端:传导发射;30MHz～1000MHz;