是不是好多人拿到需求之后，就直接按照自己的理解去测试了呢？如果直接去测试，会有很多需求理解的偏差，测试过程中会发现自己理解的需求跟开发实际做出来的功能不一致。那么拿到一个需求后，我们应该如何做呢？
1、进行需求分析讨论
拿到需求后，我们应该先将需求文档自己过一遍，标出自己不理解的地方或者可能会有争议的地方。当然我们也可以借鉴一下同类网站类似的功能是怎样处理的，这样更有助于我们理解需求。然后联系需求人员和开发人员，在大家有时间的时候一起讨论一下需求到底是怎样的，把自己对需求的理解表述一下，然后把自己不理解的地方和可能会有争议的地方拿出来大家一起讨论，往往在讨论的过程中会有一种豁然开朗的感觉，或者是对某一个点其他人会有不同的理解，这样会让我们对需求理解的更加全面。
2、编写测试用例
根据我们的需求文档以及讨论的结果，编写详细的测试用例。编写测试用例的方法这里就不详细说了。这里有人会问，为什么要编写测试用例呢？直接测试不行吗？当然行，但是直接测试会漏掉很多点，容易测试的不全面，经常会漏掉边边角角。而且测试完成之后，不能清楚的记得自己哪些点测试过，哪些点没有测试过，容易造成测试点遗漏或者工作量的冗余。而且在写测试用例的过程中，会发现一些容易忽略的点，或者是在写用例的过程中，发现某个流程并不流畅，我们在写用例的过程中发现这些问题，并及时的通知需求及开发人员，可避免开发人员做一些无用的工作量。
下面是一个修改个人资料的页面：
下面是我们提交的测试用例：
3、用例评审
用户编写完成后，我们要组织人员进行用例的评审，包括需求人员、测试人员、开发人员等。为什么要进行用例的评审呢？当然还是查缺补漏，纠正错误。测试用例包含了功能的边边角角，我们不能保证能把所有的测试点都列出来，也不能保证我们所列出来的测试点方向都是正确的，那么就需要其他人来查缺补漏，看一下有没有我们漏掉的点，看一下我们用例的方向是否正确，防止对需求的理解错误。还是以上面的例子为例，我们的用例经过评审后，发现漏掉了一些关键点，比如说没有写无任何修改就直接保存的情况，修改完信息不保存的情况等等。评审过后，我们再对这部分用例进行补充。下面是我们补充的测试用例。
4、执行测试
等用例评审完成并且我们改完之后，开发人员也差不多将需求开发完了，这个时候我们先进行冒烟测试（冒烟测试：拿到一个需求后，先对他进行最基本的功能或最主要的业务流程进行测试，确保功能没有阻塞性的bug）。如果冒烟测试不通过，则打回给开发人员重新修改；如果冒烟测试通过，则我们按照测试用例对功能进行一遍完整的测试，记录所有的bug并指派给相应的开发人员修改。并且我们要标记用例的成功失败状态，以便后期回归测试使用。
在开发人员提bug的时候，一定要写清楚复现的条件是什么。比如说用什么浏览器，用什么账号登录的，哪一步操作出的问题，有什么特殊操作，有问题的数据是哪条，详细的操作步骤是什么，这样开发人员才能理解bug到底是什么，并且快速的定位到问题。
如果遇到非常难理解的bug，可以录个视频，方便开发人员更好的理解bug。
当然你提的bug开发人员也不是全盘接受的，有一些bug会被开发人员打回来，他们认为这不是bug，那这种情况下又应该怎么处理呢？首先找到开发人员，问一下他对这个功能是怎么理解的，并且表述一下自己是怎么理解的，如果两人能达成共识，则按照正确的方向改；如果两个达不成共识，都认为自己的理解是对的，那么都需要再找需求人员进行讨论，最终定出一个正确的方向。
5、回归测试
等开发人员将bug全部修改完成后，我们需要先对所有的bug进行回归，然后确认bug都改完之后，再按照测试用例，对整个功能进行一遍回归，防止在修改bug的过程中影响了其他功能。
6、生产环境测试
功能在测试环境测试通过后，就可以准备更新到生产环境了。等功能更新到生产环境后，我们需要在生产环境上对此功能的主要流程以及生产环境的主要流程再测试一遍，确保该功能的可用性及整个生产环境的正常使用。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
