PLSQL构建代码分析工具之从测试开始.pdf

PL/SQL构建代码分析工具之从测试开始 Feuerstein 的“构建代码分析工具”系列的第 2 部分 在本系列的 第一篇文章中，我决定构建一个可以对代码进行质量检查的实用工具：特 别是识别 PL/SQL 程序包中具有歧义或者潜在歧义的超载问题。 此外，我还识别数据源（ALL_ARGUMENTS 数据字典视图）和代码（DBMS_DESCRIBE 程序 包），以帮助构建实用工具。下一步要做什么呢？ 坦率地说，我自然倾向于打开我所喜爱的集成开发环境 （IDE） 并开始动指如飞地编 写代码，投入激动人心的创作之中。我希望在工作时思考并得出结论，不断地应对挑战，使 工作成果运行起来，然后对其进行微调。 这种方法有积极的方面（您当然不会有过度设计的风险），但也有很多缺点。首先，如 果我所使用的构建方法是直通式构造非线性系统 — 常被亲切地称为 HRCLS 或 Hercules （一种非常轻型的方法论），我最终不会仅是微调代码。绝对不会，在我将范围缩小到最终 目的、目标和实质内容时，我最终将会以重写整个程序 — 一次、两次或三次。但是，尽管 可以激动地看到，经过自己的努力，实用工具成形、进步并改观，但这会浪费很多的时间。 对于 Codecheck，我会忍住最初的诱惑。我不会在项目开始的头 60 秒内就编写代码， 而是做一个简单的声明：我保证使我编写的代码适用于一个全面的测试计划。 这与避免 Hercules 综合症有什么必然的关系呢？让我们来考虑这种保证的含义： 我将制订一个测试计划，它非常全面，精心策划了数十个（甚至可能有 100 个之多） 测试方案，包括参数的数量、各种数据类型的结合以及缺省值的有无。 我要设计、构建和运行测试，这些测试可确定我的代码是否满足测试计划的要求：换言 之，设计、构建和运行涵盖我的全部测试方案的测试。 天哪，这听起来确实很有道理，不是吗？我的意思是，谁会一直做所有的这些事情？况 且，我们都知道这样的事实：我们之中很少有人实际上会花时间，或在手边有必备的工具去 做全面的测试。实际上我认为，世界上至少百分之九十的软件开发人员和开发团队（包括我 自己）远远不会完全按上述保证去做。 对我来说，在开发初始时我表明要执着地进行测试，我发现这一点促使我实现了 Codecheck. 定义范围，做出假设 在开发一项测试策略并构造测试之前，我需要确定项目的使用范围。用户群通常确定（并 经常更改）项目的使用范围。对于 Codecheck 以及我制作的很多其他实用工具，您，开发 人员，是我的用户，但我仍然需要确定使用范围，把您的需求作为我的指导。我的目标是产 生一个代码体，能立即帮助开发人员提高代码质量，但也可以作为一项稳定而且可扩展的功 能，开发人员可以将其加入代码中满足自己的需要。它必须能够处理现实世界中足够的复杂 性，这样才有用处，但又不可太复杂，以至于将 Codecheck 开发变成一种全职工作。 当我深入查看 ALL_ARGUMENTS 的内容时，我吃惊地发现那些参数列表会变得非常复杂。 例如，在 Oracle9i 的环境中，一个参数可以将记录的结合数组（以前称为表的索引）作为 其类型，其中记录的一个字段是另一个结合数组，以此类推。非常坦率地说，我实际上不希 望必须编写代码来处理这些参数全部的可能情况。 与此相反，Codecheck 将只基于“0级”参数来检查和进行分析：这是指在 ALL_ARGUMENTS 视图中的那些项目，当其出现在程序头时，它们对应于参数列表。实际上， 这可能是您为分析超载而所需的全部要素，但是全部的详细资料可能在进行某种其他的代码 检查时派上用场。（在撰写此文章时，我已确定了一种需要更多信息的情况：如果您将一个 参数定义为表单 %ROWTYPE 的记录，则 ALL_ARGUMENTS 和 DBMS_DESCRIBE 都不会提供其类 型的信息。您可能必须比较那些行类型（1 级或更多级）的各个字段的数据类型以识别岐义。 天哪。 定义测试策略 开发 Codecheck 的下一步是探究和定义测试策略。我曾提到过，我承诺编写能够满足 测试计划的代码，这种承诺影响着开发过程。例如，我在编写如 Codecheck 等实用工具时 的第一个冲动是，制作一个程序，接受一个程序包的名称并在屏幕上显示代码检查的结果。 为了确定实用工具是否正确工作，我需要查看屏幕上的检查结果并对其进行分析。这听起来 如何？熟悉吗？可伸缩吗？通常这种方法甚至对非常简单的程序都无效。 Codeche