测试经验的总结

itlead · 发表于 2012-4-13 16:31:35

做测试快4年的时间了，在测试过程中接触到了不少的事情，个人的一些测试经验的总结：

　　1、充分理解需求，找出需求缺陷

　　测试人员拿到需求、设计文档后，应积极地与需求、设计人员进行沟通确认，并及时地提出自己对相关文档的疑问，这样做的好处一方面在于帮助测试人员充分理解需求，以保证设计全面、正确的测试用例；另一方面在于帮助需求、设计人员找出文档中不完善甚至错误的地方，以便尽早解决，这样就降低了后续过程中的风险和成本，也缩短了研发的工作进度。

　　2、及时有效地沟通

　　测试过程中，测试人员可能对设计文档有了新的疑问，或者程序实现出现了与设计不一致的地方，即程序实现的效果可能会达不到或者超出其他人（设计人员、测试人员）的预期（这种情况比较常见，因为大家看待事情的角度、表达方式、处理方式不一定一样，所以可能导致前者描述的事情，后者误解或者漏掉了其中一部分内容）。此时测试人员应该积极地与相关开发人、设计人进行沟通，保证大家对同一个需求的理解是一致的，这样才尽可能地保证了我们的产品做出来是满足用户需求的；

　　3、抱着怀疑的态度了解测试依据（需求和设计相关文档）

　　测试人员应注重分析需求和设计相关文档，但又不只限于这些文档。当测试人员拿到需求和设计相关文档时，同样应该抱着怀疑的态度，仔细斟酌文档中的情景，在充分理解需求的前提下，检查文档中是否有不合理或者不完善之处。我自己有这样一个经历：拿到一个任务的设计文档（此任务是涉及资源数据处理后入库的功能），粗看设计文档的处理逻辑是对的，但实际上仔细分析，文档中提到的处理逻辑（在删除数据时）由于没有考虑到其他资源数据存在的前提，故处理逻辑实际上是少考虑了一个逻辑分支。这种情况一旦发生在用户现场，后果可想而知。

　　4、参考业务流程，模拟实际的业务场景进行测试

　　同样，测试人员在测试过程中一定要注意结合业务流程，模拟实际的业务场景去测试，这个也是界内流传不衰的话题。在我刚开始做测试的时候，对于“模拟实际的业务场景进行测试”的概念，一直很模糊。因为我刚开始做测试时，接触的后台数据比较多，所以当时我泛泛地理解为“我们需要去模拟用户的数据进行测试”。一年半之后我接触到的一个项目才让我深刻地理解了“模拟实际业务场景”的含义。项目是给移动做的增值业务，分成很多个不同的小任务，当时在测试组内是由不同的测试人员进行测试的，不过由于我是这个项目的主要负责人，所以我负责整个项目的联调测试。对于这么多任务的联调测试，我还是头一回做，没什么经验，所以赶紧去请教了当时项目的设计负责人，并且拿到了一张业务单子，上面记录了这个项目涉及到的所有业务流程。在其他测试同事完成了项目所有小任务的测试工作后，我开始根据业务单子进行联调测试，竟然也发现了很多流程上的BUG，这个场景至今仍让我记忆犹新，也让我领悟到“模拟实际的业务场景进行测试”的重要性和必要性。更多可查看中睿it服务http://www.itlead.com.cn/index.php/cms/item-view-id-8339

　　5、积极主动地反馈工作

　　平时工作过程中除了要多跟项目相关的开发/设计人员沟通，还要多跟上级或者项目负责人进行沟通，及时反馈工作进度、发现的一些问题等等，尤其是一些突发事件，让所有相关人员都能及时地了解当前任务的进展情况，以便于合理安排和处理。之前曾有人推荐我看余世维的《有效沟通》视频，讲的就是上下级、同级之间如何有效地沟通，我看过以后收获还是蛮多的，视频讲解的案例也从一定程度上反映了沟通的重要性。