谈项目管理和软件测试过程

谈项目管理和软件测试过程（一）

 

1. 软件测试在公司的组织保障是基础

1.1 研发部组织结构介绍

以华友公司研发部的组织结构为例，测试部门属于研发部副总裁直接管理，见如下结构图

公司研发部的组织结构图





对于从事软件研发的组织来说，工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理，以及其它人员，如文档编制人员和美工人员 / 系统硬件管理人员等。根据职能需要，可以以半独立方式进行部门和项目的矩阵管理，即职员要对项目经理 / 组长负责，也要对部门经理 / 总监负责，工作考核由双方共同完成，标准的组织应包括技术开发部 / 组（主要是编码和设计人员），产品开发部 / 组（产品需求和项目管理），测试部 / 组，配置管理部 / 组（因为配置管理人员基本上是按 20 个技术人员配一个配置管理人员，所以一般部门规模较小，或者只是配置管理组），软件质量保障部 / 组，其它部 / 组（如系统 / 文档 / 美工等）。华友公司组织结构中，研发部是公司软件研发的核心部门

产品研发 Ⅰ 部、 Ⅱ 部、和应用研发部主要负责：



与软件产品部或内容产品部配合，协助完成内容产品的可行性、合理性分析；

平台、网关、应用产品的研发项目的立项和方案评审；

研发项目的概要设计、详细设计工作；

研发项目的编码、单元测试工作；

组织公司相关部门进行研发产品的培训；

协助相关部门做好产品的售前技术支持工作；

协助相关部门进行软件的安装与调试；

根据相关部门的要求做好产品的售后服务工作，保障软件的运行正常。

测试部隶属研发部，主要职责如下：

与内容产品部和软件产品部配合完成软件需求分析讨论，并根据需求说明书制订《项目测试方案》，编写《测试用例》，建立测试环境；

负责完成研发部各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改升级软件的模块测试和系统测试；

建立、推广并维护实施软件版本管理系统 CVS 和 VSS ；

使用并维护软件缺陷管理系统 Bugzilla ，负责软件问题解决过程跟踪记录；

负责推广实施软件开发文档规范化工作，管理研发产品相关文档；

负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报告；

负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。

1.2 软件产品研发各部门的组织结构分解

1) 华友公司从 2003 年 10 月开始，对项目组制订明确指标的独立考核，各开发部门是技术总监带队，再细分各项目经理具体负责项目计划和执行，对项目具体开发成员进行分工。对于测试部门制订年度测试部门任务计划 / 考核表，如 SMS 业务销售额指标完成：目标 1 ： 9900 万（奖金提取比例为 0.01 ％）；目标 2 ： 16800 万（奖金提取比例为 0.02 ％）；目标 3 ： 23200 万（奖金提取比例为 0.03 ％）

详细给出财务目标和业务运营目标。

在每周的开发经理工作会议上交流报告任务进展情况，并提出最近测试需求，测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交流完成测试执行工作。测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交流掌握下周或近期可能测试任务，所有其他外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度。

2) 工作汇报关系为 :

开发部门： Team Member->Team Leader-> 研发总监 -> 研发部副总裁 -> 总裁。

测试部门：测试工程师 -> 测试小组经理 -> 测试部经理 / 总监 -> 研发部副总裁 -> 总裁。

3 ）项目成员结构：

公司通常的开发项目组为 6 到 8 个开发人员，最多不超过 10 人。

华友公司的经过三次改造后的组织结构和项目组结构，各个业务部门分类非常细，任务明确，软件开发的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总监和副总裁，层层管理，沟通渠道畅通。而在软件测试上，由于有限的测试资源，首先体现在公司的组织结构上，集中表现为测试部门不得不面对公司级管理部门的缺失和管理的交叉上，没有质量管理部门，部门质量管理工作测试部门兼做。公司从成本角度考虑，测试部门规模较小，测试人员总数不超过 10 人，几乎每个测试人员接收处理 10 个开发人员的测试任务需求。从实际情况出发，首先明确测试部门和软件开发部门相对独立的组织关系，保证测试人员的工作不受开发小组的控制，实现测试客观、公证。华友公司要想有效地保障产品质量，首先就要在构架合理的组织结构和测试流程上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构和流程不合理，其他方面再下功夫也是徒劳。

