自动化遗留项目时如何衡量进度？

#1 楼

对于遗留系统，尤其是在没有较低级别的自动化可利用的情况下，我发现首先进行分析以确定应用程序的主要功能区域以及它们获得的使用量是有帮助的。然后针对主要区域中的小节重复该分析。

这使我可以找到基本剩余量的基本指南，并确保首先涵盖系统中最重要的部分。

例如，假设您的应用程序是销售和库存管理的集成应用程序。

主要功能包括：


登录（必需的，必须是自动化的，因为没有登录用户就无法使用该系统进行其他操作）
用户管理（主要是在人员变动时使用，如果有问题可以解决）
商店/位置/仓库设置（通常一劳永逸：新店一年可能开一次或两次，现有的商店很少会完全关闭）
销售点设置（同样，多数情况下是一劳永逸的事情）
付款设置（一劳永逸的事情）
现场购买（会一直使用）
预订（将一直使用）
报告（将经常使用）

登录，购买和预订将被使用成为您自动化程度最高的模块，将报告作为下一个优先事项。

在现场购买模块中（仅作为示例），您可能具有以下功能：


销售完成后库存更新
不同的产品类别要求（例如，小部件A可能按尺寸出售，因此与无选项的小部件B相比，您需要不同的产品选择过程）
产品部门
需要特殊处理的项目类型或产生相关费用，例如安装费，送货费等。
付款方式和处理方式
退货

等等。

由于每个应用程序都不相同，因此每个应用程序的用户基础和使用配置文件都将有所不同，因此您需要自己完成此操作。

了解哪些功能得到了最大程度的利用也有助于为新功能安排自动化-关于使用它的可能性，可能有必要优先考虑使新功能自动化而不是赶上现有功能。

#2 楼

一种方法是花一些时间来创建所有应用程序功能的主列表。最简单的方法可能是将列表基于UI功能。一种更复杂的方法是基于代码，类，方法等，将重点放在后端上。

有一个清单-说278个功能，然后您可以衡量它们自动化的进度，例如当完成28个任务时，您将占整个列表的10％。

仅通过主列表和完成多少任务就可以非常简单地完成此任务。但是它并不精确，因为存在许多因素，例如共享功能代码，不同的功能复杂性，使用频率，数据驱动测试，验证验证等。但是，它总比没有好，并且可以在敏捷环境中进行优化和调整随着时间的流逝。

#3 楼

TL; DR：代码覆盖范围



对遗留项目进行“自动化”改造


遗留意味着什么？


对我来说，遗留代码只是没有测试的代码。

传统代码难题：当我们更改代码时，我们应该就地进行测试。为了进行测试，我们经常必须更改代码。

-Michael Feathers（有效处理遗留代码）


Michael Feathers描述了一些好的方法如何围绕无法测试的代码编写测试。现在，您应该重构这些类，以便您可以对它们进行单元测试。现在，您可以再次删除大多数较大的端到端测试。

由于团队可能掉入测试冰淇淋蛋筒陷阱，改装这个词使我感到恐惧。您将希望在单元测试，集成测试和端到端测试之间取得良好的平衡。在这里，我认为代码覆盖率作为度量是有意义的，因为它显示了您尚未被测试覆盖的分支。一旦覆盖了所有分支，就可以开始进行重构了。

如何知道测试是否覆盖了代码？代码覆盖率。
如果您问我，我会选择分支覆盖率作为衡量进度的主要指标。