紫晴的阅读
搜狗测试第二年：时间规划篇
前文回顾上期小明独当一面，解决了突发问题，受到leader认可，自己很开心、很有成就感。本期故事9点整闹钟响起，小明以最快的速度洗漱完毕，奔向公司。（在去地铁的路上买了2个包子，你懂的~）9点50左右，抵达公司，开始投入到忙碌的工作中……（此处省略白天中午下午一系列活动）小明起身做了一个伸展运动，自言自语说："搞定"。下意识看了一下表，"我去(ˇˍˇ)，23:55了，
266°/
2015-07-14/2661 人阅读 / 0 人点赞
/ 0 条评论
【iOS测试】白盒测试框架的选取
工欲善其事，必先利其器。选取一套优秀的白盒测试框架组合，无论对于我们的白盒测试效率还是质量，都有很大的帮助。那么我们应该怎样选取呢？这里编者简单对当下比较流行的iOS单元+集成测试框架进行对比，并介绍一种个人感觉很优秀的测试框架的搭配。单元测试框架的选取现在比较流行的就属Apple自带的XCTest、第三方的GHUnit以及BDD类型的框架如：Kiwi等，那么他们各有什么优缺点呢？XCTest：我
479°/
2015-07-09/4791 人阅读 / 9 人点赞
/ 0 条评论
性能调优, 你的力气用对地方了吗?
做过性能调优的同学都知道,最怕的不是性能差,而是费了半天劲在细节上死抠,却忽视了另外一整个对性能有巨大影响的维度,旁边放着一西瓜却使劲在芝麻上雕花.针对这种情况,<<PerformanceTuning:AComprehensiveGuide>>的作者梳理了影响性能的几个维度,具备一定的完整性,新手可以按图索骥的去调优,老手也可以拿来参考看看是否漏掉了某些事半功倍的方法.这里
221°/
2015-07-08/2211 人阅读 / 0 人点赞
/ 0 条评论
搜狗桌面产品测试部总监的肺腑之言
随着公司的扩大，有机会可以做leader，但本心上我是不愿意管人的。一、很多人都有管理恐惧症，我也不例外，作为一个理科生，觉得管人很麻烦。二、觉得自己喜欢技术且适合做技术。三、觉得管理都是动嘴皮子，技术才是实打实的真本事，管理就是政治，尔虞我诈，太假了。所以leader问我的时候，我当时不是很想做，后来让我思考几天，我想到了几个场景：我的leader对我说，其实有的时候，你去做选择，你自己都不知道
233°/
2015-07-07/2331 人阅读 / 0 人点赞
/ 0 条评论
你为什么从中国移动离职？
1、我的基本情况2000年入职，先后从事过基站维护、网络优化、新技术研究、网络管理、全业务支撑、政企客户响应。辞职前任省公司三级经理，绩效A+，薪酬税前约3x万，没有期权。获过集团先进个人一次，省公司先进个人两次，集团和省级的科技进步奖若干个，流程优化一等奖两个。给全国各省的中层干部讲过课，负责过比较大的项目。回顾这些年，值得自豪的就是：一直认真工作，没有收过黑钱，交了许多朋友，问心无愧。2013
214°/
2015-07-06/2142 人阅读 / 0 人点赞
/ 0 条评论
小白看云，一份非主流测试报告
小白工作十载，创业数年，玩云计算3年有余。面对如今互联网+和云计算大行其道，一时兴起，中国的云厂商（百家混战）和洋厂商（如AWS、Azure）做了一番比较。本次比较不是看脸，重在测试性能，小白想给大家分享一些经验（和教训）。由于八年来小白一直奋战在性能测试领域，所以觉得有些基本概念首先需要理清楚：性能&稳定性之我见世俗说的“性能”，Performance，这是一个已经被玩坏的概念，不管是国
217°/
2015-07-02/2172 人阅读 / 0 人点赞
/ 0 条评论
高质量交付，领导要做五件事
1树立正确质量观质量不是靠测试测出来的，质量需要内建，开发人员必须对质量负责开发人员关注外部质量，才能更快地提高内部质量，才能持久地改进质量；2废止不合理KPI测试团队发现的缺陷数：这个指标会阻碍测试人员融入敏捷团队，因为敏捷的工作模式（如实例化需求），会将缺陷埋葬在开发阶段，减少测试人员发现的缺陷，那么，应该用什么指标来替代呢？可以考虑使用这个指标：给定时间内漏出缺陷数目/需求规模，这个指标可以
278°/
2015-07-01/2780 人阅读 / 0 人点赞
/ 0 条评论
“持续集成”也需要重构——持续集成实践在Cruise开发过程中的演进
前言持续集成是极限编程十二实践之一（1999年KentBeck编写的《解析极限编程》），最初被使用极限编程方法的开发人员所推捧，并在过去的几年中得到广泛应用，成为业界广为人知的软件开发实践。该实践用于解决软件开发过程中一个具体且重要的问题，即“确保当某个开发人员完成新的功能或修改代码后，整个软件仍旧能正常工作。”然而，持续集成并非像大多数人想像的那样，首次部署好持续集成环境后就大功告成，一劳永逸了
225°/
2015-06-26/2259 人阅读 / 0 人点赞
/ 0 条评论
自动化测试: 策略及工具
持续集成的目的是为组织提供快速反馈.而反馈的唯一途径则是测试.手工测试无法满足集成的频繁程度和时效性的要求,我们需要自动化测试,并将其内建在开发过程当中.另一方面,持续集成可用于辅助实现持续部署.在互联网时代,将产品的新功能和缺陷修复部署到生产环境中的节奏越来越快,越来越频繁.要安全无风险的部署,完善的自动化测试不可或缺.因此从某种程度上来讲,自动化测试跟持续集成基础设施同样重要,如果不是更重要的
663°/
2015-06-25/6639 人阅读 / 7 人点赞
/ 0 条评论
实际软件工程中是否真的需要100%代码覆盖率（code coverage）？
以下是我的个人经历，可以作为一个案例参考。最后尝试总结。我近年展开新软件项目时，都尽量以测试驱动的形式开发，常常有不少的单元测试。然而，之前尝试用gcov/lcov的结果有点问题，也没有加入连续整合（ContinousIntegration,CI）中，并不太关注覆盖率。或者更坦白地说，写程序二十多年来，也没怎么做覆盖率的分析。我问这个问题之时，正在为RapidJSON的正式版做准备。刚刚上周末看到
301°/
2015-06-24/3011 人阅读 / 0 人点赞
/ 0 条评论