从实践经验看，一年前首先成立测试部，把属于开发部门的测试工程师归口到独立的测试部门管理，其次建立规范的测试流程，与开发部门交流，要求每周提出测试需求，再根据现有的资源制订每周测试计划，同时向人力资源部门提出招聘计划，随着测试工作的成绩不断被开发部门和上级领导认可，再推广实施软件开发过程规范化的管理，通过测试实践的优良成绩来确立测试部门在公司的地位和作用，经过一年的奋斗测试部门从无到有，从最初两人到现在十人，软件配置管理和缺陷跟踪系统已经被 60% 的开发人员自愿使用和接收。 总结本人在华友一年多测试工作经验，深深体会到在国内从事软件项目开发难、从事软件测试和质量保证工作更难，需要具备扎实的技术功底同时，不断提高测试项目管理能力，寻找工作的突破口。世上无难事，只怕有心人，但是只要你努力献身于软件测试工作，打出一片天地是有可能的。

 

谈项目管理和软件测试过程（二）

 

2 ．配置管理系统是项目经理的 " 眼睛 " ，是软件测试有效实施的前提

在软件质量体系的诸多支持活动中 , 配置管理系统处在支持活动的中心位置 , 它有机地把其它支持活动结合起来 , 形成一个整体 , 相互促 进 , 相互影响 , 有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的 " 矿藏资源 " 有了明确的位置，可以主动积极开展测试工作。

2.1 项目管理存在的主要问题

华友公司测试部门去年刚成立时，以建立、规范和推广使用配置管理系统 CVS 为突破口，同时建立缺陷跟踪系统 Bugzilla 提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状 , 。

存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用 , 没有建立起协同作战的氛围 , 没有科学的软件配置管理流程 ; 技术上只重视系统和数据库、开发工具的选择 , 而忽视配置管理工具的选择 , 导致即使有些项目有配置管理的规程 , 也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题 : 调查说明华友研发成员的变动的比率达到 30% ，几乎每周都有新加入的员工或者辞职人员， 一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档，甚至阅读同行代码，达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作，最大程度减少对项目开发造成的损失。

存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况 , 项目经理也不知道各开发人员的具体工作 , 项目进展随意性很大 , 可 " 左 " 可 " 右 " 。 " 左 " 时按领导下达的 " 期限 " 进行 , 到期时 , 似乎一切已顺利完成 , 大家一阵胡弄 , 交差完成 , 反正领导看的是界面 , 至于里面是什么 , 留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。 " 右 " 时则项目工期无休止地延期。对我们软件工程来说 , 总的特点是先 " 左 " 后 " 右 " 。在领导面前表现 " 左 ", 在用户面前表现 " 右 " 。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。

存在问题三、项目之间沟通不够。各个开发人员各自为政 , 每个项目经理都像个 " 地主 " ，编写的代码不仅风格各异 , 而且编码和设计脱节。每个项目组的人力资源和硬件资源成了 " 私有财产 " ，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免 , 进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。 开发大量重复 , 留下大量难维护的代码。典型案例是有个短信项目 D 两年来在这个开发人员 Y 的研发支持下运转效益很好，但是三个月之前，开发人员 Y 因为待遇问题和公司领导谈判失败，提出辞职。项目 D 仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员 Y 来协助，因为没有文档记录， Y 忙于新公司的工作也不能解决修改。

存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富 , 代码的重用率是相当高的 , 如何建好知识库 , 用好知识库对公司优质高效开发产品 , 具有重大的影响。但开发人员的一句名口号是 :" 叫我干什么都可以 , 但别叫我看别人的程序 " 。当然 , 开发人员的工作态度要转变 , 但客观上有一个很重要的原因是 : 前人留下的程序既无像样的文档 ( 即使留下了文档 , 其与源程序也严重脱节 ), 开发风格又不统一 , 就像一堆垃圾 , 要开发人员到垃圾中去捡破烂 , 从这个角度上看 , 开发人员的要求是合理的。

存在问题五、测试工作不规范。仍然停留在 " 小姑娘做测试 " 的底水平上，传统的开发方式中 , 测试工作只是人们的一种主观愿望 , 根本无法提出具体的测试要求 , 加之开发人员的遮丑 , 测试工作往往是走一走过场 , 测试结果既无法考核又无法量化 , 当然就无法对以后的开发工作起指导作用。

存在问题六、虽然项目施工时间不长，但软件版本更新周期过短 , 几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。 由于应用软件的特点 , 各个不同的施工点有不同的要求 , 开发人员要手工地保持多份不同的拷贝 , 即使是相同的问题 , 但由于在不同地方提出 , 由不同人解决 , 其做法也不同 , 程序的可维护性越来越差。久而久之 , 最后连自已都分不清楚了 , 代码的相互覆盖现象时有发生 , 且这苦水还无法倾诉 , 因为怕别人笑话 , 甚至别人问起 , 还得想法搪塞 , 可谓费尽苦心。

2.2 建立配置管理系统 , 规范项目管理流程，建立知识库的同时节约项目费用

