【软件工程】自动化测试保证卓越软件工程能力（3）

测试目标定义

对照目标系统，如下：

 给出自动化测试平台目标如下：

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，对后续绩效评价起到参考作用

                应该及时对执行情况进行奖惩