2018.4.8晚上，c2-1，在此，对讨论内容做整理。
参与人：佐蓝，helen，银子，abby，零度，me。
会议分两部分，前部分是测试方案，后部分是测试用例，聚焦是方案级项目。
接下来分别做阐述，1.方案的测试方案当如何，2.方案的测试用例当如何，3.会后待探讨部分。
方案的测试方案
稳定性的必要性与巨大资源开销的碰撞。我们发现，现阶段方案型项目准备、部署一套功能环境会需要很多硬件、人力、时间。再加诸稳定性环境n套、多个场景，此时，所需总资源量会极其巨大。我们认为方案的稳定性测试非常重要及必要，矛盾是还未探讨出合适的办法来解决资源瓶颈。
多场景时稳定性的资源不能复用。方案往往涉及多个场景，配套不同的前端、平台，那每个场景都势必要做稳定性验证，那此时，前端能否复用？平台能否复用？如果前端复用，多个平台都来拉流，此时前端挂掉，多个场景的稳定性是算正常还是异常？所以，在没有充分可靠的评估时，不能复用，需要每个场景单独布自己的前端、后端、平台。
首轮全测，之后轮次合理裁剪。关于方案测试，多个轮次之间的裁减计划如何安排？第二轮是否要全部测试？如果可以裁剪，只挑选部分来测试，那当挑选哪些部分？总结下，如何评估风险影响模块，这是关键，是需要有角色来承担起这样的技术任务。
方案的测试用例
测试用例，当以业务流为视角。业务流，除了覆盖正向业务流，还应包含逆向、异常甚至边缘性的操作流，比如删除布控库、远程前端修改、平台ip修改、局部升级、断网断电这样的。
业务流视角，当从需求阶段就开始。不止测试用例需以业务流进行设计，更往前推，所有方案的项目都应以业务流为视角。比如，从需求包开始，到需求澄清，到测试方案，甚至是到后面的部署文档，都应是对业务流的完善，持续细化、丰富、修正。
预置配置应单独步骤/用例。方案会涉及很多预置步骤，操作或配置后才是检查最终呈现。关于这些预置步骤如何形式处理，我们讨论了多种方式，最终决定根据模块合并，如果较大，则呈单独一条用例；如果较少，合并作为一个放在步骤，用预期结果分条check。精简前期条件，强化测试步骤，精简预期结果。如“山”一般，两头轻，中间重。
菜单是纽扣，业务流是线，用例来穿针引线串纽扣。系统上界面上有很多菜单、按钮，那是不是客户看到的都应测掉？不是的。业务流串到的，必测；业务流串不到的，不关注（或冗余？）；业务流串但串不起来的，代表缺少，是bug。
应包含易用性用例，1处。安装部署是否便捷、面向客户的界面有无错别字、以及其他非功能用例，如果用例里未包含，则存在漏测对我可能，但如果每个功能块都区分设计，又过于细致，讨论结果是通篇1处做提醒，总体check。
用例check点适度，不宜超过5个。一个场景流用例，如果要检查的点过多，则应拆分用例，给予不同的用例名称。
会后探讨部分
测试用例可推出典范，其他项目复用模式。我们发现好多方案项目都上了人脸这块儿的功能，内部存在多个项目在开发用例、需求分析等，我们希望能有一种方式，减少不同项目的重复投入，推出一个典范用例，后续项目基于此去沿用、补充、积累。先疏通内部资源，未来考虑如何避免各产品线的测试用例各自为战。
拉通全公司，多项目、多产品线资源复用。这或许是一种思路，顺带解决这几个痛点：方案的稳定性测试（资源及耗时）、方案的实际点位部署（资源及耗时、模拟的真实性及利用率）。
