稿件管理系统测试项目经验总结

第一篇：稿件管理系统测试项目经验总结

稿件管理发布系统测试项目经验总结

经过近两周时间，稿件管理发布系统测试工作基本完成了，收获很多，但还有很多不足，希望在之后的学习中以此为借鉴，完善测试过程。收获：

（一）了解了做一个项目的大概步骤；要想做一个好的项目，测试要贯穿整个开发过程，在做项目之前要做好充分的准备，如环境配置、文档准备、资料收集等。在一个项目中至少要有以下几个文档：需求分析报告、测试设计报告、测试用例设计报告、bug报告及测试报告。对一个测试人员来说，测试设计报告是一个前提，首先要保证测试设计合理，并且内容齐全。这样才能更直接、准确地进入下一项目步骤。测试用例是整个项目的重点，在一个项目中测试用例必须经过三方面的评审，评审通过才能执行。一是自我检查，二是测试人员互相评审，三是项目经理评审。一个好的测试用例要覆盖全测试需求，测试用例的设计要合理、正规。测试用例不在于多，要在于覆盖全，测试用例的多少在一定程度上并不代表质量的高低，所以说，测试人员对于测试用例的设计一定要细心且全面。接下来是bug记录，在bug记录中一定要详细给出测试的重现步骤。一个bug报告中所包含的标题有：缺陷ID、缺陷标题、缺陷描述、缺陷的重现步骤、缺陷的严重级或者优先级、测试模块、缺陷提交人、缺陷的版本及证明是缺陷的视频或者截图等。最后是测试报告，在测试报告中最突出的问题就是测试缺陷的分析，测试用例中缺陷有多少，通过率是多少，有哪些建设性的意见，及最终得测试结果，是通过还是没通过。

（二）了解了如何写测试计划、测试用例、bug报告、测试报告等；

1、测试计划的内容包括引言、测试背景、测试组织结构、测试策略、测试计划、测试环境及测试总结。在整个测试计划中最重要是测试的详细计划，当然在测试之前，要评估好测试的工作量分配及进度安排，人员规划等，测试计划的书写要有一定得逻辑，要能够真实反应测试项目。测试进度的安排要合理。

2、测试用例报告是一个项目中的重点，描写一个测试用例包括测试需求ID、测试需求标题、用例ID、用例步骤、期望结果、测试结果、测试人员、所属模块、严重级、备注等。在测试用例报告中重点在于测试步骤

要尽可能地详细，测试需求、标题等要描述清楚。

3、Bug报告也是测试项目中的重点，也是最让人有成就感的报告，bug报告中缺陷要描述清楚、正确评估缺陷的严重级别。

4、测试报告是一个项目的总结性报告，测试报告主要包括引言、测试设计简介、测试结果分析、测试结论及建议。

（三）了解了如何有条理地书写测试用例；首先测试用例要覆盖需求，根据项目的需求分析或者软件，设计测试用例。其次，写复杂的测试用例要掌握一些方法。例如决策表法，要先把影响因素和测试用例的个数做成表格形式，以便于详细分析设置用例的多少。在设计测试用例的过程中最常用的是等价类划分法，基本上每个测试用例的设计都要考虑正反两个方面。在这划分过程中遵守着尽量覆盖尚未覆盖的有效等价类，仅覆盖一个尚未覆盖的无效等价类原则。

不足：

1)需求分解不彻底；在本次项目执行过程中，我们发现在需求手册中很多地方描述很模糊或者很简单，不能很好地向设计者呈现要设计软件的细节操作步骤，从而，对于软件测试人员来说就很难辨别测试结果是否符合要求，换句话来说，如果一个测试人员想把需求描写的很模糊的地方测试清楚就必须和客户不停的交流、沟通，在一定程度上影响项目的进度。以上是从客户需求角度来说的。对于客户只提供软件而没有需求的情况下，项目组人员就要人怎分析测试需求，详细分解。

