最近看到有人在buzz上转文章，关于哪些技术被过度炒作，后来有个前同事回了一个comment，“脱离应用场景谈技术毫无意义”。觉得讲得很有道理，也很到位。然后忽然觉得其实很多东西都是如此，这个有点哲理的味道了。我们是做engineering，软件工程也是工程，工程的特点就是不能停留在理论和方法，最后要做出来东西，软的也好，硬的也好。

　　人有时候很奇怪，很多道理说起来浅显，别人讲出来的时候会直点头，有道理，但是真正做事的时候会常想不到。很到道理要真正经历过，体会到经验或者教训才会印象深刻，变成自己的，这大概就是经验和阅历的重要性吧。

　　这其实是一个很大的topic，这里想从测试方面来说说，其实脱离了项目的实际状况来谈测试方法也是毫无意义的。

　　光空谈太泛，而且我自己也是一个经验主义者，那就是尝到甜头或者吃过苦才能记得或者印象深刻，结合自己的经历来说说体会。在测试领域工作了好几年了，也完整的做了好几个产品的版本，回头来看，各不一样，有下面几种。

　　1. 项目是从外面转过来的

　　项目从US研发中心转过来，本来就已经在市场上在卖了，有相当的客户基础，也有相当的开发资源的积累，代码，case，automation，tool等等，当然也有相当的历史遗留问题。

　　2. 项目是基于老产品做的新产品

　　IT 其实和时尚界一样，也是一个追赶潮流的行业，今年流行格子，明年流行拉链拉起来盖住头。所以其实也没有外面人所说的那么boring，比如前几年流行 appliance，本来是卖软件，要把它装到一个盒子里，配好了和硬件一起卖，然后虚拟化流行之后开始出现virtual appliance，和OS打包到一起或者导成虚拟机。于是在这样的潮流下就有了很多新瓶装出的旧酒，把软件的产品加上系统层面的一些功能，然后针对特定的硬件作一些定制，变成一个全新的产品。

　　3. 项目是后续的版本

　　从外面转过来的版本是一个过渡的阶段，到了下一版就是一个完全独立来做的版本，加了很多大的功能，甚至架构也有一点改变。这个时候可能是5.0， 6.0， 7.0或者8.0了。

　　4. 全新的1.0的项目

　　慢慢的，就有一些全新的项目开始做了，没有既有的客户，也不知道这个市场的客户接受度有多高，还有很多的东西都是全新和未知的。前一段离开做了几年的一个产品，开始转到一个全新的产品，发现有很多不一样的体验。

　　产品有很多种，不过做哪一种不都是做嘛。确实，有时候也这么安慰自己，特别是遇到新的挑战的时候。不过实际上，还是会发现，有很多的技术和方法还是不一样的。下面从测试的角度列几个方面，供大家参考。

　　1. 产品的成熟度

　　测试的策略和方法很多时候要取决于产品的实际质量的状况。对于成熟的产品，也可能核心的模块并没有太大的改动，但是对新产品而言，可能核心的部分都不是很稳定。那么我们在考虑测试策略的时候就要想一想，我们是不是需要在很早期的时候针对核心的模块和功能开展测试，不仅是功能测试，还要做稳定性的测试，尽早的暴露问题。

　　2. 测试资产的积累

　　测试资产有很多，test case，手工测试工具，自动化的框架甚至可以跑的case等等。针对上面提到的几种情况，有些已经有了很多可以重用的工具和自动化的case，那么我们在developer刚交付产品的时候就开始验证产品的质量。对于测试人员的工作安排也很不一样，对于一个全新的项目，可能需要花很多的时间去讨论，设计和实现测试框架和组件，比如我最近的这个项目，当然有些部分也是可以考虑复用别的项目的。

　　3. 人员的成熟度

　　在有些5.0， 6.0的项目中，team里面多少都会有一些对产品和之前的测试工具和方法非常了解的team member，在这种境况下，可以很快的将很多东西build up起来。但是对于1.0的项目，一来可能新人比较多，二来大家都对要开发的产品或者领域了解有限，需要很多的时间和精力来学习相关的知识。 对于新人来讲，还有很多基本的测试相关的知识和技能需要去学习，作为QA，这些东西是省不了的。

　　4. 整个team的默契程度

　　这一点和前面提到的比较类似，越来越觉得，测试工作要很好的开展，必须和开发人员，还有外部的一些team非常紧密的合作。刚开始，还需要一些时间去熟悉，适应和磨合，慢慢的提高效率和默契。

　　5. 测试方法

　　在一些成熟的产品中，因为已经有了很好的积累，也是success story，所以很自然的，下一版还是会更大程度上采用之前的方法，当然，有些方面还是会有一些创新。但是对于新的项目，因为没有什么积累，所以也没有现成的时候这个项目的方法可以参考，所以也可以比较方便的尝试新的方法。

　　写完了，发现还是写得蛮粗略的，确实，不结合实际的例子不太好说明，就先写成这样吧，权当是抛砖。