我可以继续讨论该系统的不良做法。底线是多年，开发人员别无选择。那是“吉米吉米吉米”，与许多承包商进出一起。现在，他们想清理自己的行为。
我建议的第一件事就是测试。他们说，基本上，“我们一直想进行测试多年，但是我们真的不知道从哪里开始。”业务逻辑和数据库访问被烘焙到UI中。 （我会说GUI，但它不是图形的，而是在大型机上的。甚至连输入订单的人也可以远程登录。）数百万行代码。整个系统的年销售额超过10亿美元，因此它不需要重写（显然“按原样工作”。）无面向对象。没有正式或自动测试。我们的测试人员也是编写规范的人（这使他们倾向于“推动项目通过”。）
我快要死了。我什至愿意在业余时间编写我们需要的任何测试框架（开放源框架中的Openedge并不需要太多）。我相信它将很快收回成本。我们从哪里开始？这里有没有人遇到过类似的项目（即使规模较小），如果是，您如何应对和克服这个问题？
更新：我已经和经理聊天了，我已获批准草拟规范/时间表以创建测试工具。一开始，我听到这样的声音：“我们真正需要做的就是编写一些测试。”我对此回应说：“如果我们没有办法运行测试，那么测试将不会真正帮助我们。我一直在研究ProUnit（OEUnit的旧名称），认为它对我们有用。” “我们应该使用它编写一些测试。”他花了大约10分钟的重复时间才意识到，这并不像下载库然后“使用它”那么简单。但是，批准编写规范以创建测试工具才是开始！谢谢大家的投入！
#1 楼
您将踏上无止境的旅程，因此重要的是手段而不是终点。第一：正如Laura所说，请确保您的工作直接改善了对业务至关重要的领域。指标：在开始之前和进行过程中获取良好的指标至关重要。保持度量标准为最新状态，最好是通过自动化，因为这将是您不断的指导和辩护。
如Tangurena所说，找到缺陷率更高的区域。这是一种很好的代码味道
静态分析：您可以运行任何工具，例如sloccount，lint或计算复杂度的工具（例如McCabe），依赖图吗？如果有Findbugs或等效的代码，甚至更好:)这样做可能会突出显示以下方面：特定问题密度
高于平均复杂度
高依赖性（例如，使用例程和库函数）通过许多其他功能）。函数的依赖关系或用法越多，对系统的影响就越大。动态分析：您可以检查哪个子例程被更普遍地调用，甚至根本不被调用？ （也许通过检查日志文件或代码覆盖率工具中的模式）进行测试将产生更大的影响。 >
业务最重要的模块/功能
每个模块中的缺陷率/ ksloc（每千行代码行）（对于关键，专业，次要等具有不同的值）
每个文件中的设计/代码质量问题/ ksloc
每个模块/功能的依赖性数量
单元测试与自动GUI / CUI测试
有时，尤其是在未编写用于测试的代码库的情况下，如果不进行重大重构，几乎不可能编写单元测试-模块对其他模块有如此多的依赖关系，并且都依赖于在4GL运行时中运行。
当重构单元测试涉及的成本（和风险）过高时，您可能希望自动化前端测试，而不是构建单元测试。虽然您将无法获得单元测试的代码洞察力，也无法获得非常高频率的测试修复周期，但您将获得与最终用户体验（以及管理满意度）直接相关的测试。
自动化的GUI / CUI测试开发通常也由不同的开发人员团队而不是核心软件工程师来进行，因此实际上可以进行开发而不会影响核心工程团队。
评论
虽然我碰巧不再在这家公司工作了，但是这是我需要在系统上进行测试的任何时候都会回来的事情。我也喜欢这不仅适用于OE环境，而且对将来的读者更有用，它几乎适用于任何环境。我非常喜欢我将其更改为我接受的答案（而不是轻微的Tangurena！）。
–corsiKa♦
2012年5月3日17:10
#2 楼
我们从哪里开始？
如果您有错误跟踪系统，则可以获取过去几年的错误报告，并按模块细分（如果可能）。然后制作一个直方图/ pareto图表，以查看哪些区域是Buggiest最多的区域（每个Bug计数为+1，每个重新打开的Bug计数为+1，每个“未解决您的开发人员问题”的计数为+3）。这些领域是您应尽最大努力添加测试的地方。 “未修改7年”的文件不会出现在此类报告中。
对Web的快速检查表明OEUnit是OpenEdge的单元测试框架。这是一个好的开始，因为它表明您不必发明这种野兽。
初次未解决的错误可能意味着草率的编码器，较差的规范或比首次出现的问题更复杂的问题；这就是为什么在尝试分类开始关注的区域时，他们应该计数更高的原因。
评论
+1，确定哪些区域是最大的痛点是一个很好的起点。但是，对于刚接触代码库的人来说，从“简单”区域开始，在该区域中代码不太复杂，业务规则尽可能简单，这是获得应用程序“感觉”，如何编写以及如何使用的好方法。整个代码中都存在“未编写的约定”。
–抢夺
2011年5月4日15:48
@Rob我已经使用它大约8个月了。可以这么说，我已经积累了很多“部落知识”。也就是说，此应用程序没有“简单”区域。老实说
–corsiKa♦
2011年5月4日19:54
我要接受这个；我没有考虑过直方图方法，但是我认为这是个好主意，它与我们目前的一些政策保持一致。另外，我的队友还告诉我OEUnit不足以完成我们的任务。我跟踪了您的链接，并独自阅读了该链接，并认为该链接对我来说效果很好，因此感谢您的提醒。我也喜欢最后的见解。我确实对所有答复者表示了支持，因为我认为他们都充满了良好的信息。劳拉的清单和布鲁斯的书推荐都在我的待办事项清单上。 :)
–corsiKa♦
2011年5月6日18:39
#3 楼
我似乎还记得有一本书专门针对这种确切的情况。我搜索亚马逊仅几秒钟。听说过它的好处，它有4.5颗星。评论
我已经阅读了这本书，绝对会推荐它
– Phil Kirkham
2011年5月7日，0：20
这绝对值得阅读和应用。
–马修·罗达图斯（Matthew Rodatus）
11年5月12日在11:43
我注意到这本书在同事的架子上（在另一个团队中）。我认为这本书不仅涉及测试，还涉及更多内容？
–corsiKa♦
2011年6月23日17:10
这是一本很棒的书，但是更多的是关于重构没有测试的代码以及将接缝放置在适当的位置以便您可以添加测试。尽管该书提出了所有代码都应具有自动化测试的观念，但我认为这不是解决该特定问题的好地方。这将帮助开发人员重构紧密耦合的代码，但不会指导您从哪里开始测试。
–埃里克·赫克斯特（Eric Hexter）
2014年6月26日15:27
#4 楼
是!我也是！你说的是非结构化的？你有我最深的同情。即便如此，听起来您比我小的但充满激情的团队中的执行力和合规性要强得多。广义上讲，这就是我所做的：仍然接受我
管理的文档（开始时有零个
测试用例，所以任何事情
总比没有好）
开始我自己的个人错误列表来跟踪和监视自己，我的错误和
客户的错误（有/没有专业的缺陷跟踪系统
，我只能在这里工作；只有准系统
自产的，不会产生缺陷
报告=>因此，没有像样的缺陷
跟踪系统=没有人遇到错误
....也就是说，直到我创建了一个供自己在Excel中使用的错误
/>使用清晰性和尽可能少的步骤来记录我自己的错误，并尽可能减少屏幕快照，因为该团队不习惯记录
记录客户的错误修复并通过支持人员澄清差异
人员当他们创建的错误远不易理解时
文档功能/增强功能如上所述的水泥
与他人分享知识，以便他们可以受益（因为他们可以应付……并不是每个人都想要
受教育）
无法承受足够的压力：无论您想多么糟糕，去管理并获得明确的指示，以明确应该集中精力/花费时间的方向，并且不要偏离此方向。在这种环境下开拓创新之前，您必须赢得他们的尊重。
#5 楼
我的第一个想法可能是将系统分解为较小的组件（而不仅仅是从规划的角度来看）。在这里，您可以根据哪个更重要来对它们进行优先级排序，并首先处理那些更重要的部分。在如此庞大的项目中，这种模块化方法将有助于防止您的团队无所事事，并可能使人们保持积极性。确保系统中更关键的组件已通过测试的组件。评论
规格？是的，我记得那些。我们在这里不使用规格。我希望原始海报确实有规格。如果没有，请记录所有内容。文档是关键（在这种情况下，要保持专业精神和保持理智）。
–劳拉·亨斯利（Laura Hensley）
2011年5月4日15:21
我也没有规格的奢侈。目前，我正在尝试自己编写一套并将其传递给客户，以确保我们在做正确的事情……似乎有些倒退不是吗。
–克雷格·朝圣者
2011年5月4日15:52
我们有所谓的规格，但它们都是不符合规格的（通常彼此矛盾）。我曾经有一个规格，估计是在24小时内使用一行“规格”。它的测试计划是“设置数据，运行功能并比较结果”。公平地说，至少测试计划与规范相提并论！
–corsiKa♦
2011年5月6日18:40
#6 楼
我首先想到的是，阅读您的描述是为了追踪整个系统中最大的销售渠道。保持80％的美元正确流动比可能占其中3％的工作流更为重要。由于您说的是测试人员还写了规范，我假设他们很清楚什么业务流程/事务代表了这些，所以从这里开始。
安全性也浮现在脑海。既然您说“销售”，我想也许正在处理信用卡或银行信息？如果是这样，那么确保安全是另一个要开始的地方。
我也喜欢Tangurena的回答。如果您有历史记录或未解决的错误，请查看是否可以找到一个似乎有更多问题的区域并首先关注该区域。分配给您的时间集中在您可以获得最佳投资回报的领域。
#7 楼
步骤0，当他们签入源代码控制系统时，使构建自动化。 TeamCity pro可以签出并运行命令-它是免费的，并且易于设置。步骤1，编写一个测试。不要对单元和集成感到迷惑-只需进行一次测试即可。
步骤2，将其视为一种机会：
尝试使用适合您的域的理想测试语言编写一些测试。 （有关想法，请参见rspec / specflow）。
我感到您很痛苦，我刚刚继承了750k未经测试的代码。这全都与改变心态有关，有时只是看到人们的下巴和一分钱下降时的第一次测试，因为他们意识到这将节省多少时间。
评论
我现在正在执行步骤1。不幸的是，没有太多的系统可用于测试：数据库直接与UI紧密相关。另外，我正在尝试为此设置OEUnit，但是当然要花一两天的时间，他们说他们愿意这样做，但我仍在等待实现这一意愿。我真的很喜欢您的第2步（仅此一项就是+1）-我正努力保持这种状况：-)
–corsiKa♦
2011年7月7日在22:45
我们已经使用SQLite对测试数据库产生了很大的影响。另一个选择是说服您的应用程序不做太多工作-如果设置inTest标志可以大大加快数据库访问的速度，是否可以在SQL中附加“ TOP 1”。
–松鼠
2011年7月8日，下午5:57
也许可以，但是我们使用的是OpenEdge ABL-这是一种用于紧密数据库集成的DSL，并且很快就不会出现。 ：-{
–corsiKa♦
2011年7月8日在15:58
#8 楼
因为我认为这是所有好的建议，所以不要否定别人的说法，但是我要采取的第一步是运行一个非常基本的测试。这使您从拥有零测试的系统变为拥有可以改进的不完整测试集的系统。我的经验是，完成已经在进行中的工作比尝试找出从哪里开始要容易得多。评论
进一步回答您的问题-在其他答案中提到“模块”，我将首先写下一个模块列表以及它们之间的可能关系，然后为每个模块运行一个简单的测试，甚至最好是一个功能测试，一个简单的压力测试，否定测试和一项性能测试。
–Rsf
2011年5月8日13:03
#9 楼
除了询问您的错误案例外，还可能需要与业务部门讨论哪些功能为其提供了最大的价值/金钱。#10 楼
除了Tangurena方法外，我建议尽可能多地编写一些测试。本质上，这将是对您的软件是否按预期工作的测试。如果测试涉及大多数子系统，则任何系统中的任何错误都将表明该测试存在故障。它不会指出您的问题，但会显示是否某些重构引入了一些错误。一些用户/报告对用户/报告进行一些操作
保存结果
检查结果
使其定期在服务器上运行，因为可能对于单元测试来说太长了。
也要删除所有不推荐使用的文件。如果需要它们，只需从版本控件中查找它们。这些文件增加了开发难度，并使得查看实际执行的代码变得更加困难。
#11 楼
最好从需求文档开始，这将首先帮助完成手动测试，然后帮助其他类型的回归，负载和其他类型这将专门致力于提高产品质量
评论
您的答案虽然准确无误，但实际上并没有增加任何答案。其他答案提到了需求文档，手动测试以及针对此问题的潜在策略。通常，对旧问题的新答案应该是在已经存在的答案中添加一些内容，尤其是在存在可接受的答案的情况下
–凯特·保罗（Kate Paulk）
2014年10月31日14:19
#12 楼
添加到craig-pilgrim的答案中：如果无法将整体分解为较小的功能或微服务，请考虑将每个新功能添加为新功能或微服务的选项。显然，每个新功能都将在最终使用的任何测试框架中进行全面测试。经过几个月的新范例，您可以重新评估拆分整体的可能性。
这不是一个快速的解决方案，但最终会带您进入更可测试的设置。
#13 楼
明确说明：单元测试不再是可选任务。期间
所有代码更改现在都可以进行测试，可以根据需要进行新的或更新的测试。前几项真的很难，因为一开始的障碍太多，学习曲线陡峭。因此，也许要花一六个月的时间，通过培训和演示以及辅导和辅导让每个人都做好准备。
要变得如此严格（所有代码现在都需要测试），您首先必须处理多个级别和部分内容组织来使人们做好准备并接受他们进行如此大的变革所需的资源和知识的培训。
这种变革很容易花上几个月的时间，而花一到三年的时间才能掌握，因此管理层需要长期参与其中并设定他们的期望。结果是一家现代公司，竞争激烈并赢得了胜利。另一种方法是倒闭。
第1阶段-开始引入测试
第1步）编写
true is true测试。第2步）编写“在应用代码中调用简单方法调用'test
步骤3）为一个简单的方法编写单元测试，该方法可模拟并存根任何依赖项
阶段2-将测试应用于实际开发中
对于以后的所有代码更改： >步骤1）编写使用代码提交的测试
步骤2）在编写应用程序代码之前编写失败的测试
步骤3）编写缺少测试积压的测试
痛苦显而易见，还有好处。使用CI服务器运行分支并在其中进行测试。例如，例如circleCI。公开暴露内脏，以改善它们。测试对于开发人员而言确实是一件很棒的事！
另外，说实话，开发人员必须以某种方式运行其代码，以确保幸福的道路在实际运行中没有语法错误。我见过的人都没有写“盲”代码。测试已经进行，只是尚未正式化并转变为自动化，但很可能是这种情况。
我自己过去常常在没有自动化测试的情况下编写代码（您最好还是花点时间测试一下），数百万行。改变它是可怕的！测试是开发人员最好的朋友。我的意思是说真的，如果您没有测试来保护自己，那么您如何自信地重构代码-质量的秘诀？改善某事的动力，但是冒险打破别的东西，这意味着我经验中到处都是垃圾。一旦一扇窗户被打破，房子就会很快被砸碎（窗户理论被打破）。
通过说服人们来改变人们的思想常常会失败，因此树立正确的榜样并获得支持者的帮助是关键。
评论
听起来像Walldorf的一家公司@xster老实说，这是一个非常普遍的问题。与我交谈过的大多数人至少在他们工作过的地方分享过类似的经历。
让读者想知道为什么有人会使用这种糟糕的语言：早在90年代，4GL是客户端-服务器编程效率最高的环境，受到开发人员的喜爱（每年均获得生产力奖）。
对象编程风靡一时。 4GL具有以语言集成的（非SQL）数据库访问权限，无需将SQL语句拼凑在一起，执行它们并撬出数据。在对象关系映射器之前。应用程序语言能够区分屏幕上的（更改的）值，缓冲区中的值以及存储在磁盘上的值。集成了语言的交易处理。诸如ON ERROR UNDO，RETRY批处理之类的东西。非常好。温暖的感觉。
我环顾四周，发现可以在Python中测试Telnet GUI的以下项目：sourceforge.net/projects/three-t-py。虽然，我倾向于避免GUI测试，而倾向于单元测试。