软件制造工程组合测试

软件制造工程组合测试第四章测试工程4.4测试的前期准备软件测试工程的作业过程可分为测试设计（包括制定测试计划、确定测试方法等）和实施测试两大步骤。测试规划与测试设计对大规模开发系统一般不采用一次性整体测试，而是从局部依次扩大到整体的测试，按计划，有步骤地实施测试。一般从项目需求定义开始，概要设计、详细设计、程序编码的各个开发阶段，要进行测试设计，作成测试计划书，还包括测试作业完成后移植运行作业的计划。测试规划与测试设计表4.3各开发阶段的测试规划和设计评审验证内容测试规划与测试设计测试计划书一般包括如下的一些的内容：（1）测试工程概要、测试场所、测试方针（2）测试日程和实施体制测试规划与测试设计（3）测试管理方法

·测试工具

·测试环境

·测试检测清单

·验证方法

·版本管理方法

·进度管理方法

·问题管理方法

·回归测试方法

·设计变更管理方法测试规划与测试设计（4）针对各阶段的测试应明确的事项

·阶段测试的目的和范围

·阶段测试开始和测试终止的基准

·阶段测试检测清单

·阶段测试实施日程和实施体制

·阶段测试的验收基准和方法4.4.2了解系统错误、缺陷的影响度

信息系统的测试很难实现在与实际运行环境（数据、使用者、硬件、时间、网络、系统负荷等）完全一致的条件下进行的测试。在做测试计划和测试设计时，充分理解软件的错误、缺陷对用户将会造成什么样的影响是很重要的。4.4.2了解系统错误、缺陷的影响度软件中即使是很微小的错误，有可能会给用户造成重大的损害和影响。4.4.2了解系统错误、缺陷的影响度下图是系统缺陷对一个生产型企业的各个方面所产生的影响

