在编写代码前编写单元测试。 少做编写和更改，多做测试。 自动执行测试和生成报告：红绿灯式的方法。 下面对行程中的各站作一解释： 调用 utPLSQL 测试过程执行测试程序包。utPLSQL 按照动态 PL/SQL 和命名规范来运行任何设置代码，定位并执行单元测试程序，并进行必要的清除（“拆卸”步骤）。
单元测试过程调用“判断 API”，它将测试结果与“控制”条件进行比较。 判断程序将结果（通过或失败）写到下面的结果表中。 tPLSQL 测试读出结果表中的内容，确定该测试的状态。 utPLSQL 根据结果作出报告，或者通过 DBMS_OUTPUT 送到屏幕，或者通过 UTL_FILE 送到一个文件。
让我们来看一个很简单的示例，从而大致了解单元测试程序包的内容。假设我已经创建了一个关于 SUBSTR 的封装，允许在开始和结束点之间请求一个子串（一个简单的函数）。 即使是简单的或看似不重要的程序（如 betwnStr）也需要测试 — 而实际上我必须考虑大量的测试方案（包括 NULL 开始值、NULL 结束值以及开始大于结束等）。
那些在测试领域工作的人都知道，测试一个应用程序所需要编写的代码数量常常比应用程序本身更多。对于这个特定的程序包和测试代码的 utPLSQL 风格，您在某些情况下会生成全部的测试代码。实际上，ut_betwnstr 程序包通过对 utGen。
testpkg_from_string 过程的调用而生成。 即使您不生成测试程序包，也经常可以找到其他方法，利用最少的代码运行许多基于 utPLSQL 的测试 — 这正是我用 Codecheck 所做的工作。 将 utPLSQL 应用于 Codecheck 要利用 utPLSQL，我需要构建一个单元测试程序包并调用 utAssert 程序，以确定我的代码是否通过其测试。
但是，在进行这些操作之前，我需要精心制作我的测试方案。请记住：测试方案第一，其次才是代码。 现在应该寻找灵感，暂停前进，考虑一下我所提供的实用工具。我希望它能够验证什么？那些能编译但包含歧义超载的程序包的特例是什么？我能检测到什么情况？有效超载的示例是什么？毕竟我需要测试正面和负面的因素。
经过一段时间以后，我给出以下的内容：。
答：特别是先写测试（testfirst），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合详情>>
答：没关系，你可以关机重启看看详情>>
答：一般过程1）信息收集在网络巾不同关键点，根据系统和网络日志文件、和文件中的不期望的改变、程序执行中的不期望行为、物理形式的入侵信息这四个方面，收集系统、网络、数...详情>>
