首先来下载和搭建SVN服务器.

现在Subversion已经迁移到apache网站上了,下载地址:

http://subversion.apache.org/packages.html

这是二进制文件包的下载地址,你可在左侧的导航栏找到源代码,文档的下载地址.

windows操作系统下面的二进制文件包一共有5种,如图:

个人认为最好用VisualSVN server 服务端和 TortoiseSVN客户端搭配使用.

点开上面的VisualSVN连接,下载VisualSVN server,如图:

然后下载TortoiseSVN客户端,官网下载地址:http://tortoisesvn.net/downloads.html

注意下载跟你电脑匹配的安装包,在页面的下面你还可以找到语言包,如图:

下载完成后,应该有这些安装包,如图:

 TortoiseSVN安装包和简体中文语言包

VisualSVN server安装包

先安装VisualSVN server的安装包,双击VisualSVN server安装包,如图:

点Next,进入下一步,如图:

点同意,进图下一步,如图:

选择上面一个选项,点Next,进入下一步,如图:

Location是指VisualSVN Server的安装目录,Repositorys是指定你的版本库目录.Server Port指定一个端口,Use secure connection勾山表示使用安全连接,Use Subversion authentication 表示使用Subversion自己的用户认证.点击Next,进入下一步,如图:

点Install,进入下一步,如图:

等待安装完成,如图:

安装完成后,启动VisualSVN Server Manager,如图:

接下来我们安装TortoiseSVN,双击安装包,进入下一步.如图:

点击Next,进入下一步,如图:

选择接受,然后点击Next,进入下一步,如图:

选择安装路径,然后点击Next,进入下一步,如图:

点击Install,开始安装,如图:

等待安装完成,安装完成后如图:

接下来我们安装简体中文语言包,这个非常简单,一路Next就行,就不截图了.语言包安装完成以后在桌面任意空白地方单击鼠标右键,会在右键菜单里找到SVN,如图:

选择设置,进入下一步,如图:

在右边的语言里面选择简体中文,然后点击应用,确定,汉化即完成,如图:

到这里,服务端和客户端都已经安装完毕,下一篇介绍用VisualSVN Server创建版本库,以及TortoiseSVN的使用.

上一篇介绍了VisualSVN Server和TortoiseSVN的下载,安装,汉化.这篇介绍一下如何使用VisualSVN Server建立版本库,以及TortoiseSVN的使用.

首先打开VisualSVN Server Manager,如图:

可以在窗口的右边看到版本库的一些信息,比如状态,日志,用户认证,版本库等.要建立版本库,需要右键单击左边窗口的Repositores,如图:

在弹出的右键菜单中选择Create New Repository或者新建->Repository,进入下一步:

输入版本库名称,勾上Create default structure复选框(推荐这么做).点击OK,版本库就创建好了,版本库中会默认建立trunk,branches,tags三个文件夹,如图:

这时候我们将项目导入到版本库中,找到你的项目文件夹,在项目文件夹上点击鼠标右键,找到SVN菜单,选择导入,如图:

在弹出的对话框中填上版本库URL,这个URL可以从VisualSVN Server Manager中获取,在你的版本库上单击右键,选择Copy URL to Clipboard,这样就把版本库URL复制到你的剪贴版了.如图:

将复制的版本库URL粘贴上,在URL后面加上trunk子路径.然后在导入信息里面填上导入信息"导入项目到版本库".如图:

点击确定,所选中的项目就会被导入到版本库中.如图:

项目导入到版本库以后,不能随便让谁都能够读写版本库,所以需要建立用户组和用户.

在VisualSVN Server Manager窗口的左侧右键单击用户组,选择Create User或者新建->User,如图:

在弹出的对话框中填写User name和Password,然后点击OK,如图:

用相同的方式分别创建用户Develpoer1,Develpoer2,Develpoer3,Test1,Test2,Manger六个用户,分别代表3个开发人员,两个测试人员和一个项目经理,如图:

然后我们建立用户组,在VisualSVN Server Manager窗口的左侧右键单击用户组,选择Create Group或者新建->Group,如图:

在弹出窗口中填写Group name为Developers,然后点Add按钮,在弹出的窗口中选择三个Developer,加入到这个组,然后点Ok,如图:

用相同的方式创建组Managers,Testers,如图:

接下来我们给用户组设置权限,在MyRepository上单击右键,选择属性,如图:

在弹出的对话框中,选择Security选项卡,点击Add按钮,选中Developers,Managers,Testers三个组,然后添加进来,给Developers,Managers权限设置为Read/Write,Tester权限设置为Read Only,如图:

到此,服务端就完成了.

接下来,我们用客户端去检出代码,在桌面空白处单击右键,选择SVN检出,在弹出的对话框中填写版本库URL(具体获取方式,上面讲上传项目到版本库的时候讲过),选择检出目录,点击确定.如图:

开始检出项目,如图:

检出完成之后,我们打开工作副本文件夹,会看到所有文件和文件夹都有一个绿色的√.如图:

至此,创建版本库和使用TortoiseSVN导入项目,检出项目已经介绍完毕.

下一篇介绍TortoiseSVN的使用,以及冲突解决办法.

　　在写完了《让QTP走下神坛》之后，现在来谈谈测试管理工具，献给所有正在或打算做测试管理工作的同行。

　　当然，话题离不了Quality Center——但又不只是谈QC，我会结合对比各种主流的企业级测试管理工具，包括标题提到的：HP QC/ALM、IBM RQM、51Testing TP、Micro Focus SCTM、Atlassian Jira。但是不会提及Bugzilla、Bugfree、Mantis这些，因为它们只能属于缺陷管理工具，和以上几款工具不在一个级别上。

　　当然，得先从QC说起。

　　既然提及Quality Center，就得先谈Mercury，而既然提及Mercury，就得先谈HP。毕竟是大环境的衰败造就了QC的没落，难道不是吗？

　　（一）因此，先说HP。

　　HP原来有三大业务：PSG、IPG、EB，分别是个人电脑，打印和影像设备，企业级业务（软件服务）。PC业务利润微薄，压力大，HP早已江河日下；打印机扫描仪随着iPad等设备出现，早已经疲态尽显；HP倒一直想模仿IBM转型服务，号称要打造“Service Anywhere（一切皆服务）”，但从QTP、LoadRunner和Quality Center多年以来除了更换了华丽的界面，新增了零星半点的小特性，越来越耗资源，越来越不稳定，甚至继续保留着一堆N年以前的Bug，……，管中窥豹，可知其所谓的服务越来越流于表面了。

　　据说今年HP对外宣称自己做组织架构调整，变为PPS（打印）、EG（企业集团）、ES（企业服务）和HP Software（软件），我对HP内部不太熟，不过在我看来换汤不换药。它们在历史上架构不知道调整了多少次，用业内人的说法是“总是在用一个错误纠正另一个错误”。

　　（二）再说Mercury和Quality Center。

　　HP在2006年7月以45亿美元收购了Mercury公司。而在此之前，Mercury是专注与软件测试工具研发的专业厂商，曾几何时在测试工具这块与Rational、Segue号称“测试三巨头”。它们推出的每一款产品都堪称划时代：测试管理工具TestDirector、性能测试工具LoadRunner、功能测试自动化工具WinRunner/QuickTest，分别迅速占领了全球70%左右的市场，时至今日，仍然威震江湖。

　　QC为什么能有很强大的用户基础，其实不是因为QC的强大，归根结底，是TD当年打下大片江山，占尽了用户基础。我是从TD(TestDirector 7.2)开始用的，十年前当我第一次看到TestDirector真的是“亮瞎了眼”！世界上居然有这么Cool的测试管理工具！亮点在哪里？

　　TD的安装相当简单，几乎是傻瓜式操作，“下一步”、“下一步”、……、“完成”。连数据库都删繁就简的采用Access，安装的便捷，怎一个爽字了得！

　　而且基本不太消耗内存资源，使用起来一点都不卡。

　　2、强大的易用性。

　　TD的设计思路简单清晰，整个过程就是：写测试需求–》写测试用例–》执行测试用例–》提交缺陷、跟踪缺陷。总共只有四件事，而且完全符合Testers的日常工作流程。在当时同类竞争对手几乎只有缺陷管理工具Mantis、Bugfree、Bugzilla、ClearQuest，论强大论易用性都明显被拉开了一大截——绝对领先优势！

　　3、放号策略。

　　大家应该都还记得著名的TD License吧？有人称之为“Sale Policy”。什么意思呢？就是当初Mercury推出TD 7.6的时候，网上立刻有人出来发布TD 7.2的License；当Mercury推出8.0的时候，网上立刻有人出来发布TD 7.6的License；当HP Mercury推出Quality Center 8.2的时候，网上立刻有人出来发布TD 8.0的License……

　　呵呵，就这么巧合，至于为什么会这样，明眼人一看就知。现在明白什么叫“Sale Policy”了吗？我先让你用旧版的，等你用上了以后，数据都在上面了，然后我推新版的，诱惑你用，……，一步步让你深陷其中，当你有一天发现你已经离不开我的时候，我对你实行收费……WOW！pfpf，果然厉害！所以，一代又一代的Test Manager前赴后继，大力推行TD。51Testing软件测试网%t Vm%}'p！i+_

　　但是你们看，现在HP ALM还有吗？我毫不怀疑，没有继续延续之前的战略方针，ALM确实正在不断失守城池。《2012年测试从业人员调查报告》可以清晰看到，下面会有详细描述。

　（三）嫁对男人是女人一生的事业。

　　悲剧就在这里，自从HP收购了Mercury，内部发生了大动乱，HP素以抠门闻名，收购了Mercury研发团队后，很多人的薪资被砍掉了三分之二！于是整个团队分崩离析……

　　这也是为什么大家总感觉当初使用Mercury工具的时候那样心潮澎湃，现在每每看到HP的升级版却诸多失望多于期望。因为最核心的高层、架构师和专家早已离开了HP Mercury团队。

　　所以，你们都看到了，……，就像QTP的新版本UFT一样，加了什么PDF验证、类增强、支持移动设备……，都有啥用啊？！你内核没有改变啊，大侠。。。一一大帮子人做了一整年就加了这么一点东西，还好意思拿出来说啊？！

　　QC也莫过于此。

　　（四）关于“改名”的乐趣。

　　从频繁改名就可以知道HP的无能——没有本事升级内核，只能改改花哨的界面，加一点噱头，再换个名字，看看都有啥名字吧。

　　测试管理工具：TestDirectoràQuality CenteràALM

　　自动化测试：Astra QuickTestàQuickTest ProfessionalàUFT

