一个工作流测试项目案例

第一篇：一个工作流测试项目案例

本文以一个工作流测试项目为例，总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位，XXX5.2Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况：

● 项目规模与

○ 项目代码行数：5万行

○ 开发人员配置：开发人员5名、实习生1名

○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名 ● 项目测试时的系统部署情况:

● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。

测试如何尽早介入

基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：

● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。

● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：

● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。

● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是

测试用例的保证。

● 和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。

● 开发人员每天下午4：30之前提交所有可编译的代码，每天晚上进行日编译； ● 开发经理根据版本稳定情况，每周提交测试申请单。

● 测试人员根据测试进度需要，提取测试版本。

● 提前准备测试环境，包括和应用服务器，以及复杂集群环境。

● 如果项目需要，还可以在此阶段研究一下自动，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。

产品开发期同情的测试

要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：

● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。

● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。

产品成熟期积极的测试

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

产品稳定期多样的测试

在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测试、探索式的测试必不可少。产品发布期谨慎的测试

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

来，基本上有以下几种情况：

● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本就不能使用，如果进一步测试就是浪费时间，我们立即打回了这个测试版本。● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也就是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后就会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合： ● 负责提供冒烟测试案例。

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

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

● 主动出击，提供服务 ○ 在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务：○ 对工作流的运算逻辑?构件进行了测试，方便了后期开

发工作流客户端应用的使用。○ 对内部版本和原?型进行测试。○ 对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。○ 帮助程序员建立测试环境，方便程序员进行测试。● 耳目作用

○ 在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身，及时验证和发现项目环节中的问题。总之，测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人的帮助和支持，以及认可。

全部脚印 不留脚印 留下脚印:

第二篇：项目测试经验总结

项目测试经验总结

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

项目测试经验

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

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

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

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

第三篇：软件测试一个项目的项目总结[小编推荐]

由安博测试空间技术中心http://www.xiexiebang.com/提供

因为需求写的十分详细，所以方案也十分详细。在这期间还专门写了一个针对脚本名称、事物名称、场景名称、结果名称的命名规范。事实证明这个命名规范对后来的测试数据整理起到了巨大的作用。在书写方案的过程中体现了模板的重要性，我建立了一个模板，然后大家都按照我的模板来写，这个阶段虽然漫长但也倒还算是轻松。只是对几个专有名词的概念做了一下统一，其中比较明显的就是“并发”这个词。为了给用户系统负载比较大的感觉，我们将并发的单位变成了每分钟多少用户，这样做实际是不正确的，给后期测试带来的了很大麻烦，经常要考虑实际并发用户到底是多少，应该如何换算。其实“并发”这个词并不是一个时间段的概念，而是瞬间的概念，衡量一个时间点上用户数的多少。另外，在整合的时候还出现了一些小问题，在文档写作的细节习惯上并不能完全的统一，造成我在把所有别人的方案拿过来的时候还要花很多时间调整格式和内容以达到文档的统一和美观。进行两次方案的评审，评审进行的还算顺利。2)

经验

命名文档十分重要，对后边的数据整理起到了巨大的作用。在比较大的工程里，最好几个人要经过研究共同制订一个命名规则，这样大家都遵循这个规则去命名，可以在同伴不在的时候很容易明白他的某一个脚本或者结果的用途。

测试方案可以写的尽量详细，当然要在用户或者领导不检查是否完全按照方案执行的情况下。本次测试中方案写的十分详细，脚本详细到每一个操作，需要监控的事务都标注的很清楚，场景详细到多少用户、执行时间、并发用户数和集合点，有些还加上备注说明，写清楚为什么添加这个场景，在何种情况下会出现此场景的情况。这使我们在后边做执行的时候很容易了解到当时写这方案时的思想，有些东西可以直接拿来用而不用再思考一遍。

在书写方案的时候，如果几个人一起书写的话，一定要事先尽量统一书写的格式和方式，不然在整合的时候会十分的麻烦，要调整很多的格式。另外整合的人要十分认真，按照我的经验至少要来回看文档三遍。第一遍看整合的格式是否一致，是否有漏掉的不一致的地方，包括各个标题的格式、内容的格式、字体、字号等。第二遍看错别字，在自己的能力范围之内尽量找出文档中的错别字，这种低级错误有时候会影响看文档人对写文档人的印象。第三遍看标点符号，要统一文中各个位置的标点，尤其是表格等，填写的时候是否有标点。三遍都看完之后，还要叫来大家一起来重新看文档，提意见，然后进行修改，互相之间看文档的时候还会发现一些问题或者突然提出不同的建议，可以使文档更完美。这样的过程再进行两遍，我认为这样的文档才具备可以提交给相关部门的条件。大家不要怕麻烦，文档是一个测试人员入手的项目的第一件工作，是脸面，一定要做好。如果有能力的话，最好在书写测试方案时同步进行脚本可行性分析和数据需求的整理。脚本可行性分析可以不用录制脚本，不过尽量操作几次录制脚本的流程，观察是否还存在功能问题影响脚本录制，看是否存在技术瓶颈或测试困难，提早进行技术的补充或者想想绕过困难的方法，是否有可替代的方案。这里面尤其注意到很多宏观的问题，比如当前所拥有的测试资源，测试机的数量，是否可以运行如此多的用户，是否有带宽瓶颈，如果有如何处理等等。还有对可以预见的数据尽早提给开发让开发准备，对后期的工作会有很大的帮助，不用到录制脚本时再提数据准备，开发再准备几天，这样会影响测试进度，给开发短时间制作数据的压力，也会影响和开发的关系。

在做方案的同时，同步制定可行的测试计划，如果时间充裕最好准备两份，一份是充分测试所需要的时间，一份是在项目紧急的情况下所需要的时间。这里可以不要写出具体执行的时间段，因为这是测试人员自己不可控的，只要写出所哪一项工作具体需要的时间就可以。这样做的目的是便于后边工作量的计算。计算出工作量，就可以更好的控制项目的进度不至于因为某一个困难耽误了整个项目的进度。在测试执行开始之前，测试方案最好根据需求的更新进行同步更新，在执行开始之后，如果没有时间可以暂时放下。因为本人有记日记的习惯，所以一般一项目下来哪里是如何做的都有记录，如果最后要一个真实的方案也能拿出来。用户一般在评审后就不会要求文档同步更新，而且一直维护一个或者多个文档会耗费大量的工作量，不建议在测试执行时还进行文档的维护。方案是对测试起到指导的作用，如果执行时还要对方案进行更改就有点形式主义的意思了，不是吗？不过在有重大变故的时候，比如某一个大的模块都进行了更改或者删减增加，最好做好记录或者简单的更改方案，方便以后查阅。4.测试执行

测试执行分四个阶段大概用了两个半月的时间，四个阶段为三个阶段对三种优先级的测试点进行测试，最后一个阶段进行回归测试和大型综合场景测试。分别阐述。1)

