Ready Test? Go, Go, Go !!!
 

关注测试,也关注成长

公告
  • 关注软件测试自动化,性能测试。
    目前负责医疗软件功能测试以及
    测试过程改进

日历
<2005年6月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
统计
  • 随笔 - 22
  • 文章 - 0
  • 评论 - 87
  • 引用 - 0

导航

常用链接

留言簿(17)

随笔分类

随笔档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

 

2005年6月16日

OK--就是Pass,测试通过的意思。
POK - 部分通过,表示测试中有很多检查点,比如其中两个检查点通过,一个没有通过,就是POK
NG - 是Not Good的意思,不同的公司叫法不尽相同,有些公司也叫Fail
NT - Not Test,表示没有测试,并不是所有的测试用例在每一测试轮次都是需要测试的,没进行测试的就是NT

posted @ 2008-07-28 13:33 Cinderella 阅读(2953) | 评论 (1)编辑 收藏
 


 

一开始听讲课的老师说,性格会随着信念和经验而改变,还觉得难以相信,因为似乎我多年来的性格变化不大。

而如今经过两年多的严格要求自己,以及参加了一系列的培训之后,我再次的性格类型测试已然跟从前不同了,确实以下的这个答案更是像现在的我了。

您的性格类型倾向是“ ENTJ ”(外向 直觉 思维 判断)

坦诚、果断,有天生的领导能力。能很快看到公司/组织程序和政策中的不合理性和低效能性,发展并实施有效和全面的系统来解决问题。善于做长期的计划和目标的设定。通常见多识广,博览群书,喜欢拓广自己的知识面 并将此分享给他人。在陈述自己的想法时非常强而有力。

ENTJ型的人是伟大的领导者和决策人。他们能轻易地看出事物具有的可能性,很高兴指导别人,使他们的想象成为现实。他们是头脑灵活的思想家和伟大的长远规划者。因为ENTJ型的人很有条理和分析能力,所以他们通常 对要求推理和才智的任何事情都很擅长。为了在完成工作中称职,他们通常会很自然地看出所处情况中可能存在的缺陷,并且立刻知道如何改进。他们力求精通整个体系,而不是简单地把它们做为现存的接受而已。 ENTJ型 的人乐于完成一些需要解决的复杂问题,他们大胆地力求掌握使他们感兴趣的任何事情。 ENTJ型的人把事实看得高于一切,只有通过逻辑的推理才会确信。 ENTJ型的人渴望不断增加自己的知识基础,他们系统地计划和研 究新情况。他们乐于钻研复杂的理论性问题,力求精通任何他们认为有趣的事物。他们对于行为的未来结果更感兴趣,而不是事物现存的状况。 ENTJ型的人是热心而真诚的天生的领导者,他们往往能够控制他们所处的任何 环境。因为他们具有预见能力,并且向别人传播他们的观点,所以他们是出色的群众组织者。他们往往按照一套相当严格的规律生活,并且希望别人也是如此。因此他们往往具有挑战性,同样艰难地推动自我和他人前进。

posted @ 2008-04-03 18:41 Cinderella 阅读(2311) | 评论 (2)编辑 收藏
 
 

 

目标确定后,我第一步要做的就是找资料,找资料的工作都是春节在家里完成的(其间还带爸妈浏览了一下公司的网站),找开源的工具,主要是看大众的评价和普及度。

软件的易用度很重要,否则无法达到优化测试管理的目的。……(此处省略n字baidu和google),主流的开源测试管理工具如下:

缺陷管理工具

1.    Mantishttp://mantisbt.sourceforge.net/

2.    Bugzillahttp://www.mozilla.org/projects/bugzilla/

