发布新日志

  • 【转贴】需求不明确的情况下如何做测试

    2007-12-11 10:12:01

     

  • 让需求理解也presention起来

    2007-12-06 15:11:17

    之前在B公司,有很多的presention机会,新人自我介绍,试用期满答辩,职位晋升,工作产出评审,知识分享,专业培训等等。所以经过B公司正规历练的人,都有着一定的presention技能,哪怕一个很普通的技术人员。B公司为什么有这样的一个传统,我不深究了,只是我发现这个方法很好,被我应用到了测试管理工作中,尤其是需求理解度确认 以及 测试用例评审。

    这里我想重点说的是需求理解度确认。

    被要求上台做需求理解度presention的QA,pass的标志就是“讲的请,问不倒”。并不是赤手空拳上去接受霹雳啪啦的发问,而是会遵循一个基本流程。

    • 先跟大家说明需求的业务背景概要--从业务应用上去理解需求;
    • 然后用面向对象的方式描述业务主体流程,场景;
    • 接着选择重点业务详细讲述,可以辅助UML图形,活动图,状态图,序列图,自由组合;
    • 再后来讲述测试需求(含非功能测试需求)验收标准,测试策略,测试重点、难点。
    • 最后就是接受集体轰炸。当然前面也可以适时轰炸。

    Presention过程中可能会用到需求文档中的一些原始资料,但是我们还是极力鼓励原创,即消化吸收需求后,要用自己的语言文字表达出来。记得曾经有我们的小QA被底下的人轰炸到语塞甚至委屈到掉眼泪。比如说你问的这个需求上也没写清楚嘛,可是你不搞清楚,怎么测试呢?比如说“大概,也许是这样的吧”,可是这样的标准如何具备可测试性呢?......

    如果真的能经受住这5轮考验的测试人员,那么他写的测试用例,他在测试过程中对问题轻重缓急的拿捏,我们都可以给予一定的信赖。且具备良好表达说服能力的人,在与开发人员沟通的时候我们也不必担忧了。真是一举N得!

     

  • oracle 10g new user how to log in EM

    2007-12-05 14:37:34

    今天在Orcle 10g的EM用sys帐户新建了一个用户,然后就直接想用该新用户帐号登陆EM,但是死活不成功。后来周折了一番才搞定了。

    原来除了给这个user赋上connect的权限之外,还得赋上select_catalog_role的权限(因为登录EM需要获取一些系统信息)。

    如果在SQLPLUS完成该赋权过程的话,就是下面两条语句。

    grant connect to user;

    grant select_catalog_role to user;

     

    BTW:如果要取消的话,就是rovoke connect from user;

  • oracle几个常用的监控视图

    2007-11-28 15:52:52

    <http://www.testage.net/html/96/n-140496.html>

    v$process视图:
    v$process视图包含当前系统
    oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。

    常用列:
    ADDR:进程对象地址
    PID:oracle进程ID
    SPID:操作系统进程ID


    V$PROCESS中的连接列
    Column View Joined Column(s)
    ADDR V$SESSION PADDR

    v$session视图

    V$SESSION是基础信息视图,用于找寻用户SID或SADDR。不过,它也有一些列会动态的变化,可用于检查用户。

    常用列:
    SID:SESSION标识,常用于连接其它列
    SERIAL#:如果某个SID又被其它的session使用的话则此数值自增加(当一个SESSION结束,另一个SESSION开始并
    使用了同一个SID)。
    AUDSID:审查session ID唯一性,确认它通常也用于当寻找并行查询模式
    USERNAME:当前session在oracle中的用户名。
    STATUS:这列用来判断session状态是:
        Achtive:正执行SQL语句(waiting for/using a resource)
        Inactive:等待操作(即等待需要执行的SQL语句)
        Killed:被标注为删除

    paddr, process addr, 通过这个字段我们可以查看当前进程的相关信息, 系统进程id,操作系统用户信息等等.

    (sql_address,sql_hash_value) (prev_sql_addr,prev_hash_value) 根据这两组字段, 我们可以查询到当前session正在执行的sql语句的详细

    信息.

    v$sqltext视图

    v$sqltext视图包括Shared pool中SQL语句的完整文本,一条SQL语句可能分成多个块被保存于多个记录内。

    常用列:

    HASH_VALUE:SQL语句的Hash值
    ADDRESS:sql语句在SGA中的地址
    SQL_TEXT:SQL文本。
    PIECE:SQL语句块的序号

    V$SQLTEXT中的连接列
    Column     View     Joined Column(s)
    HASH_VALUE, ADDRESS  V$SQL, V$SESSION  HASH_VALUE, ADDRESS
    HASH_VALUE. ADDRESS  V$SESSION   SQL_HASH_VALUE, SQL_ADDRESS

    按pid查看正在执行的
    程序
    select sid,program from v$session b where paddr in (select addr from v$process where spid=$pid);

    按pid查看正在执行的sql语句
    select sql_text from v$sqltext where hash_value in (select sql_hash_value from v$session where  
    PADDR in (select addr from v"$process where spid=$pid)) order by piece;

    V$SESSION_WAIT视图

    这是一个寻找
    性能瓶颈的关键视图。它提供了任何情况下session在数据库中当前正在等待什么(如果session当前什么也没在做,则显示它最后的等待事件)。当系统存在性能问题时,本视图可以做为一个起点指明探寻问题的方向。

    V$SESSION_WAIT中,每一个连接到实例的session都对应一条记录。

    常用列:

    SID: session标识
    EVENT: session当前等待的事件,或者最后一次等待事件。
    WAIT_TIME: session等待事件的时间(单位,百分之一秒)如果本列为0,说明session当前session还未有任何等待。
    SEQ#: session等待事件将触发其值自增长
    P1, P2, P3: 等待事件中等待的详细
    资料
    P1TEXT, P2TEXT, P3TEXT: 解释说明p1,p2,p3事件

    附注:
    1.State字段有四种含义﹕
    Waiting:SESSION正等待这个事件。
    Waited unknown time:由于设置了timed_statistics值为false,导致不能得到时间信息。表示发生了等待,但时间

    很短。
    Wait short time:表示发生了等待,但由于时间非常短不超过一个时间单位,所以没有记录。
    Waited knnow time:如果session等待然后得到了所需资源,那么将从waiting进入本状态。

    Wait_time值也有四种含义:
    值>0:最后一次等待时间(单位:10ms),当前未在等待状态。
    值=0:session正在等待当前的事件。
    值=-1:最后一次等待时间小于1个统计单位,当前未在等待状态。
    值=-2:时间统计状态未置为可用,当前未在等待状态。

    3.Wait_time和Second_in_wait字段值与state相关:
    如果state值为Waiting,那么wait_time值无用。Second_in_wait值是实际的等待时间(单位:秒)。
    如果state值为Wait unknow time,那么wait_time值和Second_in_wait值都无用。
    如果state值为Wait short time,那么wait_time值和Second_in_wait值都无用。
    如果state值为Waiting known time,那么wait_time值就是实际等待时间(单位:秒),Second_in_wait值无用。

    V$SESSION_WAIT中的连接列

    Column View Joined Colum
    SID V$SESSION SID

    查看session等待事件:
    select sid,event from v$session_wait where event not like 'rdbms%' and event not like 'SQL*Net message%';

    多数的session都是空闲事件如:SQL*Net message from client, pipe get, PMON timer等。

  • 测试用例质量的判断

    2007-11-21 15:37:05

    Test Case Quality=Defect Number/Case Number.以这样的方式衡量测试用例质量的指标,大家可能也见过。大致的意思是看平均一个测试用例能发现几个缺陷。

    我对此持反对态度,我认为这样的指标没有实际意义。原因如下:

    1. 未过滤出由测试用例范围之外随机、意外发现的缺陷。

       测试过程中难免会出现一系列测试用例验证范围之外的随机的意外的缺陷。一旦发生,做的比较好的测试组织会去修正测试用例,做的不好的可能就视而不见了。这两种情况不管哪种,最终的统计结果都不是我们需要的。前者,修正过的测试用例已经不代表我们真实的测试用例设计水平,只是防范后期同类漏测的一个补救措施;后者,其粗糙、虚假程度不值得在这里分析了。

     

    2. 关于追求尽量多的缺陷 与 尽量少的测试用例 的误区。

       按照这个公式,表面理解是用尽量少的测试用例发现尽量多的缺陷。要使结果趋于良好,要么缺陷足够多,要么用例尽量少。缺陷足够多,很容易使我们陷入一个追求缺陷数量的误区;用例尽量少,其实就很难确保测试的完备性,顶多是把一些同类的做抽象合并处理,而事实上我们还是希望测试用例写的尽量细致的,这与尽量少是矛盾的,可操作性较低。

    所以,关于衡量测试用例质量好坏,我的观点是去统计 由测试用例发现的缺陷/缺陷总数,即测试用例缺陷命中率。这才代表测试用例的一个水准。只要在合理的人力、时间条件下,这个指数越高,说明测试用例的质量越高,测试有序性也越高。同时对于测试用例范围之外的缺陷,我们要持续的做分析,针对性地改善。

    这里再提供一下我们的经验值,发展了3年多的一个软件测试组织,测试对象是中小型企业应用软件,命中率大概能达到60%左右,这是一个比较诚实的数据。

  • 自动化测试最优体会—来自微软

    2007-09-30 10:34:41

    1。在做任何事情之前先编写详细的测试计划-自动战略会非常清楚,并获得管理人员和同仁的支持;
    2。将测试事例管理架构放到一起,这样每个测试人员都按相同的标准编写,所有测试也都易于维护和理解;
    3。减少维护-编写公共的功能和模块,这样可在任何地方重复使用它们;
    4。编写有意义的测试日志,并对所有通过和失败的结果产生总结报告,记录任何事情;
    5。实现测试运行的无人看管,并具有从失败中恢复的能力;
    6。使测试能够跨多种语言,平台和配置;
    7。在测试中引入随机性;
    8。启动小的每天运行的测试,例如构造验证测试,指望成功;
    9。通过发现错误的数量和比率度量自动化的有效性;
    10。在冲击测试中实现自动化-在产品中连续运行测试直至系统失败;

     

    --------

    以上是我在一本叫做“软件测试自动化测试技术与实例详解”书上摘录下来的精华,电子工业出版社的。这些点,我在实际操作中都有体会。不过,我都不记得这本书是谁借给我的了,赫赫。

  • Good Enough & Cost Management

    2007-08-29 17:35:35

    上次跟Team member做做绩效面谈的时候,小丫头提及到一个几乎被我们遗忘的话题---Schedule的紧迫感。她大抵的意思是觉得好像大家并没有因为发生了Delay而神经紧张,也更无出现什么恶果。

    嗯,的确是一个现状了。不过这个现象背后其实有很多的隐性因素与历史故事。

    记得团队组建初期,经常的加班赶Schedule也经常的被Challenge质量问题,很郁闷。一路走到今天的状况,其实是革命斗争带来的大好结果了。细说一下:

    1。Good Enough与Good

       最早之前,其实测试并无明确的验收标准,即便有验收标准也只是我们自己的,并不是大家认可的。这里面会有两个误区:要么,自己把标准定得太高,在现实情况的冲击之下,搞得很累,花了很多精力但结果相去甚远;要么,自己把标准因地制宜的放低了,但是外部人并不知晓这么多实际情况,期望也许就比我们的标准高,所以总是能对着你抱怨一下。

       后来,慢慢的意识到这里面的问题,且经验也越来越丰富。于是,开始启用“Good Enough”的标准(即我之前谈的质量因子),且这个标准是事前就公开的,绝对区别于模糊的“Good”效应。

    2。Good Enough 与 Cost

       因为我能列举出Good Enough的标准并被大家接受,于是我反推达到这个Good Enough所需要的人力Cost,于是Schedule也就不是别人说了算,而是别人尊重并相信我的预估。所以,我们每次立项总能获得在我们预估范围之内的人力预算,这样一来,达成Scheule关键在于你风险管理做得好坏。当然我发现每次都会有一些预料之外的风险,于是我学会事前争取一些Buffer,当然这个Buffer事先我不能告知我的Team member,否则这个Buffer很可能就无效了。所以,小丫头感觉到的这个问题就是因为我知道他们的Delay是为了追求Good Enough且在我预设的Cost Buffer之内,我没有进行任何强硬的压迫。

     

      当然,随着时间的推移,经验的丰富,Buffer应该越留越少。并且,也许只有真正在做产品且关注产品质量的企业才能容我们如此操作,换了一个环境恐怕就行不通了呢。

  • 自动测试技术小记----QTP描述性对象识别

    2007-08-15 16:28:49

    今天发现在某种情况下,不得不用描述性方式来定义对象。

    情况是这样的:比如我要新增一个记录,记录信息包含A/B两个信息项,其中A是具有唯一性的。所以测试脚本除了Check正常情况还要check重复性(违反唯一性的)情况。我把两个Check合并在一个Action里面了,我是对象驱动的方式,先抓对象存储到对象库再编脚本的。check是check记录提交出去后系统反馈的提示信息,所以我要先抓取提示信息框对象,因为正反两种情况提示信息是不一样的,我抓取的时候发现两个提示信息框不能生成两个不同的对象,在抓第二个时候的QTP不会生成一个新的对象,而是依附在第一个对象上,且同时第一个对象的某些关键属性会由原先的一个常量值变成[complex value]。

    所以以后如果再遇到此种情况就不得不用描述性来定义对象了哦。

  • 关于自动测试

    2007-08-14 13:28:41

    最近产品走到一个比较特殊的时期,正好有个空档安心下来做些平常没精力安心研究的事情。比如自动测试,这几天下来大抵有如下收获。

       其实我们做自动化真正的目的就是希望把平时手工重复的工作自动化,将人力腾出来做其他更有意义的事情,所以我们不能仅仅为了自动化而去自动化,我们不能仅仅想着
    实现自动化后的美妙,不能仅仅追求一种技术,我们要控制成本要追求实效。
      

       a,投入产出分析
         对于需要投入较多前期成本才能实现的自动化,请务必做一个投入产出分析。即便最后不能完全按照预计的模型实现,至少过程中你会有成本观,能取得比毫无顾忌一头扎进

    去有更好的实际效果。
        举例1----
        自动化对象------A模块
        自动化工具------QTP
        手工测试耗时----2h即120min
        自动测试耗时----40min
        自动测试脚本维护耗时-----16h
       
        如此,
        如果实现自动化,做一次测试节约80min,而前期投入了16*60=960min,所以这个自动测试至少要跑960/80=12次才能收回前期的投入。
       
        所以你脚本维护的耗时越短,这部分的成本控制得越好,见效也就越快,反之越慢;同时你还得考虑脚本的健壮性与兼容性,如果产品稍微变化你的脚本就得重新维护,那么也是不合理的。
       
        BTW:
        如果在自动化的实现上没有足够的自主权,需要向更高决策者申请人力。那么建议你通过这样的一个模型告诉他多久之后你目前投入的成本就可以收回来,且之后每次测试能节约出多少人力多做多少其他更有意义的事情,我想总比盲目申请要有理有据得多。

       b, 实效性。
          自动化的实现不一定要绑定在某种测试工具上实现自动化,可以自己开发一些小工具,哪怕只是一个批处理命令,只要它是能实现我们的目的的都是好的。
          建议可以仔细考量一下测试流程中的每个环节,看哪个环节最容易实现自动化带来成效最快,比如将手工获取测试版本这个过程实现自动化,比如将每天的缺陷分析报告发送实现自动化。。。。。


    另外,如果已经做好投入产出分析正在实现的过程中,建议能不定期进行Review判断一下目标是否能按计划达成,如果是多个人配合正好也可以相互切磋一下。

  • 坚持到底就是胜利

    2007-08-13 18:07:44

    近日Kity参加公司规定的试用期满答辩,可以说是大获全胜了。

    其一,老板对其个人给予了认可;

    其二,老板对我这个组织的人才培养方式给予了认可;

    就目前来看,人才发展体系/人才能力要求/知识体系架构与积累,这几个面都已经可以较好的结合起来有序发展。

    本身这不是一件什么厉害的事情,我们只不过按照预设的方式预设的体系在做事情,可是结合公司的一些实际情况,在一些干扰因素下,很多人迷失的很严重--找各样的理由允许自己不认真不严谨不注重长期发展,在这样的比对之下,我们的坚持显得那么的难能可贵。

    革命尚未成功,继续坚持!

     

     

  • 教练式领导

    2007-07-30 17:15:48

    今天读了朱少民老师的新文章,教练式管理。http://blog.csdn.net/KerryZhu/archive/2007/07/29/1714843.aspx

    有一句话,比较有回味。

    “命令式领导的方式是照我说的做,榜样式领导是像我这样做,愿景式领导是跟我一起做,关系式领导说你们商量着做,民主式领导则问你想怎样做。教练式领导最特别,有你有我,是我教你做。 ”

    我马上就开始对号入座,对了半天也不知道该往哪里坐。赫赫,看来我是混合式的。

    不过命令式领导应该是最不值得倡导的,这基本上是用自己的权力在领导;

    榜样式领导也许最容易受尊敬,但会累死;

    愿景式领导,似乎比较折中,但是这个愿景要是太虚幻,别人也没道理跟你做;

    关系式领导,比较能偷懒,关键是一定要对商量的结果把关,否则就失控了;

    民主式领导,这个风险较大,除非对属下的能力与专业度已经有足够的信任;

    教练式领导,既有亲历亲为的意思,又有传教的意思,但是如果真的要传教的好必须自己也做得好吗?如果是这样那就也要累死了。我觉得重点可能要教一个方法论吧,每个点上的深入度恐怕无法完全保障,只能随着传教次数的增多不断深化。

    ------

    不过我现在最大的困惑是他们的主动思考太少,我感觉不到他们在为团队的持续发展做主动提升主动规划,似乎有点温室里的花朵。兴许是我平时护犊子多了点?不晓得。要继续反思。

     

     

  • 撑起一把伞

    2007-05-24 11:44:52


        经历的越多,人的情感就会越麻木,这是自然规律吧。很久没有什么感动,尤其是在办公室,我想很多人会跟我一样,靠着残留的一丁点热情每天鼓励自己继续努力,这点热情也是很容易就能被浇灭的,如若你不刻意的去保护的话。
        但是,很庆幸的是,前几日我被狠狠的感动了一把,办公室里。
     
        那天中午午饭后,我照例在外面逛了一圈回办公室准备眯一会儿。经过Kity那里看她弓着身坐在那里低着头,我问她吃饭了没。她蚊子一样的声音说没呢。我感觉有点不对劲,那时候已经熄灯了,所以我俯下身去看清她的脸,居然挂着眼泪。我第一反应是她家里出什么事了,我摸着她的头问出什么事了?她边哭边说,我肚子疼。我说那赶紧回宿舍休息呀。她眼泪嘀嗒着说可是今天要冻结代码,我还有几个缺陷没close掉呢,其中一个还没找到重现规律...... 我当时愣了一下,心里明显嘎嘣了一下,然后直接扶起她说我现在送你回宿舍,那几个问题你暂时不用管了。她说那怎么办呢?那不就不能冻结代码了吗?我说我有办法处理,你放心。她将信将疑猫着身跟我往外走。回新厂的出租车上,她都还在跟我解释那几个问题的具体情况,想着如果有人来代处理的话她要进行足够充分的说明让我明白情况。我说现在你就靠着椅背,不要说话,休息,那几个问题我们会处理好的,一定放心。到宿舍我给她泡了热水看她吃了药安顿好之后往回赶,一路上我想了很多,想起我来公司的第二个夏天为工作上受了别人的冤枉躲在宿舍哭,想起现在已经离职的维佳在Sina eHR出货的那个晚上因为系统里面还有很多明显的缺陷在却非要逼着出货而着急的哭,这些眼泪,多么可贵,多么叫人感动。傍晚的时候我短信告诉她问题都处理完了,问她好点没。她回复,非常谢谢我的帮忙,好多了。第二天早上她早早的来办公室,笑着跟我说非常谢谢......
        希望看到这些文字的你们,也能被感动并轻微燃烧一下。
        于我,除了感动还能察觉到我的内心发生了一些微妙的变化。或许只有新鲜血液才能带给我们这种感动,所以借着这种感动,即便我不能确保给他们一片广阔的天地,至少也要撑起一把伞来。

  • 关于测试遗漏的分析

    2007-05-22 16:36:17

    大概已经有两年多的时间了,出货后的客户反馈缺陷一直作为我们的KPI。

    说实话,当时只是确认降低这个数字对我们来说非常有意义,但并不知道降低到多少是合理的,当然最理想是零,不过显然不可能。最差的时候,我们一个产品发布给3-4家客户,一天能报回来7-8个D类以上的缺陷,有几次报到总经理那里,非常的惶恐。但不管怎样,既然是KPI,肯定是要可以被衡量,所以就先主观(虽说是主观,但也是结合了以往的历史数据的)定一个目标上限。第一步我们针对之前的测试遗漏一个个作仔细的分析,分析漏测的原因,然后将原因归类,看百分比,最后依照原因百分比从大到小一个个安排对策去克服。两年来,就是这么过来的,当然随着测试质量的提升,那个主观的数字也在不断的变化,效果还蛮明显,现在一个版本出去之后半年,10多家客户,总计也就不到10个。似乎蛮好的。

    但是今天做了一个分析,把我吓了一跳。

    最近刚发布了一个新版本,我让我的team member手工统计了一下这次测试发现的缺陷中有几个是上个版本的测试遗漏,最后得到的平均值是35%,着实把我吓了一跳。也就是说这次35%的精力是补以前的漏洞了,再换算一下,把这次测到的遗漏+客户反馈的作为上个版本的测试遗漏,除以上个版本发布当时的缺陷总数,结果是30%左右,又吓了一跳,如果这个30%是我们当前的能力经验值,那么我已经能预测到这个版本发布存在的测试遗漏,只是看我们跟客户哪个发现的更快些!虽说,只要客户不发现,就造不成什么经济损失,但心理还是很怕怕的。

    当然我还要再分析一下这次发现的上版本漏测缺陷的具体原因。这次测试我加入了交叉测试,但这也不能作为百分百的理由。

    总之我要再深入的反省一次了。汗一个!

     

  • 传播测试文化

    2007-03-20 13:25:51

    与职业大学的合作已经正式步入正轨了,课程已经进行到1/3,自我感觉比较良好,因为开班两周后,还是有学生陆续的来报名交费。

    周日在讲台黑板上刷刷的写粉笔字,回头再看学生们饶有兴致的神情,忽然体会到一种幸福感。

    当然,这背后更多的是责任感。

    目前,省内的高校几乎都还没有软件测试这个专业。职业大学应该算是走得比较快的,毕竟他们比较追求就业实用性。我们的培训,从结构体系设计来说,应该是比较全面的覆盖了软件测试专业知识,我们备课也很注重实用性;但就深度来说,毕竟受到了时间的限制,只能做到入门级别。

    于公,这次的培训是在为企业带来利润,带来影响力;

    于私,其实我是在传播测试文化。我已经是一个职业的测试人,在日常招募工作中/新人培训中很深刻的体会到院校教育在这块是非常之薄弱的。所以能让学生们在进入企业之前就受到来自企业的正规培训,其意义是深远的。我为之感到自豪。

    周日课程结束的时候,叶老师开车送我回家,聊到学校想把这块放大,做成全校理工科的公开课。我觉得这个思路挺好,但是涉及到企业与学校的矛盾利益关系,我还要仔细研究一下策略。最好是能真正双赢。

  • 软件质量特性因子与软件质量验收标准

    2007-02-27 15:12:21

    近日看到一篇文章,关于软件质量特性因子。http://blog.csdn.net/giltworld/archive/2007/02/25/1513897.aspx

    忽然发现这里面的特性因子,其实与我们正在做的产品验收标准其实是异曲同工的。

    记得一年前每次老板问到产品的质量怎么样?我头头是道的讲测试用例的覆盖率,测试用例的命中率,缺陷的走势等等,但结果还是鸡同鸭讲,他最后还是会问我:为什么我认识的一个做软件测试的人告诉我经过他们测试的软件都能达到90分以上?你告诉我们的软件得多少分?我就无语了。

    后来终于明白过来,有一日晚上忽然想起来,就发短信给老板说:之所以我给不出分数是因为我们开始的时候就没有定下质量验收的标准。老人家马上回复明白。次日,即召来产品经理/研发经理/实施经理等,一起商定产品质量验收标准事宜。自打那以后我就很轻松了,每次报告就按照标准给分值,再也不会无语。

    这里总结如下几点:

    1。所谓的验收标准,其实与质量因子是一样的。你要根据实际情况分几个纬度。比如业务功能满足度/业务流程满足度/性能满足度/稳定性满足度/易用性满足度/实施标准工作量满足度等等。

    2。每个因子,得有一定的比例,即占整体质量的权重,这样最后才好给分数。

    3。每个因子要定好验收方,当然不是每个因子全部由测试来验收,比如说实施标准工作量,这得由负责交付的部门来验收。比如业务功能/性能/易用性这些其实都是可以通过测试用例来衡量的,pass了就算满足了。

    所以,一旦你学会按照这样的思路去给你的老板做报告,基本上你就很轻松了。当然,同时你的报告也不要单单是这些内容,还要注意测试本身的一些数据积累,比如缺陷走势/测试用例的命中率等等这些对于测试专业度的提升还是很有参考价值的。

  • 测试人员能力结构表

    2007-02-09 11:30:13

    最近,在做职等晋升。第一步是要做能力盘点。

    但是忽发现之前留档的能力结构表有些混乱,一时间乱了盘点的思路。故索性花时间重新调整了一下。

    能力面 能力项
    领域知识 产品熟悉度
    领域知识
    研发技能 需求分析与系统设计
    程序编写
    T-SQL
    测试技能 测试类型
    测试设计
    缺陷报告
    工具化测试
    数据库
    管理技能 配置管理
    测试项目管理
    团队管理

    因为涉及到公司机密,测试类各职等的详细能力标准(阶梯形)就不贴出来了。

    现在还不敢确认这样的结构就是完美的,但至少感觉是适用的。

  • 当专业度走向市场化

    2007-02-08 14:07:23

    .背景

    写这样的一篇文字,源于近期与苏州职业大学进行的软件测试培训合作项目。因为这样的一个机会,我经历了一些转变,使我学着从商业化的角度对外传递软件测试专业度的价值,使我发自内心体会到Kevin Make More Money”的用心良苦以及YS“开创知识服务新纪元”的深邃。这里把过程中我的一些体会跟大家分享。

     

    .机会是为准备好的人而存在

           我始终是个充满危机感的人,忧患意识比较强烈。这有可能是因为自己是个完美主义者,也可能是因为自己不够自信。

           Guru的软件测试经历了收缩->扩张->收缩的过程,这是伴随着软件产品的生命周期而存在的一个合理现象。eHR这个产品慢慢已经步入成熟期,HCM目前还是个概念。早在06年初的时候我就在考虑,eHR稳定之后我们个团队的价值如何发挥?我很不希望看到这么有感情与战斗力的一个团队瓦解掉。当时很突然的想到与高校合作,将我们已积累的测试专业度通过课程的方式向学生授课,赚取培训费,为公司赢利,直接创造价值,同时还有扩大公司知名度以及锻炼队伍的附加价值,自己是越想越兴奋的。还把这个想法与Kevin沟通了,Kevin很快给了我回复,很赞同我的忧患意识,同时告诉我近期还是希望将精力放在eHR的产品测试上,如若以后时机合适他完全支持。我吃了一颗定心丸。但我还是自己偷偷的做些市场调查,拜托目前在读研究生的大学同学了解他们学校软件学院学生的情况,拜托同事的老公(在校读博士),了解学生有没有需求以及学校在这方面的经费预算情况等,同时我也把的这个想法告诉我的Team member以及几个同事,包括告诉我的父亲(他一直很关心我跟姐姐的工作状况,所以我习惯跟他讲讲,他还建议我去找找我们家一个亲戚,是一个大学的老教授)。 就在这样的调查准备中,朱Jian给我带来了苏州职业大学的机会。苏州职业大学是小Jian的母校,有一次他跟以前的班主任聊天,很偶然间了解到他们学校果真有这样一个需求。机会就这么降临了,有点受宠若惊。虽然我还没有完全准备好真正开始做培训课程,但机会来了我怎能不使劲好好珍惜呢?我花了两个晚上的时间准备了自己手上的资料,在公司对面的迪欧咖啡跟小Jian一起把我们公司以及测试部门向职大计算机系的副主任和一个软件班的老师做了第一次推销。比较成功,因为喝咖啡的钱对方很主动的付了。J

           到这里,我基本上已经抓到了机会,看到了曙光。那天晚上回来的路上,我跟小Jian提前体验了我们自己马上就能为GEA Make More Money(绝对区别于“Help to make more money”)的那种幸福感,虽然还没有十足的把握。

     

    . 利用优势,主动出击

             回来之后,小Jian提醒我要安排人家过来参观参观。我当时还没怎么领悟其重要性,只是表示认可。觉得可能要安排客户参观,于是去跟Kevin请求资源。Kevin把李炜推荐给我一同处理此事。索求到资源以后立马邀请学校来参观,他们欣然接受。还记得当天学校老师来公司的情形,本来说是来6个人,结果来了近20个人,学校的系主任亲自带队,几乎整个计算机系的老师都来了。当我们带领他们走完公司的参观通道,当李炜专业的公司企业文化讲演/老姚的研发专业讲演/我的测试专业讲演全部完成后,我才意识到这次的参观多有威慑力。因为后来副主任跟我说目前也有几家企业在跟他们谈合作,他们也去这几家企业参观了。当我们这样一个面貌呈现给那些老师后,基本上他们就对我们情有独钟了。因为明基的企业文化(哪怕仅仅是耳濡目染层次的那种)其他企业是无法比拟的,而且我专门安排了三个讲演,对他们这样的尊重程度以及专业化服务是别的企业不能做到的。

           花絮:后来去学校参观的时候,发现学校教学楼走道里面有他们系主任写的一些书法字画(用玻璃镜框包装的)挂着,不知道是不是受了我们的感染回去做的。J 而且系主任每每跟学生老师谈到明基逐鹿都会跟他们反复强调他来这边参观时对明基的企业文化对他的触动有多深。

    四.克服对未知领域的恐惧感

          李炜问我:玲玲你看一下我们的课程怎么报价才合适?这样的一个问题,我完全傻了。因为之前的我只是简单的想着让学生交培训费就Ok了,没想到交多少是合适的。

    可以说那一刻我有一丝的恐惧感,因为我感觉到我已经踏入了未知领域,这跟我熟悉的软件测试有太大的不一样,很害怕我给出的预算是荒谬的。同时我又自我安慰:不怕,做完这次我就又成长了。赫赫,很土的观念,但很管用。于是开始回忆之前在AIP培训课程学到的一些财务知识,揣测收支关系,揣测外部报价逻辑以及内部实际核算逻辑。自己用xls比划,征求个别同事的意见,搞了一个晚上,第二天把东西给李炜看,基本上是等着返工的,竟然被pass了,很是诧异,可能本来就蛮简单的,只是一开始因为恐惧而扩大了难度。不管怎样,做完这次开始理解项目经理做项目预算的难度与重要性。

           后来还有去学校做招生宣传,需要准备海报(海报主题以及制作流程)准备演讲报告(演讲时间/技巧的把握),这些都是之前未经历的,都是带着一丝恐惧感走了过来。但克服之后,感觉很好。

        花絮:去学校做招生宣传的前一天晚上,连洗澡的时候都在演练讲演。当时实在是有点紧张。J

    . 不要把别人当傻子

             这是Kevin跟我说过的一句话,因为后续去学校谈报价的时候,学校老师提出需要参考我们内部的系统设计文档,当时因为担心已经超出了保密级别,所以没有承诺,说是回来争取。后来征求Kevin的意见,我说要不我们就派一个研发工程师给他们讲一节系统设计相关的课敷衍过去好了,Kevin回答我不要把别人当傻子,最傻的人就是把别人当傻子的人。他让我自己拿捏保密程度,但不能简单敷衍此事。现在越发明白这句话的妙处。要真正明了客户的用意,不能拿歪曲的答案应付他们的需求,当你拿应付的态度面对问题的时候往往就不能让你的客户满意了,一旦不满意,后患就埋下了。时时把对方当聪明人,巧妙运用一些办法满足他的需求,那一切都能水到渠成。

           包括后续我们对培训班的报名学员进行过滤,也是这样。本来我是不想安排过滤的,因为多一个报名对我们来说就是多一份学费收入。但考虑校方的心态,我最后还是决定做过滤,而且是笔试+面试。尤其是面试,为节约人力成本我很冒险的采用了一个面试管对多个(4-5名)学生的方式,当然我事先精心设计好面试的结构与方式,使得一对多的面试过程有据可循,有险无惊,最后校方对这样的面试效果评价很高。

           花絮:当我一开始跟学校说明面试方式时,他们持怀疑态度。我肯定的告诉他们:“你们放心,我们有经验的。”他们就答应了。其实当时心里还是有点虚的。J

      总结

         此培训项目已经开过第一次课,赶在学生放寒假之前。就这一次课我已经意识到成本控制的难度与重要性,也就体会到我们的eHR项目经理做项目成本控制的苦衷,体会到Make More Money真的很艰辛,体会到我们每一次跟老师/学生接触,其实都是我们传递知识服务的一个双向体验过程。

            很感谢我的Team member/Jian/陈阳,还有Steven等的帮助与支持。当然还有Kevin,精悍的点拨让我受益匪浅。

            当然,这还仅仅是一个开始,更有挑战的,更值得深思的应该还在后面。

            

     

  • Nisson日产汽车渠道销售总经理黄亚威的成功学分享记录

    2007-02-08 11:34:56

    因为这个人小有吸引力的Title,我去听了这次演讲。

    总体感觉下来-比较失望,Just so so。

    1。Slide的美观度极低,都是黑白镶嵌的静态文字;

    2。辅助论点的例证不具备震撼力,至少我觉得蛮牵强;

    我感觉都不如听Kevin的演讲。

    他的主题是围绕80/20原则展开,其实我本来是很想听他的成长心得的,而不是所谓成功规则。

    简单记录他的论点如下:

    20%的人            80%的人

    正面思考            反面思考

    做事业              做事情

    爱投资              爱购物

    有目标              爱瞎想

    问题中找答案         答案中找问题(找茬)

    改变自己             改变别人

    会坚持              爱放弃

    重复简单的事情       不愿做简单事情

    -----------

    What i  really got are:

    1.Personnel doc management.

      这个其实不是他讲的,是讲的过程中我忽然想到的。我愕然的发现我的工作知识管理做得还有条有理,但个人生活相关的(饮食/旅游/购物/运动)这些我管理的很贫乏。非常愕然,我居然这么重工作轻生活。这个一定要痛改!

    2.培养多一些专长

      当然这个前提是有一个专长先。当你具备多项技能后,你就会比较不患得患失。就算这里失败了,真的尽力后失败了,我还可以做别的,我还有拿手绝活。这多好。

    3.少理会挫勇者。

      这个比较好理解。谁老是给你泄气,你就基本可以不用理他了。

  • 开张宣言

    2007-02-01 14:09:15

     

     这是本人的第三个Blog。

     第一个在ChinaBlog,第二个在公司的Portal上,第三个又诞生了。

     首先申明这种行为不代表我的本质---遍地开花,见异思迁。

     实质上,ChinaBlog的那个是我的生活空间,公司的那个基本上我是荒废掉了,这里嘛,显然我要栽培成我的工作空间,职涯空间。本人其实还是算是小有事业心的,所以我相信:这里可以搞得红红火火!而且一定会搞得红红火火!

     

392/2<12
Open Toolbar