针对以上问题 , 利用自己在 Beijing Precom Inc, 普天润汇等公司积累的经验，建立配置管理系统 CVS, CVS 的全称是 Current Version Control. CVS 是一种 GNU 软件包 . 由 Intersolv 公司开发，它明确的将源文件的存储和用户的工作空间独立开来 , 并使其有利与并行开发 . 这个工具属于 Open Source ， ,CVS 可以在 intenet 上很方便的得到 . 它的源码在 ftp://202.113.29.4/pub1/unix/cvs 它的说明文档在 ftp://202.113.29.4/doc/cvs. 任何人可以很方便的下载 . 目前他的最新版本是 2..10.8 。 不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略 , 取得了很好的成效。

2.2.1. 节约费用

(1) 缩短开发周期

利用 CVS 对程序资源进行版本管理和跟踪 , 建立公司的代码知识库 , 保存开发过程中每一过程版本 , 这样大大提高了代码的重用率 , 还便于同时维护多个版本和进行新版本的开发 , 防止系统崩溃 , 最大限度地共享代码。同时项目管理人员可以通过 Version 系统查看项目开发日志 , 测试人员可以根据开发日志和不同版本对软件进行测试 , 工程人员可以从版本控制系统上得到不同的运行版本 , 并且可以安装在 Web Server 或在 Unix 操作系统上命令行方式存取供外地施工人员存取最新版本 , 无需开发人员亲临现场。



利用 CVS 系统 , 可以大大提高开发效率 , 避免了代码覆盖、沟通不够、开发无序的混乱局面 , 如果利用了公司原有的知识库 , 则更能提高工作效率 , 缩短开发周期。

(2) 减少施工费用



利用 CVS 进行软件配置管理后 , 建立开发管理规范 , 把版本管理档案挂接在公司内部的 Web 服务器上 , 工程人员可以通过远程进入内部网 , 获取所需的最新版本。开发人员无需下现场 , 现场工程人员通过对方系统管理员收集反馈意见 , 书面提交到公司内部开发组项目经理 , 开发组内部讨论决定是否修改 , 并作出书面答复。这样做 , 可以同时响应多个项目点 , 防止开发人员分配到各个项目点、分散力量、人员不够的毛病 , 同时节约大量的旅差费用。



2.2.2. 有利于知识库的建立

(1) 代码对象库



软件代码是软件开发人员脑力劳动的结晶 , 也是软件公司的宝贵财富 , 长期开发过程中形成的各种代码对象就像一个个零件坯一样 , 是快速生成系统的组成部分。长期的一个事实是 : 一旦某个开发人员离开工作岗位 , 其原来所作的代码便基本成为垃圾 , 无人过问。究其原因 , 就是没有专门对各人的有用对象进行管理 , 把其使用范围扩大到公司一级 , 进行规范化 , 加以说明和普及。 CVS 系统为开发管理提供了一个平台和仓库 , 有利于建立公司级的代码对象库。

(2) 业务及经验库

通过 CVS 的注释 , 可形成完整的开发日志及问题集合 , 以文字方式伴随开发的整个过程 , 不依某个人的转移而消失 , 有利于公司积累业务经验 , 无论对版本整改或版本升级 , 都具有重要的指导作用。

2.2.3. 规范管理

(1) 量化工作量考核

传统的开发管理中 , 工作量一直是难以估量的指标 , 靠开发人员自已把握 , 随意性相当大 ; 靠管理人员把握 , 主观性又太强。采用 CVS 管理后 , 开发人员每天下班前对修改的文件 Check In, 其中记述当天修改细节描述 , 这些描述可以作为工作量的衡量指标。

(2) 规范测试

采用 CVS 以后 , 测试有了实实在在的工作 , 测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试 , 对测试人员也具有可考核性 , 这样环环相扣 , 大大减少了其工作的随意性。

(3) 加强协调与沟通

采用 CVS 后 , 通过 VSS 文档共享系统和 Bugzilla 缺陷跟踪系统 , 大大加强了项目成员之间的沟通 , 做到有问题及时发现、及时修改、及时通知 , 但又不额外增加很多的工作量。

 

谈项目管理和软件测试过程（三）

 

3 ．性能测试是软件测试专业化的核心所在

从华友实践看，软件测试对于产品经理、开发经理和市场经理都有所认识，他们大部分人会认为功能测试工作他们能够很好的完成，产品经理是公司对于业务最熟悉的 一批人，他们对于测试工程师最急切的需求是你帮我实施产品的性能测试工作，他们听说过性能测试，我们的产品投入在线运行后碰到的最大故障是大用户量访问业务是机器凼机，或停止正常的服务，每次故障，几乎给公司的收入都造成很大损失。如果测试部门能有一套有效的性能测试手段，就确立了测试部门在项目开发过程中关键地位。