第一阶段（测试优先级为极高的测试点）第一阶段对测试优先级为极高的进行测试。对极高的点的定义为在整个系统中几乎每个子系统都要用到的通用代码和比较重要的审查流程中所涉及到的点。最主要的就是审查流程中Y的审查和X的审查及通知书，在这里不过多阐述，只描述测试过程遇到的问题及解决方法。首先在测试X时发生一个这样的情况，在测试的过程中要从网络上下载下来一个文件，这个文件最终由IE调取word的控件打开。我测试的时候，我找到这个文件的数据被从网络上下载到本地的证据，因为这里流量十分重要。但我始终找不到被下载下来的日志，打开详细日志也没有找到，然后找开发进行沟通，未果。这时候JJ说的一句话提醒了我，她说这个应该是FTP下载，我马上想到FTP是不包含在http协议中的。然后用他们两个组合的多协议方式进行脚本的录制，确实在脚本中找到FTP下载的请求和响应，并且被下载文件也已经下载到了本地。然而下一个问题又出现了，在人工操作网页时被打开查看的文件的大小为13K，而在FTP日志下显示出的大小仅为2K。找到开发后才了解到，实际上为了减少网络流量，在服务器段存储的都是zip包，在客户端需要某一个文件时，其实是在服务器上要了一个zip包从网络传到本地。本地的IE再用js将其转换成一个xml文件，然后另一个js文件再将此xml文件再转换成为一个word文件，再用IE将其打开。最后被转换成word文件的时候，它的大小才是13K，之前被从网络上下载到本地的是只有2K的zip包。而在这个过程中还有一个问题从一开始捆饶了我，在证明了这件事情之后，我信心满满地加了事务测试之后，发现从下载文件到打开的时间是7秒到8秒。因为过慢，于是仔细查看脚本中的请求，想从中发现是哪一个请求占用了过多的时间，发现在这个事务的中间有一个7秒的thinktime，后来经过一翻周折，发现其实七秒的时间是在zip包下载到本地后进行若干次转换及打开的时间。在录制的过程中因为我中间没有进行实际操作，而LR没有录制到数据在本地转换的过程，在转换结束之后客户端才又与服务器进行通信，所以中间被录制下来thinktime了。而这一点又延伸出来一个问题，我在测试的时候是使用的两页的文档，如果是更多页的呢，不用太多，十页的话这个时间也许就要翻番了吧。不过经过一番艰苦的思考与问题排除后，终于完成了第一个重要测试点的测试工作。

在刚刚进入项目和刚刚写完测试方案的时候，我们都在S采集那里进行的脚本的可行性实验。比较有趣的是在两次实验和这次正式测试的时候，逻辑一直在变，所以三次的脚本都是不可复用。值得记录的是其中的一次脚本在运行过程中是要人工输入数据的，这个数据不可重复。于是我用autoit做了一个专门生成参数表的脚本，每次都在可控制范围内生成一个参数列表。也许有人说LR可以做数字的，那如果系统要求都是字母呢，其实用autoit也可以完成的，只要做一个26个字母的数组，然后按照一定的规律进行组合就行了。

对W子系统的测试中，出现了一个很有意思的问题，测试需要我们下载图片。但在下载图片的过程中，我看到了日志上所下载的图片的数量，在显示器的网页上去看不到图片。在系统默认的文件夹中也看到了被下载下来的图片。于是探索这个问题，后来问了测试人员才知道，原来图片被下载下来后已经被查看了，只是这个系统是要求双屏的，图片被显示在副屏中，后来JJ经过一系列键盘的操作，终于在屏幕边缘把图象拉了出来。做到这里突然想到一个问题，就是以后做性能测试的时候，一定要注意脚本和手动操作的一致。前边发生手动操作后因为FTP的问题没有把文件下载到本地，现在又发生脚本下载到本地的东西没有显示。以后在测试的过程中一定要注意这一点。

对Y的测试更是一波三折。因为Y要求的最终用户是12000，而大家都知道LR所支持的最大用户数为10000。如何做，想到了T的理论，于是进行了忽略thinktime的转换，转换完测试的用户数仅为300和600。但是在测试时出现了登陆等事务的响应时间过长，因为临时有事出去了两天。两天之后回来再思考这个问题的时候突然发现其实是带宽占满造成的。于是开始寻找网络瓶颈，在多次测试后发现，在不忽略thinktime的情况下800个用户就会占满带宽100M。问题来了，如果这样推算的话，是否能够推出8000个用户就要占用一个1000M的网呢。后来与相关人员沟通，需要排除所有的网络问题，到服务器边上进行直连的测试（因为未来的使用环境是1000M的网，现在我们使用的是100M网）。在等待疏通的时间里，又做了另一件事，就是寻找忽略与不忽略thinktime的用户比例。方法是先设定一个数量的用户数进行不忽略thinktime的测试，记录下来TPS，然后进行忽略thinktime的测试，逐渐变化用户数来找到相同TPS的用户数。但事实并没有像想象中那么简单，最后测试结果发现用户数和TPS的比例是个变化的曲线（认为在服务器没达到瓶颈时应该是个相对稳定的值）。假设50个用户时的TPS为50，到测试25个用户时，因为用户数量变少了，服务器处理变快，很可能25个用户的TPS为30，再减少也是这个样子，所以要找到这个用户数还真是一个困难。虽然可以在多次的测试中找到那个值，但这只对本脚本的这个用户数有意义，既然比例是变化的，那就不可以用在更多的用户数的转化上。就在这个时候，第一阶段的时间结点到了，不得不放下现在的测试，书写第一阶段测试报告，于是Y的神秘问题被留到了第二阶段进行。本帖最后由 fairyox 于 2009-9-7 16:51 编辑

2)

第二阶段（测试优先级为高的测试点）

第二阶段主要对测试优先级为高的点和在第一阶段因为某写原因没有测试的点进行测试。测试优先级为高的点的定义为不是整个系统的通用代码却在本系统内部及审查流程中起到重要作用的测试点。

进入第二阶段后，第一个重要的任务就是第一阶段没有完成的Y问题。要解决带宽瓶颈和多少用户数进行测试的双重问题。带宽要到服务器机房进行测试，而用户数是通过再一次的需求明确解决的。在发生了用户数的问题之后，我们再一次寻访的Y方面的用户代表，后来了解到每个人每天平均也就做一件案子。而我的脚本是几分钟就要做一件案子，于是这个时候我提出了一个理论，用业务量平衡的方式来进行场景压力的设置。12000两千个用户要做12000个案子，那么我无论上多少用户，只要让他们在规定的时间内做完12000个案件，这个时间范围小于一天的工作时间八小时，就应该给足了压力。而我们将这个时间定为半小时，具体的用户数转换与计算方式详见《Y性能测试方案》，为进行本子系统的测试专门书写的一个简单的测试方案。

在Y的这个点的问题解决之后，我们又迎来了下一个问题。前边说过，为了减少网络传输压力，好多的东西都是被压缩成zip的形式传输的。这里就出现了下一个问题，我们要在本地修改文件然后上传到服务器。在LR中录制出来的是码流，看起来就是乱码，不能够对上传的码流进行修改，乱码看不明白。连续两个点都是这样的情况，经过多次努力，未果，放弃对这一类点的测试。

对L子系统的测试是固定了数据的，只有这么多，用没就没有了。只许成功，不许失败，还好，经过多次的仅用几个数据的试验。最后在跑场景的时候没有让自己失望，虽然跑出了响应时间较长的事务，但脚本本身和参数设置都没有出现问题。

