软件测试
文章平均质量分 95
阿昌喜欢吃黄桃
这个作者很懒,什么都没留下…
展开
-
Day948.组件化成熟度评估,你的目的地在哪里呢 -系统重构实战
组件化成熟度评估模型。该模型分为 5 个等级,分别为原始级、入门级、标准级、进阶级以及创新级。同时从组件化的核心能力体现为 6 个维度,包括组件设计、集成编译、测试保障、架构守护、分支策略以及持续发布,每个维度同样也有 5 个等级,最终要以最低得分的维度作为最后的评估等级。成熟度模型一方面可以帮助制定改进目标,另一方面也可以帮助我们更好地度量结果,从而帮助我们去持续改进。原创 2023-04-17 22:35:51 · 551 阅读 · 0 评论 -
Day947.Android系统组件化 -系统重构实战
组件化设计就是将自己扩展的代码独立成内聚的组件,以二进制与整机集成,尽量减少在 AOSP 框架中的代码修改量。下面给你总结了组件化解耦常见的 3 种情况,你可以通过后面的表格回顾。一方面,能够帮助我们有效减少分支数量、多版本维护工作,让团队更聚焦在高价值的业务研发和质量打磨工作中。另一方面,也能帮助我们减少产品的质量问题、提高产品的响应力。相比应用的解耦,系统解耦的复杂度和需要处理的耦合场景更多,特别是相对于框架的解耦,编译调试验证的难度更大。原创 2023-04-16 23:16:11 · 981 阅读 · 1 评论 -
Day946.厂商定制的Android系统为什么也要解耦? -系统重构实战
各个分层职责清晰,从上到下依次为应用框架层、Binder IPC、系统服务层、硬件抽象层以及 Linux 内核层。但是当厂商开始定制 Android 系统时,由于项目管理、交付压力等等情况,非常容易出现不按规矩出牌的情况,总结了 3 种最常见的耦合场景,后面的表格回顾。由于耦合的问题,团队需要完成大量重复、机械性的代码合并工作,也需要同时维护多个并行的版本。原创 2023-04-15 14:15:59 · 552 阅读 · 0 评论 -
Day945.Android系统开发的版本管理、编译与自动化测试 -系统重构实战
Android 系统开发的一些基础设施工具,与应用开发相比,系统开发更加复杂。为了解决多仓库开发的问题,官方提供了 Repo 及 Gerrit 工具。Repo 帮助我们可以去批量操作多个 Git 仓库,这大大简化了我们跨仓修改时代码提交同步的工作量。Gerrit 工具也通过 Change-ID 的形式帮我们关联多个仓库的提交记录,方便我们做 CodeReview。原创 2023-04-15 00:45:10 · 1378 阅读 · 0 评论 -
Day944.度量指标 -系统重构实战
通过度量指标可以帮助明确方向,及时反馈结果,推动持续改进。通常在项目中,都会搭建度量相关的看板来持续观察数据的变化,同时也会在团队定期的回顾会上,复盘这些数据制定改进目标。不建议团队将度量指标纳入 KPI 中,这样非常容易导致走向另外一个极端,失去了度量关键的意义。下面度量指标的定义、目的、建议阈值及趋势等总结成表格。给出了一些通用的建议参考阈值,具体的产品不同,情况可能会有差异。原创 2023-04-13 22:26:17 · 1185 阅读 · 0 评论 -
Day942.独立编译调试 -系统重构实战
3 种组件独立编译调试的方法。传统的集成编译需要我们将所有组件一起打包进行测试验证,如果开发每次修改代码都需要进行集成验证,那么效率会比较低。采用组件独立编译调试的方法,能够在开发阶段帮助更加高效对功能进行验证。一张表,总结了这 3 种调试的优缺点对比,供参考:在实践中,一般在本地开发进行验证时采用组件独立编译调试的方式,但当代码提交时会有流水线来做集成的验证检查,保证最终的代码提交质量。原创 2023-04-11 23:27:20 · 533 阅读 · 1 评论 -
Day939.如何小步安全地升级数据库框架 -系统重构实战
改造前 Sharing 项目使用了 SQLite 来管理数据库,这个方式主要存在 2 个问题。第一个是使用拼写 SQL 方式来管理表创建,不便于扩展;第二个是存在大量的对象转换重复代码,不便于维护。根据官方的建议,使用 Room 框架来帮我们完成这些重复的工作,让可以更聚焦在业务开发上。Room 框架的升级可以分 2 个阶段完成。第一个阶段是先引入 Room 框架。原创 2023-04-08 23:11:22 · 479 阅读 · 0 评论 -
Day938.消息组件Kotlin+MVVM重构 -系统重构实战
ViewModel 与 View 之间会通过 DataBindng 自动进行双向同步,所以需要先定义好关键的数据。// 数据列表// 异常信息在 MessageViewModel 类中添加对应的 LiveData 数据,同时将原本使用 Thread 创建异步的方法调整为使用协程来进行统一管理。由于这部分都是新增代码,所以下面直接展示调整后的最终代码。try {errorMessageLiveData . value = "网络异常,请点击重试。" } else {原创 2023-04-07 23:20:15 · 444 阅读 · 0 评论 -
Day937.化整为零,落地文件模块MVP重构 -系统重构实战
自动化测试作为防护网来保障整个重构的安全性。在实际的重构过程中,每当修改了代码,都可以频繁运行守护测试,提前发现修改导致的错误。另外,通过安全重构的手法,尽可能让编辑器自动帮助完成重构工作,减少人为直接挪动和修改代码。这样一方面可以减少手工带来的潜在错误,另外一方面自动化能大大提高整个重构的效率。原创 2023-04-06 22:38:36 · 419 阅读 · 0 评论 -
Day936.如何重构过大类 -系统重构实战
重构的流程和关键的要点都总结到了下面这张图中。分析阶段的两个步骤让以始为终,深入了解需求和代码现状;重构阶段的四个步骤让能更加安全、高效地完成代码调整;验收阶段则提醒我们,只有集成才是真正地完成了重构工作。原创 2023-04-05 20:33:37 · 1503 阅读 · 2 评论 -
Day932.5个步骤,高效推动组件化架构重构 -系统重构实战
组件化架构重构的流程,包含设计、守护、解耦、移动以及验收 5 个步骤。其中,解耦是整个代码落地的关键步骤,提供了 4 种常用的解除依赖的方法。下面将这 4 种方法的定义、使用场景及注意事项总结一下。原创 2023-03-31 22:48:15 · 1722 阅读 · 0 评论 -
Day926.架构是如何跟随业务演进的 -系统重构实战
从 Sharing 项目早期的问题来看,遗留系统带来的问题不仅仅降低了研发过程中的效率和质量,最终还导致产品的响应力和表现力都很差。由于代码耦合严重,无法拆分独立的组件。这样导致所有的需求需要统一规划发布, 灵活性差。另外,由于缺少足够的自动化测试覆盖,往往只能在最后的交付阶段进行人工测试,版本发布周期非常长。软件的架构就好比一座房子的地基,决定着这座房子能盖多少层楼。同样地,对于遗留系统来说,架构决定着软件产品能走多快、多远。要想解决遗留系统中一系列的问题,架构改造是关键的举措。原创 2023-03-24 23:23:27 · 391 阅读 · 0 评论 -
Day925.如何提升遗留系统代码的可测试性 -系统重构实战
如果原来的软件中没有任何接缝让去设置数据,或者说设置这些数据的成本非常高,那么这个时候就说代码的可测性低,编写自动化测试的难度就更高。可以通过下面这六种方式来暴露程序的接缝。其次,可以通过测试替身来替换被测系统的依赖。常见的测试替身有六种,分别为 Dummy、Stub、Spy、Mock、Fake 及 Shadow。通过使用测试替身技术可以隔离被测试代码、加速测试执行、确定执行变更、模拟特殊情况,从而让测试代码覆盖得更全、执行得更加高效稳定。原创 2023-03-23 21:58:32 · 497 阅读 · 0 评论