　　HP肯定会说：你不了解名字背后的意义，好吧，我替你们来说：TD升级为QC的本意是从测试整合为质量中心，把QTP捆绑进来，QC改名为ALM就是希望它不再只是针对测试或质量的管理平台，而是一个完整的软件生命周期管理平台。

　　我想问一句：累不累啊？真以为改了名字以后用户就收获了什么好处吗？我倒觉得反而增加了用户的认知成本、使用成本，最终反而伤害了自己的品牌。

　　（五）没落是一个不争的事实。

　　好吧，废话不说，下图是我们针对国内测试从业人员做的问卷调查。你可以看到QC正在市场上节节败退，按正常估计，明年一定跌破四成——极有可能被Atlassian Jira取代霸主地位。

　　看到了吗？QC从昔日的一股独大，变成了今天群雄并争。最明显的就是Jira，从2009年的14%上升为24%！！猛增10个百分点哦！这风头在自动化那边也是同样，Selenium从2009年的4%上升为12%。

　　为什么？很多原因。且听我细细道来。为了更好的说明，我以和它体量相当的大型测试管理平台比如Micro Focus SCTM(Silk Central Test Manager)、51Testing TestPlatform、IBM RQM来跟它做个简单对比——为什么不拿Atlassian Jira对比？因为Jira现在虽然也在朝着“全生命周期管理”的方向靠，也有需求管理、错误跟踪这些模块，但是走的路数和QC不太一样（设计思路不太一样，Jira走的是敏捷&项目管理模式），而且对测试需求和测试用例没有提供直接的方式进行管理（可以和别的工具集成），不好对比。当然后面还是会提及。

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

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

相关文章：

让Quality Center走下神坛--测试管理工具大PK（中）

　1、莫名其妙的架构设计。

　　前面提到过TestDirector的架构设计，完全走轻快的路子，B/S架构，基于Windows 2000平台，安装IIS4.0即可，数据库可以是Access/Sybase/SQL Server6.5,7.0,2000/Oracle7,8,9这些，内存只需要128M，CPU只要PentiumⅡ足矣。

　　但是到了QC的时候，莫名其妙的变成了Java EE架构，号称可以安装在Windows、Linux、Solaris等系统上，Web服务器可以是Apache、IIS，应用服务器可以是JBOSS、WebLogic、WebSphere，一个比一个复杂，一个比一个强大，……，架构师对外宣称QC可以更好的支持企业级用户，支持高并发……

　　到了QC 11.5(ALM 11.5)的时候，官方的建议配置变成了Windows 2008 sp2 64bit + JBOSS 5.1 + SQLServer 2008 sp1，最低配置也得是Windows 2003 sp2 + (IIS 6) + JBoss 5.1 + SQL Server 2005 sp3，而硬件方面的最低配置更让人咂舌——最低内存8 GB！硬盘最少8GB！而且连客户端的内存最低配置都必须是2GB！

　　各位都明白了吗？这也是为什么越来越多的用户抛弃了HP Quality Center的原因，内存要求短短几年之间翻了62.5倍！！惊人吧！！！

　　看到这里我狂汗啊！要知道，微软Windows 2000这么庞大的系统，不过动用了1700个开发，3200个测试，世界上有几个微软这种巨量级的软件研发公司？难道他们的架构师没有读过《长尾理论》？事实上，大部分的公司测试开发比本来就很低，真正考虑到实时并发的话，能做到一两百并发读写已经很好了，而且就像Infosys、Tata这样的航空母舰级的外包服务公司，也没有必要整个公司只用一个QC啊——再者说了，就算出于企业级管理的需要，这样的公司能有几家，为这些大公司定制化一个不就行了吗？真正要考虑的是广大的受众群体所在的企业规模和研发团队规模啊！兄弟，这只是一个内部研发管理系统！对内的系统决定了对性能的要求不可能像对外开放的大型系统那么高，既不是12306，也不是天猫，更不是谷歌/百度首页，设计这样的架构，我想问一句：有那必要吗？图啥呢？

　　假如还觉得不够的话，那么我们对比看看现在也非常流行的TestLink——一款可以和Jira、Bugzill、Mantis集成的测试过程管理工具。它的架构非常的简单：WAMP/LAMP，也就是Windows/Linux + Apache + PHP + MySQL。因为现在有大量的一键集成安装包（如WAMP Server、XAMPP），所以安装过程极其简单方便。正是因为TestLink的便捷性，这几年使用的用户比例也在攀升，而且别忘了，它可以集成很多主流的缺陷管理工具哦！

　　2、复杂繁琐的安装和登录、惊人的资源消耗。

　　QC的服务器端姑且不提，看看其复杂而坑爹的客户端——其实还是架构设计的问题。

　　相信很多朋友都见过下图的这个页面吧？

　　假如你真的经常使用Quality Center的话，一定对这个页面再熟悉不过，相信大家都有同感，这个页面往往需要下载非常的久，运气不好的话得下载5-10分钟，而且还经常下载到最后了打不开！！这时还得检查有没有关闭UAC(User Account Control)、DEP(Data Extension Prevention)等等，这种BT的架构设计真的让人不可思议了：这明明是B/S架构的系统，为啥需要下载安装这么多ActiveX？这不是挂羊头卖狗肉，打着B/S的旗帜，行C/S之事吗？与其这么麻烦，还不如你就做成C/S算了！

　　当然，它还真有客户端，而且官方推荐你使用，叫：QC Explorer。说白了，就是专门为打开QC开发的一款基于IE内核的浏览器。唉，真的无语了，放着那么多流行的JavaScript. Framework Libraries不用，偏要用ActiveX这种落伍又笨拙的东西。这还不要紧，关键是这样一来，对你的浏览器就会非常的挑剔！请看这段官方描述（针对QC客户端的浏览器要求）：Microsoft Internet Explorer 7 or 8。就是说你的客户端只能用微软的IE浏览器，而且必须是IE 7或者IE 8这个版本，不能用微软的IE 6或IE 9（一定要用高版本的IE还得到jboss\server\default\deploy目录下修改20qcbin.war里的内容），不能用Chrome、Firefox，更别提什么Opera、Safari之流了。还有更让人崩溃的，就是除了浏览器之外，你的系统上还必须要安装：Microsoft .NET Framework 3.5 (SP1)、Visual C++ 2005 SP1 ATL Security Update Redistributable、Microsoft Office 2007 (SP2)等一系列东西，你说有多烦有多烦！！！

　　相比之下，真的建议他们（HP QC的架构师）去学习一下Jira和Micro Focus SCTM，全部是用JavaScript类库实现，真正意义上的纯B/S架构，所以所有的浏览器都可以轻松访问，无需额外安装其他ActiveX！

　　纯B/S架构带来的好处还有很多，包括友好的用户体验，以及无缝切入移动互联网（手机访问），这些后面会单独列出来提及。

　这里还没说它的服务器端的安装呢！假如你曾装过Quality Center的服务器端，十有八九遇到过“数据库连接属性不正确”的问题，一般原因是数据库那边还得再做正确的配置，具体得看是SQL Server还是Oracle，各有各的招，这里就不多说了。

　　总而言之一堆的问题要注意要设置好，还记得当年我写的那篇《关于"The RPC server is unavailable"的探讨及解决方案》吗？这个也是其中之一。

　　再来说资源消耗。其实从上面的“最低配置要求8GB内存”大家就可以大致看出QC有多吃内存了。这么说吧，我们51Testing的讲师都最怕上QC这门课，不是因为这门课很难，而是很痛苦，每次从虚拟机里启动出来至少15分钟，中间还有很多操作也非常的卡。PS：我用的笔记本是HP ProBook 4230s，CPU是i3-2310M 2.10GHz，内存8GB，也是如此。

　　3、过于简化的需求管理模块。

　　QC的需求管理严格意义上不属于真正意义上“开发需求的管理”，而是指针对测试需求的管理，并且可以结合Release模块设定简单的基线，不过如果你用过CaliberRM这种专业级的需求管理工具，就会发现QC的Requirements实在是弱爆了！

　　Micro Focus SCTM就不一样了，它支持项目级的需求基线，而且可以直接切进CaliberRM（这是亮点），这才是真正意义的需求全生命周期管理。

　　当然假如你的SRS是word文档，QC倒也可以把开发需求导入进去，但是问题是QC的word插件非常非常难用，导入的工作量一点都不比你自己手工输入来的快（因为需要针对每一个需求项去打begin和end标记）！！所以通常我们在企业实战中只能采用折中的方式，先把SRS转为Excel文档，再通过Excel Addin导入进去，当然导入的过程也不那么轻松，具体可以参考我的《ALM(Quality Center) Excel Addin深入剖析》，链接是：

　　http：//wenku.baidu.com/view/04a20cee998fcc22bcd10d81.html

　　4、不伦不类的test plan——关于“测试计划”和“测试用例”的混淆。

　　从TD以来一直到后来的QC、ALM，Quality Center一直把test plan认为是test cases——从这里很容易看出来，设计这款工具的人是做开发出身的，不懂测试，呵呵。

　　测试计划是什么？首先测试过程会分为计划、设计、实现、执行几个活动（按ISTQB的说法是测试过程分为计划和控制阶段、分析和设计阶段、实现和执行阶段、评估出口准则和报告阶段以及结束收尾阶段），分别解决“做什么”、“如何做”、“具体步骤是什么”、“发现缺陷并跟踪缺陷”、“评估测试报告”这几个问题。

　　《测试计划》，是有国际性的模板的，即IEEE 829。请各位参考维基百科：http：//zh.wikipedia.org/wiki/IEEE_829内容包括明确组织形式（强矩阵、平衡矩阵、弱矩阵），明确测试对象，明确测试的需求跟踪和覆盖，明确测试的“通过/失败”标准，明确测试的挂起标准和恢复条件，明确工作的任务分配，明确项目可交付物。

　　然而，QC里所谓的测试计划（test plan）对于以上这些统统没有涉及，实质上却是编写测试用例的模块，你可以看到用例的目录规划、用例的名称、用例的步骤，还可以看到用例的类型（是手工测试还是自动化测试），……，总而言之，这就是Test Cases。

　　而它的Release模块倒可以理解为粗略的测试计划模块，只是太粗糙了点儿。

　　真正做到了可以沿着IEEE 829的样板编写测试计划的工具目前还没有，不过IBM RQM算是比较接近的，它们可定义做到的是定义测试目标，定义过程，定义每次迭代的进度并对重要的milestone跟踪，可以估计工作量，可以列出测试环境，定义开始和结束的标准，……，总体来说还算不错。