在进行P子系统测试的时候，数据准备成了最大的问题。这个子系统因为和国外的专利数据有连接，所以数据特别复杂，开发很不愿意给准备。后来找到了项目经理给沟通开发才答应给做数据，这个子系统的测试因为数据问题拖延了好几天。

其他子系统的测试都进行得比较顺利（没有遇到技术困难，但有可能出现性能问题），其中包括X、G、F、实用V。最后一个星期是到专利局机房进行测试，两个目的，第一是完成Y的测试，第二是要进行一次小规模的综合场景测试，保证第二次用户测试的顺利进行。到专利局机房测试第一件事就是做Y那个有带宽瓶颈的点的测试，当用户数上到850的时候服务器出现问题，大量的事务失败，但也有成功的。查看服务器日志，报出错误为too many files open。若干高手研究了一天的时间，包括weblogic的售后服务人员、系统组组长、软件研发中心成员、小型机售后服务人员都在研究，一直到晚上八点才完全将此问题解决。其中修改了四个参数才完全解决这个问题，在这里不想写出这四个参数，本人认为这四个参数并没有完全起到作用。网上也看到一些关于这方面的帖子，写的修改方式也不完全符合我们这次所修改的参数，所以估计要很多的参数共同作用的结果。再发现这问题的时候要具体情况具体对待。

解决了这个问题之后又继续进行了测试，用了一夜的时间，最后将小型综合场景设置并跑起来之后才去睡觉。早晨起来看测试结果。在分析之后发现了一个很难发现的情况，在测试机中有一台测试机自己的性能成为了瓶颈。在响应时间图上表现得十分清晰，这是一个宝贵的经验，如果不是有几台不同性能的测试机做对比，很难发现是测试机本身造成的瓶颈。在未来的测试中一定要注意这一点。

在这时还进行了一次我们所谓的最大连接数的测试，测试方法是上12000个用户，没隔一个固定的时间每个用户向服务器发一个请求要数据。后来在学习中发现这并不是测试了最大连接数，只是测试了服务器上可以存活12000个以上的session。这里还有一个小插曲，专利局方面让我们测试防火墙。我用7500个用户大数据流量的方法给他测试了，但是他并不满意我们的测试方法。最后这事属于不了了之。其实一开始就不应该答应他，如果要进行测试必须要有详细的需求。犯了和在北研测试网盘一样的错误，在需求不明确的情况下就开展了测试，结果当然不可用。以后要注意这一点，需求的明确是一个技术工作的入口，没有需求就是没有入口的工作，无从下手。3)

第三阶段（测试优先级为中的测试点）第三阶段测试优先级为中的测试点。对测试优先级为中的测试点的的定义为每个子系统内部经常用到但和审查主流程关系并不十分密切的测试点。在这个阶段测试的时候事情比较杂，因为所涉及到的测试点重要程度已经比较低，所以经常会有实在不行就放弃的方式来处理被测试点。

在做P脚本的时候出现了一个情况，脚本十分复杂，可能需要做很多的关联才能跑通。而开发来了之后十分的不配合，无论说什么都不好好的回答，至使我很难有效的调节脚本，最后以功能问题的名义放弃。

在做P电子公报袋时得到经验，对于关联ord=all设置取出一个数组的情况，只要后边用元素后面加下画线加数字的方式就可以直接使用被取出数组中的元素。用下画线加count的方式可以代表数组元素的个数。

4)

第四阶段（回归和综合场景测试）在做回归之前还小小地做了一下D的测试，因为是CS结构，所以还比较麻烦。先使用http协议录制脚本，结果录制出来的东西没有太看明白，找了开发来帮助也没有解决问题案件不能上传。后改用winsocket的协议录制，但录制出来的脚本回放就会LR脚本编辑器停止响应，无奈放弃。再后来用录制手动操作协议录制脚本，仍然无发调整，最后终于放弃努力。这里可能是需要LR调取客户端的东西了，但我不懂这一块，没办法更换测试方法。本来计划只做不停地请求，然后发一批案件的包上去让服务器自己处理。但是发了3000个包上去之后，服务器后台被某开发改动，没有具备环境。第二天在打开的时候，因为批处理服务器有我们上传的3000个案件要处理，反应速度很慢。被开发停止，结果一次无效的D测试宣告结束。

中间有JJ主导进行了一次详细的系统级测试，在测试的过程中主要发现两个问题。第一个是负载不能均衡的问题，F5硬件的负载均衡策略原来是有很多的，最后以判断连接数判断把负载分配给谁。另一个问题是发现了日志记录等级和方式的问题。方式是两种，一中是记录在数据库中，另一种是记录在txt文件中，不明白具体的区别。但在测试中证明记录在数据库中的方式是十分占用系统资源而且很容易将硬盘空间占满，最后还是使用的txt文件方式。日志等级同样也会有占用空间的问题，最后将日志等级定为error。用txt的方式记录是每10M新起一个文件。

第四阶段做回归测试其实很少，有些脚本的逻辑已经更新。在新版本的系统里已经不能正常运行，有两个脚本修改了关联规则。有些脚本参数已经发生了变化，还有一些直接业务逻辑发生了变化。种种原因造成很多脚本不可用，最后只得只回归有问题的脚本。

在运行最后的综合场景时出现了问题，场景运行4小时便服务器死掉。在查看情况的时候发现LR没有关闭日志，至使LR的日志在4个多小时的时间内占用了我C盘11G的空间，使C盘再无可用空间电脑死机。再次运行2小时时服务器死掉。后来经常看服务器日志，发现是W子系统一个功能的脚本发生了内存溢出。这里有个看日志的经验，内存溢出是有固定的日志报错的，一个报错是可以记住，但实际上是要学着看懂日志才是最好的。5)

经验

在进行测试的时候不要相信整个系统都在使用同一个协议，在这个系统中除了X子系统以外其他所有的系统都是使用的http协议，只有X那里的那一点点用到了Ftp的协议。所以以后如果脚本有问题最先想到的就应该是录制协议，当确定录制协议没有问题之后再考虑是否存在其他问题。

从服务器上要来的数据不一定和在浏览器上看到的一模一样，可以从开发那里了解到底处理的逻辑是如何的，有可能数据下载到本地之后被本地的java脚本加工之后才展现在浏览器当中。这里又涉及到java脚本在本地处理数据所占用的时间，对用户来说这个时间也要算在响应时间当中。在这个系统里也有这样的问题，而且处理时间超过6秒，所以如果在事务中间发现有thinktime的话一定要仔细考虑追查这个thinktime是如何产生的，很有可能这里是一个重要的逻辑步骤，是不可去掉的thinktime。在测试过程中用户数的计算有多种方法，针对不同的系统可以使用完全不同的思路来进行换算。如果用户数特别大本身不好模拟的话不要一味地使用忽略thinktime或者缩短thinktime的方法进行计算，也许换一种思路来想就可以有新的路线。现在至少有观察点击率或者是业务数量（TPS同等效应）的方法进行换算。如果不能准确换算也可以考虑比计划的需求稍微大一点的方式进行。

