谈项目管理和软件测试过程.doc
谈项目管理和软件测试过程 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 站点发出的数据流量 带宽,它与服务器提供服务的内容和交易数相关。以上将是我们对测试结果进行评述与点评的重要技术基础。