2)测试用例覆盖不了测试需求；一开始感觉设计的测试用例可以覆盖需求了，但是执行后才发现很多细节部分没有写全，例如稿件管理发布系统用谷歌浏览器打开就会出现很多错误，稿件管理系统在浏览器的应用上存在一定得兼容性问题，等等。针对这种情况，我们需要在执行之前，详细地了解用户需求及真实软件的运用效果。两者相结合，设计更全面的用例。

3)对bug的辨识度还有待提高；在测试用例执行时，会发现很多细节性的问题，不容易判断它是不是一个bug。例如稿件管理发布系统中高级查询里的版本查询，虽然说它支持的是模糊查询，但是输入很多“.”时查询的结果仍然是正确的，如果把它归类为非法版本号，非法版本号输入后查询结果应该是查不到，而不是查询到正确的结果。在一开始我将其定义为bug，但是和其他人讨论之后，觉得可以不是bug，第二天又去考虑觉得还是bug。虽然说各人的判断标准不同，但是总该有一个统一的标准。想这类问题还要在以后的项目实行过程中不断总结经验。

4)测试执行方法及步骤还存在很大的改善空间；在测试用例设计中不只

是功能测试，它还包括性能测试、界面测试、安全测试等，对于这些测试，测试用例设计时步骤不是很详细，操作时就存在一定得困难。例如：性能测试中系统支持20人并发访问系统，这就要求我们要尽量组织20人去集体测试，怎么去组织，要做哪些事情，诸如此类准备工作一定要详细准备。

5)很多业务知识还不了解；这个问题在本次项目中体现不明显。这是做

软件测试学长给的意见。要做好一个项目，必须地相应项目的业务流程有一定的了解。

6)项目中组员间的交流不够；虽然很多时候大家都提出互相检查用例及

bug记录等，但在实际过程中并没有切实实行。交流是测试人员必备的沟通技巧，在项目进行过程中遇到问题要互相沟通，以便更好地解决问题。

7)对部分基础知识的理解不够透彻；在写测试用例时，我们采取的步骤

是先把可能考虑到得测试写全，但在写测试用例时，就发现对一些测试的概念记得不清楚甚至混淆。这就说明我们对基础问题的认识还不够深。因此，在之后的学习过程中我们要不端去记忆一些概念，或者在做项目过程中不断地发现相应的问题然后去解决。反复记忆，出现问题才能铭记于心。

8)报告书写技能有待提高；测试人员做项目时，很多问题的结果都是以

报告形式，我们要不断练习自己的公文写作能力，熟悉应用office办公软件。

9)数据库、服务器等其他知识了解太少；在测试执行中，遇到一些bug，不清楚其出现的原因，知识面太狭隘。在之后的过程中要多了解与测试相关的知识。

总之，这两个星期来，收获颇多，问题多多，革命尚未成功，同志仍需努力！我们要通过各种渠道主动去获取知识，多交流，多沟通，共同收获！

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

项目测试经验总结

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

项目测试经验

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

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

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

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

第三篇：项目管理经验总结

项目管理经验和技术总结

江苏分公司第四管理部

2015.09

作为项目管理人员，要以专业技术为依托，以工程项目管理为中心，先进的工程建设理念，明确项目成本、质量、进度和安全目标。扎实的工程建设理论和技术管理知识、丰富的现场施工经验是做好工程项目管理的基础;这就需要在平时的工作中不断积累和总结，让实践与理论更好地沉淀于能力上，更好去管理协调。

一、对于整个施工过程中的技术实施，主要还是在于工程的质量，质量不合格，其它一切也就白谈了。影响施工项目的质量因素主要是人、材、机、方法和环境。所以如何控制好质量是关键。1.要熟悉工程建设中的各种材料的技术性质和质量要求;材料要严格检查验收，正确合理使用，建立管理台帐，进行收、发、储、运等环节的技术管理，避免混料和将不合格的原材料使用到工程上。2.对各工序的施工工艺充分地把握，严格按施工方案施工;全面分析，预防为主，对可能出现质量隐患的，设置控制点，重点防范;控制好整个施工过程的质量通病：质量通病面大量广，危害极大，消除质量通病只要思想重视，施工过程严格按施工验收规范进行施工，遵守施工程序和操作规程，贯彻技术责任，严格检查、层层把关，绝大多数质量通病都能消除。

