热爱测试、热爱生活

发布新日志

  • 性能计数器的监控

    2008-10-09 13:28:22

    面试了一些测试人员,感觉大多数测试人员对于性能测试的了解仅限于loadrunner工具的了解,在实际测试过程中需要监控服务端性能计数,大多数测试人员也很依赖于loadrunner,不论是windos系统、linux系统。事实上本人对于服务器性能的监控不太愿意使用loadrunner,loadrunner本身功能比较强大,但是对于linux服务器可以利用一些命令、脚本来监控,你甚至可以采用报警、发短信、邮件的方式来监控服务器,winows服务器也可以利用本身的性能计数器来监控,系统自带的计数器功能非常强大!

  • 两种开发模型

    2008-10-04 02:53:48

     

    迭代模型


      早在20世纪50年代末期,软件领域中就出现了迭代模型。最早的迭代过程可能被描述为分段模型(stagewise model,其背景是H.D.Benington领导的美国空军SAGE项目。
      迭代模型是RUPRational Unified Process,统一软件开发过程,统一软件过程)推荐的周期模型。在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
      实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。迭代的思想如图所示。

      在现代过程方法XPeXtreme Programming,极限编程)、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点,在发现那么多采用了瀑布模型的失败的项目之后,不但放弃了对它的要求,而且从1994年的报告开始,积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时,中国中科院也提倡选用迭代模型。
      对众多的开发模型和过程方法,及权威机构的看法,企业应选择什么样的开发模型,应慎重对从以下几方面进行考虑:
      1RUP虽然内容极其丰富,定义了选起、精化、构建、产品化4个阶段和业务建模、需求、分析设计、实现、测试、部署等9个工种,提供了一大堆的文档模板,但极易让人误解是重型的过程,实施推广有一定难度。
      2、再次,在质量管理方面:以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。每次迭代进行系统集成、系统测试,达到对软件质量的持续验证。每次系统测试,需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户(包括内部客户、外部客户)进行评价,通过演示操作等方式,评价该次迭代是否达到预定的目标,并以此为依据来制定下一次迭代的目标。
      3、最后,在其他方面:每次迭代成果须进行配置管理,版本控制很重要。在整个迭代过程中风险无处不在,建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集,关注每次迭代情况。
      总之,选择一个合适的生命周期模型,并应用正确的方法,对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。

    迭代模型的选择使用条件

    [编辑本段]

      1、在项目开发早期需求可能有所变化。
      2、分析设计人员对应用领域很熟悉。
      3、高风险项目。
      4、用户可不同程度地参与整个项目的开发过程。
      5、使用面向对象的语言或统一建模语言(Unified Modeling LanguageUML)。
      6、使用CASEComputer Aided Software Engineering,计算机辅助软件工程)工具,如RoseRose是非常受欢迎的物件软体开发工具。)。
      7、具有高素质的项目管理者和软件研发团队。

    迭代模型的优点


      与传统的瀑布模型相比较,迭代过程具有以下优点:
      1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
      2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。
      3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
      4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

     

    增量模型

     

    增量模型融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的增量。当使用增量模型时,第1个增量往往是核心的产品,即第1个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如图1-8所示。
    增量模型与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的可拆卸版本,但提供了为用户服务的功能,并且为用户提供了评估的平台。增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。

    采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。如果核心产品很受欢迎,则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户,对客户起到镇静剂的作用。此外,增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

  • 介绍一款web漏洞扫描工具appacan

    2008-10-04 02:25:39

    web漏洞扫描属于系统安全测试的范畴,目前最好的工具当属watchfire appscan了
    下面是appscan的一些相关介绍:
     
    互联网的发展历史也可以说是攻击与防护不断交织发展的过程。当前,Web 安全性已经提高一个空前的高度,然而针对网站的攻击却频频得手。如何最大化的保护 Web 应用呢,IBM Rational 提出了全面的解决方案。本文将针对 Web 安全的现状、根源、以及 Rational AppScan 产品的技术细节做全面的介绍,最后阐述IBM解决方案给企业带来的深层次价值。

      1 当前 Web 安全现状

      互联网的发展历史也可以说是攻击与防护不断交织发展的过程。目前,全球因特网用户已达 13.5 亿,用户利用网络进行购物、银行转账支付和各种软件下载,企业用户更是依赖于互联网构建他们的核心业务,对此,Web 安全性已经提高一个空前的高度。

      然而,现实世界中,针对网站的攻击愈演愈烈,频频得手。CardSystems 是美国一家专门处理信用卡交易资料的厂商。该公司为万事达 (Master)、维萨 (Visa) 和美国运通卡等主要信用卡组织提供数据外包服务,负责审核商家传来的消费者信用卡号码、有效期等信息,审核后再传送给银行完成付款手续。这家公司为超过 10 万家企业处理信用卡信息,每年业务金额超过 150 亿美元。这家已有 15 年历史的公司怎么也没想到,居然有黑客恶意侵入了它的电脑系统,窃取了 4000 万张信用卡的资料。这些资料包括持卡人的姓名、账户号码等。这是美国有史以来最严重的信用卡资料泄密事件。此次攻击事件不仅仅对消费者,对公司造成了巨大的损失,甚至对美国的信用卡产业产生了严重的影响!

      1.1 Web 安全的认识误区

      然而什么才是 Web 安全呢,或者说什么样的网站才是安全的呢?用户往往有一些常见的误区。

      “Web 网站使用了防火墙,所以很安全”

      无论是应用级还是端口级的防火墙针对的都是网络层面的攻击,通过设置可访问的端口或者应用,把恶意访问排除在外,然而如何鉴别善意访问和恶意访问是一个问题。访问一旦被允许,后续的安全问题就不是防火墙能应对了。

      “Web 网站使用了 IDS,所以很安全”

      通过模式识别对网络层面的攻击做出防护措施。然而类似于防火墙,通过利用程序漏洞,通过正常连接进行攻击的访问无法被识别和处理。

      “Web 网站使用了 SSL 加密,所以很安全”

      SSL 对网站发送和接收的信息都进行加密处理,然而 SSL 无法保障存储在网站里的信息的安全和网站访问者的隐私信息。采用 64 位甚至 128 位 SSL 加密的网站被黑客攻陷的例子举不胜举。

      “漏洞扫描工具没发现任何问题,所以很安全”

      当前漏洞扫描工具已经被广泛使用去查找一些明显的网络安全漏洞。同理,扫描工具无法对网站应用程序进行检测,无法查找应用本身的漏洞。

      “我们每季度都会聘用安全人员(Pen Tester)进行审计,所以很安全”

      人为的检测考察不仅仅效率低,不可控因素也较多,同时对于代码变更频繁的今天,Pen Tester 也无法满足全面的安全需求

      然而这些方法远远不能保障 Web 应用的安全,针对应用层面的攻击可以轻松的突破防火墙保护的网站。例如:最为常见的 SQL 注入攻击表现层面完全是正常的数据交互查询。对于防火墙或者入侵检测系统而言,这是最为正常的访问连接,没有任何特征能够说明此种访问连接存在恶意攻击。所以,一些简单的 SQL 注入语句就可以使得装备昂贵网络安全设备的网站被轻松攻破。

      1.2 Web 安全现状

      令人惊诧的是,几乎所有关注 Web 安全领域的人都会存在着上面我们阐述的误区,而当前 Web 的安全现状也同时证明了这些误区的普遍性。“防火墙、IDS 是主要安全手段,SSL 保证了安全性,…”与之相对的是:互联网发展到今天,75%的安全问题竟然是出现在应用程序本身。正如上面介绍的 SQL 注入攻击一样,这是防火墙、SSL、入侵检测系统无法预防、解决、和应对的!

      如下图所示,目前安全投资中,只有 10%花在了如何防护应用安全漏洞,而这却是 75%的攻击来源――10% Vs 75%,这是多么大的差距!这也是造成当前 Web 站点频频被攻陷的一个重要因素。

      图 1. 当前安全现状统计分析图

      当前安全现状统计分析图

      那么,什么样的防护才是一个完整的解决方案呢?通过附图 2 我们可以看到,一个完整的 Web 防护不仅仅包含了常见的 IDS、Firewall 等防护手段,更需要针对应用本身做好安全防护,这也是解决 75%安全漏洞的手段。那么什么样的攻击是防火墙、IDS、或者 SSL 无法应对的呢,他们又是如何利用应用本身的漏洞进行攻击的呢?下面我们将做详细的阐述。

      图 2. Web 应用的网络防护

      Web 应用的网络防护

      常见针对 Web 应用攻击的十大手段

      

    目前常用的针对应用漏洞的攻击已经多达几百种,最为常见的攻击为下表列出的十种。

    十大攻击手段
    应用威胁 负面影响 后果
    跨网站脚本攻击 标识盗窃,敏感数据丢失… 黑客可以模拟合法用户,控制其帐户。
    注入攻击 通过构造查询对数据库、LDAP 和其他系统进行非法查询。 黑客可以访问后端数据库信息,修改、盗窃。
    恶意文件执行 在服务器上执行 Shell 命令 Execute,获取控制权。 被修改的站点将所有交易传送给黑客
    不安全对象引用 黑客访问敏感文件和资源 Web 应用返回敏感文件内容
    伪造跨站点请求 黑客调用 Blind 动作,模拟合法用户 黑客发起 Blind 请求,要求进行转帐
    信息泻露和不正确的错误处理 黑客得到详细系统信息 恶意的系统检测可能有助于更深入的攻击
    被破坏的认证和 Session 管理 Session token 没有被很好的保护 在用户推出系统后,黑客能够盗窃 session。
    不安全的木马存储 过于简单的加密技术导致黑客破解编密码 隐秘信息被黑客解密盗窃
    不安全的通讯 敏感信息在不安全通道中以非加密方式传送 黑客可以通过嗅探器嗅探敏感信息,模拟合法用户。
    URL 访问限制失效 黑客可以访问非授权的资源连接 黑客可以强行访问一些登陆网页、历史网页。

      我们通过注入缺陷(Injection Flaws,排名第二的攻击)对攻击原理进行一下说明。

      在网站的应用中需要应用到大量的数据库查询检索等功能,例如最简单的例子是网站登陆,用户需要输入登陆名称和密码进行登陆认证。在早期的开发中通常使用最为简单的 select 语句实现此功能,即 select * from users where username = “XXXX” and password = “XXXX”( 假设数据库 user 表名称为 users,用户名和密码字段名称为 username 和 password)。通过截取用户在文本框中录入的字符串,再进行拼接,形成 select 语句,最终如果表 users 中有符合此条件的记录(即该用户名和密码),系统将会返回有效记录,从而允许登陆系统中。

      然而,此开发方法隐藏了一个巨大的漏洞,黑客可以通过 SQL 注入攻击攻入网站。如下图所示,黑客在登陆界面录入的不是用户名,而是一串字符串 (’or 1=1 --)。黑客的目的是在原本应该录入用户的地方录入了一串字符串,导致整个 select 语句发生了变化:select * from users where username=’’or 1=1。熟知 Select 语句的人知道,在条件语句中,无论用户名称是否正确,由于 1=1 永远是正确的,所以 select 将会将所有 users 表中的数据返回。最终的结果是,黑客登陆到这个系统中。通过 SQL 注入攻击,黑客可以轻松的敲入一些 sql 语句登陆进网站、对隐秘数据进行查询等等。

      图 3. 攻击举例

      攻击举例

      通过上述原理描述我们可以看到,对于 SQL 注入攻击无论是防火墙还是入侵检测系统都无法预防和阻止,唯一的办法是将应用本身的漏洞关闭。例如通过参数的传递配合存贮过程来实现数据库查询,这比动态的构建 sql 语句安全很多。比如在 ASP.net 中通过下面的程序将会避免攻击:

      ' Visual Basic example

      Dim DS As DataSet

      Dim MyConnection As SqlConnection

      Dim MyCommand As SqlDataAdapter

      Dim SelectCommand As String = "select * from users where username = @username"

      ...

      MyCommand.SelectCommand.Parameters.Add(New SqlParameter("@username",

      SqlDbType.NVarChar, 20))

      MyCommand.SelectCommand.Parameters("@username").Value = UserNameField.Value

      // C# example

      String selectCmd = "select * from Authors where state = @username";

      SqlConnection myConnection = new SqlConnection("server=...");

      SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);

      myCommand.SelectCommand.Parameters.Add(new SqlParameter("@username",

      SqlDbType.NVarChar, 20));

      myCommand.SelectCommand.Parameters["@username"].Value = UserNameField.Value;

      除了注入缺陷攻击,常见的应用攻击还有跨网站脚本攻击、恶意文件执行攻击、不安全直接对象应用攻击、跨站点请求伪造攻击、信息泄漏以及利用错误处理机制展开攻击、等等。每种攻击都类似与 SQL 注入攻击,根据应用程序本身的漏洞,对系统进行破坏工作,例如:获取系统权限、获取机密信息、模拟合法用户等等。

      综上所述,这些利用 Web 应用漏洞的攻击是 Web 安全最主要的威胁来源,75%的攻击来源于此,只有对应用程序本身进行改造才能避免攻击。然而,如何发现这些应用漏洞是保证安全的第一前提,我们如何以最快最有效的方式发现 Web 应用本身的漏洞呢?没有高效检测手段,安全的 Web 应用将成为水中花镜中月。

      3 通过 Rational AppScan 如何应对网站攻击

      IBM Rational AppScan 正是应对这一挑战的利器。

      如下图所示,Rational AppScan 工作方式比较简单,就像一个黑盒测试工具一样,测试人员不需要了解 Web 应用本身的结构。AppScan 拥有庞大完整的攻击特征库,通过在 http request 中插入测试用例的方法实现几百中应用攻击,再通过分析 http response 判断该应用是否存在相应的漏洞。整个过程简单易懂高效,测试人员可以快速的定位漏洞所在的位置,同时 AppScan 可以详细指出该漏洞的原理以及解决该漏洞的方法,帮助开发人员迅速修复程序安全隐患。对于攻击的特征以及测试用例用户不需要花费大量的精力,WatchFire 团队定期的对特征库进行更新,随着保证与业界的同步,最大化的提高用户的工作效率。

      图 4. Rational AppScan 工作示意图

      Rational AppScan 工作示意图

      下面我们通过简单的实例介绍一下 Rational AppScan 的使用:

      定义扫描

      首先确定扫描站点的 URL,根据默认的模板配置向导,确定扫描的整个站点模型以及你想扫描的漏洞种类。例如,我想扫描企业应用 www.xxx.com,想根据默认值扫描是否有安全隐患,启动 AppScan,创建一个扫描,敲入 www.xxx.com; 根据配置向导直至完成。

      图 5. 默认的模板配置向导

      默认的模板配置向导

      图 6. 创建一个扫描

      创建一个扫描

      扫描启动,进行测试

      只需要点击执行。

      扫描结果查看

      如图所示,AppScan 以各种维度展现了扫描后的结果,不仅仅定位了问题发生的位置,也提出了问题的解决方案。

      图 7. 扫描后的结果

      扫描后的结果

      4 Rational AppScan 深入介绍

      Rational AppScan 同时提供了很多高级功能,帮助客户对复杂应用进行检测。支持的扫描配置有:

      Starting URL:起始 URL,制定被测应用的起始地址

      Custom Error Pages:制定错误网页提高测试效率

      Session IDs:管理测试过程中的 session

      Automatic Server Detection:自动检测应用所在的应用服务器、web server、操作系统

      Exclusion and Inclusion:制定哪些 Web 被扫描或者被排除,哪些文件类型不被扫描

      Scan Limits:其他高级扫描限制,例如扫描次数限制等

      Advanced:扫描的方式,是宽度扫描还是深度扫描

      Communication Settings:对扫描中的延时、线程数量进行配置

      Proxy Settings:代理设置vLogin/logout:对被测应用的登陆进行设置,可以采用录制回放的方式、也可以使用自动登陆的方式

      configure a Test Policy: 配置测试测量,即想测试哪些漏洞。

      ……

      如上所述,用户可以通过 AppScan 进行一系列高级配置,制定所要检测的 Web 模型,即哪些需要扫描、哪些不需要、扫描的方式等等;也可以定义需要扫描漏洞的列表,从而保证了用户关心的网站模型有无用户所关心的安全漏洞。在检测出安全漏洞之后,AppScan 又提供了全面的解决方案帮助客户快速解决这些问题,最大化的保证 Web 应用的安全。另外,对于 Web 服务 AppScan 同样可以支持。

      AppScan 提供了完善的报表功能,可以支持用户对扫描的结果进行各种分析,包括对行业或者法规的支持程度;同时,AppScan 也提供了一系列的小工具,例如:Authentication Tester 通过暴力检测方法扫描被测网站的用户名称和密码;HTTP Request Editor 提供了编辑 Http request 的功能,等等。

      5 Rational AppScan 的使用场景

      在整个软件开发生命周期中的各个阶段,Rational AppScan 都可以被使用,全面的保障了软件的安全性。如下图所示,软件开发过程中,软件开发人员、软件测试人员、QA、审核人员等诸多角色都可以通过 AppScan 检测应用,将漏洞尽早挖掘出来。下面我们通过一些使用场景介绍一下 AppScan 给软件开发带来的利益。

      图 8. AppScan 使用场景

      AppScan 使用场景

      5.1 开发人员使用 AppScan

      开发人员在开发过程中可以使用 AppScan 或者专用插件,随时开发随时测试,最大化的保证个人开发程序的安全性。越早发现问题,解决问题的成本就越低,这为 Web 应用的安全提供了最为坚实的基础保障。

      测试人员使用 AppScan

      系统测试人员使用 AppScan 对应用做全面的测试,一旦发现问题,可以快速的生成 defect,通过与 ClearQuest 的集成可以实现 defect 电子化跟踪,再传递到开发人员手中,指导开发人员迅速解决问题。极大的提高了开发团队的开发效率,也提供了完整了沟通平台解决方案。

      5.3 审核人员上线前使用 AppScan

      这是系统上线前的安全质量关卡。任何系统上线都应该经过严格的上线测试,这也最大化的减少了上线后问题的出现,避免生产系统上线后给企业带来的巨额损失。

      5.4 上线后审计、监控人员使用 AppScan

      上线的系统应该定期检测,一旦出现问题更应该及时检测,越快速的定位发现问题,损失就会越小。

      上面我们介绍的是比较通用的使用场景。当然,不同的企业可能不同的特点,AppScan 使用场景的原则是最大化的提高使用效率、尽早的把问题暴露出来,为应用安全打下坚实的基础。每个企业都可以根据自身的开发现状定义适合自己的使用模式。

      6. 为企业带来的收益

      通过上面的介绍,我们对 Web 安全现状、应用安全重要性、以及应用安全产品 Rational AppScan 的使用有了一定的认识。但是,工具带给客户的不仅仅是一些功能,更为重要的是给企业带来的深层次的收益,给企业在开发过程、安全策略等层面带来了深刻的变化 . 下面我们从几方面阐述 AppScan 给企业带来的价值:

      AppScan 是 Web 应用安全的坚实保障

      正如上面所论述的一样,当前 Web 安全 75%的漏洞出自于应用本身,快速全面的定位问题并提供完善的解决方案将会帮助开发团队构建一个健壮的应用。

      AppScan 使得开发成本降低、开发效率提高

      开发测试人员通过 Rational AppScan 可以迅速的定位安全隐患,早期发现问题不仅有助于解决问题,更降低了开发成本,避免问题过晚出现所造成的巨大损失。

      AppScan 给企业提供了统计分析能力

      Rational AppScan 提供了灵活报表功能,可以支持对扫描结果进行统计分析;支持对规范法规遵循的分析;更提供了 Delta 比较报告,可以比较两次检测的结果从而作为质量检验的基础数据 AppScan 帮助建立企业级的测试策略库

      Rational AppScan

      帮助企业根据不同的应用类型建立不同的测试策略,同时用户可以定义针对不同威胁的解决方法,持续的知识积累保证了企业拥有更完善的安全解决方案。

      总结

      综上所述,随着 Internet 的蓬勃发展,Web 的安全性已经被空前重视,薄弱的安全性也成为了很多企业发展的瓶颈。然而,即便安全性如此受重视的今天,很多人对如何保障 Web 的安去性都存在着巨大的误区。现实表明,只有加强 Web 应用的防护,才能有效的防范 75%的攻击,Web 应用的防护已经成为安全话题中最为不可获缺的部分。IBM Rational 提供了 Rational AppScan 解决方案,在 Web 开发、测试、维护、运营的整个生命周期中,帮助企业高效的发现、解决安全漏洞,最大限度的保证了应用的安全性,为企业发展提供了坚实的技术保障。

  • 关于ActiveX

    2008-10-04 01:14:04

    公司采用ActiveX的方式下载客户端,但是测试人员对ActiveX并不了解,下面是一些关于ActiveX方面的知识

    概要  ActiveX 是一个打开的集成平台,为开发人员、 用户和 Web生产商提供了一个快速而简便的在 Internet 和 Intranet 创建程序集成和内容的方法。 使用 ActiveX, 可轻松方便的在 Web页中插入 多媒体效果、 交互式对象、以及复杂程序,创建用户体验相当的高质量多媒体 CD-ROM 。

      根据微软权威的软件开发指南MSDN(Microsoft Developer Network)的定义,ActiveX插件以前也叫做OLE控件或OCX控件,它是一些软件组件或对象,可以将其插入到WEB网页或其它应用程序中。

    ActiveX的内容

      ActiveX 控件
      以前称为 OLE 控件或 OCX 控件, ActiveX, 是组件 (或对象) 打包, 别人编程功能, 以便您可以重用 Web页或其他程序中插入。 例如, 随 InternetExplorer 一起提供 ActiveX 控件可用于增强 Web页具有复杂格式功能和动画。
      ActiveX 控件通过 Java 程序和 Netscape 插件关键优点是, 还可以用许多编程语言, 包括所有 Microsoft 编程和数据库语言编写程序中使用 ActiveX 控件。
      ActiveX 文档
      用一个 ActiveX - 识别 Web 浏览器如 InternetExplorer, 浏览时 ActiveX 文档使您能够使用自己的工具栏和菜单可打开程序。 这意味着您可以通过使用 ActiveX - 识别 Web 浏览器打开非HTML 文件, 如 MicrosoftExcel 或 MicrosoftWord 文件。
      ActiveX 脚本
      ActiveX 脚本支持最常用脚本语言, 包括 Microsoft VisualBasic 脚本和 Javascrīpt。 ActiveX 脚本可用于集成行为若干 ActiveX 控件或 Java 程序从 Web 浏览器或服务器, 扩展其功能。

    编辑本段ActiveX的特点

      在因特网上,ActiveX插件软件的特点是:一般软件需要用户单独下载然后执行安装,而ActiveX插件是当用户浏览到特定的网页时,IE浏览器即可自动下载并提示用户安装。 ActiveX插件安装的一个前提是必须经过用户的同意及确认。
      ActiveX插件技术是国际上通用的基于Windows平台的软件技术,除了网络实名插件之外,许多软件均采用此种方式开发,例如Flash动画播放插件、Microsoft MediaPlayer插件、CNNIC通用网址插件等。

    编辑本段相关内容

      1.浏览器如何保证ActiveX插件的安全性?
      当通过Internet发行软件时,软件的安全性是一个非常引人注意的问题,IE浏览器通过以下的方式来保证ActiveX插件的安全:
      ActiveX使用了两个补充性的策略:安全级别和证明,来追求进一步的软件安全性;
      Microsoft提供了一套工具,可以用它来增加ActiveX对象的安全性;
      通过Microsoft的验证代码工具,可以对ActiveX控件进行签名,这告诉用户你的确是控件的作者而且没有他人篡改过这个控件;
      为了使用验证代码工具对组件进行签名,必须从证书授权机构获得一个数字证书;证书包含表明特定软件程序是正版的信息,这确保了其他程序不能再使用原程序的标识。证书还记录了颁发日期。当您试图下载软件时,Internet Explorer 会验证证书中的信息,以及当前日期是否在证书的截止日期之前。如果在下载时该信息不是最新的和有效的,Internet Explorer 将显示一个警告;
      在IE默认的安全级别中,ActiveX控件安装之前,用户可以根据自己对软件发行商和软件本身的信任程度,选择决定是否继续安装和运行此软件。
      在最新的IE 7中,安全性有进一步的提高。
      2.关于三个概念:ActiveX、OLE和COM
      熟悉面向对象编程和网络编程的人一定对ActiveX、OLE和COM/DCOM这些概念不会陌生,但是它们之间究竟是什么样的关系,对许多们还是比较模糊的。在具体介绍它们的关系之间,我们还是先明确组件(Component)和对象(Object)之间的区别。组件是一个可重用的模块,它是由一组处理过程、数据封装和用户接口组成的业务对象(Rules Object)。组件看起来像对象,但不符合对象的学术定义。它们的主要区别是:1)组件可以在另一个称为容器(有时也称为承载者或宿主)的应用程序中使用,也可以作为独立过程使用;2)组件可以由一个类构成,也可以由多个类组成,或者是一个完整的应用程序;3)组件为模块重用,而对象为代码重用。现在,比较流行的组件模型有COM(Component Objiect Module,对象组件模型)/DCOM(Distributed COM,分布式对象组件模型)和CORBA(Common Object Request Broker Architecture,公共对象请求代理体系结构)。到这里,已经出现了与本文相关的主题COM,而CORBA与本文无关,就不作介绍。之所以从组件与对象的区别说起,是想让大家明确COM和CORBA是处在整个体系结构的最底层,如果暂时对此还不能理解,不妨继续往下看,最后在回过头看一看就自然明白了。现在开始阐述ActiveX、OLE和COM的关系。首先,让大家有一个总体的概念,从时间的角度讲,OLE是最早出现的,然后是COM和ActiveX;从体系结构角度讲,OLE和ActiveX是建立在COM之上的,所以COM是基础;单从名称角度讲,OLE、ActiveX是两个商标名称,而COM则是一个纯技术名词,这也是大家更多的听说ActiveX和OLE的原因。既然OLE是最早出现的,那么就从OLE说起,自从Windows操作系统流行以来,“剪贴板”(Clipboard)首先解决了不同程序间的通信问题(由剪贴板作为数据交换中心,进行复制、粘贴的操作),但是剪贴板传递的都是“死”数据,应用程序开发者得自行编写、解析数据格式的代码,于是动态数据交换(Dynamic Data Exchange,DDE)的通信协定应运而生,它可以让应用程序之间自动获取彼此的最新数据,但是,解决彼此之间的“数据格式”转换仍然是程序员沉重的负担。对象的链接与嵌入(Object Linking and Embedded,OLE)的诞生把原来应用程序的数据交换提高到“对象交换”,这样程序间不但获得数据也同样获得彼此的应用程序对象,并且可以直接使用彼此的数据内容,其实OLE是Microsoft的复合文档技术,它的最初版本只是瞄准复合文档,但在后续版本OLE2中,导入了COM。由此可见,COM是应OLE的需求而诞生的,所以虽然COM是OLE的基础,但OLE的产生却在COM之前。COM的基本出发点是,让某个软件通过一个通用的机构为另一个软件提供服务。COM是应OLE的需求而诞生,但它的第一个使用者却是OLE2,所以COM与复合文档间并没有多大的关系,实际上,后来COM就作为与复合文档完全无关的技术,开始被广泛应用。这样一来,Microsoft就开始“染指”通用平台技术。但是COM并不是产品,它需要一个商标名称。而那时Microsoft的市场专家们已经选用了OLE作为商标名称,所以使用COM技术的都开始贴上了OLE的标签。虽然这些技术中的绝大多数与复合文档没有关系。Microsoft的这一做法让人产生这样一个误解OLE是仅指复合文档呢?还是不单单指复合文档?其实OLE是COM的商标名称,自然不仅仅指复合文档。但Microsoft自己恐怕无法解释清楚,这要花费相当的精力和时间。于是,随着Internet的发展,在1996年春,Microsoft改变了主意,选择ActiveX作为新的商标名称。ActiveX是指宽松定义的、基于COM的技术集合,而OLE仍然仅指复合文档。当然,ActiveX最核心的技术还是COM。ActiveX和OLE的最大不同在于,OLE针对的是桌面上应用软件和文件之间的集成,而ActiveX则以提供进一步的网络应用与用户交互为主。到这里,大家应该对ActiveX、OLE和COM三者的关系有了一个比较明确的认识,COM才是最根本的核心技术,所以下面的重点COM。让对象模型完全独立于编程语言,这是一个非常新奇的思想。这一点从C++和Java的对象概念上,我们就能有所了解。但所谓COM对象究竟是什么呢?为了便于理解,可以把COM看作是某种(软件)打包技术,即把它看作是软件的不同部分,按照一定的面向对象的形式,组合成可以交互的过程和以组支持库。COM对象可以用C++、Java和VB等任意一种语言编写,并可以用DLL或作为不同过程工作的执行文件的形式来实现。使用COM对象的浏览器,无需关心对象是用什么语言写的,也无须关心它是以DLL还是以另外的过程来执行的。从浏览器端看,无任何区别。这样一个通用的处理技巧非常有用。例如,由用户协调运行的两个应用,可以将它们的共同作业部分作为COM对象间的交互来实现(当然,现在的OLE复合文档也能做到)。为在浏览器中执行从Web服务器下载的代码,浏览器可把它看作是COM对象,也就是说,COM技术也是一种打包可下载代码的标准方法(ActiveX控件就是执行这种功能的)。甚至连应用与本机OS进行交互的方法也可以用COM来指定,例如在Windows和Windows
      NT中用的是新API,多数是作为COM对象来定义的。可见,COM虽然起源于复合文档,但却可有效地适用于许多软件问题,它毕竟是处在底层的基础技术。用一句话来说,COM是独立于语言的组件体系结构,可以让组件间相互通信。随着计算机网络的发展,COM进一步发展为分布式组件对象模型,这就是DCOM,它类似于CORBA的ORB,本文对此将不再做进一步的阐述。通过上面的讲述相信大家一定对ActiveX、OLE和COM/DCOM的关系有了一个清楚的了解。
  • 关于Alpha测试与Beta测试

    2008-10-03 19:56:31

    Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

    Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

    但是我们公司将系统测试阶段定义为a阶段与B阶段,a测试也就是测试人员执行的系统测试,许多刚毕业且有一定测试基础理论的同事对于目前公司定义的这种a测试很有疑议,但是在我看来:“白猫黑猫逮着老鼠就是好猫!”管他呢,作为测试人员就是要尽早的尽可能多的发现软件所存在的bug,从而保证软件产品的质量!

     

  • 系统测试的基础理论

    2008-10-01 23:13:16

    大多数测试人员对于系统测试的概念比较模糊,我面试过的一些测试人员以及我项目组里的测试人员很少有人能清楚的将系统测试的概念整个明白,其实很简单,按照软件测试的过程可以分为单元、集成、确认、系统、验收测试。系统测试属于其中的一个测试阶段,目前国内的中小型企业的测试人员主要集中在这个环节。我们有必要把这个概念弄清楚,我们到底在干什么,不至于盲目的应聘,盲目的跳巢。虽然划分的方法可能不是唯一的,但是你一定要有一个概念、一个
    professional的概念。
    系统测试包含功能测试与非功能测试
    功能测试包含正常功能与异常功能的测试,正常功能是基于程序的基本功能与逻辑的验证;异常功能包含网络异常、服务器异常、操作异常。
    非功能测试包含UI、UE测试,文档测试、安全测试、兼容性测试、安装、卸载、更新测试、性能测试等,其中性能测试又包含压力、负载、强度、容量、性能、并发等测试,兼容性测试包含软件兼容性、硬件兼容性,软件一般就是系统、浏览器、杀毒软件、防火墙之类的,硬件兼容性主要是涉及到一些做底层驱动类程序的公司对于硬件要求比较高或者纯粹的硬件板卡等的测试;安全包含功能级别、权限级别、加密解密、session、cookies、漏洞扫描、脚本攻击等;UI主要是一些文字、tip、按钮、快捷方式等的测试;UE是用户体验级别的测试。
      这些测试看似简单,其实不然,如果真正能精通的测试人员也算是senior的系统测试工程师了。

Open Toolbar