上一篇blog（http://blog.csdn.net/superqa/article/details/7216934）贴出来后在weibo上引起了不少同行的讨论，也给了我一些新的启发，继续写一篇，也结合大家不同的一些观点。
对应weibo的地址在这里，http://weibo.com/1659525945/y316NCTai，列举一些评论，大家各自发表自己的观点，也没有人当得了裁判。在此也表示感谢！
“MiniStarClub001-邰晓梅：很好的测试思考和启发！ 就是文章最后的观点 认为测试还是要靠标准的方法和技术 改进才好进行 以及测试将来的方向是将标准的方法和过程工具化 不太认同 我更倾向于认为以人为中心的测试技能提升是测试的方向
而不是以工具、方法、流程为中心的技术 (1月29日 16:45)”
而不是以工具、方法、流程为中心的技术 (1月29日 16:45)”
“崔启亮-北京ISTQB
：测试发展的最终形式是流程化和自动化，缺陷可视化检查和警告及预防，测试人员的作用是确定测试策略，发挥行业领域知识，规划典型测试场景。大项目测试成功的关键是流程，小项目靠某些个体的经验和能力。 (1月29日
23:08)”
：测试发展的最终形式是流程化和自动化，缺陷可视化检查和警告及预防，测试人员的作用是确定测试策略，发挥行业领域知识，规划典型测试场景。大项目测试成功的关键是流程，小项目靠某些个体的经验和能力。 (1月29日23:08)”
“卢曰万：回复@MiniStarClub001-邰晓梅:工具、方法、流程是持续改进的目标，也是基础，同时测试是良心活，人的技能和工作意愿是测试改进的驱动力，确保面向应用场景的验证高质量完成。 (1月29日
23:19)”
23:19)”
“MiniStarClub001-邰晓梅：回复 @卢曰万:我还是觉得人的技能是基础 流程 方法 工具是辅助 最近读的一篇博文阐述了类似的观点
供参考 http://t.cn/zOvB8UW (51分钟前)”
供参考 http://t.cn/zOvB8UW (51分钟前)”
“卢曰万：回复@MiniStarClub001-邰晓梅:对团队而言，铁打的营盘流水的兵，人是会流动的，但工具流程方法可以基线下来成为基石 (34分钟前)”
首先我想澄清一点，我并没有因为认为有了这些多样的标准的检测手段，就不需要人的经验了，因为:
1. 这些检测技术还在不断发展，都是有经验技术、能力和意愿的人在推动
新的技术的出现，老的技术的改进，变得跟简便、方便和便宜。
这些就好比我们的测试技术的改进一样，也是需要人去研究，试验和实验的，并结合临床的经验来调整和改进。
2. 如果来使用技术和解读测试结果做出判断也需要人的经验技能
如果只是一项检测结果，解读起来可能比较容易，因为牵涉得东西不多，但是实际中对于一个疾病的诊断，通常都不会是只依赖于一项检测结果，那么如果综合这些结果来分析其实也是很需要经验和能力的。否则，医生怎么会有高低之分呢，大家在同一个医院拿到的检测结果是一样的，但不是每个人都能同样做出准确的诊断。
但是我不认同将经验和技能停留在经验和技能。这里拿中医和西医做个对比，无意冒犯，只是做个类比。
在传统中医（现在大点的所谓中医院里，西医的各种器和术都有）里看病，讲究说学逗唱，啊不是，望闻问切。比如看舌苔，摸脉搏，看气色等等。我不否认有很高明的中医，基于自己高深的技术和多年的经验，能很好的运用这些，来进行准确的诊断和对症的治疗。
但是现实中，我们都依赖于这些含糊的说不清楚的经验，好像难以应付那么多人的看病的需求，而且高明的中医似乎太少。他们的这些经验都是靠日积月累，难以传承。
这是一种困境，我们看到的现实还是西医的思维在主导（有多少人是老中医看好病的？），而且大家真正生病的时候大部分还是靠的西医。因为一些标准化和定量的东西更容易普及和推广，而这些很多时候体现在具体的设备和工具。
大家来看看西医的方法，有很大一部分的时间（包括患者花的钱）都是在前期的检测，其中的监测和后面的复查。这其实也说明了测试的价值（这里厚颜的把这些都揽成测试）。不说别的，看看那些大家每年体验的科目就知道很多了，这里不一一列举。
分享我自己的一个例子。
第一次结石发作的时候，右下腹部异常疼痛，早上去医院急诊，根据症状，值班医生刚开始判断可能是阑尾炎，很像，但是不确定，后来做了个血液检查，不太像阑尾炎的症状，因为白细胞计数还正常（医学知识太少，也许不是看这个），然后进一步去做了个B超，就可以更肯定不是阑尾炎，而像是结石。
我想作为医生或者患者，我们都希望看到这样的比较可靠的和结果明确的测试，而不是依靠医生的经验，这样万一碰到一个没有经验的，把我赶紧弄到手术室去切阑尾就悲剧了。而如果有了上面两项的测试报告，我想有基本的医学知识的医生都不至于把我弄去切阑尾。
那么这样的测试的价值就体现出来了，至少包含了三个方面的要求：
第一他不需要执行测试的人有太深厚的经验，当然还是要一部分的，比如做B超的，那么多人都能胜任。
第二流程比较标准，结果比较稳定。
第三，测试报告对于看的人也不高深，能清楚的反映事实。
说了这么多，我想我的point不在于否认测试人员的技能和经验的重要性，或者要把一些东西僵化。但是我感觉到我们软件测试行业这种被广泛认可的专业性的东西还是太少，不能每次说到我们对比开发或其他软件研发的工种的独特价值就是我们对测试的理解、测试的策略和方法论等等，而应该是一些明确拿得出来的被普遍认可价值的有明确结果的东西。
现实一点软件测试因为被测对象的原因还不太可能做到医学检查那么标准，所以我们花了很多的时间和精力熟悉“人”（我们的被测产品），学习或者发明检测技术，开发仪器设备（测试工具，自动化系统等），一起执行测试，分析报告。
这些都很有价值，没有错，但是有些是对外而言的，对外看的是拿出来的结果，包括别人也可以用到的东西。就好比我们说一个国家航天技术的发达程度和水平，不是看他们有多少有经验的人和知识的积累，而是发射了什么东西出去，有没有人在太空行走。这是倒过来看的，没有人脑子里的那些东西也不会出这样的成果，但是我们对于外界的贡献直接的而言是这些外化的东西，我想软件测试也是一样。
从这一点上，我比较倾向于把知识经验技能外化或者固化到可见可用的工具或者系统上。
我还没有想得太清楚，也许一套稳定高效的自动化测试集对于一个产品就是一个这样的东西，因为它同样满足于上面提到的三个要求。
在曾经做过的一个项目中，这一点让我印象很深。
当时我们将大概一半，约几千个测试用例自动化了，但是由于各种原因，daily build来用的时候总是有部分用例失败，要去确定是用例的问题还是产品的问题需要不少时间，每天这样做也耗不起。后来我们抽取了其中涉及主要功能点的重点用例，约200个左右，花力气弄得比较稳定了。能达到的结果就是，只要有用例fail了，基本都是产品的bug或者一些未知的改动导致的（如果我们不能做到如此凭什么要求产品也稳定?）。这样运行了一段时候后，比较有信心了。我们把这一套自动化的用例集帮助开发人员在他们的环境里面部署起来，作为daily
build的验收测试，每天的结果邮件通知大家，不全pass的build不接受做进一步测试。
build的验收测试，每天的结果邮件通知大家，不全pass的build不接受做进一步测试。
开始我们想这样会增加开发人员的工作量，估计会比较反感。但是后来我们发现其实并非如此，因为这套测试集比较稳定，能及时的发现问题，开发人员很积极的第一时间去看，而且觉得帮到了他们，因为他们有时也不确定改动有没有问题，反倒很认可这套东西的价值。
对比我这里举的例子，也不难理解，我们大概也很少听到医生讨厌医学检测，因为这些东西确实是在帮助他们发现问题，定位问题，或者至少提供有用的信息。
我想从这个意义上，才能实现开发和测试良好合作，因为双方都为同一个目标贡献有价值的东西。而另一个方面，测试人员要赢得别人发自内心的尊重，一定是因为专业，而不是口头呼吁重视测试。
我想一定还有更多的，更能普遍一点的东西，来自于测试人员能提供出来的，性能测试的一套可以实施的东西算一个吗？安全测试的工具和报告？
都是些不成熟的思考，欢迎大家拍砖。