3.    Bugfree (http://www.bugfree.cn/)

测试管理工具

1.    TestLinkhttp://testlink.sourceforge.net/docs/testLink.php

2.    Bugzilla Test Runner http://sourceforge.net/projects/testrunner/

最开始的时候特别侵向于2&2,因为Bugzilla Test Runner 就是基于Bugzilla的测试用例管理系统。本打算把前者改造一下让它支持更多测试计划(上篇提到的需求1),可惜工作量有点大,另外它的网络支持也较少,决定Pass。

到这时,测试管理工具就剩下Testlink了,缺陷管理工具开始也是想用2,比较熟悉,这个没有兑现则纯粹是缘分问题,现在怀疑是当时下载的Bugzilla的包是个坏的,感兴趣的同学可以再试试。

最终Testlink和Bugfree的结合就是顺理成章了。这样确定的时候,有点无奈,因为二者是PHP+mysql+Apache的,我对PHP了解太少,没有写过程序,不知道遇到问题能不能改。新发布的Bugfree2.0增加了测试用例和测试结果的管理,“冗余”了,还是用1.1.

 服务器启来,Testlink和Bugfree分别执行了一下,总的来说挺幸运,除了Testlink的乱码比较多,两个都能独立顺利跑起来。乱码的问题最后改,根据经验,这一定是个minor的bug,应该就是配置的问题。先尝试能把两个连接起来重要些。

找到配置文件,链接按钮也照着葫芦画瓢编码进去并且正确显示了,只是点击按钮后就会异常退出。找Bug是咱测试人员的强项,分析跟这个bug相关的第一嫌疑是testlink和bugfree的主程序,次嫌疑是相关的两个配置文件,主程序很短,两个index.php 从头至尾看过一遍,最可能出bug的就是几个if语句了,分支走错了退出,太常见了。果然就是少了一个!的问题。乱码是键值没有内容,逐个配置上就解决了。

试着模拟了一次CCI回归测试,从建计划到执行到指派相关人员处理临时问题,可以满足上篇的需求,也可以胜任小型项目的测试管理工作。CCI的同学可以连到我的机器玩玩http://10.1.1.187/testlink/index.php test/123456(senior tester). 目前自动化测试管理剩下一些修补的工作,像是邮件配置,明确权限管理、测试流程等,需要在业余时间慢慢做完,只是繁琐,应该不难。另外计划在4月份可以准备一次《基于Testlink&Bugfree的测试管理工具UserGuide》的内部交流。

最后总结一下整个自动化测试管理的过程,最大的感触就是“选择比努力更重要”,和人生一样,永远不只是A和B的选择,应该还有C。另外一个感触是,很多实验没有做彻底有些遗憾(主要是时间成本),无法确切定位问题,疏漏难免,因此非常欢迎大家的建议和指导!来电来函均有来必复~

posted @ 2008-03-21 09:54 Cinderella 阅读(2501) | 评论 (0)编辑 收藏
 
     摘要: 白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。

  其中运用最为广泛的是基本路径测试法。

  基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。

  设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

  阅读全文
posted @ 2008-03-12 09:50 Cinderella 阅读(2536) | 评论 (1)编辑 收藏
 
 

节日里我们总会送出也会收到很多的祝福,总觉得最实在的其实不过一句,那就是祝你健康。

节前公司体检的时候,我告诉大夫我的背坐久了就会痛,最后的体检报告只多了一条诊断:自诉背痛,没有给出什么原因。这一次回老家, 父亲给我施了3次针就好了。说实话,过年最大的收获,最大的感触,都来自于父亲。

中医是我家祖传的,也是父亲毕生的理想,都说命运爱捉弄人,为了我们姐弟更好的生活和自由追求我们的理想,20年前,父亲辞去村里赤脚医生的工作,成为了一名市政府公务员,负责乡镇环卫工人的管理工作。在全新的岗位上他依旧出色,且为了改善自己工人的工作状况,父亲还发明了一种低成本的扫路机。现在这项扫路机已经申请了专利。而父亲,是一个根本没有学过机械的人,他用自己的成绩告诉我们,多替别人着想并不会吃亏。父亲更加身体力行,即使是自己不喜欢的工作,既然在这个岗位上,就一定要做到最好。

这20年间,父亲一直不辍钻研中医,理所当然地成了邻里乡亲的家庭医生,也有邻里乡亲介绍来的亲戚朋友,甚至有专程从哈尔滨前来求医的。父亲说自己不是挂牌的医生,所以从来不收费。如今就快要退休了,政府单位的工作也成了闲职,父亲在家里辟出一间屋做诊室。我这次春节在家,前来就诊的人也是络绎不绝。

想做什么,想学什么,只要开始并且坚持,永远都不会太晚。到如今父亲已经找到了许多常见病的根治办法(中医方法),比如偏瘫和面瘫,鼻窦炎,过敏性鼻炎,扁桃体炎等。凭我有限的了解,只能列举这些,实际当然远远不止。昨天打电话想问问爸爸还有些什么,我想写到作文里。弟弟接的,弟弟说,爸爸不说,爸爸就是脸皮薄。:)