二、当今社会是一个讲效率的社会，时间就是金钱，质量保证了，进度也要跟得上，要合理地赶进度，对各种资源优化搭配，从而节省管理资源，节约管理成本。

三、建立项目核算制，对项目进行成本控制，人、材、机、管是构成成本的主要费用;人工费严格按工程量计算，优化劳动力，减少返工，杜绝滥用工，施工要按工期严格进行，严禁窝工，无故停工，用工要按时按量(定量定工);材料在在提取使用前，施工主要负责人要熟悉施工图纸，对所用的材料的数量做到心中有数，要按时按量提取材料，尽量控制材料使用量，严格按照图纸施工，多用材料和少用材料土建工长都要以洽商的形式反映在书面上。也就是说主要负责人要对提取的材料严格把关，严禁多提错提。在现场要有人专门盯工程质量，依图施工，严禁浪费材料，丢失材料。工人对施工工艺不了解会导致浪费材料，还要防止工人盗窃施工材料和施工工具;机械施工方案的选择，要合理配置机械，提高使用率;管理人员要严格配置，架构要合理，管理人员素质、技术、办事效率要高，缩短工期，减少管理成本;优化整个施工过程各工序的施工工艺，综合衡量，通过改变工艺，搞高效率，减少人、材、机，从而降低成本。

四、要以人为本，安全第一，明确安全目标、减少和消除生产过程中的事故，保证人员健康安全和财产免受损失;统一安全生产管理，制定周密的安全措施，建全规章制度，保证在多项目、多部位、多工种施工的条件下有序地进行工作，对使用一些特殊建筑材料性能、使用方法，要明确进行技术交底，控制好人、物的不安全状态、改善生产、生活环境。

在工作中要多观察，多动脑，多学习，并且不断提高交际能力，增强管理协调能力，以良好的思想品德、敬业的合作精神和奉献创新意识来回报社会的。

第四篇：各种项目管理经验总结[范文模版]

各种项目管理经验总结大全

如何在一个项目中从启动、执行、完成这一过程中，在做好项目管理的基础上，使团队所有成员在做人做事方面有所提高？

减少沟通成本是做好项目管理和团队管理的重要前提条件，而且是贯穿整个流程之中。（1）帮助新人快速理解原来团队的氛围，知识，降低后期的沟通成本。

一方面要提前将内部约定的词语或专业词语解释给新人，且必须让他们理解。

内部约定的词语有两种情形：一种是我们自己原创的，例如“栏目页”；另一种是普通的单词，在特定的环境使用中，我们对它“重新”定义，例如“模块”。而专业词语则是行业中通用的词汇，这个与个人的阅历直接相关。

内部约定的词语在团队的日常交流中经常使用，不会觉得有问题。但对于新人来说则是碰到一个概念，大部分情况下新人们会根据已有的经验、阅历去理解我们的词汇，他们自己觉得“懂”了，所以大部分情况没有提出疑问。只有在项目进行中出现问题，几轮沟通下来才发现问题在于双方对某个词的理解出现了偏差，这时已付出巨大的沟通成本。所以，在和新人沟通的时候，时刻提醒自己：当讲到一些词语，无论是否是内部约定词语还是一些专业名词，停下来问问新人是否理解，并要让他们说出理解，以此来检验大家在理解上是否有偏差。例如在界面设计中的“模块”，在不同场景有不同理解，但我们内部已经对它“重新”定义，特指界面中的一个栏目。如果没有提前解释清楚，在中期执行经常会出现多次返工修改的情形。

另一方面根据新人的理解水平，选择用词。

由于每个人的阅读量、认知水平都不同，所以在日常沟通中，一开始最好尽量少用一些专业名词，最好是在新人亲身经历过，再向他解释。例如一开始讲界面就提到用户体验、眼动实验，估计他们大脑顿时就石化了。