性能测试在华友软件的质量保证中起着非常重要的作用，将性能测试概括为四个方面： Wap 无线应用服务在手机用户端性能测试、 Web/Wap 应用服务在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下， 四方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

3.1 Wap 无线应用服务在手机用户端性能测试

如今人人用手机都追求时尚，时尚体现在款式 , 品牌和功能。手机产品功能的日新月异，移动增值业务功能层出不穷，从最初的短信、彩信、铃声到 GPRS,CDMA,K-Java, Brew 手机 , 功能的多样性带来手机用户端软件系统测试的复杂性。众所周知 , Java 手机吸引人之处是能提供智能的 , 个人化的互动服务 , 例如 : 动态产生个人化的股市服务 , 显示图形 , 动画 , 实时路况 , 气象报告 , 数字照像 , 玩游戏等 , 部分服务能直接于用户端执行。



为了提供如此生动的服务 , 移动通信系统要能给终端用户在无线装置上提供接入互联网的功能 , 要能储存、提取、管理、计算、结帐、下载软件服务 , 并使内容提供商能提供丰富的声像多媒体内容 , 形成广大的个人化交互式服务环境。 而作为移动用户 , 可将手机视作虚拟机 , 能随时、随地在适当的装置上存取应用 , 享受服务。 这确是一种时尚。



当前 , 对于不同品牌的手机 , 它们所用的平台 ( 指 CPU 和操作系统 ) 各不相同 , 由于采用不同的设计方案 , 各设计之间缺乏兼容性 , 操作系统和二进制代码都不兼容。 当手机运行需要大量内存时 , 特别是随着接入互联网 , 手机用户要求能使用个性化的 交互式应用软件 , 应用程序运行在虚拟运行环境下时 , 问题显得尤为突出。 所以 , 有必要建立一种标准的通用运行平台 , 达到在合适的成本下提供统一的交互式应用软件运行环境。 但是 , 除非该平台是基于完全标准的器件 , 否则是难以达到要求的。

标准的通用的运行平台是满足运营商 , 软件开发商 , 和终端用户三者综合要求的解决办法。 理想的环境必须具备以下性质 :

(1) 、平台应提供二进制兼容性。 可执行软件是二进制目标码 , 需要在处理器和应用软件目标码之间建立沟通 ;

(2) 、平台必须包括微处理器 , 或一个与微处理器机器代码相离的通用机器码仿真器 ;

(3) 、平台应包括带有应用程序接口 API 及支持一致性图形用户界面 GUI 相应功能的操作系统。 API 是执行典型操作功能的软件功能库 , 例如打开文件 , 读写数据 , 配置和管理内存 , 处理事件 , 显示文档和图形等。 为使应用软件真正做到可移植 , 装置上必须有公共功能集 , 并让软件开发者能通过一致性 API 扩展功能 ;

(4) 、平台不应要求过多的系统资源 , 可移植性设备不应使成本上升太多 ;

(5) 、平台应对功率有高效率 , 尤其考虑用电池供电的设备 ;

(6) 、由于要在互联网上应用 , 安全性也是重要因素。

以 Java 手机软件测试为例潜在的测试问题和解决办法

Java 有移植性好和其它很多优势 , 但用在手机上 , 速率和功耗仍是个瓶颈。 Java 带来的新问题是执行速度慢 , 消耗功率大。 与 PC 不同的是 , 手机资源有限 , 一般流行的手机中 CPU 的速率为 26MHz, 或 52MHz, 带 128M 闪存 , 8Mb, 16M 或 64Mb 内存 , 没有硬盘 , 由电池供电 , 体积小 , 空间窄。 系统慢的原因是 :

(1) 系统必须同时运行两套软件 : Java 应用和虚拟机 JVM;

(2) Java 软件需要被翻译成自然 CPU 指令 ;

(3) Java 平台是基于栈 ( 相对于寄存器 ) 结构的 , 导致更多的内存存取。

因而 , 如何对执行 Java 加速成为关键。 加速处理数据和图形 , 这对手机上互联网和多媒体的应用具有重要意义。 要克服这些问题 , 提高 Java 软件性能 , 可能的方法有四种 :

(1) 提高微处理器速率。 然而 Java 软件性能与时钟频率并不成线性关系 , 微处理器运行一般比内存存取时间高 2-10 倍 , 增加时钟频率只会增加等待周期。