posted @ 2008-03-10 11:14 Cinderella 阅读(1439) | 评论 (0)编辑 收藏
 
 

不得不说,在自动化测试研究的工作中,确实学到了很多。除了测试技术之外,更多的是在业务,还有对于工作流程的一些思索。

自动化测试的测试管理这一块,一开始的时候先是想用TD(TestDirect测试届很流行的一款测试管理软件,比较成熟,包括测试需求、计划管理,Bug管理,报告生成等)的,QCQuality Center,其实和TD是一家,目前TD已经不再升级了)直接淘汰,主要是目前为止,我还没有看见过unlimited的破解码,而没有看到效果直接让公司掏钱买当然更不合理。

经过仔细评估,TD也淘汰了。因为我们CCI的工作流程已经非常成熟,早就有了一整套的开发测试的工作流程,也有管理bug的软件。所以自动化的测试管理实际上CCI已经做到够用,当然从长远来看,有一个稳定且强大的自动化测试管理系统是非常必要的。而目前改革的必要则不大。不要为了自动化而自动化,就是这个道理啦!

需要进行自动化测试管理的范围最终缩小在回归测试,这是测试工作最辛苦的部分。回归测试需要保证测试环境的稳定,保证新增功能正常,还要验证旧的功能,主要原因是在于永远都是一个非常紧迫的Deadline,枯燥而又紧张,能否充分测试是个永远的问题。不光是在我们部门,整个测试界都为之头痛。而我考虑这个问题也真的是很久很久了,假期的某一天我突然想到,为什么不用开源的工具来为CCI的回归测试定制一套自动化的管理工具呢?

这样做的好处有很多,首先是免费,因为免费,公司就不需要承担用盗版软件侵权的风险,也便于给其他的部门推广;第二是开源,因为开源,就可以定制真正适合我们的管理工具;第三还是开源,使用的时候有什么问题,或软件有Bug,都可以通过改写调试来解决。

我同样考虑了这样做的风险,最大的自然就是技术上的,能不能找到合适的开源软件是第一个问题,毕竟开源的工具不会像主流的商业工作做得那样完善。能不能去改代码适应我们是第二个问题,如果将来多数的功能没有现成的全部要自己来写,成本会不会太高?至于第三个也是最关键的问题,在CCI使用后会不会有我预期的效果,我倒是不太担心,如果不好用,就没有使用的必要了,最差也就是维持现状。所以我觉得还是值得一试,只要遇到问题尽最大努力去解决。

再下面我就仔细考虑回归测试中的具体问题了,以争取在后面的工作中能够全部或者大部分的改进。在这里再一次给大家推荐思维导图的方法,和很多同事分享过,这一次我又使用这个方法快速地锁定要解决的问题。画了好多,经过筛选,按照角色挑出来三个主要问题:

1、测试组长:现阶段回归测试的任务管理是测试组长独立承担,通过发送邮件给大家分配工作;工作进行后会通过询问跟进每个人的完成情况,了解存在问题等;全凭组长的责任心记清问题,提交给相关人员解决。弊端显而易见,耗时,费事,任务较繁重时难免焦头烂额。

2、网管:要保证测试环境的稳定真的不是一件轻松的工作,特别是我们这样一个功能完善的系统,有这么多人使用,有些配置被改动可能就会影响正常的测试;回归测试中很常见这样的情况,一个又一个测试工程师给网管说,“给我看看XX配置,我等着测哪!”“那个XX功能还没好,先给我看看好不好?”“啊,那个功能改好了,怎么不告诉我一声,等半天了。”同样的,如果配置不稳定,网管的工作效率很容易成为整个回归测试的瓶颈。