在开会、安排任务、解释说明的措辞上，尽量用一些通俗易懂，他们的认知水平可以理解的词语来说。“用户都是傻瓜”这话也适用于新人，（没有丝毫贬低的意思）这要求leader在解释说明时要做到所用的词，连傻瓜都能听得懂。我们要的是团队一起成长，不是为了向新人炫耀自己懂了多少，不是在卖弄我们的技术。

（2）整个团队交流时要化抽象为具象，便于成员之间相互理解

由于每个人的知识、阅历不尽相同，对于概念的理解必然存在偏差。因此leader在安排任务、讲解时，能画图的不用文字，能用表格的不用文字，能用比喻的不要直白陈述概念。通过具体、生动地表述帮助大家理解，减少不必要的纠结。

（3）明确一个时间点，减少误解。

假如说leader对你说“明天上午把文件发给我”你会什么时候发？可能leader从9点多就在电脑前等，你却睡到11点多才起床。Leader肯定不爽。问题出在哪？时间不明确。每个人对“明天上午”的理解都不同，“发给我”是发送到邮箱还是QQ离线文件？稍微注意下，改成“明天上午10点前把文件发到我QQ邮箱”。双方都心知肚明，可能leader会9点50分就去查看邮箱。大家合作愉快。

（一）项目管理

项目管理的目的就是保证项目按时按质完成。最理想的情形就是适当在人安排在适当的岗位上做适当的事，但现实中往往很难实现。这时leader需要有效地执行计划并监督大家朝一个方向努力。

一个项目的执行，需要有2个角色：项目经理+产品经理。（只能借助这样装逼的词）项目经理：正确地做流程；产品经理：正确地做产品。

由于人的精力有限，需要有人专注某一领域，协调项目的进展。项目经理更注重流程，制定并把握项目的进度，安排合适的人做正确的事，而产品经理则注重产品的质量，如网页的界面、功能，后台的数据库等，安排合适的人把事情做正确！

（1）制定合理的进度表，确保各项内容安排得当。

一份进度表须包括：起始时间、内容、参与人、负责人、输出物（即某个阶段做出的成果）。

确定的起始时间应注意：

第一，包括一个缓冲期。为了避免拖拉，延误了整个项目的时间，需将起始时间设定在底限的时间的前1-3天。例如1号开始画psd图，底线是10号交最终版的样图。在确定起始时间，应当设定为1-7号。因为返工修改与可能会出现拖拉的这2个因素，空出3天这样一个弹性时间。假如设定时间是1-10号，有可能10号晚上拿到的PSD图就非常满意，不需要一点点修改？

第二，时间的最终确定需所有成员清楚并同意。为了增加成员对项目的认同感，也为了尊重成员，避免成员在情感上认为上级又布置了一个任务，只能选择接受。由于每个人有各种私人的事情，还有可能有选修课、实验课等等不定因素，所以大家的时间比较零碎。此时，leader可以先按理想中的情况安排起始时间，再在会议上让成员商议，在每个人确保自己能完成任务的时间的情况下，再确定一份最终版的时间表（当然不能超过底限时间），最后leader要强调这份时间表是所有成员做出的承诺，如果完成不了再进行问责！

确定任务的参与人时，应充分考虑到他的技能水平、时间安排能否按时按质完成。但现实情况是很难有一个量化标准来衡量一个成员，因此leader在安排时可适当降低标准，只要不底于底限即可。

（2）开会进行任务安排，明确每个人的职责。

为了避免会议冗长、低效，小团队（8-12人）开会时，全部人站着开会且开会时间尽量控制在20分钟之内。会议上无法达成协议的，由双方会后再协商，不能因为个人浪费大家时间。

在部署任务时

第一，讲清我的期望与衡量标准。可以让成员从思想上重视，且知道怎么做才能让leader满意，更具方向性。

第二，讲清楚做这件事对其个人能力成长有什么帮助。

第三，关于做事情的方法和思路，如何去做，因人而异：对于新手，就直接讲明应该如何去做，细化到步骤，让其马上去执行；对于有经验者，只需要将一个大致思路；