业务混乱系统缺陷丧失顾客信任经济损失不可能恢复的数据业务停止不能回答用户的咨询送货发生错误交付期延迟不能处理用户订货断货业务状况不明不能检索信息不能进行业务指示产品报废业务效率降低发生手工作业发生返工用户信息产品信息设计信息销售信息生产信息系统缺陷的影响图利用各种测试支持工具测试工具：⑴作为定型测试，反复实施测试作业的支持工具；⑵确定测试分支、生成测试数据的支持工具；⑶验证测试的覆盖率，提高测试效率的工具；⑷性能测试的支持工具；⑸管理与测试相关连项目的支持工具；⑹变更管理、版本管理的支持工具；⑺检测错误作业的支持工具。利用各种测试支持工具表4.4部分常用的测试支持工具测试支持工具注意点组合测试支持工具·支持测试计划的编制·支持测试项目管理·测试分支管理测试程序作成工具·支持作成测试分支的测试程序测试数据生成工具·自动生成测试数据自动测试工具·记录用户操作、自动生成测试程序·根据测试记录自动运行测试程序·自动生成测试记录测试管理工具·记录已测试的编码部分·统计分析测试的覆盖范围性能分析工具·测量运行时的特性·统计分析编码的执行次数、耗费时间检测错误工具·提供检测错误的功能（一般作为开发工具的功能提供）软件管理工具·版本管理·变更管理表4.4常用测试支持工具4.4.4测试检测清单与测试数据根据测试计划，按各个测试阶段的目的准备实施测试使用的检测清单和测试使用的数据。4.4.4测试检测清单与测试数据测试检测清单是将要检测的项目以能确认的方式用文字描述出来。在不同的测试阶段作成不同的测试检测清单，如单元（模块）测试阶段的程序检测清单称为PCL，组合测试阶段的检测清单称为CCL，系统测试阶段的检测清单称为SCL。4.4.4测试检测清单与测试数据在测试中需要验证的项目及其判别、制约条件必须全部记入检测清单。4.4.4测试检测清单与测试数据例如单元测试的程序检测清单PCL要明确以下几个方面内容：⑴窗体显示的输入、输出项目及判别条件；⑵输出表格印刷输出项目及判别条件；⑶数据库/文件输入、输出项目及判别条件；⑷程序间传递的数据、信息及判别条件。4.4.4测试检测清单与测试数据作成检测清单应遵循如下的原则：⑴具体性：判别条件和确认内容必须是在测试结果中可确认的；⑵完整性：检测内容必须是包含设计书中的所有项目、功能；⑶有一定的密度：检测点占测试对象的一定比例。4.4.4测试检测清单与测试数据⑷有一定的分布率：如PCL对正常、异常、临界处理及模块间接口数据、信息传输的检测一般按如下比率分配：①检测正常分支的PCL条数约占70%；②检测异常分支的PCL条数约占10%；③检测边界、临界项目的PCL条数约占15%；④检测关联模块间传递、接口项目的PCL条数约占5%。4.4.4测试检测清单与测试数据测试检测清单针对各种各样的测试分支，须明确测试的前提条件、应确认的内容，明确在何种条件下应有什么样的测试结果。每个测试分支都有编号，以便于实施测试时记录测试结果。4.4.4测试检测清单与测试数据测试结果的记录不仅仅是记录检查合格，还要记录测试结果的具体内容。记录测试结果要注意易读性，便于他人追踪测试中发现的问题。根据不同用户的要求，测试内容和测试结果还有可能作为开发方的系统验证资料提供给用户。4.4.4测试检测清单与测试数据在测试工程的进度管理中，可以按测试检测清单确定的测试分支作成测试实施日程，统计已实施测试的分支数，确认各个测试分支组的测试进度。因此测试检测清单又可以用于测试进度管理。4.4.4测试检测清单与测试数据作成测试检测清单后，根据测试检测清单记述的测试分支准备其使用的测试数据。此外，根据测试分支的覆盖率（正常处理、例外处理等）、测试分支数，还可预算测试工程所需要的工数。测试检测清单格式要根据测试项目的不同而进行不同的设计。一般都应包括检查条件、确认内容、确认日期等，并且要注意可读性和可实施性，便于测试者做测试数据，进行测试。4.4.5测试前期准备应确认的事项（1）开发环境和测试环境（2）确保必要的测试时间（表4.5举例说明了开发日程延后的对策处理方法。）4.4.5测试前期准备应确认的事项（3）留有余地的测试计划（回归测试）测试计划时，必须考虑如何利用测试工具等多种手段有效实施回归测试，并且制定出留有余地的测试计划，例如，制定精确的测试流程、有效利用测试工具、使测试尽可能自动化、留有回归测试的时间等。此外，因为变更、修正作业可能诱发新的错误，要根据测试中发现的问题的重要度、优先顺序进行问题管理和变更管理。例如，经判断，对于影响度低的问题，程序的修正可放在测试的最后阶段，由专人集中实施，以减少变更、修正的工作量和风险。4.4.5测试前期准备应确认的事项（4）系统的各个接口是测试工程的关注点 外部接口的测试，应尽量避免在系统测试和运行测试时才实施。最好是在程序开发工程期间内，即在单元测试阶段实施接口测试。最初测试时，只需要确认接口部分的动作，不必要完成系统整体的逻辑处理。为接口部分的处理准备简单的程序，专门的测试数据，测试接收和传送数据的效果。4.4.5测试前期准备应确认的事项在考虑测试计划、设计测试方案时要注意以下几点：（1）在设计工程期间要考虑组合测试计划书；（2）站在用户的立场考虑系统错误、缺陷造成的影响；（3）结合各种测试方法确定测试流程；（4）搭建必要的测试环境，确定测试工具；（5）将回归测试列入测试计划；（6）作测试计划时要考虑尽早实施接口测试。4.5测试的实施在作好测试计划的基础上，确认开发作业已基本完成，测试工具、数据、环境等已准备好，就可以进入测试作业。4.5.1各个测试阶段的测试设计和实施者单元测试一般由开发程序的程序员实施。组合测试由详细设计者和测试设计者实施。系统测试和运行测试一般由从事系统设计作业的系统工程师实施，而运行测试不仅仅是由承担开发项目的企业或部门实施，而且要以用户为主体实施。表4.6对各个测试阶段的计划、实施测试作业者给以了说明。4.5.2实施测试的要点1、实施测试前应确认的事项测试前必须确认系统是否进入测试状态。虽然各个测试阶段有不同的测试重点，但是对于作为测试对象的软件系统的核心部分，要尽早实施性能测试，即对软件系统的效率性进行测试。4.5.2实施测试的要点2、风险意识采用新技术、用户需求变更、开发人员的变动等都有可能带来风险。风险度=发生概率（发生频率）×发生时的影响程度（损失）每个开发人员在自己担任的作业中，都应该经常考虑有可能发生什么样的风险，一旦发现问题应及时与项目管理者商谈，尽可能避免和防止风险的发生。4.5.2实施测试的要点3、问题管理在测试中发现错误，修正程序，再测试，确认修正是否正确，这是一般测试作业的流程。表4.7处理问题的流程处理流程作业人员处理内容1发现问题测试人员记录测试中发现的问题，交给验证人员。2判断问题，确定修正方案验证人员分析问题，判断问题的重要度，确定修正方案和修正人员。3修正问题开发人员理解问题，修正程序，确认修正是否正确；记录问题发生的原因和修正的内容，交给验证人员。4确认修正内容，确定回归测试方案验证人员确认修正内容，确定对修正部分的回归测试方法和测试人员。5修正确认测试人员确认问题是否被修正，记录确认结果，交给验证人员。表4.7处理问题的流程：4.5.2实施测试的要点问题管理的要点如下：⑴设置专人进行问题管理，对发生的问题作最终判断；⑵对测试结果一定要有记录；⑶作成问题一览表，给每个问题编号，并记录问题解决的状况；⑷对发生的问题要立即记录，以免遗忘；⑸对问题的记录要注意语言简洁、明确、准确，同时要记录实施测试时的条件（如测试环境、测试流程、测试数据）；4.5.2实施测试的要点⑹如果感觉是很难再现的问题，应马上保留测试环境、测试数据等，以便分析原因；如果实施测试者判断是难以用文字表达的问题，要立即找开发人员或程序修正人员，现场说明；⑺问题发现者和处理者都要记录和判断问题的重要度；⑻问题处理者对记录的问题不明白、或认为没有必要修正程序时，要与测试人员联系、确认；对判断为不需要修正的问题，一定要说明理由；4.5.2实施测试的要点⑼修正错误之后。要记录发生问题的现象和修正的内容；⑽修正错误时要注意对同类问题的检查，不能在程序或系统的其它地方遗留同样的错误。4.5.2实施测试的要点4、问题记录表（简称B票）记录测试过程中发现的错误、问题。B票不仅仅是用于记录错误信息，还可以提供给质量管理人员、验收人员，作为追踪、分析、确认软件质量的原始资料，有利于改进和提高开发质量。4.5.2实施测试的要点根据统计规律，一般要求各个测试阶段发现的错误应占测试对象规模的一定比例，以确保测试的质量。4.5.2实施测试的要点B票主要记录如下内容：⑴发生错误的现象，如测试中发生功能遗漏、计算结果错误、打印错误等等；⑵产生错误的原因，如由于设计不良、理解错误、编程不良、测试数据错误等原因造成；⑶采取的对应措施，如修正设计书、程序、测试数据等；⑷发生设计书、程序修正时，记录其修正的范围。4.5.2实施测试的要点5、不再现问题 测试中常发生曾经出现而以后不在出现的问题，我们常称之为不再现问题。4.5.2实施测试的要点一类是问题发生时环境发生了改变，如：⑴测试数据有变化；⑵硬件发生变化；⑶数据库发生变化；⑷操作系统发生变化；⑸某个相关连的程序版本发生变化；⑹其他相关连程序发生故障；4.5.2实施测试的要点⑺受内存空间变化的影响；⑻受测试时间、日期变化的影响；⑼运行到某种程度时系统内部发生冲突；⑽系统状态发生变化（初期状态，多次运行状态）。上述的⑺～⑽项属于间歇性问题，发生的频度低，但修正很花时间。4.5.2实施测试的要点另一类是在完全相同的环境下，由于人为的原因引起的变化，如：⑴操作顺序发生变化；⑵测试人员未按测试流程进行作业；⑶测试人员变更；⑷无关人员触动了系统。4.5.2实施测试的要点在发生不再现问题时，首先要对引起不再现问题的原因进行分析。同时，向测试实施者确认测试时的状况，消除人为因素，尽可能在问题发生时的相同环境下进行再次测试，使问题再现。其次是收集、确认问题发生时的系统日志、程序日志，检查相关连的程序，反复测试使问题再现。4.5.2实施测试的要点6、测试中发现的错误的水平展开 对测试中发现的错误、缺陷，不能仅限于对该错误、缺陷的修正，要同时注意分析程序中是否有其它类似的问题；是自己的理解错误，还是编程习惯产生的错误；别的程序是否也有类似的错误等等。4.5.2实施测试的要点7、版本的管理明确发现的错误是在什么时间的程序版本上测试的。每个参加测试、修正程序的开发人员要充分理解开发项目的整体版本管理方法。4.5.2实施测试的要点8、提高测试工程的效率测试工程是需要花费整个开发工程的约25%～50%的工数的工程从外部设计阶段就开始考虑提高质量和测试规划，直到内部设计阶段考虑整体的测试方案，逐步形成周密的测试计划。4.5.2实施测试的要点9、防止系统在正式运行中出现故障在正式运行前，要尽可能在接近真实的数据量、网络环境、终端数量、集中使用密度等实际环境进行系统性能验证测试、负荷测试、耐力测试等。在正式运行前，还需要从系统的应用方面考虑编制操作手册，进行用户培训，建立技术支持体制。4.5.2实施测试的要点确保系统测试成功的一些要点⑴在充分理解用户业务流程的基础上设计测试流程；⑵在设计测试流程时设想用户容易发生的操作错误；⑶对参加测试的人员进行相关业务培训，使测试人员对用户业务有一定的了解；⑷确保系统测试必需要的时间和人员；⑸计划测试日程时要考虑回归测试的时间；⑹活用测试工具，提高测试效率；4.5.2实施测试的要点⑺系统测试以开发方为主体，用户为辅，并着手准备运行测试；⑻系统测试时尽可能使用接近真实的数据；⑼设想正式运行时系统的负荷进行耐力测试；⑽根据可靠性成长曲线（请参见中图4.24）判断测试的动向和进度，在出现异常曲线时采取适当的对策；⑾对发现的问题确定优先顺序，从优先顺序高的问题着手修正；⑿对测试发现的问题根据需要进行水平展开；⒀重视问题管理、设计变更管理和版本管理4.5.2实施测试的要点10、测试设计和实施测试中的注意事项表4.8说明了组合测试、系统测试和运行测试各个测试阶段的主要测试工作，以及开始和结束的条件。表4.9说明了各个测试阶段在测试设计和测试实施时一般应注意的一些主要问题。4.5.3从运行测试到实机运行

