发布新日志

  • 转:软件性能测试面面观

    2009-08-19 16:41:56

    作者: 未知    来源: 51Testing博客

    软件测试,作为软件工程的一部分,随着软件生产的产业化运作应运而生,是软件生产的一个动态监控过程,对软件开发全过程进行检测,可以随时发现问题、报告问题,并重新评估新的风险,设置新的监控基准,并持续下去。软件测试是软件质量控制的过程,是对软件系统中潜在的各种风险进行评估的活动,其目的是监测和排除缺陷,以确保软件产品在可用性、功能性、可操作性等多方面满足质量需求。

      目前,软件测试已经由被动的以监测和发现错误为目的发展到从软件质量控制(SQC,Software Quality Control)开始转移到软件质量保证(SQA,Software Quality Assurance),使软件测试从单纯的缺陷检测和发现覆盖到整个软件开发过程,避免了软件开发过程中由于软件需求和设计等方面的缺陷所带来的巨大风险。一个典型的软件过程可以分为测试需求分析、测试设计、测试执行、缺陷和配置管理过程等许多个不同的阶段。在软件测试技术方面也已经被细化为单元测试、集成测试、系统测试、用户验收测试等不同的测试技术。而在对软件产品质量呼声日高的今天,软件性能测试技术尤为重要。

      软件性能测试“整体观”

      软件的性能测试是为了检验系统或系统部件是否达到需求规格说明中规定的各类性能指标,并满足一些性能相关的约束和限制条件,它必须对系统或系统部件具有的性能(例如,速度、精度、频率)做出规定的要求。

      性能测试通常在系统测试阶段执行,常常与强度测试结合起来,一般需要使用测试工具。评估测试对象的性能行为时,可以使用多种评测,这些评测侧重于获取与行为相关的数据,如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行,也可以在执行测试活动中使用性能评测评估测试进度和状态。

      性能需要在各种条件下测试,这些条件包括:

      ● 不同的工作量和/或系统条件。

      ● 不同的用例/功能。

      ● 不同的配置。

      ● 性能需求在补充规格或需求规格说明书中的性能描述部分中说明。

      在上述条件下执行测试时,要特别注意以下信息,并为反映这些信息的每条语句生成至少一个测试需求:

      ● 时间语句,如响应时间或定时情况。

      ● 指出在规定时间内必须出现的事件数或用例数的语句。

      ● 将某一项性能的行为与另一项性能的行为进行比较的语句。

      ● 将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句。

      ● 一段时间内的操作可靠性(平均故障时间或MTTF)。

      ● 配置或约束

      软件性能测试工作主要包括如下几个方面:

      ● 动态监测:在测试执行过程中,实时获取并显示正在执行的各测试脚本的状态。

      ● 响应时间/吞吐量:测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

      ● 百分位报告:数据已收集值的百分位评测/计算。

      ● 比较报告:代表不同测试执行情况的两个(或多个)数据集之间的差异或趋势。

      ● 追踪报告:主角(测试脚本)和测试对象之间的消息/会话详细信息。

      软件性能测试“方法观”

      软件性能测试的方法可以根据测试目的的不同,选择不同的方法,具体如下表:

      根据测试内容的不同,性能测试主要包括以下方面:

      1、响应时间测试

      ● 响应时间测试,通常指正常单用户操作时客户端的响应时间,以及将强度测试、负载测试、压力测试结合时客户端的响应时间。

      ● 函数、方法、对象、子例程执行时间。

      ● 函数、方法调用频度及嵌套。

      ● 运行特定模块、按特定路径执行或处理特定数据所花费的时间。

      ● 处理精度。

      ● 如果两次运行时间相差三倍以上,则可能存在问题。

      2、强度测试(压力/负载测试)

      强度测试需要在反常数量、频率或资源的方式下运行系统,以检验系统能力的最高实际限度,它要求软件必须被强制在它的设计能力的极限状态下运行。

      3、软件可靠性测试

      这种测试经常发现的错误包括越界指针,内存泄露、栈溢出、超过两个特性之间的错误交互等,也称长序列测试(long sequence testing)、持久测试(duration testing)、耐力测试(endurance testing)。测试持续时间较长,目标是发现程序测试遗漏的错误。

      可靠性差的软件,如执行时总是频繁地、重复地失败,软件不能稳定地工作。

      软件可靠性测试的目的是给出可靠性的定量估计值。

    软件性能评测“指标观”

      一般来说衡量软件性能测试的标准可以采用以下曾用的方法:

      1、软件可靠度(R)指标

      一种定量描述软件可靠性的方法,是指在规定的条件下和规定的时间内,软件在其运行剖面的某时刻正确地实现规定功能的概率。

      2、软件平均故障前工作时间(MTTF)

      一种定量描述软件可靠性的方法,是指一定配置状态下的软件产品在其规定的运行剖面中故障工作时间的期望值,以及软件故障强度。

      3、软件平均无故障工作时间(MTBF)

      计算机系统或子系统实现其功能的能力。一般以对计算机系统或子系统执行其功能的能力的度量。例如,响应时间、吞吐能力、事务处理数、占用率。

      软件性能测试“实例观”

      为了让读者对性能测试有更深刻的认识,下面以手机中运行的软件为例,说明在实际的软件开发过程中性能测试方法的运用:

      手机性能测试的方法可分为手工测试和自动测试。

      手工测试主要是通过测试人员手动操作,并借助某些监测仪器和工具来验证手机性能。但由于手机功能众多,很多性能测试需要重复性地进行,工作量很大,这需要耗费大量测试时间同时也容易造成测试的遗漏,不能保证性能测试的准确性和高效率。

      借助PC平台,目前已经有很多功能强大且通用的自动测试工具,如比较典型的有Winrunner,Robot,Loadrunner等等,但这些工具必须进行二次开发,才能将自动测试工具兼容到手机这种嵌入式系统中来。

      手机的自动化性能测试一般分为以下几个步骤进行:

      1、系统分析

      将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里,要分析被测系统结构,结合性能指标,制定具体的性能测试实施方案。要求测试人员对被测系统结构和实施业务全面掌握。

      2、建立虚拟用户脚本

      将业务流程转化为测试脚本,通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户,要将各类被测业务流程从头至尾进行确认和记录,分析每步操作的细节和时间,将其精确地转化为脚本。类似制造一个能够模仿人的行为和动作的机器人过程。

      3、根据用户性能指标创建测试场景

      根据真实业务场景,对生成的测试脚本进行复制和控制,对脚本的执行制定规则和约束关系,转化为满足性能测试指标的测试用例集。这个步骤需要结合用户性能指标进行细致地分析。

      4、运行测试场景,同步监测应用性能

      在性能测试运行中,实时监测能使测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测:协议栈,MMI应用程序,内存占用情况,驱动程序运行状态等。实时监测可以在测试执行中及早发现性能瓶颈。

      5、性能测试的结果分析和性能评价

      结合测试结果数据,分析出系统性能行为表现的规律,并准确定位系统的性能瓶颈所在。可以利用数学手段对大批量数据进行计算和统计,使结果更加具有客观性。在性能测试中,需要注意的是,能够执行的性能测试方案并不一定是成功的,成败的关键在于其是否精确地对真实世界进行了模拟。

      在整个性能测试过程中,自动化测试工具的选择只能影响性能测试执行的复杂程度,但人的分析和思考却会直接导致性能测试的成败。

      总之,软件性能测试的方法很多,不同方法的评测指标也是不同的。针对用户的需求、开发模式以及开发过程的不同,灵活。

  • 转:性能测试策略

    2009-08-19 15:39:23

    需求分析问题:

      1、刚开始最好不要上来就跟客户谈,某个性能点需要什么样的指标,比如支持多少人同时登陆,等等。一上来最主要的事情是了解整个系统的作用,用户,部署的方式,约束,上线时间,等等,目的是让自己能慢慢的站在客户角度来看待这个系统,通过自己的知识,想客户所想,忧客户所忧,因为我们的目的就是要让客户满意么。

      注意性能测试场景选择的原则:

      a. 重要的(业务上),

      b. 重复的(最常用的模块),

      c. 重量级的(消耗大量系统资源的)

      具体性能指标分为几类类:

      a. 系统容量(数据容量、用户量、并发用户量),

      b. 系统并发度指标(注册用户、在线用户、并发用户),

      c. 响应度指标(正常压力下响应能力、峰值压力下的响应能力,以及异常压力下的响应能力)

      2、理解整个系统及其实现之后,再列出自己分析得到的性能需求点。

      3、询问客户的具体性能需求,共同分析,是否测试,测试的优先级。

      4、写出性能测试计划和用例,并要得到客户认可。

      性能测试策略:

      1、单一性能点,多用户测试。测试过程可以隔离测试性能场景,先单独测试加压每种性能需求点,比如用户登陆,可以单独模拟此需求,建立比如50人并发登陆的场景。但此种场景并非是用户实际使用情况,不可能有个系统大家只是在拼命的登陆,而不作其他事情。但是,如果在做别的事情,那么同时再有50人并发登陆的话,那这个登陆时间会大大的延长的。所以此场景的设计仅仅为了检查这一个模块的性能水平。

      2、隔离之后,再逐步建立混合的性能场景。比如登陆的同时有人在浏览、查询、写入系统。但是此时只加载20%的负载。这一步主要是一个集成测试,考虑各个功能模块之间是否有影响,是否有对某些资源的抢夺等问题。同时找出Top Time Transaction

      3、如果上一步没问题了,这次就加压100%,看看在真正我们规定的要求下,系统各项性能指标如何,同时对本次测试结果作为Base Line,用来性能调优之后的比较。

  • 测试用例检查单

    2009-02-12 15:45:29

    测试用例检查单

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      1. 是否涵盖了需求文档上的每个功能点

      2. 是否涵盖了需求文档上的每条业务规则说明

      3. 是否覆盖了输入条件的各种有意义组合

      4. 是否覆盖了业务操作的基本路径和异常路径

      5. 是否考虑了重要表单字段的数据合法性检查

      6. 是否考虑了其他测试类型(对某个功能很重要,但未在需求文档中提及的,如安全测试、周期性测试和故障恢复等方面)

      7. 是否考虑了对其他模块/功能的影响

      8. 是否使用了项目组的标准用例模板

      9. 用例是否覆盖了测试设计中定义的所有场景

      10.用例编号是否统一、规范

      11.用例名称是否简洁、明了

      12.目的字段是否准确地描述了对应场景的测试输入的特征(不同数据,操作,配置等)

      13.前提条件字段的条目是否充分、准确,操作上是否不依赖于同组之外的其他用例

      14.对应的需求编号字段是否填写正确

      15.用例粒度、预估出的执行时间是否适当

      16.同组用例中,仅数据不同的,是否实现了测试步骤的重用

      17.某个功能点的第一个用例是否是基本流的

      18.操作步骤的描述,是否清晰、易懂

      19.操作步骤是否充分和必要,并具有可操作性

      20.测试用例的检查点是否明确、充分和可操作

      21.单个用例步骤或检查点中是否不再存在分支

      22.测试数据的特征描述是否准确,有条件的情况下,是否给出了一个当前环境下的可用参考值

      23.文字、语法是否准确;布局、格式是否统一

  • 如果您想从一名测试员转型为测试管理人员

    2009-02-12 15:08:24

    如果您想从一名测试员转型为测试管理人员

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下内容,至少要做到几点:

      1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

      2. 要熟悉BUG跟踪工具及软件测试流程(如: TD, Bugzilla, CQ等)

      3. 要熟悉配置管理工具(如:TestCenter ,CVS, VSS等)

      4. 要熟悉自动化工具(例如:WinRunner, QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代码)

      5. 要熟悉压力及性能测试工具(例如: AutoRunner,LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)

      6. 要熟悉或精通一门语言 (例如: Java, C++)

      7. 要熟悉数据库(例如: Oracle, DB2, SQLServer, MySQL

      8. 要熟悉主流操作系统 (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux, Windows

      9. 能用英文流利的和老外交流以及往来Email

      10. 语言表达能力强,表达问题清晰明了

      11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜

      12. 学习技术的能力要强,能快速上手一个新的技术

      13. 乐于与人交流

  • 转载:要做好性能测试,该掌握些什么?

    2008-07-10 17:47:45

  • 转载:关于测试人员的考核

    2008-07-09 17:42:51

  • 如何有效的选择回归测试用例?

    2008-07-09 15:35:57

     今天看到51testing上有这个问题,觉得很值得探讨一下,就在此谈谈我的看法。

    关于这个问题,我粗粗的搜索以下网上的关于这个问题的说法,大都是空空理论之谈,实际操作起来并不一定适合。

    说到回归测试用例,先说什么是回归测试。顾名思义,回归测试就是修改完bug之后对程序的新的一轮测试,据微软的统计,按照他们的经验,一般开发人员解决3~4个bug会衍生出一个新的bug,这就是必须作回归测试的原因。简单的说,就是检测一下解决了bug之后有没有带进新的问题,以免把聋子给治成哑巴,就得不偿失了~~

    一般的软件测试的流程是后期快速迭代的,bug在后期是快速收敛的,debug和测试的周期也是越来越短,频率是越来越高,譬如说第一轮测试需要花上10天跑用例,那么到后期就没那么长的时间,可能就是1~2天的测试时间,在后期有时候一天就有一个新的版本,这时候就要求测试人员能快速的进行一轮回归测试。

    一般来说,覆盖越高,风险越低,但是效率就越差,反之亦然。所以如果时间允许的话,能把所有的用例都再跑一边是最好不过的,但是一般不会有那么多的时间,这就需要在效率和覆盖之间有一个适当的平衡,选择其中一部分测试用例用来作回归测试。

    选择回归测试的时候,首先要确定的是,回归测试用例的比例,这个要根据时间情况了,100%是最好了,我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验,一般有如下必须回归的用例:

    第一,新修改的功能,这个显然是重点

    第二,新修改的功能的关联功能,就是有耦合的部分,这个一般最好咨询一下开发人员

    第三,程序最有卖点或者说亮点的部分,这个地方一旦有问题,会使程序质量大打折扣

    第四,程序中最致命的部分,譬如说安全隐患,数据泄露,加密注册,

    第五,程序中比较脆弱的部分,这个要咨询开发人员,一般就是他们心中最没底的地方

    第六,程序的主干功能

    第七,如果以上做完,还有时间的话,最好把用例中级别比较高的用例再执行一遍。

    OK ,以上是回归测试用例的选择优先级。

    其实,即使这样做,还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能,主要功能,用自动化测试,保证每一个版本都能够执行一遍,其他修改频繁的小功能手工测试了。

    说了这么多,好像比较乱,总结一下。

    个人觉得解决这个回归测试的终极解决方案是:

    a.作每日构建

    b.基线功能自动化

    c.编写用例时一定要分级(按照风险度,常用度,重要度)

    d.手工执行回归测试用例(就是我上面说的7项)

  • 转载:微软测试有感

    2008-07-09 14:34:19

    最近和微软一哥们聊微软的测试,很有感触,记下来,和大家共同分享。

    全文如下:

    开头语:

    作测试很久了,一直为一些问题所困扰,也一直对微软有一种顶礼膜拜的向往,终于有一天,近距离的接触了微软的测试,感觉不是以前想象中那么遥不可及,却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下,希望能对大家有所帮助。

     

    1.  测试流程

    首先说说测试流程,微软的测试流程也没什么新的东西,和大多数的测试流程一样。

    大致是先进行测试准备,然后是Testcase的编写,然后是白盒测试(不一定每个项目都有),然后是功能测试阶段,然后是验收测试,最终release

    如果看流程的话,和一般公司大同小异,没什么新花样。但是我觉得值得借鉴的是两点。

    第一,   微软的流程执行的非常认真。

    这点非常值得提倡,我们都知道,测试的最终质量决定于测试流程和测试人员素质,要想测试质量有保证,要么是流程很完善,要么你流程不行,但是个人能力超强。如果有一个很好的流程,就算执行的人稍微差点,最终的质量也不会差到哪里去。所以流程是很重要的。

    但是,看国内的公司欠缺的就是这个,要么是没有流程,要么流程是个花架子,没认真执行过。我想微软的测试人都是超级牛人,但是人家还是老老实实的忠实按照流程来走,我觉得这点非常好。(在IBM 也是这样,笔者以前在IBM作项目的时候,发现他们的文档写的特认真,流程特认真),所以说忠实的执行一个好的流程是成功的一大半。

    第二,   在整个流程中,微软非常强调测试尽早介入。微软在这方面是一致提倡的,按照我们国内IT业的恶习,一般都是软件主体差不多成型了,拉几个测试人员过来点点,其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入,在需求阶段就开始介入,进行需求评审。在开发人员开始编码的时候,测试人员就开始编写Test case,并开发一些测试工具,或者写一些配套的测试代码(不要奇怪,微软的测试人员都能写很好的代码)。微软的理念就是:预防bug比解决bug好,所以非常提倡测试尽早介入,把一部分bug消灭在需求阶段。

    2.  自动化流程

    说到自动化,大家可能以为我是说微软的自动化测试工具多牛,其实微软内部用到的自动化测试工具倒是不多,就算有也都是内部开发的,非常实用的,他们不会去用MI的工具。

            说微软的自动化程度高,主要是体现在流程方面,譬如说整个自动

        构建流程,在开发人       员代码check in之后,系统自动发邮件,邮

        件内容就是一个change list,包括代码更新list以及一个编译者添加的comment,其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化,尽可能减少人为失误,并且可

        以使人和机器并行工作。个人觉得,这点很值得我们国内的测试公司借鉴,能自动化的流程都自动化,减少一些不必要的沟通。

     

    3.  质量控制机制

    说到质量控制是个大问题,需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢?是他们的机制。在微软的测试流程当中,在开发的早期,项目中所有的问题都是Dev leaderPM商量说了算(当然也要参考需求方的意见),但是到后期,具体就是功能测试之后,项目的主动权都在测试这边,某个bug的要不要解决,或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的,在微软,测试人员要对最终的软件质量负责任,但是也有相应的权利来约束开发人员。当然,他们也肯定有一些bug是产生争议的,这个时候的仲裁机制就是PM,这个不是我们传统的PMProject manager),而是一种具有微软特色的PM(全称是Program manager)。这样,测试人员在对一些争议bug的处理上有相当的话语权。

     

    4.  测试用例及管理

    微软的测试用例倒没什么特别的,不过看过他们用例之后,还是觉得写的详细,认真,但是又不冗长拖沓,这个需要很高深的水平。另外,微软的测试用例管理用的是微软自己开发的用例管理工具。

    另外值得说明的是,微软的每个用例都进行了分级,并且功能所在的模块都标的很清楚。

     

    5.  效率

    在效率方面,微软的测试效率非常高!高的让人惊叹,我问一个在微软工作的哥们,“你们那边测试的最大特点是什么”,他说“最大特点是快!”,就是效率很高,具体就是在测试后期过程中测试和开发之间的反馈非常快,开发修改一定量的bug,提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来,一般是在1天之内就能把用例快速run一遍,这样就能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是,开发解决问题带进一个新问题,测试人员整个遍历一遍用例之后才能发现,这样来回反复就消耗了大量的时间。

    但微软是如何才能实现快速反馈呢?

    第一,   测试人员对程序的了解,微软的测试人员对程序内部结构都非常熟悉,修改某一个地方,可能引起什么问题,哪些用例需要重新测试,测试人员非常清楚,能快速的执行最可能出错的地方。如果某些模块不熟悉,那么他们会和开发人员在一起沟通这次修改可能引起的问题。

    第二,   工具!还是工具,在微软的测试中,测试人员用各种工具帮助测试,提高测试效率是占到很大的比重。

    第三,   时间意识。微软的测试人员有强烈的时间意识。

     

    6.  测试工具

    测试工具能很大程度上提高测试效率,这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛,但是请注意,微软并不是像我们国内的公司一样使用的都是LRQTP这类的录制回放工具,反而这种工具倒是用的不多,就跟微软不屑CMM一样,可能是不想屈尊自己IT老大的身份吧。

    但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率,确实能办事情的工具,都不是类似WRQTP的很大很系统的工具,而是比较小的,很灵活,实用的小工具(譬如:FiddlerDriphttpwatchIE DevToolBarPaintNotNetprocexp etc.)。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的,不过大多数工具都是微软内部已经共享出来的,在微软内部各种各样的小工具特别多。

    总体给我的感觉是,不是为了用测试工具而用,而是根据实际的需要,确实能提高效率而用到,在用的过程中确实也很大的提高了效率。

     

    7.  测试人员的专业素质

    微软测试给我印象最深刻的还有他们测试人员的专业水准,在测试过程中,测试人员在一些技术上并不逊色于开发人员,在一些bug的处理上,能提出很多合理的很有建设性的建议。

     

    8.  微软的白盒测试

    微软的白盒测试怎么执行呢?让我略微有点吃惊的是,微软的一半测试人员基本不做白盒测试,除非有些不能做黑盒的模块,另外也不是所有的产品都作白盒测试。

    微软的白盒测试一般还是由专门的白盒测试人员来做,但是开发人员要对测试人员的白盒测试代码进行Review,另外微软对开发人员的代码,效率也都有一套详细的考核机制,所以开发人员对自己的代码也是非常负责任的,都进行很认真的进行测试。

     

    9.  意识(时间,质量)

    另外微软的测试还有很好的一点就是意识,时间和质量的意识都是非常强。在控制时间成本上,意识非常强,这点非常值得我们国内同仁学习,另外,风险管理的机制和意识都是非常好。在微软,项目组的每个成员都被明确告知,如果这个项目每delay一天,就会损失多少个million的美元,所以整个项目组都有比较好的时间意识。

    另外,在微软,项目组人员的质量意识都是比较强的。怎么样更好服务用户,让用户体验更好,怎么样更好的改进,这种意识比较强。

     

    10. 微软的培训

    在微软内部,员工外训的机会比较少,大多都是内部互训,各人培训自己的强项,有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。

     

    11 测试数据记录

    微软的测试数据记录是非常全的,也都是系统自动的,每天都是由系统自动统计当天的bug情况,然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候,这些测试数据将变得非常有用。

    编后感:在深入了解微软的测试之前,对微软这个IT业界巨无霸的测试感觉是顶礼膜拜,高不可攀,总觉得可能很神秘,用很牛的技术或者很高深的手段。深入了解之后,发现微软的测试也是和我们做一样的事情,只不过人家做的更认真,更细,更实用,更有效率。再回过头来看时,微软的测试给我留下印象最多的是,流程,效率,意识,工具,素质!也就是这几项,成为我们国内IT企业亟需跨越的。

  • 转载:如何进行升级测试

    2008-06-13 10:06:42

     

    什么是升级测试?比如说你们公司开发的产品现已经发布的是V1.0,由于被发现存在缺陷,这时就需开发Patch或Hot Fix,并进行升级测试,然后发布V1.1。

    升级测试听起来似乎挺平常的,但它其实也是软件测试中比较重要的一部分,它通常包括以下内容:

    • 安装测试
    • 数据库测试
    • 应用测试
    • 文档测试

    安装测试

    当发布一个系统的新版本时,程序代码肯定是被修改过了,安装测试的目的是确保安装完成后修改过的文件被复制到了正确的位置,比如说某个文件夹包含了所有更新的HTML文件,这时就要检查相关的CSS文件夹下的文件是不是更新了,如果只更新了HTML而没更新CSS,那么相应的颜色/字体就不能正确地显示。

    如果公司研发过程比较规范,安装测试通常是在配置管理员的配合下完成的。首先,是文件夹级的测试,检查安装过程中复制到系统中的文件夹的时间戳是否变化;其次,检查被修改过的文件的大小,并和之前的版本进行比较,当然,这分两种测试,如果是白盒测试,测试人员要打开相应的文件确认新代码和改过的代码,如果是黑盒测试,那就要检查文件大小应与旧版本的不同。

    数据库测试

    很多情况下,系统的升级都是伴随着数据库脚本的更新,数据库测试通常也是由DBA人员或在DBA的配合下进行。升级前要停止数据库并做备份,然后执行升级脚本,之后测试人员需要查看数据库日志,并检查库中被修改的记录是否正确。如果升级脚本是在库中创建一个新的Table或是新的Relation,那么数据库测试应该关注对空库的测试,比如先建一个空库V1.0,只包含一些空的Table和Relation,而不包含任何数据,然后测试人员执行升级脚本,并查看日志文件里是否有报错,如果没有报错一切ok,则通过应用程序连到数据库上执行一些功能测试用例来确保数据的Inset或Update都是正确的。

    应用测试

    当安装测试和数据库测试都通过之后,进行应用测试,有两种方法:

    方法一:先配一个空的数据库(即除了一些必需的初始化数据再没有其他数据),然后把应用程序升级一下,执行业务流程测试看系统是否能够正常运行。

    方法二:也是先配好数据库,但库里存有一些实际数据,然后把程序升级一下(比如从V1.0升至V1.1),运行应用程序,检查那些已有的数据在V1.1上是否也能被正确的展现和使用,最后执行业务流程测试看系统是否能够正常运行。

    有的时候升级完后还要手工修改库中已有的记录,比如一个网上银行的系统,它里面有很多支付或转帐的数据,在做升级测试时,就可能要修改那些在上一版本中生成的数据,因为它们可能涉及到多个表之间的数据转换或一二级约束。

    文档测试

    文档测试主要是验证相关的版本说明或者安装手册等文档是否和系统升级相匹配,这点很重要,因为客户通常都是根据版本说明和安装手册进行系统的安装或升级。

    进行文档测试必须理解详细的升级步骤,比如文档中应建议用户升级前要备份数据库、数据文件、配置文件等,再比如升级需要复制某些文件到特定目录,应当在版本说明中有所体现,总之,升级时任何必要的说明都应当在版本说明或安装手册内阐述清楚,安装时可以做什么以及不可以做什么都应在版本发布前得到确认。

  • 懒人第一笔

    2007-07-30 16:08:56

    欢迎光临寒舍。。。
Open Toolbar