1、冒烟测试用例集
【时机】：beforeTest（真正开始测试之前）
【意义】：用来快速的验证提测产品是否具备可测性。
【经验分享】：
此用例集，虽叫冒烟测试用例集。但更准确的称谓应该是"测试打回标准"(testable checkList)。QA同学重点工作应放在定义清晰明确且可操作性强的打回标准。并且监督标准执行。定义哪些情况是不接受提测申请，必须打回的。比如：新功能未实现，已实现功能和既定需求不符合，新功能模块存在严重的崩溃，影响后续的测试。
此用例集，不一定要QA人员亲自执行，可以作为研发同学自测的标准。这样可以充分发挥该用例集的约束性。用时也就意味着，该标准必须得到一致性认可，并且必须明确，易操作（RD不是专业的QA要避免一些过于复杂的步骤，或者冗余的描述）
此用例集，不应过长（建议控制在10条左右）。且不应过多关注具体功能，更多关注整体的可测性。同时，应该具备充分的约束力，本着执法必严的精神，不让其成为空摆设。
2、功能测试用例集
【时机】：onTesting（功能，测试进行中）
【意义】：用来保证新功能符合既定需求，找出bug，并推动改进。
【经验分享】：
此用例集，是大家最为常见的用例集。但需注意，其子用例集需 架构清晰，子用例集之间尽量低耦合，以便在资源允许的情况下由多位同学并行执行，以提高测试效率。
此用例集，非常容易也最为忌讳变成对产品需求的简单复述。当然这也是区分高级测试工程师和初级测试工程师的环节。多用些专业的测试技巧。如边界值，等价类等。注重相关测试经验的运用，以保证测试维度。
在组织此用例集的用例时，建议用极简的标题，来表明用例的验证内容。并且多用动宾短语来使得表述清晰。此外还需要关注粒度的控制。让步骤，和验证内容都控制在合理的层级。以谋求测试覆盖范围和执行效率的平衡点。
3、回归测试用例集
【时机】：afterTest（功能测试完成后，发布之前）
【意义】：保证常用、重要或三级界面中的易见功能不出问题。
【经验分享】：
测试过程中可能会因为研发改动过某一个模块，导致其他模块不可预知的问题。也可能因加入某个较新的SDK导致难以预料的问题。此时从用户角度出发思考质量保证的方案非常有必要。也就是需要关注用户最常用的功能，以及自己产品主打的重点功能，或者那些显而易见（通常是三级界面之内）的功能。此时无疑需要针对这三个方面设计回归测试用例集。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
开源项目：docs.qq.com/doc/DSlVlZExWQ0FRSE9H