被压缩成包进行传输或者是加密后进行传输的数据在LR中几乎是不可以改动的，虽然有调取dll的方式进行，但在实际测试中也许技术或时间限制不一定能完成。其中还存在一个问题就是这种用java脚本做压缩或者加密转换的是否可以用LR调取java的什么控件或者程序来做这事情。

在响应时间或系统出现响应比较慢的时候，不要仅仅把目光盯在虚拟用户是否操作过快上。任何步骤都可能影响系统运行成为瓶颈，曾经在某本书上看到过最后排查出系统的瓶颈竟然是一个交换机。而我们这次也发生了几乎是同样的问题，瓶颈竟然是我们办公那一层的局域网，是个百兆网。后来想到到专利局机房去测试的时候突然想到查看一下自己的网卡，结果不出所料，我们所使用的几台测试机的网卡全部是百兆网卡。如果把自己的机器当成千兆网卡肯定会影响测试结果。以后一定要注意，包括在写测试环境的时候，一定要把网卡这一项写明，提醒自己也是提醒别人不要让本机成为瓶颈（不过后边还是出现了这种事）。数据可以说是性能测试的命脉，一定要在测试前将数据都准备好。现在开发往往不喜欢配合测试人员准备数据，所以往往一会儿就可以做完的事情要做好几天甚至半个月。所以在进行测试之前一定要尽量的准备好数据清单，在第一时间里让开发准备数据，必要的时候要动用有决策能力的人催促开发来做这件事情。在运行自己不能够制造数据的脚本的时候一定要注意节省数据的使用，一定要完全确定没有问题了才放开了跑场景进行测试，不然如果把数据用没了或者用乱了就很容易因为开发没有及时给准备好数据而被迫测试停止。在测试进行一个阶段的时候，如果精力和资源都允许的情况下，最好进行一次小的综合测试。很可能测试的结果让我们很吃惊，单点的测试往往不会对服务器造成过大的压力，只能看出代码级的问题。而综合的测试场景把用户数加上去之后，很可能会出现系统级的错误，在出现系统级错误的时候要及时查找是否是自己的问题，确定自己测试方法没有问题之后要尽快报给开发人员解决问题。另外有些问题是在长时间运行之后才会出现的，比如在测试过程中如果有内存泄露，并不是半个小时的测试就能够体现出来的，尽量长时间的综合场景才更有可能暴露更多的问题。论优限级的话，系统级的错误要比代码级的重要很多。

关联，作为LR的基础，一定要牢牢地掌握。在本次测试中掌握了LR关于数组的应用，应该多复习，在未来的工作中如果遇到此类情况做到手到擒来。不要仅仅把眼睛放到代码及数据库上，任何一个中间环节都可能引起服务器的异常。在前边已经提到过关于网络瓶颈的问题，而后来又发现了记录日志方式不正确和负载不均衡的情况，在未来的工作中要多听多记多看书，尽量开阔自己对各方面的了解，才能准确的判断出到底是哪里出了问题。

在测试过程中，发现有问题的时候可能会进行优化，而优化过后呢？代码是否发生了变化，某一个位置原来是3个请求现在是否变成了5个，比如页面上多了两个图片。这个时候应该如何对待？所以在测试过程中应尽量跟随开发的脚步，了解开发已经完成的功能是否进行了修改，如果修改都修改了哪些部分。此次测试中的登陆就出现了这样的问题，两个不同时期录制的登陆脚本完全不一样，在最后综合场景中虽然都可以使用但实际测试出来的结果是完全不同的。另外还在最后回归测试中发现两个脚本的关联规则发生了改变，这都证明程序已经被改动过了。想避免不厌其烦的录制脚本还要保持自己的结果千真万确吗？只能把开发控制起来，完全了解他的进度是什么才能做到对项目进展了如指掌对对自己的结果在自己了解的范围内完全确定。

在LR跑长时间大型场景的时候一定要记得调整日志，或者关闭日志，如果需要日志的话就要将临时文件等进行调整，或者只打出错误的部分。在本次测试中出现了这样的问题，经过4个小时最后的综合场景之后，C盘剩余的11G空间全部被占用，造成C盘没有临时空间机器运行十分缓慢。最后实在没有办法重新启动电脑。

在进行性能测试的时候，千万不要认为性能测试就是LR，其实LR本身有很多的问题。在本次测试中就遇到了监控服务器资源的时候经常掉线失去数据的情况，虽然重新添加一次可以重新读取，但始终要有人守在电脑的前边。幸亏JJ在服务器断使用了nmon才使监控服务器资源变得比较把握和轻松，遗憾的是因为对linux的不熟悉，我没有学会这个软件的使用，在未来的工作中一定要注意积累和学习。5.测试报告 1)

内容

书写测试报告不是什么困难的事情，可以说比书写方案要简单得多。只要有模板了之后可以像填空一样把东西都填写进去，然后适当地加上自己的注释和分析。在本次测试过程中总共书写了三个阶段测试报告和一个总的性能测试报告，前边的大多数都有我来完成，最后总的报告有一部分东西是由领导来写的。2)

经验

阶段报告之所以说是阶段报告就是要在一个阶段的时候说明情况，和测试状态报告是一个概念。这个时候千万不要隐藏任何问题，把发现的和预见的问题都要暴露出来，让大家知道，这样才使后期的工作进展的同时更能够保证质量。另外阶段报告除非有领导要求，不然不要写的繁多拖沓，把主要问题暴露出来的同时只要表明我们都做了什么，什么没有问题就行了，没用的章节一律剩略。至于什么叫没用的章节，仁者见仁，智者见智了。6.测试总结 1)

内容

写总结不仅仅是给公司写的，更是给自己写的。在本次测试结束后我用了很长的时间来写这篇总结，总的字数大概要到一万五左右。在写的过程中几乎把自己一年以来的日记重新翻了一遍。所以我可以想起每一个细节，知道哪些问题我没有解决哪些问题虽然解决了但并不知其所以然，更是想起很多与开发沟通之后才知道的知识。如果不是最后做了一次总结，我想我就很难再记起那些东西了，尤其是一些细节。2)

经验

只有还有一点时间，请在做完项目的时候写总结。只有写了总结的时候才知道以前这段做项目的时间到底都做了什么，有时候我试着去想到底这个项目我都干了什么学了什么。但总是想着想着就想到了别的事情上。一直到写了总结之后我才真正了解我到底做了什么学了什么，进步在哪里。当然，具体如何写，那是大家自己的事情了。第三章 经验总结 1.做事

网络是最好的老师，任何一个技术人员，即使水平再高也没有网络水平高。有任何问题的时候第一时间想到的不是去问哪个骨灰级技术人员，而是网络。有问题问百度，但在网络上实在找不到答案或者找到的东西自己实在看不明白的时候再去问技术人员。这里边还有一个问题就是网络上写的东西不一定都是正确的，有很多人把别人的东西抄过来的时候连试都不试，造成网络上很多的假技术存在。这需要技术人员自己进行试验，只有这样才能记住这些问题到底如何解决。

