哟哪桑在他blog中,有post一篇文章"FeatureRequest,OrBugFixing?"其中谈到一个长久以来争辩不休的问题:当你找到一个问题,你会视为bug,还是视为feature?当哟哪桑一发表完后,已起很大的回响,很多人提出不同的看法.我想是很值得大家去看看最近小弟在闲逛时,刚有看到相关的blog文,因此找出来让大家参考一下另一种说法.Bugv.s.Feature
对于在软件测试上的职涯规划,作者非常主动地鞭策自己一直往前进.他认为不管公司有没有提供这样的协助或是规划,自己都有责任对自己专业生涯发展做些事情.他发现IanClatworthy提出了一个professionaldevelopmentframework,M.E.T.A.-Management,Engineering,TechnologyandApplications.他根据这个framework加
1.要记得鼓励你的员工2.要找寻资深的经理当你的导师3.要把RD当作是你的客户4.要订定你测试方向或策略,并且取得相关stakeholder的共识5.选择你需要的metrics来管理测试的状况,但不要过度迷信它6.要能善用工具帮你自动化,但要确认它真的能帮上忙.7.要能度量你的测试是否真的很有效率8.要持续投资来赶上你的测试环境9.记得要在CCB(ChangeControlBoard)中出席或是有
在几个月前,我请我11岁的儿子帮我在家里做一些事情.过了一段时间,他开始做一些我没交代他做的事情.我告诉她:"你没有在帮我忙"我儿子说:"但是我正在帮你耶!!""不,你不没有在帮我""我在帮你忙啊!!我真的在帮你啊!!"他大声叫喊着.他感到非常挫折.他真的以为他是帮我,可是他并没帮到我.我也感到非常挫折.从我的观点,他
什么时候已经测够了,可以停止了,这个问题是QA常常会被问到的,也是其中一个不容易回答的问题.可是这也是你无法逃避的问题,因为每次product要release时,你就要面对一次,即使没有人问你,你自己也会问自己是不是可以出货了.以下是常见的的criteria1.Allthehighprioritybugsarefixed.-这通常是最重要的,如果重要的bug没解,是不敢出货的-不过通常仅限于重要的
在测试现场，有一个关于测试专家使用认证模型及其必要性的生动讨论。测试人员大致可以分为两组:一组是声明当认证时，不会变得更好，因为目前的认证如ISTQB和ISEB注重方法和术语而无法观察到测试者的实际测试技能。一个提前认证过的小组认为测试行业如一个年轻人，缺乏认证模型，而这类模型已经被其他专业人员使用多年。同时，有人说，测试行业在IT行业被接受，已经成长为一个成熟的行业。最近欧洲STAR会议的网站表
无论缺陷预防工作贯彻落实地多好，软件组件总有缺陷。这很明显，因为开发商无法阻止/消除软件开发周期的所有缺陷。因此，软件必须进行彻底的测试，然后才交付给最终用户。测试人员的责任是：设计既可以（ⅰ）找软件缺陷，又能（ii）评估该软件的性能，可用性和可靠性等方面的测试。现在，为了实现这些目标，测试人员必须（往往是从一个非常大的执行域中）选择和/或制定测试用例的有限数量。不幸的是，完整的测试通常不是在这个
不论是什么行业里，能让人最兴奋的事情通常都是解决新奇的、高难度问题带来的刺激。在我的工作中，经常会遇到很多bug，乍一看，它们都是不可能的。不是不可能解决，而是完全不可能出现。就好象最前沿的科技揭示了一个新的奇怪的逻辑现象，以至于人的大脑完全无法理解。当然，这里我总结的这些bug都是很独特的，如果你想说是否能有某种最先进的系统性的方法能将这些bug归类，统一解决，那是愚蠢的，就好象一个人无法认识到
如果你稍微写过一点代码，就能知道“集成开发环境”（IDE）是多么的便利。不管是Java、C还是Python，当IDE会帮你检查语法、后台编译，或者自动导入你需要的库时，写代码就变得容易许多。另外，如果你工作在Linux上，你也会知道Vim在进行文本编辑的时候是多么的方便。所以，你可能会想从Vim中也获取这些IDE特性。事实上，很少有方法可以帮你做到。有些人可能会想到试着把Vim打造成C语言IDE的
1.什么是代码测试？与传统的功能和接口测试有什么不同？代码测试的立足点是Code，是基于代码基础之上的，而传统的功能测试和接口测试是基于应用的，必须对应的测试系统是在运行中的。代码测试不会特别注重接口测试的可持续性集成。代码测试的特点是快捷高效准确的完成测试工作，快速推进产品的迭代。2.CodeTest的方法：（1）代码走读和review适合场景：逻辑相对简单，有较多的边界值。方法介绍：直接查看和
热门文章