需求文档很少很模糊的情况下：
第一轮测试，主要是确认软件功能都是正确的。
第一轮，主要是了解系统由哪些功能组成，而且确保每个功能的正确性。比如每次操作，我都会去查数据库，看是否数据进行了相应的变更，通过数据库的设计，可以更好的了解程序员是如何想的，程序是如何运作的。
每一个功能都需要进行了解和确认，比如立项的时候，有间接费用、直接费用、管理费、利润等等数据，每个数据都需要了解从哪里来的，以及如何计算，确保计算结果的正确性。
另外，收集需求的时候，他们既然把大部分的东西都写在自己的笔记本上，而不是整理出来，所以很多时候，都需要开发人员具体的解释。
总之，第一轮过后，我保证对数据库的每个表，每个数据都心里有数，知道每个操作会影响到哪里。
第一轮提出问题后，经过开发人员的修改，进入第二轮。
第二轮不很关注功能，因为第一轮基本确认了所有的功能，保证其有效性，第二轮我主要从业务逻辑着手，发现其中可能存在的漏洞。
比如很多办理业务的过程中，需要先查询再办理，但是很多时候，查询结果只有入口，没有出口，这样随着项目的更新，查询就几乎失去了意义，因为很多都不是办理需要的。
还有像是任务单借款报销，这里并没有和任务单很好的结合，实际借款和任务单并没有太多关联。
这样的业务漏洞，在第2轮提出了很多。第二轮我所做的就是深入业务，了解各个业务是如何运作的，从整体上把握整个的项目。
在第2轮，终于从开发人员那里弄来了需求列表，上面都是项目管理部提出的对软件的要求，发现了很多不符合要求的地方，看文档日期，半年前的需求，一些确实是问题，一些后来在他们的笔记本上又变更了，其实后面第3轮，还要来了补充的需求，挤牙膏一样，很多东西他们自己都忘记有了。
第三轮我关注接口。
经过第二轮理顺业务，对整个系统应该熟悉了，就需要考虑一个地方变动，会对其他地方有什么影响。比如项目里面有客户，那么我把客户删除了，对项目有什么影响。
或者我提交了1个任务单，但是对此任务单多次借款和报销，是否会有问题。
另外就是磨一些比较细的地方，比如立项有4种类型，不同的类型对借款报销等的影响等等。第一轮也做过相应的测试，但是第3轮的时候，随着系统的熟悉，实际补充了很多的用例对可能有问题的地方做更细致的测试调整。
这样经过三轮测试，功能、业务、接口都没有问题了，剩下的就是慢慢的和开发磨了，很多时候一个问题经过多轮没有修改，或者原先一些问题没有发现，但实际都不影响大局。这个可能再经过3~5轮，项目就大概能收尾了。
测试用例我是第2轮才开始写的，因为刚接触软件的时候比较兴奋，还是第2轮沉淀和熟悉的时候，写用例更适宜，而且经过第2轮，软件很多地方有很大的调整，第一轮即使写了，也都需要变更。
还有就是一定要从业务的角度思考系统，功能是死的，但是为什么有这个功能，每个测试人员都需要了解。数据的流向也需要切实的把握，我是很喜欢用截图软件截图的，因为随时进行比对，看哪些内容有了变化
310
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
