现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp

发布新日志

  • Mantis解析(二)

    2011-08-19 19:38:33

    (二)Mantis的配置和开发环境

    Mantis的配置其实蛮复杂的,需要自己修改config_inc.php,统计图形那里的配置也不很方便,但是网上都有相应的说明,自己找找就能找到。建议对Mantis配置感兴趣的,都看看doc目录下的administration_guidedevelopers两个文档,自己试验里面的参数和功能,对Mantis的理解能加深不少。当然了,不求甚解的,直接使用问题也不大。

    因为后期做了Mantis的开发,所以使用了Zend Studio,查看函数中的参数来源和在不同的函数之间跳转,跟踪代码也很方便。

    另外还用了UltraEdite-texteditorUltraEdit主要用来在多文件中查找,当然Zend也能实现,但是很多时候未必查找zend工程内的东西。e-texteditor是很方便的代码查看器,简单的修改代码看实现在e-texteditor中即可。

    我进行Mantis修改开发的时候,www目录中有3Mantis目录,一个是Mantis,是正式上线使用的版本;一个是Mantis1,是开发新功能用的,在zend的工程就是Mantis1目录;还有一个就是MantisBT,是原版没有修改过的,当修改参照。

    当一个功能,在Mantis1工程中开发完没有问题了,再在Mantis中进行相应的修改;有问题了,和原版的MantisBT进行对照,很方便的。

    在同期,我还配置了Testlink,后期,增加了dokuwiki,这是另外一个故事了,有时间详细的说说Testlinkdokuwiki中的奥秘。

  • Mantis解析(一)

    2011-08-19 19:37:36

    (一)缺陷管理软件的选择和相关的软件环境

    既然决定用缺陷管理软件,那么就面临一个问题,用哪个缺陷管理软件。

    常见的缺陷管理软件,就是商业的QCTestDirector)、JiraClearQuest,开源的BugzillaMantisBugfree、禅道。

    ClearQuest排除,原因最开始就说了。

    TestDirector排除,第一商业,第二局域网病毒太多,而TestDirector因为构建很容易中病毒,第三至少我很久前用的7.2版的时候,有一些bug

    Jira,我去下载了一个破解版,但是没有安装上,也许安装过程中需要联网和配置邮箱的缘故吧,放弃。

    Bugzilla,有网络的情况下,我都没有信心能一次安装,在断网的条件下,还是放弃吧,而且Bugzillaperl开发的,也和现在的php主流不符,修改等费事。

    剩下的就是MantisBugfree、禅道了,都是php开发的,需要安装配置php环境。

    Php集成软件也很多,选了使用EasyPHP,建议大家不要下最新的EasyPHP-5.2.11版,无法解包。建议大家下载5.2.10版,可以直接解压,不需要安装,参照install_script.iss文档中的内容进行修改和配置,直接可以使用,这样有问题后,直接复制此easyphp目录就可以完成移植。

    EasyPHP有点小bug PhpMyAdmin固定就是80端口,在非80端口使用的时候需要注意一下端口。

    EasyPHP配置启动完毕后,没有问题了,就可以开始安装各个缺陷管理软件了。

    MantisBugfreeZentao官网下载最新的版本,解压到www目录中,按照网上的说明进行相应的安装和配置。

    Bugfree安装后,在首页有错误,去网上找了找,因为php.iniallow_call_time_pass_reference参数的问题,修改后就好了。还有其他的问题,总出现Fatal error,对Bugfree的质量印象不是很好。Bugfree本身支持测试用例管理和缺陷管理,从总体的感觉上,Bugfree简陋且山寨,建议Bugfree重新进行页面的设计,请美工人员进行页面的调整和配色。功能不提,界面上看,绝对是10年前的个人网站效果,没有任何的美工,条目的排列也很嘈杂混乱,后台管理简陋至极,测试人员自己用可以,但是给开发看,绝对不会有什么好的感觉。

    禅道按照Scrum开发方法设计,里面有需求、用例、TODO等内容,软件本身不予评价,但是功能太多了,我想用的仅仅是一个缺陷管理软件,也许按Scrum开发的团队使用禅道更合适。

    剩下的就是Mantis了,单纯的缺陷管理软件,但是可以和其他的软件进行集成,比如测试用例管理软件Testlink

  • Mantis解析-序章

    2011-08-19 19:36:33

    此系列文章,整理后,删改一些内容为《Mantis深入学习》,发表在了《51测试天地》第23期电子杂志上,在这里感谢51testing的编辑。

    序章

    文章的题目比较大,说mantis解析可能过了些,只是说些自己在使用mantis过程中,如何分析和处理mantis源码,以适合自己的需求。

    我原先一直是ClearQuest的支持者,虽然用的是盗版,虽然用的是很老的20022003版。ClearQuest的功能就我感觉在各种缺陷管理软件中定制功能最为强大,而给非测试人员使用的ClearQuest Web客户端却是各种缺陷管理软件中最简易的。ClearQuest的强大定制功能,易于测试人员对缺陷管理流程和字段、页面等进行控制;Web端的易用(屏蔽一切与缺陷管理无关的内容)很利于开发人员的培训和使用。但是ClearQuest也有问题,一是软件安装太大且慢,二是需要使用SQL ServerOracle数据库,三是配置起来过于麻烦,四是导出和备份都脱离了时代。其实我遇到的最大烦恼就是:ClearQuest的移植性不好。因为我换过几次的服务器,都需要很麻烦的步骤才能完成。感兴趣的,可以看看我曾经写过的关于ClearQuest的帖子,就能了解一些相关的内容。

    我从34年前开始,就没有怎么使用过缺陷管理软件了,发现其实txtExcel在小项目上也挺好用的,最多的时候78个测试人员,200多条缺陷,用Excel虽然麻烦些,但是也能很好的管理和记录缺陷。

    但是近期有一个稍大些的项目,3个测试,10个开发,预期千条数量级的缺陷,再用Excel很明显不合适了,所以需要一个缺陷管理软件。因为服务器经常中病毒,所以随时的准备重新安装系统和相关软件,缺陷管理软件最好具有很高的移植性。

    说下我们公司的网络环境,为了安全,我们公司的局域网完全和广域网进行物理隔离,无法上广域网,也无法使用邮箱。但是同事中很多人有笔记本,可以去专门的地方上网,局域网内电脑无法方便的升级操作系统和杀毒软件,笔记本又会从外网带来很多病毒,所以服务器常中病毒也是很正常的事情了。

    上面的内容和技术没有太多的关系,只是简单介绍一下背景,因为下面的内容我的一些做法就和上面的背景和环境相关。

    正式开始了。

  • 测试人员如何给予合理的考核呢?

    2011-07-24 14:37:17

    很老的帖子了,2005年的,在csdn上的讨论,想看讨论的在http://topic.csdn.net/t/20050224/19/3804392.html,下面的只是我自己的看法。

            csdn论坛上,有人问如何考核测试人员,我回了几个帖子,下面就是我回帖的内容,可以代表我对此事的一些看法。
             一: 测试人员的工作评价比较的难办,因为测试人员没有具体的工作产品产出。
            测试人员一般做的也就是测试用例的编写和测试缺陷的提交。而这些可以说都不是看技术,而且看职业道德。所以我更多的认为,测试人员最重要的是责任心,是想 做测试而不是开发什么的。一个测试人员提出1个问题或提出10个,对软件最终的质量影响可能并不像大家想的那么严重。 如果真的要考核,只能从工作产品考核,提交的缺陷不可能做为考核的目标,因为分配的模块、测试人员的视角、开发人员的技术差异等都可能会造成相当大的振 荡。所以通常都是从测试用例的角度来进行评价。 这样可以换个角度来说关于测试用例。
            测试用例可以说是最变幻莫测的东西,因为至今没有一个严格的标准和理论来阐示测试用例的编写(记住,是测试用例, 不是别的什么)。而且测试是软件工程收尾的工作,很难有大的时间和精力去编写详细的测试用例,但简略的用例根本用不上,只能提供一个大概的思路。并不合适考核的条件和标准。 所以真的想考核,可以,把你们单位的各种关系理顺,完全按照软件工程的方式一点一点的来(RUP,CMM等都可以,因为里面的工作都很容易度量),如果不是按照这样,凭空的说考核测试人员,还不如经理直接拍脑门决定好了。
             二: 上面说的多,但中心只有一个:想考核,就必须有一个可以比较的标准,所以首先要想好自己的公司是否存在这么一个东西。如果没有,还是不要考核好了。 用bug数考核测试人员,就像用代码行数考核程序员一样可笑。
            三: 现在别说测试人员,就是程序员又有几个公司可以做到让大家都满意的考核?
             测试应该可以说都是在摸着石头过河,有理论,但实际很难做。 所以我一再强调测试人员的责任心,因为测试工作本身几乎无法度量,就像你写的,做一个小时和做8个小时从工作成果上并不能很好的体现出来。 为什么没几个愿意做测试,因为测试即幸苦又无聊,工资也比较少,成果还总被忽视。 其实谁做的多少、好坏,大家心里都有杆秤,只要在奖惩的时候,经理能做到一碗水端平,即使没有实际的比较标准,大家也不会过多的说什么。 管理对的是人,不是机器,不要妄图制定一个完美的标准,即使有,还会有人不服气的。 只要心中无愧,做什么随便让别人去说好了。
            四: 前两天才看到有人在讨论测试用例写的时机,觉得很有道理。
            如果按照标准的软件流程,测试人员可以参与到需求、设计阶段,测试用例当然比较的容易写。 但现在更多的情况,是程序开发完毕了,才交给测试人员,这样如果写用例,一是时间的问题,二是对程序不一定熟悉。所以说真的,写测试用例有些不和适宜。 而最常见的是测试完毕后补测试用例(嗯,怎么和程序员一样了,鄙视自己和大家,哈哈),这样一般都是为了应付上面和客户用的,只能说是一个总结,因为问题都找出来了,自然容易按照问题写用例,可以比较的完美。 所以我建议写测试思路,特别是有多业务流程的时候,这样做不容易遗漏。
             至于那种白痴照着做都可以发现问题的测试用例,反正我们是没有这个时间和精力,而且很多的时候,觉得测试都是一门艺术(再鄙视自己一次),发现问题更多是直觉(也许是错误的操作),这些都是用例无法表达的。 如果真要写,可以写一个简单的,随着测试的展开,对程序的熟悉认识再逐渐的补充。这样测试的差不多了,用例也基本写好了。 测试用例其实最难掌握的就是一个度,写到多详细,而这一般和测试时间呈线性关系。
  • 测试需要业务

    2011-07-18 22:20:48

    今天看到一个人问电梯测试,这样的问题很多,大部分都是面试题,也许考官看的是一个人的分析能力和思路吧,但是我却不是很喜欢这样的题目。

    作为一个专业的测试人员,你做的到底是什么性质的工作??

    在国外,测试人员很多可以接触到前端,也就是从需求设计、编码等阶段切入软件开发过程,如果开发分工的比较细,可能随着不同的组变化,测试人员也一直在同步跟踪软件。这时一个很理想化的过程,对测试要求很高,但是对软件的理解和缺陷的跟踪,测试人员本身应该是比较清楚的。

    在国内,我想大部分测试人员接触的是黑盒系统测试吧,而且大部分公司规模不大,文档也未必很多,这个时候,测试更多凭借的是测试人员的能力和经验

    其实在我个人看来,测试最终的落实点在业务。测试理论,如果肯耐心的学习,半年时间足矣。一些工具的经验,也可以随用随学。

    我想大部分测试人员,工作3年左右,就会发现到了一个瓶颈,很难再进一步了,所有的东西都在原地踏步,这个时候,如果没有升到领导阶层,就会很容易陷入一 个循环,发现自己每天做的都是类似的东西,一点新东西都没有。学习的东西也不一定在工作里面用的上。周围的人其实也差不多。

    这个时候,区分测试人员的,更多不是能力,而是你对你所在的范围是否熟悉。也就是你所拥有的业务经验,才是和其他测试人员相分离的。

    比如你作为一个测试人员,跳槽到其他公司,你的优势是什么?你的测试经验?别人未必比你差多少。但是对于新公司软件的熟悉了解,你却很不如。这就是业务的差异。不深入到一行,不会知道那行的规则。其实不止软件,每个公司也都是自己内部运行的规律吧。

    随便写写,很乱,我的思路也很乱,也没有太表达明白自己的意思。就当灌水了吧。
  • 开发想转测试的问题

    2010-07-16 09:29:05

    下面的内容,是有人在javaeye上,给我发短信,问开发如何转测试,我就进行了一些回复,仅仅代表自己的观点。

    2010-淡定:是专职测试人员吧  我想问问你“我怎么觉得开发往测试上转,要是不在公司内部转,好像不好转??测试必须更懂需求。。。”  通过投简历开发转测试难吗 都要准备些什么才能把测试做好  另外测试和开发您觉得有什么特点 我是个女生做开发也就两年觉得我在开发上没有多大发展   我不知道如果一直走测试这条路会是什么样子??

    鹿鸣:1.开发转测试很方便的。因为现在感觉愿意做测试的人不多,而且大部分的公司,测试的待遇比开发相对要低一些。至于是否在公司内部转,看你们公司的实际情 况了。不过换个新公司,你说开发想做测试,只要了解一些测试相关内容,应该还是比较方便的。
    2.测试是否更懂需求,我个人到没有什么感觉。只是看同样的需求文档,开发人员和测试人员的视角不会相同。
    3.如果你想转测试,最好看一些测试方面的书籍,或者根据需要在网上学习一些测试知识。比如http://www.51testing.com我 觉得就是最好的中文测试论坛了,大部分的东西都可以在里面找到。如果有时间和精力,可以去考一个软件评测师,即使通不过,对测试的方方面面也能有一个很好 的了解。
    4.我没有做过开发,从毕业就一直在做系统测试的工作,所以下面的内容仅作参考,将来你有机会做测试,应该能更深刻的体会开发和测试的差别。我感 觉,开发的主要工作是完成需求,就是在最短的时间内,完成要求的功能,至于质量,其实是在进度之下的,看到一个需求,开发人员第一个想到的是如何去实现这 个功能。测试不同,测试的工作是发现问题,从各个不同的角度,去验证软件是否满足客户的需求,是否在种种条件下,都能完成要求的功能。测试看到需求文档, 第一个想法应该是,这个测试文档里面是否会有什么问题,一个好的测试人员应该是一个怀疑论者,坚持所有的东西都有其缺陷,应该有各种各样的方法去找到,至 于如何解决,那就不是测试的问题了,修改缺陷是开发人员的事情。
    5.在我见到的测试人员中,男女比例基本一致,至少比开发人员要好,这说明测试还是比开发更适于女生来做。测试其实是一个很枯燥重复的工作,细 心、耐心都是不可缺少的个人品质,这些女人比男人更好吧。但是测试也需要一定的逻辑,一定的开发技能,这就是男人的强项了,所以说测试时适合一切人做的, 呵呵。
    6.开发转测试有其固有的优势,就是对开发语言的了解。一方面对软件开发语言了解了,更容易知道软件容易在哪里发生问题;另一方面,自动化测试本 身就需要一定的开发技能。
    7.既然你做过开发工作,那么测试的方向可以向自动化测试方向发展。比如性能测试了解Loadruuner、jmeter等;功能测试,了解 QTP、Selenium、watir等,比较不会浪费开发技能,而且发展方向也会好些。
    8.如果你的外语好,还是去外企吧,更正规些,而且有更优的发展。测试的提升其实感觉真的挺难的,开发可以程序员->项目经理->技 术总监->副总之类的,测试一般到测试主管上就不容易了。按照现在javaeye的说法,开发是利润部门,测试在大部分的人眼中就是附属成员。
    9.如果没有野心,可以做测试试试,没有开发那么大的压力,竞争也相对小些,当然发展也有一定的限制,一切决定看个人和命运。

    上面说的比较零散,只代表自己的一些看法,可能有不对的地方,也请多多谅解。


  • [论坛] 也许和缺陷管理有关的一些讨论

    2010-07-15 09:47:28

    下面讨论内容在项目管理,本质和软件无关,节选部分内容,全文去看链接。

    zwchen:Bug管理,这两年,我们经历了三个阶段。
    先说说使用环境吧,因为这是决定一管理软件是否适合的最核心条件之一。
    人员 有开发人员和不懂软件的业务人员 问题主要是业务员提出
    距离 原来一年大家在一个办公室 后来IT部和业务部分,距离约1km
    项目 旅游电子商务网站 包括前台和后台 这类网站重业务和用户体验 技术上没难度

    最开始,使用的是Bug管理系统JIRA 用了约一年,基本上是推,业务人员不适应,最后我觉得反馈一个问题很烦琐,自己主动废弃了。
    后来,使用Excel,当然这是为bug管理定制的Excel, 执行一个月就觉得不行,因为问题汇总、截图等不方便,简单问题这样汇报似乎也太累。
    最后,使用Foxmail邮件 用得非常顺,特别是业务部和我们分开情况下。因为邮件有三个特性很受用:抄送人,延迟执行,贴图。
    有些很小并且及时的问题,直接通过QQ完成。
    反正,在我们这个小团队,最后一种方式,直到现在都觉得很适合我们。

    其实,在Bug管理的背后,有一个非技术支撑:信任。我们的重点不在责任界定、责任追究等和权限有关的事情上,我们只关注目标:问题被及时发现、及时解决,以及解决过程中的低成本协作。


    luming:别的不多说,至少缺陷管理上到一定的规模,必须用软件。
    个人觉得阈值是50左右,只要一次提交20以上,在修改、验证、再次出现、新缺陷等等,3 轮后,你就彻底迷糊哪个缺陷到底处理了没有,特别是可能多人测试重复提交缺陷的时候。

    前两天我们就做了一个这样的尝试,去其他地方测试,没有用我们的缺陷管理软件(CQ),直接用excel管理的,我们3个人,后来两个人,最后只有我自己一个人测试一个程序,大约6~7轮,实际缺陷 148,但是中间包括整理、重复等缺陷600+,弄的我很晕。


    zwchen:1、我不否认Bug管理系统的价值,项目到了一定规模,用它有时可以提高问题反馈、跟踪、解决效率。

    2、Bug管理系统也是一种管理软件,所以在上马它之前,一定要给员工培训其“业务”,比如Bug管理系统可以帮大家解决什么什么问题,有什么什么好处;另外,还有告诉它们实施过程中有什么阻力;然后再告诉他们使用流程。
    往往不是Bug系统不够好,而是团队不够规范,比如大家提交问题时马虎、或喜欢口头反馈。

    3、Excel可以做成很适用的Bug管理客户端,通过SVN来团队共享,见附件。

    4、本文的主题是,如何客观看待项目管理软件,偏管理、偏商业、偏宏观;你说的是微观,是问题的另一个方面。
    打个比方,你夸一个MM,你好聪明啊,她回答,难道我不够漂亮吗?



    luming:我们用的excel本身和你附件给的格式差不多啊。
    对缺陷管理这里,我想还是比较有发言权的,51testing的缺陷管理版本人就是版主,也比较关注这些方面的问题。
    这么多年,我一直用ClearQuest,其实就是因为CQ几乎隐藏了所有对开发人员无用的东西。
    zwchen说的很对,开发人员用缺陷管理软件需要培训,这么多年来,我见到的培训最少的缺陷管理软件就是ClearQuest。
    ClearQuest其实配置使用起来是最麻烦的,而且也过于古老,新的软件jira等我不否认比CQ好很多,比如可以把缺陷分配给多人处理。
    但是使用软件需要成本,我个人认为,这个成本最好转移到测试人员而不是开发人员,就是测试配置完毕后,仅仅需要开发人员方便的使用,其他麻烦的事情,都在测试方面,因为主要需要使用此软件的是测试而不是开发,开发仅仅需要了解问题并解决,至于缺陷状态时什么,有多少严重问题,有多少缺陷,什么时候需要修改,开发人员的想法很可能是“关我何事”。
    所以测试人员需要给开发人员设置方便。
    包括TestDirector或jira这样的软件,给开发人员讲解比较麻烦,因为太多的内容不好隐藏,很多时候真的是需要培训才可以的。
    ClearQuest则不然,功能相对强大自由,配置繁琐费时,客户端也比较麻烦,但是web端啥都没有,开发人员想折腾都不可能。
    通常在ClearQuest上我都按照开发人员姓名或模块和状态(等待处理,再次出现)做查询,就告诉开发,你只要点击自己名字的查询,修改里面的缺陷即可,状态选择按照你的处理模式,已经修改、不是缺陷、暂不修改,别的你不用管也不用动,2分钟完事。
    从培训和使用角度,我觉得对开发人员来说,ClearQuest是最简便的。

    Excel也一样,我之所以不想用它,也是同样的思想,麻烦事测试做,开发只需要了解哪个问题需要修改。
    所以每一轮,我都要检查几个人提交的缺陷是否重复,重复的合并。程序员已经修改的问题直接删除,只留下新问题和没有修改的,这样每轮都需要做很多整理工作。最后写总结,把这些中间过程的缺陷文档合并到一起,就觉得很多了(600+整理为148)。

    也许很多人对同样的问题看法也不一样吧。
272/2<12
Open Toolbar