测试人员必须要记得任何时候都不要想当然，不要认为什么样子就可以。一旦有这种情况的时候一定要问自己试过没有，如果没试过千万不要认为就是那样的。经常会有想当然造成的耽误了工作进度等。这次测试中就发现了此类事情，在设置好场景之后要用计划任务，我想当然地认为设置好就可以了。而JJ试了一下，发展根本就不行，后来查到相关资料才知道也是要点了运行场景之后才开始计时。如果那天是我在工作的话，可能就要让这个场景在那里静静地等待到天明了。好记性不如烂笔头，在工作的时候一定要多记录。可以用电脑记也可以在桌子上放几张纸随时写写画画也比较有效果，尤其有时候说事情的时候，边写边做简单的记录有助于事后回忆。掌握一门简单的脚本语言对准备数据十分重要，目前使用autoit的效果非常好，在本次测试当中很多的地方都使用autoit进行数据的制造。在后边还用这个工具进行自动化的数据录入来进行批处理模式的性能测试，不然准备数据也是个很麻烦的事情。

在测试过程中要多思考，巧妙利用各种工具。LR自带的定时开启功能很有用，在进行中大型场景测试的时候，进行多次试验确认无误后可使用。既减少工作量，又减少资源占用，还可以让测试人员早些回家睡个好觉。即使不用LR工作，也可以采用一些自动化的方法进行工作。其实编东西并不难，不要畏惧编东西，有时候几行简单的代码就可以代替人几个小时的工作。生活中也是如此。不要轻易地答应别人什么事情，在做事之前先想好到底能不能做，自己的能力是否能够做到。对自己不熟悉的领域不要轻视，不然很容易出现答应了别人的事却做不到。在本次测试中就出现了专利局人要求测试防火墙，我们很轻易的就答应了，等到真正做的时候才发现原来我们连测什么都根本不知道。结果这个事情最后弄得大家都不太愉快，在未来的工作中，尤其是技术工作中一定要慎重，即使想给人家测也要有十足的把握并做好准备之后再答应。在测试过程中要学会取舍，如果某个地方因为种种问题需要很多的测试资源才能够完成测试，那就要视这个测试点的重要程度评断一下到底是否需要进行测试或者是否简单测试或者用其他途径代替。不然如果这一个点占用了过多的资源而耽误了其他的工作就得不偿失了。在做任何工作的时候都要想明白自己到底在做什么，有时候听了别人的话，然后就在做，做了很久之后却发现原来自己都不知道自己在干什么。当别人要东西的时候，我们却什么都拿不出来，只有一堆不能说明任何问题的数据。所以在做一件事情，尤其是接一个工作之前，一定要想好，甚至要做到前思后想，到底这个工作都有什么输入，要输出什么，其中可能会有什么样的困难，会涉及到什么方面的知识，哪些是自己的弱项，哪些是自己的强项，遇到什么样的问题如何处理。即使没有想到这么多也至少要明确自己到底需要做什么，最少也要知道输入和输出到底是什么。2.做人

技术人员都应该有自己的职业操守，就是认真的完成自己技术上的事情。任何其他的原因都不应该影响我们的技术水平，包括完成手头的工作。在必要的时候要不记报酬地加班完成工作。

测试人员的最大特点应该是严谨，我们几乎是软件质量的最后一关，过了我们这一关就是不拥有技术的用户了。所以在我们这里任何事情都要做的严谨，要谨慎再谨慎。在写报告的时候更要认真对待，不要因为某些原因而修改测试结果或者编写测试结果。我们是技术不是商务，这不仅是责任问题，还是我们作为技术人员的职业品德。第四章 感受

项目结束了。感觉在这整整一年里，我的进步非同小可。看了好多的书上了好多的论坛看了好多的各方面的帖子，也遇到了好多问题解决了好多的问题。当然解决的永远会比遇到的问题要少。可是现在回头再看看这一年，似乎又浪费了很多很多的时间，有的时候什么也不干就坐在电脑前静静地看着电脑，脑子里一片空白。

无论怎样，一年时间过去了，一个轮回结束了。下面我要投入到另一个项目的轮回当中继续谱写我自己的事业与生命。至少在这个轮回结束的时候，我不再迷茫，我知道自己要走的路到底是如何的，我也隐隐地感觉到它的崎岖与坎坷，但人生在世路还是要走下去的。积极地去迎接自己的未来吧。第五章 鸣谢

首先感谢T和公司的各位领导们给我这个机会，让胆小的我加入到这样一个大项目中来而且有幸成为唯一一个见证这个系统的性能测试从开始到结束的过程的人。其次要感谢我的领导在这个项目实施的过程中给了我很大的关怀与谅解，给我很多的时间和机会让我成长。更在很多人事的问题上给我很多的指导，让我知道到项目原来不只是技术，还有很多技术以外的东西需要去做。

然后再谢谢JJ，一个不打不相识的搭档。从开始进入项目的争吵和暗战，到后来的同进同出的合作，一起经历了项目上太多太多的事情。即有愤怒和眼泪，也有欢笑和兴奋，有顶着眼皮彻底辛劳，也有连续若干小时激情讨论一个问题。至少目前为止，她是我最好的搭档，我们技术互补，能够互相理解对方的困难，尤其在我最艰难的时刻帮我做了很多的工作。再这里再一次谢谢你。还要感谢在我刚刚进入项目时帮助我快速熟悉项目的各位长软的同事，他们大多数是测试人员，但各个技术精湛，能够把事情说非十分清晰对我融入项目起到了很大的作用。

最后，感谢我的妻子、H和C。在我遇到生活和工作上的困难的时候，一直鼓励我，让我能够有足够的信心坚持下来，完成我人生重要的一段路。

第四篇：项目案例

美国GCI中国总部

Successful Cases List

成功案例━政府机关 Government  中央六部委项目（8000点六类）

 陕西省政府大楼（3000点六类屏蔽+非屏蔽） 六安市政府行政中心（1.2万点六类非屏蔽） 黑龙江政府办公楼

 安徽广德行政中心(4500点六类) 吴江行政中心一、二期(5000点六类) 国家密码局

 宁夏石嘴山市委行政中心  休宁政务区会议中心  中央党校党史陈列馆  珠海拱北口岸  山东寿光文化馆

 上海金山区政府会议中心改造 湖北省检验局  北京中直机关机房



中共杭州市委组织部信息化建设项目  广西人大综合办公大楼

 广西区政府信息改造（全屏蔽） 山东烟台工商局  济南奥体中心  国家专利局机房  国家防火中心  国家旅游局

http://www.xiexiebang.com

美国GCI中国总部

 南宁市科技局  广西防城海事局  江阴老干部局项目  无锡旺庄镇镇政府  巨野县政府办公楼  内蒙锡林浩特市国土局  无锡荣巷街道办事处

 宁波鄞州地方税务局急士岗分局办税服务大厅  杭州市林水局大楼改造  安徽省郎溪县财政局  江西金溪县行政中心  江西赣州市检验检疫局

 西安市文保中心及国家文物科研基地综合办公楼弱电项目  乐山政府

 广西区统计局资料管理楼（六类屏蔽+非屏蔽） 山东省政协活动中心 宁夏回族自治区党委办公楼机房  全国信访信息中心机房  中国航天测控中心  海关总署外事培训基地 丽水市水利局办公大楼  茂名市招商局

 珠海市残疾人联合会办公大楼  茂名市残疾人联合会办公大楼  株洲市水利局  阜阳纪委  北京市委机房  昌平财政局办公楼  当涂建委办公楼  北京市旅游局机房

