说起我拍厂大什么数据部门的技术架构，可谓是百花齐放百家争鸣，各种编程语言漫天飞。
有性能直逼C/C++而且应用广泛的
及框架等；
也有无缝衔接TF等一众机器学习框架的
及框架等；
更有突然火起来的
及框架 （我没有Logo我是抄隔壁的）；
还有其他C#，Ruby on Rails等小众而优美的语言。
走读代码是非常有效率也非常推荐的开始方式，而基础是尽快掌握新的语言。走读代码的优势体现在：
1.快速熟悉已有业务功能，不仅仅限于产品文档和对接介绍，而是包含所有业务细节和逻辑；
2.快速确认新增业务逻辑实现是否正确合理；
3.结合自身的技术积累和测试经验，能很快发现基本业务功能之外的诸如高并发多线程情况下是否有其他功能或性能问题。
不仅仅需要能够看懂代码，也要能使用所掌握语言开发各种测试工具，包含但不限于下图所示：
总之尽可能把一切繁杂重复的质量保证工作都转化为代码来完成，提高团队的工作质量和工作效率。
有新需求要上线了，如何才能保证已有系统和新增需求在各个维度都完美无瑕？
全量回归看似是个完美的方案，但在面对风控系统中几十条借款业务线、近百种外部数据源、千余个中间变量的快递迭代上线时，全量回归就显得不切实际又效率低下：
1.全量自动化回归需要解决环境稳定性和维护大量回归用例的繁杂问题
2.局部功能的调整又没有必要全量回归。
那么究竟什么才是最可行又极具产出比的测试方案？
在保证对核心关键业务功能的自动回归验证通过的基础上，通过对已上线和即将上线的代码版本的对比：
1.分析每一行已有代码变动的原因，并全局搜索相关改动影响到的功能，执行针对性的验证测试，并适度扩大针对性测试范围，保证已有系统一切正常；
2.对新增代码执行相关的功能、性能等测试，保证上线后系统整体可靠。
在实际工作中，使用这样的方案，需要测试人员对所负责系统业务、代码有足够的熟悉程度，可以很大程度上提高工作效率并有效保证上线质量，从而可以承担更多的任务和职责。
代码实现需求，测试用例验证需求，那么会有以下问题：
1.测试用例究竟覆盖到了哪些代码？
2.是否有冗余代码？
3.是否有需求文档未阐明但代码实现了的业务逻辑？
4.是否有开发同学未沟通到的代码改动或优化？
使用代码覆盖率统计工具，可以完成这样任务。不同的编程语言使用的代码覆盖率统计工具也不一样，应用广泛的工具有Java的Jacoco，Python的Coverage，均可以在单元测试和Web服务器端测试中，完成插桩、数据收集和覆盖率报告生成。
使用IDEA执行Java单元测试，既可以统计到Class文件覆盖率，也可以有效统计到被打包引用的代码，获取项目整体代码覆盖率报告。
使用UWSGI等Python Web服务器，加载Python Coverage模块来启动项目，通过调用对外暴露接口的方法，也可以获取项目整体代码覆盖率报告。
在覆盖率报告中，可以完整的分析文件覆盖、语句覆盖、判定覆盖、条件覆盖等，继而发现测试未覆盖到的代码逻辑，补充更多的测试用例，从而尽可能达到100%的测试覆盖率。
金融科技的测试质保工作时时面临挑战，发布经常需要面对新的业务、技术和平台，测试技术种类繁多，各有所专各有所长，需要不断学习并尝试使用新的技术、方法，并辅以细心、负责的工作态度，才能做好支持业务稳健发展的坚强后盾。
Realworld