在我们公司，还是作坊式的开发，需求、设计基本没有，都是客户说几点要做的，其他都看开发人员的想象力。
这样在很少的需求文档，并且没有设计等内容的情况下，测试如何进行测试？
下面就以我近期测试的一个项目为例，说明在这种情况下，我如何处理这种情况。
我接手测试的是我们公司内部开发的一个项目管理系统，需求都是由项目管理部的经理提出，现有流程都是走的纸质单子，想把各个项目组的流程电子化。
我们测试并没有介入前期，所以直到交给我们，才看到具体的软件样子。
同期给我们的，只有数据库结构设计，其他莫有了。
开始第一轮测试。
第一轮测试，我主要是确认软件功能都是正确的。
项目管理软件，主要由3个部分组成，一是立项管理，就是销售或项目经理建立项目，指定项目经理，项目类型，预计人员，里程碑，项目回款等等。立项管理这里还有项目管理部等的审批，以及修改等内容。二是任务单，主要是确定做项目的人员，每个活动都对应到具体的人上面，根据人员计算项目花销。三是借款报销，主要就是在项目的框架内，进行直接借款或通过任务单借款和相应的报销。
功能算不上太复杂，大概6个大模块70个左右功能。
第一轮，主要是了解系统由哪些功能组成，而且确保每个功能的正确性。比如每次操作，我都会去查数据库，看是否数据进行了相应的变更，通过数据库的设计，可以更好的了解程序员是如何想的，程序是如何运作的。
每一个功能都需要进行了解和确认，比如立项的时候，有间接费用、直接费用、管理费、利润等等数据，每个数据都需要了解从哪里来的，以及如何计算，确保计算结果的正确性。
另外，收集需求的时候，他们既然把大部分的东西都写在自己的笔记本上，而不是整理出来，所以很多时候，都需要开发人员具体的解释。
总之，第一轮过后，我保证对数据库的每个表，每个数据都心里有数，知道每个操作会影响到哪里。
第一轮提出问题后，经过开发人员的修改，进入第二轮。
第二轮我不很关注功能，因为第一轮基本确认了所有的功能，保证其有效性，第二轮我主要从业务逻辑着手，发现其中可能存在的漏洞。
比如很多办理业务的过程中，需要先查询再办理，但是很多时候，查询结果只有入口，没有出口，这样随着项目的更新，查询就几乎失去了意义，因为很多都不是办理需要的。
还有像是任务单借款报销，这里并没有和任务单很好的结合，实际借款和任务单并没有太多关联。
这样的业务漏洞，在第2轮提出了很多。第二轮我所做的就是深入业务，了解各个业务是如何运作的，从整体上把握整个的项目。
在第2轮，终于从开发人员那里弄来了需求列表，上面都是项目管理部提出的对软件的要求，发现了很多不符合要求的地方，看文档日期，半年前的需求，一些确实是问题，一些后来在他们的笔记本上又变更了，其实后面第3轮，还要来了补充的需求，挤牙膏一样，很多东西他们自己都忘记有了。
第三轮我关注接口。
经过第二轮理顺业务，对整个系统应该熟悉了，就需要考虑一个地方变动，会对其他地方有什么影响。比如项目里面有客户，那么我把客户删除了，对项目有什么影响。
或者我提交了1个任务单，但是对此任务单多次借款和报销，是否会有问题。
另外就是磨一些比较细的地方，比如立项有4种类型，不同的类型对借款报销等的影响等等。第一轮也做过相应的测试，但是第3轮的时候，随着系统的熟悉，实际补充了很多的用例对可能有问题的地方做更细致的测试调整。
这样经过三轮测试，功能、业务、接口都没有问题了，剩下的就是慢慢的和开发磨了，很多时候一个问题经过多轮没有修改，或者原先一些问题没有发现，但实际都不影响大局。这个可能再经过3~5轮，项目就大概能收尾了。
测试用例我是第2轮才开始写的，因为刚接触软件的时候比较兴奋，还是第2轮沉淀和熟悉的时候，写用例更适宜，而且经过第2轮，软件很多地方有很大的调整，第一轮即使写了，也都需要变更。
还有就是一定要从业务的角度思考系统，功能是死的，但是为什么有这个功能，每个测试人员都需要了解。数据的流向也需要切实的把握，我是很喜欢用截图软件截图的，因为随时进行比对，看哪些内容有了变化。
大概就是这些了，只是自己的一点经验，可能大家有更好的测试方法，不妨也都说出来进行参考。
版权声明：本文出自 luming 的51Testing软件测试博客：http://www.51testing.com/?7844
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
