一般一个新人（这里指新接触项目的人，而不是刚入行的人）来了，他之前可能有一些测试经验，所以在对一个游戏/软件，有了大致了解之后可以很快上手测试新功能，因为测试都是相通的。
但是新人进行测试的时候，会比较容易漏测一些游戏中不那么通用的点。
比如一个RPG游戏一般游戏的强化系统都会很稳定，但是这个游戏的强化系统则时不时的会出现问题，那么这个新人即使他的测试经验十分丰富，也很可能不会对一个看似平常的强化系统投入多大的注意力，所以很容易漏发现相关系统的bug。
其实从我举的这个例子来看，解决方法很容易，只要把“强化系统经常有bug”这件事情告诉该人即可，根本不会有什么麻烦。
但实际上，像类似这种“一般游戏没有，但这个游戏却有”的这种独特性较强的问题，一般一个游戏可能不会只有这一个，这就需要项目的老人们，将自己平时发现的一些本游戏独特性较强，并且重复出现的较多的问题归类收集起来。
这样的优点：
1.方便自己在测试类似系统时快速发现相关问题
2.使新人更不容易遗漏这些问题
有的项目可能一上来会让新人跑用例，我觉得这也是一个方法，可以通过触类旁通的方法让新人理解游戏中容易出现的问题。
但对这种问题来看，并不直观，如果一个新人没有完全理解，那么就有可能出现漏测。
在游戏中，同样容易漏测的问题还有关联功能的测试。
游戏测试中经常容易出现漏测关联功能的问题，特别是新来的人，即使他经验丰富，也只是拿自己以前的经验来用，对于新接手项目的关联系统，其实并没有一个清晰的认识。
这就需要老人为新人整理好这些内容，帮助新手迅速上手，并且方便自己编写新系统的用例。
另外，当测试的功能与从前的功能比较相似的时候，可以查看从前功能的用例设计和出现的bug直接拿过来借鉴。
把容易出现的问题系统的整理到一起也方便老人在测试新系统时快速查看，而不用去翻老用例。
这是对对项目已经有较丰富的了解的人的建议。
另外对于新人有两点要说的一是：要保持对游戏的敏感度。
有些隐约感觉到的东西但是没有弄明白就会出现歧义，从而导致漏测，所以有疑问多向老人请教，不要怕烦（自己烦，或者惹对方烦），
因为你理解的越多，实际上对整个项目的益处就越大，能发现更多的bug，也能更少的漏测。
二是：多尝试。
对于想到的测试点要多去尝试，你可能突然想到一个点，但是懒的去试，那如果那个点真的有问题的话，就等同于你根本没想到一样。而且bug实际上也是随着你的用例覆盖的比例越大发现的越多，所以多多尝试。
平时的容易遗漏一些测试中不常见的点，要理解这些点需要保持对游戏的敏感。
