测试目标定义
对照目标系统，如下：
给出自动化测试平台目标如下：
| Case level | Case brief | Report send to |
| OVERALL | User 1 -> Process -> Customer 1 | Boss |
| Level 1 | User 1 -> Process -> Customer 1 User 1 -> Process -> Customer 2 User 2 -> Process -> Customer 1 ... | Manager, Some users, Developers, Testers |
| Level 2 | User 1 -> Igeress -> Process -> Router -> Sender 1 -> Customer 1 User 1 -> Igeress -> Process -> Router -> Sender 2 -> Customer 1 ... User 1 -> Igeress -> Process -> Router -> Sender 1 -> Customer 2 User 1 -> Igeress -> Process -> Router -> Sender 2 -> Customer 2 ... | Manager, Developers, Testers |
| Level 3 | User 1 -> Igeress -> Process -> Router -> Sender 1 -> Customer 1 , check configuration and logs ... | Developers, Testers |
| Others | System capacity: xx GB remains, xx GB consumed after last check Respond time: API1 - xx ms ... | Can be combined with OVERALL cases |
OVERALL： 整体用例，这部分用例只保证系统还能运行，定期发报告给老板
Level 1： 覆盖从输入到输出的每个组合，比OVERALL的用例更能说明系统运行正常。
Level 2： 需要覆盖输入输出意外，内部子系统的组合也要覆盖到。
Level 3： 除了覆盖所有子系统，也需要检查配置、日志等非对外子系统是否正常。
OTHERS： 非功能性要求，包括剩余存储容量、API响应时间等，由项目相关方共同定义。这部分也可以包含在OVERALL或者Level 1报告中。
最小测试队伍组成
一个团队主管，初期建立时也可以兼任项目经理，统筹团队成员和项目管理。
BA或者Tech Lead，能够对目标系统进行抽象，可以设计测试目标、拆分用例。可以支持外部的讨论并给出预算、计划等，初始平台框架搭建由他负责。
用例开发多名，根据进度要求和系统复杂度配置，对特定技术范围的用例负责。在某系统用例比较完备以后部分开发转为系统维护，负责检查报告的失败项并判断是否由最新代码提交引起。
用例维护者，判断是否代码引起系统异常，并且驱动对应开发人员快速修复BUG。
开发计划
OVERALL，OTHERS，一般小于20个用例，2个月以内。如果使用已有框架并且可以快速确认目标场景，一般可以缩短进度，具体项目具体分析。一般此时队伍规模不大， 5个人左右即可启动。
Level1，一般要几百个用例规模，需要根据需求增加开发者数量，至少需要6个月逐渐稳定输出报告。
Level2，一般几百到上千用例，需要一到两年的周期完成。如果需求紧急此时可以通过增加开发人员加快进度。
Level3，用例数可能达到上万，进一步细化甚至对部分关键模块进行白盒测试，直到对所有模块有足够的信心。目标达成可以将大部分开发释放到其他产品，只留部分维护者。但是由于产品在不断变化，包括部分功能甚至子系统的重构或者业务迁移等，很多情况还是需要保留用例开发进一步满足要求。这个阶段是稳定的维护阶段，时间和软件的生命周期一致。
ROI
| STAGE | Investment | Revenue |
|---|---|---|
| L1 | 4 HCM | NA |
| L2 | 30 HCM 5 members, 6 months | 54,000 USD 9,000 USD, 6 months |
| L3 | 144 HCM 8 members, 18 months | 810,000 USD 45,000 USD, 18 months |
| Continuously | 4 HCM/month | 72,000 USD/month |
本次内容是假设的抽象模型，并没有具体数据支持，因此这里只提供一个计算方法，大BOSS会关心ROI。
Investment，只计算了人力投入HCM，没有考虑运行环境等其他成本。
Revenue，假设每个月有30个包要release到生产环境，每个测试报告成本3,000 USD（按照人力成本远远不止）。假设在L1 / L2 / L3上线后，我们可以节省测试费用的10% / 50% / 80%，那么整体每月可以节省9,000 / 45,000 / 72,000 USD费用。
ROI折线图这里不提供，但是结论很明确，随着使用时间越来越长，投入成本一定可以收回，在此之后就是净收益阶段。
管理规定
使用一个新规则会导致很多人的工作流程发生变化，我们必须制定一些规则否则结论一定是“系统不好用”并且最后放弃。我们针对不同角色给出工作流程的变化和必须遵守的规则。
对BOSS：
每天检查OVERALL用例是否通过，以确定产品是否还正常工作。
对测试团队上报的关键用例失败，督促Manager尽快解决。
参加测试团队组织的月度质量例会，回顾上一个周期发生的关键事件并作出调整决策。
对Managers：
每天检查L1 / L2报告，主动发现问题。
发现任何失败，主动找开发，尽快解决问题。
对Software developers：
检查L2 / L3报告，如果有自己工作范围内的用例失败，马上投入，尽快解决。
奖惩：
应该根据业务实际情况设置SLA
应该根据执行情况记录到相关人员的KPI，对后续绩效评价起到参考作用
应该及时对执行情况进行奖惩
