刚加入互联网企业时，有两个事情让我印象深刻，并给我很深的思考，

1.互联网企业做性能测试时，一般10分钟左右就完成测试，而传统企业性能测试时间大多在几个小时，有什么甚至要做到7*24小时，为什么会这样呢？到底是什么原因导致有这么大的差异？
2.另外一个事情是刚到金融不久，开发金条项目，第一个版本上线的是借款，第二个版本上线的是还钱（大概2周后），后续的版本逐渐上线的合规风控等。这个事情当时给我一个很大的震撼，互联网企业不讲规则，原来还可以这么玩！

为什么有这么大的差异呢？需要从客户（用户）自身的组织目标、人员能力、技术等方面进行分析。本文主要通过分析ToC和ToB之间的差异，探索互联网企业向ToB转型质量保证工作着力点和抓手。

ToB和ToC四个根本差异

面向互联网企业的ToC和面向传统企业的ToB有诸多不一样，通过个人多年总结实践及思考主要有四个不同，组织目标不同、客户（用户）不同以及技术架构不同，技术架构差异进一步分化体现技术能力的差异和运营（运维）能力的差异。

1）组织目标不同

传统ToB企业大多肩负着国计民生，如金融、电信等企业，组织目标以安全稳定为第一要务。基于安全稳定这一目标，在企业文化、组织流程、技术选择时都会相对保守，一般会选择既要业务发展又要组织稳定的考核与协作机制。

2）客户（用户）不同

传统ToB客户对象多为有一定专业能力的人群（如银行业的柜员、业务员等），客户在某一领域具有专业的知识和业务能力，可以是领域专家，他们对交付的产品除了要求像互联网产品那样简单易用，还要求交付系统符合领域内的业务规则和逻辑。这要求在ToB产品需求调研时，要更为深入的调研，在交付过程要保持持续沟通，以确保产品能够高质量的交付。

3）技术架构不同

传统ToB企业，早在上个世纪70、80年代就开始对其核心能力进行信息化改造升级，有部分企业核心系统一直还在使用。这些较老的技术架构，一则是相对互联网新兴技术来说显得比较落伍；二则因为技术架构存在的时间长，完全了解其技术和业务的人员相对较少，因此在ToB企业存在技术架构升级和改造成本较高；导致传统ToB企业各种技术架构并存，比如常见的总线架构和分布式架构并存。所以在质量保障手段和策略上存在着很大的差异。

4）运营（运维）能力不同

传统ToB企业的运营运维主要采用自主运维加代运维相结合的方式进行。这种运营运维模式，比互联网自运维模式要在对系统维护响应速度上来说要慢一些，再加之传统ToB企业安全稳定的组织要求，在流程上要更加严格。为了弥补运维响应速度、架构上的差异，就要求在质量保证体系上有更严格的质量保障要求。

互联网性能测试只要十分钟？

什么互联网企业性能测试只要十几分钟甚至更短，传统企业要几个小时甚至更多呢？从上章节提到四个差异分析。

1）技术栈的不同

主要有技术架构的不同，互联网企业技术架构大多采用微服务架构，扩展性较好；在系统遇到业务高峰时，可以通过快速扩展、限流、降级等技术手段，可以使用很短的时间（5分钟之内）解决业务洪流所带来业务压力。

而传统企业技术就各种复杂，各种技术栈混在在一起，核心系统大部分系统是总线结构，有些老系统甚至是上个世纪七八十代的产物。这就导致系统在遇到业务高峰时，很难快速实现系统扩展。从而需要在上线前做各种复杂的测试和验证。

2）组织目标不同

互联网企业的要求是快时实现业务上线，快时完成业务验证，快速占领市场取得先机；所以有时候在达成业务目标时可以允许流程灵活制定和执行，可以在紧急情况下根据需要灵活实现业务能力扩展（增减机器）。

而传统目标是系统能够安全稳定运行为目标；为了保障这一目标，有很强的流程保证和审批机制，即使技术架构具备快速扩展能力，但在流程和制度的影响下，也不能实现快速伸缩扩能，实现业务系统的业务能力快速增强。

3）运营（运维）能力不同