1、运行测试的主要特征⑴运行测试以使用者为主体⑵运行测试是进行业务测试4.5.3从运行测试到实机运行

2、运行测试的结束 在结束运行测试，进入实机运行时，必须是用户的所有与系统相关的人员都能够使用该系统。因此为了确保系统实机运行能够顺利进行，用户培训是非常必要的。一般在开发计划中应包括用户培训计划，准备与实际系统接近的培训系统，在运行测试阶段同时实施用户培训。4.5.3从运行测试到实机运行

从运行测试到实机运行作以下几点总结：①运行测试要以用户为主体进行设计、实施；②业务测试是在运行测试阶段实施，而不是在系统测试阶段实施；③在进行运行测试前作成操作手册；④尽早明确实机运行的评价基准；⑤运行测试的设计、实施要从技术、业务、环境等多方面考虑；⑥运行测试是用户培训的最好时机。4.5.4测试实例说明--单元测试测试策略单元测试一般总是把白盒测试法和黑盒测试法结合运用。先用黑盒测试法设计出一组基本的测试用例，然后用白盒测试法，根据覆盖标准补充新的测试用例以满足覆盖标准。一般情况下，单元测试以白盒法为主。4.5.4测试实例说明--单元测试主要工作：根据详细设计书作成单元测试使用的程序检测清单（PCL）

