摘要：最近新上的几个测试产品，真心不容易，改天把过程记录下。众测市场：http://hema.aliyun.com安全测试服务：http://sts.aliyun.com/性能测试服务：http://cloud.tmall.com/ptsSelection.htm另外无线测试服务和兼容性测试服务准备7月底...
阅读全文
posted @ 2014-06-24 11:52
随笔分类 - 测试
摘要：垂直化差不多三年，这三年主要做的事用三幅图可以表示：法拉利模式、机器人模式、春联模式。法拉利2011年垂直后，面临的主要问题是如何快速提高测试产能，基于垂直团队的特点，主要做的是任务分级、测试准入及基于风险测试。有朋友看到这幅图后说你这是方程式赛车啊，所以我称它为法拉利模式，目标就是要快，缩短测试周期。机器人在2011年的基础上，2012年大力发展测试基础建设，引入多样化的测试手段，全方位提升产品可测性，当时面临的主要问题是业务规模急剧扩张但团队规模增长缓慢，所以我们的目标是一个省字，大幅降低测试成本，故而我称其为机器人模式。春联2013年在延续前面快和省的基础上，想做到的是多与好，多就是支撑
阅读全文
posted @ 2013-11-29 16:27
摘要：最近很多人问测试服务输出的业务价值是什么，把目前已识别的价值写下来，以后自行观看。注意，很多问题目前仍在调研中有不少细节没想清楚，拍脑袋上产品只图政绩不考虑业绩的事我是不会干的，至于其他人会不会我管不着。试运行的地址就不提供了，提供了你也没权限。商家效率：isv是中间客户，商家是最终客户，提升isv产品质量是中间目标，能提升商家效率让商家更好的开展商业活动才是最终目标，同时也能让商家挑选到更好的产品。数据回流：isv产品的线上运行数据与线下测试数据，只有拿到这些数据我们才能准确评估isv产品质量，才能做到心中有数提前做好风险预防，才能在大促期间胸有成竹处变不惊。以上主要是对内价值。独特性：提供
阅读全文
posted @ 2013-08-10 10:39
摘要：前几周有写过但不小心被删了，最近一直在和不同人群讲今年测试思路，偷懒写下来，以后再有人问就说自个儿看去吧。以基于风险测试为指导，测试驱动开发为核心，加强测试基础建设，提升产品可测性可恢复性，提升测试工程师能力走专精路线，结合多样化的测试手段与持续集成开展全过程质量保障活动。基于风险测试概念不多说，简单讲分为高中低九个区块，所有研发任务会首先进行风险判别，属于高危三区块的测试人员全程参与，属于中危三区块的测试人员提供测试设计支持不参与执行过程，属于低危三区块的开发人员自行完成。从10年就开始说全民测试概念，直到12年实施土壤才逐渐形成，一专多能复合型人员是未来发展趋势，细节不多说，这里主要谈一个
阅读全文
posted @ 2013-04-19 15:52
摘要：测试管理FAQ三。测试开发比多少合适？1：3？1：10？作此统计纯属扯淡，分析团队产能有很多指标，这是最不靠谱的一个，但偏偏不少人就是喜欢，由此不知误导了多少老板。测试开发工作量比多少合适？5：5？5.5：4.5？这个更扯淡，世间万物千变万化，就是一般情况也无法套用此比例，误人子弟。要说世间万物是否有其内在规律，我信，但规律远远不是一个单纯比例能够汇总的，之所以很多人喜欢用是因为它简单，不用了解太多细节不用做深入分析简单粗暴的一个比例搞定，小团队长年累月做那么几个产品还好说一点，团队规模越大业务越复杂越是不能套用，作为一名合格的管理者，准确评估团队产能团队整体性能是必做功课，是必须掌握的技能，
阅读全文
posted @ 2012-10-29 16:19
摘要：工作定位：测试管理（组织、协调、培养、发展，过程控制优化……），偏向于对团队的管理。业务测试架构（测试任务分析、技术支撑、工作量判断、人员分配、风险评估……），偏向于对业务测试的支撑，各式各样的业务测试活动应如何开展。产品规划设计（业务发展、产品架构、技术团队走向定位……），偏向于开发工作，向开发架构师、开发主管方向发展。目前挑战：人员规模不增长业务支撑增长迅速，工作方式转变团队转型要有清晰的思路，为保证成功转变需要哪些基础建设，在基建的基础上渐进式的进行变化，与协作团队达成一致，尽量控制风险，在某些特殊任务上仍然需要采用传统方式。目前已支撑业务：服务平台、汇金平台、数据分析、旺旺分流、摄影市
阅读全文
posted @ 2012-07-10 11:35
摘要：活动时间: 2012年7月8日活动地点：杭州海外海国际会展中心·广场活动报名官网：http://adc.taobao.com/carnival/ 活动举办方：阿里巴巴技术协会本次主题：1、Athrun淘宝无线测试平台2、豆瓣ios自动化测试实践和经验3、Leverage Virtualization in Software Test4、Fault Injection5、Tester,One Step Forward 测试向前一步6、XPP（Extreme Programming Practice）7、分布式系统测试实践8、移动测试中心BMTC详情：http://www.taobaot
阅读全文
posted @ 2012-06-19 14:11
摘要：目标：团队规模缓慢增长，业务规模线性增长，如果能支撑的住指数增长那就更好。简单讲就是多快好省。阶段：l 测试门槛降低：上半年一直在做的，让测试越来越简单。l 测试持续深入：已经开始运作的，专业测试做更专业的工作，门槛降低后可发散的测试工作会越来越多。l 测试模型建立：上两步成功完成后，综合各种方法手段确立业务产品测试模型，服务、汇金、开放、数据等等产品依据模型开展测试活动。此为下半年重点。l 全过程控制：类似TDD的思路但并不全是，不局限于测试领域，站在整个研发体系进行质量控制。说白了，给个工作框架，照这样做，就对了。指导思想：l 针对垂直化团队：模糊产品、开发、测试界限。l 针对电商服务支撑
阅读全文
posted @ 2012-06-12 11:04
摘要：测试管理FAQ二。1、 人员流动好吗？首先注意人员流动和人才流失的区别。人才流失是一定要控制的，当然如何评判是不是人才这是门学问，有道是千里马常有而伯乐不常有，本文不展开此问题。而正常的人员流动是很有必要的，吐故纳新并不一定是坏事，所以我们才有轮岗才有末位淘汰。我想任何老板都不希望自己团队成为养老部门。测试工程师有别于其他技术人员的一个明显点是对于技术广度的掌握，这是工作性质所决定，必须先了解待测产品的各种背景才能正常开展测试活动。有鉴于此，我们应该多鼓励测试人员的流动，也可以进行更多的虚线管理。核心思想，我们不用过多关注工作到底是由谁来完成，应更关注我们有哪些工作这些工作有没有被完成。用个简
阅读全文
posted @ 2012-05-08 15:59
摘要：测试管理FAQ一。1、 测试团队结构是怎样的？大多数测试团队，或者说传统测试团队，一般按照测试类型构建团队体系，如图所示：优点：职能划分明确。缺点：技能发展单一，协调成本较高。有部分团队按照测试粒度构建体系，如图所示：优点：测试提前。缺点：测试成本偏高。还有的按照测试阶段或者说测试能力构建体系，也就是通常说的流水线，如图所示：优点：测试速度快。缺点：测试职业发展容易形成瓶颈。有极少数团队按照测试专业程度构建体系，这也是目前甚嚣尘上大肆鼓吹的结构，如图所示：优点：测试成本低。缺点：容易脱离实际业务。上面几种结构本身并无高下之分，可结合团队实际情况进行选择。笔者所处团队的结构目前是第一种、第三种和
阅读全文
posted @ 2012-04-18 17:31
摘要：本文为分享会而准备，保持一年一次的传统，照例开篇公告诸位：下面会有大量个人思想，不喜勿看。国标：这东东真不想讲，涵盖的内容非常多，这里摘录几个主要质量特性，有兴趣的可自行查阅资料。l 功能性：与一组功能及其指定的性质有关的一组属性。l 可靠性：与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。l 易用性：与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性。l 效率：与在规定的条件下，软件的性能水平与所使用资源量之间关系有关的一组属性。l 维护性：与进行指定的修改所需的努力有关的一组属性。l 可移植性：与软件可从某一环境转移到另一环境的能力有关的
阅读全文
posted @ 2011-12-20 16:22
摘要：现在拆分出来自己玩了，招聘压力很大，各位朋友看看：http://bbs.51testing.com/thread-165124-1-1.html
阅读全文
posted @ 2011-08-08 15:31
摘要：团队如何规划测试手段？1、了解产品特点、团队特点。了解渠道最好是经历一次完整的项目。2、结合产品、团队特点引入业内已有手段。例如测试管理用QC，界面自动化用QTP、watir，单元、接口、集成测试用junit、nunit、cppunit、dbunit，太多不一一列举。大多测试团队均处于此阶段。3、自主研发。刚开始主要结合实际工作开发小工具，此类工具不具备太多通用性，针对性很强。例如汇金需具备以下工具：测试环境监控：告警、监控、排查、解决。持续集成框架：自动化测试脚本框架、脚本集中管理、自动运行、自动发送报告（报告中需初步定位问题）。知识管理：业务、技能知识管理，轻松搜索、导出；工作交流。业务测
阅读全文
posted @ 2011-08-06 16:23
摘要：作为产品测试团队，它最关注的应该是什么？它需要不断优化、发展的是什么？经常提到的落地于它而言具体是什么应该怎么做？单就产品及团队而言有两个目标：第一，快速响应业务需求，快速响应市场变化，快速解决线上问题；第二，保持系统稳定，减少线上故障。这是互联网产品、团队的特点。某种意义上说，为什么总加班也与此有关，因为你要快速响应快速变化。同时，快速与稳定就像常说的进度、成本、质量一样，没有绝对的只有相对的，有时候甚至是悖论。那如何找平衡？首先要在组织结构上保证。举个例子，下半年所在团队组织结构会调整，以产品接入、故障解决两个团队为尖兵，它们的首要任务是快速。然后系统优化、结算、底层系统等团队作为大后方，
阅读全文
posted @ 2011-07-30 18:01
摘要：什么是务实？我开发个测试工具出来，看得见摸得着，这叫务实。仅此就够了吗？那人家什么时候用工具，应该怎么用甚至用不用，这些问题咋办？所以要提到一个概念：务虚。什么是务虚？规划、设计应该开发怎样的测试工具，开发完成后指导、引领他人使用，告诉他人在何时何地用何种工具可以解决何种问题，这就是务虚，因为这些工作看不见摸不着。举个例子，兵工厂制造武器弹药，制造的目的是啥？是为了给前方士兵打仗用。如果制造的武器士兵不会用或根本用不上，那制造出的武器还有意义吗？好比我现在打场内战，兵工厂提供我原子弹或化学武器，我能用吗？即使使用后打赢这场战争，土地我能要吗？因此，做测试产品乃至做任何测试工作，都应包含务实、务
阅读全文
posted @ 2011-06-23 11:10
摘要：前两天出的线上故障：一批量审批功能，对当前页显示的所有记录可以一次性审批。同时，每页显示的记录数可以在页面上直接修改。当每页显示20条记录时，批量审批没问题；当每页显示80条时，批量审批仍只审批了20条；当每页显示80条并跳转到最后一页进行审批时，最后一页的所有记录（44条）均被审批。这里不探讨故障原因是什么，主要说下为什么会出现漏测，怎样才不会漏测。我一直在说我们做测试不能学土八路，拍脑袋做测试设计，经验主义害死人。需要有专业的测试理论来指导我们做设计，这是测试人员的专业技能，是有别于开发人员的主要技能。这里附带鄙视下部门的某些人某些观点，整天要求一线测试人员编码，说只有这样才能晋升，搞得业
阅读全文
posted @ 2011-03-18 13:49
摘要：测试人员和开发人员的比例应该多少才合适？拿两个业内最典型的公司也是大家最喜欢讨论的公司来举例：微软和谷歌。先说微软，老牌软件公司，有钱，资源充足，测试开发比基本稳定在1：1。当然，这说的是一般情况，或者说是平均情况。再说谷歌，新兴软件公司，有钱，资源充足，测试开发比基本稳定在1：10。当然，这说的是一般情况，或者说是平均情况。为啥两家都有大把钞票的企业此比例会迥然不同？原因当然很多，但重点是在测试理念的不同。微软推行的测试理念偏传统，而谷歌推行的测试理念是大量的测试工作交由开发人员自行完成，测试人员主要提供完善的测试工具。这和笔者常挂在嘴边的智能化测试类似。笔者一向以为，未来的测试发展方向必然
阅读全文
posted @ 2011-02-23 14:42
摘要：前言软件测试发展到今天，已经逐渐形成一门学科，但是还不够系统。初学者面对铺天盖地的资料应该如何选取？应该从哪里入手？如何迅速的掌握各种业务各项测试技能以便开展工作？在保证测试质量的前提下，一日内编写或执行1000个测试用例是不是梦想？入行多年者面对复杂的业务逻辑，海量的测试需求，如何在最短的时间内进行测试？如何尽可能更早的开展测试？如何对系统架构进行测试？如何全面提高测试质量与测试效率？如何百尺竿...
阅读全文
posted @ 2010-11-23 13:27
摘要：最近发现一个现象，大家都在谈软件测试的未来在哪里，你也谈他也谈并且是大谈特谈。那么我心中的软件测试未来是啥？其实一直没变过，测试智能化。测试自动化不是银弹，现在已经有不少人认识到了。为什么不是？具体原因有很多，但根源是因为自动化是智能化发展的衍生产物，或者说是过渡产品，它本来就无法从根源上解决测试的问题。自动化面临的最大问题是，门槛高维护成本大。那么此时的发展方向在哪？测试傻瓜化。也就是说，测试入...
阅读全文
posted @ 2010-11-23 13:25
浙公网安备 33010602011771号