原创： Kevin改变世界的点滴 Kevin改变世界的点滴 昨天
测试用例作为互联网产品开发流程中，是一个被要求细致与耐心的工作。测试用例的抒写与表达要求测试人员熟悉产品的页面跳转逻辑与功能解释，为此产品人是务必参加测试用例校验甚至是设计的。
测试用例也会有相应的用例评审。为此测试用例评审也成了需求再次了解与沟通的会议。不同于需求评审人员要求，测试用例评审参与的人员是测试、开发、产品人员。
如果你还没有参加过测试用例评审，也不能认为当前开发流程是有缺陷的。在创业团队，用例只要保证主功能、主流程通常即可，为了尽快的上线mvp产品。产品与测试人员都会把非紧急bug问题作为后期优化，测试用例的评审反而会让开发过程降低。
不同于测试用例评审，如果没有测试用例评审那一定有需求再次小团队沟通，我们也可以将把这样的沟通会作为用例评审。不过这样的沟通往往是在主功能上沟通，不会像测试用例那样细致，也没有把需求从上到下、从里到外的沟通顺序，就导致了在开发过程中需求调整或改动。
产品人再次核对需求
往往在测试用例设计中，这个需求已经经过每周的需求评审会。产品人员在此时此刻已经在其他需求中游荡。为此围绕着用例的评审会就会导致需求不清洗或遗忘等问题。
用例提前查看
需求的上下游问题
需求背景
我建议产品新人在准备测试用例前，可以做到上述三方面。第一次是及时对用例的审查、其次是要明确需求所涉及的上下游（例如订单会涉及到物流仓促、库存、财务结算）、这个需求解决的问题是什么。
用例设计中，也是产品人提升自己边界值、产品设计能力的训练。为什么我会要求产品新人学习如何设计测试用例，是因测试用例会考虑到产品的流程、页面跳转、交互问题。及时收集来自测试甚至是开发反馈对产品的意见，会让整个产品更完善。
产品经理没办法保证每个需求100%通畅、完美，通过及时收集用例设计中反馈的需求不合理问题，最终归纳为自己的需求弱势项。
类似上图筛选条件下，产品人很难想到筛选的子逻辑。用户的操作是从上到下还是从下到上、还是组合操作？ 简单的2个组件却在背后有不小的逻辑工作。
从用例开始做产品
很多产品经理的招聘中，包括我自己都希望招募到来自产品助理或产品专员的产品新人。而不希望来自开发或设计等转型等，为的就是希望能够建立一套“用户体验”的产品感。
一旦进入开发或设计，设想的内容就不是主要以用户为主。但就算是这样，我们不得不否认，从做设计、做开发转产品的同学也有优势。
对于需求的难度评估、需求的设计评估等，都可以借鉴之前的经验。
但我想说的是针对产品新人，还要学会从用例开始学起。学会描述一个产品页面的用例和可能的交互情况。熟悉产品中多少控件、多少页面，及时的掌握基本产品交互或跳转形态。
一个好的用例设计一定是快速、高校、精确，掌握主流程与主功能、次级路径。方便产品新人更好的考虑未来的扩展与后台管理。
但要切记的是，测试用例只是帮我们更好理解需求与需求的合理性。本来就是一个页面的设计，反而花大量时间去做少部分用例设计是非常没必要的。需求的沟通是本质
好啦，今天的分享就在这里。我争取每周更新两篇～
近期专题
产品助理（专员）、产品经理、高级产品经理、产品总监是什么样子？
另外我个人第一本书籍《从零到壹：PM改变世界的点滴》电子档正式上线这本我归纳222篇产品原创，涵盖产品经理面试、算法、交互等不同维度的内容，如果你感兴趣可以打赏后留言你的邮箱。我会在每天中午12点左右发送到你邮件中（希望大家勿外传支持，支持版权）。如果你需要预览书籍大纲，可以跳转链接