http://www.xiexiebang.com

美国GCI中国总部

 福建闽侯县项目服务中心  长征运载火箭技术研究院  珠海市环境监测监控中心

 珠海市社保局



贵州省档案馆屏蔽布线系统 

贵州省福泉市政府办公网络系统 

南宁海事局 

安徽广德国土局 

江西省档案局办公大楼 

成都海关宜宾办事处

成功案例━ 军队/公安/检察院/法院 Military/Police/ Procurator ate/Court

 江西602研究所（2008，军工六类5000点屏蔽） 海军91917部队（六类屏蔽低烟无卤LSZH） 浙江舟山92910部队（六类屏蔽低烟无卤LSZH）

航天401研究所项目 

台州市交警大队大楼  合肥交警指挥中心

 宁波市公安局巡特警支队训练基地  义乌公安局新办公大楼 北京市西城区公安局  北京密云法院  北京顺义法院  北京门头沟法院  安徽马鞍山雨山区法院

http://www.xiexiebang.com

美国GCI中国总部

 广西柳州融安检察院  无锡东亭派出所改造工程  山东济宁监狱

 绍兴县人民法院法官培训用房智能化  绍兴人防指挥中心大楼

 浙江省军分区第五批干部安置房  安徽芜湖鸠江区法院  北京牛街派出所  乐山军分区项目  62664部队屏蔽系统  63880部队屏蔽系统 成都军区屏蔽系统 武警38师办公大楼屏蔽系统



中国人民解放军总参  中国人民解放军第二炮兵学院  空军政治部  军事科学院  空军装备研究院

 珠海市香洲区检察院（六类屏蔽+非屏蔽） 江西省宜丰人民检察院  安徽省芜湖鸠江区法院  株洲市交警支队办公楼  株洲市交警支队天元支队  北京市公安局机房  丽水市国家安全局办公大楼  诸暨市商检局办公大楼

 宁波市公安局巡特警支队办公大楼

 深圳市国家税务局中心机房  浙江省安全厅办公楼  宜宾商检局

http://www.xiexiebang.com

美国GCI中国总部

 浙江省桐乡市工商局办公大楼

成功案例━医疗 Medical Treatment

 中国人民解放军总医院  南京军区福州总院  兰州石化医院  安徽黄山人民医院  新余市人民医院  台州市急救中心  深圳市罗湖区妇幼保健院  南昌市第九医院  常熟二院  北京大学校医院

 广西区人民医院改造（六类屏蔽） 国家气象局综合门诊楼  北京西苑医院  北京康复医院  北京同仁医院  珠海市人民医院二期  上海邮电医院  福州九三医院  福州晋安医院  江阴中医医院  许昌人民医院漯河三院  江阴人民医院  南京市医药公司

 南京肿瘤医药新大楼综合布线  南京口腔医院

http://www.xiexiebang.com

美国GCI中国总部

 江阴明城卫生院

 上海市东医院医技楼布线项目  湖北襄樊人民医院  上海东光医院医技楼  湖州市中医医院  黄山中铁疗养院

成功案例━电力/交通运输 Electric Power/ Transportation

 安徽省电力公司自动化处

 江西赣粤高速公路股份有限公司行政办公楼  南京禄口国际机场物流中心  广州白云机场航空邮件处理中心  安徽阜阳农电公司综合办公楼) 安徽省宿州华电电厂  唐山热电厂  山西大同发电厂  山西忻州卫星发射基地  丽水公路管理局  绵阳电力  乐山电力  云南拉扬铜矿  云南弈西矿务

 宜宾铁路调度大楼布线工程



湖北襄樊运输公路局 

河南洛阳电业局

 上海浦东供电分公司生产调度楼（8000点六类）

中铁四局第一分公司小区、酒店、办公大楼4200点

中铁四局第七分公司办公大楼以及小区宽带3800点

http://www.xiexiebang.com

美国GCI中国总部



中铁四局第八分公司酒店和办公大楼3300点

中铁八局智能小区、酒店、办公大楼12000点

新长铁路信息化系统

宁启铁路信息化系统 

南京中电光伏厂房

成功案例 ━ 金融/银行及保险系统

Finance/Banking& Insurance system



南京（中国－东盟）商品集合交易竞价市场 

江南证券中心机房



内蒙古鄂尔多斯维邦金融广场  北京金融中心  光大银行金融中心  石家庄商业银行



大连民生银行  北京建行培训中心

 杭州市社会保险服务局智能化  建德信用联社  深圳发展银行余杭支行  江西省宜春市建设银行  杭州市建行中山支行  台州市工行大楼  淳安县农行  丽水市庆元县农行  上饶市银监分局  鹰潭市银监分局  江西宜春市银行监督分局  株洲市商业银行

http://www.xiexiebang.com

美国GCI中国总部

 中国工商银行株洲市分行  日本三菱东京日联银行  中信实业大厦天山路营业所  上海工行南区计算机中心  安庆怀宁人民银行  中国农业银行一分理处  厦门工行监督中心  泰康人寿

 福建省莆田农业发展银行

 北京万国数据中心

成功案例 ━ 教育Education

 广西南宁二中新校区

 西北师范大学（12000点，六类） 无锡北大研究生基地  内蒙古医学院  江夏学院校园网  上海嘉定进修学院  贵州大学  遵义师范大学  贵州建材工业学校  咸宁学院网络管理中心

 泉州泰山航海学院  内蒙古大学

 内蒙古师范大学教学楼  内蒙古远程教育网  苏州大学炳麟图书馆

 嘉兴市工程学院（中职园）

http://www.xiexiebang.com

美国GCI中国总部

 宁波教育学院改造工程  开化中学



中南民族大学 

武汉理工大学  湖北工业大学  大连海事大学  北京科技大学  河北省实验中学  广东警官学院

 衢州市第三中学

 杭州职业技术学院

 深圳大学城

 天津四十一中弱电系统一期  渭南合阳中学  浙江楚门中学

 浙江省开化中学新校区弱电系统工程  国家图书馆机房(5000点 六类) 解放军电子工程学院  安徽建工学院  安徽警官学院

 贵州民族学院研究生楼  贵州师范大学校园网 湖北经济学院 武汉船舶学院  华中师范大学

 南京林业大学计算机中心机房建设  南京炮兵学院 鲁东石油大学 北京外国语大学机房布线工程 无锡太湖科学教育产业园

http://www.xiexiebang.com

美国GCI中国总部

 浦江中心新校区 江南大学蠡湖校区专家楼综合布线工程 广西中医学院图书馆 江南大学蠡湖校区专家楼综合布线工程 河南商丘职业技术学院 江西经济管理干部学院实验楼 贵阳大学 达州职业学校 河北沙河中学 贵州师范学院机房项目  安徽科技学院教学楼

