软件测试理论/方法/实践
文章平均质量分 73
roger_ge
这个作者很懒,什么都没留下…
展开
-
关于测试用例的详细程度
一直迷惑于test case应该详细到什么份上,作为存档的test case文档,太过详细貌似内容过于繁琐。因为自己刚入行,刚进公司的时候参加了一个项目,照着spec基本上就是一通随机测试,也没设计什么test case,结果可想而知,覆盖率很差,甚至项目过去了两个月,被项目leader问到当初有个case有没有跑,才恍然大悟,原来有很多小的细节case全都疏忽掉了。最近一个月又有一个新项目上马,原创 2009-10-22 15:41:00 · 2895 阅读 · 0 评论 -
求变
进入现在所在的公司已经快一年了,期间参与了多个项目的测试工作,收获良多,感触颇多。一直想静下心来,好好总结一下个人所认识到的,现在所在部门可能存在的问题,并提出个人的观点。倒不是想改变什么,毕竟自身只是一个Tester,无力改变什么。只想在将来的某一天如果再遇到相同的问题,且自身有能力做点什么的时候,留下个参考而已。 一、 业务转型 在过去,部门所测试的是领域原创 2010-05-23 21:42:00 · 1521 阅读 · 1 评论 -
怎样诠释测试--记开展测试的记忆式方法
怎样诠释测试--记开展测试的记忆式方法James Bach 《How Do you Spell Testing》Roger翻译于5/24//2010 在探索性测试中,我们设计和执行测试是实时的。那么我们应该怎样组织我们的思维以使我们能思考出有价值的测试?有一种方式就是通过使用启发式方法(heuristic)和记忆式方法(mnemonics)进行。启发式方法是一种“依据经验法则,翻译 2010-05-24 17:45:00 · 1369 阅读 · 1 评论 -
Daily Report 到底该写点什么?
作为一个tester,每天下班前最后做的一件事情或许就是将自己这一天的工作内容发送给自己的老板,以让老板清楚的看到这一天你到底做了些什么内容的工作。转入软件测试行业快一年了,一直觉得自己的daily report很烂,秉着细节决定成败的原则,决心好好想想自己的daily report到底该怎么写。先看看自己之前发送的daily report格式与内容:l What did原创 2010-05-20 00:03:00 · 23952 阅读 · 0 评论 -
3W+2H:学习和思考问题的有效方式
在测试工作中,肯定会遇到各种各样的知识点,如测试用例、手工测试、自动化测试、性能测试等等。如何全面的整理,深入的思考这些知识点,从而在广度和深度上同时能进行把握和探究?在实践中,发现还是有规律可循的,可简单概括为: 3W+2H:What,Why,When,How,How What(是什么):知识点的本质理解,可从纯理论性上加以整理。原创 2010-05-17 23:48:00 · 14035 阅读 · 0 评论 -
灰太狼与红太狼抓羊 - 记一次应用云测试经历
灰太狼和红太狼(它们是用户)从羊羊村抓了6只羊放在羊圈(云)中,并且羊圈总共有5扇门。现在它们想吃羊,但是有一定的条件:l 吃羊必须经过两个步骤:u 将羊经过5扇门中任何其中一扇从羊圈中牵出u 将羊吃掉l 从同一扇门中可以分批次牵出1至5只羊不等。l 总共能从羊圈中牵出5只羊。l 抓出来的羊归属一旦确定,不能相互交换,即灰太狼的羊不能给红太狼吃原创 2010-05-10 23:18:00 · 2866 阅读 · 1 评论 -
再谈测试用例的详细程度
在写测试博客之初写过一篇名为“关于测试用例的详细程度”的文章,现在看来有些杂乱,也缺乏一定的严谨性和条理性,那篇文章更多侧重的是有感而发。 今天和所带项目的一位组员探讨测试用例的时候,关于测试用例的详细程度发生了明显的分歧。静下心来,还是想好好整理一下思路。 对于软件测试用例(只涵盖功能测试,不包括性能测试)大类,个人目前的认知基本由以下几原创 2010-05-07 00:46:00 · 2090 阅读 · 3 评论 -
关于组建Test Lab的几点想法
上午有位同事向我“推销”他的test lab构想,出发点是想提高公司设备的有效利用率。那么就需要征求测试部门的同事们贡献出手上空闲的测试机资源,以组建test lab。想法真的非常不错,很多大公司如微软等,都搭建了非常高效的test lab,虽然其具体实现细节个人无从知晓,但其效果确实从微软工程师所著的书中得到了说明。目前所在公司的状况是,每个Tester手上都有多台测试机器,少则一两台原创 2010-05-06 21:10:00 · 3030 阅读 · 0 评论 -
怎样才算是一个好的测试用例
今日花了数小时的时间仔细的阅读了一下Cem Kaner教授的《What Is a Good Test Case?》一文。起初看到文章的标题原以为是一篇讲述编写测试用例所应该采用的步骤和注意事项的文章,读完才发现原来是一篇讲述评判测试用例”good”的文章。文中提出的测试用例应该更倾向于向被测程序索求信息(不仅仅包含缺陷信息),以及建议在软件测试的开始阶段应该秉着以合法的数据来验证程序是否实现了规定原创 2010-03-02 16:24:00 · 6030 阅读 · 0 评论 -
交叉测试之苹果理论
第一部分:苹果理论清晨打开冰箱准备拿出牛奶吃早餐,猛然发现冰箱里已经累计有四瓶鲜奶了,这还不包含屋外奶盒中今天新送到的两瓶。怎样解决?这使我想起了著名的苹果理论也存在类似的问题。买了一袋苹果,持续数日后,有部分苹果新鲜程度已经开始有了变化,且开始腐烂。传统的观念似乎是这样的:正确的做法是一直挑没有变质的苹果吃,这样的结果的是部分没有变质的苹果被你成功吃掉,另外一部分则彻底坏掉;错误原创 2010-03-03 11:18:00 · 1575 阅读 · 4 评论 -
浅谈实施软件测试风险分析
作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章,其中不乏精品之作。本文将此类知识进行了归纳,查漏补缺,并在思维导向性上给出了简单的实施步骤,以使得在实际应用中能得到更好的运用。第原创 2010-03-03 17:45:00 · 8585 阅读 · 0 评论 -
OATS PK Pairwise Testing
对于多输入参数组合类的测试方法目前业界流行两种方法,一种是OATS(Orthogonal Array Testing Strategy),即正交表法;另一种是Pairwise/All-Pairs Testing,即配对测试法。对于两种方法,虽然业内已经存在比较成熟的设计工具,但是秉着知其然,知其所以然的目标,还是先熟悉一下两者的原理,然后再进行区分和比较,从而在实际运用中将其灵活运用。 第原创 2010-02-26 15:56:00 · 7960 阅读 · 8 评论 -
基于缺陷数据的度量与分析
软件的度量分析一直是个“虚幻”的话题,因为软件的开发过程毕竟不能和制造业相比,后者的过程中所产生的数据是非常有类比性的,从而度量也变得容易一些。如何在软件开发过程中抽象出可度量且具有实际使用意义的属性确实非常值得思考。 目前所在的公司是一家美资企业,没有实际意义上的QA,虽然我自身的角色被定义为QA,但其实质上是Tester。那么没有QA,也就没有专门负责原创 2010-02-25 20:31:00 · 10876 阅读 · 0 评论 -
怎样衡量测试成功
怎样衡量测试成功-- Rob Pirozzi 《How to Measure Testing Success》Roger翻译于2/27/2010原文地址:http://www.logigear.com/newsletter/how_to_measure_testing_success.asp 摘要:在很多时候,高级管理层通过可以节约多少成本来考核软件测试。测试自动化和外包被翻译 2010-02-27 23:33:00 · 1557 阅读 · 1 评论 -
软件测试,你到底是个什么东东?
做了快一年的软件测试(先前做了几年的硬件测试),一直纠结于软件测试最“淳朴”的概念到底是什么,期间也看到了很多种版本,细细想来总结一番: 版本1:软件测试就是发现bug最质朴的一种解释,也是遇见最多的一种解释。至少现今所在的公司对此是这样理解的。一个Tester所从事的软件测试工作似乎就是熟读spec后查找bug,跟踪bug 版本2:验证软件实现了规格说明书要求的功能,确认没有原创 2010-02-24 00:43:00 · 1315 阅读 · 0 评论 -
劈材挑水之“等价类”
<br />等价类,作为最常用的测试方法之一,最难的地方可能就有两点:如何对每个输入元素进行合适的有效及无效等价类划分,太细,则冗余,太粗,则覆盖率降低;另外对于元素之间有关联和制约关系的情况来说,也需要进行合适的有效及无效等价类划分(如下面的“下一日期”软件中年、月、日之间就存在一定的制约关系)。<br />以C#语言编写的“下一日期”软件进行等价类设计分析。<br /><br /><br /> <br /><br />第一步,对每个输入条件进行等价类拆分<br />输入<br />输入条件<br />有原创 2010-06-25 15:15:00 · 1266 阅读 · 0 评论