发布新日志

  • 一份较完善的反应测试人员绩效的数据分析

    2012-06-04 14:31:41

    一份较完善的反应测试人员绩效的数据分析
  • 预防缺陷三步曲

    2012-04-25 11:27:25

    1.数据收集,数据度量,.数据分析

    2.原因分析,措施定义,措施执行

    3. 效果评估,周而复始,不断完善

  • 定位缺陷三原则

    2012-04-25 11:26:27

    1.不是所有缺陷都要定位

    2.报表数据错误,缺陷重现步骤较多必须定位。

    3.缺陷定位花费时间不易过长,控制在半个小时内

  • 发现缺陷三境界

    2012-04-25 11:03:42

    1、找缺陷,俗称跑功能,跑流程

    2、嗅缺陷,有想法、有目的找缺陷

    3、触缺陷,用心体验用户感觉去找缺陷

  • 软件测试的三个层次

    2012-04-24 17:33:05

    最近有问我,什么是有经验测试人员。感觉做了三个月测试人跟做了三年的测试人员做的事差不多。我根据测试人员的主要工作成果“缺陷”,我觉得测试人员可以分为三种层次:

    l  第一层:发现缺陷

             发现缺陷这个阶层段,觉得也分几个阶段,第一阶段通过一些正常操作和测试用例发现缺陷。第二阶段随着功能和业务熟悉有思考、有感觉、有目的发现缺陷。第三阶段是站在用户的角度,深入用户应用场景的发现缺陷。也可以理解为第一阶段和第二阶段发的是开发缺陷,第三阶段发现的是用户缺陷,真正体验用户以后所提的缺陷。

    l  第二层:定位缺陷

    从我角度来说发现缺陷是测试人员的基本功,而定位缺陷是测试技术水平提高一种体现,是一种测试人员价值一种新的初体验。因为缺陷的定位要求测试人员具备一些综合的能力,如业务,功能,开发,数据库,操作系统,网络等各方面的能力。而且能够在团队中受到认可最佳手段之一。当然是不是所有缺陷我们都要去定,如一些界面问题等。缺陷定位应该应用到一些报表数据错误,和一些操作步骤较多才能再现的缺陷。

    l  第三层:预防缺陷

    预防缺陷我觉得应该有定层次的测试人员如果资深的测试人员、测试架构师、测试管理者,他要通过各种数据分析结果找出原因,并进行原因分析,并提出解决措施。以下是几种分析得出的解决措施:

    序号

    数据分析

    解决措施

    1

    缺陷分析中需求阶段注入缺陷较多。

    1.         加强需求评审

    2.         加强与前期需求确认,多做一些DEMO给用户确认。

    2

    缺陷分析中编码阶段注入的功能缺陷,优先级高的缺陷较多。

    3.         加强接收测试验证的工作。

    4.         加强开发人员责任心的强化学习

    5.         开发绩效考核中引入接收测试通过的内容。

    3

    缺陷分析中发现Reopen缺陷较多

    6.         测试人员提高缺陷描述的要求。

    7.         请参见第45条解决措施。

    4

    缺陷分析发现界面问题较多。

    8.         定义好UI标准,并引入界面设计环节中

    9.         测试人员,开发人员加强UI标准的培训

    5

    缺陷分析中发现交叉测试时,缺陷没有明显减少

    10.     加强测试人员测试过程方法培训和交流

    11.     完善已编写好的测试用例。

    6

    ……

    12.      

  • 单元测试工程CheckStyle代码检查工具使用说明(BSTT分享)

    2012-03-31 15:03:40

    CheckStyleSourceForge下的一个项目,是一款代码格式检查工具,可以根据设置好的编码规则来检查代码,帮助JAVA开发人员遵守某些编码的规范,从而使得开发人员从这项重要,但是枯燥的任务中解脱出来。

    它可以检查的内容包括Javadoc注释、命名约定、标题、Import语句、体积大小、空白、修饰符、块、代码问题、类设计、混合检查(包活一些有用的比如非必须的System.outprintstackTrace)。

    它支持几乎所有主流的IDE,包括 EclipseIntelliJNetBeansJBuilder 等。

     感谢BSTT成员杭州-熊熊的分享。

  • 使用Adobe Reader 报Invalid plugin detected.adobe reader will quit错误

    2012-03-31 15:01:23

    安装了有道词典,  去C:\Program Files\Adobe Reader 10\Reader\Plug_ins\.把YodaoDict,api删了就行了
  • 代码静态走查检查列表表(BSTT分享)

    2012-03-26 16:40:19

    代码检查列表(JAVA JAVASCRIPT. SQL)
  • 软件测试退回标准模板(BSTT分享)

    2012-03-09 17:48:06

    软件测试退回标准
  • 新员工问题答疑(二)

    2011-12-28 17:04:13

       问题1:目前大多数项目经理及项目组成员对QA没有一个正确的认识,很多工作开展起来都相对比较困难,他们的普遍认知是QA仅仅是督促他们写东西和监督他们做事情的人,且写出来的文档也仅仅是为了应付QA的检查,认为很多工作是为了QA而做,目标不明确
       回复:我们要学会“查言观色”,我这里可不是让你去拍马屁,根据项目的特点和项目经理的关注点,重点沟通一些大家关注的东东,当然前提你做过很多功课,学习很多的业务。只有大家有共同语言了,有些事情就好处理了。QA督促他们写东西和监督他们做事情的人不假,但是方式可以多种多样,就像老师跟学生一样,不同学生要有不同教育方式。比如项目经理比较关注业务需求,那就多跟他沟通需求编写,需求跟踪,以及每个里程碑需求的完成情况,甚至可以跟测试一样站在用户角度跟他交流用户体验。至于公司的规范要求,要寻求方式如何有效简化过程,可以通过哪些方式约束他,这个事情不做,另一件事不能做,如里作为里程碑节点,项目是验收要求之一,甚至可以建议研发中心跟所有人绩效挂钩。
        问题2:现在的项目代码走查力度不够,很多项目立项时是这些人员安排,到后期编码测试阶段人员流动较大,最后会发展成为编码人员只剩1到2人,他们既要编码又要修改BUG,导致代码走查这块很少开展,项目进展也缓慢,一再延期。实际进度与计划安排相差很大,没能够根据项目具体情况预估。
        回复:这个确实是我们目前存在的比较突出的问题,其实代码走查这块我们一直考虑,上次要求你们学习代码的一些基本知识,其实就是接下来工作做准备的,希望以后我们以代码进行一些走查,从简单的代码规范做起。我们也可以考虑优化一代码走查过程,比如定义基本走查范围,如一些优先级很高模块不走查的话测试不能接受测试等。
        
       问题3:风险管理这块目前项目上基本做不起来,都是QA一味的督促和说服才勉强写了份《风险计划及跟踪表》,基本只是为了写文档而写文档,项目经理自身对风险管理这块不够重视,没能够及时采取相应补救措施。
        回复:风险实际上在每个产品经理和项目经理的工作本子和领导汇报中都有,只是他不愿意风险记录到那个《风险计划及跟踪表》中,你有没有想过其实产品经理每周都要写周报给相关领导了,你有没有想将那个周报利用起来,或者我们主动去那采集一些数据。
  • 测试管理之痛(感言篇)

    2011-11-02 10:24:28

    1.对上要很强的执行力,对下要有很高威信力

    2.要有很深的专业能力,又要有很强协调能力

    3.要懂开发又要懂测试,还得懂人情事故和原则

    4.别人都说他不是BUG,但是你往要为他买单

    5.平常你都不重要,只要客户投诉都是你的错

    6.管理一两年,发现变老油条哈哈

    走自己的路,做自己认为对的事,坚持就是胜利

  • 系统中所有单一序号主键值字段长度增长,测试思路

    2011-10-15 19:33:46

        今天看到部门同事“围脖”说“此需求几乎要检查所有的表结构,手酸啊,有木有”,天啊我知道这个产品有将近4000张表,这要测试要花多少时间。我看了一下需求。

        需求描述:  各业务系统中所有的单一序号主键值全部扩展为numberic(18,0),以防止超过范围不能保存

    我分析了一下所有表将近4000张,类似这样的表也将近500张,而且很多表都有主从表关系,而且很多表虽然是主从表关系,但是很多都是没有外键关系,要她这么干,一个星期都做不完,而且很容易遗漏。后面我想想,只能从数据库本身去处理了。

     因为是sqlserver数据库,我去看了一下系统表发现两张sysobjects(存放数据库中所有表信息),syscolumns(存放数据库所有字段信息)。所有增长字段的类型都是numberic,那么是否可以过滤呢,然后可以考虑其它共性条件,表名等。条件可以根据需要增加,目的达到一个最小范围,然后一个一个识别验证。这点工作量肯定有点大,但是缺陷清除率会很高。

    例:select sysobjects.name,syscolumns.* from syscolumns,sysobjects

    where syscolumns.xtype=108 and syscolumns.xprec <> 18 and sysobjects.id=syscolumns.id

    说明:xtype=108指类型为numbericxprec <> 18指长度不等于18的。

    如果大家更好的测试思路欢迎提供。

  • 常用WEB应用服务器安装与部署手册(BSTT整理)

    2011-10-14 10:48:46

    其内容包含:tomcat、WebLogic、WebSphere、金蝶中间件Apusic的部署与安装。感谢BSTT成员杭州-熊熊的分享
  • 简单有效的项目质量考评表

    2011-09-30 09:07:13

    简单有效的项目质量考评表
  • 简单有效的季度考核评分统计表

    2011-09-22 14:34:22

    只有填写空白处,其它自动生成和计算。
  • Loadrunner在WINXP测试WEB Error -26628: HTTP Status-Code=403 (Access Forbidden)

    2011-06-30 17:26:33

    这次接到一个移动项目是在Ipod上开发需要做性能测试,使用了safari浏览器,刚开始使用LR9.5录制不出脚本,使用LR11录制Ok了。但是项目组用了一个XP的服务器,发现超过5个用户就报 Error -26628: HTTP Status-Code=403 (Access Forbidden)。解决方法:

    下载:MtaEdt22.exe工具,安装好后修改Lm-> W3SVC-> 1->Maxconnections值(默认为10,最大只能设40)。Lm-> W3SVC-> 1->ROOT->AspMaxDiskTemplateCacheFile值(默认为10,改为1024.

    建议一般情况一下不要把XP操作系统的电脑当作服务器,问题太多,选择win2003。

  • TestDirector 访问HTTP 错误 401.1 - 未经授权:访问由于凭据无效被拒绝

    2011-06-30 09:23:44

    由于用户匿名访问使用的账号(默认是IUSR_机器名)被禁用,或者没有权限访问计算机,将造成用户无法访问,解决方案:

    1)查看IIS管理器中站点安全设置的匿名帐户是否被禁用,如果是,请尝试用以下办法启用: 控制面板->管理工具->计算机管理->本地用户和组,将IUSR_机器名账号启用。如果还没有解决,请继续下一步。

    2)查看本地安全策略中,IIS管理器中站点的默认匿名访问帐号或者其所属的组是否有通过网络访问服务器的权限,如果没有尝试用以下步骤赋予权限: 开始->程序->管理工具->本地安全策略->安全策略->本地策略->用户权限分配,双击“从网络访问此计算机”,添加IIS默认用户或者其所属的组。

  • 15 LoadRunner无法监测Windows服务器资源处理步骤

    2011-06-27 13:50:10

    以前接触监测服务器资源一般都是win2000win2003,只要能访问到服务器共享文件一般问题就解决,这次要监测Win xP用了好多方法,共享,防火墙都处理还是不行,后面网上找了几方法,综合自己的经验总算通了,我整理了一下,针对windows平台可以按照以下思路处理。

    一、监视连接前的准备工作

    1.         检查服务器与测试客户端,是否能ping通。

    2.         服务器能否共享文件,可以共享一个空白的文件夹出来。

    3.         服务器administrator必须设置密码。】

    4.         测试客户端用administrator该问共享文件夹。

    二、修改服务器的属性。

    5.         被监测服务器:管理工具 -> 本地安全策略 -> 安全选项 -> 网络访问:本地帐户的共享和安全模式,将"仅来宾"的方式,改为“经典”模式。

    6.         被监测服务器:三个服务Remote Procedure Call(RPC) Remote Registry Service Remote Registry,保证正常启动。

  • 新员工问题答疑(一)

    2011-05-31 13:21:05

    我一直希望我们的团队能是一个学习型的团队,一直鼓励他们提问,最近收到几个问题,我也稍微想想回复了一些。

    1.         在了解了基本的理论后,重点应先从哪些方面着手去进行学习?

    回复:应从这几个方面进行学习。

    a)         部门总体的测试流程,测试规范,包括各个阶段各个工作产物和每个细节。

    b)         学公司习公司主要的业务知识,通过业务联系到现有产品的每个功能以及细节。

    c)         尽快融入公司,部门,团队的文化,并保留自己现有好的特点。

    2.         在描述某些方法时,最好能提供一些实际的例子(比如测试用例的设计方法)

         回复:你可以使用guest用户去查找别的项目的测试用例,看看其他同事是如何设计的。

    3.         测试时经常会出于自己的惯性思维,怎样能更全面地、多角度地去展开测试,希望能给予一些启发?

    回复:这个肯定会出现,其实好的办法就两点

                 多看多想:就是通过 各种渠道包括专业网站,公司现有知识库,同事沟通,同行沟通并通过自己的“脑袋”转换成自己明白的。

                多应用多总结:把整明白的东西尽快现实工作中应用,应用过程进行 问题总结,并分享给同事。

    4.         在实际的工作中,往往给予测试的时间、资源有限,不能按照特别规范的测试流程进行,测试用例来不及写得很全或者没有时间完全去执行测试用例,但是又必须保证质量,那么如何去平衡这样一种关系?或者说有什么比较好的方法分享?

    回复: 这个问题提得很好,实际上所有人都想把一件事情都想做很完美,其实都是不可能的。测试用例也是如此,首先我们要把握两件事情,首先这个项目的目标是什么,当然是这个项目目标是合法的情况下。我们要根据这个目标结合测试资源制定我们的测试策略,可能存在的风险提交产品委员审批。策略中对测试用例设计你就可以根据进度,资源进行调整。目前我们常用只种方案。

    a)         只对需求优先级高的设计用例

    b)         只例出测试要点,不编写测试步骤

    c)         只编写测试思路,不编写测试步骤

    d)         ……

    5.         想了解下怎样去搭建测试环境

    回复:当工作到一定阶段的时候你的小组长会安排的,但是你自己先要熟悉项目中应用的数据库,应用服务涉及到的相关工具的基本使用。

     

     

  • 我们主要的测试活动过程

    2011-05-24 11:30:38

    测试活动

     

1222/7<1234567>
Open Toolbar