第四，明确优先级。有时会出现一个人手头上多个任务，不知道先做那个，所以leader在安排时，有时需要对多任务设定一个优先级排序。（3）追踪目标，动态掌握项目的进程，适时进行干预确保能按时完成。

第一，leader要主动去询问、帮助成员解决问题。通过询问、了解、帮助成员解决问题，既有利于项目的顺利进行，又有利于团队的和谐融洽。由于习惯、年级等多方面因素，成员不习惯向上提问，向上反馈，特别是新成员，经常是到截至日期前一刻才会反馈出一堆问题，倘若此时再解决，时间已经不允许了，造成的结果往往就是项目拖时。越少的沟通，成员之间的了解就越少，默契配合就越差，成员之间如果一直在陌生人的情形下合作是相当不利的。Leader可以这样发问“最近**做得怎么样，有什么需要我帮助的吗？”

第二、定期举行进度会议来一次性解决问题，反馈进度。进度会议既可以让成员了解项目的进度，清楚现状，又可以根据实际情况解决出现的问题并调整计划。由于许多问题在做计划时是无法提前遇见，因此通过定期的会议来总结问题并解决问题。

第三、在风险可承担的前提下，适当放权，允许成员犯错。既可以发挥成员的积极性也可以让他领悟更深。做一个项目的开发，与大学其他社团活动最大的区别就是终止时间。一旦活动举办的时间确定下来，无论中间多少个不确定因素，无论质量好坏，活动必须举办。而项目开发因为弹性时间大，一个成员犯的错对于整个项目最后能否按时按质完成的影响的风险，leader若可以承担，就主动放权，让成员去试错。在犯错之后，及时帮他总结，解释，让他有更深的领悟，但绝不允许一个错误犯两次。

第五篇：手机安卓系统测试经验总结

手机安卓系统简介及测试经验总结

一、Android简介

Android（安卓）系统是手机或一些平板电脑等终端的操作系统，可以说是现在最流行的系统之一。是目前最流行的手机智能平台，目前广泛的应用在智能手机上，在智能手机领域掀起了“Android风暴”。Android系统在不久的将来即将应用在平板电脑，微波炉，电冰箱等等电器上，发展前景很好。尤其是Android操作系统的平板电脑更值得大家期待！

安卓相比塞班主要有这几个优点：

1、系统基于Linux,非常稳定，怎么折腾都不死机，不像塞班三天两头死机。

2、系统代码年轻并且精简，手机运行比较快！不像塞班手机用一段时间后速度会变慢。

3、系统升级后以前的软件都可用，目前支持的软件极多达三万种！不像塞班系统一升级以前软件都作废，用户毫无办法智能干瞪眼。

4、安卓操作界面很人性化，像苹果手机一样很多界面都是动态的，酷炫且华丽，并且在图标甚至空白处长按三秒有类似电脑鼠标右键的快捷菜单弹出，很方便。相比之下塞班界面设计较保守，诺基亚的触屏机号称多次升级，其实还是老一代的手机N73加触控点按。

Android是基于Linux开放性内核的手机操作系统，Android系统由操作系统、中间件、用户界面和应用软件组成。它采用软件堆层（Software Stack，又名软件叠层）的架构，主要分为三部分。底层以Linux内核工作为基础，由C语言开发，只提供基本功能；中间层包括函数库Library和虚拟机Virtual Machine，由C++开发。最上层是各种应用软件，包括通话程序，短信程序等，应用软件则由各公司自行开发，以Java作为编写程序的一部分。

二、Android系统各个版本及功能

1、Android 1.1 2008年9月22日，由HTC代工生产T-Mobile定制的HTC G1正式面世，Android系统终于面向世人。作为全球首款使用Android操作系统的手机，该机支持WCDMA/HSPA网络，并支持Wi-Fi。

主要功能有闹钟，API示例，浏览器，摄像头，联系人，开发工具包，拨号应用，电子邮件，地图（包含街景），音乐，图片，设置。

2、Android 1.5(Cupcake)

2009年4月30日，官方1.5版本的android（基于 Linux Kernel 2.6.27）发布。主要的更新如下。

