本节书摘来自异步社区《精通软件性能测试与LoadRunner最佳实战》一书中的第1章1.6节软件测试流程，作者于涌 , 王磊 , 曹向志 , 高楼 , 于跃，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.6 软件测试流程
精通软件性能测试与LoadRunner最佳实战
软件测试工作通常要通过制订测试计划、测试设计、执行测试、测试总结几个阶段来完成。
测试计划
测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。
1．制订测试计划的目的
一个计划一定是为了某种目的而产生的，对于软件质量管理而言，制订测试计划的目的主要有以下几点。
（1）使软件测试工作各个阶段目标更明确，测试工作可以有条不紊顺利进行。
（2）促进项目组成员相互沟通，及时解决由于沟通不畅而引起的问题。
（3）预测在测试过程中可能出现风险并制订合理规避风险措施。
（4）使软件测试工作更易于管理。
2．制订测试计划的原则
制订测试计划是测试中最有挑战性的一个工作，以下原则将有助于制订测试计划工作。
（1）制订测试计划应尽早开始。
（2）保持测试计划的灵活性。
（3）保持测试计划简洁和易读。
（4）尽量争取多渠道测试计划评审工作。
（5）计算测试计划的投入成本。
3．面对的问题
制订测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。
（1）与开发者意见不一致，尽量达成一致，必要时企业高层需要介入。
（2）缺乏测试工具，在应用熟练的情况下，大型的项目测试工具的应用会在一定程度上减少测试周期，特别是在性能测试方面，测试工具的应用是非常必要的，大用户量的并发操作，人工模拟困难巨大。
（3）培训/沟通不够，培训工作很重要，有助于测试人员了解需求，了解系统实现的细节等。
（4）管理部门缺乏对测试工作的理解和支持，这是非常困难的事情，如果没有管理部门的支持与理解，我们的测试工作就会阻力重重，处理方法还是要测试部门相关领导要多和管理部门相关领导沟通、交流，阐述测试的重要性，当然，测试人员也要通过自己的不懈努力来证明经过测试的产品和没有测试的产品的具体差别，让管理部门人员真正意识到测试的重要性。
（5）缺乏用户的参与，测试的目的是为了要满足客户的需求。如果有客户的参与，我们可以更加明确客户的操作环境、操作方式等，这些对于我们后期能够合理地设计测试用例都是大有裨益的。
（6）测试时间不足、工期短、资源少是测试部门经常要面临的问题。这也需要和项目组合理确定测试时间，阐述测试时间和产品质量之间的关系以及测试的重点等内容，尽量多争取较长的、合理的测试时间。
4．建议
制订测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制订测试计划时，使用正规化文档通常比较好，本书的附录提供了相关模板请大家借鉴参考。
测试设计
测试设计阶段要设计测试用例和测试数据，要保证测试用例完全覆盖测试需求。简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重现出来，那就表示已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，将问题修改完成后，在下一个测试版本提交后，测试工程师取得新的测试版本，用同一个测试用例来测试这个问题，确保该问题被修复。在测试时，不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从庞大的测试用例中精心挑选出具有代表性的测试数据来进行测试。使用测试用例的好处主要体现在以下几个方面。
（1）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
（2）测试用例使软件测试的实施重点更加突出、目的更加明确。
（3）在软件版本更新后，只需修正少量的测试用例便可开展测试工作，降低工作强度，缩短项目周期。
（4）功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化，其效率也不断提高。
测试用例主要有如下几种。
（1）功能测试用例。包含功能测试、健壮性测试、可靠性测试。
（2）安全测试用例。
（3）用户界面测试用例。
（4）安装/反安装测试用例。
（5）集成测试用例。包含接口测试。
（6）性能测试用例。包含性能测试、负载测试、压力测试、容量测试、并发测试、配置测试、可靠性测试、失败测试。
.1 测试用例设计
测试设计阶段最重要的是如何将测试需求分解，如何设计测试用例。
1．如何对测试需求进行分解
对测试需求进行分解需要反复检查并理解各种信息，主要是和需求分析人员进行交流，必要的情况下也可以和用户交流，理解用户的真正需求是什么。
可以按照以下步骤执行。
（1）确定软件提供的主要功能、性能测试项详细内容。
（2）对每个功能，确定完成该功能所要进行的操作内容。
（3）确定数据的输入和预期的输出结果。
（4）确定会产生性能和压力测试的重要指标，包括硬件资源的利用率，业务的响应时间，并发用户数等重要内容。
（5）确定应用需要处理的数据量，根据业务情况预期未来2、3年内的数据扩展。
（6）确定需要的软件和硬件配置。
……
2．如何设计测试用例
测试用例一般指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，需要指出的是，测试数据都是从庞大的可用测试数据中精心挑选出具有代表性的用例。测试用例是软件测试系统化、工程化的产物，而测试用例的设计一直是软件测试工作的重点和难点。
设计测试用例也就是设计针对特定功能或功能组合的测试方案，并编写成文档。测试用例应该体现软件工程的思想和原则。
传统的测试用例文档编写有两种方式。
（1）一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细记录下来，包括所有被操作的项目和相应的值。
（2）另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录则是这些字段的值。
评价测试用例的好坏有以下两个标准。
（1）是否可以发现尚未发现的软件缺陷。
（2）是否可以覆盖全部的测试需求。
.2 测试用例设计的方法
软件测试设计的重要工作内容就是用例的设计，那么用例设计有那些方法呢？接下来，就给大家介绍一下用例设计一些常用的方法。
1．等价类划分方法
等价类划分是一种典型的黑盒测试方法。使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个进行测试。如何选择适当的子集，使其尽可能多地发现错误，解决的办法之一就是等价类划分。
首先，把数目极多的输入数据，包括有效的和无效的，划分为若干等价类，而所谓等价类，是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可用少量代表性测试数据，取得较好的测试结果。
等价类的划分有以下两种不同的情况。
（1）有效等价类：是指符合《用户需求规格说明书》的数据规范，合理地输入数据集合。
（2）无效等价类：是指符合《用户需求规格说明书》的数据规范，无效地输入数据集合。
划分等价类的原则如下。
（1）按区间划分。
（2）按数值划分。
（3）按数值集合划分。
（4）按限制条件或规则划分。
在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表1-1所示。
再从划分出的等价类中按以下原则选择测试用例。
（1）为每一个等价类规定一个唯一的编号。
（2）设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，直到所有的有效等价类都被覆盖为止。
（3）设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。
这里给大家举一个小例子，记得上小学一年级的时候，主要学习两门功课：语文和数学，两门功课单科满分成绩均为100分。期末考试的时候，老师会计算每个学生的总分，即总分＝语文分数＋数学分数。为了老师计算个人总成绩，编写如下C语言代码：
int sumscore(int maths，int chinese)
{
int sumdata;
if (((maths>100) || (maths<0)) || ((chinese>100) || (chinese<0)))
{
printf("单科成绩不能小于0或者大于100！");
return -1;
}
sumdata=maths+chinese;
printf("%d"，sumdata);
return sumdata;
}
我们现在根据“单科成绩只能在0～100的两个数字相加”的需求来设计测试用例，大家可以知道如果想把0～100的所有情况都测试到（仅包含正整数和零），我们需要101×101＝10201个用例，显然这种穷举测试的情况是不可行的方法，因此我们尝试用等价类划分的方法来设计用例。
根据单科成绩输入的限制条件，可以将输入区域划分成3个等价类，如图1-10所示。
从图1-10中可以看到，我们将输入区域分成了一个有效等价类（成绩在0～100）和两个无效等价类（成绩<0）和（成绩>100）。下面可以从每一个等价类中选择一组具有代表性的数据来进行函数正确性的测试，详细数据请参见表1-2。
细心的朋友们可能会发现一个问题，就是我们刚才等价类的划分并不是很完善，我们只针对整型数据进行用例的设计，如果我们输入的是空格、小数、字母等数据怎么办？所以，测试用例的设计应该尽可能用少量的数据覆盖尽可能多的情况，上面用例的设计我们更多地从输入数据的范围进行了考虑，没有考虑如果参数的类型输入不正确的情况。下面我们将先前没有考虑进去的字母、空格等特殊字符也加入到测试数据列表中，形成比较完善的等价类划分测试数据列表，详细数据请参见表1-3。
2．边界值分析法
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。
选择测试用例的原则如下。
（1）如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。
（2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数作为测试数据。
（3）如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例。
（4）如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。
（5）分析规格说明，找出其他可能的边界条件。
3．因果图表法
因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤如下。
（1）分析软件需求规格说明描述中哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件。
（2）分析软件需求规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。
（3）标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干标准的符号标明约束条件。
（4）把因果图转换成判定表。
（5）为判定表中的每一列设计测试用例。
下面我们列出一些因果关系图常用的表示符号，如图1-11所示。
为了使大家对因果关系图方法有一个清晰的了解，这里给大家举一个例子：在一个应用系统中，系统要求能够分类导入进货和销售的数据，对文件的命名有如下要求，文件名第一个字符必须为A（进货）或B（销售），第二个字符必须为数字。满足则导入进货、销售接口文件信息到系统中。第一个字符不正确发出信息X12（“非进货或销售数据！”），第二个字符不正确发出信息X13（“单据信息不正确！”）。
（1）分析规范（如表1-4所示）。
（2）画出因果图（如图1-12所示）。
中间结点 是导出结果的进一步原因，考虑到原因1、2不可能同时为1，加上E约束。
（3）将因果图转换为判断表（如表1-5所示）。
从上表可能发现组合情况1、2测试用例是空的，这是为什么呢？这是因为前面已经提到了原因，1、2不可能同时为1，所以条件1和条件2同时为1是没有意义的（即第一个字符既为A又为B这种情况）。
4．判定表方法
判定表是分析和表达多逻辑条件下执行不同操作的情况的一种方法。判定表的优点是能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
判定表通常由4个部分组成，如图1-13所示。
下面分别描述一下各个组成部分。
条件桩（Condition Stub）：列出问题的所有条件。通常认为列出的条件的次序无关紧要。
动作桩（Action Stub）：列出问题规定可能采取的操作。这些操作的排列顺序没有约束。
条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真 假值。
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
这里给大家举一个例子：“某个货运公司邮递货物的收费标准如下：如果收件地点在本省，则快件每千克5元，慢件每千克3元；如果收件地点在外省，则在以内（包括）快件每千克7元，慢件每千克5元，而超过时，快件每千克9元，慢件每千克7元。
根据对上面问题的分析以后，我们可以得到条件取值分析表，如表1-6和表1-7所示。
（1）规则及规则合并。
规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。
化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。
两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关，于是可合并，这里我们用“－”表示与取值无关，如表1-8所示。
表1-8 化简规则表
判定表的建立步骤如下（根据软件规格说明）。
① 分析判定问题涉及几个条件。
② 分析每个条件有几个取值区间。
③ 画出条件取值分析表，分析条件的各种可能组合。
④ 分析决策问题涉及几个判定方案。
⑤ 画出有条件组合的判定表。
⑥ 决定各种条件组合的决策方案，即填写判定规则。
⑦ 合并化简判定表，即相同决策方案所对应的各个条件组合是否存在无须判定的条件。
（2）判定表的优点和缺点。
优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏，如表1-9所示。
缺点：不能表达重复执行的动作，例如，循环结构。
B. Beizer指出了适合使用判定表设计测试用例的条件：
规格说明以判定表形式给出，或很容易转换成判定表；
条件的排列顺序不会也不影响执行哪些操作；
规则的排列顺序不会也不影响执行哪些操作；
每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其他的测试用例罢了。
5．错误推测法
有时候，为了发现一些问题，需要个人开发、测试以及其他方面的经验积累才能够发现缺陷。有很多朋友可能发现，一般用人单位都希望同等价位招聘一名有测试工作经验的人，而不愿意招聘一名应届毕业生。原因不仅仅是工作过的同志了解测试工作的流程，作为招聘单位可能考虑更多的是，已工作的朋友在测试方面积累了丰富的经验，将会为公司的软件测试缺陷的定位提供良好的条件。有经验的人靠直觉和经验来推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子，这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
笔者曾经在对一个人事信息管理性能测试的时候，发现内存泄露明显，在使用LoadRunner做性能测试的时候，50个虚拟用户并发的情况下，应用系统会出现内存被耗尽，最后宕机的情况发生。依照以前的开发经验，笔者认为有以下几种原因都会导致内存泄露情况的发生：
（1）代码编写时，申请了内存，使用完成以后，没有释放申请的内存；
（2）变量使用完成后，没有清空这些变量的内容，也将会导致内存泄露；
（3）建立数据库连接、网络连接、文件操作等使用完成后，没有断开使用的连接。
……
上面几种情况都将会出现内存泄露。作者把内存泄露现象以及出现内存泄露的原因信息提供给了开发人员，研发人员通过对代码的审查，很快就发现在显示人员的照片时，申请了内存，使用完成后，没有释放，就是这个原因直接导致宕机情况的发生。
综上所述，对于测试工作来讲，软件开发、软件测试、操作系统、应用服务器、数据库以及网络等方面的经验，都会对您发现系统中的缺陷、定位问题产生的原因、解决问题提供一种思路。
6．场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。
如图1-14所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
为了使大家对场景设计方法能够有一个较深入的了解，这里给大家举一个银行ATM机提款操作的例子。下面是银行ATM机操作业务的流程示意图，如图1-15所示。
根据上面的流程示意图，我们以银行的客户提款为例结合用例设计的方法，设计出如下场景，如表1-10所示。
注：T 代表 True（真），F代表 False（假），N/A代表Not Applicable（不适合）。
用例的设计不仅仅是简单地把要做的事情描述出来，通常还需要把每一个场景的测试数据也设计出来，这样再进入测试执行阶段就可以按部就班，做到心中有数了。下面就是针对前面的场景用例而设计出来的数据，如表1-11所示。
当然，除了上面讲的这些常用的用例设计方法以外，还有正交试验等设计方法。在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理、认真研读需求规格说明书，了解客户的需求，积累更多的测试经验，以便有效地提高测试水平。
以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。
（1）首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。
（2）在任何情况下都必须使用边界值分析方法，经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。
（3）可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
（5）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。
（6）对于参数配置类的软件，要用正交实验法选择较少的组合方式达到最佳效果（请关注正交实验法的读者自行查找相关资料进行学习）。
（7）功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。
（8）对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
性能测试用例在测试设计阶段也是一项重要的工作，本书重点是讲解性能测试工具LoadRunner的应用，在后续章节对性能测试用例的设计有详细地描述，请大家参看。
测试执行
用例设计完成之后，通常进行需求、研发、测试、质控人员举行一轮或者多轮对用例的评审工作，评审主要是大家针对设计的用例，考查是否能够覆盖用户的需求。如果用例评审不通过，则需要测试人员对用例进行修改完善、用例补充等工作，直到用例评审通过为止。
测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，就是尽可能发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率、获得更高质量的收益。
1．缺陷管理
测试阶段是测试人员和研发人员沟通最频繁的一个阶段。在软件测试过程中，测试人员发现缺陷以后，通常会提交到缺陷管理工具中，常见的缺陷管理工具包括：开源免费的测试工具BugZilla、Mantis、JIRA、BugFree等；商业的测试工具有HP TestDirector(QualityCenter)、IBM Rational ClearQuest、Compuware TrackRecord等。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个中央数据仓库，在不同地方就能交互测试信息。一般缺陷管理工具都是测试管理工具的一个重要组成部分，它们都能够将测试过程流水化——从测试需求管理，到测试计划；测试日程安排，测试执行到出错后的错误跟踪——仅在一个基于浏览器的应用中便可完成，而不需要每个客户端都安装一套客户端程序，使用简便。
缺陷提交以后，在大型软件企业或者非常规范企业，测试人员提交缺陷以后，测试负责任人或测试主管首先看一下这个缺陷是不是一个缺陷，如果是缺陷提交给研发的项目经理，研发项目经理将缺陷再分派给具体的研发人员。研发将缺陷修改完成以后，形成一个新的版本，提交给测试组，测试人员对新提交的版本进行问题的验证——这个过程也叫回归测试。如果测试人员经验证所有缺陷均得到修复，则关闭缺陷，那么这个版本就可以作为发布的版本。但是，更多的时候大家可能会遇到对缺陷研发、测试人员之间存在着争议的情况——测试人员认为这个缺陷应该修改，而研发人员认为这个缺陷不需要修改，这时需要质控、研发、测试等相关人员坐到一起，大家对缺陷进行评审来决定缺陷是否需要修改，或者对缺陷是否进行降级处理等，待达到产品的准出条件以后（准出条件举例，如严重等级为中等级别的缺陷不能超过2个），就可以发行产品了。当然，缺陷的处理流程，不同企业对缺陷的处理流程也是各不相同的，这里给大家介绍一下最普遍的缺陷处理流程，如图1-16所示。
下面简单给大家介绍一下。
（1）测试人员发现并提交一个Bug，此时Bug的状态为新建（New）状态。
（2）测试负责人、测试主管确认是一个Bug以后，将Bug的状态置为打开（Open）状态，研发经理针对提交的Bug指定研发人员对Bug进行修复，研发人员接受以后，Bug的状态变为已分配（Assigned）状态。
（3）研发人员修改该Bug以后，将Bug的变为已修复（Fixed），待系统Bug修复完成以后，形成一个新的版本提交给测试人员。
（4）测试人员对新版本进行回归测试，如果该Bug确实已经修正，则将Bug的状态修改为已关闭（Closed）状态，如果没有修正，则需要让开发人员继续修改该Bug。
当然，上面的流程还很不完善，在测试过程中还会遇到，新版本中仍然存在与上个版本相同的缺陷，此时就需要将Bug置为重新打开（Reopen）状态，测试人员甲和测试人员乙提交相同Bug，此时就需要将Bug置为重复（Duplicated）状态，还有研发人员认为这不是一个Bug，此时Bug被置为拒绝（Rejected）状态等，这些情况在上面的流程中都没有涉及，所以如果您对缺陷的流程非常关心的话，建议您参考其他的测试书籍，这里限于篇幅，不做过多介绍。
通常在提交一个Bug的时候，都需要输入一些重要的信息，如图1-17所示，包括：缺陷的概要信息（Summary）、指派给某人（Assigned To）、缺陷发现者（Detected By）、缺陷发现的版本（Detected in Version）、缺陷发现日期（Detected on Date）、优先级（Priority）、Severity（严重等级）、项目名称（Project）、模块名称（Subject）、状态（Status）、描述（Description）等信息。
下面简要描述一下提交Bug时一些重要项的含义。
（1）缺陷概要是用简明扼要的语言表述缺陷的实质性问题。
（2）描述是对概要信息的详细表述，可以包括操作环境、操作步骤、测试数据等信息，这些内容将是您复现问题的重要依据。
（3）缺陷发现的版本是在测试的时候，那个版本的软件中发现的该缺陷。
（4）项目名称是您测试的产品或项目的名称。
（5）模块名称是指产品或项目的具体的功能模块名称，如系统设置模块、业务处理模块等。
（6）状态是指当前缺陷处于何种阶段，如New、Open、Fixed、Closed等。
（7）优先级是处理该缺陷的优先等级，等级高的需要优先处理。
（8）严重等级是指该缺陷将对系统造成的影响程度，在TestDirector(QualityCenter)中主要包括：Low（轻微）、Medium（中等）、High（高）、Urgent（严重）等。
2．测试执行
在软件测试执行过程中，因为各个企业的背景不一样，所以实施的手段也各不相同。有的企业非常规范，不仅进行常规的黑盒测试（功能性测试），还进行了白盒测试（如单元测试等），同时进行了系统性能方面的测试；有的企业则主要进行功能性测试和简易的性能测试，这可能是目前国内软件企业最普遍处理方式；有的企业则仅仅进行功能性的测试。
执行测试时应遵循以下步骤。
（1）设置测试环境，确保所需的全部构件（硬件、软件、工具、数据等）都已实施并处于测试环境中。
（2）将测试环境初始化，以确保所有构件都处于正确的初始状态，可以开始测试。
（3）执行测试过程。
测试的执行过程是非常重要， 如果测试执行过程处理不得当将会引起软件测试周期变长，测试不完全，人力、物力严重浪费等情况。测试执行阶段是软件测试人员与软件开发人员之间沟通最密切的一个阶段。软件测试是否能够按照计划正常执行和开发人员、IT管理人员、需求人员等的密切配合分不开的。通常，开发人员构建一个版本并制作成一个安装包以后，首先要先运行一下，看看系统的各个功能是否能够正常工作，如果涉及硬件产品还要结合硬件产品进行测试，保证系统大的流程应该是可以运行通的，这也就是我们前面所说的冒烟测试。经过冒烟测试以后，如果没有问题则把该包提交给测试部门进行测试，否则，研发人员需要定位问题产生的原因，修改代码或设置，重新编译、打包以及进行冒烟测试。如果测试部门拿到的是没有经过冒烟测试的产品，则很有可能会出现前面讲的资源浪费、耽误测试进度等情况的发生。笔者管理的测试团队有一次就因为研发人员因为工作任务繁忙，没有对提交的软、硬件结合产品进行冒烟测试，导致测试人员为定位问题而进行业务模块、系统设置等多方面的测试工作，苦苦耗时达5个工作日之久，最后检查到原因，是研发人员提供的硬件的端口是坏的，这个教训很深刻。冒烟测试后的产品提交给测试部门以后，测试人员部署相应的环境，开始依据前期已经通过评审的功能、性能方面的测试用例。在执行用例的过程中，如果发现了缺陷，则提交到缺陷管理工具中，所有的功能、性能测试用例执行完成以后，宣告第一轮测试工作完成。开发人员需要对第一轮测试完成后，出现的缺陷进行修复工作，测试人员也需要在测试过程中修改、完善、补充用例的工作，通常，每轮测试完成以后，测试人员都会给出一个测试的报告，指出当前存在缺陷的严重等级数目，重要的缺陷，缺陷的列表等数据提供给项目经理、研发经理等，目的是让项目组的相关负责人清楚当前系统中存在的主要问题，及时把问题解决掉。等到研发人员对第一轮的缺陷修复完成后，重新编译、打包、冒烟测试，提交给测试部门，测试人员进行第二轮测试，测试人员此时需要进行回归测试，验证上一轮的问题是否已经修复，是不是还有新的问题产生等。如此往复，经过几轮的测试以后，依据项目计划、测试计划以及缺陷的情况等来决定是否终止测试。
测试总结
测试执行完成以后，我们需要对测试的整个活动进行总结。测试总结工作是非常有意义的一件事情，它不仅能够对本次测试活动进行分析，也能够为以后测试同类产品提供重要的依据。
通常，一份测试总结报告中会包括如下内容：系统的概述、编写目的、参考资料、测试环境、差异、测试充分性评价、残留缺陷、缺陷统计、缺陷分析、测试活动总结、测试结论等方面。
1．编写测试总结报告的目的
测试总结的目的是总结测试活动的结果，并根据这些结果对测试进行评价。这种报告是测试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。在测试执行阶段的末期，应该为每个测试计划准备一份相应的测试总结报告。本质上讲，测试总结报告是测试计划的扩展，起着对测试计划“封闭回路”的作用。
2．重要项说明
编写目的：主要说明编写这份文档的目的，指出预期的读者。
参考资料：主要列出编写本文档时参考的文件、资料、技术标准以及他们的作者、标题、编号、发布日期和出版单位，说明能够得到这些文件资料的来源。对于每个测试项，如果存在测试计划、测试设计说明、测试规程说明、测试项传递报告、测试日志和测试事件报告等文件，则可以引用它们。一般参考资料可以用列表形式给出，参考表1-12。
系统概述：主要归纳对测试项的评价，指明被测试项及其版本/修订级别，测试项概述，如项目/产品的名称、版本以及测试项内容等。您可以参考表1-13。
产品名称：人事代理系统。
产品版本：V。
测试项信息如表1-13所示。
差异：报告测试项与它们的设计说明之间的差别，并指出与测试计划、测试设计说明或测试规程说明中描述或涉及的测试间的差别，说明产生差别的原因。
测试充分性评价：根据测试计划规定的充分性准则（如果存在的话）对测试过程作充分性评价。指出未被充分测试的特性或特性组合，并说明理由。测试的评测主要方法包括覆盖评测和质量评测。测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。
3．覆盖评测
覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。
（1）基于需求的测试覆盖。
基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。
（2）基于代码的测试覆盖。
如果您所在的单位做白盒测试，则需要考虑基于代码的测试覆盖。基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少。许多测试专家认为，一个测试小组在测试工作中所要做的最为重要的事情之一就是度量代码的覆盖情况。很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。
但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能担保代码是按照客户需求和设计的要求去做了。
4．质量评测
测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。
常用的测试有效性度量是围绕缺陷分析来构造的。缺陷分析就是分析缺陷在与缺陷相关联的一个或者多个参数值上的分布。缺陷分析提供了一个软件可靠性指标，这些分析为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。
对于缺陷分析，常用的主要缺陷参数有以下4个。
状态：缺陷的当前状态（打开的、正在修复的或关闭的等）。
优先级：表示修复缺陷的重要程度和应该何时修复。
严重性：表示软件缺陷的恶劣程度，反映其对产品和用户的影响等。
起源：导致缺陷的原因及其位置，或排除该缺陷需要修复的构件。
缺陷分析通常用以下3类形式的度量提供缺陷评测。
（1）缺陷发现率。
缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图，请大家参见图1-18。
（2）缺陷潜伏期。
测试有效性的另外一个有用的度量是缺陷潜伏期，通常也称为阶段潜伏期。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。图1-19显示了一个项目的缺陷潜伏期的度量。
（3）缺陷密度。
软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的：
图1-20所示为一个项目的各个模块中每千行代码的缺陷密度分布图。
但是，在实际评测中，缺陷密度这种度量方法是极不完善的，度量本身是不充分的。这里边存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度及其对产品和用户影响的严重程度，以及修复缺陷的重要程度有很大差别，有必要对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，这样将使这种评测更加充分，更有实际应用价值。因为在测试工作中，大多数的缺陷都记录了它的严重程度的等级和优先级，所以这个问题通常都能够很好解决。例如，图1-21所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布方式。
上面讲了一些关于覆盖评测和质量评测内容，下面结合以前做过的项目给大家举一些测试充分性评价方面的示例。
（1）本次测试严格按照软件系统测试规范执行测试任务。
（2）在测试进行过程中，满足执行测试的前置条件，测试计划、测试用例准备齐全，并经过内部评审认可，需求覆盖度达到100%，满足测试准入条件。
（3）测试过程严格按照测试计划实施，测试用例的执行覆盖度达100%，同时，测试过程中根据实际系统的运行方式，对测试用例和数据进行了修改和补充。
（4）测试过程中进行了必要的回归测试和交叉测试。
……
结果概述：总结测试的结果，指出各测试项的测试情况，描述测试用例的执行通过情况，给出最后一次的测试版本号，这里给大家一个示例参考。
（1）本次测试进行了功能测试的检查。最后一次的测试基线为：Build_HHR(α) V.014。
（2）功能测试执行情况详见表1-14，缺陷描述详见TD。
残留缺陷摘要：简要罗列未被修改的残留缺陷，并附有未修复意见。
缺陷统计：对隶属于各个测试项的缺陷进行统计，通常都需要统计一下两项数据，有的测试部门还有统计其他一些数据信息，请大家根据需要进行选择添加。
各模块下不同解决方案的缺陷统计如表1-15所示。
各模块下不同严重级别的缺陷统计如表1-16所示。
缺陷分析：对有效缺陷进行缺陷分布分析、缺陷趋势分析，以及缺陷龄期分析。
通常都会对以下数据进行分析。
缺陷分布：如表1-17所示。
由表1-17可知，模块“预约”和“电子档案”、“批量导入”、“档案录入”占的缺陷相对比较多，主要是异常处理、逻辑控制以及界面易用性问题。
缺陷趋势图：如图1-22所示。
由图1-22可知：
（1）整个测试活动持续11天，随着测试时间的推移，新提交的缺陷数减少；
（2）整个测试共提交有效缺陷42个，所有缺陷均已解决、已关闭。
活动总结：总结主要的测试活动和事件。总结资源消耗数据，如人员的总体水平，总机时和每项主要测试活动所花费的时间。同时，与《测试计划》中活动进度安排进行比对，如表1-18所示。
根据《测试计划》中计划的测试时间和实际测试执行时间进行比对，可得表1-19。
由表1-19可知，计划时间比执行时间偏差较大，主要原因为安排两个测试人员执行测试，但是由于另外一名测试人员配合其他产品的测试相关工作，所以计划时间长于实际测试时间。
测试结论：对每个测试项进行总的评价。本评价必须以测试结果和项的通过准则为依据。说明该项软件的开发是否已达到预定目标。计算代码缺陷率和产品缺陷率。
例如：
（1）经测试验证，系统完成需求所要求的全部功能，测试项中各功能的实现与需求描述一致；
（2）测试结果满足测试退出准则；
（3）整个系统在设计结束后定义功能点96个，测试发现的有效缺陷为42个，按功能点对缺陷数进行计算可得，代码缺陷率=42/96=0.4375个/FP（代码缺陷率=有效缺陷/FP总数）。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
