150万行代码。0次测试。我们该从哪里开始？
我是一名Java开发人员。我是在你所谓的最佳实践中“长大”的。然后我接受了我现在的工作。我可以在Java/SOA团队和ERP团队之间做出选择。我被告知，加入ERP团队将使我对企业的运作方式有最好的洞察力(不是在技术方面，而是在业务方面)。所以我选择了ERP。
我发现了一个系统，它有超过400万行的“Advancement4GL”代码(自从改名为Openedge ABL，因为"4GLs听起来很糟糕“)代码，分布在大约11000个文件中。最好的部分是，没有一个文件存在多个文件夹下。所以你有大约50个文件夹，每个文件夹中都有300-400个文件。幸运的是，许多文件已经超过7年没有被访问过，其中许多文件被废弃了(但我们不会“以防万一”从版本控制中删除它们。甚至不要让我开始做那件事。)所以我们实际上只需要测试大约150万行代码。“只有”
我可以不停地谈论这个系统的不良做法。底线是多年来，开发人员没有选择说不。这是“给我，给我，给我”，与许多承包商搬进和离开。现在，他们想要清理他们的行为。
我建议的第一件事之一是测试。他们说，基本上“我们多年来一直想做测试，但我们不知道从哪里开始。”业务逻辑和数据库访问被写入UI中。(我想说GUI，但它不是图形化的，而是在大型机上。即使是订单输入的人也会上网。)
所以这是最坏的情况。上百万行代码。超过10亿美元的年销售额通过这个系统，所以它不会得到重写(很明显“它是工作的”)。没有目标定位。没有正式的或自动化的测试。我们的测试人员也是编写规范的人(这使他们倾向于“推动项目通过”)。
我越来越绝望了。我甚至愿意在业余时间编写任何我们需要的测试框架(开放源码框架中的Openedge没有太多)。我相信它很快就会付出代价的。我们从哪里开始？这里有没有人遇到过类似的项目(即使规模较小)，如果是的话，您是如何应对和克服这一问题的？
更新:我已经和我的经理聊过了，我已经批准为创建一个测试工具制定一个规范/时间表。起初，我听到这样的话：“我们真正需要做的是写一些测试。”对此，我的回答是：“如果我们没有办法运行测试，那么测试对我们没有任何帮助。我一直在研究ProUnit (OEUnit的旧名称)，并认为它会对我们有用。”“我们应该用它写一些测试。”经过10分钟的重复，他才意识到这并不像下载图书馆和“使用它”那么简单。但是，批准编写规范来创建测试工具是一个开始！谢谢各位的投入！
回答 13
Stack Exchange QA用户
发布于 2012-05-03 05:36:30
你即将踏上无止境的旅程，所以重要的是手段，而不是目的。
决定从何处开始
- 商业第一:正如劳拉所说，确保你的工作能直接改善对企业重要的领域。
- 度量:无论是在开始之前还是在进展过程中，都必须获得良好的度量。保持您的指标更新，最好是通过自动化，因为这将是您不断的指南和理由。
- 正如唐古雷纳所说，找出缺陷率较高的地区。这是一种很好的代码气味。
- 静态分析:您能运行诸如sloccount、lint或计算复杂度(例如McCabe)、依赖图之类的工具吗？更好的是，如果存在Findbug或等效的:)，那么这样做可能会突出显示：的区域
- 特殊问题密度
- 高于平均复杂度
- 高度依赖(例如，许多其他函数使用的例程和库函数)。函数的依赖或使用越多，对系统的影响就越大。
- Dynamic analysis: Can you check which subroutines are more commonly called, or even called at all? (maybe by examining patterns in log files or code coverage tool) Testing these will have a higher impact- 决策:开发并保持最新的分析，其中基于：对区域进行排序
- 对业务最重要的模块/功能
- 每个模块中的缺陷率/ksloc(每千行源代码)(关键、专业、未成年人等的不同值)
- 每个文件中的设计/代码质量问题/ksloc
- 每个模块/函数的依赖项数
单元测试与自动GUI/CUI测试
有时，特别是在没有为测试编写的代码基础上，没有主要的重构，编写单元测试几乎是不可能的--模块对其他模块有如此多的依赖，并且都依赖于4GL运行时内的运行。
当单元测试的重构所涉及的成本(和风险)太高时，您可能希望自动化前端测试，而不是构建单元测试。虽然您将无法获得单元测试的代码洞察力，也无法获得非常高频率的测试修复周期，但是您将得到与最终用户体验直接相关的测试(从而获得管理上的快乐)。
自动化GUI/CUI测试开发通常也由不同的开发人员进行，而不是核心软件工程师，因此实际上可以在不影响核心工程团队的情况下取得进展。
Stack Exchange QA用户
发布于 2011-05-04 15:35:19
我们从哪里开始？
如果您有一个bug跟踪系统，得到一些过去几年的bug报告，按模块分类(如果可能的话)。然后制作一个直方图/帕雷托图表，以查看哪些是最错误的区域(每个bug都算作+1，每个重新打开的bug都算作+1，每个“没有修复您的开发人员”的bug都算作+3)。在这些方面，您应该把最大的精力放在添加测试上。“7年未动”的文件不会出现在这样的报告中。
快速检查web显示，OEUnit是OpenEdge的单元测试框架。这是一个很好的开始，因为它表明你不必发明这样的野兽。
第一次没有修复的Bugs可能意味着代码草率、规格差或问题比最初看上去复杂得多；这就是为什么在尝试对哪些领域进行分类时，它们应该计算得更高一些。
Stack Exchange QA用户
发布于 2011-05-04 16:58:34
我似乎还记得，有一本书专门论述了这一具体情况。等一下我搜索亚马逊..。
...here我们走：有效地使用遗产代码
我承认我自己还没读过这篇文章，但是我听说过很多关于它的东西，而且它有4.5颗星。
https://sqa.stackexchange.com/questions/149
复制相似问题
腾讯云开发者
