现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp

发布新日志

  • 《接口测试全流程扫盲》怕以后找不到帖子,特意copy下来的。转自“蓝风雨66”的空间

    Julia_RL 发布于 2018-06-08 11:08:38

      接口测试全流程扫盲
      扫盲内容:
      1.什么是接口?
      2.接口都有哪些类型?
      3.接口的本质是什么?
      4.什么是接口测试?
      5.问什么要做接口测试?
      6.怎样做接口测试?
      7.接口测测试点是什么?
      8.接口测试都要掌握哪些知识?
      9.其他相关知识?
      1.什么是接口?
      接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。
      2.接口都有哪些类型?
      接口一般分为两种:1.程序内部的接口 2.系统对外的接口
      系统对外的接口:比如你要从别的网站或服务器上获取资源或信息,别人肯定不会把数据库共享给你,他只能给你提供一个他们写好的方法来获取数据,你引用他提供的接口就能使用他写好的方法,从而达到数据共享的目的。
      程序内部的接口:方法与方法之间,模块与模块之间的交互,程序内部抛出的接口,比如bbs系统,有登录模块、发帖模块等等,那你要发帖就必须先登录,那么这两个模块就得有交互,它就会抛出一个接口,供内部系统进行调用。
      接口的分类:1.webservice接口 2.http api接口
      webService接口是走soap协议通过http传输,请求报文和返回报文都是xml格式的,我们在测试的时候都用通过工具才能进行调用,测试。
      http api接口是走http协议,通过路径来区分调用的方法,请求报文都是key-value形式的,返回报文一般都是json串,有get和post等方法,这也是最常用的两种请求方式。
      json是一种通用的数据类型,所有的语言都认识它。(json的本质是字符串,他与其他语言无关,只是可以经过稍稍加工可以转换成其他语言的数据类型,比如可以转换成Python中的字典,key-value的形式,可以转换成JavaScript中的原生对象,可以转换成java中的类对象等。)
      3.接口的本质及其工作原理是什么?
      接口你可以简单的理解他就是URL,工作原理就会说URL通过get或者post请求像服务器发送一些东西,然后得到一些相应的返回值,本质就是数据的传输与接收。
      4.什么是接口测试?
      接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
                    --百度百科
      简答的说就是通过URL像服务器或者其他模块等,传输我们想传输的数据,然后看看他们返回的是不是我们预期想要的。
      5.问什么要做接口测试?
         1.越底层发现bug,它的修复成本是越低的。
         2.前端随便变,接口测好了,后端不用变,前后端是两拨人开发的。
         3.检查系统的安全性、稳定性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元。
       4.如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案。
       5. 接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
       6.   现在很多系统前后端架构是分离的,从安全层面来说:
              (1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
              (2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
      6.怎样做接口测试?
      --由于我们项目前后端调用主要是基于http协议的接口,所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如:postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
      --也可以用 接口自动化来实现,就是用代码实现,框架和UI自动化差不多,发送请求用断言来判断。
      7.接口测测试点是什么?
      目的:测试接口的正确性和稳定性;
      原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;
      重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;
      核心:持续集成是接口测试的核心;
      优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本);
      用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常);
      PS:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能,外部用户真正需要什么功能;
      问题1.1、后端接口都测试什么?
        --回答这个问题,我们可以从接口测试活动内容的角度下手,看一下面这张图,基本反应了当前我们项目后端接口测试的主要内容:
      问题2、后端接口测试一遍 ,前端也测试一遍,是不是重复测试了?
        --回答这个问题,我们可以直接对比接口测试和app端测试活动的内容,如下图为app测试时需要覆盖或考虑内容:
       从上面这两张图对比可以看出,两个测试活动中相同的部分有功能测试、边界分析测试和性能测试,其它部分由于各自特性或关注点不同需要进行特殊的测试,在此不做讨论。接下来我们针对以上三部分相同的内容再进行分析:
      1、基本功能测试:
      由于是针对基本业务功能进行测试,所以这部分是两种测试重合度最高的一块,开发同学通常所指的也主要是这部分的内容。
      2、边界分析测试:
      在基本功能测试的基础上考虑输入输出的边界条件,这部分内容也会有重复的部分(比如业务规则的边界)。但是,前端的输入输出很多时候都是提供固守的值让用户选择(如下拉框),在这种情况下测试的边界范围就非常有限,但接口测试就不存在这方面的限制,相对来说接口可以覆盖的范围更广,同样的,接口出现问题的概率也更高。
      3、性能测试:
      这个比较容易区分,虽然都需要做性能测试,但关注点确大不相同。App端性能主要关注与手机相关的特性,如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别,所以这部分内容是需要分开单独进行测试的,理论上来说这也是不同的部分。 
      综论:
      1、接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面。除此之外,针对各自特性的测试都不一样,需要分别进行有针对性的测试,才能确保整个产品的质量。
      2、接口测试可以关注于服务器逻辑验证,而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证
      3、接口测试持续集成:
      对接口测试而言,持续集成自动化是核心内容,通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化,主要应用于回归阶段,后续还需要加强自动化的程度,包括但不限于下面的内容:
        a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试,冒烟测试阶段延伸,最终达到全流程自动化。
        b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等
        c) 问题定位:报错信息、日志更精准,方便问题复现与定位。
        d) 结果校验:加强自动化校验能力,如数据库信息校验。
        e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探,提高代码覆盖率。
        f) 性能需求:完善性能测试体系,通过自动化的手段监控接口性能指标是否正常。
      4、接口测试质量评估标准:
        a) 业务功能覆盖是否完整
        b) 业务规则覆盖是否完整
        c) 参数验证是否达到要求(边界、业务规则)
        d) 接口异常场景覆盖是否完整
        e) 接口覆盖率是否达到要求
        f)  代码覆盖率是否达到要求
        g) 性能指标是否满足要求
        h) 安全指标是否满足要求
      8.接口测试都要掌握哪些知识?
      ①了解系统及内部各个组件之间的业务逻辑交互;
      ②了解接口的I/O(input/output:输入输出);
      ③了解协议的基本内容,包括:通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等;
      ④常用的接口测试工具,比如:jmeter、loadrunner、postman、soapUI等;
      ⑤数据库基础操作命令(检查数据入库、提取测试数据等);
      ⑥常见的字符类型,比如:char、varchar、text、int、float、datatime、string等;  
      如何学这些技能?
      ①系统间业务交互逻辑:通过需求文档、流程图、思维导图、沟通等很多渠道和方式;
      ②协议:推荐《图解http》这本书,内容生动,相对算是入门级的书籍,其他的还有《图解tcp、IP》等;
      ③接口测试工具:百度这些工具,然后你会发现,好多的教学博客、相关问题解决方案、以及一些基于工具的书籍,当然,选择合适的书很重要;
      ④数据库操作命令:学习网站(W3C、菜鸟教程)、教学博客,以及一些数据库相关书籍,入门级推荐:《mysql必知必会》、《oracle PL/SQL必知必会》等
      ⑤字符类型:还是百度,有句话这么说:内事不决问百度,外事不决问Google。。。
       如何获取接口相关信息?
      一般的企业,都会由开发或者对应的技术负责人员编写接口文档,里面会注明接口相关的地址、参数类型、方法、输入、输出等信息,如果没有,想办法获取。。。
      接口文档八要素:
      封面:封面最好是本公司规定的封面,有logo,内容标题,版本号,公司名称,文档产生日期;
      修订历史:表格形式较好些,包括:版本、修订说明、修订日期、修订人、审核时间审核人等;
      接口信息:接口调用方式,常用的GET/POST方式,接口地址;
      功能描述:简洁清晰的描述接口功能,比如:接口获取的信息不包括哪些;
      接口参数说明:每个参数都要和实际中调用的一样,包括大小写;参数的含义言简意赅的说明,格式,是string 还是int 还是long等格式;
                  说明部分,说明参数值是需要哪里提供,并详细说明参数怎么生成的,例如时间戳,是哪个时间段的,参数是否必填,一些参数是必须要有的,有些是可选参数等;
      返回值说明:
      ①最好有一个模板返回值,并说明每个返回参数的意义;
      ②提供一个真实的调用接口,真实的返回值;
      调用限制,安全方面:
      加密方式,或者自己公司一个特殊的加密过程,只要双方采用一致的加密算法就可以调用接口,保证了接口调用的安全性,比如常见的md5;
      文档维护:文档在维护的时候,如有修改一定要写上修改日期,修改人,对大的修改要有版本号变更;
      9.其他相关知识?
      get请求,post请求的区别:
      1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
      2、GET的URL会有长度上的限制,则POST的数据则可以非常大。
      3、POST比GET安全,因为数据在地址栏上不可见。
      4、一般get请求用来获取数据,post请求用来发送数据。
      其实上面这几点,只有最后一点说的是比较靠谱的,第一点post请求也可以把数据放到url里面,get请求其实也没长度限制,post请求看起来参数是隐式的,稍微安全那么一些些,但是那只是对于小白用户来说的,就算post请求,你通过抓包也是可以抓到参数的。(唯一区别就是这一点,上面3点区别都是不准确的)
      http状态码:
      1、200 2开头的都表示这个请求发送成功,最常见的就是200,就代表这个请求是ok的,服务器也返回了。
      2、300 3开头的代表重定向,最常见的是302,把这个请求重定向到别的地方了。
      3、400 400代表客户端发送的请求有语法错误,401代表访问的页面没有授权,403表示没有权限访问这个页面,404代表没有这个页面。
      4、500 5开头的代表服务器有异常,500代表服务器内部异常,504代表服务器端超时,没返回结果。
      webservice接口怎么测试:
      它不需要你在拼报文了,会给一个webservice的地址,或者wsdl文件,直接在soapui导入,就可以看到这个webservice里面的所有接口,也有报文,直接填入参数调用,看返回结果就可以了。
      天气预报wsdl地址:http://www.webservicex.net/globalweather.asmx?wsdl   
      cookie与session的区别:
      1、cookie数据存放在客户的浏览器上,session数据放在服务器上。
      2、cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗
      考虑到安全应当使用session。
      3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
      考虑到减轻服务器性能方面,应当使用cookie。
      4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
      5、所以个人建议:
      将登陆信息等重要信息存放为session
      其他信息如果需要保留,可以放在cookie中

  • 某公司测试环境规划方案

    雪儿 发布于 2008-05-27 17:14:10

    某公司测试环境规划方案(全是瞎编的)

     

    假设1:目前测试部门共有20名测试人员,分为三个小组,其中功能测试小组15人、性能测试小组2人,兼容性/界面测试小组3人。

    假设2:未来3年,测试部门的扩大比例为50%,到30人。其中功能测试人员23人,性能测试人员3人,兼容性/界面测试人员4人。

    假设3:公司的项目有CS架构,也有BS架构。目前的项目有80%CS结构,有20%BS结构。未来的发展趋势要全部转为BS结构。

    假设4:项目关注的测试有:功能、性能、兼容;其它类型的测试也要包含,但不考虑单独申购机器,可以在总预算上预留一部分进行。

    假设5:只考虑机器的数量,以最大程序地节约成本,但不考虑机器硬件配置导致的价格差异。

    假设6:兼容性只考虑WINDOWS平台,包括WIN2KWINXPWIN2003VISTA。浏览器:IE5.5IE 6.0 IE7.0、遨游、FIXFOX(不考虑版本)。其它如果项目临时需要考虑,可以借用其它机器完成。

     

    一、硬件需求:

     

    首先:功能测试,其使用的机器都在自己的测试机,为了保证测试环境的干净,每位测试人员都会有一台工作机和一台测试机(理想状况,如果没有机子可以使用虚拟机进行)。所需数15――23台。

     其次:兼容性测试,根据公司的产品性质,对兼容性的考虑,需要510台,如果5台机的话,每台机需要安装2个操作系统(估算的)。

    性能测试:(应该有专门的规划)。CS结构假设需要支持200个并发(多数项目如此),而每个客户端发起的请求数是100个,则需要2台服务器,1台控制机(服务器), 1台数据库服务器,1台应用服务器,共4台。

    BS结构的并发是5000个,每个客户端(服务器)支持1000个并发,则需要5台服务器,1台控制器(服务器),1台数据库服务器,1台应用服务器,共8台。

      考虑如果两类项目不会同时进行测试的话,所需要的机器数量(满足BS就行): 8台服务器,如果项目有并发的情况,需要的机器为12台服务器。 基于成本考虑,可以购买10台服务器。如果有项目并行进行性能测试时,可以临时借用功能测试机来完成。(服务器配置下面再谈。)

    总结:20台台式机+7台服务器(最小配置)

          33台台式机+12台服务器(最大配置)

     

      推荐配置:30台台式机+10台服务器。

    其它需求(要问相关部门),:能放这么多台式机的空间最好是单独的房间,能承受重量、隔音、隔潮,安装2匹的空调,UPS电源。 机架(不知道需要多少)。。。 这些找别人考虑吧。

    二、台式机和硬件服务器配置

     

      台式机:2G内存。 CPU(2.3以上)200G空间

      服务器:8G内存。 8CPU2.3以上),200G空间

    具体配置是多少不知道,不过最好保持一致。

     

    三、软件(如果要正版的话)

      如:WIN2K+SP2   两套

          ORALCE10G   一套

          LR 8.1        一套

    。。。。。。。。。。。

    四、环境管理

      1)需要相应的文档,如环境管理办法

      2)如果可能,做一个软件来实现

      3)  可能还需要一个环境管理员

    五、预算

       做个表格,看看共有多少钱,就OK

     

  • [转]如何量化评估被测试软件的质量?

    小狐狸如如 发布于 2008-05-27 22:31:00

     软件测试每周一问在软件测试过程中,我们需要根据各种度量数据从不同角度来对被测软件的质量进行分析评估,找出软件的质量薄弱点、评价软件发布的风险、预估软件测试结束的时间等等,这些分析评估涉及到各种角度、不同指标,也有一些从工程中总结的分析模型,欢迎大家踊跃讨论,分享各自在工作中所使用的评估方法,共同进步。

            会员cityyard的精彩回答:

            量化评估,最重要的一点是经验。同时科能需要大量统计工作作为铺垫。
            下面我主要从bug统计来说一下我的经验。

    1。测试项目数和摘出bug数预测
            一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的bug数目和需要的测试项目。
            现在有些公司流行每千行bug数的标准来制定测试计划,这个标准是通过以往测试经验总结出来的,
            一般来说,同类的产品,尤其是同一个开发流程的产品,这些数值不应该相差太多,
            如果相差一个数量级以上,我们几乎可以说,要么是QA出问题了,要么是开发出问题了。

    2。测试bug分级
            使用bugzilla或者Jira之类的缺陷管理系统何以很容易的实现bug分级,一般至少有
            Fatal, Major, Minor, cosmatic这几种,还有一种特殊的叫做blocker,意思是这个bug
            会影响测试进度。产品发布前,可以根据实际情况,定一个界限级别,比如要求
            新出Major为0,并且所有已有的Major全部close。

    3。测试bug收敛
            量化评估必不可少的是bug收敛,这个要通过统计每日新出bug并跟踪已有bug
            制作收敛曲线来实现。收敛曲线的形状发散表明目前产品极其不稳定,收敛曲线
            开始收敛表示目前产品趋于稳定,完全收敛之后可以认为是发布的时机。

    4。测试bug分布
            bug分布是决定下面测试重点的一个重要的参考数据。首先还是需要统计,
            找出所有已有的不同级别的bug在各个模块的分布,假如ABC三个模块,
            A模块占了bug的60%,C模块占了bug的8%那么,我们可以得出这样的结论,
            软件的不稳定瓶颈在于A模块,是一个薄弱点,需要开发人员集中力量对应。
            但是C模块也是一个可疑模块,因为出现bug率太低,如果不是开发的太好
            就是测试方法不当。

    5。测试bug的周期
            一个bug的生命历程是一个完整的轮回,从他出生(open)开始,到调查(Accept)
            到修复(Fix),再到确认(Verify)是最简单的路线,这个周期越短,说明项目进展越顺利
            反之则意味着项目进度目前有很大的阻碍。

    6。降级bug数
            降级bug的多少对于软件质量评估也是一个重要参考标准,降级bug也就是由于修正一个bug
            又作了一个新bug,降级bug数目过多意味着现在的产品在越修越坏。

            一个新的QA团队,在2,3,4,5,6步骤可能会有所迷惑,不知道阈值应该怎样选
            但如果每次都坚持这样做,很多次之后2,3,4,5,6会给这个团队大量的经验积累,
            完全可以做到看着统计图估计出一个产品处于什么状态,需要加强哪些方面等等。

  • 关于测试人员的考核(本人原创)

    godn_1981 发布于 2008-05-17 00:10:39

    关于测试人员的考核,这个问题一直很头痛,后来参照了不少著名IT公司的做法,写了一篇稿子,刚好51testing上有人问到这个问题,就贴上去,不小心获得第一名~~真是无心插柳柳成荫,于是贴出来给大家参考一下

    下面是正文:

    测试考核的问题

    鄙人从事软件测试好几年了,也一直为该问题困扰,每次项目作完了,感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美,既然存在问题,说明测试人员的考核做的不到位,所以最近痛定思痛,也咨询了一些在微软和IBM做测试的朋友,结合自己多年来的实践,得出如下核心考核指标,和大家共享。
    测试人员主要是三个方面。
    第一,整体工作效率。第二,工作结果。第三,过程控制。(针对测试主管或组长)

    1.整体工作效率
    1.1有效工作时间
    主要check指标是每日实际工作时间,按照Ms的标准,一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间,那么不能成为好的测试工程师,因为他有能力做得更好。
    1.2是否在制定时间内完成工作任务
    主要check指标是进度偏离度。主要是和测试计划相比,有多少的延期。这个指标计算是:计划时间/实际需用时间。
    当然,本指标未考虑其他因素,如开发人员窝工导致的delay。
    2.工作结果
    2.1测试用例的数量和质量
    a,测试用例的数量
    主要考核指标是用例编写速度,考核办法是测试用例的个数/写用例所用时间。
    b,测试用例的质量
    主要考核指标是用例编写质量,用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目,应该是70%以上才算是质量比较好的用例。
    2.2bug的数量和质量
    a,bug提交的数量
    主要考核指标是提交bug的数量,这个指标根据项目不同而定,不好给出固定经验值。
    b,bug的质量
    主要考核指标是提交bug的质量,即提交的bug,严重程度和,发现路径的复杂程度
    c,发现bug的阶段
    主要考核指标是提交bug的时间段,具体执行是统计在测试的每个阶段,发现bug的比例,特别是严重的bug发现的早晚
    2.3是否及时验证关闭bug
    主要考核指标是验证关闭bug的及时度
    2.4测试自动化程度及收效
    主要考核指标是,测试中自动化运用的含量,也就是测试技术含量,成果如何?
    2.5所负责模块的产品总体质量以及用户反馈
    这个总体质量是产品发布之后一段时间才能得出结论,主要是市场,用户对产品的质量、稳定性、性能的反馈。
    考核的主要指标是两个。
    a,根据市场反馈(由经理定性考核)
    b,根据测试人员提交的bug和用户反馈的bug之间的比例,比例越大,说明测试质量相对越高。当然前提是必须划清楚客户的新需求,或者对spec设计方面的抱怨。
    3.过程改进
    考核点,是纵向对比,相比上一个项目,在质量控制上和测试进度进程上有否进步。包括测试方法,提升质量的手段,测试数据记录,用例更新等等有没有改进。
    该项具体考核方法也是经理来根据测试组在过程中具体表现,来定性打分。
    还包括测试人员在测试过程中的学习能力。这个也是定性。
    4.考核注意事项
    4.1统计bug的注意事项
    5.其它注意事项
    作为考核者要注意以下比例,也许有些没有列入考核内容,但是如下这些点可以指导测试。
    a,测试团队发现的bug和所有bug之间的比例
    b,spec设计造成的bug
    c,重复或者误提交的bug所占的比例
    d,每周发现的bug的趋势图
    e,Bug严重等级的构成比例
    f,Bug从提交到解决的平均需要时间
    g,Bug从解决到关闭的平均需要时间

    51testing上地址:http://bbs.51testing.com/viewthread.php?tid=111440&extra=&page=2

  • 软件测试中容易忽略的缺陷<转>

    zhan_gqian 发布于 2008-05-28 17:54:33

    摘要
        在系统测试和确认测试中,有些缺陷由于某些原因往往被忽略了,这就给软件留下了隐患或者危机。本文通过描述这些容易忽略的缺陷,提供一个完善测试用例和测试执行的参考。
    关键词:缺陷
    正文:
        通常软件测试会暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和确认测试中,测试人员容易遗漏一些隐藏的缺陷。众所周知,软件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:
    1、安装缺陷
        通常项目组完成代码后,发布时候安装打包是最后一个环节,而测试人员通常在测试的时候,没有仔细的测试这一部分,而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件,结果正式安装时候出现问题,引起例如控件没有注册,注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件,成数据丢失;使用绝对路径;安装顺序没有说明书
    2、配置文件
        有些文件在 ini 等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。另外,有些安装文件的 XML 文件,为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的测试人员,必须检查这些可以用记事本打开的文件。因为,一个稍有常识而且喜欢探索的用户,可能从中获取信息而成为不自觉的黑客。所以,配置文件可能成为软件安全方面的一个缺陷。
    3、网页安全缺陷
        现在网站开发已经注意到:登陆网站进入其内部网页后,直接拷贝网址,然后粘贴到另IE 窗口输入,可以绕过登陆直接访问。也许商业网站很关注这个问题,但是很多行业软件却很容易忽略。
        网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个明显的漏洞,而且还大大增加了错误发生的几率。
    4、判断顺序/逻辑缺陷
        对界面进行多个输入判断的时候,非常容易出现这种问题。例如判断年月顺序,判断长度,判断非空等。假如操作员仅仅满足单个条件,保存不能成功;而按界面从上之下顺序一一满足条件之后,保存是没有问题的。但是,改变一下输入的次序,校验失效。例如,一一满足条件之后,不保存,倒过来将上面的输入改成非法输入,然后保存,结果居然也能成功,这是因为原先的判断由于发生过,或者根据语句顺序只检查最后一个判断,所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确,有可能引起系统崩溃或者后续数据错误。所以,在测试的时候,不要按照正常的顺序输入,而是要打乱步骤,看看代码是否强健,是否在判断逻辑上没有错误。良好的代码应该经得起折腾,至少保存时会再此全部进行判断,而不只是简简单单走到判断的最后一行。
    5、调试语句和冗余信息
       维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息,会使不明真相的用户产生误以为系统发生了严重故障,从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用,其结果可想而知;而多余的按钮会误导好奇心强的用户操作,产生不必要的错误。
        同样值得关注的还有参数设置,由于没有实际数据,开发人员在调试或者单元测试的时候,习惯性的进行自我设定而忘了删除,测试人员可能会忽略掉了这部分测试,也可能导致在客户现场发生错误而影响系统发布和验收。
    6、不可重现的故障
        新参加测试的人员或者新来的开发人员总是要问,不可重现的缺陷是否需要记录,有必要吗?回答是肯定的。测试必须如实的记录发生的问题,也许不能重现,或者使非软件系统本身问题,但是,可能这些偶然性背后是有规律的,不记录这些,就不可能发现这些规律。
    7、多节点的逆向流转缺陷
        当前软件不少喜欢使用工作流来驱动。工作流的问题,就是可能出现多个流向分支。测试容易忽略的部分,就是工作流多节点的逆向流转。例如,通过不通过涉及两个分支,但是流程逆转的时候,有可能不是回到上一节点而是平级的另一个节点去了。测试要格外注意这类用例的设计。另外,有些时候默认分支在向前的时候是有默认值的,例如默认通过,那么保存的时候要提示用户是否通过,否则可能由于操作疲劳而走错了节点,引起回退。
    8、输入框缺陷
        试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候,输入框会根据长度大小自动截断输入长度。但是用鼠标,截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了,保存的时候,数据库崩溃。有些网站登陆的口令****可以拷贝下来的,只要放在剪贴板里面马上明文显示
        输入框可以说是问题最多的部分,能够引起的麻烦也很多。日期、数字、文本等等,都需要耐心的测试一下。
    9、界面布局缺陷
       曾经有一次,项目经理回来向测试部反映一个问题,客户对界面不满意。原因很简单,因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按。这个问题是测试人员没有意料到的,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布
        界面布局还可能发生在窗口最大化和最小化上,有可能窗口缩小的时候没有下拉框或不匹配分辨率,对用户来讲,这个错误实在很低级。有些用户由于操作习惯,非常不喜欢腾出手使用鼠标,尤其是大量输入的界面,因此,要注意设置键盘的快捷方式。还有,按 Tab定位到下一焦点时要注意顺序,避免跳转太灵活而让操作人员感到无从适应,在界面进行维护或者修改的时候,不要忘了测试开发人员是否无意改变了这些快捷方式和跳转顺序。
    10、版本和补丁包的环境问题
        理论上讲,这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包,问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例,多用不同软件版本的机器跑一跑。测试有个定律是:你没跑过的地方,就一定会出事。经常听到开发人员抱怨,怎么我的机器没问题,你的机器就有事了呢?这不能完全靠配置管理员解决问题,环境配置项是大家最容易忽略的。
    11、用户管理缺陷
        用户管理的角色和授权需要好好研究一下,作过测试的人员都知道,有时候为了测试的方便,测试用户都是具有超级权限的用户。而且,比较容易忽略用户管理这一部分的测试。往往发往客户的时候,很多测试用户都没有删除。
        另外,有些接口的用户和口令,到软件使用寿命结束都没有更改过在一次测试中,测试人员发现,给一个用户授超级用户权限,之后更改这个用户为受限权限。使用中发现,用户居然没有真正回收权限,用户管理界面上没有任何不对。及早准备用户管理用例,不要等到测试快结束时候才想起。
    12、常识缺陷
        从逻辑或者统计学上讲,计算机是允许如此处理的,但是从常识上来讲,这些情况不可能发生。例如电话号码不可能出现小数点,终止时间不能大于开始时间等等。除此之外,常识还要结合业务特点来进行判断,因此,开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现,对用户来说,这些错误可能是很荒谬的。
        尽管我们不可能完美的测试一个软件,但是我们仍然可以改进我们的测试。每次测试结束,及时总结测试中的不足,进一步完善用例。思考一下那些容易忽略的软件缺陷,能提高对测试的认识,提高所在组织软件的质量。
  • 有用的测试网站收集

    lisilin 发布于 2009-01-16 10:00:13

    http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
    http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
    http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
    http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
    http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局(NASA)投资设立的一个软件可靠性和安全性研究中心,研究包括了度量、工具、风险等各个方面
    http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织,可以提供研究论文的下载
    http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构(Sofrware Engineering Process Office)主页,包括软件工程知识方面的资料
    http://www.asq.org/ 是世界上最大的一个质量团体组织之一,有着比较丰富的论文资源,不过是收费的
    http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面,属于个人网页,上面有些资源可供下载
    http://www.benchmarkresources.com/ 提供有关标杆方面的资料,也有一些其它软件测试方面的资料
    http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论,还提供测试方面的资料
    http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织,主要从事通过切片技术测试技术和转换技术来验证和分析系统,对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
    http://www.cc.gatech.edu/aristotle/ Aristole研究组织,研究软件系统分析、测试和维护等方面的技术,在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容,该网站有丰富的论文资源可供下载
    http://www.computer.org/ IEEE是世界上最悠久,也是在最大的计算机社会团体,它的电子图书馆拥有众多计算机方面的论文资料,是研究计算机方面的一个重要资源参考来源
    http://www.cs.colostate.edu/testing/ 可靠性研究网站,有一些可靠性方面的论文资料
    http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页,有比较丰富的资料下载,内容涵盖了测试的多个方面,包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
    http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心,提供有关软件可靠性研究方面的一些信息和资料,对这方面感兴趣的人可以参考
    http://www.dcs.shef.ac.uk/research/groups/vt/
    学校里的一个验证和测试研究机构,有一些相关项目和论文可供参考
    http://www.esi.es/en/main/ ESI(欧洲软件组织),提供包括CMM评估方面的各种服务
    http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站,有可靠性方面的一些资料提供参考
    http://www.fortest.org.uk/ 一个测试研究网站,研究包括了静态测试技术(如模型检查、理论证明)和动态测试(如测试自动化、特定缺陷的检查、测试有效性分析等)
    http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站,有一些测试方面的课程和资料供下载
    http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
    http://www.io.com/~wazmo/ Bret Pettichord的主页,他的一个热点测试页面连接非常有价值,从中可以获得相当大的测试资料,很有价值
    http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织,提供包括ISO标准系统方面的各类参考资料
    http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载,对这方面感兴趣的读者可以参考该网站,肯定有价值
    http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构,该机构提出了软件开发的全面验证和确认,在此可以获得这方面的研究资料
    http://www.kaner.com/ 著名的测试专家Cem Kanner的主页,里面有许多关于测试的专题文章,相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
    http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆,在这里你可以获得有关计算机方面各类论文资料,内容极其庞大,是研究软件测试不可获取的资料来源之一
    http://www.loadtester.com/ 一个性能测试方面的网站,提供有关性能测试、性能监控等方面的资源,包括论文、论坛以及一些相关链接
    http://www.mareinig.ch/mt/index.html
    关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载,包括了测试方面的内容
    http://www.mtsu.ceu/-storm/ 软件测试在线资源,包括提供目前有哪些人在研究测试,测试工具列表连接,测试会议,测试新闻和讨论,软件测试文学(包括各种测试杂志,测试报告),各种测试研究组织等内容
    http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站,每年都会举行两次
    http://www.qacity.com/front.htm 测试工程师资源网站,包含各种测试技术及相关资料下载
    http://www.qaforums.com/ 关于软件质量保证方面的一个论坛,需要注册
    http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构,提供各种质量和测试方面证书认证
    http://www.qualitytree.com/ 一个测试咨询提供商,有一些测试可供下载,有几篇关于缺陷管理方面的文章值得参考
    http://www.rational.com/ IBM Rational的官方网站,可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具,比较全面
    http://rexblackconsulting.com/Pages/publicat-ions.htm
    Rex Black
    的个人主页,有一些测试和测试管理方面的资料可供下载
    http://www.riceconsulting.com/ 一个测试咨询提供商,有一些测试资料可供下载,但不多
    http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文,尤其在启发式测试策略方面值得参考
    http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会,主要由测试专家Cem KanarJames Bach组织,有一些值得下载的资料
    http://www.sdmagazine.com/ 软件开发杂志,经常会有一些关于测试方面好的论文资料,同时还包括了项目和过程改进方面的课题,并且定期会有一些关于质量和测试方面的问题讨论
    http://www.sei.cmu.edu/ 著名的软件工程组织,承担美国国防部众多软件工程研究项目,在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能,可以快速检索到你想要的论文资料,并且可以免费下载
    http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接,包括:专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
    http://www.soft.com/News/QTN-Online/ 质量技术时事,提供有关测试质量方面的一些时事介绍信息,对于关心测试和质量发展的人士来说是很有价值的
    http://www.softwaredioxide.com/ 包括软件工程(CMM,CMMI,项目管理)软件测试等方面的资源
    http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料,各质量/测试网站介绍,各质量/测试工具介绍,各质量/策划书籍介绍以及与测试相关的工作网站介绍
    http://www.softwaretestinginstitute.com 一个软件测试机构,提供软件质量/测试方面的调查分析,测试计划模板,测试WWW的技术,如何获得测试证书的指导,测试方面书籍介绍,并且提供了一个测试论坛
    http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站,提供咨询和培训服务,并有一些测试人员社团组织,特色内容是缺陷处理方面的技术
    http://www.sqe.com/ 一个软件质量工程服务性网站,组织软件测试自动化、STAR-EASESTARWEST等方面的测试学术会议,并提供一些相关信息资料和课程服务
    http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料,论文等资源
    http://www.stqemagazine.com/ 软件策划和质量工程杂志,经常有一些好的论文供下载,不过数量较少,更多地需要通过订购获得,内容还是很有价值的
    http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站,有过程改进方面的一些资料提供
    http://www.tcse.org/ IEEE的一个软件工程技术委员会,提供技术论文下载,并有一个功能强大的分类下载搜索功能,可以搜索到测试类型、测试管理、测试分析等各方面资料
    http://www.testing.com/ 测试技术专家Brain Marick的主页,包含了Marick 研究的一些资料和论文,该网页提供了测试模式方面的资料,值得研究。总之,如果对测试实践感兴趣,该网站一定不能错过
    http://www.testingcenter.com/ 有一些测试方面的课程体系,有一些价值
    http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站,感兴趣的人一定不能错过
    http://www.testingstuff.com/ Kerry Zallar的个人主页,提供一些有关培训、工具、会议、论文方面的参考信息
    http://www-sqi.cit.gu.edu.au/ 软件质量机构,有一些技术资料可以供下载,包括软件产品质量模型、再工程、软件质量改进等
    http://www.csc.ncsu.edu/faculty/xie/softtestingedu.html

    http://www.testingeducation.org/

    http://www.qasoftwaretesting.com/

    http://www.onestoptesting.com/

    http://www.devbistro.com/articles/Testing/ 

    http://www.soft.com/Institute/HotList/index.html

    http://www.softwaretestingwiki.com/doku.php

    http://www.softwareqatest.com/

    http://www.aptest.com/resources.html

    http://www.cc.gatech.edu/classes/AY2005/cs4803epr_spring/ 国外大学的性能测试课程

    http://www.testing-post.com/testing/ 测试论坛

    http://www.stpmag.com/ 国外的软件测试电子杂志

    http://www.workroom-productions.com/papers.html E文文章下载站点

    http://www.informit.com/articles/index.asp?st=41368 E文文章下载站点
    http://www.informit.com/articles/index.asp?st=41271
     E文文章下载站点

    http://testertested.blogspot.com/2007/02/there-is-no-four-and-six-in-testing.html

     

     

  • 产品质量差及测试人员的责任过多源于中国公司总体管理水平低下

    zengyixun 发布于 2008-12-08 16:46:08

    转载请保留:本文出自zengyixun的51Testing软件测试博客:http://www.51testing.com/?9810

        任何人都知道产品质量是企业的生命,很多企业都会把质量放在嘴上,藏在心中,摆上媒体,但就是不落实在手中,或者落实的方法不对!
        质量不好,有几种情况:
        1、眼光短视!
        2、官本位作祟!
        3、思想上的偏差。
        4、方法不正确。
        第一种情况吧,他们从未想过做好产品质量,一但企业效益不好,就开始寻找新的赚钱的行业进行转产就是了。
        第二种情况,认为当官的就是水平高,当官的说的话就是对的,做产品的论证方法是这样的:一个当官的提出自己的见解,于是一大帮“专家”们为这个见解制作,编造合理性报 告。所以才会有人有这样的狡辩,XX总要是错的,他能坐到那个位置上去吗?你不过是一个小小的XXOO,也敢提反对意见?这是社会大环境,大背景,上好下效的不正之风造成的,所以我曾经以对一位领导笑言,李世民也不过2000多年才出一个嘛,我们怎么能期望一家小小的公司中出现李世民似的人物来!
        可是大家有没有想过,政治上的这种不正之风好理解,我们大不了不同他们玩了就是,但如果一般的企业也有这种官本位思想,这样的企业一定没有前途,就算能风光一时,也做不了百年品牌,当然也可能人家的想法是我死之后哪管洪水滔天,人家或者从未想过要做百年品牌呢,要不怎么说一家公司的天花板就是这家公司的领导者呢!
        应该说当官的(管理者)也是一个职位,也有自己的专业知识要加强,不要太把这个当一回事,如果把所有在企业中的位置都当成一种角色,所有这些角色是要合力去做好事情,提高产品质量,打造品牌,当这样的意识深入人心时,后面对于产品的质量问题的讨论就有了基础了,否则人为因素就会干扰事件因素,如此水就搅混了,水混了,人就看不清事情的本质,看不清,人就会跟着混,混蛋就多起来了,混蛋一多,王八蛋就有了作怪的空间与条件!一个多是混蛋、王八蛋的公司,能做出好产品么?
        可是问题就来了,人无完人,当官的也是人,面对这么多事,这么多复杂的情况,很可能不知觉中就做了混蛋了,怎么办呢?那就是以事情的是非正误作为每一评价标准!但跟着问题又来了,事情的是非正误如何评价,以何为标准?这就有了导致质量低下的第三种与第四种情况的发生。
        第三种情况是思想的偏差,这个思想偏差很容易就发生在我们身边,我们常能听到这种管理者的声音,“我不管过程,我只要结果,好的结果”,事情的是非正误真是一针见血,你下面的人做出好的结果就是对了,否则就是错了,可事情有这么简单吧,我在私下笑着对一位说这话的领导说:如果只看事情的好结果就能当领导,我也可以当嘛,谁都能当领导了,那为什么是你坐在这个位置上?为什么拿那么高的工资做这么简单的事呀?
        可以说,今天打工者中最高工资的,或者平均工资最高的就是管理职位,这说明什么?说明这个职位不是好做的,是很难的,比写操作系统难多了,所以才给你比写程序的做测试的人要高得多的工资嘛,你如果就是指手划脚而已,谁不会呢?这就是思想上的问题,也是一个管理水平的问题,这种管理水平的人能到了管理位置上,一来说明,我们更高层的管理水平也不怎么样,二来说明真正懂管理的人实在太缺啦,也说明这个管理职业的行业水平总体太低,比测试的行业水平总体低多啦!
        但你说管理这职业又真有多难呢?我看也不见得,因为这是一个相当高端的学科,所以这方面的研究理论与实践都是有相当丰富的资源的,有时候只不过是这个管理者能不能甘于寂寞、平淡而已,这可能又要触及官本位的思想了,真把管理当一个普通的职位看,可能很多问题都好解决了!
        第四种就是方法问题,管理者有心,但方法不对也不行,我自己观察了成功的企业与不太成功的企业,发现成功的企业在方法上总是更加接近于理性,更加细节,而不成功的企业往往就是想当然,一个问题在客户处爆发,想当然是测试部的问题呀,这还有什么好说的?于是把罪名丢给测试部就算完了,测试部把问题丢给小兵就完了,这样就可以了吗?稍好一些的企业可能会说,小XX呀以后要注意呀,要好好测试,这次的教训要吸取哟,你也不要太有压力,以后细心些,这话说得还挺有人文关怀的,听起来也应该是不错的企业管理者,可问题是这问题真是小XX的吗?我曾经对一个关系好的领导戏言:你认为二次世界大战时德国战败是因为前线一名士兵枪法不准造成的吗?方法的问题可以说已经是今天中国企业质量问题的根本所在,所以业界有ISO,有CMM,又有了CMMI,6西格马什么的,一大堆,其实都是好东西,但中国的问题似乎又出在思想上,反映在方法上,用了这些也不好,很多人就开始牛PP哄哄的总结什么CMMI只适合大公司,不适应小团队,总之就是找借口,解释就是掩释,掩饰自己在习惯上形成的方法惰性,掩饰自己的思维僵化!其实运用这些好东西,它同样有一个思想与方法的问题要解决!
        思想上是,你不能拿来就用,你要搞清楚你为什么要用,是为了得个好名声?还是为了解决事情中的是非对错,减少感性因素,增强理性因子,关注细节,整合资源,优化效率才去使用呢?有的企业很怪异,认为用了它能让客户对我们放心,我们能有好的品牌,要我看你的潜台词实际上是用了CMMI我们可以骗更多更大的客户啦!却不知客户对你有信心,你有了一个好的品牌,这只是你做好了事情,提高了产品质量而达到的一个结果而已,如果你使用CMMI的出发点是人家的结果处,那完蛋了,这才出发呢,就已经给结果了,可不完蛋了吗?因为思想上你的出发点不同,必然做事的方法就不同,结果当然就不会相同。这就要说到对方法的运用的方法上来了。
        请大家想想CMMI这四个字母,最重要的是哪个?我个人认为是“I”,它为什么重要?周六在深圳参加了51testing的沙龙,很多资深的专家谈到了软件产业的分工合作问题,实际上就是一个产业链的整合问题,可是你知道吗,宏观上产业链要整合,但一家公司更实在的是你公司内部的工作流要整合的问题,调动每一个环节,工序,点线结合,优化效率,有这个基础才有了质量保证的基础,有了这个基础,才有了方法中的一切细节,才有可能产生出客户对你有信心,你有了一个好品牌的结果,方法细节是在那些事情上的,结果是自然而然产生的,不是一开始就刻意去营造的,出发点放在结果身上,结果只能是做事浮燥,弄虚作假!
       如果已经有了这样的思想与方法,我们再来看一个案例,测试工作中的责任问题就不难解答了:
       有这样一个贴子:
    ------------------------------------------------------------------------------------
      “我们公司的测试人员是一个人负责一个项目的,测试组也有10个人!
       基本上都有评审需求,写测试用例,然后评审用例,然后修改用例,然后执行测试....
      前天做了一个项目,到最后测试完了,开发说漏掉了一个重要的需求没有测试到,他们发现了BUG,发现就发 现了呗,非得在什么公司高级领导面前炫耀自己然后批评我!
    然后我们组的领导就一直跟我说什么漏测这个,什么多严重多严重的,然后别人怎么说怎么说的!
    现在拿项目给我测试非得多说几句什么注意需求,什么上次你的漏测什么怎么样的,靠,真想一巴掌拍死他们!

    1.我写测试用例没错,错是我在先,难道我没提交测试用例评审么?把全部责任全部给我?开发算什么?他们评审自己的毛么?如果我有责任他们没责任么?
    2.你主管JJYY说个毛呀,一天到晚说,还次次说,你不烦我都烦了,主管要当到你这份了,靠,当初真瞎眼进这个公司!
    3.我不是万能的,需求写得跟没写一样,本身用例就难写,写个什么操作员登记报告,NND,报告里面有啥?什么都没有详细描述,项目经理怎么不先批评你那垃圾需求!

    真的累,不太想干了,又是12月了,又要考核了,一年一次,还得降薪,估计我上次漏测那个,估计得挨好几刀,没则,过年后考虑闪人,碰到一个垃圾主管窝气还火大!”
    ------------------------------------------------------------------------------------
        对照我前面说的思想与方法,很明显这家公司在思想上存在官本位,导致了混蛋(测试主管),王八蛋(开发部门的某些人)的出现,最后把罪名丢给了测试小兵,也就是德国战败的原因是该小兵枪法不准,这不笑掉大牙么?于是人心焕散了,人心散了,队伍不好带了,可人心为什么会散?
       再说方法,表面看似乎流程不错,还评审呢,可最后还是出问题,其实这家公司到这一步都没有什么关系,还有很大的空间改进与发展,问题是思想错误导致后面的方法就不对了,如果是我,我会制定一个bug回塑机制,从测试到测试评审,从测试评审到开发及开发过程中的评审,再到需求及需求评审,看看这有多少流程与工序,有多少步骤,这里的每一个工序如果细节做到位,都是可以把这个问题给事先发现的,而越到后面越不好发现,所以责任的大小应该是越靠前的越大,比如,需求评审中开发为什么不提出疑问?测试为什么不提出疑问?测试做出测试需求,测试计划,进行评审时,需求人员为什么没有提出疑问?开发人员为什么没有提疑问?测试做出测试用例后,同行评审的同行,测试经理,开发经理及参加评审的开发人员为什么没有在这里提出疑问?什么原因导致了没有提出疑问?为什么这么多的工序每个工序中都可以发现此问题,却没有发现此问题?是什么流程不对?是什么方法不当?找出最深层的原因加以改进,才是这家公司最好的出路,看了这种贴子,我就为中国的软件业难过!当然他们也有这个机制,就是把bug的责任回塑到了测试部,测试部回塑到了小兵身上,呵呵!每一件事都要有正确的,理性的方法才能成就事情最后的成功,做点儿事多不容易!一不小心就会成为混蛋!所以流程与工序多重要,一步步的流程与工序才是最大避免成为混蛋的武器!
         然而流程工序是死的,人是活的,我中国人特别的灵活,真不知道是好事还是坏事了!总之,今天管理者本身的职业水平造成了质量的低下,而多数人对不太高的管理者的水平的温心的理解体谅,对已经高于管理者水平的的测试与技术水平的苛刻挑剔,形成了鲜明的对比!
         另外我要说的是测试人员本身的问题,当这种问题发生时,居然就认了下来,但凡对公司负责任,就应该心平气和的把深层原因与之探讨清楚,测试人员特别是经理,不要太过于自我批评了,我们中国人真的不缺自我批评的精神,我们太缺敢于指出事件本质的勇气!

    最后:文章是看了贴子后临时写成,没有好好构思,语句也有不通之处,错字也一大堆,见谅!由此说明,就是随便作篇文章,思想态度与方法不对,质量也是不好的!呵呵!

    事情要做,生活也要过,周六晚看了《梅兰芳》特把《戏凤》选段贴出来,大家欣赏一下:
     李凤姐:[西皮流水]月儿弯弯照天下,
              问声军爷你哪里有家?
     正德帝:[西皮流水]凤姐不必细盘查,
              为军家住在那天底下。
     李凤姐:(白)人不住在天底下,还住在天上头不成么?
     正德帝:(白)我这个住处与众大不相同。
     李凤姐:(白)怎么不同?
     正德帝:(白)我住在北京城内,大圈圈里面有个小圈圈。小圈圈里面有个黄圈圈,我呀,就住在那个黄圈圈里面呐。
     李凤姐:(白)我啊,我认得你。
     正德帝:(白)你怎么认得我?哎呀呀,她怎么晓得我啊?
     李凤姐:(白)你就是我哥哥的……
     正德帝:(白)什么?
     李凤姐:(白)大舅子呀。
     正德帝:(白)胡说!
     李凤姐:[西皮流水]军爷做事理太差,
              三番两次取笑咱。
              梅龙镇上访一访,
              凤姐本是个好人家。
     正德帝:[西皮流水]好人家,歹人家,
              不该鬓间斜插海棠花。
              扭扭捏,实可爱,
              风流就在这朵海棠花。
     李凤姐:[西皮流水]海棠花来海棠花,
              到把军爷取笑咱。
              将花撇在海棠花,
              从今后不戴这海棠花。
     正德帝:[西皮流水]凤姐做事理太差,
              不该踏碎了海棠花。
              为军用手忙拾起,
         [西皮摇板]我与你插,插!插上这朵海棠花。
     李凤姐:[西皮摇板]凤姐一见事不好,
              去到绣房我躲避他。
  • LoadRunner 代码样例

    pcl2004_27 发布于 2008-07-05 13:31:37

       输出信息到外部文件?

       #include "as_web.h"


    Action()
    {
     long stream;
     char kmp1[6];

     lr_vuser_status_message("Iteration: %s", lr_eval_string("{it_number}"));

     if( (stream = fopen( "D:\\LTProjects\\Log\\order1.txt", "a" )) == NULL ){
           
        return(-1); 
     }

     lr_output_message("Iteration Number:""%s",lr_eval_string("{it_number}"));
     strcpy (kmp1,lr_eval_string("{it_number}"));
     fprintf(stream,"Iteration number:%s",kmp1);
     fCLose(stream);
     return 0;

    }

      ip欺骗的时候得到主机机器名字?

      #include "as_web.h"


    Action()
    {

    char *my_ip;
    char *my_host;

    my_ip = lr_get_vuser_ip();

    my_host = lr_get_host_name( );

    web_url("yahoo.com",
    "URL=http://yahoo.com/",
    "Resource=0",
    "RecContentType=text/html",
    "Referer=",
    "Snapshot=t1.inf",
    "Mode=HTML",
    LAST);

    lr_output_message("The IP address is %s", my_ip);

    lr_output_message("Host IP address is %s", my_host);
     return 0;
    }

  • 鼠标点击桌面任意坐标的问题,顺便介绍下Mercury.DeviceReplay这个对象

    zte_boy 发布于 2008-06-06 15:47:57

    一朋友问到如何实现鼠标点击桌面上任意指定的坐标的问题,呵呵

    不复杂,呵呵

    可以两种方法实现:

    1、QTP采用低级别录制,然后坐标用随机数替代

    2、创建一个DeviceReplay对象进行操作

    Function Mouse_Click(x , y)

     Dim device
     Set device = CreateObject("Mercury.DeviceReplay")
     device.MouseMove x , y
     device.MouseClick x , y , LEFT_MOUSE_BUTTON
     
    End Function

    既然写了这个方法,顺便就介绍下Mercury.DeviceReplay这个对象,呵呵

    很实用的一个对象,不知道为啥QTP的帮助几乎就没有它的介绍

    这个对象用来模拟鼠标的单击和移动、键盘输入等,但有个前提,实用该对象前,需要保证键盘状态正确

    如NUMLOCK是否打开等,因为DeviceReplay不能检测键盘状态

    Mercury.DeviceReplay包括如下方法:

    1、SendString方法

    向激活的窗口发送一个或多个键盘按键:object.SendString( str )

    2、KeyDown方法

    模拟一个按键的按下并保持:object.KeyDown( key )   key 按键的数值码

    3、KeyUp方法

    模拟通过键盘释放某个按下的按键:object.KeyUp( key )

    4、PressKey方法

    模拟通过键盘按下一个按键并立即释放:object.PressKey( key )

     

    5、PressNKeys方法

     

    模拟通过键盘多次按下一个按键并立即释放:object.PressNKey( key, N )  N:重复次数

     

    6、DragAndDrop方法

     

    用于执行从一点拖动到另外一点的操作:object.DragAndDrop( dragX, dragY, dropX, dropY, Button )

    Button 的值包括

    LEFT_MOUSE_BUTTON = 0

    MIDDLE_MOUSE_BUTTON = 1

     RIGHT_MOUSE_BUTTON = 2

     

    7、MouseClick方法

     

    在指定的屏幕位置执行鼠标左键或右键的单击操作:object.MouseClick( x, y, Button )

     

    8、MouseDbClick方法

     

    在指定的屏幕位置中执行鼠标左键或右键的双击事件:object.MouseDblClick( x, y, Button )

     

    9、MouseDown方法

     

    在屏幕指定位置按下鼠标左键或右键,并保持按下状态:object.MouseDown( x, y, Button )

     

    10、MouseUp方法

     

    用于释放之前执行的MouseDown方法所按下的鼠标按键:object.MouseDown( x, y, Button )

     

    11、MouseMove方法

     

    用于模拟鼠标移动:object.MouseMove( x, y)

     

    12、SetSynchronizationTimeout方法

     

    设置一个新的同步超时的时间值:object. SetSynchronizationTimeoutnSyncTimeout , is_sec

    nSyncTimeout 同步超时的时间值。

    is_sec 指定设置的时间值是否以秒为单位

     

     

  • 分析图表-中级测试师用

    shen1936 发布于 2008-05-16 15:31:22

    性能测试(并发负载压力)测试分析-简要篇

    在论坛混了多日,发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试,但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,希望能对大家分析测试结果有所帮助。

    分析原则:
        •
    具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
        •
    查找瓶颈时按以下顺序,由易到难。
       
    服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
       
    注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
        •
    分段排除法 很有效

    分析的信息来源:
        •1
    根据场景运行过程中的错误提示信息
        •2
    根据测试结果收集到的监控指标数据

    一.错误提示分析
    分析实例:
    1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
      •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

      
    分析:
    •A
    、应用服务死掉。
       
    (小用户时:程序上的问题。程序上处理数据库的问题)
    •B
    、应用服务没有死
       
    (应用服务参数设置问题)
       
    例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25
    •C
    、数据库的连接
       (1
    、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))

    2  Error: Page download timeout (120 seconds) has expired

    分析:可能是以下原因造成
    •A
    、应用服务参数设置太大导致服务器的瓶颈
    •B
    、页面中图片太多
    •C
    、在程序处理表的时候检查字段太大多

    二.监控指标数据分析
    1
    .最大并发用户数:
    应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。
    在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
    如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2
    .业务操作响应时间:
    分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用事务性能摘要图,可以确定在方案执行期间响应时间过长的事务。
    细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
    如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用网络监视器图确定导致性能瓶颈的网络问题
    3
    .服务器资源监控指标:
    内存:
        1 UNIX
    资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

        2 Windows
    资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
       
    很高的换页率(high pageout rate);
       
    进程进入不活动状态;
       
    交换区所有磁盘的活动次数可高;
       
    可高的全局系统CPU利用率;
       
    内存不够出错(out of memory errors)

    处理器:
        1 UNIX
    资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
       
    合理使用的范围在60%70%
        2 Windows
    资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

    CPU
    资源成为系统性能的瓶颈的征兆:   
         
    很慢的响应时间(slow response time)
         CPU
    空闲时间为零(zero percent idle CPU)
         
    过高的用户占用CPU时间(high percent user CPU)
         
    过高的系统占用CPU时间(high percent system CPU)
       
    长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O
        1 UNIX
    资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
        2 Windows
    资源监控中,如果 Disk TimeAvg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。

    I/O
    资源成为系统性能的瓶颈的征兆 :
         
    过高的磁盘利用率(high disk utilization)
       
    太长的磁盘等待队列(large disk queue length)
       
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
       
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
       
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
       
    太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

    4
    .数据库服务器:
    SQL Server
    数据库:
        1 SQLServer
    资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
        2
    如果Full Scans/sec(全表扫描/秒)计数器显示的值比12高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
        3 Number of Deadlocks/sec(
    死锁的数量/):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0
       4 Lock Requests/sec(
    锁请求/),通过优化查询来减少读取次数,可以减少该计数器的值。

    Oracle
    数据库:
      1
    如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
       
    快存(共享SQL区)和数据字典快存的命中率:
       select(sum(pins-reloads))/sum(pins) from v$librarycache;
        select(sum(gets-getmisses))/sum(gets) from v$rowcache;
       
    自由内存:    select * from v$sgastat where name=’free memory’;
    2
    如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
      
    缓冲区高速缓存命中率:
        select name,value from v$sysstat where name in ('db block gets’,
        'consistent gets','physical reads') ;
       
        Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
    3
    如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
       
    日志缓冲区的申请情况
         select name,value from v$sysstat where name = 'redo log space requests' ;
    4
    如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序
       
    内存排序命中率
         select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
       
       
    注:上述SQL ServerOracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。

    说明:
       
    以上只是个人的体会和部分资料的整理,并不代表专家之言。算抛砖引玉,有不同看法和更深入的分析的,希望大家勇要发言,以推动我们国内的性能测试工作。

     

  • LR性能分析图解释

    shen1936 发布于 2008-05-15 14:47:16

    Transactions(用户事务分析)
    用户事务分析是站在用户角度进行的基础性能分析。

    1、Transation Sunmmary(事务综述)
    对事务进行综合分析是性能分析的第一步,通过分析测试时间内用户事务的成功与失败情况,可以直接判断出系统是否运行正常。

    2、Average Transaciton Response Time(事务平均响应时间)
    “事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。
    例:随着测试时间的变化,系统处理事务的速度开始逐渐变慢,这说明应用系统随着投产时间的变化,整体性能将会有下降的趋势。

    3、Transactions per Second(每秒通过事务数/TPS)
    “每秒通过事务数/TPS”显示在场景运行的每一秒钟,每个事务通过、失败以及停止的数量,使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
    将它与平均事务响应时间进行对比,可以分析事务数目对执行时间的影响。
    例:当压力加大时,点击率/TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈。

    4、Total Transactions per Second(每秒通过事务总数)
    “每秒通过事务总数”显示在场景运行时,在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

    5、Transaction Performance Sunmmary(事务性能摘要)
    “事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间,可以直接判断响应时间是否符合用户的要求。
    重点关注事务的平均和最大执行时间,如果其范围不在用户可以接受的时间范围内,需要进行原因分析。

    6、Transaction Response Time Under Load(事务响应时间与负载)
    “事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响,对分析具有渐变负载的测试场景比较有用。

    7、Transaction Response Time(Percentile)(事务响应时间(百分比))
    “事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图,也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

    8、Transaction Response Time(Distribution)(事务响应时间(分布))
    “事务响应时间(分布)”显示在场景运行过程中,事务执行所用时间的分布,通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间,则可以使用此图确定服务器性能是否在可以接受的范围内。

     

    Web Resources(Web资源分析)
    Web资源分析是从服务器入手对Web服务器的性能分析。

    1、Hits per Second(每秒点击次数)
    “每秒点击次数”,即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
    通过它可以评估虚拟用户产生的负载量,如将其和“平均事务响应时间”图比较,可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”,可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢,需进一步分析,发现系统瓶颈所在。

    2、Throughput(吞吐率)
    “吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节,表示虚拟用在任何给定的每一秒从服务器获得的数据量。
    可以依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
    “吞吐率”图和“点击率”图的区别:
    “吞吐率”图,是每秒服务器处理的HTTP申请数。
    “点击率”图,是客户端每秒从服务器获得的总数据量。

    3、HTTP Status Code Summary(HTTP状态代码概要)
    “HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数,该图按照代码分组。HTTP状态代码表示HTTP请求的状态。

    4、HTTP Responses per Second(每秒HTTP响应数)
    “每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量,还能返回其它各类状态码的信息,通过分析状态码,可以判断服务器在压力下的运行情况,也可以通过对图中显示的结果进行分组,进而定位生成错误的代码脚本。

    5、Pages Downloader per Second(每秒下载页面数)
    “每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
    和吞吐量图一样,每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小(例,每个GIF文件的大小、每个网页的大小)。而每秒下载页面数只考虑页面数。
    注:要查看每秒下载页数图,必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

    6、Retries per Second(每秒重试次数)
    “每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
    在下列情况将重试服务器连接:
    A、初始连接未经授权
    B、要求代理服务器身份验证
    C、服务器关闭了初始连接
    D、初始连接无法连接到服务器
    E、服务器最初无法解析负载生成器的IP地址

    7、Retries Summary(重试次数概要)
    “重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数,它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

    8、Connections(连接数)
    “连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
    借助此图,可以知道何时需要添加其他连接。
    例:当连接数到达稳定状态而事务响应时间迅速增大时,添加连接可以使性能得到极大提高(事务响应时间将降低)。

    9、Connections Per Second(每秒连接数)
    “每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
    理想情况下,很多HTTP请求都应该使用同一连接,而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况,就表明服务器的性能在逐渐下降。

    10、SSLs Per Second(每秒SSL连接数)
    “每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后,浏览器将打开SSL连接。


    Web Page Breakdown(网页元素细分)
    “网页元素细分”主要用来评估页面内容是否影响事务的响应时间,通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
    元素。

    1、Web Page Breakdown(页面分解总图)
    “页面分解”显示某一具体事务在测试过程的响应情况,进而分析相关的事务运行是否正常。
    “页面分解”图可以按下面四种方式进行进一步细分:
    1)、Download Time Breaddown(下载时间细分)
    “下载时间细分”图显示网页中不同元素的下载时间,同时还可按照下载过程把时间进行分解,用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
    2)、Component Breakdown(Over Time)(组件细分(随时间变化))
    “组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面,通过分析控件的响应时间,很容易就能发现那些控件不稳定或者比较耗时。
    3)、Download Time Breakdown(Over Time)(下载时间细分(随时间变化))
    “下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分(随时间变化)情况,它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
    “下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果,“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果,两者分别从宏观和微观角度来分析页面元素的下载时间。
    4)、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))
    “第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间,场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间(以秒为单位)。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
    First Buffer Time:是指客户端与服务器端建立连接后,从服务器发送第一个数据包开始计时,数据经过网络传送到客户端,到浏览器接收到第一个缓冲所用的时间。

    2、Page Component Breakdown(页面组件细分)
    “页面组件细分”图显示每个网页及其组件的平均下载时间(以秒为单位)。可以根据下载组件所用的平均秒数对图列进行排序,通过它有助于隔离有问题的组件。

    3、Page Component Breakdown(Over Time)(页面组件分解(随时间变化))
    “页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 (以秒为单位)。

    4、Page Download Time Breakdown(页面下载时间细分)
    “页面下载时间细分”图显示每个页面组件下载时间的细分,可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
    “页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

    5、Page Download Time Breakdown(Over Time)(页面下载时间细分(随时间变化))
    “页面下载时间细分(随时间变化)”图显示方案运行期间,每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
    “页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析:首先确定有问题的组件,然后分析它们的下载过程,进而定位原因在哪里。

    6、Time to First Buffer Breakdown(第一次缓冲时间细分)
    “第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长,则可以使用此图确定产生的问题与服务器有关还是与网络有关。
    网络时间:定义为第一个HTTP请求那一刻开始,直到确认为止所经过的平均时间。
    服务器时间:定义为从收到初始HTTP请求确认开始,直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

    7、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))
    “第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内,场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

    8、Downloader Component Size(KB)(已下载组件大小)
    “已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

     

     

     

     

     

     

     

     

     

     

     


     

  • loadrunner参数化详解

    huruihai 发布于 2008-05-16 22:42:54

    通过自己编写的脚本,对参数化时不同的设置组合,进行结果的验证,从而总结各个选项的作用,希望能对大家有所帮助,总结的有不正确的地方,还请指出!谢谢

    原创文章转载请注明来自http://www.51testing.com/?uid/41972

    脚本
    Action()
    {
     char *aa ;char *bb ;
     aa="{NewParam}" ;bb="{NewParam}" ;
     lr_message("aa:%s",lr_eval_string(aa));
     lr_message("bb:%s",lr_eval_string(bb));
     return 0;
    }
    前提: 对aa,bb进行参数化,使用同一个参数列表
    参数类型为table
    脚本迭代次数为3次
    参数列表为:
    a
    b
    c
    参数 含义
    columns
    1.select all columns
    TRUE 所有列的数据均会当作参数提取
    2.columns by number TRUE 输入要提取参数的列号,从指定的列中提取参数
    3.column delimiter COMMA 参数值通过逗号分隔
    TAB 参数通过TAB分隔
    SPACE 参数通过空格分隔
    rows
    1.rows per iteration
    行数 每次迭代遇到该参数时,循环几次取参数列表中的值
    例如:如果设置成1,脚本运行一次,依次取参数列表中的值,结果为
    aa:a
    bb:a
    例如:如果设置成2,脚本运行一次,依次取参数列表中的值,结果为
    aa:ab
    bb:ab
    例如:如果设置成3,脚本运行一次,依次取参数列表中的值,结果为
    aa:abc
    bb:abc
    2.first line of data 行数 输入的行数决定了提取参数的第一行,从参数列表的哪行开始
    rows delimeter for log display   每次迭代遇到该参数时,取出的参数后加入什么值,与rows per iteration
    配合使用
    例如:rows per iteration设置为2
    此处设置为分号
    运行后显示的结果为
    aa:a;b
    bb:a;b
    例如:rows per iteration设置为3
    此处设置为分号
    运行后显示的结果为
    aa:a;b;c
    bb:a;b;c
    when not enough rows parameter will
    get less rows
    than required
    取值超出所有行时,如何处理,目前选择这两个值没有发现差别,也请
    知道差别的朋友指出
    use behavīor of
    "select next row"
    第一种设置
    参数 结果 总结
    第一次迭代 第二次迭代 第三次迭代
    select next row sequential aa:a aa:b aa:c 顺序的取参数列表中的值
    在一次迭代过程中如果再次遇到该参数时,所取得值与上一次相同
    update value on each iteration bb:a bb:b bb:c
    第二种设置
    参数 结果 总结
    第一次迭代 第二次迭代 第三次迭代
    select next row sequential aa:a aa:c aa:b 顺序的取参数列表中的值
    在一次迭代过程中如果再次遇到该参数时,所取得值是下一个值
    在第二次迭代的时候会顺序取下一个值,所有取得值不会重复
    update value on each occurrence bb:b bb:a bb:c
               
    第三种设置
    参数 结果 总结
    第一次迭代 第二次迭代 第三次迭代
    select next row sequential aa:a aa:a aa:a 不论迭代几次,无论在一次迭代中第几次遇到该参数均使用一个值
    update value on each once bb:a bb:a bb:a

  • 如何编写有效测试用例

    handen 发布于 2007-09-26 16:28:49

    测试用例描述了测试的输入参数、条件及配置、预期的输出结果的组成部分.

    一、编写测试用例的原则

    1、测试用例要达到最大覆盖软件系统的功能点。测试工程师应该在测试计划编写完成之后,在开发阶段编写测试用例,参考需求规格说明书和软件功能点对每个功能点进行操作上的细化,尽可能趋向最大需求覆盖率。

    2、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。

    3、测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候,除了满足系统基本功能需求外,还应该考虑各种异常情况、边界情况和承受压力的能力等。

     

    一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性,而一个成功的测试案例能够发现某个尚未发现的错误,通常一个好的测试案例有以下特性:

    1、具有高的发现错误的概率

    2、没有冗余测试和冗余的步骤

    3、测试是“最佳类别”

    4、既不太简单也不太复杂

    5、.案例是可重用和易于跟踪的

    6、确保系统能够满足功能需求

     

           测试用例不可能设计得天衣无缝,也不可能完全满足软件需求的覆盖率,测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现,那么事后该将其补充到用例库里,以方便他人和后续版本的测试。

    二、如何编写测试用例

    测试用例的信息有很多,可以根据实际的情况进行增删,一般来说一个优秀的测试用例应该包含以下信息:

    1、产品相关信息

    (1)    软件产品或项目的名称

    (2)    软件产品或项目的版本

    (3)    功能模块名

    (4)    功能描述

    (5)    测试平台

    这些信息建议可以在测试案例手工选择。

    2、基本记录信息

    (1)    测试用例入库者

    (2)    测试用例入库时间

    (3)    测试用例更新者

    (4)    测试用例更新时间

    这些信息建议可以由测试案例自动生成。

    3、测试用例的属性

    (1)    测试用例ID:测试用例的ID(由案例管理系统自动生成,方便跟踪管理)

    (2)    测试用例名称:测试用例的名称

    (3)    测试功能点:测试的功能检查点

    (4)    测试目的:该测试功能点的测试目的

    (5)    测试级别:主路径测试、烟雾测试、基本功能测试、详细功能测试。     

    下面对这几个测试级别进行说明:

    A、                   主路径测试:对照需求中重要模块和功能的最主要功能路径,主路径测试为设计探针模块,快速检查程序的可测试性(可测试性还包括安装测试是否成功)的主要依据的测试案例

    B、                   烟雾测试:对照需求中所有模块的主要功能路径,主路径测试案例为烟雾测试案例的子集,烟雾测试为做回归测试的主要依据的测试案例。

    C、                   基本功能测试:对照需求和总体设计中所有模块和功能的基本功能路径,基本功能测试为测试软件产品的非重要级别模块,书写完全的自动测试脚本的主要依据。

    D、                   详细功能测试:对照总体设计中所有模块和功能的功能路径,测试各个模块及功能各个层次,各种类型。详细功能测试案例为对重点模块,易发生错误的模块的主要依据。

    (6)    测试类型:功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。

    (7)    预置条件:对测试的特殊条件或配置进行说明

    (8)    测试步骤:详细描述测试过程,案例的操作步骤建议少于15个。

    (9)    预期结果:预期的测试结果

    例如:假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关,测试用例的设计如下:

    (1)    测试用例IDTC000001

    (2)    测试用例名称:中国移动全球通手机用户成功发送短信给中国联通手机用户

    (3)    测试功能点:中国移动全球通手机用户成功短信给中国联通手机用户,中国联通网关返回成功的状态报告

    (4)    测试目的:

    A、                  中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信;

    B、                  中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。

    (5)    测试级别:基本功能测试

    (6)    测试类型:功能测试

    (7)    预置条件:各网关实体按照组网图中的关系连接好,各实体之间的连接和通信正常。

    (8)    测试步骤:

    A、                  中国移动全球通手机用户(13901000001)给中国联通手机用户(13001000001)发送MO短信,内容为“测试”,目的号码填为中国联通手机号码;

    B、                  中国联通互联短信网关把短信下发给中国联通用户成功后,给中国移动互联短信网关返回一个标识成功的状态报告。

    (9)    预期结果:

    A、                  中国联通手机用户(13001000001)接收到了短信,内容为“测试”,源号码为中国移动全球通的用户号码(13901000001);

    B、                  在中国移动互联短信网关上产生SMO话单,其中“短消息发送状态”填0(表示成功),“源手机号码”为13001000001,“目的手机号码”为13001000001

    三、测试案例的模版

    下面是一个完整的测试用例的模版:

    测试用例ID

    TC000002

    测试用例名称

    非法用户登录管理网页

    产品名称

    互联互通网关

    产品版本

    V3.3.2

    功能模块名

    管理网页

    测试平台

    所有

    用例入库者

    smilings

    用例更新者

    smilings

    用例入库时间

    2006-5-30

    用例更新时间

    2006-5-30

    测试功能点

    输入错误的用户名和密码

    测试目的

    阻止非法用户登录系统

    测试级别

    详细功能测试

    测试类型

    功能测试

    预置条件

    登录用户名和密码为admin/test

    测试步骤

    1、输入用户名称为admin,密码为test%

    2、按“登录”按扭登录管理页面

    预期结果

    1、系统拒绝该用户登录

    2<SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hans

  • 从测试用例看测试的问题及变化

    dionysus 发布于 2006-12-12 15:19:10

    对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术,它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

    一、问题:

    许多测试类书籍中都有大幅的篇章介绍用例的设计方法,如等价类划分,边界值,错误推断,因果图等。但实际应用中这些理论却不能给我们很明确的行为指导,尤其是业务复杂,关联模块紧密,输入标准和输出结果间路径众多时,完全的遵循这些方法只能让我们在心理上得到一种满足,而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验(或习惯),希望能在这一个项目中更加规范,但多数情况下我们规范的只是“书写的规范”,在用例设计上以前存在的问题现在依旧。

    当好不容易用例基本完成,我们却发现面对随之而来的众多地区特性和新增需求,测试用例突然处于一种十分尴尬的境地:

    l         从此几乎很少被执行

    l         已经与程序的实现发生了冲突(界面变动,功能变动)

    l         执行用例发现的bug很少

    l         根本没有时间为新的功能需求增补用例

    l         有时间补充,但用例结构越来越乱,

    l         特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改,但特性与通行之间的数据或业务联系在用例中逐渐淡化)

    l         知道怎样执行这个用例,但它要说明什么呢?(多数用例给我们的感觉是只见树木,不见森林,只对某一功能,无法串起)

    通过上面的一系列问题可以看到,似乎测试用例给我们带来的问题远多于益处,也正是因为在实际过程中遇到的问题积累,导致我们有很充分的理由忽视或拒绝用例的应用。

    但没有用例或简略用例的编写我们又会舒服很多么?不言自明,谁也不想倒退发展吧。

    二、原因:

    事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现,究其原因我认为有如下几点:

    1、没有适合的规范

    “适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题,通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义,但它适合我们当前的项目么?

    每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语,进入公司或项目组后也会进一步学习相应的文档,例如怎样规范编写,怎样定义bug级别,软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时,又有多少人知道该怎样去写,怎样写算是好?

    在测试论坛中常能看到介绍用例编写方法的帖子,而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制,不管是结构还是方式都依赖于以往·的经验,我并不是说这样就是错误的,但不能总结成文的经验无法给予测试更多帮助。

    我们有太多经验,但却没有形成适合的规范。

    2、功能与业务的分离

    我们知道怎样列举一个输入框的用例,但却很少考虑说明这个输入框是用来做什么的,如果仔细分析不难发现,用例中这种功能与业务的分离越来越普遍也越来越明显。

    边界值、等价类划分、因果图,这些用例方法是一种高度提纯的方法,本身就很偏向于功能及代码,所以怎样编写业务的用例我们就从理论上失去了参考。

    复杂的业务会贯穿于整个软件,涉及众多功能点,里面组合的分支更不可胜数。测试用例务求简洁、明确,这一点也与业务“格格不入”。功能用例依赖程序界面,业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例,列举出众多的边界值、等价类。流程的操作只有凭借经验和理解,这时测试出的bug是最多的,但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)。正因为我们没有很好的积累业务上的用例,才使得我们感到执行用例时发现的bug不多。

    用例结构的划分一定程度上也造成了功能和业务的分离,依照界面模块建立文件夹,并在其中新建不同用例,这使得用例从结构上就很难联通起来。

    3、测试未能跟上变化

    变化!想象一下,当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候,测试又有什么举措呢?当地区特性,软件版本越来越多的时候,测试是否在积极响应呢?变化是我们面临的最大挑战,我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

    对需求和程序的变化测试人员的感受是非常深的,测试总是跟在需求和开发后面跑,使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作:尽快投入测试,尽快发现bug,而非从整体把握软件的质量情况,统筹策略。

    疲于应对的直接影响就是程序质量无法准确度量,进度无法控制,风险无法预估。用例与程序脱节,新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例,甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要,没有测试数据的保留,测试步骤和重点无法体现,新加功能与原来的程序逐渐“脱离”,可能还会出现相互违背的情况,但这我们却无法很快发现。

    永远是变化决定我们的下一步工作,这也是混乱的开始。

    三、可能的解决办法:

    在这里我希望以探讨的方式提出一些可能的解决办法,因为上面的问题也许在成熟的公司和项目组内很少遇到,而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式,最适合的就是最好的。

    1、测试驱动开发,用例指导结果,数据记录变化

    “测试驱动开发”(TDD)是一个比较新的概念,在网上可以看到很多介绍文章,它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean),“测试驱动开发的基本思想就是在开发功能代码之前,先编写测试代码”。可以看到,TDD是建立在“代码”级别的驱动,但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

    首先我们需要纠正一个态度,很多人认为黑盒测试的技术含量不高,可思考可拓展的内容不多,主要的工作就是用鼠标在那里瞎点,于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug80%以上都是黑盒测试发现的,手工操作软件仍是目前检验软件质量最有效的一种方法。

    如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起,以业务用例指导过程和结果。

    开发人员通常比较关注技术,对于业务上的理解容易忽视并出现偏差,而需求文档又不会很明确的指出应该实现怎样的结果,这使得从业务到功能出现一个“阅读上的障碍”,如果最后程序错误了还需返工,这样耗费的人力物力就非常大了。使用业务用例驱动开发,就是一个比较好的方法,同样这也需要运用测试中的各种方法,列举出业务流程里数据的等价类和边界值。

    业务用例的构造要先于程序实现,与需求和开发人员沟通一致,并以此作为一个基准,保证程序实现不会错,还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面,但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

    我们不仅要应对变化,还要记录变化,使测试用例成为对程序持续性的监控,数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的),使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享,最理想的情况就是建立一个“数据库”,每个业务用例都从“数据库”中取得输入数据和预期结果,这个数据只是针对业务入口和出口的,当程序内部设计变更时,保留的数据不会因此而作废。举一个例子,例如我的程序要从某种文件中读取数据并计算结果,一段时间后程序内部字段增加了,如果是以保存的文件附件方式提供数据,则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入,而不关心程序内部结构。

    再进一步的话“数据库”就开始涉及到程序内部的接口了,这需要开发人员的配合。

    2、为用例标明时间(版本)和优先级

    为测试用例标明时间或版本可以起到一种基准的作用,标明项目进度过程中的每一个阶段,使用例直接和需求基线、软件版本对应。同样这需要规范流程,也是对变更的一种确认和控制。或者可以为用例增加一个状态,指明这个用例目前是否与程序冲突,当程序变更时改变用例的状态,并更新用例版本。

    为测试用例标明优先级可以指出软件的测试重点、用例编写的重点,减少用例回归的时间,增加重点用例执行的次数,帮助项目组新人尽快了解需求,在自动化测试的初期也可以参考这个优先级录制脚本。

    3、功能用例与业务用例分开组织

    将功能用例与业务用例分开组织,按照不同关注点列举执行路径。业务用例应在开发前或同期编写,帮助测试人员和开发人员明确业务,了解正确流程和错误流程。功能用例更依赖于程序界面的描述,但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug,也许与业务无关,但用户往往很容易这样操作(例如登录名,你是否考虑到很长的名字,或者用户的键盘有问题,总是敲入n多空格在里面,这与业务无关,但程序将会怎样处理?)。

    4、审核用例,结对编写

    测试组长或经理对用例进行审核可以做到用例的补充和校对,但一般情况下是很难做到的,我们可以采用另一种方法,就是结对编写测试用例(前提是你有两个以上的测试人员),内部审核。

    测试用例不是一个人编写一个人执行,它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”,同时也能拓展思维,加强测试重点的确认,小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理,提高组员的参与积极性。

    四、发展

    上面的这些解决方法只是一种建议,具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的,传统的黑盒测试并不是毫无新意,测试工作怎样适合我们而发展,将给予我们更多的思考。

  • 安全测评之----操作系统安全配置

    ruanyongjie 发布于 2007-07-10 21:10:46

    l       1.利用win2000的安全配置工具来配置策略
      微软提供了一套的基于MMC(管理控制台)安全配置和分析工具,利用他们你可以很方便的配置你的服务器以满足你的要求。具体内容请参考微软主页:
    http://www.microsoft.com/windows2000/techinfo/
    howitworks/security/sctoolset.asp

    l       2.关闭不必要的服务

    l         windows 2000 Terminal Services(终端服务),IIS ,RAS都可能给你的系统带来安全漏洞。为了能够在远程方便的管理服务器,很多机器的终端服务都是开着的,如果你的也开了,要确认你已经正确的配置了终端服务。有些恶意的程序也能以服务方式悄悄的运行。要留意服务器上面开启的所有服务,中期性(每天)的检查他们。下面是C2级别安装的默认服务:

    l       Computer Browser service TCP/IP NetBIOS Helper
    Microsoft DNS server Spooler
    NTLM SSP Server
    RPC Locator WINS
    RPC service Workstation
    Netlogon Event log

    l       3.关闭不必要的端口

    l         关闭端口意味着减少功能,在安全和功能上面需要你作一点决策。如果服务器安装在防火墙的后面,冒的险就会少些,但是,永远不要认为你可以高枕无忧了。用端口扫描器扫描系统所开放的端口,确定开放了哪些服务是黑客入侵你的系统的第一步。\system32\drivers\etc\services 文件中有知名端口和服务的对照表可供参考。具体方法为:
    网上邻居>属性>本地连接>属性>internet 协议(tcp/ip)>属性>高级>选项>tcp/ip筛选>属性 打开tcp/ip筛选,添加需要的tcp,udp,协议即可。

    4.打开审核策略

      开启安全审核是win2000最基本的入侵检测方法。当有人尝试对你的系统进行某些方式(如尝试用户密码,改变帐户策略,未经许可的文件访问等等)入侵的时候,都会被安全审核记录下来。很多的管理员在系统被入侵了几个月都不知道,直到系统遭到破坏。下面的这些审核是必须开启的,其他的可以根据需要增加:
    策略       设置
    审核系统登陆事件 成功,失败
    审核帐户管理 成功,失败

    审核登陆事件 成功,失败

    审核对象访问 成功

    审核策略更改 成功,失败

    审核特权使用 成功,失败

    审核系统事件 成功,失败

    5.开启密码密码策略

    策略      设置

    密码复杂性要求 启用
    密码长度最小值 6

    强制密码历史 5

    强制密码历史 42

    6.开启帐户策略

    策略        设置

    复位帐户锁定计数器 20分钟
    帐户锁定时间 20分钟

    帐户锁定阈值 3

    7.设定安全记录的访问权限

      安全记录在默认情况下是没有保护的,把他设置成只有Administrator和系统帐户才有权访问。

    8.把敏感文件存放在另外的文件服务器中

      虽然现在服务器的硬盘容量都很大,但是你还是应该考虑是否有必要把一些重要的用户数据(文件,数据表,项目文件等)存放在另外一个安全的服务器中,并且经常备份它们。

    9.不让系统显示上次登陆的用户名

      默认情况下,终端服务接入服务器时,登陆对话框中会显示上次登陆的帐户明,本地的登陆对话框也是一样。这使得别人可以很容易的得到系统的一些用户名,进而作密码猜测。修改注册表可以不让对话框里显示上次登陆的用户名,具体是:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DontDisplayLastUserName
    REG_SZ 的键值改成 1 .

    10.禁止建立空连接

      默认情况下,任何用户通过通过空连接连上服务器,进而枚举出帐号,猜测密码。我们可以通过修改注册表来禁止建立空连接:

    Local_Machine\System\CurrentControlSet\Control
    \LSA-RestrictAnonymous
    的值改成1”即可。

    11.到微软网站下载最新的补丁程序

      很多网络管理员没有访问安全站点的习惯,以至于一些漏洞都出了很久了,还放着服务器的漏洞不补给人家当靶子用。谁也不敢保证数百万行以上代码的2000不出一点安全漏洞,经常访问微软和一些安全站点,下载最新的service pack和漏洞补丁,是保障服务器长久安全的唯一方法。

    12. 关闭 DirectDraw

      这是C2级安全标准对视频卡和内存的要求。关闭DirectDraw可能对一些需要用到DirectX的程序有影响(比如游戏),但是对于绝大多数的商业站点都应该是没有影响的。

      修改注册表 HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DCI Timeout(REG_DWORD) 0 即可。

    13.关闭默认共享
      win2000安装好以后,系统会创建一些隐藏的共享,你可以在cmd下打 net share 查看他们。网上有很多关于IPC入侵的文章,相信大家一定对它不陌生。要禁止这些共享 ,打开 管理工具>计算机管理>共享文件夹>共享 在相应的共享文件夹上按右键,点停止共享即可,不过机器重新启动后,这些共享又会重新开启的。

      C$ D$ E$ 每个分区的根目录。Win2000 Pro版中,只有AdministratorBackup Operators组成员才可连接,Win2000 Server版本Server Operatros组也可以连接到这些共享目录。

      ADMIN$ %SYSTEMROOT% 远程管理用的共享目录。它的路径永远都指向Win2000的安装路径,比如 c:\winntFAX$ Win2000 Server中,FAX$fax客户端发传真的时候会到。

      IPC$ 空连接。IPC$共享提供了登录到系统的能力。
    NetLogon
    这个共享在Windows 2000 服务器的Net Login 服务在处理登陆域请求时用到
    PRINT$ %SYSTEMROOT%\SYSTEM32\SPOOL\DRIVERS
    用户远程管理打印机

    14.禁止dump file的产生

      dump文件在系统崩溃和蓝屏的时候是一份很有用的查找问题的资料(不然我就照字面意思翻译成垃圾文件了)。然而,它也能够给黑客提供一些敏感信息比如一些应用程序的密码等。要禁止它,打开 控制面板>系统属性>高级>启动和故障恢复 写入调试信息 改成无。要用的时候,可以再重新打开它。

    15.使用文件加密系统EFS

      Windows2000 强大的加密系统能够给磁盘,文件夹,文件加上一层安全保护。这样可以防止别人把你的硬盘挂到别的机器上以读出里面的数据。记住要给文件夹也使用EFS,而不仅仅是单个的文件。 有关EFS的具体信息可以查看http://www.microsoft.com/windows2000/techinfo
    /howitworks/security/encrypt.asp

     

    16.加密temp文件夹

      一些应用程序在安装和升级的时候,会把一些东西拷贝到temp文件夹,但是当程序升级完毕或关闭的时候,它们并不会自己清除temp文件夹的内容。所以,给temp文件夹加密可以给你的文件多一层保护。

    17.锁住注册表

      在windows2000中,只有administratorsBackup Operators才有从网络上访问注册表的权限。如果你觉得还不够的话,可以进一步设定注册表访问权限

    18.关机时清除掉页面文件
        
    页面文件也就是调度文件,是win2000用来存储没有装入内存的程序和数据文件部分的隐藏文件。一些第三方的程序可以把一些没有的加密的密码存在内存中,页面文件中也可能含有另外一些敏感的资料。 要在关机的时候清楚页面文件,可以编辑注册表HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory ManagementClearPageFileAtShutdown的值设置成1

    19.禁止从软盘和CD Rom启动系统

      一些第三方的工具能通过引导系统来绕过原有的安全机制。如果你的服务器对安全要求非常高,可以考虑使用可移动软盘和光驱。把机箱锁起来扔不失为一个好方法。

    20.考虑使用智能卡来代替密码

      对于密码,总是使安全管理员进退两难,容易受到 10phtcrack 等工具的攻击,如果密码太复杂,用户把为了记住密码,会把密码到处乱写。如果条件允许,用智能卡来代替复杂的密码是一个很好的解决方法。

    21.考虑使用IPSec

      正如其名字的含义,IPSec 提供 IP 数据包的安全性。IPSec 提供身份验证、完整性和可选择的机密性。发送方计算机在传输之前加密数据,而接收方计算机在收到数据之后解密数据。利用IPSec可以使得系统的安全性能大大增强。有关IPSes的详细信息可以参考: http://www.microsoft.com/china/technet/security/ipsecloc.asp

  • 自动化测试有关问题

    lanlan1202 发布于 2007-07-01 22:09:56

    1.自动化测试需编写自动化测试脚本,而你对自动化脚本只是略知一二,由于项目成本的限制,不可能再增加专门编写测试脚本的人员,而对这个问题你如何解决?
    答:
         我的解决方案是:软件测试自动化 。在项目成本的限制不能增加专门编写测试脚本人员的这样的经济以及人力的限制条件下,我认为测试自动化是一个很好的解决方案。
         具体解决方案:利用自动化的测试支持工具。尤其是在时间、资源或成本有限的这种棘手的问题下,利用自动化的测试支持工具是一非常好的解决方法。这样的自动化的测试支持工具有很多,我们在自动化脚本只是略知一二和项目成本的限制不能再增加专门编写测试脚本的人员的情况下,我们可以选用自动化的测试支持工具来进测试自动化,这种工具只需我们进行一些简单的操作,而且对我们所做的操作可以自动生成所需的脚本。有一种这样的工具如WinRuuner,它可以确保那些复杂的企业级应用在不同环境下都能正常可靠地运行,可以对简单的操作来自动完成应用程序的功能性测试。用WinRuuner创建一个测试,只需点击鼠标和键盘,就能完成一个标准的业务操作流程,WinRunner自动记录所做的操作并生成所需的脚本代码。这样,即使计算机技术知识有限的业务用户轻松创建完整的测试。而且还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式,满足测试团队中业务用户和专业技术人员的不同需求。这就十分符合我们所需的要求。


    2.单元测试自动化,你打算使用哪些工具或框架?
    答:
         (1)JUnit是一个开源的java测试框架,它是Xuint测试体系架构的一种实现。在JUnit单元测试框
    架的设计时,设定了三个总体目标,第一个是简化测试的编写,这种简化包括测试框架的学习和实际测试单元的编写;第二个是使测试单元保持持久性;第三个是可以利用既有的测试来编写相关的测试。而且junit是完全Free的,所以是一个既经济又强大的单元测试自动化框架。
         (2)LUnit是一个单元测试框架,用于对数据库存储过程进行回归测试。用 Java/JUnit/XML开发。
         (3)Jtest是一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类,然后自动生成junit测试用例并执行用例,从而实现代码的最大覆盖,并将代码运行时未处理的异常暴露出来;另外,它还可以检查以DbC(Design by Contract)规范开发的代码的正确性。不过价格昂贵。
         (4)Ckrunner用在J2EE环境中进行应用程序的单元测试。它不仅支持Struts actions, servlets,过滤器和标签类还包括一个JDBC和一个JMS测试框架,可以用于测试基于EJB的应用程序。
         (5)Rrogate Test framework是一个值得称赞单元测试框架,特别适合于大型,复杂Java系统的单元测试。这个框架能与JUnit,MockEJB和各种支持模拟对象(mock object )的测试工具无缝给合。这个框架基于AspectJ技术。
          总之:具体选用那种工具或框架,应该根据公司自身和具体单元测试自动化的情况来定。


    3.为了能让单元测试自动化顺利实施,实施前的培训非常重要,结合你选择的工具或框架谈谈培训内容重点,及时间的安排?
    答:
        1、为了能让单元测试自动化顺利实施,那么这是对单元自动化测试的培训。因此,第一应该了解“软件详细设计评审”,它包括:(1)详细设计文档的文档格式、规范。应知道如何根据根据概要设计文档完成详细设计文档,并且,保证详细设计文档可以指导后续的编码和单元测试工作;(2)伪码写作注意事项。
        第二应该掌握“单元测试理论”,它包括:测试理论基础,什么是单元测试,单元测试的基本方法,桩和驱动,单元测试策略,单元测试过程,单元测试辅助工具。
        第三应该掌握“单元测试用例设计”。
        第四应该熟知“软件单元测试相关工具”,知道怎么使用,使用方法,及使哪些工具或框架适合对哪些测试要求能更好达到更高质量的测试。这就需要对所选择的工具及框架有相当的了解和对其使用的技术。这是培训的重点。在培训中应让学员充分掌握对选择的JUnit、LUnit、Jtest、Ckrunner、Rrogate Test framework等工具的了解和使用方法,及对它们的性能、优点和适合什么样的情况下的测试等特性应十分了解,这对于具体实践工作中很重要,这将直接影响到测试的质量。
        2、培训的时间安排:培训的时间安排可以是在软件开发前进行为期一到两个月的培训时间,然后从学员中筛选优秀的学员正式应用到软件开发中来;或者在边开发期间边实地实战培训,具体参与软件开发,这样面对实践专家技术指导,如此的培训有一定的风险,但培训的效果也是比较显著和具体。

         
    4.Robot和WinRunner都是自动化功能测试的利器,它们之中都各自蕴含着向自己独特的一套自动化测试框架和方法论,请综合评价这两个工具并最终选择哪个更合适会在项目上使用,说明理由。
    答:
          (1)Robot:
        Robot测试技术框架是基于表驱动测试思想。表驱动测试就是预先在表中定义清楚代表每一步执行操作的关键字,然后由脚本读入表中的每一行,根据关键字来执行对应的动作。Robot 可以通过环境变量设置自行启动和运行的时间,和Test manager 协作自动按照顺序运行某些脚本;再则可以通过 Insert at Cursor 方式 进行插入录制,而且Robot 不仅支持 c/s 架构的程序完全没有问题而且只需要语句call 就可以完成。
        Robot执行完整的功能测试。记录和回放遍历应用程序的脚本,以及测试在查证点处的对象状态。
        Robot执行完整的性能测试。Robot和Test Manager协作可以记录和回放脚本,这些脚本有助于断定多客户系统在不同负载情况下是否能够按照用户定义标准运行。
          在SQA Basic、VB、VU环境下创建并编辑脚本。Robot编辑器提供有色代码命令,并且在强大的集成脚本开发阶段提供键盘帮助。测试IDE下Visual Basic、Oracle Forms、Power Builder、HTML、Java开发的应用程序。甚至可测试用户界面上不可见对象。
         脚本回放阶段收集应用程序诊断信息,Robot同Rational Purify、Quantify、Pure Coverage集成,可以通过诊断工具回放脚本,在日志中察看结果。
        Robot使用面向对象记录技术:记录对象内部名称,而非屏幕坐标。若对象改变位置或者窗口文本发生变化,Robot仍然可以找到对象并回放。
        Robot提供的强大功能所搭建起来的自动化功能测试框架,能够帮助软件开发组织成功的实施自动化的功能测试。通过重用已有的静态结构和动态结构,能够有效的促进测试的重用,并且在IBM Rational Robot的支持下,可以自动的执行这些测试。 通过使用测试设计工具来生成动态配置,可以看到除测试技术框架的SQABasic脚本外,不需要再维护任何其它的脚本,降低了脚本调试、维护的工作量。并且将来的维护是基于测试设计工具来进行,也降低了自动化测试整体的维护工作量。通过使用测试设计工具来生成静态配置,能够做到根据界面的设计来进行配置,而不需要等到待测试应用完全可用,就使得及早测试成为可能。通过支持业务、技术测试人员的分工,在测试技术框架中封装自动化测试技术细节,使得业务测试人员不需要自动化测试技术的相关知识,只需要通过测试设计工具,就能够简单、直观的进行测试的设计和执行,降低了自动化测试的实施难度。
          (2)WinRunner:
        WinRunner是一种强大的企业级自动化功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。WinRunner自动记录你的操作并生成所需的脚本代码随着时间的推移,开发人员会对应用程序做进一步的修改,并需要增加另外的测试。使用WinRunner,不必对程序的每一次改动都重新创建测试。除了创建并运行测试,WinRunner还能验证数据库的数值,从而确保业务交易的准确性。
    创建好测试脚本,并插入检查点和必要的添加功能后,就可以开始运行测试。运行测试时,WinRunner会自动操作应用程序,就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中,如有网络消息窗口出现或其它意外事件出现,WinRunner也会根据预先的设定排除这些干扰。
        Winrunner是专门用于C/S和B/S架构功能测试的自动化测试工具,其强项在C/S架构功能测试上WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试,从而大大地节省时间和资源,因此可以充分利用公司的测试投资。
           (3)我选用Winrunner的理由:
        虽然Robot和WinRunner都是自动化功能测试的利器,它们之中都各自蕴含着向自己独特的一套自动化测试框架和方法论,但我认为WinRunner更合适会在项目上使用。
     如果时间或资源有限,这样的问题会很棘手。人工测试的工作量太大,还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行,需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。而用WinRuuner创建一个测试,只需点击鼠标和键盘,就能完成一个标准的业务操作流程,WinRunner自动记录所做的操作并生成所需的脚本代码。这样,即使计算机技术知识有限的业务用户轻松创建完整的测试。而且还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式,满足测试团队中业务用户和专业技术人员的不同需求。因此我认为WinRunner更合适会在项目上使用。


    4.Bug跟踪管理是一个不可忽视的环节,请你作为这个项目定义一个合理的bug跟踪流程,绘制流程图并附文字说明。
    答:
         1、Bug跟踪管理系统对于一个软件开发团队的Bug管理是非常有效的,它能记录和跟踪每个出现的问题,为软件开发团队提供有效的交互平台,Bug跟踪管理系统从另一定程度上还可以提高团队效率和增强团队工作氛围。同时,作为问题记录的数据库,能积累处理问题的经验,有利于以后维护。bug跟踪系统用于帮助公司和软件开发团队跟踪工作中的Bug,管理和记录这些Bug的出现及处理过程,并为用户提供事务分配和自动通知的平台。常见的Bug跟踪工具有很多,网上很容易找到最新的,华军软件下载区就有。
         2、只是有Bug跟踪管理工具还远远不能正常完成具体的Bug跟踪管理,还需要为自己公司定义一个合理的Bug跟踪流程,绘制出Bug跟踪流程图。对于比较大型的公司或开发团队,比较倾向于自己开发符合自己需求的Bug跟踪管理系统。我的Bug跟踪流程图:

        Bug跟踪流程图如下:

     

     

     

     

     

     

     

     

     

     

    4.除了上述问题,你认为还可能有哪些问题是需要考虑解决的?
    答:(参考来源于网络)
         (1)自动化测试时间不充足:根据项目计划的安排,测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间,无法得到真正的关注。
         (2)缺乏清晰的目标:有很多好的理由去开展自动化测试工作,诸如自动化测试可以节省时间,使测试更加简单,提高测试的覆盖率,可以让测试人员保持更好的测试主动性。但是,自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望,这些希望应该提出来,否则很可能面对的是失望。
         (3)缺乏经验:尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验,很难保证自动化测试的顺利开展。
         (4)更新换代频繁:测试自动化往往需要花费很多时间学习,当自动化测试更新换代频繁的时候,你就丧失了刚刚学习到的自动化测试经验。
         (5)对于绝望的反应:在测试还远没有开始的时候,问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言,测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时,测试人员变得疲劳起来。测试什么时候后结束?当按照计划的安排,软件应该交付的时候,测试人员的绝望变得尤其强烈。如果不需要测试,那该有多好呀!在这种环境中,自动化测试可能是个可以选择的解决方法。但是,自动化测试却未必是最好的选择,他不是一个现实的解决方法,更像是一个希望。
         (6)不愿思考软件测试:很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况,自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂,导致很多自动化对软件测试并没有太大的帮助。
         (7)关注于技术:如何实现软件的自动化测试是一个很吸引人的技术问题。不过,过多的关注如何实现自动化测试,导致忽略了自动化测试方案是否符合测试需要。

Open Toolbar