我的软件测试职业的4年光阴

　　软件测试岗位同一个业务产品不知不觉已经经度过了4个多年头，也是自己现有唯一的工作经历。为自己负责，对4年光阴进行一下回顾总结：庆幸这4年多也不是一成不变，每年基本都螚有新的形式挑战。

　　算来也是经历了产品测试工作的几个时代吧，浅谈一下自己对几个时代的感受。(PS：按个人感觉分的时代有片面性，老了记忆也不太牢靠可能发生时空穿越，有不正确的地方还请大家见谅!! 谢谢)

　　零时代.只有Dev无正式测试工作(没亲身经历过，列在这里算全面一点吧，呵呵)

　　【时代特征】软件开发的初期，只需要唯一的核心人员：Dev。 编码完成后,无专职Tester也没有正式的测试工作，Dev按照自己对软件功能要求，随便进行操作验证，觉得没问题后就算测试结束，即可软件发布。

　　【时代优势】自由开发自由测试，相信“自由”会让现在的很多Dev激动不已，呵呵。

　　【测试定位】 无

　　【不足困难】软件功能点多了后，为保证质量需要测试执行的功能点变大， Dev们自己负责会觉得浪费时间;没有正式测试计划的情况下也很难保证质量。 觉得还是需要专职的测试人员好了

　　时代一. 纯手工测试(自己应该是抓住了这个时代的尾巴,开始工作时业务线组内很多人也是纯手工的)

　　【时代特征】 1. 测试工作纯手工完成，能弥补零时代不足，即：释放Dev劳动力，让他们可以专心的开发; 保证测试质量，开展正式测试工作：测试设计+TC编写+测试执行+产 出测试报告。 2. 测试工作门槛低，逻辑清晰的实习生稍微学习一下就能胜任。工作重心从用户需求角度出发，进行测试

　　【时代优势】 劳动分工Dev的效率提高了;专人负责测试工作产品质量更能得到保证

　　【测试定位】 1. 从产品需求出发开展测试工作，产品质量的守护神。 产品上线质量好就可得到PD(产品经理)，Dev的肯定，实现价值。 2. 守护神对质量要求高，一些需求小点也可以和Dev拉锯几天。

　　【不足之处】 测试工作效率不高往往成为研发环节的瓶颈。面对互联网产品迭代开发的模式，重复工作量大，纯手工太累! 需要需求方式提高测试工作效率

　　时代二. 尝试小部分自动化(准确的说我参加工作时，已经是这个时代了)

　　【时代特征】 依然是手工测试为主，业务线团队中开始尝试页面自动化等。

　　【时代优势】 脚本覆盖主要流程，可以逐渐替代之前每次发布前人工手工回归的工作。释放了测试人员部分机械的重复工作

　　【测试定位】 依然是产品的质量守护神，开始用技术手段提高工作效率

　　【不足困难】 自动化刚起步，需要进步提高自动化覆盖率

　　时代三. UI和API自动化搞起(自动化持续集成，成为发布前标准)

　　【时代特征】 尝到自动化的甜头后，测试团队全员都开始投入自动化工作，UI和API全面开花。 建立自动化持续集成， 自动化成为发布前标准等

　　【时代优势】 自动化工作蓬勃发展，覆盖率大幅提高。 自动化释放了很多手工测试工作

　　【测试定位】 手工向自动化测试转型，论证把尽可能多的工作用自动化手段实现

　　【不足困难】1. UI和API都是集成测试，覆盖率到达一定地步后，遇到瓶颈。对系统和外部交互较多的产品线， 例如：电子商务网站的交易业务产品要交互应用(用户，商品，物流，支付，优惠，各种交易模式涉及的应用，各种交易渠道涉及的应用，各种特殊服务涉及的应用等)会较多， 集成测试依赖真实外部环境，导致脚本维护确认成本大。 2. 业务发展需要，系统承载业务功能点愈来愈额庞大，又需要较快速的响应多业务方在系统中的迭代开发。 即要求：测试工作量变大情况下 ，更加高效率。面对瓶颈，测试不得不寻求新的突破点

　　时代四. 拉开发下水：质量不是测出来的，是开发出来的

　　【时代特征】 测试退去质量守护神光环，拉开发下水：提倡开发自测，坚持提测标准，让开发开展UT。代码review，要求开发更精准的评估每次迭代。

　　【时代优势】 测试对质量保证发现了一个新大陆，看到解决时代三矛盾体的希望了

　　【测试定位】 综合考虑质量成本效率，更多的关注系统持续迭代的质量; 退去守护神光环， 对一些小的业务需求点不会和开发死磕到底了。

　　【不足困难】 Dev面对这些新的质量保证工作，时间成本个人情感什么也不一定能承受，几项工作开展的效果如何，就不能一概而论了‘

　　时代五. 测试深入系统，开发掌握测试工作

　　【时代特征】 1. 三军整合：之前海陆空(UI，API，UT)各军都有一定发展基础，考虑效率成本等需要整合。 2. 测试UIAPI和开发UT整合时，考虑资源统一协调，提倡大家熟悉系统。

　　【时代优势】 对系统进行剖析，测试更加熟悉系统，开发也更加熟悉测试工作

　　【测试定位】 测试工作还是让熟悉系统代码的人负责协调，优势原因：熟悉系统能更好的协调3军， 能更精准的评估每次迭代的影响范围保证质量。

　　【不足困难】 测试工作向开发转移，但人力资源还没有跟上，Dever承受不了新增工作量。 后续：希望开发/测试比提升，熟悉测试的人员向开发岗位转移。

原文转自：http://www.taobaotesting.com/blogs/2399