测试是什么
测试的独有价值是什么
测试和开发的合理分工是什么
测试的未来是什么
我做了八年测试，完整经历了一个产品从生到死。不可否认，测试一直在为自己的存在寻找理由，几乎没有一个新来的开发认为测试是一个重要的岗位，大多数人认为测试是可有可无的，没了测试也能活，有了测试可以活的更好而已，却不会关乎大局，没有那个局点因为质量问题不用产品了，出了问题开发上去顶一顶快速响应就可以了。测试的价值可以忽略，时间可以缩短，人员可以缩编… 回顾过去，于我而言，技术和产品的关系，开发和测试的关系，是我工作的主旋律，就从这边开始说起…
先说技术和产品的关系
产品很小的时候，技术的活跃程度很高，技术纳入产品的计划非常明显，直白一点，技术形成可用产品，产品的成败直接以技术的实现质量为前提，市场的压力也非常大，技术成为产品开拓市场的决定因素。
随着时间推移，市场占有一定份额之后，产品逐步转向定制和维护，目标只是市场的成功而已,这就意味着可以用更便宜的人力来完成面向市场的定制，可替代性的技术，方法（不局限于技术）出现，变得灵活多变，技术的地位直线下降，其中很多是短期的、暂时性的成功。这里面软硬件规律差别性应该很大，硬件的失效影响度是显而易见的，而软件的失效影响度是弹性的，他的危害可以用人来填补，即反复修复，影响变得不那么明显，攻关流程也短暂很多。
所以，当一个团队，产品不以技术为重要驱动力，那么技术的关注度就会被降低，技术的拥有人也会跟着贬值，日子就会不好过，也许有人会说，修复问题也是靠技术的，没技术解决不了问题。这里澄清下技术的概念，我说的技术是有生命力的技术，当产品某项功能做完后，短期内实现需求，适应需求变动并交付下游使用而且得到下游认可的，才算是真正的技术；反之，如果功能实现后随时都要原编码人员负责修改，那个代码是没有生命力的，一截烂木头而已，这个编码人员也同样会被团队“鄙视”，只有苦劳没有功劳，码农一个，技术也是空有其表没有内在。
不可否认，在这过程中，技术应对市场反应有滞后性，关键是领导层针对技术负面影响态度是什么，这个世界不存在完美无缺的事物，我们是因为它的负面影响而抛弃他？不以他为根基？还是正视他，并且不动根基的来弥补它，面对缺陷短期内克服？同时促进技术的整体更新，长期努力偿还，使整个团队以技术为核心竞争力来实施布局，走一条不大幅偏离技术的道路？
再说开发和测试的关系
这个关系始终纠缠不清，开发测试表面上一个写代码，一个测代码，看上去测试的工作产出以开发的工作输出为源头，开发的代码输出质量越高，测试越轻松，测试质量越高。开发也会有个直观心态，我只负责写不负责测，要是写的代码没问题，要你测试干嘛；极端的例子，见过一个团队搞出一个优秀DNA，把测试管理下放到开发代表层，即产品级管理，独立测试管理不再适应研发的现状，把自己的命革了，推广到全公司。结果证明是短视的，交付整体质量下滑，引发出一系列问题，因为测试资源配比，话语权，技术准备度都无人关注，唯一不变的是测试的目标，守护版本质量，都成了纸上谈兵。而产品交付呢，得益于软件本身的易修复性，面对海量缺陷使用车轮战，人海战术，血肉之躯堵枪眼，一批一批的人走远，一批一批的人走近又走远…
测试遇到的这些过去不公平吗？我觉得公平，因为测试自己也不知道自己是什么，本质是什么，如果抛开公司制度，领导支持，单纯以产品成功，市场大卖，经济价值来衡量，把测试和开发放放平，谁才是真的个大？！我还没找到答案，不过已经有些认识：
单纯从产品角度来看：
开发是破后成，测试是成后破。拿到一份需求，开发把需求一块一块切开（“破”），用代码实现，再一块一块组装起来（“成”）；测试是把需求闭着眼睛摸一遍（“成”），打上标记，然后在开发组装好的实体上一块一块地敲打验证（“破”），可以说思路是相反的。
开发的能力是构造，即不同性质的成；测试的能力是复制，即成再成。举个简单例子，如果开发使用一套架构、代码逻辑完美地实现了产品的安装，过程中运用很多独有的技术和语言，区别于以往任何历史实现，可以说是独一无二的实现（成），那么测试就可以短期内复制安装过程，同类产品不同环境的安装都是可以独立完成，甚至可以复制到其他产品或是改善老产品的安装，让更多的产品来分享这一成果（成再成）。
还有一种“原始”的产品观点：测试职业的存在是开发不自测代码的理由，简单粗暴的划分为写代码，测代码的公工，一写一扔，美其名曰“给测试留饭碗”；这个就不置评论了。
从技术本身来看：
不管开发还是测试，都面对着一个事实，快速变化的需求交付，开发从整体架构上实现了解耦，实现了变化的波动可控，同时解耦后的模块采用敏捷流程，适应了软件需求形势。然而测试跟着开发分散成一个个信息孤岛，久而久之，测试在技术上下文连续理解的优势被割裂，越来越依附于开发需求，唯一的挑战是多变需求要求测试工作量成比例缩减。这一点上，工具的支撑尤为重要，目前已基本适应了变化，测试的自动化执行，自动化设计应付日常多变的测试活动已经很完美。
测试几乎学习了从操作系统到数据库，网络，存储，集群，脚本语言各种计算机知识；随着产品的演进，测试有条件从“破”的角度劈开产品的架构细节，寻找漏洞所在，可以这么理解，测试的思维特点是基于已成型的实现整体，反向剖析产品的价值，可能一无所获，也有可能发掘独有成果，这一独门秘籍估计已经失传，很多年没看到了，很是可惜。
其实，大多软件人心里都是这么想，开发做的好可以不要测试，有了测试，开发反而有惰性，不愿意仔细测试，这个思想的危害极大，开发潜意识里从技术上轻视测试，测试的“前途”就被无形中局限在开发的需求范围之内，当掌握了需求及开发层面的结果后，测试便没有了学习的方向。但这个层次仅是用户的层次，即外围的非专业人士的层次，纯技术角度看，存在的价值意义微乎其微，因为充其量“你”不过是一个非常敬业的用户影子，但只能是影子，修不成“正果”。长此以往，专注测试本身的价值也会渺小很多。又因为测试的视野开阔，测试职业生涯变成一个跳板机，要么转开发，要么转项目经理，不会有人关注测试本身、测试职业的发展了。
现实也是如此，八年的测试一点不轻松，一直在学习，一直在奔跑，尤其是由于成本的压力，产品转合作模式，技术的积累，几乎都是跟着人走，人在技术在，人走技术丢，重复学习代价异常高。耦合的模块团队彼此之间交流只剩下责任的推脱，回溯，缺乏技术的平等交流和互补，每个人心累的要死。
过去已经过去，再看看未来。
目前软件产业两个趋势明显，值得关注：一是大数据，二是开源。大数据趋势表示系统的复杂度越来越高，往往一个完整的产品交付需要自下而上各个层级的消息接入，与之类似的，一个缺陷的出现，自上而下，每个环节都有可能存在问题，不是简单的交付级别代码就能覆盖；开源趋势表示系统的内部实现将扁平化，就是团队所有人都可以无障碍阅读全部产品代码；并且实现的模块可选，即模块的代码不符合产品要求直接丢弃，由产品经理把关产品的架构形态和模块实现。
测试的价值也存在于这一趋势之中，现有软件交付已不在是代码层级的交付，更多是模块级的交付，测试的价值就增加了模块和模块间接口的测试。换句话说，不以代码为直接目标的测试都可以纳入现有测试的范畴。拉通联调测试已成为主流，同时白盒测试要求越来越高。这和软件的事实标准“高内聚，低耦合”也是对应的。低耦合的工作，可以剥离出来作为测试的核心价值之一，而将开发归位到代码逻辑，算法的实现上。
同时，测试作为产品的重要参与人可以给出备选模块的准入评估意见，从而让产品模块架构和入口质量达到最佳状态。
简言之，优秀的研发团队将会是开发测试，SE融为一体。高级开发配对高级测试，组合成对模块接口，端到端需求的落地分解；SE负责评审分解的落地合理性方向性，守护需求可扩展性和价值贡献；低级的开发和测试负责模块内部和接口实现，并且接口实现优于内部实现，如下：
高级的开发+高级的测试è概念层级的把控
低级的开发+低级的测试è实现层级的把控
同样，对于开发，测试产出的度量方式也跟着变化。对于开发的输出，不仅度量代码的质量，还有代码量的多少，产品的使用范围；对于测试的输出，不仅度量模块的质量呈现，也关注接口间整体的质量呈现，拉通传播技术，对腐化的模块质量提出预警，守护产品的价值成果。
时代不同，对劳动者的要求也不同，测试行业伴随软件行业兴起，对测试能力的要求也越来越高，以前是“以一当十”，现在可以说“以一当百、当千”，以前一天测试20个用例，现在一天要100个用例不止！靠肩拉手扛是没有用的，二十四小时轮流转也完不成任务，产生不了附加值，所以未来的测试生产模式需要革新，人不可以只是靠体力来衡量价值，而是更多靠工具，脑力来实现价值，一个人的价值也是体现在对工具的操控性上，唯有这样才能从重复单调的机械动作里解脱出来，更多的面向测试的输入——需求的源头做事，因为同样重要的还有家庭，社交，娱乐，这些让生活更美好。
释放双手，拥抱未来，通过学习软件需求规律的知识，通过极简化的测试过程，让软件价值的原点和测试工作的核心重合起来，更多的思考软件的本质和软件的未来、方向，以及人自身价值的思考。某种意义上说，测试的价值体现在产品和人的需求实现上的匹配度，也是最有可能体会人本质的交互方式，随着测试行业的发展，必然会诞生出世界级的产品价值专家，给各行各业以更多的思考和方向的指引。