生活的乐趣都在过程里面,而目的只是在长长的过程之后一秒钟的高潮

我的最新日志

  • 测试管理相关

    2008-11-06

    看到几段文字,我贴上来。

    国内企业好像还没有PM 这个角色,而测
    试人员又往往成为开发人员的附庸,一个Bug 是否要被解决全由开发人员说了算,这很糟
    糕,就像政治上一个权力没有被有效的制衡一样,一定会产生各种问题。

    做完一个版本后,还会让所有员工匿名投票,找出这次研发过程中出
    现的各种问题以便在下个版本中解决(此过程称为Postmortem,挺吓人的一个词)。

    微软的Bug 处理过程,非常类似于“击鼓传花”的游戏。鼓点响起,你的任务
    就是尽快把自己手中的“花”(Bug)传给下一个人,不要让它在自己手里耽误很长时间。
    从表面上看,在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你,但
    是有Email 跟着、有Bug 催着,你永远不可能偷懒。没有人盯着你,只是事情如影随形,
    而且所有和你相关的事情都是公开的,相关的人都知道,就像处于非常开放的舆论监督之中,
    除了把事情办漂亮你还能有别的选择吗?

    想办法,把对某个人的依赖尽量降低,并使产品可持续发展。

    但是测试这一块大家还是不够重视,对测试人员的素质要求也不是很高、人员比例也较
    低,测试人员往往依附于开发人员的直接管理,人微言轻.

  • 关于QTP参数化的一个思路

    2008-10-31

    我可以参数化3组不同权限的用户,进行登陆测试,这样用一个脚本完成了3个不同用户的登陆,方便维护脚本.
  • QTP action三种调用方式

    2008-10-31

    QTP调用Action有三种方式:

    a)call to new Action,在当前test中创建一个新的Action;
    b)call to Copy of Action;以嵌套方式调用
    c)call to existing action,调用一个re-usable action,如果这个re-usable action来自另外一个test,将以只读的方式插入到当前test中。
  • 性能调整基础知识

    2008-10-24

    1.确定问题
    可以从几个方面入手:

    应用程序代码:通常情况下,很多程序的性能问题都是写出来的,因此对于发现瓶颈的模块,应该首先检查一下代码。

    数据库配置:数据库配置经常会引起整个系统运行缓慢,一些诸如Oracle的大型数据库都是需要DBA进行正确的参数调整才能投产的。

    操作系统配置:操作系统配置不合理也可能会引起系统瓶颈。

    硬件设置:磁盘速度、内存大小等都是容易引起瓶颈的原因,因此这些都是分析的重点。

    网络:网络负载过重会导致网络冲突和网络延迟。

    系统性能问题不是显而易见的,要进行仔细的查找才能够进行正确的定位。

    2.确定原因(主要取决于你的经验)

    问题的影响是什么:响应时间还是吞吐量,或者其他问题?

    是大多数用户还是少数用户遇到了问题?如果是少数用户,这几个用户与其他用户的操作有什么不同?

    系统资源监控的结果是否正常:cpu的使用是否到了极限?I/O情况如何?

    3.确定调整目标和解决方案

    确定调整目标的主要作用是明确何时停止调整系统,否则工作将永无止尽。

    提高系统吞吐量

    缩短响应时间

    更好的支持并发

    设计解决方案的主要依据就是这些调整目标,有了明确的方案和目标,就可以进行后面的工作。

    4.测试解决方案

    5.分析调整结果

    主要考虑以下的问题:

    系统调整是否达到或者超出了预定的目标?
    系统是整体性能得到了改善,还是以牺牲某部分性能来解决问题的?
    调整是否可以结束了?



  • 性能测试工程师应该具备的技能

    2008-10-24

    1.掌握常见自动化测试工具的使用

    2.具备一定的编程能力

    3.掌握基础的数据库知识

    4.掌握常见的操作系统知识

    5.掌握一些web应用服务器例如Weblogic和Websphere等的使用

    6.具有综合分析问题的能力,例如通过综合分析测试结果来确定系统瓶颈。

  • 架构剖析

    2008-10-22

    web应用需要底层架构的支持-web服务器硬件/软件、DNS入口、网络设备、负载均衡器等等。

    任何好的web安全评估方法,首先都是识别和分析应用程序所位于的底层架构的。

    踩点和扫描:定义范围
    注册调查、DNS查询、常规的组织结构调查
    服务器发现(ping扫描)、网络服务识别(端口扫描)

    Banner抓取,通常可以确定目标web服务器软件的类型及版本

    高级HTTP指纹:抓取HTTP相关版本的Banner称之为web服务器指纹识别。
    例如,一个IIS服务器和一个Apache web服务器可能会对某个非法的HTTP请求返回不同的响应信息。(这是确定web服务器真实类型和版本非常好的方法)

    不常见的http请求方法
    httpprint工具使用了诸如检查HTTP头顺序等的大部分探测技术。他也带有可定制的web服务器指纹数据库。

    中间件架构(负载均衡、虚拟服务器配置、代理和web应用防火墙)

    虚拟服务器(一般小公司比较喜欢用,为了节约硬件条件,可以在一台server上模拟多个不同IP)

    检测负载均衡器
    探测在目标站点上是否运行了负载均衡器的方法:在一个ip范围内做端口扫描

  • SQL技巧

    2008-10-21

    使用SQL时必须考虑的关键因素。依我看来,有五大要素:

    1.获得结果集所需访问的数据量

    2.定义结果集所需的查询条件

    3.结果集的大小

    4.获得结果集所涉及的表的数量

    5.多少用户会同时修改这些数据

    一.数据总量(Total Quantity of Data)

    必须访问的数据总量,是要考虑的 最重要因素。没有确定目标容量之前,很难断定查询执行的效率。

    二.定义结果集的查询条件(Criteria Defining the Result Set)

    多数情况下会涉及where子句条件,应该从几个方面考虑("过滤"、主要SQL语句、以及庞大的数据量对查询的影响等)。这个问题比较复杂。

    三.查询所返回的数据量(或是SQL语句改动的数据量)(Size of the Result Set)

    取决于表的大小和过滤条件的细节。

    个人认为应该从以下几个角度去考虑1.若干个独立使用时效率不高的条件,结合起来使用时会产生极高的效率.

    从技术角度来讲,结果集的大小并不重要,而是取决于最终用户的感觉。用户的耐心,在很大的程度上和预期返回的记录条数有关

    熟练的开发者应该努力使响应时间与返回的记录数成比例。

    四.表的数量(Number of Tables)


  • Http分析工具和篡改工具简介

    2008-10-20

    一.TamperIE工具
    TamperIE 是来自Bayden系统的一种浏览器辅助对象(Browser Helper Object,BHO).它非常简单,只有两个选项-篡改GET和Post.在默认情况下,设置为仅篡改post,所以当你在浏览时遇到post请求时,TamperIE会自动阻断提交并在屏幕上显示出来。

    二.IEWatch
    IEWatch是简单但功能完整的HTTP监控客户端,它可以作为浏览器栏集成在IE中。它位于浏览器的下方,将HTTP和HTTPS交互的所有方面都暴露出来,包括请求头、表单、cookies等等,都可以进行简单双击输出日志中的对象进行详细的分析。但不能篡改参数

    三.IE Headers
    基本功能与IEWatch一样,他也不允许篡改数据

    以上都是IE插件

    Firefox插件(用于HTTP分析和篡改)
    一。LiveHTTPHeaders
    二。TamperData
    三.Modify Headers
  • web安全薄弱点

    2008-10-20

    1.web平台:web平台软件漏洞,包括Http底层服务软件(比如,IIS或Apache)等底层基础设施,以及应用程序开发框架(如Asp.Net或者PHP).

    2.web应用:对授权、认证、站点结构、输入验证、程序逻辑以及管理接口进行攻击。

    3.数据库:通过数据库查询进行特权命令,操纵查询以返回额外的数据集,这里最具破坏性的攻击是SQL注入。

    4.web客户端:活动内容执行、客户端软件漏洞攻击、跨站脚本错误,以及钓鱼欺骗

    5.传输:窃听客户-服务器通信,SSL重定向

    6.可用性:如果要你迅速地指出更危险的"黑客"技术,拒绝服务攻击(denial of service,DoS)经常会被遗漏,其实DoS攻击是任何可公开访问的Web应用所面临的最大威胁之一。让任何资源都对公众开放本来就有很大的挑战,在网络世界中更是如此。

    其中Open Web Application Security Project(owas)就是流行之一。
  • QTP试用范围

    2008-10-16

    如果软件的GUI界面都在不停的变化,确实不太适合做自动化测试。但是我们也可以考虑一些变通的方法,减少脚本维护的工作量。比如我们可以把GUI的属性写到xml文件里,然后QTP从xml读取属性值,并使用setProperty方法将属性赋值给测试对象,最后就是脚本的执行了。在去年的自动化测试过程中,曾小范围的尝试过这种做法,但是效果不理想,主要是学习成本高:
    1、要解决XML在TD上的存储和读取问题;
    2、要解决QTP对XML的读取和写入问题;
    3、要解决XML文件和测试对象属性的对应问题;
    4、即使把测试对象的属性都写进xml文件,对XML文件的维护又成了我们头疼的事情。
    最后采取的方法是,对于IE标题、页面名称等固定的对象,则建立共享对象库,对于每个功能模块的GUI对象,由于变化次数比较多,采用单独对象库模式。软件即使要变,也不可能把所有的GUI对象都改头换面。这样当开发人员每次发版的时候,我们会去了解哪些模块进行了改动,然后花1-2天对脚本进行调试和修改,完成后就是脚本的整体运行了。
Open Toolbar