以下是网上找到的一些常规的估算测试工作量的方法：

    1. Ad-hoc方法

    这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。

　　这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

　　2.开发时间的百分比法Percentage of development time。

    这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。　　这种方法变化比较大而且通常基于以前的经验。

　　通常预留项目的总花费时间的35%给测试。? 5-7%给组件和集成测试? 18-20%给系统测试? 10%给接收测试(或回归测试等)

　　3.类比法(经验值法或历史数据法)

　　根据以前或相似项目(主要在项目性质，领域，规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确 度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要 收集以下相关的历史数据：? 在设计和实现阶段花费的时间? 测试工作的规模，例如用户需求的数量，页面数，功能点? 数据样式，例如实体，字段的数量? 屏幕或字段数量? 测试对象的规模，例如KLOC

    4.WBS(work breakdown structure)估算法

    将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

　　5.Delphi 法

    Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方……

　　Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭 代表格;4、协调人整理出一个估计总结，以迭代表的形式返回专家;5、协调人召集小组会，讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一 个匿名估计;7、重复4-6， 直到达到一个最低和最高估计的一致。

　　6.PERT估计法

    PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E， 和标准偏差SD.

   WebSphere Application Server 是一个基于 Java 的 Web 应用程序服务器，它构建在开放标准的基础之上，能帮助您部署与管理从简单的 Web 站点到强大的电子商务解决方案的诸多应用程序。它遵循 J2EE 并为 Java 组件、XML 和 Web 服务提供了一个可移植的 Web 部署平台，这个平台能够与数据库交互并提供动态 Web 内容。

   随着WebSphere Application Server产品在中间市场的份额不断增加，使用WebSphere Application Server作为IT基础产品的企业越来越多，作为我们企业的IT部门，很重要的一部分工作就是管理WebSphere Application Server。由于业务系统的复杂性，以及IT系统的庞大等多种原因，我们的系统不可避免的会出现这样那样的问题，要定定位和解决这些问题，WebSphere Application Server的日志将起了很关键作用。怎么管理以及查看这些日志呢？

    本文作者所一直从事WebSphere Application Server的相关服务工作，积累了许多WebSphere Application Server的管理经验。我们希望能够通过一系列的文章与读者分享这些经验想，帮助您更好管理好你的WebSphere Application Server。

    本文将从问题诊断入手，在解决一系列具体问题的过程中，介绍配置日志的策略以及具体参数的用法，为您提供诊断问题的途经以及指定日志策略的方式和方法。

问题诊断的方法

   在我们基于J2EE的应用程序中，问题的出现可能在各个相关的环节出现。所以首先要明确问题是发生在哪个组建上的，我们可以通过测试单个组件，检查他们成功或者失败来把问题进行一个隔离。从而分析相关日志来定位问题。下图是一些常用的测试方法以及相关日志的位置。

当我们的系统出现不能访问现象时，我们一般按照一下步骤进行分析：

1．使用浏览器通过80端口访问应用（例如：http://localhost/myWeb/）

2．使用浏览器通过9080(根据实际端口而定)端口访问应用（例如：http://localhost:9080/myWeb）如果访问正常，说明HTTP server的请求没有正常转发，这时候通过http://localhost来验证HTTP 服务器是否正常启动，如果正常说明HTTP server 运行正常，此时请检查http_plugin.log查看插件日志，并且查看HTTP server 的配置文件httpd.conf，查找WebSpherePluginConfig 所加载的plugin-cfg.xml文件是否正确。

3．如果通过9080(根据实际端口而定)端口不能访问应用程序，可以通过http://localhost:9080/snoop 验证应用服务器是否存活。如存活则如图：

一般说明应用程序存在问题，查看分析相关日志：System.Out.log 、SystemErr.log、activity.log定位应用程序引起的问题。

日志介绍

System.Out.log 、SystemErr.log 属于JVM 日志，。WebSphere Application Server 写格式化的消息到 System.out日志。另外，应用程序和其他代码可以写入这些日志，通过print() 和 println() 方法实现。有些开发工具箱（Developer Kit）内置如 Throwable 类的 printStackTrace() 方法也可以写入这些日志。通常，System.out 日志用于监控应用程序服务器的运行是否正常。System.out 日志可用于问题确定，但建议改为使用 IBM 服务日志和日志分析器的高级能力。System.err 日志包含异常堆栈跟踪信息，这在执行问题分析时很有用。

因为每个应用程序服务器都代表 JVM，所以每个应用程序服务器和它的所有应用程序都有一组 JVM 日志，缺省情况下该日志位于 installation_root/profiles/profile_name/logs/server_name 目录。在 WebSphere Application Server Network Deployment 配置的情况下，也为 Deployment Manager 和每个节点管理器创建 JVM 日志，因为它们也代表 JVM。

activity.log为IBM 日志，应用程序服务器从各种 WebSphere Application Server 组件的活动创建服务或活动日志文件。服务或活动日志文件（activity.log）是二进制文件，它位于 install_root 的 logs 目录中，我们可以使用日志分析器用于查看服务或活动日志文件。

查看 JVM 日志

JVM 日志是作为纯文本文件写的。因此，查看这些日志没有特殊的要求。它们位于 installation_directory/profiles/profile_name/logs/server_name 目录中，并在缺省情况下命名为 SystemOut.log 和 SystemErr.log。

有两种技术可用于查看应用程序服务器的 JVM 日志。

l         使用管理控制台。它支持从远程机器查看 JVM 日志。

l         使用存储日志的机器上的文本编辑器。

此任务的步骤

1．从管理控制台查看 JVM 日志。

启动管理控制台。

在控制台导航树中单击故障诊断 > 日志和跟踪。要查看特定服务器的日志，单击服务器名以选择它，然后单击 JVM 日志。

选择运行时选项卡。

单击与您要查看的日志相应的查看。

2．在服务器硬盘查看JVM 日志。

转至存储日志的机器。

在文本编辑器中打开文件或将文件拖放到编辑和查看程序中。

日志格式：

根据 JVM 日志配置的不同，格式化的消息可以用基本或高级格式写入 JVM 日志。

消息格式 格式化的消息可以使用这两种格式中的一种写入 JVM 日志：

基本格式 这是 WebSphere Application Server 的较早版本中使用的格式。

高级格式 如果可能，则通过添加有关事件的信息来扩展基本格式。

下面是一些日志常用格式，可以帮助我们更好的查看日志，可能找到的采用这些格式的各种字段如下：

TimeStamp

时间戳记是使用其被格式化所处于的进程语言环境格式化的。它包含标准日期（例如，YYMMDD），以毫秒为精度的 24 小时时间和时区。

ThreadId

从发出消息的线程的散列代码生成的 8 个字符的十六进制值。

ThreadName

发出消息或跟踪事件的 Java 线程名。

ShortName

发出消息或跟踪事件的记录组件的缩写名称。这通常是 WebSphere Application Server 内部组件的类名，但也可以是一些用户应用程序的其他标识。

LongName

发出消息或跟踪事件的记录组件的全名。这通常是 WebSphere Application Server 内部组件的标准类名，但也可以是一些用户应用程序的其他标识。

EventType

表明消息或跟踪事件类型的一个字符字段。消息类型是大写的。可能值包括：

F

致命消息。

E

错误消息。

W

警告消息。

A

审计消息。

I

参考消息。

C

配置消息。

D

详细信息消息。

O

通过用户应用程序或内部组件直接写入 System.out 的消息。

R

通过用户应用程序或内部组件直接写入 System.err 的消息。

Z

表明不可识别的类型的占位符。

类名

发出消息或跟踪事件的类。

方法名称

发出消息或跟踪事件的方法。

组织

拥有发出消息或跟踪事件的应用程序的组织。

产品

发出消息或跟踪事件的产品。

组件

发出消息或跟踪事件的产品内的组件。

基本格式

以基本格式显示的消息事件使用下列格式。符号 <name> 表明将总是在基本格式消息中出现的必需字段。符号 [name] 表明将被包括的可选的或有条件的字段，如果可以确定它们的话。

<timestamp><threadId><shortName><eventType>[className][methodName]<message>

高级格式

以高级格式显示的消息事件使用下列格式。表示法 <name> 用于表明将总是以消息条目的高级格式出现的必需字段。表示法 [name] 用于表明将被包括的可选的或有条件的字段（如果可以确定它们的话）。

<timestamp><threadId><eventType><UOW><source=longName>[className][methodName]<Organization><Product><Component>[thread=threadName]

<message>

配置 JVM 日志

使用管理控制台配置应用程序服务器的 JVM 日志。直到下一次重新启动应用程序服务器，才应用为了运行应用程序服务器而对 JVM 日志进行的配置更改。

此任务的步骤

启动管理控制台

单击故障诊断 > 记录和跟踪，然后单击服务器 > JVM 日志。

选择“配置”选项卡。

滚动通过面板以显示要配置的日志的属性。

更改相应的配置属性并单击应用。

保存您的配置更改。

Java 虚拟机（JVM）日志设置

使用此页面查看和修改 Java 虚拟机（JVM）System.out 和 System.err 日志的设置。

要查看此管理控制台页面，单击故障诊断 > 日志和跟踪 > server name > JVM 日志。

查看和修改此受管进程的 Java 虚拟机（JVM）System.out 和 System.err 日志的设置。通过将 JVM 的 System.out 和 System.err 流重定向到独立日志文件来创建 JVM 日志。System.out 日志用于监控运行应用程序服务器的运行状况。System.err 日志包含执行问题分析时有用的异常堆栈跟踪信息。每个应用程序服务器及其所有应用程序有一组 JVM 日志。还为 Deployment Manager 和每个节点管理器创建 JVM 日志。“配置”面板上的更改将在重新启动服务器时应用。“运行时”面板上的更改将立即应用。

“配置”选项卡

文件名

指定此页面中描述的某个日志文件的名称。

第一个文件名字段指定 System.out 日志的名称。第二个文件名字段指定 System.err 文件的名称。

按下“运行时”选项卡上的查看按钮查看所选日志文件的内容。

为 System.out 日志或 System.err 日志指定的文件名必须具有以下某个值：

文件名

文件系统中的文件的名称。建议您使用标准文件名。如果该文件名不是标准文件名，则认为它相对于服务器的当前工作目录。每个日志必须配置一个专用文件。例如，我们无法将 System.out 和 System.err 重定向到同一物理文件。

如果包含文件的目录已经存在，则正在运行的服务器所使用的用户标识需要该目录的读／写访问权限。如果该目录不存在，将会用适当的许可权创建它。正在运行的服务器所使用的用户标识必须有创建该目录的权限。

控制台

这是用于将流重定向到关联进程流的特殊文件名。如果为 System.out 指定了此值，则文件重定向到 stdout。如果为 System.err 指定了此值，则文件重定向到 stderr。

无

废弃写入流的所有数据。指定无等于将流重定向到 UNIX 系统上的 dev/null。

filename 的缺省路径是变量 SERVER_LOG_ROOT 的值。要查看 SERVER_LOG_ROOT 变量的值：

1．在管理控制台上，选择环境 > WebSphere 变量

2．单击服务器单选按钮，然后单击应用。在显示的列表中出现 SERVER_LOG_ROOT 变量的值。

要更改 SERVER_LOG_ROOT 的值：

1．选择 SERVER_LOG_ROOT

2．在值字段中输入新的路径

3．单击“应用”

4．保存此配置。您必须重新启动服务器以使更改生效。

当然我们还可以以将 ${SERVER_LOG_ROOT}/和 ${SERVER_LOG_ROOT}/SystemErr.log 文件的位置和名称更改为任何其他绝对路径和文件名（例如，/tmp/myLogfile.log）。

文件格式

指定用于保存 System.out 文件的格式。

日志文件滚动（保留旧的日志文件生成新的日志文件）

应用服务器有日志自管理功能，通过使用这一组配置属性将 System.out 或 System.err 日志文件配置为自我管理。

自我管理日志文件将消息写入文件，直到达到时间或大小条件。当达到指定时间或文件达到指定大小时，日志文件将滚动（包括关闭文件并重命名保存的文件），同时记录将临时挂起。新保存的文件名是原始文件名加上表明文件重命名时间的时间戳记限定符。一旦完成重命名，则重新打开具有原始名称的新的空日志文件，并恢复记录。虽然日志文件滚动后一条消息可能会分割在保存的文件和当前文件中，但全部消息都将保留。

如果关联流重定向到文件，则仅可以将一个日志配置为自我管理。

文件大小

单击日志文件的此属性以让它根据其文件大小管理它自己。当文件达到最大大小字段中指定的大小时，发生自动滚动。

最大大小

指定文件的最大大小（以兆字节为单位）。当文件达到此大小时，它就滚动。

此属性仅当您单击“文件大小”后才有效。

时间

单击日志文件的此属性以让它根据一天中的时间管理它自己。文件在启动时间字段中指定的时间滚动。

启动时间

指定应用程序服务器重新启动后第一次启动周期滚动算法的时间，即，一天中的几点（从 1 到 24）。算法在应用程序服务器启动时装入。一旦滚动算法在启动时间字段指定的钟点启动后，它将每隔一定的时间（重复时间字段指定的小时数）滚动文件。此滚动模式将继续使用不作调整，直到应用程序服务器停止。

注：滚动总是在一天中指定钟点开始时发生。一天的第一个小一天的第一个小时（自 00:00:00（午夜）起）是 1 点，而一天的最后一个小时（自 23:00:00 起）是 24 点。因此，如果您希望日志文件在午夜滚动，则将启动时间设置为 1。

重复时间

指定隔多少小时（从 1 到 24）发生周期滚动。

重复时间

指定每隔多少小时日志文件滚动一次。有效值范围是从 1 到 24。

配置日志文件按时间、按大小或按时间和大小滚动。单击文件大小和时间以在首次匹配条件时滚动文件。例如，如果重复时间字段是 5 小时，而最大文件大小是 2 MB，则文件将每 5 小时滚动一次，除非时间间隔未到而文件大小已达 2 MB。按文件大小滚动后，文件将继续按时间间隔滚动。

历史日志文件的最大大小

指定要保存的历史（已滚动）文件数。流将写入当前文件，直到它滚动。滚动时，关闭当前文件，并以当前名称加上滚动时间戳记组成的新名称保存该文件。然后流将以原始名称重新打开一个新文件以继续写入。历史文件数从零增长到最大历史文件数字段的值。下一次滚动删除最旧的历史文件。

已安装应用程序的输出

指定是否记录和格式化应用程序代码发出的 System.out 或 System.err 打印语句。

显示应用程序打印语句

单击此字段以显示应用程序使用 print 和 println 流方法写入流的消息。总是出现 WebSphere Application Server 系统消息。

格式化打印语句

单击此字段以格式化应用程序打印语句（如 WebSphere Application Server 系统消息）。

“运行时”选项卡

文件名

指定此页面中描述的某个日志文件的名称。

第一个文件名字段指定 System.out 日志的名称。第二个文件名字段指定 System.err 文件的名称。

按下“运行时”选项卡上的查看按钮查看所选日志文件的内容。

为 System.out 日志或 System.err 日志指定的文件名必须具有以下某个值：

文件名

文件系统中的文件的名称。建议您使用标准文件名。如果该文件名不是标准文件名，则认为它相对于服务器的当前工作目录。每个流必须配置一个专用文件。例如，您无法将 System.out 和 System.err 重定向到同一物理文件。

如果包含文件的目录已经存在，则正在运行的服务器所使用的用户标识需要该目录的读／写访问权限。如果该目录不存在，将会用适当的许可权创建它。正在运行的服务器所使用的用户标识必须有创建该目录的权限。

控制台

这是用于将流重定向到关联进程流的特殊文件名。如果为 System.out 指定了此值，则文件重定向到 stdout。如果为 System.err 指定了此值，则文件重定向到 stderr。

无

废弃写入流的所有数据。指定无等于将流重定向到 UNIX 系统上的 dev/null。

filename 的缺省路径是变量 SERVER_LOG_ROOT 的值。要查看 SERVER_LOG_ROOT 变量的值：

1．在管理控制台上，选择环境 > WebSphere 变量

2．单击服务器单选按钮，然后单击应用。在显示的列表中出现 SERVER_LOG_ROOT 变量的值。

要更改 SERVER_LOG_ROOT 的值：

1．选择 SERVER_LOG_ROOT

2．在值字段中输入新的路径

3．单击“应用”

保存此配置。您必须重新启动服务器以使更改生效。当然我们还可以以将${SERVER_LOG_ROOT}/SystemOut.log 和 ${SERVER_LOG_ROOT}/SystemErr.log 文件的位置和名称更改为任何其他绝对路径和文件名（例如，/tmp/myLogfile.log）。

结束语

JVM 日志对我们对问题的的分析和跟踪是非常重要的。WebSphere Application Server 强大的日志自管理功能，使我们的日常工作更方便更简单，学习和掌握这些功能对我们管理人员来说受益非浅。

性能测试经验总结

第一步：计划测试

1、明确压力点，根据压力点设计多少种场景组合

2、把文档（包括多少种场景组合、场景与场景组合条件的对应表）写好

3、如果监测UNIX机器，在被监测的机器需要安装监测Unix的进程

4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据

5、让开发人员做一个恢复数据的脚本，以便于我们每次测试的时候都能够有一个相同的环境

6、针对每一个模块包括四个子文件夹：如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹，每个子文件夹储存对应的文件，如下表所示：

char varchar varchar2 的区别:

1．CHAR的长度是固定的，而VARCHAR2的长度是可以变化的， 比如，存储字符串“abc"，对于CHAR (20)，表示你存储的字符将占20个字节(包括17个空字符)，而同样的VARCHAR2 (20)则只占用3个字节的长度，20只是最大值，当你存储的字符小于20时，按实际长度存储。
2．CHAR的效率比VARCHAR2的效率稍高。
3．目前VARCHAR是VARCHAR2的同义词。工业标准的VARCHAR类型可以存储空字符串，但是oracle不这样做，尽管它保留以后这样做的权利。Oracle自己开发了一个数据类型VARCHAR2，这个类型不是一个标准的VARCHAR，它将在数据库中varchar列可以存储空字符串的特性改为存储NULL值。如果你想有向后兼容的能力，Oracle建议使用VARCHAR2而不是VARCHAR。
4.何时该用CHAR，何时该用varchar2？
CHAR与VARCHAR2是一对矛盾的统一体，两者是互补的关系.
VARCHAR2比CHAR节省空间，在效率上比CHAR会稍微差一些，即要想获得效率，就必须牺牲一定的空间，这也就是我们在数据库设计上常说的‘以空间换效率’。
VARCHAR2虽然比CHAR节省空间，但是如果一个VARCHAR2列经常被修改，而且每次被修改的数据的长度不同，这会引起‘行迁移’(Row Migration)现象，而这造成多余的I/O，是数据库设计和调整中要尽力避免的，在这种情况下用CHAR代替VARCHAR2会更好一些。

Oracle数据库中char()，varchar2()，nvarchar2()三种数据类型的区别如下:

1.  char()类型:
（1）如果在数据库中定义的长度为10位，而我实际录入的数据长度不足10位，系统会在录入数据的后面用空字符串补足10位。
（2）一个全角认作2位长度。
2. varchar2()类型：
（1）不足数据库规定长度，不会补足长度。
（2）一个全角认作2位长度。
3. nvarchar2()类型：
（1）不足数据库规定长度，不会补足长度。
（2）一个全角认作1位长度。
结论：由此在做设计时，为节省系统资源会尽量选用varchar2()和nvarchar2()类型。

文章出处：http://www.diybl.com/course/7_databases/oracle/oraclexl/2008324/107065.html

由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试报告能很好地展示自己的工作状况，测试报告是提供给很多人看的一份文档。

        下面是一个项目的测试报告的纲要：
1 简介
1.1 编写目的
1.2 项目背景
1.3 术语和缩略词
1.4 参考资料
2 目标及范围
2.1 测试目的及标准
2.2 测试范围
3 测试过程
3.1 测试内容
3.2 测试时间
3.3 测试环境
3.4 测试方法及测试用例设计
4 测试情况分析
4.1 测试概要
4.2 测试用例执行情况
4.3 缺陷情况
4.4 测试覆盖率分析
4.5 产品质量情况分析
5 测试总结
5.1 测试资源消耗情况
5.2 测试经验总结
6 附件
附件1 测试用例清单
附件2 缺陷清单
一、缺陷分类报告
        缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
1．缺陷类型分布报告
        缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。
缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。

三、典型缺陷与Bug模式
        软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习，总结出Bug模式，用于指导测试。如果开发人员能关注这些Bug模式，还能起到预防错误的效果。
        要成为典型缺陷，必须满足以下条件：
        重复出现、经常出现；
        能代表某种类型的错误；
        能通过相对固定的测试方法或测试手段来发现这些错误。
        总结这些典型缺陷出现的现象，出现的原因，以及测试方法，就能成为一个Bug模式。

        说明：根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等，可以总结出不同的Bug模式，不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

        提炼Bug模式的一般步骤如下：
        步骤1：分析缺陷报告，找出经常出现的Bug类型。
        步骤2：分析Bug的根源，找出Bug产生的深层次原因。
        步骤3：分析找到Bug的方法，总结如何才能每次都发现该类型的Bug。
        下面举一个例子来说明这个过程。
        首先，测试人员在分析缺陷报告时发现，有一类Bug经常出现，并且错误现象一致：执行某功能时提示Time Out。
        测试人员与程序员一起分析原因，发现这些错误都是在操作数据库时发生，发送的SQL语句被数据库长时间执行未返回，因此提示Time Out。通过进一步地分析表明，.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间（以秒为单位）默认为30s，而数据库操作在较大数据量的情况下一般都超过这个时间，因此会提示超时的错误信息。
        这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
        那么，如何才能找出这样的Bug呢？一般情况下，这类Bug基本上不会出现，只有数据量足够大时才会出现，因此需要设置大批数据，结合性能测试或压力测试来发现此类问题。也可以通过白盒的方式，查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性，这样将更有针对性地揭露上述的错误。
        至此就完成了一个Bug模式的归纳、提炼和总结，如果程序员积极地参与到该总结和分析过程中来，则可形成一个良性的反馈，当下次程序员编写相同的程序时就会避免类似的错误发生。
四、测试中的PDCA循环
        PDCA循环是一种放之四海皆准的原则。在软件测试的过程中，也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型，如图7.34所示，对质量的不断提高和改进非常有效。

  PDCA循环模型