天山彤佬

摘要： 本文其实是一篇招聘贴，不管你以前是做开发还是测试，都欢迎加入我们的小组。2014年阿里巴巴的共享业务事业部有很大变化，共享的测试团队也做了一些调整，我不再担任共享业务的测试经理，但是仍然会留在共享测试团队，组建一个名为“稳定性测试&技术创新”的小组，这个小组在组织架构上，独立于会员平台、商品平台、交... 阅读全文

摘要： 本文讨论的团队模型，是基于阿里巴巴（淘宝、天猫）这样比较复杂的电子商务互联网公司；本文讨论的是软件测试的团队模型，开发团队可以参考，但是由于开发和测试工作性质的不同，不能简单的推理为开发团队模型；Part1一般电子商务网站，都有“会员、商品、店铺、交易、评价”这些基本概念，在淘宝网最开始发展的几年，这些产品概念在架构上是一个整体。随着技术架构的发展，这些概念被一个接一个的从淘宝系统中拆分出来，形成一个又一个产品中心，如下图（系统架构图）：底层的这些“中心”，都有独立的测试团队支持；然后接下来几年，业务的发展非常快，除了淘宝网，又发展出天猫、聚划算、旅行等一些独立的业务概念，如下图：上层这些组织 阅读全文

摘要： 一听到初级Bug这个名字，很多开发工程师都会觉得很头痛，还有那个“初级Bug率”，让人随时受不了。初级Bug这个概念，在多数缺陷跟踪工具中，是不存在的，可以说是淘宝研发部的特色。初级Bug对应Bug的一个属性：“Bug深度”，这个属性有三个选项：1很容易发现、2正常发现、3很难发现，其中“很容易发现”的Bug就是初级Bug。深度代表了发现Bug需要的成本和技术含量，初级Bug就是那些非常明显，通过简单的操作就能发现的Bug。从初级Bug这个概念被提出，到现在大约有2年时间。最初的时候，在一次开发经理的周会上，研发部VP提出，开发工程师必须要提高代码质量，不要一提交测试，马上就被测试工程师找出一 阅读全文

摘要： 现在很多软件应用，都设计成2部分：应用程序Application + 数据库DB。要对这种类型的应用软件进行测试，“测试数据”这个概念就非常的关键。测试用例中的“前置条件”，基本就是围绕测试数据来设计的。以淘宝网的测试为例，验证每个功能点时，最重要的就是准备好各种类型的数据对象，比如：不通信用级别的卖家，不同类目属性的商品等等。熟练的测试工程师手里都会保存一批测试数据（比如账号、商品），并且分类管理，不同场景的测试用例，都会有专门的测试数据来支持。在ta的心里，存在着一套完整的测试设计方案，在工作中也会显得游刃有余。要达到这种状态，需要经过一段时间的积累，需要“磨合”。对测试数据的控制力，也是 阅读全文

摘要： 现在亲友聚会的消费方式，AA制已经成为主流。结帐时有人莫明其妙的失踪，或者是一堆人在柜台前扭打抢着买单的情景，已经不多见了。AA制的表现形式主要有两种：1、每次聚会大家轮流买单；2、聚会由固定一人买单，第二天算清每人的消费额度后再分别付钱给买单人。第一种形式适用于聚会成员固定，聚会频率也非常固定的好友聚会。比如每年除夕的年夜饭，姊妹几人每年轮流安排，或者在家里吃，或者到饭店去。每年消费的金额，肯定是不一样的，但是相差不会太多，大家也不会介意。在同事聚会中这种形式有时也采用，并不太多，往往是成员非常固定，消费内容也完全一致时会出现，比如马拉松式的周会后，参会人员轮流请吃工作餐。第二种形式出现最频 阅读全文