　　还有就是我们51Testing的TP(Test Platform)，也有独立的测试计划管理模块，可以建立多级测试计划，也包含了任务分配、工作量估计、风险管理、测试环境管理和分配等，也能通过度量监控测试的执行进度，质量状况。

　　5、华而不实的Business Components。

　　QC中有个HP自己鼓吹的“业务驱动测试”的概念，叫：Business Components。核心理念是：BPT(Business Process Testing)，业务流程测试。

　　干嘛用呢？简单的说，就是让SME（主题事件专家，也就是“业务专家”）可以借助自身对业务的熟悉通过对系统的熟练操作，让这个Business Components把所有操作记录下来，生成一个自动化脚本，然后通过QTP进行回归测试（只能通过QTP）。实际上如果大家对QTP的Keyword View比较熟悉的话，就能明白是怎么回事了。HP认定做测试的人主要分为两类：一类熟悉测试技术（包括精通编程、数据库，但对业务不甚精熟），一类则熟悉业务（但可能是编程白痴），这两类人都有测试的盲点，通过这个业务设计让两类截然不同的人得以协作。很美好吧？其实也有一点儿TDD的味道（沾边）。

　　SCTM也有个类似的东西叫workbench，基于StoryBoard技术，也不需要编程（Visual Test）。

　　但事实上，很少有公司可以做到清晰的划分这些，往往做测试的必须懂业务，即使你是自动化测试工程师，也得了解业务。所以，……，就黄了，这个组件根本没有办法大面积推广开，在内部被证明失败之后，HP开始转型做 Sprinter——这个东西后面会提，是个神器！不过国内还没有汉化，也几乎没人深入研究，大部分testers还没能体会到它的强大。

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

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

相关文章：

让Quality Center走下神坛--测试管理工具大PK（上）

让Quality Center走下神坛--测试管理工具大PK（下）

　6、测试设计分析的薄弱。

　　QC把自己的架构做的很复杂很“强大”，可遗憾的是，在测试的分析设计上却非常的薄弱，可以说几乎没有——很难想象一个被假设为如此强大的公司居然会没有测试分析？这种感觉就像给一个拖拉机安上了波音747的引擎。

　　关于测试分析：其实业内的大部分测试管理工具往往都是跳过分析这一环直接从测试需求跳到了测试用例设计，而实际上对测试需求分解出来的东西直接进行用例设计的话会造成分解粒度过于粗糙，导致大量测试分析细化的过程无法以可视化的方式体现出来，从而造成漏测。假如你的系统比较复杂，这个过程应该是：从测试需求分解出测试项，测试项分解出测试子项，然后在测试子项中设计测试用例。

　　TP在这块上做的很不错，可以进行继承性分析、质量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用户场景分析等专业性的分析，通过这些系统性的分析我们可以得到高质量的测试项。而且TP把我们测试人员对分析思考的过程记录和管理起来，这样就实现了对分析过程的评审了。

　　所有做测试的人都知道V&V，即Test = Verification + Validation。“测试”本质上就是验证和确认，验证过程的正确性，确认结果的正确性。而TP真正意义上实现了既确认结果，又验证过程。但很遗憾，QC不具备这个功能。

　　而测试设计这块，也就是我们通常提到的等价类划分、边界值分析、判定表、因果图、状态迁移法、场景法（流程分析法）、正交实验法、输出域分析、错误猜测法等各种测试用例设计方法。它们同样在QC中也无法体现，这就意味着我们没有办法评审我们测试设计的过程！而漏了这个过程的评审，那么漏测也是在所难免了！比如我们只考虑了边界值，忽略了两两组合的分析（通过判定表或正交实验），虽然针对需求的覆盖可以达到100%了，但是仍然忽略了一些情况的考虑，那么QC这时是根本“察觉”不出来的。

　　目前市面上的所有测试管理工具中，普遍缺少这块的功能实现，究其原因，我还是认为这些软件的设计者不是一个经验丰富的测试专家（应该只是做开发出身的），所以忽略了这些核心模块的功能实现。

　　目前做到这一点的，只有51Testing的Test Platform这款工具——这里我得自卖自夸一下，周峰（90年代就已经通过国家系统分析员认证），对测试的理解确实是高瞻远瞩，要比很多人都深入、全面。而他所有的考虑都融入到了TP里面，我也衷心希望同行可以借鉴，把这些功能添加到各自的工具模块中，毕竟百花齐放、百家争鸣才是最应该看到的景象。

　　7、忽略白盒测试，缺少代码覆盖率分析。

　　所有熟知测试过程V模型的人都知道，测试活动分为：单元测试、集成测试、系统测试，验收测试，分别验证软件的内部质量、外部质量、使用质量。

　　然而QC似乎并不关心这些。因为QC只实现了测试用例对需求的覆盖关联，却没有办法进行代码级别的覆盖率分析。给人感觉QC更多关注的其实是黑盒层面的测试。

　　而SCTM则进行全面的关注，它也可以关联需求，还可以收集Java/.Net的代码覆盖率，而且可以提供比较报告，让SQA随时掌握代码覆盖率的趋势变化，了解测试用例的充分程度。

　　这样可以更好的帮助项目成员一起来使用这个测试管理平台。

　　顺便说一下，SCTM在单元测试这块应该是所有测试管理工具中做的最好的，可以支持Fitness、JUnit、NUnit、.Net Explorer、Process Executor、Windows Scripting等主流的单元测试/集成测试框架，而QC根本不支持，除非你做二次开发。差的远了！

　　8、最关键的缺陷分析和Report功能。

　　经常有朋友问我QC导出报告的问题，比如怎么把测试用例或缺陷以Excel的方式导出。其实QC的报告导出功能也很弱，特别是在Excel上，而且word的导出一直有Bug，基本上不可定制的，特别是你如果针对前面的Test Plan等模块做过定制化或二次开发，在导出的时候会有各种问题。

　　后来QC整合了Dashboard（其实就是展现各种数据指标的仪表盘），但是这意味着你必须是Enterprise Edition（收费更高昂），而且即使整合了Dashboard，只是在展示上更华丽了，导出的问题还是没解决！而其实“测试报告”才是关键，只要做过项目的兄弟都知道，甲方需要的是漂亮的word报告！

　　而SCTM的报告功能却非常的丰富，它提供了一个专门的报告引擎BIRT，可以定制各种报告，也可以支持项目群报告、Dashboard，而且最重要的是：它们都是免费的！

　　再说度量和缺陷分析，这更是QC的一大软肋！严格意义上来说，QC的那些数据分析离真正的缺陷分析还非常的远！可以说几乎就没有。而51Testing TP在这块上做的非常出众，提供了专业的ODC分析、Gompertz分析、Rayleigh分析、四象限分析、DRE/DRM等工程分析方法，可以对缺陷进行单、多维度分析、进行缺陷趋势分析、对缺陷进行预测等，为测试工作质量评估、测试退出判断、遗留缺陷预测提供支撑。51Testing软件测试网9oz;R+nG(t2w:V]5LL"m

　　一句话：QC弱爆了，TP“碉堡了”！！

　　9、敏捷哪儿去了？

　　敏捷时代，不能不提敏捷。

　　“个体与交互胜过过程与工具”——这是著名的《敏捷宣言》的第一条价值观。不过，有意思的是，工具却成了今天大多数敏捷团队的重要组成部分。

　　做过敏捷的人应该听说过Rally，这家公司是做敏捷项目生命周期管理工具的。其实还有很多，比如VersionOne、Mingle、DotProject、Redmine等。。。

　　很遗憾，QC不提供这些工具的集成工具，也没有技术支持！

　　这块做的最好的应该是Micro Focus SCTM，它提供了配套的集成工具，而且还提供技术支持，因为Micro Focus和这些软件厂商本身就是战略伙伴。

　　当然，Atlassian Jira也是具有敏捷基因的工具，它有个GreenHopper插件，可以通过快速创建User Story来建立一个产品Backlog，可以在整个发布过程中管理Backlog、Sprint，并且监控项目的进度。此外，Jira还有一个名为Bonfire的插件，做敏捷测试管理的，不过我还没有使用过，不敢做太多评论。

　10、移动端的访问。

　　十年前，我就在想这件事情。作为团队的项目经理、测试经理，或公司的老板，日理万机，每天就为了了解项目状况，得扛着笔记本电脑“飞来飞去”，看上去实在大煞风景。更何况，在讲究“碎片化时间利用”的今天，我们在公交上、地铁里，掏出手机访问一下我们的测试管理系统，了解下“张三用例写到哪里了，李四缺陷修复了没有”岂不更加方便、高效？

　　要说敏捷，我觉得这也算一种“敏捷”。

　　QC有移动端APP吗？或是能通过手机浏览器访问吗？道听途说过，却从未曾见。个人觉得很不靠谱，为什么？别忘了前面第2点提到的QC客户端对Windows平台和IE浏览器的依赖，假如我们用的是iPhone、iPad，或者Android设备，那怎么可能访问呢？

　　相比之下，Jira和SCTM就具有这样的先天优势了。为什么呢？别忘了它们都是用JavaScript类库实现的，不需要安装ActiveX，是真正的纯B/S——自然可以通过手机浏览器访问了！

　　事实上，Jira确实有移动端的APP，我刚特地去App Store上搜索了一下，呵呵，见下：

　　而且，连Bugzilla也有移动端的APP了！

　　个人觉得，移动互联网时代，这些测试管理工具也都将面临着新一轮的洗牌，HTML5的支持、CSS3的支持、大量的JavaScript类库……QC还能撑多久，我们拭目以待！

　　11、用户体验哪儿去了？

　　其实TD当初的用户体验还真的挺好的，但是QC的用户体验，唉，不提也罢。

　　庞大的身躯、臃肿的组件、极差的兼容性、缓慢的运行速度、滞后的设计理念、封闭性……其实前面都已经提到过了。

　　用户体验的精髓在于“Don’t make me think”，而QC却是“make me think hard”。

　　12、唯一的亮点：Sprinter，探索性测试（Exploratory Testing）和兼容性测试的头号利器！

　　QC唯一的亮点应该就是从QC 11.0开始推出了Sprinter——一个半自动化测试的集成工具。

　　它既不是QTP，也不是Selenium，而是可以把你手工测试的过程直接记录下来，进行“自动化回归”，比如屏幕捕捉（截图、截视频）、屏幕记录（截图以后可以在上面做标记）、自动数据注入（Data Injection），可以在执行用例的同时直接生成缺陷报告，非常适合做探索式测试。还可以做镜像测试，也就是同时进行多环境的配置测试，是兼容性测试的利器！我亲见过它的强大，确实“亮瞎了眼”！我推荐大家去体验一把，这种针对手工测试的自动化一点都不需要你有编程基础，用起来又快又方便，真的是“谁用谁知道”！

