uat测试用例怎么写_还是套路，告诉新人，面对突如其来的需求文档，如何思路清晰地写测试用例...

一个初入测试职场的新人，有没有经历过这样一个场景：一个项目来了，让你编写测试用例，可是你的脑袋里却是一片浆糊，然后哆哆嗦嗦的开始提笔，想到这一出写个测试用例，想到那一出写个测试用例。写着写着就在想这些用例够了吗？覆盖全部功能了吗？还有哪些遗漏的?然后回头继续对着看需求文档纠结着。我想大家或许或多或少都似曾相识吧。

那这篇文章就是用自己的工作经验来告诉大家怎么思路清晰的去编写测试用例。

一个项目刚来时，测试人员最先拿到手的文档应该是PRD（产品需求文档），当然作为测试用例的输入还有其他文档比如MRD或者use case等。PRD详细定义了产品的需求功能，测试工程师需要好好细品一下这篇文档。第一，通过它你就知道了这个产品的具体功能；第二，可以找出文档的需求缺陷然后提出意见给相关stakeholders。

熟悉了PRD之后，我们该干什么呢，当然是拆分它，把需求拆分的越小越好，当然很多PRD已经通过目录结构把功能需求划分了。

现在我们有原子需求了，所以目标非常清晰，接下来就可以编写测试用例去覆盖它们了。如何编写测试用例去达到全覆盖呢？本人觉得三种黑盒测试方法结合使用就可以满足需求——等价类划分+边界值分析+错误估计法。利用等价类划分+边界值分析编写出的测试用例可以覆盖功能，但有时候一些狡猾的bug还需要错误估计法去探索。

一开始，我们不必填写具体的测试步骤和结果，一个标题和简单的描述就足够了。因为覆盖率才是最重要的，具体细节可以等后期慢慢完善。如果产品功能不多，我们可以把测试用例全部写完后组织第一轮测试用例的review会议，邀请stakeholders比如软件，测试以及项目经理等，会议目的只有一个，就是大家一起看下现有的测试用例是否全部覆盖所有功能。如果产品功能比较复杂，可以写完一个模块的用例，review一次。

功能测试完成后，后面就可以添加其他的测试类型比如性能测试和压力测试。

其实流程并不复杂，我们用一个简单的流程图最后总结一下.