进入互联网行业快一年，感受之一就是，软件测试进入了一个新的时代。这个变化几年前就发生了，只是我之前没有感受到。我2001年开始做软件测试，那个时候真是软件测试的蛮荒时代，从业的人少，资料少，交流少，收入少。书店里只有几本相关的书籍，都是老外写的。国内的也有，只是大多是在软件工程的书里设了一个章节顺便介绍一下。几年后，各种软件测试的沙龙办起来了，也慢慢有了本土作者写的软件测试的书。当时，大家除了交流
又被拉到围城里。什么是全栈工程师在现在这一个时代来说，不会有人掌握所有的编程语言、技能，以后应该会有，但是掌握这些全部技术的不是人类了。所以，其实我们需要的是懂得多种技术的，并能借些独立完成产品的人。当我们需要做一个移动CMS的时候，我们就会在不同的技术栈之前选择，或是RequireJS+Backbone+jQuery+Mustache，又或者是ReactJS+Backbone，当然也有可能是An
假设正在读这篇文章的你是一名黑盒软件测试人员，请思考这样一个问题，如何向开发同学报一个BUG呢？或许我们每一个人心中都有自己的答案。这答案或者是许多人都在用的一种格式、步骤、流程甚至模版，或者是项目组内大家都认可的一种形式，又或者是带有自己独特风格的一种方法。其实，不管是哪种方式，我们报一个BUG的目的都是相通的，那就是向开发同学清晰的描述BUG的复现步骤、特殊条件、出现机型、复现率等对于修复该B
前文回顾上期小明独当一面，解决了突发问题，受到leader认可，自己很开心、很有成就感。本期故事9点整闹钟响起，小明以最快的速度洗漱完毕，奔向公司。（在去地铁的路上买了2个包子，你懂的~）9点50左右，抵达公司，开始投入到忙碌的工作中……（此处省略白天中午下午一系列活动）小明起身做了一个伸展运动，自言自语说："搞定"。下意识看了一下表，"我去(ˇˍˇ)，23:55了，
工欲善其事，必先利其器。选取一套优秀的白盒测试框架组合，无论对于我们的白盒测试效率还是质量，都有很大的帮助。那么我们应该怎样选取呢？这里编者简单对当下比较流行的iOS单元+集成测试框架进行对比，并介绍一种个人感觉很优秀的测试框架的搭配。单元测试框架的选取现在比较流行的就属Apple自带的XCTest、第三方的GHUnit以及BDD类型的框架如：Kiwi等，那么他们各有什么优缺点呢？XCTest：我
随着公司的扩大，有机会可以做leader，但本心上我是不愿意管人的。一、很多人都有管理恐惧症，我也不例外，作为一个理科生，觉得管人很麻烦。二、觉得自己喜欢技术且适合做技术。三、觉得管理都是动嘴皮子，技术才是实打实的真本事，管理就是政治，尔虞我诈，太假了。所以leader问我的时候，我当时不是很想做，后来让我思考几天，我想到了几个场景：我的leader对我说，其实有的时候，你去做选择，你自己都不知道
持续集成的目的是为组织提供快速反馈.而反馈的唯一途径则是测试.手工测试无法满足集成的频繁程度和时效性的要求,我们需要自动化测试,并将其内建在开发过程当中.另一方面,持续集成可用于辅助实现持续部署.在互联网时代,将产品的新功能和缺陷修复部署到生产环境中的节奏越来越快,越来越频繁.要安全无风险的部署,完善的自动化测试不可或缺.因此从某种程度上来讲,自动化测试跟持续集成基础设施同样重要,如果不是更重要的
以下是我的个人经历，可以作为一个案例参考。最后尝试总结。我近年展开新软件项目时，都尽量以测试驱动的形式开发，常常有不少的单元测试。然而，之前尝试用gcov/lcov的结果有点问题，也没有加入连续整合（ContinousIntegration,CI）中，并不太关注覆盖率。或者更坦白地说，写程序二十多年来，也没怎么做覆盖率的分析。我问这个问题之时，正在为RapidJSON的正式版做准备。刚刚上周末看到
知乎上有人问：“历史上有哪些红极一时却最终消失了的产品和品牌？”瞬间勾起了大家的怀旧情绪，尤其是70后、80后，对于上世纪末到本世纪初的那些经典软件和网站，肯定还是记忆犹新、历历在目。其中一位用户“Mr.Gidot”，更是生猛地拎出来一大堆老软件、老网站。看着看着泪就下来了啊！一起来怀旧软件和网站吧（排名无先后）：东方快车汉化超级解霸金山游侠金山快译CCEDUCDOS网络蚂蚁WinAMPWICQN
作为一只本科非计算机专业的程序猿，手动写单元测试是我从来没接触过的东西，甚至在几个月前，我都不知道单元测试是什么东西。倒不是说没听过这个词，也不是不知道它的大概是什么东西——“用来测试一个方法，或者是一小块代码的测试代码”。然而真正是怎么做的？我并没有一个概念，或者说并没有一个感觉。记得第一份工作在创新工场的时候，听当时的boss@王明礼说，公司有个神级的程序员（。。。名字忘了。。。），他会写大量
热门文章