　　只是很可惜，HP没有足够的重视Sprinter，没有把这张王牌打好。因为准确的说，QC是用不了Sprinter的，ALM才能支持Sprinter，这意味这你必须先升级到它们的ALM(QC 11)。这成了它的第十二宗罪！

　　13、离线模式和版本管理。

　　随着GIT的兴起，离线开发和离线Repository将成为一种新兴的需求和开发模式。

　　我们51Testing出去和用户推TP的时候，就遇到有用户提出这样的需求（而我们的TP已经实现了离线模式）。但事实上，QC并没有离线模式，必须始终保持QC Connection，而且消耗你的License！

　　除了51Testing的TP，Micro Focus SCTM也支持离线模式（通过MTC来支持），也可以在你工作完成后提交测试结果。

　　好吧，即使我们不谈离线模式，就说版本管理，QC仍然在同类测试管理工具中处于下游。QC虽然提供了版本管理的功能，但是非常弱，易用性也极差。比如你编写了测试用例，经过评审之后修改了用例，过几天删除了，过几天又想恢复……那么这些通过QC实现是几乎不可能的。

　　在版本管理这块，SCTM(Silk Central Test Manager)就不一样了，它可以支持测试用例的版本化，还可以指定当前测试项目测试用例的活动版本！是不是很强大？！

　　14、相形见绌的扩展性。

　　QC几乎没有任何扩展性！虽然它有一个Add-in Pages，但是基本都没有和业界主流工具集成，上面可以下载的都是诸如QTP Addin、Excel Addin这种东西，实在不值一提。

　　扩展性这块，Jira很不错，不过最强的还是SCTM，还记得前面发过的文章吗？——《你见过的这么强大的开箱即用的测试管理工具吗？》

　　好吧，这里再次描述一次：SCTM号称业界最开放的测试管理平台，需求部分支持CaliberRM、DOORS、RequisitePro、Word，变更管理部分支持StarTeam、Subversion(SVN)、VSS、CVS、PVCS、VSTS，缺陷管理部分支持Atlassian Jira、Bugzilla、IBM ClearQuest、Microsoft VSTS、StarTeam，自动化测试这块支持JUnit、NUnit、Fitness、TestPartner、SilkTest、SilkPerformer、VMWare Lab Manager……据说现在还在增加扩展……不得不赞美一句，牛B！

　　OK，至此，《让Quality Center走下神坛》已经全部打完收工！

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

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

相关文章：

让Quality Center走下神坛--测试管理工具大PK（上）

让Quality Center走下神坛--测试管理工具大PK（中）

　　● 手段：针对需求开展测试设计

　　● 测试设计面临的挑战：

　　1、测试准则不确定（测试是比较预期结果与实际结果的过程，预期结果最了解的人群是开发、需求人员还是客户？答案未知，但是如果需求的质量更高些的话，会更利于更准确的知道预期结果）

　　2、测试无穷尽：要用少的用例覆盖尽可能多的需求，如何挑选合适的用例显得尤其重要

　　3、用例执行pass是否真正代表对应场景或功能就pass =>缺陷隐藏效应证明不一定，那么在挑选用例时如何做到，RBT会有所考虑

　　RBT是如何实现上面所提挑战的？

　　● 为什么要基于需求来开展测试？

　　1、导致软件失败的原因如下：

　　a）需求不完整

　　b）需求多变

　　c）需求缺少来自用户的实际输入

　　从而导致仅有60%~70%的需求交付量，且此其中50%左右的需求未被使用过，而开发团队针对这些未使用过的需求，投入了大量精力，存在一定程度的浪费。

　　2、BUG分析缺陷来自哪个阶段？=>60%来源于需求阶段（怎么有效区分BUG是哪个阶段？）

　　● RBT解决的是偏重型的测试问题（考虑项目的可适用性），是针对每条需求进行分析设计

　　● RBT倡导的思维是先测试，再构建

　　● RBT过程两大步：需求模糊度分析、因果图方法进行测试设计

　　1、需求模糊度分析

　　实际是分析需求是可测试的、可观察可触发的、结果是确定的（结果是确定的指：给定输入后，能准确得出其唯一的结果，对于输入A，结果为C，再次输入A，结果为B的情况则是不符合“结果是确定的”原则。当出现这种情况，则需求是肯定有问题的）

　　2、因果图方法进行测试设计，以下是几类设计方法的对比分析

　　a）根据用户实际使用场景、环境参数来设计用例的情况：30%左右的覆盖不乐观，且异常考虑不充分，依赖时间的场景无法覆盖

　　b）依据直觉进行设计的情况：依赖测试者经验，覆盖不确定，只能代表执行过的是OK，不能证明其完整覆盖度

　　c）组合测试设计的情况：所有场景组合全部覆盖，量太大

　　d）因果图方法设计的情况：借鉴了硬件领域的一些工程算法，覆盖率高

　　● RBT方法选择用例的标准：

　　1、体现变量间的各种逻辑关系

　　2、体现每个变量各种状态间的约束

　　3、考虑各节点的可观察性，如下面的例子

　　例子：

　　A、B、D、E全为T，C、F、G均为True，假定当A恒为False的缺陷存在时，直接通过对G的观察是无法发现此缺陷的，因为C、F是不可观察的

　　4、需测试哪些功能块

　● RBT过程12步骤（12步记录不全）

　　1、分析为什么要做这个需求？（如同敏捷测试中要求一样，即：需求来自于哪里？用户是什么样的群体？基于什么原因提出这样的需求？要解决什么样的问题？有无其它可替代方案来解决？是否一定要做这样的需求？

　　2、用场景分析方法来分析需求的应用情况

　　3、进行模糊度分析，即：识别不清晰、不完整、疑惑点的地方（此点更期望是不了解需求的人来做，而非专家）

　　4、领域专家进行更深层次的审视

　　5、针对需求建模，理出所有业务逻辑，采用因果图方法

　　6、用工具检查逻辑不一致问题，可能是需求本身的问题，也可能是建模的问题

　　7、工具自动生成用例（此处的用例可以理解为是测试验证点，而非具体的测试数据）

　　8、确认生成的用例是否正确（此处有一个个人问题：既然自动生成的用例已经是很精简了，再进行评审怎么保证评审出的问题是否需要补充到用例的？=>答案：评审的目的一是确认是否正确理解了规则与需求，二是通过评审问题反向识别出需求遗漏的场景（如果可能，要求客户对需求进行review是最合适的）

　　9、设计编码阶段，用生成的用例进行验证

　　● RBT工具用途（记录了一些，不全）

　　1、自动生成测试用例

　　2、自动生成两张表单：因与果清单、规则VS用例覆盖率的对照表（“X”表示多个用例覆盖此规则，“#”表示1个用例覆盖此规则）

　　3、生成测试统计数据

　　4、自动反向生成较规范的需求文档，适用场景：a、review需求时发现的问题确认后，不会更新需求，通过自动生成更新得到全集；b、敏捷项目中适用，项目结束后形成需求与用例的匹配

　　5、生成用例过程中自动进行功能逻辑一致性校验，并给出提示，如同开发程序编译时的错误提示

　　6、维护过程会考虑对原有用例的最大程度复用

　　7、告诉你可优先执行哪些用例

　　8、支持快速设计（推荐在配置测试中使用，如移动领域测试环境支持验证，可生成基础用例）

　　9、可定义节点间的状态、约束，以便生成的用例是可执行或真实的组合，对于不可执行的用例前面会有“I”标识，点击后会显示原因

　　“ 需求分析”不代表“用户要求什么就是什么”也不代表“我们能做什么就做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上 自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的 分析。

　　一般可以从三个方面去考虑：

　　1、功能需求--产品应该完成哪些功能，即向用户提供的功能，一般来说这个都是比较硬性的标准；

　　2、非功能性需求--用户可能不能明确告诉你的一些需求，比如说性能达到什么要求，可靠性方面，响应时间，扩展性，性能方面等，这块的内容并不 是说用户需要，而是说不知道需要做成什么样的，我们不能不做，做了只会对自己受益。要不然等到后期用户使用感觉这慢，那不爽，那倒霉的还是是自己；

　　3、限制条件--在需求分析中需要考虑一些条件约束，规则等，比如客户的约束，行业的约束，法律的约束以及自己的约束等，这些都需要在需求分析考虑清楚，要不然做出一款白人狂殴黑人的游戏给黑人玩，那就惨了……

　　测试需求分析的步骤

　　1 、 熟悉需求背景及商业目标：

　　a) 了解清楚项目发起的原因，是为了解决用户的什么问题。

　　b) 当前的解决方案是不是最优的，为什么会这样做？

　　2 、业务模型法：

　　a) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。

　　b) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

　　3 、业务场景法：

　　a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注）

　　b) 考虑系统内部各个用例之间的交互，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。

　　4 、功能分解法

　　a). 业务功能：与用户实际业务直接相关的功能 或细节。

　　b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。

　　c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

　　d). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。

　　e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

　　f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。

　　g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。

　　Test Director：是Mercury Interactive 公司推出的基于WEB 的测试管理工具，在本文档中我们简称为TD。

　　其中包括的内容有：

　　1、需求定义（Specify Requirements）：

　　分析应用程序并确定测试需求。

　　2、测试计划（Plan Tests）：

　　基于测试需求，建立测试计划。

　　3、测试执行（Execute Tests）：

　　创建测试集（Test Set）并执行测试。

　　4、缺陷跟踪（Track Defects）：

　　报告程序中产生的缺陷并跟踪缺陷修复的全过程。

　　TD的缺陷跟踪功能

　　1、公司部署的TD访问地址：

　　http：//td.teacher.it/tdbin/start_a.htm；也可以从http：//dev.teacher.it/中访问.

　　2、用户名及密码设置：

　　用户名为姓名的字母全拼，

　　如：姓名：李翠霞，用户名为：licuixia，

　　初始密码为空，用户登录后在TOOLS中修改密码。

　　3、项目选择：teacher-1

　　可参考下面的图片：

　　项目的未来充满风险。风险是一种不确定的事件或条件，一旦发生，会对至少一个项目目标造成影响，如范围、进度、成本和质量。风险可能有一种或多种起因，一旦发生可能有一项或多项影响。风险的起因包括可能引起消极或积极结果的需求、假设条件、制约因素或某种状况。

　　项目风险管理包括风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程。项目风险管理的目标在于提高项目积极事件的概率和影响，降低项目消极事件的概率和影响。对于已识别出的风险，需要分析其发生概率和影响程度，并进行优先级排序，优先处理高概率和高影响风险。

