一个成功的面试,往往意味着,我们职业的阶梯上踏进了一步。目前为止，STH发表了各种测试专题访谈文章。在这个系列的上一篇文章中,收到巨大的反响的是:一个真正意义上的软件测试面试Q&A这将是那篇文章的后续,因为我们的重视我们的读者以及他们的问题。他们的期望就是我们的动力。这里我们对读者提出的问题作出反馈：问题1：在你负责的项目中，你的测试流程是怎么样的?因为所有的项目是不一样的,他们都不遵循完
近年来，智能手机越来越普及，目前它已经渗入到我们生活的方方面面,不仅仅是日常的交流。而其存储的信息也已不限于手机号码，联系人方式，或者是短信内容，其他与用户生活、工作相关的许多活动以及信息都已与这个小小的东西联系在一起了。毫无疑问，智能手机极大地改变了我们的生活方式，它让我们的生活、工作变得更加方便。然而，另外一方面，正是由于它与我们的生活、工作的联系如此紧密，与之相应的安全问题也日益突出，而且需
这篇文章是由我们在SoftwareTestingHelp的特约作者PradeepSoundararajan写的。在我遇到过的成千上万的软件测试员中，他们都有一个观念,就是他们应该在测试和质量上全权负责。他们中的一些人甚至认为作为一个测试人员也赋予他们作为产品质量权威的权利。我要问你的问题是：这是好事吗？这是我的一些想法,同时也希望看到你能考虑一下这些想法。保证产品质量是每个人的责任,而不仅仅是一个
本文首先列举了Dojo应用UI自动化测试所面临的挑战，进而引出设计Dojo应用UI自动化测试的框架时应考虑的一些原则。对于正从事WebUI自动化测试工作的读者（即便所测试的应用不是Dojo应用）或者对这方面感兴趣的读者，本文都有一定的参考价值。随着富Internet应用（RIA）的不断兴起，各种JavaScript开发工具包的功能也在不断增强，Dojo正是其中的佼佼者。Dojo提供了一套完整的开发
毫无疑问这个观点会引起争议。开发人员测试他们自己的代码——会得到怎样的测试结果?一切完美？是的,开发代码的人通常只能看到产品好的方面，而不想去关注更多的细节。开发人员做测试的主要担忧是,被曲解的需求。如果需求被开发人员误解了,那么无论开发人员在什么深度测试应用程序,他将永远找不到错误。第一个被认为是BUG的地方将从始至终一直保持现状,因为开发人员会将它看作正常功能。乐观的开发者——是的,我写的代码
又一次,我想和你分享关于软件测试行业的这个有趣的话题。这也是一个在任何组织中都很热门的话题。作为一个测试人员或QA你可以猜一下。对了！没别的——就是测试人员vs.开发人员。测试人员——麻烦制造者这很有趣,几乎所有开发人员都认为测试人员是麻烦制造者。实际上这不是他们的错,没有人喜欢听他/她自己”孩子”的缺点。我们(测试人员)正在做同样的事情,当然背后的意图是向全世界的客户输出高质量的产品。在这两个角
测试行业长期存在的争论之一是，为什么功能测试用例在某种意义上可能是很有用的，是因为:"Manualscriptedtestcasesareagreatwayfornewtesterstolearntheproductwhiletheytest"“当测试新人着手产品测试时，以往的测试用例是一个非常好了解产品的方式”这种说法貌似很有用:“使用GPS来找路，是了解这个城市的极好途径”
最近一段时间，在登月项目中接触到一个涉及数据对比的工具，需要对hdfs上的一些原始数据进行按行解析，并重新保存成可被hive识别的数据文件。作为一个复杂度不高的应用MR并行计算框架的工具，设计制作过程还是很顺利的，两三天的功夫编码完成，自测也通过了，然而上线使用后，却发生了一个意想不到的bug，在解决该bug的过程中，我有幸从中获得了一些新的技术启发，也许对大多数技术人员来说只是一个常规到不值一提
测试提前进行的越深入，越体会到了解系统架构的重要性，参与到技术方案评审，不仅是听，还要评，进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等举几个技术方案阶段关注并改进的例子.性能考虑关注方向：系统调用、单个\批量，串行\并行，读tair\读db例子：qc系统资质验证的过程是，业务系统发起验证一颗资质树（多个资质）的请求，资质系统获取请求后，从多个业务方系统获取数据并和要求值进行对比，将
在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动测试我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵,尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地,手动测试常常能触发某些你无法预期到的软件使用行为。这是一个18个月左右的长期项目,后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能
热门文章