3、项目经理:需要了解进度时也是通过询问的方式;还有如果测试组需要项目经理协调解决一些问题时,同样是询问。

将测试工程师排除出来不是说没有问题,而是123已经包括。针对1,需建立测试计划分配、以及任务跟进的机制。针对2,需要包括任务优先级定义设置;针对3,需要建立自动生成测试进度报告;123都需要建立自动通知的机制。

 

(欢迎继续关注下篇 实践篇)
posted @ 2008-03-07 09:57 Cinderella 阅读(1635) | 评论 (0)编辑 收藏
 
<<士兵突击>>看完了,每个人身上都有一些值得我们学习的东西。
 
喜欢许三多的坚持不懈。铁棒磨成针就是说的他吧。
 
喜欢史今的对自己人生负责。我猜他复员回家一定是和他的那个生离死别的可爱同桌在一起。
 
喜欢伍六一的挑战自我,他相信自己会活的更好!特别是放弃了一次之后的伍六一,他会在他的人生中有取也有舍得。
 
喜欢成才,喜欢成长之后懂得珍惜了的那个成才,有了失去,才有了再一次的争取;有了年少的轻狂,和目空一切,才有了后来的沉淀、成熟、更加清晰目标的未来。
 
喜欢连长高城,当7连被瓜分殆尽,他那么短的时间,煎熬中那么快速的成长。人无完人,要像他一样,快速地发现自己的不足,快速地成长。

[

posted @ 2008-03-06 10:37 Cinderella 阅读(1326) | 评论 (0)编辑 收藏
 
     摘要:   阅读全文
posted @ 2008-02-15 14:13 Cinderella 阅读(1887) | 评论 (0)编辑 收藏
 
     摘要:   阅读全文
posted @ 2007-12-19 16:20 Cinderella 阅读(335) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2007-11-23 14:35 Cinderella 阅读(1463) | 评论 (1)编辑 收藏
 

今天发生一件事情很不爽。

因为服务器的原因,我提交的Test Case没有更新,美国的工程师照着旧的Test Case将该单元fail了。

这件事完全由于我的失误,作为一名测试工程师,一定要在Pass之前Confirm所有相关的内容。

这应该是最起码的责任心。

 

之所以写在这里,是我希望自己一定要记住这点,不要忘了!切记!

===

2008年1月10日 追加

第二点,还是今天实实在在发生的哦!差一点犯错~记住!
上一轮的回归测试之中,发现了不少bug,有好多是serious的,
而这一个是medium的级别,开发工程师Confirm的时候,说是一个配置的原因
如果配置项修改了,就不会出现,所以不是bug。并且说他尝试了多组数据,都没有再出现。

于是我按照他说的,用了几组数据来试,看上去真的是配置的问题。
因为在测试的时候,确实没有注意到这个配置项是相关的。
幸好自己又多试了一组数据,只是一组,发现这个配置根本不起作用!!!
然后后面再试的,就是又证明了而已!原来这还是个bug啊!
我都差一点给Close了!

于是跟工程师道歉,告诉他测试的时候确实没有关注到这个配置项,他能给指出真是很了不起。
同时也跟他讲,可能这个问题还需要我们一起进一步来研究看问题出现在什么地方,于是他很爽快地答应了!!!

posted @ 2007-11-23 10:26 Cinderella 阅读(1351) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2007-11-22 17:24 Cinderella 阅读(1834) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2007-11-08 10:14 Cinderella 阅读(455) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2005-10-09 22:21 Cinderella 阅读(2033) | 评论 (7)编辑 收藏
 
     摘要:   阅读全文
posted @ 2005-09-06 18:51 Cinderella 阅读(829) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2005-08-17 10:51 Cinderella 阅读(3395) | 评论 (1)编辑 收藏
 
     摘要:   阅读全文
posted @ 2005-06-17 21:19 Cinderella 阅读(11903) | 评论 (25)编辑 收藏
 
     摘要:   阅读全文
posted @ 2005-06-16 14:48 Cinderella 阅读(1127) | 评论 (8)编辑 收藏
 
Copyright © Cinderella Powered by: 博客园 模板提供:沪江博客