“脱离应用场景谈技术毫无意义”。其实很多东西都是如此，这个有点哲理的味道了。我们是做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，所以很自然的，下一版还是会更大程度上采用之前的方法，当然，有些方面还是会有一些创新。但是对于新的项目，因为没有什么积累，所以也没有现成的时候这个项目的方法可以参考，所以也可以比较方便的尝试新的方法。
写完了，发现还是写得蛮粗略的，确实，不结合实际的例子不太好说明，就先写成这样吧，权当是抛砖。