150 万行代码。0 个测试。我们应该从哪里开始?

软件测试 测试创建 遗留系统
2022-02-04 19:15:48

我是一名 Java 开发人员。我在所谓的最佳实践中“长大”。然后我接受了我现在的工作。我在 Java/SOA 团队和 ERP 团队之间做出了选择。有人告诉我,加入 ERP 团队会让我对业务运作方式有最好的了解(不是在技术方面,而是在业务方面。)所以我选择了 ERP。

我发现一个系统包含超过 400 万行“Progress 4GL”代码(因为“4GL 听起来很糟糕”而重命名为 Openedge ABL)代码,分布在大约 11000 个文件中。最好的部分是,没有文件存在超过一个文件夹。所以你有大约 50 个文件夹,每个文件夹中有 300-400 个文件。幸运的是,许多文件在 7 年多的时间里都没有被修改过,其中许多文件已被弃用(但我们不会“以防万一”将它们从版本控制中删除。甚至不要让我开始处理那个文件。 ) 所以我们实际上只需要测试大约 150 万行代码。“仅有的。”

我可以继续谈论该系统的不良做法。底线是多年来,开发人员没有选择拒绝。这是“给我给我给我”,再加上很多承包商进进出出。现在,他们想清理自己的行为。

我建议的第一件事是测试。他们说,基本上“我们多年来一直想进行测试,但我们真的不知道从哪里开始。” 业务逻辑和数据库访问被嵌入到 UI 中。(我会说 GUI,但它不是图形的,它在大型机上。即使是订单输入人员也可以远程登录。)

所以这几乎是最坏的情况。数百万行代码。超过 10 亿美元的年销售额通过该系统运行,因此不会被重写(显然“它按原样工作。”)没有面向对象。没有正式的或自动化的测试。我们的测试人员也是编写规范的人(这使他们倾向于“推动项目通过”。)

我越来越绝望了。我什至愿意在业余时间编写我们需要的任何测试框架(开源框架中的 Openedge 并不多)。我相信它会很快收回成本。我们可以从哪里开始?这里有没有人遇到过类似的项目(即使规模较小),如果有,您是如何应对和克服的?

更新:我已经与我的经理进行了交谈,并且我已批准为创建测试工具制定规范/时间表。起初,我听到的是:“我们真正需要做的是编写一些测试。” 我回答说:“如果我们没有办法运行它们,那么进行测试并不会真正帮助我们。我一直在研究 ProUnit(OEUnit 的旧名称)并认为它对我们有用。” “我们应该用它写一些测试。” 重复了大约 10 分钟,他才意识到这并不像下载库并“使用它”那么简单。但是,批准编写规范以创建测试工具是一个开始!谢谢大家的意见!

4个回答

你即将踏上一段没有尽头的旅程,所以重要的是手段,而不是目的。

决定从哪里开始

  1. 业务第一:正如劳拉所说,确保您的工作直接改善对业务重要的领域
  2. 指标:在开始之前和进展过程中获得良好的指标至关重要。保持你的指标是最新的,最好是自动化,因为这将是你不断的指导和理由。
    • 正如 Tangurena 所说,找到缺陷率较高的区域。这是一个很好的代码气味
    • 静态分析:您可以运行任何工具,例如 sloccount、lint 或计算复杂度的工具(例如 McCabe)、依赖图吗?如果有 Findbugs 或等价物就更好了 :) 这样做可能会突出以下区域:
      • 特定问题密度
      • 高于平均复杂度
      • 高度依赖(例如,许多其他函数使用的例程和库函数)。一个函数的依赖或使用越多,它对系统的影响就越大
    • 动态分析:你能检查出哪些子程序更常被调用,甚至根本没有被调用吗?(也许通过检查日志文件或代码覆盖工具中的模式)测试这些会产生更大的影响
  3. 决策:制定并保持最新的分析,该分析基于:
    • 对业务最重要的模块/功能
    • 每个模块中的缺陷率/ksloc(每千行代码)(对于关键、主要、次要等具有不同的值)
    • 每个文件中的设计/代码质量问题/ksloc
    • 每个模块/功能的依赖数量

单元测试与自动化 GUI/CUI 测试

有时,特别是在不是为测试而编写的代码库上,如果不进行重大重构,编写单元测试几乎是不可能的——模块对其他模块有很多依赖,并且都依赖于在 4GL 运行时中运行。

当单元测试重构所涉及的成本(和风险)太高时,您可能希望自动化前端测试而不是构建单元测试。虽然您将无法获得单元测试的代码洞察力,也无法获得非常高频率的测试修复周期,但您获得的测试与最终用户体验(从而管理幸福感)直接相关。

自动化 GUI/CUI 测试开发通常也由不同的开发团队进行,而不是核心软件工程师,因此可以在不影响核心工程团队的情况下实际进行。

我们可以从哪里开始?

如果您有错误跟踪系统,请获取过去几年的某种错误报告,按模块细分(如果可能的话)。然后制作一个直方图/帕累托图,看看哪些是 bug 最多的区域(每个 bug 计为 +1,每个重新打开的 bug 计为 +1,每个“没有修复它的开发者”计为 +3)。这些区域是您应该尽最大努力添加测试的地方。“7 年未触及”的文件不会出现在此类报告中。

对网络的快速检查表明OEUnit是 OpenEdge 的单元测试框架。这是一个好的开始,因为它表明您不必发明这样的野兽。

第一次没有修复的错误可能意味着马虎的编码器、糟糕的规格或比最初出现的问题更复杂的问题;这就是为什么在尝试对开始关注的领域进行分类时,他们应该计算得更高。

我似乎记得有一本书专门针对这种情况。等一下我搜索亚马逊...

...我们开始:有效地使用遗留代码

我承认我自己没有读过这篇文章,但我听说过它的好消息,它有 4.5 颗星。

是的!我也是!你说非结构化?你有我最深切的同情;即便如此,听起来你在执行规则和合规方面的权重比在我这个小而热情的团队中真正的权重。

从广义上讲,这就是我所做的:

  • 选择了一个模块并开始为它编写测试用例——向月球射击,但仍然接受我设法记录的内容(我开始时测试用例为零,所以有总比没有好)

  • 开始我自己的个人错误列表来跟踪和监控我自己、我的错误和客户的错误(我工作的地方有/没有专业的缺陷跟踪系统;只有一个不生成报告的准系统本土系统 => 所以,没有像样的缺陷跟踪系统=没有人有错误列表....也就是说,直到我在 Excel 中创建了一个供我自己使用的错误列表)

  • 由于这个团队不习惯记录,所以使用清晰和尽可能少的步骤和屏幕截图来记录我自己的错误

  • 记录客户错误修复并在支持人员创建的错误远无法理解时与他们澄清差异

  • 如上所述记录功能/增强功能

  • 与他人分享获得的知识,以便他们受益(因为他们可以处理......不是每个人都想接受教育)

我怎么强调都不过分:去找管理层,就你应该关注/花时间在什么方面获得明确的指示,无论你多么想这样做,都不要偏离这一点。在这种环境中开拓创新之前,您必须赢得他们的尊重。