勇于突破,突破不止!

发布新日志

  • loadrunner 测试Webservice

    kaluodier123 发布于 2010-06-22 09:57:31

    使用loadrunner测试Web Services的程序大致可以使用两种方法,分别为web_service_call()和soap_request()。两者的使用很相识,我们录制时都使用Web Services的协议。下面分别介绍一下使用方法:

    一、web_service_call()使用步骤如下:

    1、保存WSDL文件。在IE中打开Web Services的地址,并加上“?wsdl”。比如:“http://192.168.4.112:8082/EDASer ... neService.asmx?wsdl”。然后将打开的XML文件另存为扩展名为".wsdl"的文件。如下图



    2、在loadrunner中导入刚才保存的WSDL文件,如下图



    3、增加调用函数,如下图



    4、完成后将自动生成以下代码。

            web_service_call( "StepName=RunService_101",
                    "SOAPMethod=ServiceEngineService|ServiceEngineServiceSoap|RunService",
                    "ResponseParam=response",
                    "Service=ServiceEngineService",
                    "ExpectedResponse=SoapResult",
                    "Snapshot=t1273650512.inf",
                    BEGIN_ARGUMENTS,
                    "xml:inDataBuf="
                            "<inDataBuf>"
                                    "<serviceName>2307</serviceName>"
                                    "<serviceType>3</serviceType>"
                                    "<pageNo></pageNo>"
                                    "<sessionID></sessionID>"
                                    "<xmlData><DataSet></xmlData>"
                            "</inDataBuf>",
                    END_ARGUMENTS,
                    BEGIN_RESULT,
                    "RunServiceResult=Param_RunServiceResult",
                    END_RESULT,
                    LAST);

            lr_log_message("result = %s", lr_eval_string("{Param_RunServiceResult}"));
    --可以输出返回值

      

    二、soap_request(),使用步骤如下:

    1、定义SOAP REQUEST FILE。在IE中打开Web Services的页面,比如:http://192.168.4.112:8082/EDASer ... .asmx?op=RunService。IE中将显示这个文件的信息,复制保存为XML文件。如图下图:



    2、导入刚才定义的XML文件。



    3、导入后自动以下代码。

            soap_request("StepName=SOAP Request",                                                                               
                    "URL=http://192.168.4.112:8082/EDAService/ServiceEngineService.asmx",                                                                               
                    "SOAPEnvelope="
                    "<?xml version=\"1.0\" encoding=\"utf-8\"?>"
                    "<soap12:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap12=\"http://www.w3.org/2003/05/soap-envelope\">"
                            "<soap12:Body>"
                                    "<RunService xmlns=\"http://192.168.4.112/\">"
                                            "<inDataBuf>"
                                                    "<serviceName>2307</serviceName>"  --入参需要改成自己需要的值
                                                    "<serviceType>3</serviceType>"          --入参需要改成自己需要的值
                                                    "<pageNo></pageNo>"                     
                                                    "<sessionID></sessionID>"
                                                    "<xmlData></xmlData>"
                                            "</inDataBuf>"
                                    "</RunService>"
                            "</soap12:Body>"
                    "</soap12:Envelope>",                                                                               
                    "SOAPAction=RunService",                                                                               
                    "ResponseParam=response",                                                                               
                    "Snapshot=t1273722181.inf",                                                                           
                    LAST);


    4、在刚才自动生成的代码前,增加header信息。需要增加的内容见步骤1里的截图。“Content-Length”不需要加。本例中我们增加的代码为:

            web_add_header("POST",
                    "/EDAService/ServiceEngineService.asmx HTTP/1.1");
            web_add_header("Host",
                    "192.168.4.112");
            web_add_header("Content-Type",
                    "application/soap+xml; charset=utf-8");


    这样2种方式就介绍完了。

    补充说明:

    1、如果入参的字符串需要使用“<”或“>”,则必须传递“& l t ;”或“& g t ;(这几个字符需要去空格)

    2、如果WEB SERVICES返回的是XML文件,则可以使用lr_xml_get_values来获取。比如:

        int  NumOfValues;
        NumOfValues= lr_xml_get_values("XML={response}",  --response为soap_request函数的返回值
              "ValueParam=OutputParam",                              --定义lr_xml_get_values的返回值                   
              "Query=/soap:Envelope/soap:Body/HelloWorldResponse/HelloWorldResult",    --XML的节点名称,需要包含父节点的名称,并用"/"隔开。
              "SelectAll=yes", LAST);

        for ( i = 0; i < NumOfValues; i++) { /* Print multiple values of OutputParam */          --输出刚才获取的XML的值 

              sprintf (buf, "{OutputParam_%d}",i+1);
              lr_output_message("result = %s",lr_eval_string(buf));

                      re = strncmp(lr_eval_string(buf),string1,85);
                      lr_output_message("return : %d",re);
        }


    3、可以切换到TREE界面查看我们定义的函数的请求,以及服务器的返回值。

    // function ratevalveimg(rate,ratevalveset){ valveimg = '';if(rate) {image = rate > 0 ? 'templates/special/images/agree.gif' : 'templates/special/images/disagree.gif';var ratevalve = ratevalveset.split(",");for(i = 0; i < ratevalve.length; i++) { if(Math.abs(rate)>ratevalve[i]){ valveimg += '';}else{ break;}}}return valveimg;} // ]]>

  • ALM(Quality Center) Excel Addin深度剖析

    songfun 发布于 2011-12-17 17:22:49

     声明:由于51testing博客有严重bug,上传图片一直有问题(被切割成一半了),所以做个pdf附件在下面,欢迎大家免费下载正版原创资料,也可以去百度文库下载!以下文章同样适用于Quality Center Excel Addin!

    如何使用Excel插件将需求或者用例导入到HP ALM 11中——ALM(Quality Center) Excel Addin深入剖析

    51Testing版主songfun

     

        自从HPQuality Center 10升级为ALM 11后,Excel插件的导入也和以前有些不同了。区别在于:在原来的TD(TestDirector)/QC(Quality Center)环境下,只要安装相关的Excel Addin就可以导入了,但是在ALM11中必须事先注册一下客户端,否则会遇到一个“隐含模块中的编译错误:CTDServer”的问题,如下图:

        相信这是很多人在导入Excel时遇到的一个郁闷问题。原因是什么呢?请随我来,songfun老师带你探究HP ALM11EXCEL的奥秘。

        下面先从最基本的客户端登录讲起。

        首先给出我的客户端环境:Windows XP + .Net Framework 3.5 sp1 + Visual Studio 2010 + Office 2007 + IE 8.0 。注意,客户端的环境配置很重要,因为ALM 11的兼容性非常差。主要有几点:

    1. 机器必须安装 .Net Framework 3.5 sp1Visual C++ 2005 SP1,这是前提条件,而且VC++ 2005 sp1必须为英文版(vcredist_x86 english.exe,2681 KB),不能装中文版(vcredist_x86 chinese.exe,2654 KB),否则会有问题。

    2. Office 2007的内部代号是Office12,而ALM对不同版本的Office是有挑剔的。建议装Office 2003/Office 2007。同时请把Excel的宏启用起来,

     

    3. 请确保浏览器是IE7或者IE8的版本,才能打开ALM页面——目前不支持IE 6.0/Google Chrome/Mozilla Firefox等浏览器。

     

        接下来,用IE8打开ALM11的主页面: http://songfun:8080/qcbin

    点第一个链接进去,见到如下页面:

    浏览器弹出一个提示,让你安装浏览器的插件,这是ALM的客户端插件。如下图:

    安装完毕,出现登录页面:

    登录后,进入需求模块:

    假如要导入需求,那就自己制作一个Excel文件,以下是一个我做好的excelImport.xlsx 文件。

    要导入的话的,就得安装Excel Addin,这个在上述的主页面的第三个链接Add-ins Page里下载。我这里直接给出下载链接 http://update.external.hp.com/qualitycenter/qc110/msoffice/msexcel/HP-ALM-MSExcelAddin.exe

        但是仅仅只是这些是不够的,否则就会看到前面提到的CTDServer错误。我下面先给出分析,再给出解决方案——知其然还要知其所以然嘛。

        其实这个Excel插件的核心是一个xla文件(xla叫“加载宏”文件,这个后缀是Office2003以前的文件格式,在Office2007中叫xlam文件),简单的说,这种文件就是在你的Excel文档中加载一段代码(Excel中的代码,我们称之为“宏”,英文叫Macro),所谓的插件安装就是往你的Office安装目录下拷贝这么一个“加载宏”文件而已。详细的路径是“C:\Program Files\Microsoft Office\Office12\XLSTART”,核心文件就是TDExcelAddin.xla 这个文件。其实你只要把这个文件拷贝到这个目录下,根本就不必安装这个插件!不信你可以试试看!那么这个文件到底是什么文件呢?说白了,就是一个VBA应用程序,看到我下面的分解就知道端倪了。

        好,我们现在用Excel打开这个文件。见下图:

        打开之后,可能你会觉得有点奇怪,好像啥都没有啊?!对了,因为这个是代码,在界面上面是看不到的。好了,在Excel界面上,用快捷键 Alt + F11 吧(所有Office的编程界面都用这个激活)!

    看到什么了呢?哦,原来Office也可以编程的!这个界面就是 Visual Basic for Application(简称VBA)的开发界面!换句话说,我们的Office不但可以用来写文档、做表格、做幻灯片,还可以用来开发一个软件!是不是有点神奇呢?!其实我们早期提及的宏病毒就藏身于此。

        好了,回到主题。在上图中,是不是看到“VBAProject (TDExcelAddin.xla)”这个对象了?用鼠标点击过去,展开(点那个“加号”)。。。是不是看到了一个密码框?对了,Mercury研发团队为了避免让你看到他们的内部代码,加了锁。不过,songfun老师偷偷告诉你密码吧,是:tdtdtd。试试看!

        这下是不是一览无遗了?!呵呵!为什么叫这个密码呢?其实ALM 11HP内部的代号就是QC 11,即Quality Center 11,而QC的前身就是TD,即TestDirector。如果大家用过QC的项目定制(Project Customize)功能,就会知道里面有个管理员角色叫 TDAdmin。其实TD/QC/ALM产品只是换了外壳(产品版本演进是TD 8.0->QC 8.2->ALM 11),内部的东西还是叫TD

        好了,现在点左边的窗体,展开一个个查看。看到什么了?是不是看到一个个窗体(Form)了?

    再继续查看它们的代码,比如看看导入窗体的登录模块的Next按钮的代码,你就会看到原来这个Excel插件的功能就是把你的用户名和密码传递给ALM ,代码就是这句:m_server.LoginToProject

        把代码窗口的滚动条拉到最上面,看到了这么几句代码:

    Option Explicit

    Private m_server As CTDServer

    Private m_settings As CSettings

    Private m_exportType As Integer

        简单解释下,Option Explicit是强制打开变量声明开关(因为Visual Basic语法可以不定义变量直接使用,不像C语言那样要强制声明),目的是让解释器在做语法检查时像C语言一样去检查变量是否有定义过才使用。而“m_”开头的表示这是模块级变量(module),也就是跨Sub的类似于全局变量的变量(模块内的所有Sub都可以共享这个变量)。Private m_server As CTDServer的意思就是定义一个模块级变量m_server,并指定为CTDServer对象类型。好了,看到这里,应该明白开篇里提到的为什么用Excel会报错了吧?对了,就是缺失这个对象!

    换句话说,这段代码要能运行起来,需要找到一个“神奇的东西”,是这个“东西”使得你可以访问ALM。怎么理解呢?这就好比C语言中,你要用“#include <string.h>”才能运行strcat/strcmp等字符串函数的道理一样。我们这个“神奇的东西”其实是一个“库”,我们把它称之为“COM Library(Common Object Model Library)”,公共对象模型库。其实我们要调用的就是一个COM组件。而对于我们这段ALM的相关代码则需要引用一个OTA COM Type Library(路径在 C:\Documents and Settings\All Users\Application Data\HP\ALM-Client\qc )。

    可能大家又会好奇,OTA是什么?OTA全称叫Open Test Architecture(开放式测试结构体系)。这是HP Mercury Quality Center提供的API。这个OTA就是一个让你能够通过外部应用程序(比如Excel/VBA)来访问Quality Center/ALM的公共对象模型库(COM Library)。官方提供了专门的帮助指南API,有兴趣的朋友可以网上搜索或者找我要。

        回到OTA COM Type Library的话题。为什么会出现CTDServer编译错误呢?因为我们的代码试图引用这个库,结果你没有在电脑上安装过这个库,所以引用失败。报的错误就是“隐含模块中的编译错误:CTDServer”。

        既然讲的这么清楚了,请大家去看看“C:\Documents and Settings\All Users\Application Data\HP\ALM-Client”这个目录下有没有东西吧,如果没有,那你就不可能引用OTA API来做Excel的导入。怎么办呢?

        你得安装ALM的客户端,即“HP ALM Client Registration”。到哪里安装呢?怎么安装呢?OK,注意下面几点,照着我说的做:

    1. 确保自己的计算机已经装好了.Net Framework 3.5 sp1 VC++ 2005 sp1http://www.microsoft.com/download/en/details.aspx?id=5638 ),注意千万别装中文版!

    2. 以管理员权限(Administrator)登录计算机。

    3.  IE7/IE8的浏览器地址框中输入 http://songfun:8080/qcbin/start_a.jsp?common=true ,这里songfun是我的计算机名,对于各位读者来讲,其他部分不用改,只要把机器名替换成你们自己的ALM的服务器的机器名! 如果大家可以连Internet,也可以连ALM Client在线下载的地址: https://qc.marchofdimes.com/qcbin/start_a.jsp?common=true

     

    安装完毕后,检查对应路径下是否已经出现了OTA的组件。如下图:

        好了,搞定了ALM Client,现在可以安装Excel插件了——我前面说过,其实只要把TDExcelAddin.xla拷贝到Office对应的目录下即可(C:\Program Files\Microsoft Office\Office12\XLSTART),不必安装。

        完成后,打开Excel 2007。点“加载项”,是不是看到了“Export to HP ALM”?好,把刚才的excelImport.xlsx打开,选中你想导入的部分(注意,一定要选中,否则它不知道到底想导入什么内容)——不要把表头(Table Header)也选进来,见图:

        点击“Export to HP ALM”,弹出一个对话框了——成功了一大半了!不再报CTDServer错误了!如图:

        好,点“Next”,看到下图:

        输入用户名和密码(确保已经在ALM中添加过),看到下图:

        因为我们这里要演示导入需求的例子,所以选择Requirements,如下图:

        因为导入的时候要告诉ALM想导入Excel的哪个列,所以这里需要建立映射关系,这里我选择“创建一个临时的映射”(大家工作的时候建议选择上面的,让它记住),如下图:

        这时候首先要选择的映射的列(字段)就是需求的类型,我们知道QC里的需求有个实体属性叫“Requirement Type”,它指明这个需求是需求的目录(Folder)还是功能性需求(Functional)或者其他,我在Excel中定义好了,就是那个D的列,看到了吗?在下图里:

        所以我们这里要选择“Requirement Type Column: D”,接下来就是导入所有的Excel中的内容:需求项(Name)、路径(Path)、优先级(Priority)、需求产品(Product)和作者(Author)。其实这里的中文叫什么无所谓,只要你映射好就行。如下图:

        点击“Export”,导出到ALM吧,只要你数据没问题,就会看到下面的喜图:

        真的成功了吗?好,我们登录ALM 11看看吧!

        怎么样?是不是已经导进去了?呵呵!

        关于ALMExcel插件深入剖析就到这里,下次给大家介绍下word插件。喜欢就顶下,呵呵...

  • 如何缺陷预防提高软件的可靠性

    架构师Jack 发布于 2011-10-25 20:25:39

              为什么在实验室测试完成后,在用户处总会出一些难重现古怪的问题,测试人员会困惑按需求进行了完整测试可为什么还会出现这些小概率的问题?究其原因,有多种根因导致软件在用户处会出现一些难重现的古怪问题(我需要另写一篇文章来分析和整理)。本文重点阐述其中一种常见根因——软件可靠性测试不足

     

    我先来介绍下常见软件可靠性测试的几个阶段:

    1.0阶段:基于个人经验的发散异常测试——测试过程和结果随机,难管理,遗漏也很多

    2.0 阶段:使用压力测试来发现系统抗压的可靠性问题——物料和时间成本高

    3.0 阶段:基于用户应用反馈回来的问题逐个亡羊补牢——被动等待,产品稳定周期长

    4.0 阶段:基于失效模式的系统故障注入测试——针对关键模块提早进行容错测试发现软件系统可靠性实现的不足之处。

     

        3种阶段应该是目前中国大部分企业的主流做法,这些方法对测试技术的储备和门槛要求较低,所以容易开展。但不足之处上面已谈到了:测试过程和结果缺乏确定性,物料成本高,测试时间(重现时间和定位时间)成本高,产品稳定周期长,还是会遗漏一些可靠性相关的问题到用户处。

    显然问题所在的地方就是测试技术研究应该关注和投入的地方。因此经过业界的努力有了软件可靠性测试的4.0阶段:基于失效模式的系统的故障注入测试。

     

    基于失效模式的系统的故障注入测试的好处:

    ——测试过程和结果具有确定性,可重复性

    ——几乎不增加物料,问题触发时间,重现时间和定位时间非常短

    ——主动尽早发现可靠性不足风险,实现尽早缺陷预防,缩短产品稳定周期

     

    基于失效模式的系统故障注入的测试分类:

    ——网络传输层故障场景   impossible or often ?

    ——硬件平台故障场景                   impossible or often ?

    ——运行软件平台故障场景          impossible or often ?

    ——人因差错故障场景     impossible or often ?

     

    在互联网时代任何软件只有对以上4个纬度的故障场景都进行了适度(对确实可能发生的失效模式)的可靠性实现,才算有了系统的可靠性保障,否则被动等待和大量亡羊补牢工作会等着大家。

     目前在网络传输层故障场景有比较完善系统的测试框架: 网络中断;网络抖动(闪断);丢包;数据包乱序是常见测试方案。

    而人因差错故障场景因为不同软件用户的使用方式不同,所以难统一抽象。但还是可以借用场景分析法对每个用户场景进行分支路径和异常路径的发散分析, 提前提取出用户可能的操作故障场景。

    硬件平台故障场景:对于软件而言,硬件平台就是运行软件的CPU所在的硬件载体。最小抽象的硬件故障场景有:硬件平台断电;硬件部件不可用;硬件部件不稳定;

    运行软件平台故障场景:软件所运行的驱动层、操作系统层或中间层软件。软件要正常运转需要通过调用运行平台所提供的资源接口API,然后运行平台也会有返回非成功值的场景,返回边界值的场景——而这是最容易被遗忘和最难测试实现的。如果软件对这些非日常场景(日常场景大部分都是返回正确值或中间值)没有对应的处理代码,则软件的可靠性就要大打折扣。

     

       想减少用户现场难重现的问题数,想减少可靠性测试成本,想缩短发现软件可靠性缺陷的时间,就尽早在组织中实践:软件可靠性测试4.0阶段——基于失效模式的系统的故障注入测试。

        在我新浪微博http://weibo.com/dongjietest 中分享的如何导致Google浏览器、Firefox浏览器、百度浏览器、QQ客户端、360浏览器、百度影音播放器、阿里旺旺等软件崩溃的测试技术原理就是基于失效模式的系统的故障注入测试之运行软件平台故障场景,证明某些软件在这个区域的测试还需要继续完善。

     

        任何意见欢迎邮件交流:                           dongjietest@163.com

  • 提升测试用例重用和逐渐完善的2个简单方案

    架构师Jack 发布于 2012-01-05 11:10:55

       今天收到一封关于如何测试用例管理的求助邮件,在帮助给出简短答复建议的同时有必要与更多的同行进行分享.
     
    董老师
    您好
      听过您讲课,非常精彩,但是太过短暂。
      现在请教一个问题,关于用例管理的问题。我们部门一直在做类似的项目,只是由于不同的地区,各个项目有些区别,怎么做,或者模板怎么设置可以让用例管理起来比较方便,或者哪些工具可以做到用例管理起来更方便,可以让用例的重复使用起来更好实现。同时可以让用例的基本的测试用例在使用的过程中逐渐完善,增多。
                           请赐教
     
    Jack提升测试用例重用管理的方法建议:
        用例应该这样来分类: 公共通用的基础用例集(所有地区都可通用)+ 半公共通用用例集(仅限单个地区通用)+专用用例(仅限单项目使用)-----做到用例尽可能的重用。
     
    Jack测试用例逐渐完善并与项目快速迭代同步的方法建议:
       每个用例应该至少有对应的:用户群+软件版本(开发用例时的第一个软件版本) 这样的2个属性。
       用户群属性:能帮助你围绕以用户为中心,以用户群类别为查询关键字随时调整和优化对应的用例质量。 真正实现以用户为中心的测试。
       软件版本属性: 能帮助你当软件实现发生较大变化时,你能快速调整对应的所有用例,避免存在用例与软件实现不一致同步的问题。
  • 测试技术方法对测试团队的影响

    架构师Jack 发布于 2012-01-05 23:22:26

     
        曾经大家对各种书本上的软件测试技术方法从追捧到排斥,主要原因觉得这些书上的测试方法很难在项目中落地和使用。对于不能在项目中使用的方法我也不太支持进行推广。但是来源于项目实践中的经验总结出来一些测试方法却是对我们测试团队提高效率和质量很有帮助。例如:James Whittaker总结出的很多探索性测试方法,James Bach提出的基于风险的测试策略,这些都是来源于他们解决项目中的测试问题所总结提炼出的实用测试方法。本文侧重谈谈我个人对测试技术方法对测试团队作用影响的一些感受,希望对大家有所帮助:
       1、 测试技术方法对tester而言类似士兵的作战手册,遇到各种常规作战中的问题时士兵们可以查翻作战手册快速做出有针对性地应对。如果tester或测试团队没有足够的测试技术方法积累,那么就会出现某些场景缺乏针对的测试活动,导致测试浪费或低效;
       2、 用测试技术方法武装训练测试新人可以帮助其快速提升测试专业工作效率和质量。对于组织而言,当有熟练测试人员离开项目组时可以快速补充新人在短时间内达到老测试人员的质量和效率。易用易推广的测试技术方法也降低了对人的依赖性;
       3、 一个测试团队积累了很多测试技术方法资产时有利于提升团队测试人员对所从事工作价值的认同感(有技术含量和有趣),以及看到个人专业技能提升的方向,整个团队积极向上,积极学习提升的氛围会更好。从而产生一个正向的良性循环。
      
      
        以上三点测试技术方法是对测试团队最主要的影响。欢迎大家积极补充。
  • 一个长期重要测试技术研究方向

    架构师Jack 发布于 2012-05-29 20:13:33

    最近心里悟到的一个可供大家长期研究的命题:"如果你都不知道什么是好的测试设计,那你又怎么知道如何进行好的测试设计?"   这句话放到其他行业" 如果你都不知道什么是好的设计,那你又如何知道进行好的设计."

        针对这个命题, 我已开始分解为功能测试, 稳定性测试, 性能测试三个领域的测试设计开始探索, 思考,提炼了,希望能在2012年底至少给我自己一个满意的答案"什么是好的测试设计".

  • 如何在需求阶段发现更多的缺陷

    架构师Jack 发布于 2012-08-16 11:51:20

     你知道如何在需求评审阶段快速高效的发现高质量的需求问题吗?下面我将第一次公开分享我在工作中所原创的一种需求评审方法-结对需求评审法(在国内国外都是首创)

     无论在任何软件企业,都会存在需求评审的环节,在这个环节我们测试人员应该如何发挥更大的质量保障的价值,是很多团队都会尝试的事。因为大家都知道在需求阶段发现问题成本、定位问题成本,修复问题成本最少。要提升整个研发的效率,减少返工浪费,最好能在需求环节尽早发现需求问题。如何快速容易的发现需求的问题,软件测试业界其实一直苦于缺乏高效的实践方法。

    09年时我也曾经接到过这样的一个任务:如何进行早期测试?如何进行缺陷预防。其中必须解决的一个问题就是:如何提高测试人员在单位时间内发现的有效需求问题数?虽然我们知道需求的质量也是有维度的:二义性、可测性、完整性、前后一致性、可实现性、必要性。我们应该从这些维度来发现需求问题,其中最主要的是二义性问题。但这只解决了What的问题,应该如何解决How的问题,如何发现这些类型的需求问题,就是测试技术或测试方法需要填补的空白。

      现在有两套方案推荐给大家:

    方案一:Richard BenderRBT基于需求的测试。

    方案二:我原创的DZ结对需求评审法

    如果你担心用得方法听起来太简单无法体现技术含量,而希望用复杂的过程及方法来体现技术的高精尖,你可以选择方案一;

    如果你希望用简单快速高效,不介意别人说你方法太简单的可以选择方案二。

    下面主要分享DZ结对需求评审法

     这个方法是我09年时与一位叫周博的同事,一起实践发明的。 针对需求中问题数量最多,也最严重的二义性问题,体会到很难通过传统的评审会形式快速发现,而且发现效率也低。 正好当时大产品团队正在实施结对编程(只对着一台电脑,一人写代码一人review代码)。我受此启发,某日灵感一现:想到结对需求评审这种形式。于是拉上周博同学,一起进行实践,实践方法如下:

    1、  两人只对着一台电脑、由1人作为引导员来操作电脑,记录评审结论

    2、  引导员控制时间节奏和维持结对需求评审的规则,两人针对每条需求,逐条进行固定时间窗(13分钟)范围内的理解

    3、  2位评审人在单个需求的理解时间到时,直接说出每人对这条需求的理解。如果两人理解一致,就直接看下一条需求;如果理解不一致,不能进行讨论,而是由引导员直接记录下两个人的不同理解内容,这时说明这条需求至少已让2个人产生了二义性的理解,需求存在二义性问题。

     

    关键技术活动点的理论支撑:

    1、          一条需求(13行文字)如果需要你使劲思考和理解5分钟以上还不能准确说出其描述的本意,那么已说明这是一段容易让人理解出错,容易产生二义性问题的文字描述;

    2、          如果一条需求已至少让两个人产生两种不同观点,那么就可能让更多的人同样产生二义性理解问题;

     

    影响结对需求评审效果的关键:

      1 多练习。 对于方法的初次使用者,建议第一次先用1小时拿需求文档进行练习熟练后,再在正式的需求评审项目中进行使用(提高效率)。

      2 参加需求评审的2名测试人员应该先了解过产品的背景和历史,才参与结对需求评审活动。(提高效率和产出质量)

     

    参考投入产出比:

    某项目用2小时发现40多条需求问题;

    某项目第一次练习应用20分钟发现4条需求问题;

     

    备注:一个需求二义性场景,需求编写人员心里想做个椭圆的盖子,开发者理解成了圆形,测试者理解成了方形(已开发了方形盖子的测试用例),然后开发者和测试者发生沟通冲突开发被迫返工。

  • 用户体验质量的测试方法论-“你的风扇方案”

    架构师Jack 发布于 2012-10-25 21:56:14

    用户体验质量的测试因为涉及到很多人直观感觉的判断,导致了一直以来没有好的测试评判标准。虽然有一种用户体验实验室通过录制用户操作的眼球变化来记录用户行为,推断用户体验效果。但是让我想起了经典的检查空香皂盒的故事:生产线要检查出空香皂盒,有家公司投入多名专家研发了一套激光系统来检查,一家小公司的工人想出用风扇吹飞空香皂盒的方法。对于绝大多数的同行公司更适合风扇方案因为经济实用,实施快。不是所有公司都有条件建立用户体验实验室来录制用户操作眼球变化。那么有无一套“风扇方案”简单有效地发现软件产品用户体验质量的质量问题。类似的问题有:如何发现微软地图中的路线错误问题,如何发现图片搜索中搜索结果图片集质量差的问题。我曾听过一个经典的案例分享:微软一个实习生在不知道微软地图搜索任何实现算法的基础上,建立了一套只有几百行脚本的测试判断系统就能对百分之九十多的地图线路进行用户体验质量的判断和质量保障,这是一种逆向的真正地以用户体验来基准的测试,而不是验证算法实现有无程序错误。自从听了这个案例后,我一直都在思考如何把微软地图测试案例的思想应用到其他软件的测试中。

     最近终于有所收获,并在产品中进行应用。在此把总结出来的用户体验质量测试的方法论与大家做一个分享,也请大家拍砖给各种意见。

      第一步:收集1020 你产品领域的其他产品

      第二步:安排不同角色的34名同事对第一步收集的所有产品进行输出结果质量最严格的评价,每个评估同事至少为每一个用户体验不好的产品输出510条不好的“现象”,注意是“现象”不是“原因”

      第三步:汇总所有不好的“现象”,提炼出高概率有共性的“现象”列表。

      第四步: 共性“现象”列表 就是你用户体验质量测试结果的判断标准,这些判断标准是任何一个测试人员都能执行判断的,这就是你的“风扇方案”。

      对于某些产品甚至可以实现自动化用户体验测试执行。

     

    背后的逻辑和方法论:

     逻辑1大多数人都能发现严重不好的用户体验现象

     逻辑2同领域产品解决同样的用户需求,会表现出大多数相同的用户体验质量问题现象

        逻辑3用户体验不好的现象会有多种badcase现象类型,产生问题的设计和实现根因会有多种可能,你无法事先正向知道所有设计组合的badcase效果,但是一旦出现了质量差的用户体验现象,那么一定是产品设计和实现出了问题,具体根因再继续定位分析。

     

    虽然不是所有的用户体验质量测试都可以自动化实现,但是有一部分产品是可以实现自动化的挖掘用户体验质量badcase的,其核心思想之一:抓取产品输出的badcase现象,即使不能自动判断出所有badcase现象,只要能自动挖掘到部分badcase现象也能证明产品的设计或实现存在用户体验质量领域的问题。限于工作原因,具体应用案例暂不公开请理解。

  • 减少缺陷漏测的系统方法体系思考(10年经验的反思)

    架构师Jack 发布于 2013-03-22 10:05:45

           从接触软件测试工作开始,相信所有人都希望减少软件测试后漏测的问题(tester希望,开发经理希望,老板希望),但事实是一直以来都没有很好的真正解决产品漏测的问题以及如何减少功能组合爆炸的问题。过去几年因为工作任务的缘故,我在历经几年自动化测试、系统测试和缺陷预防工作后,又回到测试的本源开始思考功能缺陷的测试应该如何做好?从2011年版本到2012年版本直到2013年终于优化完善出了自己的功能测试方法体系,没想到居然在软件测试行业从业近10年时才搞明白了10年前就开始的问题。过去的5年通过实践补充了自己在缺陷预防领域的技能和认知、可测试性设计领域的技能和认知、产品可靠性测试(稳定性测试)领域的技能和认知,直到2年前才开始真正介入功能测试方法改进。最后才意识到原来我们不少漏测的问题,不是性能测试可以发现的,也不是稳定性测试可以发现的,更不是自动化测试能发现的,现有的功能测试用例及方法也发现不了--多功能组合下和不同用户操作序列下才发生的bug。怎么办?以及如何解决组合爆炸的问题--我们一直都在回避。如何让我们投入测试时间最多的功能测试用例该多的地方多,该少的地方少?搞了半天,原来测试领域最基本的工作都没做好,然后就开始疯狂追踪上层建筑,或是简单实行拿来主义拿来一些工具或方法,虽然所拿来的这些工具或方法对局部的确是有优化作用,但你知道自己的全局全貌在哪里吗?知道全部漏测的测试根因在哪里吗(而不是产品技术根因), 如果不知道则容易陷入盲目乐观与更加保守的状态。听说有个工具或方法能发现很多bug--于是开始盲目乐观引入,希望能从此解决完所有测试漏测的问题,结果确实能发现一部分问题但是还是有不少漏测,结果--开始更加保守,对新工具和新方法不再相信和信任,从此对漏测问题放在一边交给其他人去关心。那我就是那位被迫要去关心和解决漏测问题的非主流测试工程师,幸运的是经过过去几年的思考与学习,如今随着个人稳定性测试模型和功能测试模型方法体系的完善,终于让我有信心有知识去应对任何软件的漏测问题, 可以阶段性的结束对漏测问题领域的专注思考,投入更多精力于其他测试技术和方法体系了, 故写此文阶段性纪念下。下面分享一部分如何减少功能缺陷漏测的干货吧,与各位共勉:    

    功能缺陷的测试方法流程
       第一步: 功能测试分析 功能测试阶段
                目的: 提取功能测试对象
                           准备功能测试数据
                减少因为功能测试对象遗漏的漏测

       第二步:功能验证功能测试阶段
                目的:检查功能是否已基本正确实现   
                测试方法 :
    基于生命期: 对象创建 -使用- 销毁 的验证
    数据测试方法: 静态数据测试方法和动态数据测试方法 (边界值和数据等价类、7因子数据类型)
                减少功能的基本逻辑错误漏测和数据处理错误的漏测

       第三步:单功能内测试 功能测试阶段
                目的:发现功能是否存在分支情况、异常情况处理不足的缺陷
                测试方法 :
                功能内子功能的场景插入法
                             重复法设计
                             反叛法设计
                             取消法设计
                            测一送一法设计
                           场景删除法设计
                减少功能内代码的漏测
                 
       第四步:多功能间组合测试 系统测试阶段的用户场景测试
                目的:发现功能间配合工作时存在的缺陷
                测试方法
                    基于用户场景的测试 (Scenario Test)
                减少多功能间组合错误的漏测

    为什么需要用户场景的测试模型?
         补充多个功能组合的测试用例解决传统正交组合测试后3个及以上功能组合缺陷的漏测
         通过常见用户操作序列的场景设计解决数学式穷尽组合爆炸的问题减少组合测试时间和成本,获得最佳投入产出比的组合测试

    用户场景测试的测试步骤 是 不同角色用户最常用的基本操作序列
    用户场景的探索测试    是 不同角色用户非常用的操作序列

    用户场景的探索测试
    在用户场景测试用例执行结束后 , 再用专项时间进行多功能组合的探索测试,补充用户场景测试用例之外的用户操作序列,提高用户操作序列的覆盖面。因为用户最常用的操作序列已在用户场景测试用例中覆盖,但又不能对非常规的操作序列不进行测试,   因此将非常规的操作序列的测试与测试成本进行一个平衡,通过专项的探索测试时间来补充这部分的测试。

    在补充用户操作序列的探索测试中可用的探索测试方法有:
    收藏家法
                同时开启多个功能,同时工作。
    技术根因
               同时多个功能交互容易出现资源竞争处理的错误。

    地标法
            改变一系列规定顺序操作的先后顺序。( A->B->C->D->E)改为 (A->D->C->B->E)
    技术根因
          在实际场景中用户因为对操作不熟悉难免会操作的步骤不是标准的步骤顺序,而程序实现时对于这些改变了操作顺序的操作步骤缺乏容错处理则会出现程序错误。

     混票法
           把最不常用的功能与常用功能进行组合
        技术根因
           在功能测试阶段由于时间及优先级限制,测试人员习惯把常用功能进行组合测试,时间一久就容易忘掉不常用功能与常用功能的组合,而用户的使用习惯中也一定会出现不常用功能与常用功能一起组合的场景

      
      
  • 什么是测试框架

    架构师Jack 发布于 2011-03-01 21:13:04

    测试框架总体而言可以参考软件开发框架来构建,下面是从软件开发框架原则中对应提取的测试框架的属性:
    1、测试框架是测试开发过程中提取特定领域测试方法共性部分形成的体系结构;
    (软件框架是软件开发过程中提取特定领域软件的共性部分形成的体系结构)

    2、测试框架的作用:在其基础上重用测试设计原则和测试经验,调整部分内容便可满足需求,可提高测试用例设计开发质量,降低成本,缩短时间;

    3、不同测试技术领域有不同的测试框架类型;

    4、测试框架不是一个现成可用的系统,是一个半成品,需要测试工程师基于它结合自己的测试对象知识转化成自己的测试用例;

    5、测试框架是提供给测试人员开发相应领域测试用例的测试分析设计工具;

    6、测试框架不是测试用例集,而是通用的,具有一般性的系统主体部分。测试人员像做填空一样,根据具体业务完成特定应用系统中与众不同的特殊部分;

    7、测试设计模式的思想(等价类/边界值)在测试框架中进行应用。

    以上为个人总结体会,不一定正确,但我开发的测试框架却是的确满足了以上7个属性来实现的。
  • 设计路径测试覆盖率与代码测试覆盖率

    架构师Jack 发布于 2011-05-29 18:24:23

       100%代码测试覆盖率就代表了我们的软件100%测试完毕了吗?我们就能对测试放心了吗?代码测试覆盖率到底给了我们什么确定性的结论呢? 节选自微软技术丛书《完美软件:缺陷预防最佳实践》软件测量与度量一章:较高的代码覆盖率与较高质量的代码不存在相关性,较高的代码覆盖率反映了测试宽度,不是测试深度,Pareto原理客户关心的缺陷80%可能存在于20%的代码。
         该书微软的作者提出了这样的一种观点:测试宽度和测试深度。我对测试宽度的理解是测试宽度代表实现软件的函数有多少比例被测试调用验证过,如果还有部分实现的函数从未被测试调用验证过,难免在这些函数中会有遗留的缺陷,这是我们追求单元测试覆盖率100%的原始动力。
           哪什么是测试深度呢? 先举一个例子:某模块有A(),B(),C() ,D(),E()5个函数。正常的处理流程是A并行依赖B和C, B并行依赖D和E,C依赖E; 如果在实际业务中E()函数的调用失败了(原因有:CPU忙OS调用E超时或E依赖的某个资源不足),那么对原来的函数调用序列的影响是什么呢?则是我们传统的函数接口测试或函数单元测试中难反应的场景,这类函数间的多层次调用序列和相互间的调用交互关系这就是我们的测试深度。传统模式下我们一般在集成黑盒测试的条件下发现这类深层次的测试深度问题。
          这也是为什么一直以来单元测试代码做到了100%覆盖了,还是能在系统测试环节发现不少埋藏深难通过人脑静态检视而发现的bug。既然代码测试覆盖率不能代表测试对需求实现覆盖的完整性(包含测试宽度和测试深度),那么我们如何度量测试对需求实现覆盖的完整性呢?
          在此我提出了一个设计路径测试覆盖率的概念,鉴于blog表达机制的约束,我就先简单文字描写一下什么是设计路径测试覆盖率—— 任何原始需求的实现都有一个内部状态迁移图,这个迁移图中包含了所有软件运行的路径(成功路径和失效路径)。我们针对状态图的所有路径分段用不同的测试用例来覆盖,并以此目标来设计我们的用例(可以使用单元测试工具手段和可测试性手段来实现),这样我们的测试用例就一定是覆盖了所有的需求实现成功路径和失效路径,并且我们没有多余用例。
          当然以上做法的不足是:由于需要测试设计人员对模块实现的设计逻辑要100%清晰理解,耗时会比较多。因此可以只针对20%对客户所关注的高风险模块进行设计路径测试覆盖率的测试设计活动。

    最后总结2个建议:
          1、代码覆盖率可以作为需求实现测试完整度的宽度参考,但不能作为决定测试投入结束的标准。
         2、如果测试组织内测试人力和时间不够(大多数情况下),则参考Pareto原理在20%的高风险模块进行设计路径测试覆盖代替进行函数级的代码测试覆盖,用100%的设计路径覆盖用例代替代码测试覆盖率更具真正的测试深度完整性。
        
        
  • 培训策略技巧---经验分享

    congyu15 发布于 2011-03-02 16:03:24

    如果一次培训结束之后,没有热烈的掌声,那这次培训就很失败!

    最近我不得不开始怀疑自己、反省自己:

    “这到底是怎么啦?”

    “我到底是哪里做错了?”
    ……………………

    于是我将问题转向并集中在了下列方面:

    我培训的内容是不是听众所迫切需要的?

    我培训的方式、方法是否被听众喜欢?

    我培训时的语气、语速等等是否被听众所接受?
    ……………………

    我终于恍然大悟,像我一样来自底层充满希望进行培训的不在少数,要把一件事情做的完美,不是那么简单、容易的事情!

    因此要做好一次培训,总结如下:

    一、培训资料的搜集与整理
     原则:复杂的东西简单化,简单的东西实用化
      1、 资料搜集(各种媒介、网上摘要、工作经验、请教类似的专业人士)
      3、 培训时间的长短把握(最好在培训教材上注明)
      4、 优化培训教材(多站在听众的角度来考虑,培训之前先简单阐述一下该次培训的主要原因、内容、目的)
      5、 换位思考,多站在听众的角度上考虑问题
      6、 说话不要过于主观,特别是不要武断,要保持中立
      7、 初步了解学员的组构,有针对性的准备一些相关的资料

      二、如何提高与达到讲课的实效
     原则:版书数据化、用词专业化、书写简易化、讲课通俗化(用标准的普通话,忌用别字,讲课时说话要比平时略大声一点)
      1、 培训前的气氛调整(如借用课堂的布置、当天的天气、也可利用自己的名字、借用赞美听众们坐姿规范或精神来调整课堂氛围)
      2、 把当次要讲的主要内容版书出来(最好用通俗易懂,一目了然的方式体现出来)
      3、 学会用讲故事的方法来解释及描述
      4、 相互学习及归零的培训法
      5、 不挑剔听众,不另眼看待听众,听众在你眼里都是最优秀的
      6、 语速、语调的规范(每分钟约40个字,切忌不宜太快了,否则培训结束后听众还一头雾水,那你此次培训肯定完了)
      7、 利用自己的特长,结合听众的实际临场发挥
      8、 经验分享(自己成长的过程及历史)
      9、 引用一些名人及名事来引起听众的认同
      10、 在说话与发表自己的观点时,保持中立及多角度的来分析看待
      11、 说话不要过于主观,更不能武断的下定义
      12、 换位思考,多站在听众的角度上考虑他们的承受力

      三、如何规避一些不良习惯
      1、讲师常犯的口误例:
      你我他
      你们/我们
      据我所知
      “知足”与“满足”
      2、讲师常犯的举措
      手指指点点
      站立不端正
      3、讲师一些不良习惯
      例:尾音/噢之类
      这个吗
      一句重复的说
      不乱模仿他人的种种习惯

      四、如何与听众现场互动
     原则:先要求自己用心讲课,发自内心的来参与,目的是让听众主动参与
      1、 培训过程中善于穿插幽默、笑话
      2、 用一些名人、名事作案例来引起听众的共鸣

      五、完善培训教材,为下一次培训补充新的血液
     原则:在于及时与坚持
      1、 在讲课时有些不完善的地方要及时加以补充(当时和课后补充)
      2、 采用填表的方式对听众做一个培训内容及讲师讲课技巧的跟进调查
      3、 培训之后与一些听众进行交流 (有则改之、无则加勉)
      4、 培训之后要回忆自己讲课时的情景,从中找出优缺点,再进一步的完善培训教材及培训方式

    从哪儿跌倒,再从哪儿爬起

    不能被同一个石头绊倒两次

    期盼下次培训不会很糟糕

  • 测试过程与团队管理培训——分享一

    alipay_TM沙龙 发布于 2008-12-03 21:16:52

    什么是软件测试?

    开篇就以三个可以作为我们日后工作知道的信条开始吧,呵呵~~

    ü  做不到更好是因为我们不知道什么是更好的

    ü  所有人摘掉的借口就不是借口

    ü  更大的能力意味着更大的责任

    当听到这三句话的时候,发现如果在日常测试工作中能以这个为指导,那很多测试mm、刚毕业的测试人员等等,就不会有那么多的抱怨,或者迷失方向的感觉。其实工作就是一个探寻的过程,重点不是技术有多难,重点是判断事务的方法和做事情的态度。呵呵~~(稍微感性一些)

      下面就本次的题目进行一下简单的论述:

    n  测试是一个软件质量保证的过程,不是在软件开发过程中的一个简单的环节。如果这样理解测试,那么测试过程就可以类似软件开发过程一样,可以定位多个层级。然后就可以针对各个层级的描述,针对当前公司的真实状态,找准最需要最紧迫要解决的问题。这样就不会出现“测试现在问题好多呀,要改进的地方太多了,感觉哪一个都紧迫,所以不知道要先做哪一个。那就干脆还是维持现状吧。”

        初始级->重复级->定义级->管理级->优化级

     就目前我们的测试过程现状,基本上是处于重复级和定义级之间。目前传授的更多的是经验,例如:最  佳实践。但是也在做一些方法的定义,例如:度量数据的统计。就是期望这些数据能给我们后续的一个  改进措施和方法。

    n  测试的目的是什么?经常会有如下几类的答案。第一,测试就是为了寻找bug,尽可能更多的寻找bug。第二,是通过寻找bug来保证和提高软件的质量。第三,是为了实现一个特定的目标而进行的有规划、设计、实施、完善等一系列活动。

    如果我们延续第一个思路,那显然就第三个才是正确的答案。也就是说第三个才是我们做测试的真正目的。但是感觉第三又是比较玄乎的,怎么才能让测试真正的成为一个过程,而不简单的是一个行为、动作。那就是要很定期测试整个过程的规范。(详情见下一次的分享,呵呵~

    另外,从这个测试目的来说,测试其实不是很需要有特殊癖好的人。例如:有个人说自己很喜欢找别人的bug,把自己的幸福建立在别人的痛苦之上。显然,如果这个人技术很好,能找出很多隐藏很深的bug,而我们更需要让他把他的经验总结成为一个可操作的方法,这样才是对我们来说更有价值的。如果简单的就是只有他一个人能做,那从整体的团队价值、过程建立方面,其价值是微乎其微的。并且我们更重要的是建立我们的产品目标。也许对某些产品而言,这些更深层次的bug并不影响用户的使用,或者用户根本就遇不到这样的场景。

    n  软件测试的成本。这个问题似乎在某一个阶段是很少有人考虑的。但是从现实情况来说,测试是公司的一个成本部门,所以我们在做任何行动的时候都应该考虑我们的投入产出比是否核算。怎么能利用更少或者更合适的人,做出更好的或者说更有效的产出。并且在做策略定义的时候也需要考虑一下公司对测试的定位和目标。

    n  最后,在此想就老师提出的几个错误认知在此描述一下。

    误区一:按照规范来测试可以提高软件质量

    ……>测试是用来验证软件质量是否符合预期的,软件质量是做出来的,不是测出来的。

    误区二:依靠规范的过程来保证软件质量

    ……>标准的规范只能作为规范受益者的一个判断衡量标准。

     

    Add by kitty.wangx

  • 培训归来小感

    挪威森林 发布于 2008-08-22 16:47:56

    12天的培训,今天终于结束了,12天确实是生命中一段难忘的经历,150个同事聚在一起,我们用几天晚上的时间准备出一台晚会,用几天的学习了解了公司文化,也了解了如何定位自己的人生,定位自己的工作,如何管理自己时间,如何为自己人生制定计划。短短的相聚让我们结识了很多朋友,虽然我们来自公司不同的部门,但是我们因为培训的相处,距离变得很近。

    我觉得人生最重要的是经历,经历让自己触发很多的感想,思考,感悟。工作最重要的是经验的积累,而经验来自于你在工作中不断学习,摸索和总结。

    有人为我为什么不跳槽选择开发,我说我是希望能学到更多的东西,我觉得测试比开发能学到更多的东西,因为测试需要很广的知识面,很强化的知识体系,很熟练的业务技能。我们要比研发更细心。我从来不觉得自己的工作比较低等,也许软件测试现在还不太被重视,但是这种处境会改变,我们需要用我们的工作来赢得更多的尊重,这点你我都可以做到!

  • 教你如何做主管——MTP培训心得

    ypeony 发布于 2008-03-06 11:10:58

    教你如何做主管——MTP培训心得

    前段时间,公司有组织中高阶主管及其培养干部进行了为期三天的管理训练培训。三天的课程下来,虽然内容较多,因对老师三天来的课程内容深有感触,故借着整理学习心得的机会,将三天来的培训课程做了一个结构化的整理,与大家来分享。

    在上课的过程中,觉得老师讲的内容较多,涉及的面也比较多。刚开始在整理学习心得时,点点滴滴整理了大约十七八条。再反复经过对这整理的十七八条心得,发现其实老师主要就是围绕“如何做主管?”这个话题展开的。整体上可以将这四天培训的主要知识点用下面这个图来表示。

    clip_image002

    作为一个中阶主管,其基本工作如上图所示,主要是五大项:

    1. 设定工作目标;
    2. 工作规划与分配;
    3. 人力资源发展;
    4. 激励和人际沟通;
    5. 授权给部属。

    下面分别就这五项工作来对老师讲的内容以Q&A的方式做一个陈述。

    一、设定工作目标

    Q1:如何设定团队与部属目标?

    A1这里老师主要结合围绕企业运行的三个流程来讲的:策略流程、人员流程和营运流程。设定公司和部门的目标是策略流程的主要内容。公司依据其内、外部环境来设定公司的目标、策略。这一过程主要由高阶主管来完成。最终会形成诸如《公司年度事业计划》。

    部门目标则是对公司目标和策略的有效分解,最终形成诸如各部门年度KPI。

    部属或者说是个人的目标则是对本部门的KPI的有效分解。

    这一系列的从公司目标和策略的制定到个人KPI的制定的过程就是前面讲到的策略流程。

    同时老师也给我们介绍了一些关于目标设定的读物,它们是:

    1)《蓝海策略》、《战略地图》、《方针管理》——用于指导公司目标和方针的制定;

    2)《目标管理》、《关键绩效指标》、《平衡记分卡》——用于指导部门目标/KPI的制定。我们公司就是用平衡记分卡来指导KPI的制定。

    3)《变革管理》——用于指导当公司目标和方针发生变化时,团队如何应对。

    Q2:如何面对上级主管的临时插单?

    A2在计划之外,上级主管分派新任务总是中阶主管经常面对的事情。那么作为中阶主管需要如何来面对这种情况呢,老师给我们介绍了一些可行的方法:

    1) 首先,作为主管需要将新课题放在最优先的位置,安排最重要的人,最重要的资源来处理,因为往往只有这些新课题才会创造公司价值;

    2)其次, 要优化,改善原来计划内的工作,采取诸如删除、合并、简化、OA化、E化等方式来优化旧课题,以提高生产率。

    3)另外,对于分派的新课题,作为中阶主管,需要采用有效的方法及时(在上司分配工作2~4小时内)与上司明确新课题的目的:本单位/现在的目的是什么、公司/未来的目的是什么、实现新课题的限制条件有哪些等。

    Q3:如何向上级主管行销你的计划?

    A3向上机主管报告计划时,时间不能超过10分钟。为了能够让上级主管快速有效地了解自己的计划,需要在向上司报告前,对自己的计划进行摘要,突显出计划的重点内容。计划摘要的内容包含以下几个部分:

    1)计划目的:当前目的、最终目的(跟公司的策略连接)

    2)现状问题

    3)创意(构想)——有哪些新的创意,或者是计划的整体思路

    4)效果:有形成果、无形成果

    5)费用

    6)风险评估与应对

    Q4:如何改善团队的工作绩效?

    A4通常我们都可以将团队的工作内容分解成三种类型的动作:

    1)有价值的动作,它指对产品和顾客增值的动作,对于这类动作,我们需要的就是将其标准化,并写成工作分解表/指南/Checklist;

    2)无价值的动作,它指诸如拿材料、检查等动作。对于这类动作,需要的就是尽量将其合理化;

    3)浪费的动作。对于这类动作,需要的就是尽量将其消除。

    进行这样的持续改善,就能够不断地提升团队的工作绩效。

    Q5:如何解决工作中的问题?

    A5在工作中发生的问题,通常有80%~90%都是事实明确的,剩下的10%~20%是事实不明确的。

    对于事实明确的问题,解决问题的方式是:

    1)收集数据——三现主义(现场,现物,现实),并采取紧急措施;

    2)寻找问题的真正原因:(3WHY 系统图法)

    a)让所有人知道问题在哪里

    b)弄清楚解决问题的目的

    c)即使一个不良也要对策

    3)采取对策消除真正的原因

    对于事实不明确的问题,解决问题的方式是:

    1)成立QCC(品管圈)或者QIT(品质改进小组)

    2)利用SPC,QC工具,6σ等工具进行问题分析,找真正原因

    3)形成统计报表,用来做预防管理。

    Q6:目标设定的SMART原则

    A6SMART指的是Specific、Measurable、Achievable、Relevant、Timely。

    Specific是指每项目标的指订,一定是特定的,而不是一个概略性的;

    Measurable是指可衡量的,每项目标必须要用量化的指标来订定;

    Achievable是指可达成的,所有的目标一定要是能达得到的;

    Relevant是指有关的,也就是每项目标都必须与主管的目标相结合;

    Timely是指时效性,也就是每项目标要在限定的时间内完成。

    二、工作规划与分配

    Q7:主管的时间如何管理?

    A7工作通常可以分为四种类型:定型性工作、规则性工作、特别性工作、创造性工作。

    1)定型工作指个人专长的事情;

    2)规则性工作指诸如开会、电话、巡视工作现场;

    3)特别性工作指诸如跟上司讨论计划、协助上司解决问题;

    4)创造性工作指辅导部属解决问题。

    通常前二种工作的绩效比重常只占20%,对于这样的工作,主管需要思考:

    a)是否可以授权?

    b)是否可以代理给别人?

    c)是否可以不要做?

    对于后两种工作需要多思考如何增加其比重。

    Q8:工作如何分配给下属?

    A81)团队的建立是主管的职责不是部属的责任;

    2)主管培养接班人一定会造成组织的不平衡,但主管要负责平衡;

    3)主管在分配工作时,需要根据事情的成熟度,部属的成熟度和组织的成熟度之不同来分派工作。分配工作时需要告诉部属:

    a)是什么事,谁交代的;

    b)为什么让他做(个人重要性)

    c)这件事的价值:对单位,对个人

    Q9:主管如何面对命令系统的例外?

    A9一个组织通常都会从品质、成本、弹性、速度和服务等几个方面来提高客户满意度。其中品质和成本是基本因素,弹性、速度和服务是差异化因素。

    在追求用差异化因素提高客户满意度的组织里,命令系统的例外是经常会遇到的。

    主管在遇到这样的情形时,面对部属需要扮演支援的角色,支援部属时,需要:

    1)问部属做什么事情,目的在哪里;

    2)问部属是否需要支援;

    3)问部属什么时候可以完成;

    4)帮部属安排事情的轻重缓急;

    5)责任主管承担。

    对于上司,主管需要:

    1)报告进度;

    2)重新确认目的;

    3)跟上级寻求支援;

    4)对上司笑一笑。

    任务完成后,向上司报告时,主管需要:

    1)跟部属一起报告。由主管报告两头,部属报告专业性的内容。

    2)部属报告完毕后,请部属先离开。

    三、人力资源发展

    Q10:主管如何培育部属?

    A10主管需要与部属一起,以个人KPI为目标,结合个人期待(生涯规划、部属目前具备的条件)和组织期待(担任工作必备条件),来制定部属指导计划表。

    并按照部属指导计划表对部属进行培养,并且定期与部属就训练成果进行沟通,寻找差距以改进。

    完成KPI是主管的职责,培养接班人/部属是主管的天职。

    四、激励与人际沟通

    Q11 如何使部属表现良好的绩效?

    A11要使部属表现出良好的绩效,需要做到以下几点:

    1)让部属了解自己的职责;

    2)让部属知道自己的工作目标;

    3)让部属知道自己的工作对组织的贡献和价值;

    4)使部属具备从事该项工作的知识技能;

    5)对绩效好的部属要给以奖励;

    6)对部属的工作,主管要给以支持,并及时加以回馈和鼓励;

    7)主管要促进员工有意愿不断改善绩效。

    Q12:如何与部属做绩效Review

    A12在与部属做绩效Review时,主管重点需要思考三个问题:

    1)这个部属做得如何?

    2)他可以改进些什么?

    3)我应该做些什么来改善部属的绩效?

    在实施绩效Review时,主管需要:

    1)准备议程(面谈结构化);

    2)建立一个不拘泥,不仓促的气氛;

    3)用称赞来建立双方的信心;

    4)让部属做自我评量,以降低部属的紧张;

    5)鼓励部属说话并积极倾听部属说话。

    6)讨论部属的工作绩效,焦点放在事实上,不做人身攻击,不牵扯到不相干的争端;

    7)主管需要保持正向态度,用正向语言做批评;

    8)主管需要在平日即时指正需改善之处,以避免面谈时突然提出;

    9)与部属一起商讨可测量的目标以及未来可行的计划。

    Q13:部属需求不满时如何处理?

    A131)先完成需求的分析表格,弄清楚部属的需求、目标、障碍和不满行为是什么;

    2)排除工作上的障碍。部属不满通常60%~70%是感情、家庭、个人等方面的因素,对于这些方面的因素,主管要做的是:

    a)公司的规定只能表达一次

    b)不能说公私分明

    c)倾听对方讲话,讨论对方的话题

    d)共通讨论可能的解决方案(请上司裁决)

    e)适当时请同事在工作上给以协助

    Q14:部属做得不好时如何处理?

    A14当部属做得不好时,跟其反馈需要注意:

    1)尽量不要当下指正(时间,地点)

    2)方式上

    a)不要批评,指责

    b)要提出问题,要提供解决方案

    c)采用分享的方式

    3)态度上

    a)协助对方

    b)平等的

    部属为什么不愿意承担责任,是因为我们常在其他人面前指正部属。

    Q15:如何与平行单位沟通?

    A15当单位间有冲突不可调和时,需要从以下几点来考虑和解决:

    1)公司的目的/顾客的目的是什么?

    单位的目的是手段,不能因为手段而忘了目的。

    2)提高两个位阶来考虑

    3)提出双方意见,求同存异,先执行相同的

    4)创造新的解决方法

    5)请上司裁决(尽量少用,因为高阶主管不喜欢做内部裁决,原因

    a) 因为手心手背都是肉

    b) 并不了解过程

    c) 会造成更激烈的冲突和派系

    组织的冲突是进步的动力

    Q16:如何与上司进行沟通?

    A16在与上司沟通时,重要的是做到参与管理:

    1)不只是提出问题,同时也要提出建议;

    2)提建议时,需要提二个以上的建议,并加以分析(只提一个建议的主管是陷害上司的人);

    3)与上司讨论,并由上司做裁决。

    同时需要注意上班是行销。行销的是自己的能力。

    最后需要注意的是与上司沟通时的态度:是争取资源与支援,而不是证明对或错。

    五、授权给部属

    Q17:授权的前提是什么?

    A17授权的前提是工作标准化。只有将工作标准化后,主管才可以授权给部属处理——可控。

    工作标准化的方式是拟定工作分解表,或工作指南或Checklist。

    Q18:授权失败后如何做?

    A181)主管要能承担责任;

    2)与部属一起寻找原因并分析它;

    3)辅导部属执行纠正措施。

    Q19:主管裁决的7-2-1原则

    A19对于市场,顾客与员工的需求,通常通过组织的办法,流程(法)可以满足70%,对于这些部分需要进行标准化,细化到工作分解表,并授权给基层人员直接处理。

    对于另外的20%,则需要由主管根据顾客利益和公司利益平衡后从合理的角度进行决定

    对于剩下10%中阶主管不能确定的,则由高阶主管进行裁决。高阶主管裁决时多从情的角度决定。

    通过对以上内容的学习,让我自感受益非浅,故将其整理出来作为自己未来的一个行动指南。同时将其与大家分享,也希望能够对各位同仁的工作产生积极的影响。

    另外,对于以上整理的内容,如果你觉得有任何遗漏的地方,欢迎与我联系,让我们共同完善上面的知识地图,期待与大家的交流!

  • 培训策略技巧---经验分享

    你奈我何 发布于 2007-12-07 13:37:11

    如果一次培训结束之后,没有热烈的掌声,那这次培训就很失败!

    最近我不得不开始怀疑自己、反省自己:

    “这到底是怎么啦?”

    “我到底是哪里做错了?”
    ……………………

    于是我将问题转向并集中在了下列方面:

    我培训的内容是不是听众所迫切需要的?

    我培训的方式、方法是否被听众喜欢?

    我培训时的语气、语速等等是否被听众所接受?
    ……………………

    我终于恍然大悟,像我一样来自底层充满希望进行培训的不在少数,要把一件事情做的完美,不是那么简单、容易的事情!

    因此要做好一次培训,总结如下:

    一、培训资料的搜集与整理
      原则:复杂的东西简单化,简单的东西实用化
      1、 资料搜集(各种媒介、网上摘要、工作经验、请教类似的专业人士)
      3、 培训时间的长短把握(最好在培训教材上注明)
      4、 优化培训教材(多站在听众的角度来考虑,培训之前先简单阐述一下该次培训的主要原因、内容、目的)
      5、 换位思考,多站在听众的角度上考虑问题
      6、 说话不要过于主观,特别是不要武断,要保持中立
      7、 初步了解学员的组构,有针对性的准备一些相关的资料

      二、如何提高与达到讲课的实效
      原则:版书数据化、用词专业化、书写简易化、讲课通俗化(用标准的普通话,忌用别字,讲课时说话要比平时略大声一点)
      1、 培训前的气氛调整(如借用课堂的布置、当天的天气、也可利用自己的名字、借用赞美听众们坐姿规范或精神来调整课堂氛围)
      2、 把当次要讲的主要内容版书出来(最好用通俗易懂,一目了然的方式体现出来)
      3、 学会用讲故事的方法来解释及描述
      4、 相互学习及归零的培训法
      5、 不挑剔听众,不另眼看待听众,听众在你眼里都是最优秀的
      6、 语速、语调的规范(每分钟约40个字,切忌不宜太快了,否则培训结束后听众还一头雾水,那你此次培训肯定完了)
      7、 利用自己的特长,结合听众的实际临场发挥
      8、 经验分享(自己成长的过程及历史)
      9、 引用一些名人及名事来引起听众的认同
      10、 在说话与发表自己的观点时,保持中立及多角度的来分析看待
      11、 说话不要过于主观,更不能武断的下定义
      12、 换位思考,多站在听众的角度上考虑他们的承受力

      三、如何规避一些不良习惯
      1、讲师常犯的口误例:
      你我他
      你们/我们
      据我所知
      “知足”与“满足”
      2、讲师常犯的举措
      手指指点点
      站立不端正
      3、讲师一些不良习惯
      例:尾音/噢之类
      这个吗
      一句重复的说
      不乱模仿他人的种种习惯

      四、如何与听众现场互动
      原则:先要求自己用心讲课,发自内心的来参与,目的是让听众主动参与
      1、 培训过程中善于穿插幽默、笑话
      2、 用一些名人、名事作案例来引起听众的共鸣

      五、完善培训教材,为下一次培训补充新的血液
      原则:在于及时与坚持
      1、 在讲课时有些不完善的地方要及时加以补充(当时和课后补充)
      2、 采用填表的方式对听众做一个培训内容及讲师讲课技巧的跟进调查
      3、 培训之后与一些听众进行交流 (有则改之、无则加勉)
      4、 培训之后要回忆自己讲课时的情景,从中找出优缺点,再进一步的完善培训教材及培训方式

    从哪儿跌倒,再从哪儿爬起

    不能被同一个石头绊倒两次

    期盼下次培训不会很糟糕


     

  • 测试工程师职业规划流程图

    huior 发布于 2008-03-19 14:33:41

    51testing本周问题:测试工程师如何规划自己的职业生涯?

    http://bbs.51testing.com/thread-108644-1-1.html

    我用一个流程图的形式来表达我的观点,请参考。

    注:1 每个阶段需要的时间因人而异

          2 每个阶段需要的知识因不同的行业不同的平台而异

  • 初创公司测试部门:如何加强测试管理,提高测试地位?

    sunlight426 发布于 2015-08-07 14:49:55

    一封邮件引发我的思考:测试人员测试完成版本后,建议上生产,同时发邮件要求开发经理进行把关。开发经理给出的回复:难道是我一句话能够决定是否上生产么,上生产的依据不是测试结果吗?

     

             这封邮件有点点**味,开发说得没错,同时也有很多问题值得我们探讨。

    作为一个初创公司,经常会遇到生产上的重大问题,而此时就特别需要开发老大们出马解决,长此以往,公司对开发的依赖越来越强。

    而测试呢,没有测试流程管理,上到生产的版本也出现很多的未发现问题,项目经理经常流露出对测试的不满,大有演变成生产的遗留问题都是测试人员的问题之势。而测试人员中有一位测试技术高手,对测试管理、测试技术都有一套很清晰的理论思路,并且这些理论和技术在很多大公司实践过。但是到了这里水土不服,公司没人给出特别的支持和理解。虽然公司领导对该测试牛人多次给出肯定,但是仍然改变不了测试没有地位这个现实问题。

     

             思考之后,我们的现状如下:

    1、  公司领导非常依赖开发,生产紧急问题都需要开发解决,否则损失巨大。

    2、  测试没有很好的管理思路。测试人员在这种无规范的测试中,按照自己的想法进行测试,一盘散沙。没有形成好的测试方法和测试思路,甚至基本没有测试文档,测试工作无法评估。

    3、  领导虽然肯定这个测试牛人,但是对整个测试部门没有太多肯定。

    4、  测试牛人有很好的管理思路和测试方法论,但是实践过程遇到太多阻力,包括领导的高度认同、测试内部同事的认同和开发的包容。

     

    这些问题出现后,作为测试管理者,应该深入的思考,寻找改变之路。我个人提出如下几点建议,希望能够为我们的测试支招。

    1、  我们要改变,要练内功,我们需要时间和空间。不要相信立即能够见效。给自己一个时间表,但是要严格执行。给我们自己犯错的空间,但是要尽量让犯错的几率减到最少。

    2、  测试内部的管理者要精诚团结,可以提出不同的解决问题的思路,但是矛头要一致,就是要完善我们的队伍,排除私心,一起努力。

    3、  改变测试人员的思路。不断培训,通过会议或沟通结果尽可能统一测试人员的思想。定制一些测试流程。由于日常工作也占用不少时间,测试流程可以从简单到复杂,例如从最初编写测试报告à增加本次测试场景开始à再增加测试需求分析à增加测试用例à增加不同测试类型等,不断完善测试流程,不断实践,让测试人员的思路逐渐清晰起来,同时积累测试成果库。

    4、  理清现有功能,建立一支测试设计队伍,搭建测试框架,理清测试测试需求,同时指导测试人员版本测试过程中进行测试设计。

    5、  收集生产问题,并记录解决方法,为我们的测试库增加校验的场景,且作为每次版本测试必须回归的内容,绝不允许重复出现。针对生产经常出现的配置问题,要求编写部署文档,整理部署要求,避免这些问题。

    6、  尽量有技巧地让领导和开发能够明白我们测试的目的,了解测试的原则和立场。尤其是出现冲突时,能够抱着合作的态度互相包容,一起努力解决问题。

     

    我们的队伍不缺测试牛人,这些我相信都能够做好,要改变的是意识,是管理者的思路。当然,做这些的目的主要是,将生产上出现问题的可能性降到最低,进而把我们产品的质量提高,建立起有效的测试管理机制和测试框架,测试人员也能在这个不断完善的流程中提升自身测试的技能。生产上没有问题,公司的损失才会降低,测试才能提升自身的地位,才能得到大家的认可和尊重。

  • 测试人员的思想理念和工作方法

    51Xiaolin 发布于 2012-03-28 13:16:57Top 3 Digest 1

        软件测试的前提假设

      测试人员进行软件测试的基本假设是“有罪推断” ,即认为被测程序一定是有bug的,而且每个功能点的实现都存在bug,而且一定存在严重的bug。 请牢记这个假设 ,一旦在日后的工作过程中产生了这样的认识:“这个功能很简单,肯定不会出现问题,就不再测试了。”或者“这个功能上一轮刚测试过,当时就没有问题,这一 轮应该也不会有问题,就不用测试了。”等等诸如此类的意识,那么 你就有90%的概率导致漏测 ,造成线上问题。其原因也正是这个测试工作的基本前提假设,一旦被违背就从开端导致了测试工作存在问题,所以真正出现问题的可能性也就很大了。 正因为软件测试的这个前提假设,在导致了如果我们同开发人员看待程序的角度和出发点完全不同。因为,通常情况下一个有自信心的开发人员不会认为自己写的代 码全部都有问题,他一定是认为自己的代码没有问题了才交付测试的。因此,如果要从事软件测试工作,那么就必须牢记并运用该假设。 这个前提假设要求我们在实施测试的过程中不能放过任何一个细小问题。比如,某个程序运行时在控制台打印了一些错误信息,但是实际上该程序的运行和功能都没 有问题,如果我们摒弃有罪推断的假设,从合理实现的角度去分析,那么就可以认为这是开发人员对于日志打印的输出控制没有做好导致的,属于微不足道的小问 题,不需提出即可。于是,这就使你有90%的可能性错过了发现其编码上的异常分支判断错误导致的重大问题。此类案例更常见与那些小概率问题,即在测试过程 中偶尔出现,但确实很难、甚至无法复现的问题,如果我们同样摒弃有罪推断的假设,这些问题也会从我们手边溜走,跑到线上由用户发现。相信诸如此类的教训在 每一个测试人员那里都不是少数。 所以, 请转变思维,牢记这个假设 。

      测试工作的开展思路

      从需求出发

      无论什么样的软件产品,其设计开发的目的必然是为了满足一定的需求,这种需求或者是用户提出的,或者是某个关联系统提出的。因此,软件产品最终是为了 交付给用户使用的,也因此可以满足需求是对于软件产品质量的基本保证,其它如扩展性、维护性等等其实也算是更为广义的需求。 所以,我们开展软件测试工作必须从需求出发。首先要全面了解需求,包括其背景、关联性、用户特点等;其次要深入挖掘隐含的需求和关联,包括某个需求隐含了 对于系统现有功能的修改等等。 我们只有在全面、深入了解需求的基础上,才能设计全面、有效的测试用例来进行测试,以满足对于软件产品满足需求的基本质量保证。

      测试依据是测试设计

      我们进行测试设计的依据是对于软件产品需求的全面和深入分析,但是需求决不全是软件测试的依据。因为我们不仅要验证需求,而且要验证设计。比如程序实 现的异常(指针越界、字符串copy越界等等)判断,是保证软件产品可以正常运行的必要实现,但是我们在需求中是无法描述和分析出来的。 那么进行测试的依据是软件产品的设计或者是代码吗?当然也不是,因为如果依据开发人员的设计或代码来进行测试的话,设计或代码正确,但是不符合需求逻辑的 错误就无法发现。而且,如果依据设计或代码进行测试的话,那么也就违背了我们进行软件测试的基本假设——有罪推断。 所以,我们进行软件测试的依据应该是我们根据对需求的全面深入分析和对设计实现的了解,两相综合产生的测试设计。 正因为如此,测试是否充分和有效的根源也是测试设计。所以,我们的工作重点也是测试用例设计。

      测试人员只是验证质量

      首先要明确的是测试人员无法保证软件产品的质量,软件产品的质量是通过参与软件过程的各方联合共同保证的。 有两个原因:一、由于软件测试人员不是产品设计人员和开发人员,所以无法做到比他们更了解产品需求和产品设计,如果他们都无法保证需求和设计没有问题,那 么测试人员就更无法保证了;二、软件测试位于软件开发生命周期的末端,如果依靠测试人员来发现所有的bug来保证质量的话,那么风险就会后置,导致问题修 复的成本增加,同时也增加了修复问题带来新问题的风险,因为在项目末端是不可能投入过多的成本来进行那怕接近全面覆盖的测试的。 也正因为如此,我们是无法决定一个软件产品质量的好坏的,只有PM设计出产品需求,RD编码完成,我们才能够通过我们的工作,促进PM、RD改进他们的产 品、系统,从而达到产品、系统的高质量。 所以,我们才要参与需求评审和设计评审,大家一起努力,各个阶段由专业化的人员来保证阶段的质量,将问题尽量在前期发现。而测试人员只能根据前期分析的结 果,设计出测试用例,来验证软件产品在事先设计或后续补充的测试用例上不存在问题。 但是“测试人员只是验证质量”决不是指我们可以不为产品质量负责。 因为大家(PM、RD、QA、OP等)工作的最终目标是产品质量保证,这个目标是大家共同的目标,所以每个人都必须为这个目标负责。只是由于咱们处于软件 生命周期的最后一个环节,所以目前看起来产品质量都是由我们来负责和把握的,实际上,如果最终发布的软件产品出现了问题,那么无论如何我们肯定是有责任 的。

      测试的内容一定是确定的

      既然软件测试只能验证质量,那么所要验证的内容必然是确定的,或者说是概率确定的。否则也就无从验证了。 因此,模糊不确定的需求我们无法验证,输出结果没有任何规律的程序设计我们也无法验证,这就是软件产品的可测性判断。也因此,我们进行需求评审和设计评审 时是一定要保证这个基本点的。

      测试的目标不是没有bug

      综上所述,进行软件测试的目标不是通过测试使得软件产品不存在bug(这是不可能达成的),而是我们根据确定的需求、确定的设计和确定的测试用例验证 出的结果不存在bug。 同样的,测试人员的目标也不是在测试执行过程中去找bug,而是运用测试思维,使用一定的测试方法,尽可能早地在需求阶段、设计阶段将所有的bug找出 来,真正测试执行阶段只是验证不存在用例所描述的那样的bug,而不是通过用例去发现bug。

      测试人员的工作方法

      通过前文的分析,我么可以总结出测试人员的工作方法是这样的: 首先对需求进行全面深入地分析,接着去分析评审程序设计,假定每个需求的功能点开发人员的实现都是存在问题的,同时也假定每一个程序设计的编码实现(无论 是方式还是代码写作)都是存在问题的,然后根据这些假定设计测试用例,最后执行这些测试用例,验证程序不存在那些问题。 从中不难看出,我们同开发人员同时由需求出发,开发人员产生详细设计和代码,我们产生方案和测试用例,然后开发人员提交被测程序,由测试人员同时运行被测 程序和测试用例,来动态验证程序质量。所以,测试方案和测试用例设计的过程等价于开发人员进行详细设计和代码开发的过程,两相对比可以看出,测试人员最重 要也是最核心的工作就是测试设计。 因此,测试人员的工作可以重点描述成:是一个运用测试的思维和各种测试理论及方法,将所测试的软件产品的每一个功能都改变成一组特定的输入和一组特定的输 出一一确定对应的形式,形成测试用例,然后待开发人员提交测试后,在测试环境部署被测程序,根据测试用例进行主动测试的过程。
  • 转摘一篇关于测试工作量评估的帖子

    yxf 发布于 2011-02-25 17:24:05

    转摘地址:http://bbs.51testing.com/thread-402388-1-1.html

    1.     根据测试范围和测试方法来估计工作量:
      a)制定测试计划以前,明确测试范围:

      不同的测试范围,对测试量的评估起到至关重要的因素,比如说测试一个模块或测试多个模块或测试整个系统等等,都属于测试范围不一样,明显工作量也不同,差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等,在做测试工作量评估的时候,都必须考虑。

      b)确定合理、有效的测试方法:

      比如说你要考虑测试某个项目,你必须考虑测试方法是否合理。比如说某个模块的功能测试,你可以采用QTP做自动化功能测试,还是手工做功能测试,工作量就不一样,做测试计划以前必须考虑清楚。要不然,估算的工作量肯定不准。

      2.     根据测试任务来评估工作量:

      a)质量需求和项目背景决定工作量:

      不同的项目背景,不同的质量要求,决定不同的测试工作量。如果我们测试的是一个银行系统,涉及到每个人的经济利益,我们测试时必然会对性能测试或安全测试放到第一位,设计较多的异常测试用例,这样一做,必然增加我们的工作量。如果是一般的系统,我们可以只执行一般的功能测试通过就可以了,没有必要去做其它的异常、安全测试。如果系统的质量需求要求高,也许就要进行更深层次的测试,回归测试的力度必然要加大,工作量自然就上去了。

      b)尽可能详细的罗列出项目测试内容:

      一般来说,测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量,必须要求测试Leader明确详细的测试内容,只有知道测试什么?哪些需要测试?详细分析需求规格说明书,明确测试任务以后,评估才会有依据,所以

      尽可能详细的罗列出项目测试内容非常必要。

      c)把测试任务细化到每个测试功能点:

      我们在估算测试时间的时候,可以把测试任务细化到每个测试的功能点,比如说“新增”、“修改”、“删除”、“暂停”、“恢复”等等都记成一个功能点,在预算的时候,同时把编写测试用例和执行测试用例的时间都要计算进去。例如:编写一个测试用例或执行一个功能测试各需要一个小时,如果我们有100个功能点,我们就知道大约要200个小时。这样估算出来的时间比较精确一点,比较符合实际。

      d)预估业务测试或模块交叉测试的复杂容易程度:

      很多时候,我们测试初期,对业务了解不是很多,忽视了对业务方面或交叉模块测试的评估,等到了测试后期,大量的业务测试没有测试,测试时间特别紧,所以在测试初期预估测试的复杂容易程度,在评估工作量方面至关重要。

      3.      根据开发阶段来评估工作量:

      不同的开发阶段,测试时间估算也不太相同。比如说,开发的系统是第一个版本,相对以后的测试工作来说,可能安排的时间要多一点。大多数情况下是这样的,也许后面的版本增加很多新功能,测试工作量还大于第一个版本也是常有的事情。作为测试负责人,对于使用测试阶段来评估工作量,必须根据实际情况来定,不能盲目给出数字,应付了事。

    4.     根据测试经验的积累来评估工作量:

      我们可以借鉴类似项目的测试经验,比如说被测试的系统,我们做过类似的产品,就可以把相关的测试文档,修改一下,复用以前的测试用例,这时候测试工作量就减少了很多。如果没有,我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间,对测试工作量的准确评估,也具有一定的参考价值。

      5.     根据测试风险来评估工作量:

      a)测试人员变动带来的风险:

      在一般的软件公司,测试人员的流动是常有的事情,所以估计测试工作量的时候,我们一定要把它计算在里面,留有一定的余地,以防不测。比如说:以前安排了一个做过类似项目,对类似项目熟悉的测试人员,也许给他安排了一天的工作量。如果他不在了,其它的人去做这个测试也许就2天,甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。

      b)系统测试环境的风险:

      系统测试环境带来的风险,一般来说比较小,发生的可能性很小,如果一旦发生了,也相当可怕。最可怕的就是硬件故障,在经济实力允许的情况下,我们一般的方法是准备两套测试环境,一套测试环境出现问题,我们立马切换到另外一个测试环境中去继续测试,避免影响正常的测试进度。但是大部分的公司都不愿意花血本,来购买昂贵的硬件,而是以牺牲时间来付出代价。

      c)、开发人员版本发布延迟风险:

      不做好版本配置管理或没有正规的测试规范的公司,大部分情况下很难估计工作量,他们基本上都是边改边开发边测试,如果一旦开发出现异常,整个测试就立马终止,这对测试的相互制约作用也会更大,这样对我们估算的工作量也不准确。

      d)、项目变更带了的风险:

      一个项目做到中途,由于客户对技术不断深入的了解,很多时候不是“需求变更”,就是“设计变更”,弄得我们测试人员特别郁闷,不断修改测试文档。如果相关部门没有正规的变更管理,变更引起的工作量更没办法估算。很多测试后期出现工作量加大,测试延期的问题,都是对项目风险估算不足造成的。

      6.     发挥项目团队的力量来评估工作量:

      a)积极调动下属,发挥集体的智慧:

      我带领的测试团队,对工作量的估计大致是这样的:

      测试主管对自己带的项目做一个整体时间预估,给出一个大致估计时间。我再把每个模块分配给准备安排测试这个项目的每个测试工程师做一个测试工作量评估,得到结果后和测试主管的工作量对比。这个时候我要考虑他们每个人的实际能力做适当的调整,最后把调整相对准确的时间,递交项目组评审,如果通过,就OK,如果他们有建议,视建议的程度好坏,再决定是否做修改。有空的时候,我会定时检查每个人的工作内容是否准时完成,督促一下工作。一般来说,时间偏差相差不会超过一周,呵呵!!!

      b)建立一个测试工作量的预算表格:

      测试计划书写结束,我一般是把测试工作量的每一项,写成一个Checklist,每项大致多少时间,写出来。邮件的形式发给部门的全体成员,提高工作量的透明度。每天下班结束以前,每个人都要对测试的工作做汇报,包括已经完成的工作或未完成的工作都进行汇报,时间不是很长,就几分钟的时间,测试Leader也要做Review,以防虚报。

     

521/3123>
Open Toolbar