摘要： 他们在一个很普通的软件小组里相遇就在那个拥挤的小办公室里那一年他二十三，刚在职场站稳而她二十二，新兵一名他是开发工程师，她是测试工程师两个教科书里永远不分家的职业在房间的角落里，他们静静的坐在一起一见如故让他们很快彼此熟悉紧张的工作缩短了他们的距离有时会有争执，争到面红耳赤有时会很开心，联手解决了难题在他眼里，她是个开朗的小女孩机灵，还带着那么一点固执在她眼里，他是个专注的男人勤奋，深深沉醉在自己的工作里在大家眼里，他们是一对欢喜冤家听他们的交谈，乐趣无穷好像是上个礼拜或者就在昨天他们不止一次在电梯里的偶遇互相为对方拉开透明的玻璃门一个眼神，他们还无法完全解读但渐渐的，他们开始无话不谈那些同时 阅读全文

摘要： ——使用功能点分析来设计测试用例最近有位同事问我，“天彤你搞这个功能点分析算法，主要目的是度量project的规模么，还是度量测试工程师的工作量？”我说，这两个确实是最初的目标，不过现在，这只是功能点算法的副产品，并不是核心价值。“那是不是根据功能点分析，可以自动生成测试用例呢？”这的确是一个很诱人的功能，而且随着进一步研究发现，先用freemind进行功能点分析，然后自动生成一部分测试用例，是完全可行的，不过这仍然是副产品，不是最核心的目标。功能点分析法应用在软件测试中，它最核心的价值究竟是什么呢？让我们先看看软件开发，这是跟测试离得最近的工作类型。开发工程师工作大致可以分为“设计”和“编码 阅读全文

摘要： 2010年底，技术研发部那轰轰烈烈的晋升面试慢慢落下帷幕，有人快乐有人失落。一晃几个月过去了，晋升失败的痛苦慢慢平复，晋升成功的快感也逐渐消退。接下来一个非常实际的问题摆在了我们面前，特别是对那些晋升成功的工程师来说，那就是，晋升成功后，你是不是依然做着相同的工作，跟以前没啥分别。尽管受到一些争议，新的job model在这次晋升过程中，还是起到了比较关键的作用，它明确的定义了各个层级的测试工程师，应该具备何种能力，能够完成哪些不同难度的工作。除此以外，我们几乎隔一段时间就能看到一幅“测试工程师职业发展路线图”，每张画的都不一样，不过中心思想基本差不多，无非是说测试是万金油，可以向多个方向发展 阅读全文

摘要： ——计算逻辑事务的实体、输入DET、输出DET前一篇文章（Part2）介绍了如何划分逻辑事务，文章发表后，大家提出了很多非常好的问题，我这里先简单回复一下，作为我们Part3的引子。Q：逻辑事务分解对于那种“增删改查”类型的功能点比较适用，但是流程类的功能点，就不合适了吧？A：就拿交易流程来说好了，我们在设计交易流程的TC时，是把下单、付款、发货、确认等操作，分别进行设计的，这些操作，其实都是单独的逻辑事务，实际上，开发在设计程序的时候，也是分开做的，不可能全写在一个函数里面。Q：我发现有的逻辑事务，比如点击一个按钮以后，程序既做了查，又做了改，按照你Part2里的分类，是不是应该算两个逻辑事 阅读全文

摘要： 淘宝测试团队的知识沉淀发展到今天，经历了无数风风雨雨，到现在各个产品线的沉淀方式，仍然没有完全统一，处于群雄割据的局面。现在，该是做一个了断的时候了。我们先简单看看淘测试的知识沉淀的发展历史。在混沌初开的年代，大家基本都是用MS Word来编写沉淀文档，然后放在一个共享目录下面。后来wiki概念兴起，产生了很多这一类型的web应用程序，MS share point（SP）是被普遍使用的。淘测试因此把沉淀文档都转移到了SP上，也就是大家现在熟知的“测试人员站点”。SP是非常好的wiki工具，不过有一点被大家诟病，就是SP无法用树形目录结构对文档进行分类。还有一点，当时淘测试有一个规定：每做一个日 阅读全文