(2) 对 JVM 软件进行优化。 这可能涉及到要用汇编语言对字节码翻译环路进行编程 , 而这会导致 JRE 变得与微处理器类别有关。 而与可移植相抵触 ;

(3) 编译。 将软件直接编译到微处理器的自然机器语言。 但是这会增加内存的开销 , 也不节省能量的消耗。

(4) 采用基于硬件的加速器。 这可以做到提高性能 , 保障能量和成本的有效性。 被手机设计厂商认为是较理想的措施。 通用型 Java 加速芯片于今年年初问世。

3.2 分析 Web/Wap 应用服务在客户端性能的测试

Web/Wap 应用服务在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、大数据量测试和速度测试等，其中并发性能测试是重点。

并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（ Load Testing ）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、 CPU 负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（ Stress Testing ）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

我们公司自己组织力量同时委托第三方软件 HG 公司开发 Hawa 网站的一套应用 Avatar 形象系统的时候 , Avatar 形象在网站业务中占有着重要的位置，网站上的很多业务都是围绕 Avatar 开展。 这套系统能不能承受大量的并发用户同时访问 ? 成为这个网站能否成功的关键，也是这次两个公司合做开发能否顺利完成的关键。这类问题最常见于采用联机事务处理 (OLTP) 方式数据库应用、 Web 浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

Web 软件测试实例说明：哈哇网站 Avatar 形象系统软件。 Avatar 形象系统在上线试运行三个月后，所有的功能测试顺利完成，软件功能缺陷也修改完毕。但是，性能问题越来越成为项目经理关心的焦点，我们测试部门借助比较熟悉的压力测试工具 Web Stress 实施客户端性能测试进行 100 ， 500 ， 1000 等并发用户访问。每次测试主要在基于 URL ： http://avatar.hawa.cn/index.jsp 的基础上，与 HG 公司实时交互地进行多种情况下的测试。按照 HG 公司要求主要针对并发数为 1000 和 500 的情况下，尽量准确的对 Avatar 系统的性能压力进行模拟测试；并排除所有不是从 web 服务器（即 avatar.hawa.cn ）上得到的 URL ，即只对 /index.jsp 等页面进行测试。三次结果后，尽管程序优化、运行服务器配置多次修改，仍然存在用户量并发数达到 1000 ，服务质量下降，页面方面时间超过正常显示时间。这里有最后一次测试结果与前几次大致相同。但是本次测试，是用多客户端测试，按原理是应该比以前的单机测试准确度要高，但其结果是比用单机测试的时间还要长，当并发数达到 1000 时，其页面的最长响应时间在 80 多秒（而单机测试时时 59 秒多）！第三次又发现 ISP 网络 100MB 带宽实际上不到 20MB ，也是影响用户服务的关键因素之一。

这个性能问题经过 HG 公司开发人员近三个月改进， /index.jsp 页面的 1000 个用户并发响应时间 10 秒左右。对于我方采用的 Web Stress 性能测试工具 HG 公司也认同其测试结果的客观性，公司因为该软件性能问题推迟支付对方经费 200 万圆三个月，更重要的是软件的性能问题得到很好解决，并与 HG 公司的关系很好保持。另外一个更大的收获是测试部门在 Web 产品部门有个很好的形象，他们每次新软件产品需求提出、产品上线都主动要求测试部门参与并实施严格测试。

如何模拟实际情况呢 ? 找若干台电脑和同样数目的操作人员在同一时刻进行操作 , 然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况 , 这样就需要压力测试工具的辅助。

测试的基本策略是自动负载测试，通过在一台或几台 PC 机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力 , 就为最终用户规划整个运行环境的配置提供了有力的依据。

并发性能测试前的准备工作

　　

测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机 / 扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　

一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

　　

测试工具：成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有 QALoad 、 LoadRunner 、 Benchmark Factory 、 Webstress 和 AB-Apache 等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

　　

测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

　　

在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　

并发性能测试的关键的是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择 Java Script 监控对象，手工编写脚本，可以达到测试目的。

　　

采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

　　

3.3 应用在网络上性能的测试

应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

　　

网络应用性能分析

　　

网络应用性能分析的目的是准确展示网络带宽、延迟、负载和 TCP 端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如 Application Expert ，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用 Application Expert 调整应用在广域网上的性能； Application Expert 能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

　　

网络应用性能监控

　　

在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少 PC 正在访问 LAN 或 WAN ；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是 Network Vantage 。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

　　

网络预测

　　

考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具 PREDICTOR 可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

　　

从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR 提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

3.4 应用在服务器上性能的测试

　　

