本文首先列举了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个月左右的长期项目,后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能
我不清楚别人,反正我是可以很容易被分心的。比如，我检查自己的电子邮件,看看我的Facebook,Linkedin。我们生活在一个可以通过多渠道获取信息的世界里。我认为这是一些伟大的事物,但它有时让你效率降低。这里有5件事可以帮助你成为一个更有效率的测试人员。不要进行多任务你也许是世界上最擅长处理多任务的一个人。然而,这意味着你正在为自己的任务而瘦身。当我们执行测试的时候，需要很高的集中力和注意力。
技术写手的工作任何一个人都可以做。这份工作并不需要任何真正的技巧，因为它仅仅是写文本。更何况，通常情况下技术写手往往不能牢固掌握他们正在记录着的技术。他们只是问一些，什么样的功能是应该做的，然后他们把开发的话写下来，也许增加一个章节和一些修饰的文字。有没有想过这样一个问题？事实上，人们有时候也会用这种思维，类比测试人员。任何人都可以做测试。做测试只是需要有一个人站在产品面前，点击一下鼠标，或者给出
快毕业的通信学生，之前正式代码经验几乎零。目前在已经给Offer的公司实习安卓开发。Mentor说先从找codebase中bug开始。但是我感觉我们的codebase好复杂，这几天突然没什么进展。uml之类的也画了不少。想问问前辈们有什么建议？update：感谢各位分享自己的经验。这段时间略有进展，就来说说自己的体会吧。1、首先，我是很认同mentor让我从修bug开始慢慢掌握codebase的。
热门文章