一、会议记录目的
备份会议内容，以便后续跟进。如果有需求变更，提醒产品更新需求文档并发需求变更邮件。
二、会议记录内容
记录会议中经过讨论，给出的结论性的内容。
例：
追剧需求中没有对同一电视剧在不同网站观看要弹几个弹泡具体说明。不同网站观看同一电视剧是分网站不同剧集弹泡，还是记录最后一集所在的网站，弹这一个弹泡。最后经讨论决定，不同网站观看同一电视剧分网站不同剧集弹泡。所以要将这一天结论记下来。
有时存在某些需求由于现在的技术、框架或服务器端现有的逻辑、开发实现成本的限制无法实现，开发会告知产品，此时应该记录下该内容。
例：
在追剧需求中有这样的描述"用户本次观看集数不足一集，但剧集在热播剧榜的前三名，定义为追剧"，由于电视剧的观看时长服务器获取不到，如果是爬数据开发成本会很高，投入产出比不高，所以将该需求砍掉。
由于产品一开始没有想到的内容、需求细节不合理、需求过于复杂等问题导致需求的变更，应该有记录，并提醒产品更新需求文档。
例：
追剧需求中根据用户尚未观看的集数，将剧集分为充分观看的剧集和非充分观看的剧集，充分观看的剧集指的是指用户已观了剧集已有视频的最后一集，反之则称为非充分观看的剧集，而非充分观看的剧集又分为规律性观看和随意性观看。针对不同的用户弹不同的追剧提醒。由于判断逻辑复杂，对用户的区分过于细化，项目时间上的限制，将该非充分观看剧集的需求砍掉。
主要包括会议中没有结论、待确认的的内容。
注意todo要记清楚todo内容和todo负责人。
例：
追剧需求需要计算弹泡然后给用户推泡，但是没有说明具体是什么时间计算弹泡数据，所以这是一个待确认的内容。因为对于产品来说，什么时间算弹泡无所谓，只要算了就可以，而测试却要根据这个时间设计相应用例，所以这个todo的负责人是测试。
由于需求逻辑产生的风险备忘。
例：
追剧需求中描述"在用户上次观看此剧集视频的当天第一集的时间基础上提前五分钟提醒。"如果服务器算出8:00PM弹第11集的弹泡，并且已经把弹泡数据推送到了Pushserver服务器，但是客户端在7:59PM看了第12集，此时客户端仍然弹第11集的弹泡。
在一个项目中，可能涉及到多个开发和多个测试，此时需要指定一个开发接口人和一个测试接口人，以便后续问题的沟通和项目的推进。
如果会议中待确认的内容较多或较严重，影响到后续开发实现，在会议结尾和开发、产品确认是否需要下次会议。
例：
追剧开始的需求文档很复杂，经过讨论，还有很多待评估的内容，有的需求因为要砍掉所以会更改一下需求内容，所以在会议结尾的时候，产品会说需求再整理一下，下次会议继续讨论。
本文出自《51测试天地》原创测试文章系列（四十四）
填问卷，100%送公开课视频！