首先分析服务器的类型，服务器的划分起码可以依据四大部分进行。一是根据整个架构，可分为 IA 服务器和 RISC 服务器；二是按照硬件配置的差别可分为工作组级、部门级、企业级；三是按照具体安装的应用软件可分为 Web 服务器、文件服务器、 FTP 服务器、 E-mail 服务器、数据库服务器等等；四是根据操作系统分为 WINDOWS 阵营、 UNIX 阵营。这四大分类有所关联，但其中按应用分类是最能给用户清晰概念的。因为用户在采购选型时，总是先想好了拿它做什么用的。 Intel 最近所提出的前端（用于接入等）、中端（用于各种应用和中间件）和后端（用于数据库、在线分析等）的分类办法，这也是从应用角度考虑的。



分析服务器性能指标莫不聚焦于三大指标： CPU 、 I/O 及 Web 。如果大家还记得图灵机的话，应该对计算单元和输入输出的重要不会抱什么怀疑的态度。至于选择 Web 作为衡量服务器性能的要点，只能说是网络的力量。 Internet 的大行其道让我们很难想象有服务器孤岛出现。工程师往往通过给与被测服务器不断增加的并发式文件读写、数据库操作以及 HTTP 访问来取得其最大的潜值。



以 Web 测试为例，衡量 Web 性能一般有下列几个重要指标： HTTP 每秒交易数（ Transaction Per Second ）；每秒会话数（ Sessions Per Second ）；当前用户数（ Concurrent users ）；吞吐量（ Throughput ）。 HTTP TPS 通常也叫做每秒的点击数；每秒会话数是每秒到达 Web 服务器的用户数；当前用户数是特定时间在 Web 站点上的用户数；吞吐量是在特定时间由 Web 站点发出的数据流量带宽，它与服务器提供服务的内容和交易数相关。以上将是我们对测试结果进行评述与点评的重要技术基础。

 

谈项目管理和软件测试过程（四）

 

4. 项目管理开发环节的测试任务

当公司构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。 下面以已经实施完成的 CYB 项目一期为例，分析华友公司在项目管理上的正在推广的具体 项目管理细节的优缺点和测试工作改进探讨：

CYB 项目一期需求：由于华友各类业务（ SMS 和 WAP 等）在不同运营商（中国联通、中国移动、中国电信等）的不同平台和在网站 http://www.hawa.cn/ 的 WEB 门户中向用户提供服务，各类业务的相互独立，为了统一管理用户信息、业务和计费等信息，并汇总进行统计分析处理，同时也为了整合各类业务系统的资源，建立公司的业务运营支撑系统。

4.1 开发阶段和项目周期

开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。明确项目经理为 D ，项目组开发程序员六人，项目第一阶段周期 3 个月，项目需要完成的功能：

1) 实现用户信息的统一管理，包括：用户基本信息，用户使用业务的积分，用户的定制 / 退定信息的管理

2) 实现各类业务信息的集中管理，包括：短信业务、 WAP1.2 、 WAP2.0 、 JAVA 、彩铃等各种业务

3) 实现计费信息的统一管理

4) 提供客服功能

5) 提供统计分析功能

6) 提供统一的标准接口，分别与各业务子系统及运营商的系统相连接

7) 提供网络管理、监控等功能

在这个阶段，测试经理需要负责详细了解项目开发需要的需求、设计文档等，制订初步的测试方案，根据测试任务的特点决定测试开发任务。实际结果表明开发阶段的最大两个问题：重视设计、不重视测试和软件质量，设计会议开了至少五次，参加会议有公司很有经验的设计人员，测试有关人员没有被邀请参加，忽视产品的性能需求，更多的关注基本功能实现；忽视需求是客服和运维人员，自以为很理解市场部提出的需求，忽视程序开发人员实现的难度和开发人员之间理解需求的差别，项目组成员之间重视口头交流，忽视文档价值。

问题解决方法：开始阶段请测试和质量保证工程师参加讨论，就会提出软件实现的性能需求；重视文档交流的价值，建立软件文档模版和版本控制机制，每次交流落实在成员理解和书面文档。

4.2 软件开发流程

华友公司原来是重视项目管理，忽视流程，一味夸大个别人努力在项目成功中的作用。经过一年痛苦的实践，开始探讨流程管理，已经启动公司的 SW-CMM 质量体系认证工作，希望建立非常规范化和系统化的软件开发流程，其流程的有很高的可执行性，并且能在实践过程中不断改进。华友公司的流程管理改进从一个项目研发的所有方面开始摸索，包括从最开始的意向、市场策划到最后软件的版本发布 (release) 上线投入商业运营，都设计有相应的流程规定，基本上已由测试部门负责推广一种能够达到规范、高效的软件开发流程。

