软件生命周期中，需求是整个项目的源头。俗话说良好的开端是成功的一半，但是，不是每个项目都能遵从流程，花太多时间在上，而把精力投入到代码的编写中。这可能导致什么问题呢？开发和对需求理解都不充分，开发出来的功能与实际需求不符，测试要么凭自己的经验一步一步发掘潜藏的功能点，把项目往良性的轨道上引，要么就听从开发的脚步，亦步亦趋。那么测试人员要如何在需求不明确或者文档不全的情况下着手测试才能保证软件的质量呢？
一、参考同类型的网站：一般情况下，我们测的系统总会有原型可参考，比如我目前测的订票系统，就可以参照携程，主要功能基本一样，细节可能有出入，携程上操作一遍，然后再看看它提供的帮助，再有可以网上搜索资料，参考下行业的基础知识，这都是收集需求的方法，这样子下来也基本对订票系统也就有个认识了，然后与开发经理确认，再和开发一起把功能定下来，该改的改，该修的修，BUG一点不含糊。弱弱的吐槽下，这个项目的开发居然都不知道有需求说明书，虽然写的基本没太大的价值。
二、根据经验和常识判断：做项目多了就知道，万变不离其宗，系统不一样，思路可以套用，所谓的学以致用，举一反三。我上个项目做的银行测试，我照样可以测现在的订票系统，就在一个字：活。有需求照需求测，没有需求找参照，说个例子吧，订票系统中有个功能是积分，需求上就一句话提到有积分功能，怎么测？难道看到有这个功能就算过了？我后来就参照了淘宝的积分抵扣，下单了积分就被临时冻结了，取消订单又释放出来，但开发在做这个功能的时候也没有跟他们的头沟通，直接是要等支付完成后才扣除积分，这导致一个什么问题呢，可以重复使用积分，如果真上线使用了，说不定会造成不小的经济损失的。类似这样的问题太多太多，你总可以从一些地方获得参照，或者说是灵感，项目测的怎么样，跟测试人员的素养有很大的关系，尤其是在没有规范的流程下。
三、沟通：毋庸置疑，这太重要了，需求不一定在文档中写出来，但道理上开发肯定知道需求的，但一般不会主动和测试沟通，因此，我们作为测试就要主动和开发人员沟通，不仅可以对系统有更深的了解，还可以对项目进度有把握。
最新内容请见作者的GitHub页：http://qaseven.github.io/