成功案例━体育/资讯/通Telecommunications/Broadcast

 广西柳州游泳馆、李宁体育馆 广西钦州体育馆 深圳市龙岗区文体中心 中国体彩中心机房 安徽省移动公司办公大楼  安徽移动1860客户中心(4000点) 浙江绍兴移动办公大楼  丽水市移动办公楼  安徽省安庆广播电视局  郑州中原传媒大厦

 北京歌华有限公司前端总指挥机房  中视传媒股份有限公司

 中国联通东莞分公司新时空大厦  丽水市电信数字化城管监控系统

http://www.xiexiebang.com

讯/广播/媒体10

美国GCI中国总部

  临平城乡导报大楼 《温州晚报》报业大厦



北京长宽公司

广州市电信收费中心 广东茂名电信



成都电信宽带网

成都联通宽带网

宜宾联通综合大楼布线工程 四川泸州电信教学部网络项目

新疆电信多媒体公司

成功案例━智能大厦/小区 Intelligent Building/Community

   成都尚都国际广场 北京CBD“世贸天阶” 物美大厦弱电系统工程



时代大厦弱电系统工程 

北京碧荷花园高档小区           杭州市九树公寓 宁波里仁小区

深圳市水源大厦智能化系统工程 深圳市劳动局高训大厦 湖南金湘潭商业广场 北京伊东猗龙台商务公寓 长沙信托大厦改造 烟台世纪大厦 北京新恒基大厦 北京船舶信息大厦



常州红梅假日广场

http://www.xiexiebang.com

美国GCI中国总部



常州金城大厦

上海钱江大厦综合布线系统 苏州工业园区邻里中心师惠大厦

广州奥林匹克大厦 

深圳本元大厦 青塔小区  北京玉林花园



广州骏景花园 

广州嘉润商务大厦  苏州吴中科技园 中国四季青服装交易中心一期工程 佛山丽日豪庭 广州荔港南湾住宅区 常州新城市花园3期



大连中盛家园

沈阳凤凰花园 成都龙泉小区

成功案例 ━ 酒店

Hotel

 上海皇冠假日大酒店  无锡香梅国际大酒店

 宜宾蜀南竹海三江湖世外桃源酒店  锦江皇冠大酒店(南昌金苑大酒店) 九江世纪大酒店

 烟台南山皇冠假日酒店(7000点六类) 总统大酒店

 舟山普陀祥生大酒店  海口天利万豪酒店

http://www.xiexiebang.com

美国GCI中国总部

 舟山花园大酒店

 恩平山泉湾温泉酒店5星级  舟山祥生大酒店  安徽黄山溪递桃园大酒店

 咸阳关中温泉(海泉湾)综合布线项目  中铁五棵松酒店办公楼  上海中祥宾馆  无锡金陵饭店  新友联假日酒店

 南宁名都广场皇冠假日酒店  苏州三德轩太湖度假村酒店  黄山中铁疗养院

 镇江一泉宾馆

赣州金龙大酒店 

上海宝虹大酒店  上海浦东大酒店  苏州菜家食谱酒店 长沙鑫远白天鹅大酒店成功案例 ━ 企业 Enterprise

 中国石化湖北全省屏蔽布线系统  中兴（西安）科技研发基地  巨石集团（玻璃纤维厂） 国美电器(全国联锁店) 珠海市高栏港办公楼  台州东港集团办公楼

 昆山人力资源市场  珠海世纪鼎利生产综合楼

http://www.xiexiebang.com

美国GCI中国总部

 上海延峰江森座椅有限公司芜湖分分厂  山东潍坊软件园  江苏中外运办公大楼  芜湖江森自控厂区项目  江森南通分厂

 延锋伟世通汽车饰件公司

 上海延锋江森座椅有限公司TC大楼  河南许昌卷烟厂

 浙江网新恒天软件有限公司紫金国际工程

 abeam信息技术有限公司(西安分公司)综合布线项目  浙江海盛鞋业有限公司  合肥中建机械有些责任公司  江西用友软件行政办公楼  贝尔罗斯（北京）电子  北京世纪互联  朗讯实验室

 长沙市岳麋区中心机房改造  首钢搬迁京塘分部  台州市海洋馆弱电项目  安徽中石化办公大楼  宝钢计算机机房  江苏金属勘探局办公大楼  广州奥林匹克体育馆



番愚利华金属制品有限公司办公大楼 

深圳粮食集团中心机房

http://www.xiexiebang.com

第五篇：VoLTE测试案例分析

案例1：580 Precondition Failure导致的未接通。

【问题描述】

在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。

Log文件名：

9100060920***3MS2_UE1.lte 9100060920***3MS2_UE2.lte MO UE: *** MT UE: *** 时间：10：16：14.320

【问题分析】

1、呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。

2、从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。主叫收到网络侧下发的580，接续被中止，导致了会话未接通。

3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。

4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE 580，会话流程中断，导致未接通

【问题定位】

在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。【解决措施】

需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。

【测试验证】

案例2：Server Internal Error 500导致的未接通

【问题描述】

在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。

Log文件名：

9500061120***2ms1.lte 9500061220***2ms1.lte MO UE: *** MT UE: *** 时间：10：19：29.051

【问题分析】

1、主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。

2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放，去激活，导致会话未接通。

【问题定位】

主叫收到网络侧下发的INVITE 500，然后网络侧又下发RRC重配，释放掉QCI 1，然后去激活，会话流程终止，导致未接通

【解决措施】

需要核心网确认，为什么会下发INVITE 500，什么情况下会导致网络侧下发INVITE 500，随后的专载释放是否由INVITE 500导致的

【测试验证】

案例3：软件对失败事件的误判导致统计错误

【问题描述】

在集团测试LOG中，存在软件的误判而错误统计的失败事件。如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。

Log文件名：

9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：09：44：14.0 【问题分析】

1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功，在通话过程中信令流程正常，中间出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。

2、在09：44：14.910主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，在09：44：15：004，然后因为TAU，在09：44：15：128 RRC Connection Release了，软件统计为掉话。随后主叫又发起RRC连接，且在09：44：15.659重建完成，从RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。

3、到最后结束通话正常挂机都没有出现失败事件

【问题定位】

主叫接通后，在没有收到通话结束的情况下，中间出现RRC Connection Release，软件判断为掉线，此次是在会话建立后出现，软件统计为掉话

【解决措施 】

需要鼎利修改判断事件失败的机制

【测试验证】

案例4：软件对失败事件的重复统计

【问题描述】

软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。

Log文件名：

9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：04：08.0 【问题分析】

1、主叫在10：04：04.642发出INVITE会话请求，被叫在10：04：08.261收到网络侧下发的BYE Request，软件统计为掉话。

查看BYE Request中的CALL-ID，发现是上次会话的BYE Request

2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100，又在10：04：08.261收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送INVITE 486，软件统计为未接通。

3、主叫在收到网络侧下发的UPDATE 200后，在10：04：24.845上报Cancel，主叫的整个会话流程到这里被终止，事件上表现为未接通。且承载都存在

【问题定位】

通话期间，被叫收到网络下发的BYE Request会被软件统计为掉话。被叫连续两次收到网络下发的INVITE Request，回复INVITE 486 Busy Here，由于第一次INVITE Request未释放，故第二次INVITE Request网络侧才会下发INVITE 486，流程停止，软件统计为未接通。此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。

