发布新日志

  • Pairwise Testing (变量值对测试)

    2009-08-27 10:41:46

    关于测试有一条众所周知的普遍定律就是：没有100％覆盖的测试面。而另一方面的一个不争的事实却是：庞大的测试组合不可避免。举例来说，我曾经测过一个转码软件，该软件支持wmv格式的转码输出，对于wmv格式具体的设置参数包括这么几项：

    codec：wmv-7, wmv-8, wmv-9, wmv-vc1

    frame. size: 128x96, 176x144, 320x240, 352x288, 480x270, 640x480, 720x480, 720x576

    frame. rate: 14.97, 15, 23.97, 25, 29.97

    aspect ratio: 4:3, 16:9

    bitrate mode: 1-pass CBR, 2-pass CBR, 2-pass VBR

    所有的输出变量值的组合是： 4x8x5x2x3=960

    毫无疑问，这是一个比较大的测试覆盖组合，那么是每次测试都一条不落的执行一遍还是可以有其它方式呢？这时候一种称之为pairwise testing的测试方法就派上用场了。

    这种测试方法不是去组合所有“变量值”而是组合所有“变量值对”。目前来说，没有什么软件理论能够论证这种测试方法的可行性，提出这种测试策略是基于如下假设：即大多数的软件缺陷要么是单模式缺陷（注一）要么是双模式缺陷（注二），而“变量值对”测试就是建立了一个同时测试单模式和双模式缺陷的最小子集，不过已记载的一些数据却说明了该方法的实际有效性。如：AT&T在对其基于局域网的邮件系统进行的测试中，应用pairwaise testing得到的 1000条测试用例比其原有的1500条测试用例多抓出20％的缺陷而测试精力却减少了50％。National Institute of Standards and Technology在一项对医疗设备测试所进行的15年追踪中发现，有98％的软件缺陷可以通过“变量值对”测试抓获。而另一项对Mozilla网页浏览器的缺陷分析显示，76％的缺陷可以通过“变量值对”测试抓获。

    那么如何实际运用这种测试方法呢？两个途径。

    第一，James Bach基于allpairs算法写了一个小工具可以用来生成“变量值对”表。这个工具可以从这里下载http://www.satisfice.com/tools.shtml。  这个exe工具用起来也很简单。首先在excel里把所有的变量以及可取值罗列如下：

    codec

    frame. size

    frame. rate

    aspect ratio

    bitrate mode

    wmv-7

    128x96

    14.97

    4:03

    1-pass CBR

    wmv-8

    176x144

    15

    16:09

    2-pass CBR

    wmv-9

    320x240

    23.97

    2-pass VBR

    wmv-vc1

    352x288

    25

    　

    　

    480x270

    29.97

    　

    　

    640x480

    　

    　

    720x480

    　

    　

    720x576

    　

    　

    　

    存为.txt格式，然后将该txt文件（例如input.txt）放在和exe工具同一个目录下，进入命令行运行窗口，在exe工作目录下运行命令allpairs.exe input.txt > output.txt, 回车，你会看到output.txt生成，将里面的内容全部拷贝到excel表格里即可。上面例子得出的结果如下：

    case

    codec

    frame. size

    frame. rate

    aspect ratio

    bitrate mode

    1

    wmv-7

    128x96

    14.97

    4:03

    1-pass CBR

    2

    wmv-8

    128x96

    15

    16:09

    2-pass CBR

    3

    wmv-8

    176x144

    14.97

    4:03

    2-pass VBR

    4

    wmv-7

    176x144

    15

    16:09

    1-pass CBR

    5

    wmv-9 查看(1592) 评论(0) 收藏 分享 管理

  • 简易打造自己的自动构建任务

    2009-08-18 14:01:00

    在没有成熟的构建系统和团队的情况，依靠批处理文件和Windows的任务计划我们可以构造一个简易的自动构建任务。

    环境：
    操作系统 Windows Server 2003 
    代码编译环境 Visual Studio 2005 sp2
    代码管理工具 Subversion
    安装包制作工具Inno Setup 5

    基本思路为：写一个批处理文件执行本地代码更新、编译以及调用Inno脚本制作安装包，将这个批处理文件加到windows server系统的任务计划中（可以设置为每日、每周、或者更长的运行间隔）定期执行。

    批处理如下：（将该批处理文件放在本地源码根目录下）
    echo ======Set realted Dirs and parameters======
    set SVNdir=C:\Program Files\Subversion\bin
    set SourceCodePath=E:\SourceCode
    set Innocomdir=C:\Program Files\Inno Setup 5
    set path=%path%;C:\Program Files\Microsoft Visual Studio 8\VC\bin;
    call vcvars32.bat
    set VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
    set SolutionConfig=release
    set BuildType=/rebuild
    set CommandOption1=update
    set CommandOption2=log

    echo ======Update source code to the latest======
    taskkill /f /im TSVNCache.exe
    call "%SVNdir%\svn.exe" %CommandOption1% %SourceCodePath%
    call "%Workdir%\svn.exe" %CommandOption2% -q %SourceCodePath% >VersionInfo.txt
     
    echo ======Create foler to accomodate build log files======
    md %cd%\AutoBuildLogs

    echo ======Cleanning up log files======
    del /Q %cd%\AutoBuildLogs\timestart.txt
    del /Q %cd%\AutoBuildLogs\timeend.txt
    del /Q %cd%\AutoBuildLogs\CommonBuild.log

    echo ======Processing all build======
    echo %date% %time% > %cd%\AutoBuildLogs\timestart.txt"
    call "%VSINSTALLDIR%\DEVENV.COM" %BuildType% %SolutionConfig% "%SourceCodePath%\Common.sln" /out "%cd%\AutoBuildLogs\CommonBuild.log"
    rem "you can expand any more solutions which are ready to build"
    echo %date% %time% > %cd%\AutoBuildLogs\timeend.txt"

    echo ======Create installer======
    call "%Innocomdir%\compil32" /cc "E:\sourcecode\Build.iss"
    rem "you can apply any other installer tool to perform. installer creation"

    查看(563) 评论(0) 收藏 分享 管理

  • 如何写测试人员的周报(或日报)

    2009-08-17 20:58:06

    众所周知,在职场,总有各式各样的报告要看,要写,而最常规的莫过于周报(或者日报)了.这类报告通常是关于个人的工作情况或者项目的进展情况等.那么作为一名测试人员,该如何写周报呢(若有日报需要,以此类推).

    通常在写一份报告之前考虑这么两个方面会让你的报告更具阅读性,那就是:报告要表达的主题是什么,报告的观众/听众是谁.对于同一个(或者相似的)主题,观众/听众不一样,报告所需要陈述的具体内容通常也是不一样的.

    下面我想从测试员和测试组长(负责人)的角度分别罗列一下测试周报的模式和内容.

    一.　测试员　(tester)
    测试员的周报一般来说是汇报给自己的组长,就我自己的工作经历来说,一般软件公司测试组长兼具项目以及行政两个方面,也就是说一方面主导分配到这个测试小组的测试任务,另一方面也要关注组员的工作绩效以及团队发展等.所以汇报给测试组长的周报就要比较详细的从项目和团队合作方面同时阐述自己一周的工作情况.大概可以包括这个几点:
    １.内容概要罗列以及花费时间列表
    阐述本周自己主要的工作情况,譬如参与了哪几个项目的哪些相关测试,出席了几个公司会议,参加了几个公司内(或外)的相关培训课,阅读了什么工作相关的资料/书籍等,同时(推荐以表格的形式)列出每一项工作(或相关)内容所花费的时间(work hour)
    ２.执行的测试用例数目
    按照项目分别列出,本周执行了多少测试用例,其中pass多少,fail多少,有多少用例被block了不能执行(需要另外列出具体的被block原因,如某个bug或者某项测试资源没有到位),还有多少已分配的测试用例没有完成.这些信息推荐以表格形式给出,参见下面的草图:
       Pass  Fail Blocked   Remaining
      Project A  25  3  2  16
     ......        
    如果执行了ad-hoc或者exploration测试,可以考虑以表格形式列出测试内容.
    ３.提交的bug具体数目
    体现测试人员绩效一个重要的方面是提交的bug数量和质量.所有在这里列出本周里在每个测试项目中你提交的有效bug数,无效bug数(重复的bug,不能复现的bug),验证的bug数(有效修复-fixed,无效修复-reject),这些信息同样推荐以表格形式给出,参见下面的草图:
       Submitted-Valid  Submitted-Duplicated  Submitted-Unreproduciable  Verify-Fixed Verify-Reject 
     Project A  5  2  0  8  3
     ......          
    ４.其它
    任何工作相关的其余内容.譬如你希望多一个测试平台,你需要某本专业书籍等等等等.

    版权声明：本文出自小丫头的51Testing软件测试博客：http://www.51testing.com/?18819

    原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

    二.测试组长
    测试组长的周报通常来说覆盖两个方面,一是项目相关情况,这个内容的目标读者是所有和项目相关的人员(项目经理,产品经理,开发人员,测试人员,发布人员等),另一个方面是关于团队管理方面(有时候会把这一项单独放在一份报告里发给测试经理,毕竟项目相关人员只关注项目的测试进展情况,基本不关心测试团队成员的具体工作内容)
    １.严重问题
    任何阻止测试顺利进行的issue都要在这里醒目列出,同时要注明希望问题得到解决的最后期限,如果知道报告接受者中的谁可以帮助推动解决这个问题,要明确指到该人姓名.
    ２.各个项目测试用例完成情况
    可以用类似于下面的柱状图来表示
    (如有必要,可以给出具体的链接指向测试用例管理库中本轮测试的详细内容和结果)
    ３.各个项目的bug以固定时间为单位(通常周报中就按周来统计)的增减情况
    (统计的bug数量可以是所有优先级/严重程度的bug总和,也可以只取第一第二优先级/严重程度的bug进行统计,因为很多时候,这类bug的数量直接影响产品发布与否,而这个,正是项目相关人员最关心的)
    例见下图
    (如有必要,给出具体链接指向bug管理库中该项目所有bug的详细内容)
    ４.各个项目的bug按照一定类别的百分比统计
    (这个图可以让看报告的人一目了然当前项目中的主要问题存在哪里,是功能上的,还是界面上的,还是通讯上的,还是其它等等等等)
    例见下图(具体分类根据不同产品不同项目而不同)
    ５.(如有必要)测试小组成员的大概工作情况
    可以包括:有多少测试人员参与,每个人在各个项目中花费的时间,有时候也可以列出每个测试员执行了多少测试用例,提交了多少bug,验证了多少bug等信息
    可以参见如下表格:
    ６.任何项目相关的其它杂事


    暂时就想到这么多了,欢迎大家指点意见.

    版权声明：本文出自小丫头的51Testing软件测试博客：http://www.51testing.com/?18819

    原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

    查看(4075) 评论(8) 收藏 分享 管理

  • 如何进行软件的安装卸载测试

    2009-08-14 14:16:17

    根据自己所在项目的实际情况并参考了网上一些资料，整理了下面关于如何进行安装卸载测试的概要。（我自己的主要指责包括：做安装包，准备测试用例，组织搭建测试环境并进行测试）

     

    准备阶段：

    1．  确定测试平台操作系统 （Windows XP SP3, Windows Vista Ultimate SP2, Windows Server 2003, Windows Server 2008…..）

    2．  确定测试平台硬件条件 (主板、内存、显卡、硬盘、光驱…..)

    3．  根据以上两项配置出具体的测试平台分布表 （例子见图一）

    图一：

    4．  准备安装文件检查表 （负责做安装包的小组应该可以提供这个检查表，类似于下图二）

    图二：

    5．  确定软件安装流程图（在测试开始之前准备这个流程图可以参考软件以前版本的安装流程，同时咨询做安装包的小组得到最新的更新情况，等到正式的测试版本拿到手可以再微调这个流程图，例子见图三）

    图三：

    6．  第三方工具：注册表快照(RegSnap)，卸载工具(Revo Uninstaller)，系统备份工具(Ghost)

    7．  自动化测试工具以及脚本准备 （如果部分或者全部测试是自动化进行，准备好测试工具以及测试脚本）

    8．  准备需要预装的第三方软件（譬如防火墙、硬盘实时检测、影音播放器等）。

    9．  根据图一进行机器配置、系统安装以及备份 （这项工作比较耗时）

    10.  准备好测试用例 （具体测试什么，怎么测试，这个可以参考下面的“测试大纲”部分）

    到这里，基本准备工作就算完成了，如果你是测试负责人，还要从项目管理的角度考虑测试周期，所需人力资源等因素 （可以结合以前的历史数据和目前的人力资源分布以及项目需求，这方面的细节不在本篇讨论）

     

    测试大纲

    （这里只讨论测试的覆盖内容，不关注测试是通过手工还是自动完成。）

    （安装之前和之后进行注册表快照并比对，确定软件安装带来的注册表修改符合预期设定）。

    （任何一次安装完成以后，对比如上图二的安装文件检查表确定是否所有的文件都装在正确的地方）

    （任何一次卸载完成以后，对比如上图二的安装文件检查表确保所有的安装文件已经被移除）

    1．  根据上图三的测试流程图，按照默认设置，完成安装。

    2．  根据上图三的测试流程图，安装过程中，改变每一个用户可以自定义的选项为非默认值，完成安装。

    3．  对于上图三的测试流程图，在每两个步骤之间都进行“取消”操作，确保安装中止的功能正常。

    4．  以不同的用户权限进行安装和卸载测试 （管理员，受限用户）

    5．  安装到不同硬盘格式的分区（FAT16, FAT32, NTFS）

    6．  从不同的路径安装（本地硬盘，网络路径，移动设备，虚拟机）

    7．  安装到不同的目标地（本地硬盘，网络路径，移动设备，虚拟机）

    8．  选择安装目标分区小于软件安装所需要的磁盘空间大小

    9．  选择一个不存在的目录作为软件安装的目标路径

    10．安装过程中机器进入待机、休眠、关机等状态

    11． 安装过程中检测到旧版本 （这个既包括本身的测试软件，也包括任何随着安装包一起安装的第三方软件），确定卸载或者升级功能正常。

    12．从控制面板卸载软件

    13． 通过第三方工具卸载软件

    14． 通过软件自己的卸载程序卸载软件

     

    欢迎任何意见、问题。

     

    查看(1598) 评论(1) 收藏 分享 管理