1.拍摄/播放影片，并支持上传到Youtube 2.支持立体声蓝牙耳机，同时改善自动配对性能。

3.采用最新的Webkit技术的浏览器，支持复制/粘贴上和页面中搜索。4.GPS性能大大提高，提供屏幕虚拟键盘。

5.主屏幕增加音乐播放器和相框widgets，应用程序自动随着手机旋转。6.短信，Gmail,日历，浏览器的用户接口大幅改进，如Gmail可以批量删除邮件。

7.相机启动速度加快，拍摄图片可以直接上传Picasa，来电照片显示。代表机型有HTC Magic G2、HTC HeroG3、HTC TattooG4等。

3、Android 1.6(Donut)2009年9月15日，1.6（基于Linux Kernel 2.6.29）版本软件开发工具包发布。主要的更新如下。

1、重新设计的Android Market,手势支持，支持CDMA网络。文字转语音系统（Text-to-Speech），快速搜索框，全新的拍照接口。

2、查看应用程序耗电，支持虚拟私人网络（VPN）

3、支持更多的屏幕分辨率，支持OpenCore2媒体引擎。

4、新增面向视觉或听觉困难人群的易用性插。

代表机型：索尼爱立信X10，在Android 1.6还没有普及的情况下，谷歌又出招了，带来的是Android 2.0固件。

4、Android 2.0/2.0.1/2.1(Eclair)2009年10月26日，2.0（基于Linux Kernel 2.6.29）版本软件开发工具包发布。主要的更新如下。

1、优化硬件速度，“Car Home”程序，支持更多的屏幕分辨率。

2、改良的用户界面，新的浏览器的用户接口和支持HTML5

3、新的联系人名单，更好的白色/黑色北京比率，改进Google Maps 3.1.2

4、支持Microsoft Exchange，支持内置相机闪光灯。支持数码变焦。

5、改进虚拟键盘，支持蓝牙2.1，支持动态桌面设计。代表机型：摩托罗拉XT800,HTC G6

5、Android 2.2/2.2.1(Froyo)2010年5月20日，2.2（基于Linux Kernel 2.6.32）版本软件开发工具包发布。主要的更新如下。

1、支持将软件安装至扩展内存，支持Adobe Flash 10.1。

2、加强软件即时编译的速度，新增软件启动“快速”至电话和浏览器。

3、USB分享器和WiFi热点功能，支持在浏览器上传档案。

4、更新Market中的批量和自动更新。

5、增加对Microsoft Exchange的支持，集成Chrome的V8 JavaScript 引擎到浏览器。

6、加强快速搜索小工具，速度和性能的优化。

7、更多软件能透过Market更新，类似2.0/2.1中的Map更新。代表机型：三星I9000

6、Android 2.3(Gingerbread)2010年12月7日，Google正式对外发布了他们的下一代只能手机操作系统2.3。主要跟新如下。

1、游戏：增加了新的垃圾回收和优化处理时间，以提高对游戏的支持能力，原生代码可直接存取输入和感应器时间，EGL/OpenGL ES,OpenSl ES，新的管理窗口和生命周期的框架。

2、多媒体：支持VP8和WebM视频格式，提供AAC和AMR宽频编码，提供了新的音频效果器，比如混响，均衡，虚拟耳机和低频提升。

3、通讯方式：支持前置摄像头，SIP/VOIP和NFC（近场通讯）

4、简化界面，速度提升，更快更直观的文字输入，一键文字选择和复制/粘贴，改进电源管理系统，新的应用管理方式。

代表机型：三星代工的谷歌Nexus S

7、Android 3.0(Honeycomb)谷歌在2011年2月3日发布了专用于平板电脑的android 3.0系统，它带来了很多激动人心的新特性。这是首个基于Android的平板电脑专用操作系统。新功能如下。

1、多任务处理：可在桌面中方便使用所有开放性应用软件。

2、桌面工具：可建立在数据合成基础上，正如在桌面小窗口中可以同时设置多种应用软件。此外，还有不同的桌面工具，包括竖屏，横屏以及滚动屏。