　　风险识别

　　风险识别是系统化地识别已知的和可预测的风险，才能提前采取措施，尽可能避免这些风险的发生，最重要的是量化不确定性的程度和每个风险可能造成损失的程度。

　　问题1：风险可分为哪些类型？

　　建议：

　　1、需求风险，如需求变更频繁、缺少有效的需求变更管理。

　　2、计划风险，如实际规模比估算规模大很多、项目交付时间提前但没有调整项目计划。

　　3、人员风险，如项目新员工较多、骨干员工不稳定。

　　4、环境风险，如设备未及时到位、新开发工具学习时间较长、环境未及时到位。

　　5、产品风险，如新产品、新技术、基础版本质量不高。

　　6、客户风险，如客户问题确认时间过长、客户不能保证投入需求评审。

　　7、组织和管理风险，如低效的项目团队结构降低生产率、缺乏必要的规范，导致工作失误与重复工作。

　　8、过程风险，如前期质量保证活动执行不到位，导致后期的返工工作量过大、需求方案确认时间过长。

　　问题2：风险识别有哪些方法？

　　建议：

　　1、头脑风暴：组织测试组成员识别可能出现的风险；

　　2、访谈：找内部或外部资深专家访谈；

　　3、风险检查列表：对照表的每一项进行判断，逐个检查风险。

　　风险评估

　　风险评估是对已识别风险的影响和可能性大小的分析过程。从经验来看，许多最终导致项目失败、延期、客户投诉的风险，都是从不起眼的小风险开始，由于这些小风险长时间得不到重视和解决，最终严重的影响到项目交付。

　　关键词：软件测试；单元测试；测试文档；

　　一、引言

　　软件测试作为软件开发的一个重要阶段，除了必须具备被测软件、测试工具、测试技术等一些必备的客观条件外，还受到测试人员、组织管理、测试策略等相关主观性较强的因素的影响。这些因素的综合作用——本文称之为软件的“测试软环境”，决定了软件测试的成败。

　　二、软件测试软环境的构成要素

　　1、测试人员

　　测试人员是软件测试的执行者，他们的素质将直接影响到软件测试的成败。软件测试是一项严谨的工作，一名优秀的软件测试工程师应具备以下的素质：

　 　（1）沟通能力。测试者必须能够与测试涉及的所有人员（包括技术人员和非技术人员）进行沟通。由于人本身具有排他性，因此，当你试图从别人的程序中寻找 错误或缺陷时，往往会遭到反对或对抗。测试者应尽量避免冲突和发生矛盾，要对每个人具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的 冲突和对抗降低到最低程度。

　　（2）技术能力。由于开发人员对不懂技术的通常持一种不屑或轻视的态度，因此，一旦测试小组的某个成员作出 了一个错误的判断，将直接导致他甚至整个测试小组的可信度降低，相反，则会大大增强测试人员的信心和测试工作的说服力。一个优秀的测试人员必须既明白被测 软件系统的概念，又要熟悉并会使用相关的工具，而要做到这一点需要有几年的编程经验，只有通过这样的经验积累才会对软件的开发有更加深刻的了解。

　　（3）耐心。软件测试是一项非常烦琐的工作，很容易使人变得懒散，甚至烦躁不安。作为一个测试人员，你必须要有足够的耐心和自律能力，有时你需要花费惊人的时间去识别、排除一个故障，有些看似毫无成就的工作，往往就在你的苦思冥想后豁然开朗。

　　（4）兴趣和自信心。测试者应对自己所从事的工作具有浓厚的兴趣，对自己的观点有足够的自信，如果具备了这两点，那么在开发过程中，不管遇到什么样的困难，都能克服。

　　（5）怀疑与探索精神。一个软件从开发到投入使用通常要经历许多的循环往复，难免出现这样或那样的错误和缺陷，测试人员应具有叛逆心理，敢于怀疑，勇于探索，在可能的条件下，充分发挥自己的潜能，创造性地开展工作，力求寻找出软件中存在的故障。

　　（6）其它方面的素质。具有良好的判断能力，有一定的幽默感，逻辑思维敏捷等等。

　　2、组织与管理

　　（1）测试小组

　 　由于软件故障的产生主要来源于软件需求分析、设计和编码阶段，因此，需求分析、软件设计和程序编码等各个阶段所得到的文档资料，包括需求规格说明书、设 计规格说明书以及源程序都是软件测试的对象，而由此产生的测试组织与管理也是分阶段的，测试小组的人员组成方式也是不一样的。

　　需求分析阶段。这一阶段的测试人员应包括：用户、项目经理、系统分析员、软件设计、开发以及测试人员。他们需要进行多次讨论和协商来确定软件的功能，以此作为评价需求规格说明书的依据。

　　软件设计阶段。人员组成应包括：系统分析员、软件设计人员、测试负责人以及用户。这一阶段的主要工作是按照需求分析规格说明书的要求对系统结构的合理性以及过程处理的正确性进行审查，用户的作用在这一阶段不是非常突出。

　　软件测试阶段。软件测试作为保障软件质量的一个重要的手段，通常包含以下一些测试：单元测试、集成测试、确认测试、系统测试和验证测试。其中，单元测试由编程小组内部的编程人员交叉进行，其它测试工作则要由测试组来完成，此时，测试组成员的组成应包括：测试经理、测试技术人员、软件开发人员、相关技术支持人员以及用户。需要注意的是，在单元测试阶段，要严格杜绝编程人员测试自己编写的程序。

（2）测试管理

　　测试工作的管理，尤其是对于包含多个子系统的大型软件系统，其测试工作涉及大量的人力和物力，有效的测试管理是保证有效测试工作的必要前提。

　　首先，软件测试的有效实施需要测试组织与开发组织充分配合。虽然测试活动看似是对开发人员劳动成果的不断“挑剔”，但测试工作的出发点是：确保 开发人员的劳动成果成为可被接收的、更高品质的软件产品。测试经理应在组织协调各组织工作方面发挥作用，并和他们一起工作，甚至对公司以外的个人和组织都 是如此。测试经理在工作中所要处理的人员关系可用图1表示。此外，测试经理所处的职位要求他能提交日常主要工作的有关信息，如状态报告、测试计划、评估报 告等，同时，还要根据当前的状态做出一些重大决策，这些决策可能会对整个测试过程产生一定的影响。

图1 测试经理的人际关系角色

　　其次，为确保软件测试在软件质量保证中发挥应有的作用，建立和完善软件测试管理体系是十分必要的。从软件工程的角度出发，软件测试管理所涉及的管理对象包含以下几个方面：

　　● 测试资源。包括对人员分配、工作环境、相关设施等的管理。

　　● 测试计划。根据资源配备情况，制定总体测试计划，确定各个阶段的测试目标和策略。

　　● 分析与设计。测试分析与设计就是确定测试目标并且如何以一种高效执行的方式组织测试的过程。这个过程需要根据测试计划选择合适的测试方案，设计出好的测试用例。

　　● 测试实施。测试实施是指测试人员根据测试计划，利用测试资源来运行测试用例以获得测试数据、开发测试规程的过程。这个过程涉及到测试环境的设置、测试数据的收集以及测试验证等具体的工作。

　　● 测试管理。测试管理作用于测试的各个阶段，其管理的对象包括测试组织的建立、测试过程的控制、测试计划和测试规程的制订与管理等等。

　　三、测试软环境的构建

　　1、测试人员

　　在一个测试小组中，并不是所有的测试人员都需要具有同样的技能，由于分工不同，他们所起的作用也不同。一般情况下，测试小组中测试人员的构成一般包括：

　　开发人员。最好的情况是：让开发人员去做单元测试，如果需要的话还可以让他们做集成测试。

　　用户。通常在测试阶段会给测试提供很好的帮助。

　　技术支持人员。熟悉软件产品的流程，与用户有更多的沟通，往往更能理解用户的想法。

　　QA人员。他们了解产品质量的重要性，对测试小组的工作是一个很好的补充。

　　技术文员。这是测试工作中必不可少的一个角色。由于工作的需要，他们关注测试过程中的很多细节问题，并按照要求完成相关的技术文档的编制，使得整个测试工作都有据可查。

　2、测试组织

　　由于软件的规模大小不一，软件测试的方法也比较多，因此，测试组织的构成形式也多种多样。表l列出了各种测试组织的一些优缺点。测试组织如何进行内部构造和设置职位，这在很大程度上取决于政策、企业文化、质量标准、成员的技术和知识水平，以及产品的风险。

表1 各种测试组织的优点和缺点

　　3、工作环境

　　对许多测试人员和管理人员来说，工作环境似乎不是最重要的问题，而且长期以来也没有得到重视，但测试人员所处的工作环境对他们的生产力和工作效果所起的作用是非常重要的。

　　测试人员为了完成他们的工作，需要有特定的基本需求，他们需要有一个自己的办公空间，能够方便地与小组中的其他人员进行交流而不互相干扰，在资源配置许可的情况下可以自由使用各项设施，所有这些条件的满足都会对整个小组的工作效率产生很大的影响。

　　四、测试软环境的优化

　　从测试软环境的构成来看，由于测试人员的主观性较强，测试管理和测试策略的灵活性较大，因此这几个方面都可以作为软环境优化的出发点，以提高软件测试的效率。

　　1、测试小组的优化

　　挑选合适的人员来从事适当的工作，这是每一个管理者都必须面临的挑战。事实上，由于很少有大学会设立软件测试方面的 课程，因此，要在很短的时间里寻找到合适的软件测试员是非常困难的。通常情况下，优秀的软件测试人员都是经过长期的经验积累后由开发人员转变而来。另外， 确定测试小组的其他人员也是要考虑的一个重要方面。

　　技能培训作为测试人员提高自身素质的重要手段，对整个测试工作的实施能够起到事半功倍的作用。在确定了测试小组的组 成人员后，管理者有责任、有必要对他们进行相关的技能培训。这种培训包括：专业技能、业务知识、交流能力等。培训的方式可以采用指导、内部培训、由相关培 训机构实地培训等多种形式。

　2、测试管理的优化

　　前面已经提到，对测试过程的有效控制是测试工作顺利进行的基础，而对测试工作的有效管理则是提高测试效率的有力保障。

　　（1）测试规范化

　　软件测试是一项相当烦琐的工作，必须加以规范，避免随意性。测试文档的编写就是测试工作规范化的一个重要组成部分。软件测试文档通常分为两类， 测试计划和测试分析报告。测试计划用来指导一个测试过程，包括测试的目的、内容、策略、进度等，而测试报告则对测试的结果进行分析说明，指出软件所具有的 功能以及存在的缺陷。通常情况下，软件测试文档规定了进行软件测试所必须具备的条件，这些条件作为测试资源必须在测试进行之前落实。

