每次在写用例时都会有个疑惑，没有在需求内的功能是否应该编写用例去测试？
如果编写了用例去测试，对于这部分用例来说没有需求来源。
若不编写用例去测试又担心自己没考虑全面，给别人揪小辫子的机会。
所以每次都会编写一些没有需求的用例。很苦恼，大家有什么好的解决办法吗？分享分享
PS：有时候是需求没有写，考虑到此场景就会涉及改需求。有的研发会改，有的则觉得没有必要不动需求。有时候需求担心加上又是否合理
「原创声明：保留所有权利，禁止转载」
需求方面，统一反馈到产品，测试无权利决定需求，同时保留好凭证，最好在群里，或者公司聊天软件，避免事后追责。
测试目的是保障质量，而且出了问题每个人都有责任，即使主要责任人不是测试，那还是要花时间处理问题。如果产品研发没考虑到全部场景，还是需尽量去兜底，评估到有风险的场景都应该回归下。如果经常遗漏风险点，应该开项目复盘会，对经常遗漏的人的思考方式能力责任心提出质疑
产品没考虑到的是常态，开发和测试在设计过程中也是可以逐步完善的
想清楚为什么存在评审环节，你也就没有疑虑了
用例评审就是解决这个问题的啊，会上和产品确认，产品说改就改，不改后面出问题也赖不着测试
- 测试要对整个产品的质量负责，而不是针对某一个需求（甚至是未经评审的需求）。
- 做好需求评审，避免出现没在需求内的功能点。
- 做好和产品、开发的沟通工作。
需求和用例评审阶段如果能发现就及时提出并补充，测试阶段发现就反馈到产品补充需求，正常走开发 - 提测 - 测试流程完成新功能点的测试，整个过程做好记录
需求没考虑全面的，需要团队补充啊，有疑问就找产品确定。如果经常出现这样就产品的水平问题
咨询产品了就好了
可以看下产品对你反馈这个的态度
如果积极响应 并且 补充需求 这些都是你的亮点
如果产品不怎么鸟 那你就别多事了
需求有的，一个都不能少，需求没有的，一个都不能多