PCL有矩阵型PCL

和表格式PCL。无论哪种格式，都有检查项目、检查条件、确认内容、确认时间等基本内容。作成PCL的主要思路是针对详细设计书中的每个功能项目，列出其执行时需要的条件，确认在相对应的条件下应产生的结果。4.5.4测试实例说明--单元测试主要工作：根据详细设计书和PCL则可作成测试数据通常可以用一批数据来测试一个或几个PCL的检查项目，一般不采用一条数据测试一个或几个PCL。使用问题记录表（B票）记录在测试过程中程序发生错误和对错误进行处理的相关信息。对测试结果进行整理。在测试结果中需要注明测试的输入数据和输出数据，并标注相对应的PCL的检查项目编号。4.5.4测试实例说明--单元测试测试实例p120

程序检测清单（PCL）表4.11是一个矩阵型PCLp122表4.12是一个表格式PCLp123

测试数据

P121

问：要完成PCL中的所有测试项目的测试，应怎样补充测试 数据？问题记录表（B票）

P125

测试结果

P1264.5.4测试实例说明--组合测试组合测试需考虑的问题:

数据穿越接口可能丢失。一模块可能破坏另一模块功能。子功能组装可能未产生所要求的主功能。全程数据结构可能出问题。误差累积问题。测试策略由独立的测试小组进行测试用例通常采用黑盒法设计推进方式可采用渐增式或非渐增式模块组合后，应进行回归测试（采用软件改动前测试时执行过的测试用例对改动后的软件再进行测试。）4.5.4测试实例说明--组合测试主要工作：测试流程和测试计划。测试流程的作成，一般可以利用基本设计的各个子系统的数据流程图，按照各个子系统的输入参数，自顶向下设计测试流程。同时，要做好测试计划，落实各个子系统的测试期间、测试人员和验收人员。CCL。CCL的作成一般以各个子系统的相关联几个程序模块为单位进行。它主要检测各个程序模块之间的参数设置和传递是否正确，确认关联程序运行的最后结果。4.5.4测试实例说明--组合测试主要工作：测试数据。测试数据的作成要按照CCL的检查条件进行，一般要注意多个参数的各种组合条件的测试数据、数据记录条数(1条或多条)和特殊条件下的测试数据的做成。当然，基本数据文件（例如初期设定文件等），各种代码表的数据文件要事先准备好。4.5.4测试实例说明--组合测试主要工作：B票。组合测试阶段的B票作成方法与单元测试阶段的B票作成方法基本相同。其目的是要把测试过程中所发现的设计不良和程序错误记录到B票中，以保证快速有效地解决问题，提高程序系统的质量。测试结果。作成测试结果的目的首先是要使测试人员和验收人员按照CCL和测试结果对各个子系统的功能进行严格检查，其次是要证明所进行的组合测试是有效的。4.5.4测试实例说明--组合测试测试实例p127

