最近一段时间，在登月项目中接触到一个涉及数据对比的工具，需要对hdfs上的一些原始数据进行按行解析，并重新保存成可被hive识别的数据文件。作为一个复杂度不高的应用MR并行计算框架的工具，设计制作过程还是很顺利的，两三天的功夫编码完成，自测也通过了，然而上线使用后，却发生了一个意想不到的bug，在解决该bug的过程中，我有幸从中获得了一些新的技术启发，也许对大多数技术人员来说只是一个常规到不值一提
测试提前进行的越深入，越体会到了解系统架构的重要性，参与到技术方案评审，不仅是听，还要评，进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等举几个技术方案阶段关注并改进的例子.性能考虑关注方向：系统调用、单个\批量，串行\并行，读tair\读db例子：qc系统资质验证的过程是，业务系统发起验证一颗资质树（多个资质）的请求，资质系统获取请求后，从多个业务方系统获取数据并和要求值进行对比，将
在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动测试我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵,尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地,手动测试常常能触发某些你无法预期到的软件使用行为。这是一个18个月左右的长期项目,后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能
我不清楚别人,反正我是可以很容易被分心的。比如，我检查自己的电子邮件,看看我的Facebook,Linkedin。我们生活在一个可以通过多渠道获取信息的世界里。我认为这是一些伟大的事物,但它有时让你效率降低。这里有5件事可以帮助你成为一个更有效率的测试人员。不要进行多任务你也许是世界上最擅长处理多任务的一个人。然而,这意味着你正在为自己的任务而瘦身。当我们执行测试的时候，需要很高的集中力和注意力。
技术写手的工作任何一个人都可以做。这份工作并不需要任何真正的技巧，因为它仅仅是写文本。更何况，通常情况下技术写手往往不能牢固掌握他们正在记录着的技术。他们只是问一些，什么样的功能是应该做的，然后他们把开发的话写下来，也许增加一个章节和一些修饰的文字。有没有想过这样一个问题？事实上，人们有时候也会用这种思维，类比测试人员。任何人都可以做测试。做测试只是需要有一个人站在产品面前，点击一下鼠标，或者给出
快毕业的通信学生，之前正式代码经验几乎零。目前在已经给Offer的公司实习安卓开发。Mentor说先从找codebase中bug开始。但是我感觉我们的codebase好复杂，这几天突然没什么进展。uml之类的也画了不少。想问问前辈们有什么建议？update：感谢各位分享自己的经验。这段时间略有进展，就来说说自己的体会吧。1、首先，我是很认同mentor让我从修bug开始慢慢掌握codebase的。
这篇文章从去年很早就想写，一直没时间，刚好过段时间有沙龙是讲这方面的东西，整理了下就有了下文。以往安全爱好者研究的往往是app的本地安全，比如远控、应用破解、信息窃取等等，大多人还没有关注到app服务端的安全问题，于是在这块的安全漏洞非常多。移动app大多通过webapi服务的方式跟服务端交互，这种模式把移动安全跟web安全绑在一起。移动app以web服务的方式跟服务端交互，服务器端也是一个展示信
昨天看了个电影《摇滚教室》，内容是一个不靠谱的摇滚乐狂热屌丝，偶然机会充当某精英小学的代课老师，他不教孩子科学文化知识，却教孩子们摇滚乐，组建schoolofrock乐队参加比赛。大家都会觉得不靠谱吧，在学校的任务就是学习，考出好成绩，这就是我们从小接受的教育。延续到工作中也是如此，作为一个测试工程师，就要能够努力找出最多的Bug，做出强大的自动化测试平台，构建完美的测试流程和质量保证体系…下面我
测试DAO层最常见的就是直接组织数据，调用相关的方法，然后查看数据库，看看相关数据是否在DB中正确的展示。这样测试，效率低下，容易出错，过多的依赖了人肉。如果选择测试数据来配置，根据配置的测试数据验证相关信息，或许能够达到事半功倍的效果。测试数据配置选择(YAML)在JavaBean中，传统的对象set是这样的：对象属性多时，对象的set显得有些复杂，自动代码生成工具生成的代码较多都是set数据的
传统上,我们作为测试人员，被教导要根据功能features编写测试计划，以及那些测试计划。都慢慢转换成了测试用例。这种感觉就是,不管是管理者还是一般人在测试的时候就觉得,一个功能一个测试用例是好的,两个测试用例是更好,和三个就更加好了....这样如此类推。随着时间的推移，我们尝试执行了多个项目以及多个功能，所以我们慢慢收集到一定量的测试用例，就像松鼠在寒冬前收集好坚果一样。更新:我的同事Scott
热门文章