【解决措施】

需要鼎利确认对失败事件的统计机制。

【测试验证】

案例5：LTE到2G eSRVCC切换失败导致的掉话

【问题描述】

呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入失败，导致掉话。

Log文件名： 9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：11：16：42：311 【问题分析】

1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSI Reallocation Command，被叫回复TMSI Reallocation Complete，此后流程中断，eSRVCC切换失败。

3、信令上看，4G流程正常走完且建立会话，被叫切换到2G，但是网络下发TMSI Reallocation Command导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是2G问题。

【问题定位】

4G流程正常且已正常建立会话，由于2G网络侧下发TMSI Reallocation Command导致eSRVCC切换失败，会话流程结束，导致掉话，怀疑是2G的问题。

【解决措施】

下周准备复侧，准备定位。

【测试验证】

案例6： TAU过程中RRC Connection Release导致的未接通

【问题描述】

在越秀区网格10的测试LOG中，出现如下的未接通事件： 主叫起呼发出Invite消息后，在收到网络效应Trying 100之前，先收到了网络下发的RRC Connection Release消息，RRC连接释放后，接续被终止，出现了Blocked Call事件。

【问题分析】

1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：

2、在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。然而Invite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了Blocked Call事件的发生：

3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:42:53至11:43:04就发生了4次，可能在存在TAC规划不合理的问题。

【问题定位】 【解决措施】 【测试验证】

案例7：Alerting中eSRVCC失败导致未接通

【问题描述】

主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180，主叫未摘机，由于切换失败导致未接通。

Log文件名：

9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：11：25：28：189

【问题分析】

1、主叫在11：25：26.130起呼，到11：25：28.204收到网络侧转发的Ringing 180，整个信令流程正常

2、在主叫几乎收到网络侧转发的Ringing 180的同时，主叫达到eSRVCC切换门限，网络侧在11：25：28.189下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。

【问题定位】

主叫已经收到Ringing 180，处于振铃状态还未摘话，由于在Alerting中发生了eSRVCC 切换失败导致了未接通

【解决措施】

需要核心网方面帮忙定位 【测试验证】

案例8：CSFB失败导致未接通

【问题描述】

主叫起呼后，被叫CSFB失败，主叫直接Cancel导致未接通

Log文件名：

9500060520***6ms1.lte 9500060620***6ms1.lte MO UE: *** MT UE: *** 时间：15：42：53：063 【问题分析】

1、主叫于15:42:22发起invite，被叫未收到网络侧转发的INVITE Request，但是主叫能一直收到网络侧下发的INVITE 183、PRACK、UPDATE消息，这些消息被叫并没有收到也没有回复。被叫在15:42:24收到网络侧下发的CSFB request，但CSFB到2G后从信令看没有呼叫相关的信令交互过程

2、直到15:42:35 CSFB失败，由于收不到被叫的响应，主叫主动于15:42:53发起CANCLE。导致会话未接通。

【问题定位】

主叫发起会话后，被叫没有收到会话请求，直接CSFB，CSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。

【解决措施】

需要核心网 查看为什么被叫没有收到主叫的会话请求，且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息。【测试验证】

案例9：被叫Detach导致会话未接通

【问题描述】

主叫发起会话，被叫驻留在2G未返回4G，没有响应主叫的会话请求，主叫收不到被叫相应，直接Cancel导致未接通。

Log文件名：

9500060520***6ms1.lte 9500060620***6ms1.lte MO UE: *** MT UE: *** 时间：15：43：37：999

【问题分析】

1、主叫在15：43：08.657起呼，此时被叫任然驻留在2G，由于上一次会话中CSFB失败，并没有返回4G。

2、起呼后，被叫一直无响应，没有与主叫进行信令交互，然而主叫能一直收到网络侧下发的PRACK、UPDATE消息。

3、主叫一直收不到被叫的回复，被叫在15:43:30.449被叫上发Detach Request，主叫在15：43：37.999上发Cancel，取消会话，导致未接通

【问题定位】

被叫停留在2G未返回4G，然后上发Detach Request，主叫收不到被叫的回复，直接Cancel，导致未接通 【解决措施】

需要核心网查看为什么主叫会话信令流程正常，被叫却无法收到主叫的会话请求。同时查看2G无线侧，为什么被叫会上发Detach Request。

【测试验证】

案例10：承载未建立导致未接通

【问题描述】

主叫收到100 Trying 后未建立承载，使得 RRC直接释放，导致未接通

Log文件名：

9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：15：46：36：271 【问题分析】

1、主叫在15：46：19.079发起会话，收到网络侧下发的100 Trying后，专有承载一直未建立，10s后RRC释放，主叫在15：46：36.271上发Cancel，导致会话未接通

【问题定位】

专有承载未建立，10s后RRC释放，导致未接通

【解决措施】

需要核心网查看为什么没有建立专有承载 【测试验证】

案例11：承载异常释放导致掉话

【问题描述】

被叫重建立成功后，专有承载突然被释放，导致掉话

Log文件名：

9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：35：41：981 【问题分析】

1、主叫在10：28：06.903起呼，流程正常，收到网络侧转发的Ringing 180，UPDATE 200，主被叫会话正常建立。

2、被叫在10：35：38.253发送重建立，重建立成功，且流程正常，但是在10：35：41.981承载被释放，导致掉话

【问题定位】

会话建立后，被叫重建立完成，但是专有承载被释放，导致掉话

【解决措施】

需要核心网确认承载释放的原因 【测试验证】

案例12：信令转发失败导致未接通

【问题描述】

主叫发起会话请求，网络侧未转发，被叫未收到，主叫Cancel，导致未接通

Log文件名：

9500060520***1ms1.lte 9500060620***1ms1.lte MO UE: *** MT UE: *** 时间：10：03：48：952 【问题分析】

主叫在10：03：32.741发起会话，被叫未收到，直到10：03：48.952主叫Cancel，会话接续无法继续，导致未接通。整个过程无线环境良好，网络侧未转发信令。

【问题定位】

网络侧未转发主叫会话请求，使得会话接续无法继续，主叫Cancel，导致未接通。

【解决措施】

需要核心网确认会话信令是否成功转发

【测试验证】

案例13：终端上报Cancel导致会话未接通

【问题描述】

会话流程正常接续，终端上报Cancel，导致会话未接通

Log文件名：

9500060520***5ms1.lte 9500060620***5ms1.lte MO UE: *** MT UE: *** 时间：14：53：06：510 【问题分析】

1、主叫在14：53：03.998起呼，信令流程正常，且被叫上发Ringing 180，主叫收到网络侧转发的Ringing 180，主被叫都已经振铃。但是主叫突然在14：53：06.510上发Cancel，被叫也收到网络侧转发的Cancel，会话接续停止，导致未接通。

【问题定位】

主被叫会话流程正常，无线环境良好，信令转发正常。主叫上报Cancel，导致会话未接通，定位为终端问题

【解决措施】

需要终端确认或者更换终端测试再查看结果

【测试验证】

案例14：

【问题分析】 【问题定位】 【解决措施】 【测试验证】