　　（2）管理制度化

　　测试管理是整个软件产品质量保证的一个重要组成部分，管理的制度化是保证有效测试工作的必要前提。由于测试工作长期以来没有受到足够的重视，几 乎没有可供参考的、已实现的、完整的测试管理方面的资料。通常情况下，可以将管理工程的一些基本原理用于测试工作中，根据测试过程的进展情况，吸收其他组 织或行业的先进经验，对整个测试工作进行计划和管理，使得一些行之有效的方法和机制逐渐制度化，进一步规范整个测试过程。

　　五、小结

　　长期以来，由于软件测试在软件开发中没有得到足够的重视，使得可遵循的测试规范尤其是测试管理方面的知识及相关资料非常缺乏，本文所提到的测试 软环境及其构成要素在很多软件开发方面的书籍中有所提及，而在一些专门讲述软件测试的书中往往更多地注重讲解各种测试策略和测试方法。而忽略了组织与管 理，随着人们对软件开发过程的认识逐渐加深，软件测试也越来越得到了应有的重视。

　　该问题是讨论紧急和严重程度的理解，但在面试的时候我们很容易直观想到紧急程度跟时间有关系，严重程度跟功能重要性有关系。这个不能说错，但这个理解未免太过于表面进而得分不高。

　　有人说：紧急不严重的会挑一些在临近上线的时候突然冒出一个文字错误、体验不佳的BUG，因为时机不巧所以紧急。

　　有人说：严重不紧急的会挑一些某功能很少有人使用即出现了BUG，因为其特性所以不紧急了。

　　对于这类答案，我有一个明显的疑问：难道在测试的初期我们就没有了紧急而不严重的BUG了，难道在常用功能里面我们就没有严重而不紧急的问题了？如果突破了这两个前提条件而符合要求的BUG，我认为才是一个高质量的BUG。这是我发表该问题看法的前置条件。

　　我更倾向于如下答案（用户登陆为例）：

　　紧急而不严重：

　　因为登陆验证码无法显示，导致用户无法登陆进而影响所有人登入系统进行测试。

　　解析：就该问题而言，解决该问题的迫切程度远高于讨论问题的严重程度且验证码的问题算不上严重。对于开发来说，可能只需要动几处代码就行。对于需求方来说就算阉割该功能也没事。

　　严重而不紧急：

　　输入任何密码均能登陆系统

　　解析：该缺陷属于登陆的核心功能异常，登陆等于被废。毫无疑问为严重，但对测试影响并不大，仍然可以登陆系统进行系统功能测试。

　　登陆功能毕竟属于最常用来举例的程序同时又是极少出问题的模块，若举非软件测试经典案例效果将会更好。再另举一例（通用型）

　　紧急而不严重：

　　某流程因其中一个节点使用无法通过，不能流转至下一个环节。

　　解析：该缺陷在所有流程类测试中均可认为是紧急缺陷，严重程序视情况而定即首先咱们迫切希望问题解决、其次再去争论缺陷严重等级。

　　严重而不紧急：

　　某流程如手机充值交易，充值完成后发现手机到账金额为充值金额的2倍，即充值100元，实际到账200元。

　　解析：直接提BUG，但不影响后续测试。

　　有人也许要反对了，以上的严重问题同样也很紧急。那怎么判断是否紧急呢，假设负责处理该BUG的开发因病休假或者结婚休假了，我们对于严重BUG能够忍受几天，说明并不那么紧急。如果半刻也不能忍受，那必是绝对紧急、相对不严重。

　　再有一条相对要求：所有严重、紧急的BUG均需在上线前修复完成；能够容忍到上线后的BUG全部为不严重同时不紧急的BUG。

　　如果问100个软件公司的CEO，问他们是否愿意发布含有bug的软件。他们会说什么？50个根本不愿意回答，会说一些软件bug是这个行业中一个需要解决的大问题等不着边的话；40个会说“当然不会！”，并立即给他们的投资者打电话说这是诬陷，会追究法律责任。9位会低着头说“无能为力”。而这最后一位会直盯着你的眼睛说“当然会。”

　　我不知道这最后一位是如何领导一个软件公司的，因为他明显学过经济学。

　　软件不可能没有bug，如果你希望发布一个完美的软件，你必须解决藏在代码里的所有bug。（想把它们挡在门外？不可能，单元测试，敏捷方法，scrum，以及任何当今你能想到的方法论，都不能防止bug进入你的代码库。如果我错了，我相信你会在评论里告诉我。）

　　正如你期望的，你在修补bug中投入越多的时间和资金，你就能解决越多的bug。但是，不幸的是，我们的来自经济学的死对头，受益递减法则，同样适用于这个过程。专业的讲，这个法则指在投入生产要素后，每单位生产要素所能提供的产量增加发生递减的现象。用通俗的话讲，这就是说，你能从这个过程中得到的并不等同于你所有投入的。相反，你的产出会随着投入到增加形成一条迅速下降的曲线，曲线的末端、投入到轴线上，最终成为一条长尾。

　　举个例子，假如一个程序有100个bug，我们知道这需要投入100分的努力来找到并修复这所有100个bug。受益递减法则告诉我们，头40分努力将会找到70个bug，而接下来的30分努力能找到20个bug，剩下的30分努力能找到最后的10个bug。这就是说，头70个bug（很简单的bug）很便宜，容易找到，算起来每个bug只消耗40/70=0.571分努力。接下来的20个bug（藏的较深的bug）要昂贵的多，每个消耗30/20=1.5分努力，而最后的10个bug（真正难发现的bug）惊人的昂贵，每个消耗30/10=3分努力。消灭这最后的10个bug要比消灭起初的70个bug，每个bug需要投入的时间或资金要多出5倍。从付出的努力看，消灭大多数bug（70%-90%）和消灭所有bug，它们的成本有巨大差别，从数字上看相差两倍之多。

　　而在现实中，实际情况比这更糟糕。因为你不知道何时能干掉这最后一个bug---没有一个像上面例子那样的倒计数——你不得不不断的去寻找更多的bug，即使是它们已经全部被干掉了，你也要去证明它们确是全部被干掉了。如果你想消灭所有的bug，你还要计算你的成本。

　　所以，消灭一个程序中所有的bug是一件代价很大的事。不妨让我们花一分钟这样思考一下：一个软件公司最终决定要这么做。软件公司并没有设定像“发布没有bug的软件”的目标——他们设定的目标是“11月19号发布”——于是，这个目标改变了公司的测试计划和开发计划（不论有没有计划），这必然意味着的预算的增加。现在，你想象一下，谁会为这多出的预算买单？公司？（嗨！）如果你没有在软件公司工作过，让我来给你一点提示：非也。软件公司会把成本转嫁到客户身上。因此可以得出，你喜欢的软件都是你支付的起的软件。我得到的消息是：你喜欢有bug的软件。（开源软件也是如此。除非你愿意花更多的钱或等更长的时间。很有可能你会接受去忍受次等的软件事实。）

　　现在澄清一下，我并不是说软件公司应该发布有大量严重bug的软件。我是说他们的软件里可以有少量的小bug。

　　如何知道一个bug是大还是小？你应该思考谁会遇到它，当遇到时会发生什么样的坏情况。如果一个用户，进入第三层菜单，打开一个高级配置窗口，选中三个复选框，在敲击“A”键时得到了一个奇怪的错误信息，这是小bug。它埋的很深，当碰到它时人们会说“靠”，然后改为点击按钮，然后就会愉快的做其它事情去了。如果在使用你的程序中一个常用的操作时崩溃，那这就是个大bug。大部分人遇到这样的bug时都会愤怒不已。

　　所以，我要提出一个判断你的软件何时满足发布条件的黄金法则。这个黄金法则内容是，你应该不断的测试并修复软件中的bug，直到发现这些bug是：

　　不会让你的公司蒙羞。

　　不会激怒你的客户。

　　相比起让一些用户遇到这些并不在于的bug的代价，你的要找出程序中所有bug并确保全部纠正的做法代价实在太高。前提条件是，不要让用户做你的测试员——如果你这样做，必定会跟黄金法则冲突——宁愿相信所有的bug并非生来平等，有些能影响一个产品的发布，而另一些则不然。不要害怕发布的产品中有bug。如果你开发的是人们想要的好软件，一些bug的存在并不会打搅他们，尤其是当软件升级操作简便时，比如通过SaaS或Web应用。

　　如果你的软件测试符合黄金法则，那么，你的客户最迫切得到的是你的软件，而不是希望你去修改那些小bug。所以，准备发布吧！

　　哦，别忘了去问那最后一个CEO关于炒股的技巧。经济学家的公文包里总有最好的数据。

　　测试过程中如何区分什么是功能bug，什么是需求bug，什么是设计bug？

　　精彩答案：

　　会员 土土的豆豆：

　　本期问题其实主要是针对不同方面或纬度上对于bug的一个归类和定位。

　　个人认为，从软件开发测试生命周期上分析的话，三者从开发测试阶段应该是需求bug、设计bug、功能bug。（这里仅针对提问排比）

　　需求问题可以包括设计问题和功能问题，当然还有非功能性缺陷等。

　　需求bug，简而言之就是对于业务需求不清晰或者理解有偏差产生的问题。可能包括业务分析人员不专业因素、开发与测试人员思维不一致、产品未满足客户实际需求（想法）等一系列bug。

　　功能问题大部分理应该是附属于需求说明书上的功能模块，因为开发、设计、实现等原因故而产生功能bug。但也不仅限于需求上列举出的功能，因为一个项目/产品，完全有可能因为相关协作的功能模块或整合的第三方程序导致产生bug。所以功能bug既可能是需求bug，也可能是需求外的bug。这里对于bug的优先级和安全级别等不作赘述。

　　设计问题可以认为是开发架构师/人员在项目设计编码前遗留的“历史”问题。因为设计bug还是根据需求说明书来进行开发设计，故而一些业务逻辑上的关系、代码算法的优化、数据库/表的关联等都属于设计bug。

　　个人认为，需求bug最为麻烦，也是后期维护成本最高的bug。设计bug次之，因为一个产品/项目设计层面问题较多的话，无论修复或改进多少，在代码编写结束后，开发人员很难重头再整理一套框架，即便目前没有设计bug，以后产生的风险也是很大的。

　　功能bug最平凡，但是也是基础。除去客户业务需求上的变更因素，整个项目/产品的质量好坏最基本的就是取决于功能是否按需求进行了实现，其问题是否很多。我们大部分测试阶段的bug以功能问题为主。

