软件测试岗位同一个业务产品不知不觉已经经度过了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面对这些新的质量保证工作，时间成本个人情感什么也不一定能承受，几项工作开展的效果如何，就不能一概而论了。
......
本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/33/n-844633.html