中台业务测试&白盒测试

1.什么是中台？

行业中把中台分为：技术中台、业务中台，组织中台（类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”）

我认为：中台其实就是提供各种能力到上层

2.中台业务测试流程

需求阶段：

做正确的事比正确地做事更重要，问题发现越晚，修复的成本就越高，在需求阶段测试左移，开发测试产品一起参与需求评审，测试参与技术评审，提前发现设计问题、可测性问题，当然这会需要开发和测试有比较强的需求分析能力和测试分析能力。

开发阶段：

我们会提供冒烟测试用例，并要求开发在提测之前完成执行，有两个目的，一是减少提测的轮数，提测打回的次数越多，资源浪费就越多；二是很多开发不是不想测而是不知道测什么，冒烟测试阶段测试会给开发用例，可以帮助开发梳理要自测的用例。在冒烟测试执行过程中，开发可以跟测试确定一个合理的冒烟用例数。

 我们对于核心应用的静态代码扫描以及单测也有一定的要求。

 

上图是测试金字塔，越是上层的测试，就会耗费越多的精力、时间和成本。假设我们在验收阶段发现了问题，这个时候修复代码会导致之前测过的功能很可能需要重新测试一遍，项目延期的风险很高，而且bugfix有引入新bug的风险。所以我们希望在单测或者静态代码扫描阶段可以尽可能发现问题，降低成本。

测试阶段：

目前通知中心有15个核心场景自动化，200个测试用例，业务覆盖率为95%以上，如此庞大的用例量无法通过单纯的功能测试进行很好地质量保障，搭建完善的自动化保障体系非常重要。开发体测后，我们针对本次改动的业务场景先跑一边自动化，如果结果与预期不同或者断言不通过，立即排查定位问题

 

拿通知中心来说，从拿到需求，根据接口文档来看 入参出参校验，边界值啥的

接口报错 500（服务器内部错误） ，404,403（服务器拒绝请求）,502（错误网关）,503（服务不可用）

怎么排查问题，步骤 从controller出发——service层——serviceImpl业务逻辑——，逐级排查，代码逻辑正常，是否符合业务需求，是否有内存泄露风险，针对多线程，mq消息，怎么去服务器上看日志，根据日志报错 找到对应的代码行

查看数据库的字段是否符合需求，增删改查时数据库字段是否更新；

上线阶段

线上自动化测试回归

线上日志监控

线上接口探活

总结

找bug不是目的，保障线上质量才是！