　　当然还有其他一些bug类型，本期问题所列3个bug从根本上分析不属于一个维度。但是也是很基本的概念。

　　以上是我个人拙见，请大家补充指正。谢谢！

　　会员 TesterChen：

　　首先什么是需求Bug、设计Bug、功能bug？

　　需求Bug，指由于客户需求描述不清晰或错误、需求收集人员自身原因及需求本身模糊难于分析、获取等原因，导致客户需求获取不准确，后期产品不能满足客户、用户的要求

　　设计Bug，是指产品在最初设计时由于未考虑全面，而使产品在使用中存在的一些潜在的缺陷。

　　功能Bug，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

　　建议从以下几点进行区分：

　　1、产生的时间不相同：
　　需求Bug：产生于项目前期
　　设计Bug：产生于项目前期或中期
　　功能Bug：产生于项目中期或后期

　　2、产生的原因不相同：
　　需求Bug：客户需求描述不清晰或错误、需求收集人员不够专业、需求本身模糊难于分析、获取等原因
　　设计Bug：系统框架、通讯模式、库表设计、编写语言等选择不当，导致后期扩展棘手、安全性低等
　　功能Bug：开发工程师需求理解错误、代码编写缺陷等原因

　　3、造成的影响不相同：
　　需求Bug：对整个项目的影响极大，会直接拖后项目的进度、加大项目成本、降低客户对公司的评价
　　设计Bug：后期功能扩展、性能、安全性等可能会遭到威胁
　　功能Bug：影响用户使用体验、影响数据、资金安全

　　4、处理方式不相同
　　需求Bug：重新收集需求，重新设计和开发（需求Bug是对项目成本和进度影响最大的因素）
　　设计Bug：重大缺陷必须修复，小设计缺陷在下一次发布时更新（一般难于修复或修复成本较大）
　　功能Bug：直接修复缺陷，重新发布或更新

　　5、Bug的直接责任人不相同
　　需求Bug：业务人员、需求专员、项目经理等
　　设计Bug：架构工程师、数据库工程师、技术经理、项目经理等
　　功能Bug：开发、测试工程师

　　原帖地址：http://bbs.51testing.com/thread-820993-1-1.html

版权声明：本文由会员土土的豆豆、TesterChen首发于51Testing软件测试论坛每周一问活动。

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

　　简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无反应。

　　2、软件在使用上感觉不方便

　　只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面也凸显了这些软件公司的集成能力不足。

　　3、软件的结构未做良好规划

　　这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分散，容易出现缺陷。

　　4、提供的功能不充分

　　这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角度进行思考，这就是所谓的“从用户体验出发”。

　　5、与软件操作者的互动不良

　　一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。

　　6、使用性能不佳

　　被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需要加以注意！

　　7、为做好错误处理

　　软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！

　　8、边界错误

　　缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情况下是由于开发人员在声明变量或使用边界范围时不小心引起的。

　　下面是一个典型的缓冲区溢出的边界错误：

　　只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0.

　　10、使用一段时间所产生的错误

　　这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，查找时间自然会变长。这就需要改变解决方案了！

　　11、控制流程的错误

　　控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是软件控制流程不完整导致的错误问题。

　　12、在大数据量压力下所产生的错误

　　程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。

　　13、在不同硬件环境下产生的错误

　　这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处理机制。

　　14、版本控制不良导致的错误

　　出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也出现了偏差。

　　15、软件文档的错误

　　最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UI Spec等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！

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

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

　　1、并不是测试人员发现的每个缺陷都是必须修复的。

　　测试是为了发现程序错误，而不能保证程序没有错误。不管测试计划和执行多么努力，也不是所有缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到后续版本中修复。

　　一般不修复软件缺陷原因如下：

　　没有足够的时间。在任何一个项目中，通常是软件功能较多，而程序设计人员和测试人员较少，并且可能在项目进度中没有为开发和测试留出足够的时间。在实际开发过程中，经常出现客户对软件的完成提出一个最后期限，在此时间点之前，必须按时完成软件。这就导致了时间的有限性和任务紧迫性，在此压力下就有可能忽略一些缺陷。

　　不算真正的缺陷。在某些特殊场合，错误理解、测试错误或设计说明书变更，会使测试人员把一些软件缺陷不作为缺陷来处理。

　　修复的风险太大。这种情况比较常见，软件本身是脆弱而复杂的，修复一个缺陷，常常可能导致其它更严重问题的出现。在紧迫的产品发布进度压力下，修改软件缺陷必须评估其影响程度和风险，以决定是否可修改。

　　2、发现缺陷的数量说明不了软件的质量

　　软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是很正常的事。缺陷的数量大，只能说明测试的方法很好，思路很全面，测试工作卓有成效。但以此来否认软件的质量，还是不具客观性的。

　　如果测试中发现的缺陷，大部分都是提示性错误、文字错误等，或错误的等级很低，而且这些缺陷的修复几乎不会影响到执行指令的部分。但对于软件的基本功能和性能，发现的缺陷很少，通常这样的测试证明了“软件的质量是稳定的”，因而属于良好软件的范畴。这样的软件只要处理好发现的缺陷，基本就可以发行使用了。而进行完整的回归和大规模测试，就是增加软件开发的成本，浪费商机和时间。

　　发过来，如果在测试过程中发现的缺陷较少，但这些缺陷都集中的功能没有实现、性能未达标、经常引起死机或系统崩溃等现象，而且出现几率大，多数用户使用过程中都会发现这样的问题。那这样的软件就不能随便就发布，因为发布风险太大了！

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

　　首先，我们将从缺陷的角度来看看测试尽早介入的表现。缺陷是我们测试人员的最主要输出之一，但是它的一些特征说明了测试尽早介入的必要性。

　　1）缺陷是什么时候引入的

图1 不同阶段缺陷引入的分布

　　2）缺陷在什么时候发现

图2 缺陷发现的阶段

　　3）缺陷的雪崩效应

图3 缺陷的雪崩效应

　　4）缺陷发现与修复的成本放大效应

图4 缺陷发现与修复的成本放大效应

　　图1缺陷是在什么时候引入的，说明大部分的缺陷都是在需求阶段引入的；而图2说明大部分的缺陷却是在系统测试阶段才被发现；图3说明前期阶段存在的缺陷，会随着开发阶段的开展而不断的放大；而图4说明发现和修复缺陷会随着开发阶段的演进而不断的放大。因此，从这些图表和数据中，我们可以看出测试尽早介入的必要性。尽早测试介入，尽早发现缺陷，开展良好的评审活动就是一个非常好的手段。

　　其次，我们从测试计划的角度，看看尽早介入的必要性。我们提倡尽早制定测试计划，其主要的目的是：

　　1）尽早识别测试风险，并采取合适的应对策略。其中风险包括了产品风险与项目风险。

　　（1）产品风险：可以帮助我们更好的分配测试工作量、选择测试技术、确定测试顺序和选择缺陷修复的优先级。

　　（2）项目风险：帮助我们计划和管理测试工作，例如：产品培训或者测试工具培训等。

　　2）尽早估算测试工作量，并以此为基础协调与沟通测试资源，例如：测试仪表、测试人员、测试工具等。

　　3）根据测试资源情况，尽早安排和搭建测试环境。

　　第三，测试人员尽早开展对开发工作产品的学习和研究，有助于测试用例的设计与执行，并更好的开展测试活动和完成测试任务。

　　但是很多时候，开发人员很难理解提交上的缺陷报告，因为发送人并不了解我们需要的是什么，那如何与开发人员沟通以及如何写出一份缺陷报告，在这篇文章，我将教你如何写出一份清晰的缺陷报告能使开发者理解、复现、修复问题，这里下载缺陷报告模板。

　　为什么要发送缺陷报告

　　缺陷报告可以用很多方式来帮助我们的开发者。

　　● 他们能告知我们没有意识到的问题

　　● 他们能发现我们可能还没想到的新特性

　　● 他们能帮助我们感受到客户是如何使用我们的软件，以至于我们可以做的更好

　　没有这些缺陷报告，我们就不知道出错的地方，我们需要它就像你唱歌跳舞时需要有软件的支持一样。

　　什么时候发送缺陷报告

　　● 简单来说就是越快越好，详细来说就是：

　　● 当你看到一个错误消息时就发送错误报告

　　● 当屏幕是空白或者数据缺失就发送报告

　　● 当程序没有出现预期的结果时发送报告

　　● 当程序崩溃、死机、没有响应或者响应很慢时发送报告

　　● 当程序返回错误结果时发送报告

　　● 当你得不到想需要的结果时发送报告

　　● 如果你不清楚怎样做时发送报告

　　● 如果你不喜欢软件做的方式，或者软件老打搅你时，发送错报告

　　● 如果你想在系统中实现一个变通方案时发送报告

　　缺陷报告需要有哪些内容

　　缺陷报告应该包含很多信息，你提供的信息越多效果越好，对于开发者，就像我，提供一个纯文本文件模板给你填充然后邮件发给我，当然也有表格形式的，但是最期待你自己杜撰一份然后发给我。下面是一些必须包括的部分以及如何写好每部分：

　 　标题：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题应该包含错 误消息和消息码，或者是结果的名称以及失败时你正在做的事情。例如：Error 402：访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的上下文信息。

　　差：“程序崩溃”，“报错”，“Bug”

　　好：“从’Kifu’中打印时5C79错误”，“’Kifu honors’报表为空”

　　产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web应用的版本信息通常在页脚。

　　差：“你的应用”

　　好：”Kifu v1.01″

　　软件测试类型分析是进行细化测试用例条件的重要手段之一，通过测试类型的分类，软件测试人员可以将测试条件从不同的维度进行考虑，并发现不同的缺陷类型，从而提高测试的覆盖率。

　　测试类型并不是一个标准，它的定义需要考虑公司内部不同的产品，结合项目开发特点和软件产品的特点，以及测试人员在行业领域的技能和经验的积累。图1是作者提出的测试类型定义需要考虑的几个方面：

图1 测试类型的主要来源

　　测试类型定义需要综合考虑各个方面的输入，包括开发文档定义的需求（包括涉及的一些标准与规范等）、ISO/IEC 9126质量模型、测试经验，以及通过分析在研发阶段发现的缺陷、产品发布之后用户反馈的缺陷分析等，不断分类提炼之后形成可用的测试类型。同时测试类型是一个不断迭代和更新的过程，在测试过程中可以不断改进测试类型。

　　1）需求文档分析