CYB 项目经理 D 重视口头交流沟通，忽视文档交流，同时缺少与项目组成员知识共享意识；经理 D 重视与领导的交流，忽视与开发人员交流，项目实施中开发人员碰到具体问题没人协助解决，开发效率降低。虽然流程没错，但是流程涉及到开发人员出现问题也是需要重视的。流程管理的关键，以 " 人 " 为本。

目前的组织框架下，经过一年多的工作实践，深深体会到人和流程是保证项目成功的两个最关键因素。由具备项目实施基本素质的人按规范的合理化流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差一点的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。通过流程我们部门间的配合才节省宝贵时间，为项目早期完成，赢得市场主动权。

4.3 项目计划的阶段性

1) 努力做到项目计划详细、周到。 CYB 项目计划从开始有三个月计划，到修改三次以上，计划完成时间从三个月、延长到六个月、直到现在的八个月。计划已经形同虚设。实践证明不合理的计划不如没有计划，不合理的计划给领导造成错误的认识。合理的计划应该是先明确本周工作计划，对于难以预测的任务或者困难给出一个近期工作的方向，然后根据实际进展情况进行细化调整。

2) 流程中明确定义开发阶段、测试阶段。开发阶段任务没有完成，占用测试阶段计划时间，测试工作效率降低。正确的处理方式建议不要减少测试工作时间，项目开发完成时间根据实际需要顺延。

3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性 :

进入条件，输入 ;

验证方法 ;

结束条件，输出。

4) 每个阶段结束都要召开阶段结束会议。前一个阶段结束（以本阶段开发任务测试完成为标志）才能进入下一阶段。项目经理需要在每个阶段测试任务完成情况进行分析，存在的问题要充分暴露出来，以便于早点解决。 CYB 项目经理 D 采取报喜不报优的做法，在会议上常得到领导的表扬，其他项目经理常愁眉苦脸摆出人员问题、可能的技术问题、测试人员和时间问题等。实际结果最后笑的项目经理也是项目完成比较顺利。

5) 理想计划中每个活动都比较具体，每个活动的时间以天为单位。计划包括了开展质量控制活动的时间，推广说明版本控制系统和缺陷跟踪系统的使用的时间。

典型案例是公司研发用于用户信息管理的代号 CYB 项目， CYB 项目开始时副总裁牵头，由于测试人员少没有参与，开发经理们讨论设计实施方案后几乎大家一片赞美。随后项目经理 D 负责开发，他认为时间紧，省去了许多必须的文档工作。经理 D 采取报喜不报优的做法，项目文档差，过分强调计划，而忽视计划任务达到的质量，大部分项目测试没有完成就宣布开发完成，结果前三个月每次经理会上总裁都会表扬他们取得的阶段成果，我做为测试经理没有说话的机会，有一次刚讲几句，总裁马上提醒希望大家克服困难，每个组的任务都可能需要加班等。结果原计划三个月完成项目，已经过了半年发现要实现商用还需要做很多工作，具体完成时间也不确定， 可是现在每天总是强调专人测试，问文档没有，只能通过问了一次又一次的沟通方式实施测试工作， 有个不错的测试人员实在无法忍耐，辞职了，我只好安排新的测试人员应对完成任务。这个 CYB 项目遭到了整个公司的一片嘘声，虽然没有放弃，但没有商业价值了。快 9 个月的研发成本老本最清楚去那儿了。

总结教训，项目经理对计划和测试工作的高度重视、周密制定、严格执行是能够实现项目有效商业价值的基本保障。

4.4 重视 Review 的作用

按软件工程规范化流程，一般把 Review 和测试作为保证软件质量两个主要手段。测试的重要性已经成为各项目经理认识，并贯穿于开发的全过程，形成了项目组成员人人重视测试工作的氛围。 Review 则是一个非常简单有效并能尽早发现软件中错误的有效方法，项目经理在每周必须根据进展情况制订 Review 计划，可以说，任何交付物都要经技术总监参加的 Review 后才能进行基线化。目前华友公司正在建立比较详细全面、可执行性高的由 Review 流程和各种交付物的 Review Checklist 。

我们正在弥补这方面的工作流程缺陷，提出：凡事有计划，凡事必 review 。首先在开发组内部推广代码规范化工作，定期进行员工 Code Review 的工作， Code Review 是工作的重要环节。

4.5 质量管理和测试（ QA ）

