测试用例|产品的需求只有一句话，如何破局（）测试用例|软件测试

大家好，我是小谭。
不知，小伙伴们在工作中是否遇到过：产品提的需求只有一句话。
拿小谭之前分享的接口实战来说：分享一份适合练手的接口测试实战项目。如果这个项目的产品丢来了一份PRD（需求文档），就一句话：在学生管理系统中，可以新增、修改、删除、查询学院信息。
你会怎么破局？
问题在现实工作中，如果产品的需求文档真是这样，至少说明了三件事：

产品能力不行
公司业务流程不完整，没有需求规范流程
开发和测试默许了第1点和第2点，不抗争不改变

一句话PRD有什么缺点？
01 增加了团队沟通成本
需求文档出来之后，开发要问产品；提测后，测试要问开发和产品……
何必呢？
02 增加了问题成本
紧跟上一点，很多时候，作为中间人的开发，连问也不会问，这就造成：产品是一种想法，开发是一种想法，测试是一种想法，最后出来的东西完全不对胃口。
03 难以回溯和总结
一句话通常发生在微信或内部通讯工具上，过时既忘，难以总结。在项目回溯、项目总结、业务文档输出时，极易遗漏。
如果你进入的是一个给力的公司或者一个给力的技术团队，基本上不会出现一句话的需求文档。
产品的PRD通常是这样的，哪怕是一个很小的优化项目 or 需求：

文章图片

文章图片

破局作为测试，如果你接到的需求是一句话，你得抗争，或者寻求改变。
抗争（改变）会有两种结果：
01 抗争（改变）有效
日日念、时时念，每次开项目总结或者需求总结会，都讲这件事，让产品改进。当一件事说久了之后，会形成一种潜移默化的推动力（这句话，自己悟）。
同你的上级多沟通，多交流这个问题，有主人翁意识，主动推进产品完善PRD；发现公司流程问题，完善公司流程。
这一套做下来并认真闭环，绝对是你工作的亮点。
02 抗争（改变）无效
主动出击，及早接入需求。在需求提出阶段，就找产品、开发统一思想。这样做，会减少你后期很多的沟通成本和测试时间。
自己做总结，记录每一次需求从设计、评审、实现的生命周期。这样做，看似很浪费时间，但多花点时间，绝对会提升你的业务水平，说不定到后面，你比产品都要厉害。
【测试用例|产品的需求只有一句话，如何破局（）】当然，如果你的公司没有产品，测试要身兼数职，你就得考虑另外的问题：