《软件工程》第八章学习辅导.docx
《《软件工程》第八章学习辅导.docx》由会员分享，可在线阅读，更多相关《《软件工程》第八章学习辅导.docx（10页珍藏版）》请在冰点文库上搜索。
《软件工程》第八章学习辅导
《软件工程》第八章学习辅导
————————————————————————————————作者：
————————————————————————————————日期：
《软件工程》第八章学习辅导
在开发软件的过程中，为了保证软件质量必须认真计划、彻底地进行软件测试。
8.1软件测试的基础
8.1.1什么是软件测试
软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
如果给软件测试下定义，可以这样讲：
软件测试是为了发现错误而执行程序的过程。
或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果，并利用这些测试用例去运行程序，以发现程序错误的过程。
软件测试在软件生存期中横跨两个阶段：
通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。
编码与单元测试属于软件生存期中的同一个阶段。
在结束这个阶段之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段。
8.1.2软件测试的目的和原则
基于不同的立场，存在着两种完全不同的测试目的。
从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。
而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。
因此，他们会选择那些导致程序失效概率小的测试用例，回避那些易于暴露程序错误的测试用例。
同时，也不会着意去检测、排除程序中可能包含的副作用。
显然，这样的测试对完善和提高软件质量毫无价值。
因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。
如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。
如果站在用户的角度，替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。
软件测试目的：
（1）测试是程序的执行过程，目的在于发现错误；
（2）一个好的测试用例在于能发现至今未发现的错误，
（3）一个成功的测试是发现了至今未发现的错误的测试。
测试的目标是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。
如果成功地实施了测试，就能够发现软件中的错误。
测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。
此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。
根据这样的测试目的，软件测试的原则应该是：
（1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
由于原始问题的复杂性，软件的复杂性和抽象性，软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。
所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。
坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。
（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。
测试以前应当根据测试的要求选择在测试过程中使用的测试用例（Testcase）。
测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。
如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。
（3）程序员应避免检查自己的程序。
测试工作需要严格的作风，客观的态度和冷静的情绪。
人们常由于各种原因具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事。
这一心理状态就成为测试自己程序的障碍。
另外，程序员对软件规格说明理解错误而引入的错误则更难发现。
如果由别人来测试程序员编写的程序，可能会更客观，更有效，并更容易取得成功。
要注意的是，这点不能与程序的调试（debuging）相混淆。
调试由程序员自己来做可能更有效。
（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。
在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。
事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户在键盘上按错了键或打入了非法的命令。
如果开发的软件遇到这种情况时不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。
因此，软件系统处理非法命令的能力也必须在测试时受到检验。
用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。
（5）充分注意测试中的群集现象。
测试时不要以为找到了几个错误问题就已解决，不需继续测试了。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。
根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。
在所测程序段中，若发现错误数目多，则残存错误数目也比较多。
这种错误群集性现象，己为许多程序的测试实践所证实。
如果发现某一程序模块似乎比其他程序模块有更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。
（6）严格执行测试计划，排除测试的随意性。
测试计划应包括：
所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，调试规程，以及回归测试的规定等以及评价标准。
对于测试计划，要明确规定，不要随意解释。
（7）应当对每一个测试结果做全面检查。
这是一条最明显的原则，但常常被忽视。
有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。
所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。
（8）妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
8.1.3软件测试的对象
软件测试并不等于程序测试。
软件测试应贯穿于软件定义与开发的整个期间。
因此，需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。
软件测试不应仅限在程序测试的狭小范围内，而置其他阶段的工作于不顾。
另一方面，由于定义与开发各阶段是互相衔接的，前一阶段工作中发生的问题如未及时解决，很自然要影响到下一阶段。
从源程序的测试中找到的程序错误不一定都是程序编写过程中造成的。
如果简单地把程序中的错误全都归罪于程序员，未免冤枉他们。
事实上，到程序的测试为止，软件开发工作已经经历了许多环节，每个环节都可能发生问题。
为了把握各个环节的正确性，人们需要进行各种确认和验证工作。
确认（Validation）是一系列的活动和过程，其目的是想证实在一个给定的外部环境中软件的逻辑正确性。
它包括需求规格说明的确认和程序的确认，而程序的确认又分为静态确认与动态确认。
静态确认一般不在计算机上实际执行程序，而是通过人工分析或者程序正确性证明来确认程序的正确性；动态确认主要通过动态分析和程序测试来检查程序的执行状态，以确认程序是否有问题。
验证（Verification）则试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。
确认与验证工作都属于软件测试。
在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表现出来。
8.1.4测试信息流
测试过程需要三类输入
（1）软件配置：
包括软件需求规格说明、软件设计规格说明、源代码等；
（2）测试配置：
包括测试计划、测试用例、测试驱动程序等。
实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。
（3）测试工具：
为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻人们完成测试任务中的手工劳动。
测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。
如果发现出错的数据，就意味着软件有错误，然后就需要开始排错（调试）。
即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。
修正后的文档一般都要经过再次测试，直到通过测试为止。
排错的过程是测试过程中最不可预知的部分。
也正是因为排错中的这种固有的不确定性，使得我们很难定出可靠的测试进度。
通过收集和分析测试结果数据，开始针对软件建立可靠性模型。
如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。
如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：
或者是软件的质量和可靠性达到可以接受的程度，或者是所做的测试不足以发现严重的错误。
如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。
这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。
但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。
8.1.5测试与软件开发各阶段的关系
软件开发过程是一个自顶向下，逐步细化的过程，首先在软件计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束和一些有效性准则。
接着进入软件开发，首先是软件设计，然后再把设计用某种程序设计语言转换成程序代码。
而测试过程则是依相反的顺序安排的自底向上，逐步集成的过程。
低一级测试为上一级测试准备条件。
当然不排除两者平行地进行测试。
8.2测试用例设计
8.2.1黑盒测试
任何工程产品都可以使用以下的两种方法之一进行测试：
（1）已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
（2）已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。
前者就是黑盒测试，后者就是白盒测试。
就软件测试来讲，软件的黑盒测试意味着测试要在软件的接口处进行。
也就是说，这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
因此黑盒测试又叫做功能测试或数据驱动测试。
黑盒测试主要是为了发现以下几类错误：
·是否有不正确或遗漏了的功能?
·在接口上，输入能否正确地接受?
能否输出正确的结果?
·是否有数据结构错误或外部信息（例如数据文件）访问错误?
·性能上是否能够满足要求?
·是否有初始化或终止性错误?
所以，用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。
8.2.2白盒测试
软件的白盒测试是对软件的过程性细节做细致的检查。
这一方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
因此白盒测试又称为结构测试或逻辑驱动测试。
软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：
·对程序模块的所有独立的执行路径至少测试一次；
·对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次；
·在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性，等等。
在测试阶段既然穷举测试不可行，为了节省时间和资源，提高测试效率，就必须精心设计测试用例，也就是要从数量极大的可用测试用例中精心地挑选少量的测试数据，使得采用这些测试数据能够达到最佳的测试效果，或者说它们能够高效率地把隐藏的错误揭露出来。
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。
由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在发现错误时能说明程序有问题；但在未发现错误时，不能说明程序中没有错误，不能说明程序中没有问题。
8.3白盒测试的测试用例设计
8.3.1逻辑覆盖
逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术，属白盒测试。
这一方法要求测试员对程序的逻辑结构有清楚的了解。
由于覆盖测试的目标不同，逻辑覆盖可分为：
语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖及路径覆盖。
8.3.2基本路径测试
基本路径测试就是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。
8.4黑盒测试的测试用例设计
8.4.1等价类划分
等价类划分是一种典型的黑盒测试方法，也是一种非常实用的重要测试方法。
使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
如前所述，用所有可能输入的数据来测试程序是不可能的，只能从全部可供输入的数据中选择一个子集进行测试。
如何选择适当的子集，使其尽可能多地发现错误。
一种解决的办法就是等价类划分。
该方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。
8.4.2边界值分析
边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
8.4.3错误推测法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。
这就是错误推测法。
8.4.4因果图
要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，它们之间的组合情况也相当多。
因此必须考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种组合情况。
8.4.5功能图
功能图方法是一种黑盒测试方法。
它用功能图FD（FunctionalDiagram）形式化地表示程序的功能说明，并机械地生成功能图的测试用例。
8.5软件测试的策略
测试过程按4个步骤进行，即单元测试、组装（集成）测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
然后，把已测试过的模块组装起来，进行组装测试，主要对与设计相关的软件体系结构的构造进行测试。
为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。
严格地说，系统测试已超出了软件工程的范围。
8.6程序的静态分析方法
程序的静态分析不要求在计算机上实际执行所测程序，而是以一些人工的模拟技术和一些类似动态分析所使用的方法对程序进行分析和测试
8.7调试（Debug，排错）
软件调试则是在进行了成功的测试之后才开始的工作。
它与软件测试不同，测试的目的是尽可能多地发现软件中的错误。
进一步诊断和改正程序中潜在的错误，则是调试的任务。
调试活动由两部分组成：
（1）确定程序中可疑错误的确切性质和位置。
（2）对程序（设计，编码）进行修改，排除这个错误。
通常，调试工作是一个具有很强技巧性的工作。
一个软件人员在分析测试结果的时候会发现，软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部表现与内在原因之间常常没有明显的联系。
如果要找出真正的原因，排除潜在的错误，不是一件易事。
因此可以说，调试是通过现象，找出原因的一个思维分析的过程。
8.8软件测试工具
测试工作在软件开发的整个过程中占有极重要的位置，而人工测试又特别困难，所以测试过程的自动化成为测试的发展方向。
升级会员 