3、通知系统：在屏幕右下方会跳出通知短消息。消息短信中可包括多种数据，例如用户朋友通过Iming发送消息时的头像照片。此外用户还可以通过该功能快速访问应用软件，如媒体播放器等。

4、硬件加速：通过简单添加一行代码，2D硬件加速可被使用在现在的Android应用软件上。5、3D功能：有新的3D图像引擎功能Renderscript，该功能由3D公司War Drum Studios负责开发。

6、视频通话：设有前置摄像头。可通过Google Talk工具支持视频通话。

8、Android 3.1 2011年5月11日在Google I/O开发者大会宣布发布。新版本最大的改变是将Android手机系统跟平板系统再次合并，从而方便开发者。具体更新内容如下。

1、支持基于android Market的电影租赁业务，可以通过自身的显示器或在更大的屏幕上进行观看。

2、全面支持的Adobe Flash Player 10.2，提升网页Flash的显示性能。

3、支持调整部件大小，方便用户进行自定义主屏幕。

4、支持键盘，鼠标，游戏手柄，数码相机等USB外围设备和配件。

5、支持蓝牙扩展功能，可以通过Google talk 进行视频通话。

6、支持图片传输协议，支持多种USB设备直接导入数据到平板中，而无需电脑支持。

9、Android 3.2 谷歌2011年7月13日发布了Android 3.2操作系统，Google为Android3.2增加了屏幕分辨率缩放兼容的新功能。Android 3.2不会带来许多的新功能，只是一个BUG修复更新，让平板机运行更稳定。3.2也将会成为Honeycomb的最终版本。更新内容包括。

1、错误修复和硬件加速优化

2、新版本的movie studio，Movies和Music

3、桌面小部件自由缩放

4、手机应用缩放兼容，SD卡支持，7英寸平板和高通处理器获得支持。还有一个是Android 2.4将2011年第四季度发布，代号为IceCream Sandwich将是所有设备通用的，Google将拿出同一的UI，增加更多UI元素和效果以减轻开发者的负担。而且新增的API将会支持脸部跟踪，现场展示了一个使用了脸部跟踪识别API的应用。

三、Android系统优势

（1）开放性

在优势方面，Android平台首先就是其开放性，开发的平台允许任何移动终端厂商加入到Android联盟中来。显著的开放性可以使其拥有更多的开发者，随着用户和应用的日益丰富，一个崭新的平台也将很快走向成熟。

开放性对于Android的发展而言，有利于积累人气，这里的人气包括消费者和厂商，而对于消费者来讲，最大的受益正是丰富的软件资源。开放的平台也会带来更大竞争，如此一来，消费者将可以用更低的价位购得心仪的手机。

（2）挣脱束缚

在过去很长的一段时间，特别是在欧美地区，手机应用往往受到运营商制约，使用什么功能接入什么网络，几乎都受到运营商的控制。自从iPhone上市，用户可以更加方便地连接网络，运营商的制约减少。随着EDGE、HSDPA这些2G至3G移动网络的逐步过渡和提升，手机随意接入网络已不是运营商口中的笑谈。

（3）丰富的硬件

这一点还是与Android平台的开放性相关，由于Android的开放性，众多的厂商会推出千奇百怪，功能特色各具的多种产品。功能上的差异和特色，却不会影响到数据同步、甚至软件的兼容。好比你从诺基亚Symbian风格手机一下改用苹果iPhone，同时还可将Symbian中优秀的软件带到iPhone上使用、联系人等资料更是可以方便地转移。

（4）开发商

Android平台提供给第三方开发商一个十分宽泛、自由的环境。因此不会受到各种条条框框的阻挠，可想而知，会有多少新颖别致的软件会诞生。但也有其两面性，血腥、暴力、情色方面的程序和游戏如何控制正是留给Android难题之一。

（5）无缝结合的Google应用

如今叱诧互联网的Google已经走过10历史。从搜索巨人到全面的互联网渗透，Google服务如地图、邮件、搜索等已经成为连接用户和互联网的重要纽带，而Android平台手机将无缝结合这些优秀的Google服务。

