微软在测试方面提出一个practice:bugbars.也就是说他们会设定一个magicnumber,当RD身上所负责的bugnumber超过这个数字,他必须要停下手中的工作,立即把bugnumber降到这个数字已下,或者是全部解完.它的目的是希望bug早点找到,就能够尽早被处理.避免bug影响之后其他功能.此外若是这bug很久之后才解,容易被忘记它到底是怎么发生,或者是要根据哪个版本的sourc
TheFeatureCrewModel在.NET2.0release之后,开发团队对开发软件的方法,做了一个很大的转变.这个改变是从上到下,作者称它为"FeatureCrewModel".整个开发部门为了这个方法做了很多准备,花了几个月的时间去开发许多工具以及infrastructure.这个model主要概念如下:1.在开发部门中,每个ProductUnit(PU)会把要re
我想你一定听过很多人说,测试应该要涵盖所有状况,或是抱怨未甚么连简单的东西都没有测试到,或者测试为什么需要这么多时间....这是因为他们对测试这个活动的本质有点误解,他们不知道软件测试是sampling的活动.即然是取样,自然不会涵盖所有状况;有可能你选样不好,导致某些状况漏掉;或者是随着你取样的多寡,自然需要花的时间也就不同.这时候你会问,为什么软件测试是sampling的活动?这个问题的答案是
微软对测试人员有提供以下trainingroadmap0.Day1-2:CrossDisciplineNewEmployeeOrientation1.0-2yearsTestDesignApproachesTestAutomationDebuggingModelBasedTestingElectiveCourses2.2-5yearsTechnicalElectives:Designpattern
作者在这里列出,bugreport常见的一些问题,很值得QA人员注意:1.不完整的reprosteps-95%的人认为bugreport最严重的问题就是reprosteps不完整不详细.-RD,QA会来来回回的确认问题在哪里,将会浪费两边大量的时间-造成此问题容易被放在最后才解,并且也造成双方不信任或是气馁2.出现在像email形式的讨论-不要出现太多废话,毕竟bugreport是一种techre
你要report一个bug时,若是你并不知道rootcause,请确认你会把以下信息放到bugtrackingsystem中:#screenshots#logfiles(localandserverifyoucangetthem)#machinestats(CPUusage,memoryusage,disk,etc…)#whatwashappening:*Whatwereyoudoing(step
要测多少才足够呢?这答案会根据你所问的对象而有所不同.不过其中一个答案,应该会有人回答你要达到100%测试涵盖度.但是也会有人说那不重要,重要的是你应该根据测试结果的质量来决定,测试涵盖度不会告诉你任何有测试结果或是程序代码的质量.来自ObjectMentor的TimOttinger写到:http://blog.objectmentor.com/articles/2007/05/07/unit-t
这里有列出开发人员常去的前100大blog(2009Q1统计的),此外在这里你可以看到excel文件的数据http://nooperation.typepad.com/files/top100devblogsq12009.xls其中和测试有关的blog如下(如果我没选漏的话):TTLTBlog/SiteAuthor/Twitter1925HighScalability(various)2761Ja
昨天老板和我们分享一个想法:除错只能靠DebugLog吗?他说到他来公司已经不少年,可是对于公司的一件事情还是不是很习惯.那就是engineer要解决一个bug时,总是要求说要提供debuglog给他,否则他们就无法解这个问题.对他来说,这事件很不可思议的事.因为解决问题的方法很多,并不是只有看debuglog才能解决,而且这可能是你不肯动脑的借口,只想让人把线所放到你面前.更糟的事,这线索可能是
最近在测试时遭遇到一个问题:当用户在执行我们的产品,同时也在执行其他软件,像是ftp,听音乐,上网,烧片子,用MSOffice,MSN,facebook...等等,可能会造成系统缓慢或是不正常.我们的QA大部分时间都在执行funcationaltesting,也就是确认我们系统的功能是否正确,因此在他们执行过程中不会去执行其他软件,因此也就没有遇到这种状况.或许有些QA会想说要做兼容性测试(com
热门文章