　　首先，测试对象相关的软件工作产品，包括相关的标准与规范等，是定义测试类型需要考虑的最主要来源。也就是说，软件产品的具体特点、实现的功能、面向的客户等是确定测试类型首先需要考虑的。例如：有的软件产品主要关注在用户体验上面，而有的软件产品是安全关键系统，那么它们在定义测试类型的时候是需要首先考虑的。

　　2）ISO/IEC 9126质量模型

　　不同的产品利益相关者，其对软件产品质量的描述和要求是不一样的，而测试人员需要兼顾不同人员对产品质量的要求。因此，仅仅依赖于产品的需求文档，测试人员无法设计有效的测试用例（用户反馈的缺陷就是一个有力的例证）。ISO/IEC 9126质量模型中定义的质量特性，可以为测试人员选择质量特性提供较好的思路，如图2所示。

图2 ISO/IEC 9126质量模型

　　3）测试经验

　　测试人员在行业和软件产品方面的经验也是测试类型定义中的重要输入之一。不同工作经验和行业工作经验的测试人员，在定义和分类测试类型过程中提出各自不同的观点和思路，有助于完善测试类型。

　　4）发布前的缺陷分析

　　测试人员在测试过程中可以发现大量的缺陷，通过分析不同产品、不同阶段发现的缺陷，也有助于测试类型的分类和完善。

　　5）发布后的缺陷分析

　　穷尽测试不可能，因此软件产品发布之后，总是能在用户使用现场发现不同类型的缺陷，通过分析和归类这些缺陷，同样也有助于完善测试类型。

　　很多朋友平时电脑做服务器都是搭建iis服务器，今天我给大家分享几个一键搭建php本地测试工具！，喜欢做网站论坛的朋友为了使自己的站点能够具有独特的个性和良好的用户体验，总会对自己的站点进行一系列的深度调整，方能充分体现网站特色和唯一性，一般的PHP 本地测试环境【PHP 本地测试、本地服务器、网站制作必备工具】

　　Wordpress 够流行了吧，它是一个用 PHP 编写的强大的博客平台。使用它来架设一个博客平 台相关容易，是新手建站比较方便的工具。但是要真正体会 WordPress（以下简称 WP）强 大，插件是不可少的东西。一般来说，我们不可能想试一个插件就把文件通过 FTP 来上传， 然后去自己的网站里试，那样风险大了点。所以我们需要在本地计算机上搭建一个 PHP 平 台。我就把常用的 PHP 本地测试平台都收集一下，给需要的人提供方便。 一般来说，本地的 PHP 平台分为两种，一种是 LAMP，即为 Linux+Apache+MySql+PHP；另一 种是 WAMP，它是 Windows+Apache+MySql+PHP，而前者一般优秀于后者。如果让我们自己来 安装 Apache+MySql+PHP，难度不少，改一堆代码不说，还容易出错。再者考虑到现在大家 大多使用的是 Windows 操作系统，自己又是个 Linux 盲，所以我提供的这些本地测试平台 都是 WAMP，都是集成以上功能的，安装完成即可使用。先大概了解一下吧：

　　1、XAMPP

　　XAMPP 是一款比较强大的本地测试平台，它集成了必须的三个功能，还带有 FileZilla，软 件带有一个控制面板，在里面可以把 Apache、MySql 和 FileZilla 三者注册为系统服务或 者卸载服务，有服务启动的控制按钮，而且在窗口下部还能看到服务的运行信息。虽说面 板是英文的，但清楚易懂。注册为系统服务有个好处就是开机能够自动运行，但是会消耗 一定的系统资源，怎么取舍用户自己来定。安装成功，服务也启动成功后，就可以把浏览 器打开输入 http://localhost/，试试是否成功。在 XAMPP 的网页选项里，有中文支持。

　　2、WampServer

　　它的官方网站没有中文，但是程序支持中文。启动安装程序后，它会提示你请先卸载旧版， 不支持覆盖式的升级，然后一路 NEXT 就能安装成功。它在任务托盘里有个图标，如果服务 启动异常，它就是红色的；如果部分异常，它就变成黄色；如果是一切正常，那么它就变 成了白色。这些不同的颜色警示，你很容易判断当前你的 localhost 能不能打开。它还能 切换在线和离线状态，选项中的文语言项中也有简体中文可选，很不错。

　　WampServer 2.0c [05/05/2008] Includes : – Apache 2.2.8 – MySQL 5.0.51b – PHP 5.2.6 changelog Downloads http://internap.dl.sourceforge.n … /WampServer2.0c.exe

　　3、Vertrigo Server

　　这是一个轻量级的 WAMP 环境，但是你下载它的时候，迅雷自带的安全组件居然说它带有病 毒。经过我 的扫描（ESS3.0）和使用来看，这完全是个误报，所以大家可以放心使用。安 装一路 NEXT 就行，其中 PhpMyAdmin 中居然还有原始密码，是 vertrigo，感觉在本地测试 的话，这种默认没有必要。它带有一个简单的控制面板，运行状态也一目了然。 在它的 localhost 页面中带有常用链接，很方便。

　　4、PHPNow

　　PHPNow 真的很简单，简单到安装程序就是用 RAR 做的一个自解压程序。自释放后快捷方式 也没有，你必须自己找到那个文件存放的文件夹，然后运行 Init.cmd 这个程序来初始化。 初始化过程中提示设置密码，因为是在 CMD 命令行中，只设计了一次密码输入，没有密码 确认项，所以请设置的时候千万小心，不要忘了。它也把式 Apache 和 MySql 注册为服务， 开机自启动。 在程序文件夹中，它也带有控制面板，只不过是 CMD 的，但很好用。 卸载就更容易了，在软件自带的控制面板中卸载服务，然后关把整个文件夹删掉就行。这 么方便，图简便的可以试试。

　　5、PHPStudy 本人推荐使用此款

　　PHPStudy 不一样，它含有 IIS+PHP 和 Apache+PHP，软件推荐设置是后者。在任务托盘里也有图标，可以打开面板来看服务运行状态，也很简洁。打开 localhost，出现的是标准的 PHP 信息界面。

　　6、AppServ

　　程序安装过程中它提示你可以改变默认的 80 端口为服务端口，这样可以避免端口共享产生 的冲突。可有密码设置提示，但是做得比 PHPNow 好多了，软件还可以设置字符集，默认为 UTF-8。虽然软件没有控制面板，但一切操作都在开始菜单中加入了快捷方式，使用当然很方便。软件还带有 MySql 命令行终端。 7. EasyPHP 软件如其名，真的很 EASY！安装一路 NEXT，但是不会把 Apache 和 MySql 加载为服务，所 以每次使用都要手工来启动。软件也带简单的控制面板，其他的没什么要说的了。

　　说了这么多，我想，这些工具应该够你使用的了，找一个你最满意的安装就行了。 PS：如果某些这样的 PHP 相关的服务无法启动，请注意一下你的机器中的 80 端口是否被占 用。一般的程序，如迅雷，BT 软件什么的，即使它们没有在工作，开着也会占用 80 端口。 所以把它们关掉后，启动 PHP 相关的服务后再把这些下载软件什么的打开，就不会有服务 启动不成功这样的问题的。

　　谈每日构建都会连带谈冒烟测试这个词。每日构建不是简单的指每日编译，编译和构建完成后必须对增加的新功能点进行系统测试，对已经测试过的功能点进行冒烟测试。每日构建是微软比较推荐的最佳实践，强调测试的早期介入和持续的版本集成。

　　每日构建和冒烟测试的优点主要有：

　　1、进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差

　　2、及早的发现开发BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量

　　3、由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。

　　4、在项目中宣灌质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题

　　每日构建和冒烟测试也存在一些风险和缺陷，具体主要有：

　　1、给开发人员太大压力，开发每天都在较紧张环境中工作

　　2、需要额外的测试人力资源和每日构建硬件环境的投入

　　3、开发人员不能专注，既要分心去修改BUG，又要开发新的功能点

　　4、对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点

　　5、开发需要投入额外的精力来保证每日构建顺畅

　　适用场景：

　　1、对进度偏差控制和要求很高的项目

　　2、开发检查点和里程碑制定的很细致的项目

　　3、采用增量和迭代开发的项目，快速和敏捷开发的项目

　　每日构建提前需要进行的准备工作：

　　1、对开发进度计划的要求，需要细化出每1-2天的开发进度计划，可以到一个很小的功能点。

　　2、对每日构建测试计划的要求，需要根据开发进度计划来安排冒烟测试和系统测试进度计划。

　　3、需要提前准备好每日构建的环境（每日构建必须是独立的环境）

　　每日构建和冒烟测试工作的实现可以人工来实现，但更多的需要借助些自动化的工具来完成。对于每日构建一般要提前编写好每日够建的脚本，可以借助Ant或NAnt构建工具来完成。每日构建脚本的复杂性跟项目或系统本身复杂性相关，对于简单的只有一个项目的解决方案，可能构建脚本会很简单，而对于较复杂的系统或项目构建脚本将会教复杂。NAnt是一个强大的通过构建脚本自动编译的工具，像我现在的项目在NAnt里面会做如下事情，而这个即使打开解决方案来编译也无法做到。

　　1、调用批文件重新自动生成数据访问层组件

　　2、创建相关的部署需要的cs_client，bs_client，server，service相关目录并拷贝公用文件

　　编写背景：

　　前段时间有不少猎头来电询问是否考虑换工作，我一一回绝；因为在目前公司要完成的目标目前完成了1个，正在进行中1个，剩余1个还没有开始；其中一个猎头问我为什么来这家公司，主要是因为我的老板懂测试这个工种和工作，非常实实在在的支持和重视测试部门。

　　非常感谢今年的绩效考核工作，增加了一项考核指标：生产环境bug修复及时率，让我有机会学习和学会如何用这项指标来驱动开发的工作和检查测试工作成果，感谢我的老板给我的工作指导和好的想法，感谢在工作中时常提醒我做重要事情并给我很多工作建议的mac。

　　今天拿出来和同行分享，希望对大家有帮助。^_^。

　　点子1：生产环境bug的review会议

　　我们有固定的时间每周四上午，花1小时和开发及管理层过生产环境没有处理的P0、P1、P2问题，时间来得及会把P3也过一过；主要让大家知道目前生产环境都有哪些问题，处理进展如何，什么时候能解决，解决这些问题有什么困难。连续开了4周，有一些进步，还需继续引导。

　　点子2：每周过一遍生产环境bug修复及时率数据

　　给大家分享一下上半年的数据，还没有进行更深入的分析。从数据上可以看出测试漏出去不少问题，我在想：为什么会漏出去这些问题？在哪些环节给漏出去的？

　　我们要通过什么方法改善？为什么修复及时率这么低，工作流程中哪个地方有问题？数据因什么原因上升或下降？