Software Testing－拿到一个需求之后，我们该如何开展测试工作？

青旅半醒 2023-01-19 03:23 19阅读 0赞

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击[http://www.captainbed.net][http_www.captainbed.net]

1、分析需求并讨论  
　　拿到需求后，我们应该先将需求文档自己过一遍，标出自己不理解的地方或者可能会有争议的地方。同时我们也可以借鉴一下竞品类似的功能是怎样处理的，这样更有助于我们理解需求。然后联系需求人员和开发人员，一起讨论一下需求到底是怎样的，把自己对需求的理解表述一下，然后把自己不理解的地方和可能会有争议的地方拿出来跟大家一起讨论，往往在讨论的过程中会有一种豁然开朗的感觉；或者是对某一个点其他人会有不同的理解，这样会让我们对需求理解的更加全面。  
　　需求讨论时，会做好记录，然后根据会议记录，把需求文档再完整的过一遍。把在需求讨论过程中容易理解偏差的地方和容易忽略的地方重点标记一下，以备后期编写测试用例时使用。

2、编写测试用例  
　　根据我们的需求文档以及讨论的结果，编写详细的测试用例。编写测试用例的方法这里就不详细说了。这里有人会问，为什么要编写测试用例呢？直接测试不行吗？当然行，但是直接测试会漏掉很多点，容易测试的不全面，经常会漏掉边边角角。而且测试完成之后，不能清楚的记得自己哪些点测试过，哪些点没有测试过，容易造成测试点遗漏或者工作量的冗余。而且在写测试用例的过程中，会发现一些容易忽略的点，或者是在写用例的过程中，发现某个流程并不流畅等等，这些问题要及时的通知需求及开发人员，可避免开发人员做一些无用的工作。

3、用例评审  
　　用户编写完成后，我们要组织人员进行用例的评审，包括需求人员、测试人员、开发人员等。为什么要进行用例的评审呢？当然还是查缺补漏，纠正错误。测试用例包含了功能的边边角角，我们不能保证能把所有的测试点都列出来，也不能保证我们所列出来的测试点方向都是正确的，那么就需要其他人来查缺补漏，看一下有没有我们漏掉的点，看一下我们用例的方向是否正确，防止对需求的理解错误。

4、执行测试  
　　等用例评审完成并且我们改完之后，开发人员也差不多将需求开发完了，这个时候我们先进行冒烟测试（冒烟测试：拿到一个需求后，先对需求最基本的功能或最主要的业务流程进行测试，确保功能没有阻塞性的bug）。如果冒烟测试不通过，则打回给开发人员重新修改；如果冒烟测试通过，则我们按照测试用例对功能进行一遍完整的测试，记录所有的bug并指派给相应的开发人员修改。并且我们要标记用例的成功失败状态，以便后期回归测试使用。  
　　在给开发人员提bug的时候，一定要写清楚复现的条件是什么。比如说用什么浏览器，用什么账号登录的，哪一步操作出的问题，有什么特殊操作，有问题的数据是哪条，详细的操作步骤是什么，这样开发人员才能理解bug到底是什么，并且快速定位到问题。  
　　如果遇到非常难理解的bug，可以录个视频，方便开发人员更好的理解bug。  
　　当然你提的bug开发人员也不是全盘接受的，有一些bug会被开发人员打回来，他们认为这不是bug，那这种情况下又应该怎么处理呢？首先找到开发人员，问一下他对这个功能是怎么理解的，并且表述一下自己是怎么理解的，如果两人能达成共识，则按照共识来改；如果两人达不成共识，都认为自己的理解是对的，那么就再找需求人员进行讨论，最终定出一个正确的方向。

5、回归测试  
　　等开发人员将bug全部修改完成后，我们需要先对所有的bug进行回归，然后确认bug都改完之后，再按照测试用例，对整个功能进行一遍回归，防止在修改bug的过程中影响了其他功能。

6、生产环境测试  
　　需求在测试环境测试通过后，就可以准备更新到生产环境了。等功能更新到生产环境后，我们需要在生产环境上对此需求的主要流程以及生产环境的主要流程再测试一遍，确保该需求的可用性及整个生产环境的正常使用。

[http_www.captainbed.net]: http://www.captainbed.net/troubleshooter