万科项目的功能测试已经接近尾声，作为常规项目，与产品化项目存在一定差异，从测试来说，对常规项目与产品化项目所提缺陷的尺度与侧重点也应该是存在差异的，在这一点上，我对自己在万科项目中表现的并不满意。

　　首先，并未理解常规项目与产品化项目的区别，往往以产品化项目的尺度来要求万科项目在一些方面做出改进。其次，测试过程中没有所谓的侧重点，基本上是广撒网的形式。

　　那么，作为测试应该如何应对常规项目与产品化项目的差异，并做好功能测试呢？

　　常规项目

　　由于是由客户提需求，那么从业务层面上讲，测试人员的业务经验应该是服从于客户的业务需求的，不能作为评判功能是否合理的依据或标准（冻结的业务需求是唯一的标准）。常规项目的测试侧重点则应该放在客户真实的业务场景上，要明白客户如何使用我们的软件，使用软件的哪个功能解决什么样的问题，我们的软件是否真的能很好地为客户解决这些问题？

　　个人认为常规项目的功能测试安排两轮为好。

　　第一轮，以主流用户（即客户）的角度测试功能的正确性，在这一轮中，需明确列出客户使用软件的各个业务场景，测试点覆盖所有的业务场景。理论上来说，这一轮发现的问题将会主要集中在跨模块的业务场景中，所以需重点关注跨模块的业务场景。这一轮中发现的问题一般都是功能上的，严重级和优先级都很高，开发和测试需要尽快修复和验证，以保证第二轮功能测试的展开。第一轮的测试效果很大程度上依赖于测试人员对客户需求、真实业务场景的理解和掌握，所以测试人员如何更好地掌握客户的需求和业务场景很关键。

　　第二轮，以专家用户（即测试人员）的角度对软件的健壮性及容错性进行验证，在这一环节中的侧重点是对异常情况的考虑，例如功能并发、不符合条件的输入、边界值等等。第二轮测试最好能够安排交叉测试，测试人员重点测试自己负责的模块，对其他模块的关注度可适当降低（在工作量上体现），这样的交叉测试的好处是能很轻易地覆盖由于不同人看问题的聚焦点不同而带来的测试盲点。

　　产品化项目

　　个人认为产品化项目对测试来说有着更高的要求，因为对产品化项目来说，面向的客户并不是固定的，因此就不会有非常明确的业务场景，也不像常规项目那样，有任何不明确的地方可以直接找一线确认，然后按照客户提的需求实现即可。所以对测试来说，在功能的合理性方面也是需要增加关注度的，这样，对测试也就会有更高的要求，对业务的熟悉，对公司管理理念的理解，这些都将直接影响到测试的深度。

　　个人认为，产品化项目功能测试流程基本可以参照常规项目的两轮测试，而根据其差异，需增加关注点、调整测试尺度。

　　在第一轮中，需要增加对功能合理性的考虑，加强对各种异常的业务场景的验证，思考功能的实现是否遵守先进的管理理念，这些看似并不属于测试的范畴，但个人恰恰认为正是这些对产品的完善和个人能力的提升有着很积极的意义。

　　在第二轮中，与常规项目相比，测试应该提高对产品的要求。真正让客户觉得产品是否专业的，往往是细节。大胆的制定严格的尺度，面对吹毛求疵、鸡蛋里面挑骨头的评价必须hold住！

　　关于产品化项目，说句题外话，卖产品的同时也是在卖你的管理理念，先进的管理理念才能真正成就客户并得到客户的认可，也在不知不觉中提升了客户对我们产品的满意度。