程序检测清单（CCL）主要检测各个程序模块之间的参数设置和传递是否正确，确认关联程序运行的最后结果。表4.15CCL清单p128测试数据

P127

测试数据的作成要按照CCL的检查条件进行，一般要注意多个参数的各种组合条件的测试数据、数据记录条数(1条或多条)和特殊条件下的测试数据的做成。当然，基本数据文件（例如初期设定文件等），各种代码表的数据文件要事先准备好。

问题记录表（B票）

测试结果整理

P1294.6软件调试测试与调试的比较调试的步骤调试困难的原因调试策略软件测试与调试

测试与调试的比较

测试(test)调试(debug)以已知条件开始,使用预先定义的程序,有预知的结果以不可知内部条件开始,结果一般不可预见有计划被动的由独立的测试组，在不了解软件设计的条件下完成由程序作者进行发现错误找出错误位置，排除软件调试调试的步骤从错误的外部表现形式着手，确定出错位置；研究有关部分的程序，找出出错的内在原因；修改设计和代码，以排除有关错误；进行回归测试，以确认错误是否排除，是否引起新的错误；若不能通过回归测试，则撤消此次修改活动，恢复设计和代码至此次修改之前的状态，并重复上述过程，直到错误得以改正。软件调试调试困难的原因心理方面：高度焦虑、不愿接受可能发现的错误错误本身的特点错误症状和引起错误的原因相隔很远（高度耦合的程序结构）；错误症状可能在另一个错误被纠正后消失或暂时消失；错误症状可能实际并不是由错误引起的（如误差）；错误症状可能是由不易跟踪的人工操作引起的；软件调试调试困难的原因错误本身的特点(续)错误症状可能是和时间相关，而不是处理问题；很难再现错误症状的输入条件；错误症状可能时有时无（如在软硬件结合的嵌入式系统中）错误症状可能是由于把任务分布在若干不同处理器上运行而造成软件调试调试策略猜测法通过分析错误症状，根据以往的经验，辅助使用已有的计算机工具，猜测错误的原因并进行定位。在程序中插入打印语句使用注释或GOTO语句运行部分程序使用调试工具软件调试调试策略跟踪法检查错误征兆，确定最先发现错误“症状”的位置，然后人工沿程序的控制流往回跟踪源代码，直到找出错误的根源；也可以向前跟踪每条语句的执行情况，找到最先出现错误的地方进行分析软件调试调试策略原因排除法:先假定错误原因，然后利用数据证明或否定假设（归纳法）；或先列出所有可能的原因，然后逐一排除。（演绎法）收集有关数据组织数据研究数据间的关系提出假设证明假设纠正错误不能不能能能归纳法调试的过程软件调试调试策略原因排除法:先假定错误原因，然后利用数据证明或否定假设（归纳法）；或先列出所有可能的原因，然后逐一排除。（演绎法）列举可能原因排除不会发生的原因收集更多的测试结果分析余下的原因证明假设纠正错误无剩余有剩余能不能演绎法调试过程4.7软件质量与测试工程