公司目前没有独立的质量管理部门，暂时由测试部门测试经理作为质量保证部门的代表，监督和保证项目的进展的各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。由于公司对测试人才有着迫切的需要，因此，只好自己组建培养测试人才队伍。从现实出发，我们不可能想 IBM 和微软等大公司有雄厚的才力支持质量保障和测试工作开展，我们的工作重点放在软件测试方面。从起步三人开始的实施测试工作，首先测试工程师的工作让项目经理和上级领导发现并肯定他们的工作成果。通过对比测试人员实施测试后的模块和未实施测试的模块投入商业运营带来的很大差异，看到软件修补的高昂费用，提高了领导和项目经理对测试部门的重视程度。逐步扩大测试人员数量，增加测试队伍的规模，提高测试人员的的福利待遇成为可能。

招聘测试人员时，要把好质量关，国内联想、华为等公司一般对于测试人员待遇底，重视不够，我们需要测试认为改变这种错误认识，让优秀的人加入测试队伍。目前测试部门工程师 10 个人中有 2 个留学回国计算机方面硕士，其余几人都是计算机或相关学科本科生。尽管经验方面不够，但测试人员的素质和专业技能是国内一流的，一段时间测试团队的努力，这个部门已经成为公司业务开发的至关重要的部门。要不断提高软件测试的自动化程度，测试工作不能仅靠手工劳动来完成，更多的情况是要使用工具软件和编写测试程序来完成，培养全面的测试专业人才是项任重道远的工作。

4.6 度量数据

公司最近开始 CMM 的质量管理体系工作， CMM 中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。但是公司的项目管理定量化工作实施有一定难度，配合华友公司的绩效考核，测试部门要求项目经理重视项目中的数据收集，主要包括各种 Review 数据、测试数据以及项目组员每天的活动数据等。要求项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。测试部门提供能够进行团队项目开发的 CVS 或 VSS 等团队开发系统，可以这么说，有了这个项目团队开发系统，测试经理和项目经理就可以方便了解这个项目的开发过程。

4.7 团队精神

团队精神就好比人身体的每个部位，一起合作去完成一个动作。对公司来讲，团队精神就是每个人各就各位，通力合作。我们公司的每一个奖励活动或者我们的业绩评估，都是把个人能力和团队精神作为两个最主要的评估标准。如果一个人的能力非常好，而他却不具备团队精神，那么我们宁可选择后者。公司强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。公司不定期的对经理级别人员进行团队管理培训，在对员工不断进行相关培训，使员工的合作精神和协调精神都比刚进入公司时有较大提高。

4.8 培训

公司有专门的培训人员和培训费用计划，每半年会征集员工培训需求和建议，然后安排有关主题的培训活动。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。

4.9 配置管理

在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。

4.10 记录

记录及时、充分、比较准确。这些记录包括 : 重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。

1) 提倡与客户和其他项目组的所有往来必须邮件记录。

2) 对所有的活动都有一个跟踪落实的过程，比如对所有的 Review 记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。

3) 对所有的活动，包括对文档和代码的更改都会有一个历史记录。

4) 记录比较准确、比较客观。

以上是华友公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。

 

谈项目管理和软件测试过程（五）

 

5.1 项目管理存在问题

总结软件企业管理中易出现的如下问题，结合我公司在产品开发管理的过程中出现问题总结如下：

1) 需求说明差─ 需求不清楚、不完整、太概括、 或者不可测试，都会造成问题。

2) 不切实际的时间表─ 如果在很短的时间里要求做许多事，出现错误是不可避免的。

3) 不重视测试─ 只能根据客户意见或系统崩溃来判断系统的质量，整个公司没有质量管理部门。有些经理认为测试工作是服务工作，只有编写代码工作才是生产工作，编程人员待遇高、地位高。

4) 不断增加功能─ 在开发正在进行过程中要求增加许多新的功能，这是常见的问题。

5) 交流问题─ 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。

6 ）编写文档意识太差─90% 的开发人员不愿意花时间写文档，项目经理缺少这方面的管理考核要求，喜欢采取多次对话开会等轻松的沟通方式。

5.2 解决措施

这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合公司在项目管理方面的实践经验，笔者提出一些相应的解决方法，以供参考：

1) 可靠的需求─ 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes) 。

2 ）合理的时间表—— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

3) 尽早安排测试─ 从需求讨论开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。重视测试人员的待遇和地位问题，认识上把测试工作做为研发工作的一个重要阶段完成，他和编写代码同样重要。

4) 尽可能坚持最初的需求─ 一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

5) 沟通—— 在适当时机进行预排和检查; 充分利用团组通信工具— 电子邮件、MSN 实时对话、网络故障跟踪Bugzilla 工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档: 进行远距离联合作业及协作; 尽早使用模型，使客户的预想表达清楚。

6 ）强化文档工作— 对于每个测试任务必须有相应的需求、开发设计文档，测试任务完成后必须有测试报告，让文档成为互相沟通的基础。