四、Android系统在手机上表现的缺陷

每一款手机都有缺陷，每一个操作系统也不是没有BUG。即使是IPHONE4也有许多不尽如人意的地方。

一、Android系统手机泄密信息时代很严重

二、拨号后自动挂断电话通话BUG频繁出现

三、对硬件配置要求高制造成本增加

四、系统费电严重安卓手机续航不足

五、系统计算器计算有偏差

五、Android系统手机端应用程序测试

5.1、安卓系统应用程序安装与卸载

（1）.应用程序的安装：安卓系统的安装文件一般为.apk文件，把安装文件放到手机存储卡中，在“文件管理器”中就可以找到相应的安装文件，点击进行安装。

（2）.应用程序服务的开启与停止：在“设置”——“应用程序”——“正在运行的服务”中列出了手机现在开启正在运行的服务，点击相应的服务可以开启或关闭服务。

（3）.应用程序的卸载：在“设置”——“应用程序”——“管理应用程序”中，找到相应的应用程序，可以对程序进行卸载、强行停止和清除数据操作。

5.2、网络配置

（1）.WLAN设置：通过“设置”——“无线和网络”——“WLAN”来连接WLAN，并可以点击“WLAN设置”来进行设置参数。

（2）.无线网络连接：如果有需要可以在“设置”——“无线和网络”——“移动网络”来选择或新建移动网络。（比如，新建公安内网）

（3）.蓝牙设置：通过“设置”——“无线和网络”——“蓝牙”来打开蓝牙，并可以通过“蓝牙设置”来设置其参数。

5.3、系统测试注意要点

（1）.安装时系统能否正常安装成功；（2）.测试系统能否正常卸载；（3）.系统界面信息是否正确；

（4）.由于系统容易触碰导致误操作，测试系统有没有相应的提示信息；（5）.登录系统时检查网络连接是否正常，在不同的网络状态下进行登录观察登录情况；

（6）.测试查询到的信息和加载的信息是否正确；

（7）.测试信息能否通过网络上传到数据库，上传的数据是否保持正确，数据上传后重点测试数据库的数据情况；

（8）.如果有记录或者图片保存到手机端存储器，检查是否能正常保存，保存的信息是否正确；

（9）.测试时注意系统崩溃情况；

（10）.进行登录、查询、上传时注意响应时间，等待响应时间不要太长；（11）.测试时用一台手机登录几个账号或者用几台手机登录一个账号，进行操作，检查数据是否有混乱现象；

（12）.手动更新时，查检是否需要先卸载旧版本后再进行新版本的安装；或者不卸载旧的版本进行新版本安装，测试新版本能否正常安装，安装后是否覆盖旧版本；

（13）.如果有自动更新的系统，测试系统能否正常自动更新，更新后系统是否保留旧版本的一些数据和设置；

（14）.对应用程序中的“系统设置”中的参数进行设置，检查设置参数后系统是否有相应的变化。

（15）.手机端需求进行计时的，要对规定的时间内、设定的时间点和设定的时间点之外的时间进行测试和统计，检查在不同的时间段系统的变化、数据库中数据的变化。

（16）.手机应用程序运行时需要连接其它设备的，如打印机、扫描仪，检查能否正常通过无线网络或者线路正常连接并使用。

六、Android的发展趋势

相对于iPhone的成功，Android目前还仅拥有很小的，尽管是增长的，移动设备操作系统的市场份额。我们已经看到开源移动操作系统Symbian在2009年占有51%市场份额已经被侵蚀到现在41.2%的份额。同样RIM在2009年占有19% 的市场份额，已经缩减到17.2%。在同一时期，由于智能手机销售驱动，Android的市场份额已从1.9%上升到17.2%，在这个由Symbian和RIM长期占主导地位的市场有着惊人的增长。Android智能手机开始像滚动的雪球那样迅速增长。该系统已应用于60多个型号的手机中。使用Android也已经延伸到其他便携式和嵌入式设备（平板电脑、电子书、上网本、高清电视等）。