互联网企业基本上都采用自主可控的自运维模式，出现问题时可以在第一时间进行快速的处理，甚至机器网络的扩展，快速响应业务洪流带来的影响；而传统企业大多采用代运维（外包或者第三方运维）的方式或者自运维加代运维的模式，出现问题时需要协调和沟通的业务方较多，从而影响在第一时间进行快速扩展的能力。

金条项目迭代

1）用户（客户）不同

ToC市场，面向的用户复杂，上至七八十岁的老人，下到两三岁的小孩，既有城市高级知识分子，也有乡村识字不多父老乡亲，他们共同的诉求就是满足需求，简单好用；而ToB市场，面向的客户主要是具有一定专业能力的业务专家，他们既要求满足需求，简单好用，同时也要求满足业务基础专业规则。

像金条业务，这样先上线借款功能，在上线还款功能，在互联网企业从用户的角度觉得这样没什么问题，当前最主要的先验证客户有没有这样的需求，先满足用户借款的需求，只要在下一个还款周期之前上线用户的还款功能，这样既满足用户的需求，又可以解决业务快速上线的压力，一举两得。但对于ToB客户来说，借款和还款分开上线，从业务的角度有借有还，这是基本的业务常识，拆开来上线不合业务逻辑，从技术的角度不符合闭合原则，很难在业务和产研侧得到认可并上线。互联网企业就是依靠突破原有业务实现逻辑，通过小步快跑的模式，不断迭代和验证客户需求，滚雪球式的快速壮大并蚕食传统企业的市场份额。从这个意义上来说，敏捷模式是搭上了互联网企业高速发展的快车道，实现了自身的超规模发展。

2）组织目标不同

正如前文提到，ToB企业要求安全稳定，在业务决策时相对偏保守，一般会通盘考虑，反复讨论论证后才开始实施，谨慎的态度使得传统企业在互联网企业冲击下会错失很多机会。

3）技术要求能力不同

因为组织目标的不同以及历史包袱的影响，导致传统企业在新技术的应用和推广上明显落后于传统企业。技术上的差异直接影响质量保证的手段和策略不同。

ToB质量保障目标与策略

基于ToB和ToC在组织目标、客户群体、技术要求、运维能力上的差异，ToB质量保证体系和ToC质量保障体系有很大的不同，如何高质量、低成本、高效率的完成项目交付，是互联网企业向ToB转型质量保证的核心目标。要实现这个目标，必须构建一个完整的ToB质量保障体系。通过个人多年的实践以及结合行业最佳实践，而在对ToB质量保证体系中必须做到“四化”，能够实现“高质量、低成本、高效率”的交付。“四化”即流程标准化、业务组件化、工具通用化、人才能力模型化。

流程标准化，就是将整个质量保证工程流程化，质量保证人员只需要对照流程，做好每一个关键活动工作，并按照要求完成输出工件产品，在研发测试阶段实现快速迭代，在交付质量保证阶段实现高质量交付体现专业能力。另外流程标准化中还需要在每个节点和关键流程产出上标准化，从需求开始到交付结束软件全生命周期内文档内容要做到标准化，实现快速向内部人员、生态伙伴、客户交付高质量成果。

通过业务组件化，将复杂的业务拆分成一个个组件并整理形成通用的测试方法或者测试用例，并提供给相关人员学习。从而实现人员能力与业务的解耦，降低业务对人的依赖。

针对ToB企业交付标准化流程和交付环境的复杂多样化，工具层面既要实现端对端的流程管控，又要注重实现工具在不同环境下的兼容性，特别是在自动构建和自动测试环节需要重点关注。

互联网企业要实现ToB交付高质量、低成本、快速交付目标，必须合理引入生态共建，引入生态带来的第一个问题就是产品质量的控制。除了通过流程标准化、业务组件化、工具通用化、还需要实现人才能力的快速复制，要做的人员能力的快速复制必须建立标准人才体系，通过对人才定义并分级分类，专项培训与认证，实现人才快速复制培养。

以上从组织目标、客户群体、技术要求、运维能力上的比较说明互联网和传统企业差异，提出ToB企业质量保证目标和实施策略。后续继续从ToB质量保证体系和ToB端对端交付质量能力建设来进一步阐述和说明。