我们知道，只要有软件就会有bug。一者，再严格的测试也只是抽样活动，总会有bug被遗留下来。再者，做软件也是一种商业行为，对质量的投入要看ROI。基于以上两种原因，软件或者系统发布时总会或多或少带点bug。对于这些bug，我们要看它的影响程度是什么样的。对于生命周期比较长的系统，这些bug只要产生了影响都是要修改的。在我上篇文章《测试的最高境界是什么？》中给出了软件不同周期中缺陷修复所需要的成本的
今天参加了单位组织的测试架构师培训。外部的咨询老师问了我一个问题：做测试最高境界是什么？我当时给出的仓促回答是：“帮助你所在的组织改善树立正确的质量观念；帮助所在建立起有效预防和发现bug的流程体系与技术栈。”限于时间，这个问题没有展开深入探讨，却让我总是忍不住去想它。做测试最高的境界是什么呢？仔细思索后，发现我这个答案还挺不错的。最高境界代表着极致，极致就是在已经达到非常好的时候还在不断的追寻：
昨天晚上微博上有测试同仁@testGM想了解下如何从传统ERP测试向主流互联网测试转型。我本人在来淘宝之前就是做传统ERP测试的，现在在淘宝做了这么长时间，对互联网测试也有一定的了解，就想谈谈自己的看法。特意说明下，我这边了解到的传统ERP测试就是4或5年前的ERP测试情况，不代表目前的整体情况，说的不对的地方望谅解。整体策略：谈过如何转型，那就是知己知彼了。首先自己要了解传统ERP测试的优点和缺
专业的咨询师不仅需要对新兴的技术和趋势有足够的好奇心去探索，也要能够对过气的技术工具有自己的评价，这样当客户咨询师为什么做这样的技术抉择，而必须放弃手头已经的技术投资时，才能有足够的说服力。这次要介绍的是2013年12月版ThoughtWorksTechRadar中的HeavyweightTestTool条目，状态是Hold。Hold就是建议停止使用。建议停止使用重量级测试工具，有很多角度和因素的
译者注：本文来自Facebook工程师团队博客两年前，我们重写了我们移动端（iOS，Android）的应用，使用了原生的开发栈（nativedevelopmentstacks）代替我们以前定制开发的Web栈(customweb-stack)。这给了我们在关于项目在那里/怎样下载、缓存、释放等等方面一个更好的控制。它分别深入地和操作系统整合在一起，提供在底层调整修改所有系统的一整套工具。测试是我们开
译者：蔡小滢在软件开发上任何花费时间少于十分钟的都是非常琐碎或者优先级不高的。如果你使用这个准则来衡量事情的价值，那么你打算怎么看待测试计划呢？当然，要进行一个测试计划所花费的时间是不止10分钟的。在我担任Google测试主管时，我带领过一个写大量测试计划的团队，每每询问到完成一个测试计划需要多长的时间，我总被告知「明天」，「这周末」或者有几次被告知「今天晚些时候」。所以我会理解为完成一个测试计划
作者@散步的SUN序言：测试开发部门做自动化测试很容易脱离测试项目去做，仅仅为了做自动化测试而做。开发部门做自动化测试很容易考虑不够全面，但是在自动化测试开发、维护性和复用性以及可测性上结合比较好。测试部门去做自动化测试，对测试项目理解比较深，对自动化测试的应用也比较能理解，但是却无法开发应用比较好的自动化测试系统与框架为之服务，自动化测试只是作为测试的一种辅助手段，而每个人都术业有专攻，我们需要
作者：@季哥_岁月无声2012年是移动互联网年，我学习了O-C的开发，开发了较多的功能和内容，对于开发的过程和开发后的质量，以及开发自测有了新的认识。此前一直站在测试的角度去思考开发如何做测试，如何自测，如何共同保证测试。当时觉得不是很有难度，应该可以这样做，应该可以做到什么程度。现在对这个问题有了一些新的看法，也顺便讨论我从从事测试行业以来，如何处理开发能力和测试能力的平衡，内心的所思所想，作为
作者：XingBinbin(测试工程师）摘要众所周知，自动化测试可以一定程度上减轻测试人员负担，提高测试效率，并且通过自动化还可以实现可靠性测试和性能测试。对于移动客户端测试而言，如果我们能够让手机自动运行应用程序来帮助我们检测功能的正确性，会不会很酷？有道测试组对一些热门的手机自动化工具进行了调研，并选择了一些工具进行实际的使用。本文将会结合实际工作，对移动客户端（Android&iOS
「移动至上」已然是如今许多公司的宗旨了。然而想要合理高效地去测试一个移动应用程序却绝非那么简单。今天Google+团队，我们将和你一起分享在iOS和Android两个平台上通过不断尝试总结出的成功经验和走过的弯路。总体而言●你需要熟悉和理解平台。在Android和在iOS上测试是存在着一些差异。这两个平台可用的测试工具和测试框架也是截然不同。（比如，在开发语言上，Android使用的是Java与此
热门文章