系统实现与维护.ppt

第七章 系统实现与维护,7.1 系统实施的任务 7.2 程序设计语言的分类 7.3 程序设计语言的选择 7.4 程序设计风格 7.5 系统测试基础 7.6 单元测试 7.7 集成测试 7.8 确认测试 7.9 测试技术 7.10 软件调试 7.11 软件维护,2019/7/26,第7章 系统实现与维护,2,绪言,系统设计完成后进入系统实施阶段。系统实施就是将系统分析和设计的结果转换为能够在计算机上实际运行的系统的过程，属于系统开发周期的后期阶段。 本章的主要内容有： 系统实施的任务、特点和方法； 程序设计的原则、标准和方法； 软件开发工具； 系统测试的原则、内容和方法； 系统转换的主要方式和工作等。,2019/7/26,第7章 系统实现与维护,3,7.1 系统实施的任务,系统实施的任务就是以系统设计方案为依据，按照系统实施方案进行具体的实现，最终组建一个能够实际运行的系统交付用户使用。实现阶段的任务和工作内容包括以下4个方面： 硬件准备； 软件准备 人员培训； 数据准备。,2019/7/26,第7章 系统实现与维护,4,7.1 系统实施的任务,系统实施的特点 系统实施是管理信息系统开发工作的后期阶段，是一项涉及各级管理人员、系统开发技术人员、系统测试人员、系统操作和维护人员的组织协调，以及系统应用场地、设备和资金的调配管理，持续时间长且十分复杂的系统工程。工作量大，投入的人力、物力多，组织管理工作繁重是其主要特点。,2019/7/26,第7章 系统实现与维护,5,7.2 程序设计语言分类,按应用特点分类 面向机器语言（机器语言和汇编语言） 高级语言 基础语言（BASIC、Fortran） 现代语言（Pascal、C、C+） 专用语言（Lisp、Prolog） 按语言内在特点分类 系统实现语言 静态高级语言 块结构高级语言 动态高级语言,2019/7/26,第7章 系统实现与维护,6,7.3 程序设计语言的选择,理想标准 应该有理想的模块化机制，以及可读性好的控制结构和数据结构，以使程序容易测试和维护，同时减少软件生存周期的总成本。 应有良好的独立编译机制，以降低软件开发和维护的成本。 应该使编译程序能够尽可能多地发现程序中的错误，以便于调试和提高软件的可靠性。,2019/7/26,第7章 系统实现与维护,7,7.3 程序设计语言的选择,实践标准 语言自身的功能 系统用户的要求 编码和维护成本 软件的兼容性 可以使用的软件工具 软件的可移植性 开发系统的规模 程序设计人员的水平,2019/7/26,第7章 系统实现与维护,8,7.4 程序设计风格,编码阶段的任务是把详细设计阶段中用伪代码写成的程序转换成用程序设计语言实现的程序。 程序设计语言的特性和程序设计风格会深刻地影响软件的质量和可维护性。 为保证编码的质量，程序员必须深刻理解、熟练掌握并正确地运用程序设计语言的特性。此外，还要求源程序具有良好的结构性和良好的程序设计风格。,2019/7/26,第7章 系统实现与维护,9,7.4 程序设计风格,好程序的代码逻辑简明清晰、易读易懂： 程序的内部文档； 数据说明； 语句构造； 输入输出方法；,2019/7/26,第7章 系统实现与维护,10,7.4 程序设计风格,程序的内部文档 标识符的命名： 标识符即符号名，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。 这些名字应能反映它所代表的实际东西，应有一定实际意义。 名字不是越长越好，应当选择精炼的意义明确的名字。 必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。 在一个程序中，一个变量只应用于一种用途。,2019/7/26,第7章 系统实现与维护,11,7.4 程序设计风格,程序的内部文档 C#、Java等语言编码命名规范对字段、变量、类、方法和属性等指定了统一的命名形式： 类名、方法名和属性名均使用Pascal命名法，即所有单词连写，每个单词的第一个字母大写，其它字母小写。 例如：GetData、HelloWorld等。 变量名、对象名以及方法的参数名均使用Camel命名法，即所有单词连写，第一个单词全部小写，其它每个单词的第一个字母大写。 例如：userName、userAge等等。,2019/7/26,第7章 系统实现与维护,12,7.4 程序设计风格,这里需要强调一点，对于一名合格的程序员来说，不论是练习还是实际开发，一定不要养成随意命名的坏习惯。良好的命名习惯会给项目开发带来很多益处。,2019/7/26,第7章 系统实现与维护,13,7.4 程序设计风格,程序的内部文档 程序的注释： 夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。 注释决不是可有可无的。 一些正规的程序文本中，注释行的数量占到整个源程序的13到12，甚至更多。 注释分为序言性注释和功能性注释。,2019/7/26,第7章 系统实现与维护,14,7.4 程序设计风格,序言性注释： 通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。,2019/7/26,第7章 系统实现与维护,15,7.4 程序设计风格,序言性注释有关项目包括： 程序标题； 有关本模块功能和目的的说明； 主要算法； 接口说明：包括调用形式，参数描述，子程序清单； 有关数据描述：重要的变量及其用途，约束或限制条件，以及其它有关信息； 模块位置：在哪一个源文件中，或隶属于哪一个软件包； 开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。,2019/7/26,第7章 系统实现与维护,16,7.4 程序设计风格,功能性注释： 功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句而会怎么样。而不要解释下面怎么做。,2019/7/26,第7章 系统实现与维护,17,7.4 程序设计风格,程序的内部文档： 视觉组织 空格、空行和缩进。 恰当地利用空格，可以突出运算的优先性。 自然的程序段之间可用空行隔开。 缩进也叫做向右缩格或移行。它是指程序中的各行不必都在左端对齐，都从第一格起排列。这样做使程序完全分不清层次关系。 对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。使程序的逻辑结构更加清晰。,2019/7/26,第7章 系统实现与维护,18,7.4 程序设计风格,数据说明 在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。 为了使程序中数据说明更易于理解和维护，必须注意以下几点： 数据说明的次序应当规范化； 说明语句中变量安排有序化； 使用注释说明复杂数据结构。,2019/7/26,第7章 系统实现与维护,19,7.4 程序设计风格,数据说明的次序应当规范化： 数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护 。 原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。 例如，在类型说明中可按如下顺序排列： 整型量说明 实型量说明 字符量说明 逻辑量说明,2019/7/26,第7章 系统实现与维护,20,7.4 程序设计风格,说明语句中变量安排有序化 当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。 例如： 把integer size, length, width, cost, price 写成 integer cost, length, price , size, width,2019/7/26,第7章 系统实现与维护,21,7.4 程序设计风格,使用注释说明复杂数据结构 如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的特点。,2019/7/26,第7章 系统实现与维护,22,7.4 程序设计风格,语句构造 在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。 在一行内只写一条语句。 避免采用过于复杂的条件测试。 尽量减少“非” 条件的测试。 避免大量使用循环嵌套和条件嵌套。 利用括号使逻辑表达式或算术表达式的运算次序清晰直观。 除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二。,2019/7/26,第7章 系统实现与维护,23,7.4 程序设计风格,语句构造 比较下面两段代码，哪一段更好？,AI = AI AT; AT = AI AT; AI = AI AT;,WORK = AT; AT = AI; AI = WORK;,2019/7/26,第7章 系统实现与维护,24,7.4 程序设计风格,语句构造 程序要能直截了当地说明程序员的用意。 比较下面两段代码，哪一段更好？,for ( i = 1; i = n; i+ ) for ( j = 1; j = n; j+ ) Vij = ( i j ) * ( j i )；,for ( i=1; i = n; i+ ) for ( j=1; j = n; j+ ) if ( i = j ) Vij = 1; else Vij = 0;,2019/7/26,第7章 系统实现与维护,25,7.4 程序设计风格,语句构造 首先要保证程序正确,然后才要求提高速度。反过来说，在使程序高速运行时，首先要保证它是正确的。 让编译程序做简单的优化。 尽可能使用库函数。 避免使用临时变量而使可读性下降。 避免不必要的转移。同时如果能保持程序可读性，则不必用GOTO语句。 尽量只采用三种基本的控制结构来编写程序。 避免使用空的ELSE语句和IF THEN语句。这种结构容易使读者产生误解。 “如果我不是编码的人，那么能看懂它吗？”,2019/7/26,第7章 系统实现与维护,26,7.4 程序设计风格,输入与输出 关于输入和输出有下列的启发规则： 对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性； 检查输入项的各种重要组合的合理性，必要时报告输入状态信息； 使得输入的步骤和操作尽可能简单，并保持简单的输入格式； 输入数据时，应允许使用自由格式输入； 应允许缺省值； 输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；,2019/7/26,第7章 系统实现与维护,27,7.4 程序设计风格,输入与输出 关于输入和输出有下列的启发规则： 在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息； 当程序设计语言对输入输出格式有严格要求时，应保持输入格式与输入语句要求的一致性； 给所有的输出加注解，并设计输出报表格式。输入输出风格还受到许多其它因素的影响。如输入输出设备（例如终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。,2019/7/26,第7章 系统实现与维护,28,7.4 程序设计风格,程序效率的准则 效率是一个性能要求，目标值应当在需求分析阶段给出，软件效率应以需求为准。 好的软件设计可以提高效率。 程序的效率与程序的简单性相关。,2019/7/26,第7章 系统实现与维护,29,7.4 程序设计风格,算法对效率的影响 尽可能简化相关的表达式； 仔细检查算法中的嵌套循环，将某些语句移到循环外； 尽量避免使用多维数组； 尽量避免使用指针和复杂的表达式； 采用“快速”的算术运算； 不要混淆数据结构，避免类型混杂； 尽量采用整数算术表达式和布尔表达式； 选用高效算法；,2019/7/26,第7章 系统实现与维护,30,7.5 系统测试基础,软件测试目的： 测试是程序的执行过程，目的在于发现错误； 一个好的测试用例在于能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。,2019/7/26,第7章 系统实现与维护,31,7.5 系统测试基础,软件测试的准则： 所有测试都应该能追溯到用户需求。 应该远在测试开始之前就制定出测试计划 。 把Pareto原理应用到软件测试中。Pareto原理说明，测试发现的错误中的80很可能是由程序中20的模块造成的。 应该从“小规模”测试开始，并逐步进行“ “大规模”测试。 穷举测试是不可能的。 为了达到最佳的测试效果，应该由独立的第三方从事测试工作。,2019/7/26,第7章 系统实现与维护,32,7.5 系统测试基础,软件测试步骤： 模块测试（单元测试）： 把每个模块作为一个单独的实体来测试，发现的往往是编码和详细设计的错误。 子系统测试（集成测试）： 把经过单元测试的模块放在一起形成一个子系统来测试，着重测试模块的接口。 系统测试（集成测试）： 把经过测试的子系统装配成一个完整的系统来测试。发现的往往是软件设计中的错误，也可能发现需求说明中的错误。,2019/7/26,第7章 系统实现与维护,33,7.5 系统测试基础,软件测试步骤： 验收测试（确认测试）： 把软件系统作为单一的实体进行测试，是在用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。目的是验证系统确实能够满足用户的需要。发现的往往是系统需求说明书中的错误。 平行运行： 是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。 这样做的具体目的有如下几点： 可以在准生产环境中运行新系统而又不冒风险；用户能有一段熟悉新系统的时间；可以验证用户指南和使用手册之类的文档；能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。,2019/7/26,第7章 系统实现与维护,34,7.5 系统测试基础,2019/7/26,第7章 系统实现与维护,35,7.5 系统测试基础,测试阶段的信息流程： 软件配置：软件需求规格说明、软件设计规格说明、源代码等； 测试配置：测试计划、测试方案、测试数据等； 测试结果分析：比较实测结果与预期结果，评价错误是否发生。 排错(调试) ：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。,2019/7/26,第7章 系统实现与维护,36,7.6 单元测试,测试重点： 模块接口。主要检查下述几个方面： 参数的数目、次序、属性或单位系统与变元是否一致； 是否修改了只作输入用的变元； 全局变量的定义和用法在各个模块中是否一致。 局部数据结构：发现局部数据说明、初始化、默认值等方面的错误。 重要的执行通路：选择最有代表性、最可能发现错误的执行通路进行测试。,2019/7/26,第7章 系统实现与维护,37,7.6 单元测试,测试重点： 出错处理通路。当评价出错处理通路时，应该着重测试下述一些可能发生的错误： 对错误的描述是难以理解的； 记下的错误与实际遇到的错误不同； 在对错误进行处理之前，错误条件已经引起系统干预 ； 对错误的处理不正确； 描述错误的信息不足以帮助确定造成错误的位置 。,2019/7/26,第7章 系统实现与维护,38,7.6 单元测试,测试重点： 边界条件。 软件常常在它的边界上失效 。 使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。,2019/7/26,第7章 系统实现与维护,39,7.6 单元测试,代码检测 由审查小组对源程序正式进行人工测试。 审查之前，小组成员应该先研究设计说明书，力求理解这个设计。 审查会上倾听程序编写者的解释，并力图发现其中的错误。 对照类似于上一小节中介绍的程序设计常见错误清单，分析审查这个程序。 预排：由一个人扮演“测试者”，其他人扮演“计算机”。,2019/7/26,第7章 系统实现与维护,40,7.7 集成测试,测试重点： 恢复测试：通过各种方式强制地让系统发生故障并验证其能适当恢复的一种测试。（初始化、重启、平均恢复时间等等） 安全测试：验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。 压力测试：以一种要求反常数量、频率和容量的方式执行系统。 性能测试：常与压力测试一起进行，需要软件和硬件配合。,2019/7/26,第7章 系统实现与维护,41,7.7 集成测试,代表工具： OTF：由MCG Software开发 QADirector：由Compuware Crop开发 TestWorks：由Software Research开发，包含完整的、集成的成套测试工具，包括测试管理和测试报告。 C+Test：是一个单元测试工具，用于C或C+代码测试。 CodeMedic、BugColllector Pro、GNATS,2019/7/26,第7章 系统实现与维护,42,7.7 集成测试,集成测试是测试和组装软件的系统化技术。 由模块组装成程序时有两类方法： 非渐增式测试：先分别测试每个模块，再一下子把所有模块按设计要求放在一起结合成所要的程序。 渐增式测试：把下一个要测试的模块同已测试好的那些模块结合起来进行测试，依次类推，每次增加一个模块。这种方法实质上同时完成单元测试和集成测试。,2019/7/26,第7章 系统实现与维护,43,7.7 集成测试,2019/7/26,第7章 系统实现与维护,44,7.7 集成测试,四种集成策略： 一次性集成 自顶向下集成 自底向上集成 三明治集成,2019/7/26,第7章 系统实现与维护,45,7.8 确认测试,确认测试目标是验证软件的有效性。 软件有效性的简单定义：如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的。 因此，需求阶段产生的需求规格说明书或类似文档是软件有效性的标准，也是进行确认测试的基础。 确认测试以用户为主来进行。,2019/7/26,第7章 系统实现与维护,46,7.8 确认测试,确认测试的范围 保证软件能满足所有功能要求。 能达到每个性能要求。 文档资料是准确而完整的。 应该保证软件能满足其他预定的要求（例如，安全性、可移植性、兼容性和可维护性等）。,2019/7/26,第7章 系统实现与维护,47,7.8 确认测试,软件配置复查 复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。 在确认测试过程中应该严格遵循用户手册及其他操作程序的说明和要求，从而检验用户使用手册的完整性和正确性。,2019/7/26,第7章 系统实现与维护,48,7.8 确认测试,Alpha 和Beta测试 Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。 开发者负责记录发现的错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。 Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。,2019/7/26,第7章 系统实现与维护,49,7.9 测试技术,白盒测试：把测试对象看做一个透明盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序的所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。白盒测试又称为结构测试或逻辑驱动测试。 黑盒测试：把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。,2019/7/26,第7章 系统实现与维护,50,7.9.1 白盒测试技术,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查： 对程序模块的所有独立的执行路径至少测试一次； 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次； 在循环的边界和运行界限内执行循环体； 测试内部数据结构的有效性等； “错误潜伏在角落里，聚集在边界上”,2019/7/26,第7章 系统实现与维护,51,7.9.1 白盒测试技术,逻辑覆盖：逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。 语句覆盖； 判定覆盖； 条件覆盖； 判定/条件覆盖； 条件组合覆盖； 点覆盖； 边覆盖； 路径覆盖；,2019/7/26,第7章 系统实现与维护,52,7.9.1 白盒测试技术,语句覆盖：语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 判断覆盖：判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判定的取真分支和取假分支至少经历一次。 判定覆盖又称为分支覆盖。 条件覆盖：条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判定中的每个条件的可能取值至少执行一次。,2019/7/26,第7章 系统实现与维护,53,7.9.1 白盒测试技术,判定/条件覆盖：选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。 条件组合覆盖：条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判定中条件的所有可能组合至少出现一次。 满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定条件覆盖标准。因此，条件组合覆盖是前述几种覆盖标准中最强的。但是，满足条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。,2019/7/26,第7章 系统实现与维护,54,7.9.1 白盒测试技术,点覆盖：要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次，由于流图的每个结点与一条或多条语句相对应，显然，点覆盖标准和语句覆盖标准是相同的。 边覆盖：要求选取足够多测试数据，使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。 路径覆盖：路径覆盖就是设计足够的测试用例，程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至少经过一次)。,2019/7/26,第7章 系统实现与维护,55,7.9.2 黑盒测试技术,黑盒测试力图发现下述类型的错误： 功能不正确或遗漏了功能； 界面错误； 数据结构错误或外部数据库访问错误； 性能错误； 初始化和终止错误。 黑盒测试法与白盒测试法不能互相代替，两者应互为补充。,2019/7/26,第7章 系统实现与维护,56,7.9.2 黑盒测试技术,黑盒测试的主要方法有： 等价划分； 边界值分析； 错误推测； 因果图。,2019/7/26,第7章 系统实现与维护,57,7.9.2 黑盒测试技术,等价值划分 等价划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。 等价类的划分有两种不同的情况： 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。,2019/7/26,第7章 系统实现与维护,58,7.9.2 黑盒测试技术,划分等价类的原则： 如果输入条件规定了取值范围或值的个数，则可以确立一个有效等价类和两个无效等价类。 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。 如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。,2019/7/26,第7章 系统实现与维护,59,7.9.2 黑盒测试技术,划分等价类的原则： 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 如果规定了输入数据为整型，则可以划分出正整数、零和负整数等3个有效类。 如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。,2019/7/26,第7章 系统实现与维护,60,7.9.2 黑盒测试技术,确定测试用例 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止； 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。,2019/7/26,第7章 系统实现与维护,61,7.9.2 黑盒测试技术,等价划分实例： 假设有一个把数字串转变成整数的函数。被处理的数字串是右对齐的，也就是说，如果数字串比6个字符短，则在它的左边补空格。如果数字串是负的，则负号和最高位数字紧相邻(负号在最高位数字左边一位) 。且只能转化-3276832767之间的整数。,2019/7/26,第7章 系统实现与维护,62,7.9.2 黑盒测试技术,分析这个程序的规格说明，划分出有效输入的等价类有： l6个数字字符组成的数字串(最高位数字不是零)； 最高位数字是零的数字串； 最高位数字左邻是负号的数字串；,2019/7/26,第7章 系统实现与维护,63,7.9.2 黑盒测试技术,无效输入的等价类有： 空字符串(全是空格)； 左部填充的字符既不是零也不是空格； 最高位数字右面由数字和空格混合组成； 最高位数字右面由数字和其他字符混合组成； 负号与最高位数字之间有空格；,2019/7/26,第7章 系统实现与维护,64,7.9.2 黑盒测试技术,合法输出的等价类有： 在计算机能表示的最小负整数和零之间的负整数； 零； 在零和计算机能表示的最大正整数之间的正整数； 非法输出的等价类有： 比计算机能表示的最小负整数还小的负整数； 比计算机能表示的最大正整数还大的正整数。,2019/7/26,第7章 系统实现与维护,65,7.9.2 黑盒测试技术,根据上面划分出的等价类，可以设计出下述测试方案： 16个数字组成的数字串，输出是合法的正整数。 输入：1 预期的输出：1。 最高位数字是零的数字串，输出是合法的正整数。 输入：00000l 预期的输出：1,2019/7/26,第7章 系统实现与维护,66,7.9.2 黑盒测试技术,最高位是负号的数字串，输出是合法的负整数。 输入：-1 预期的输出：-1。 全部是零，输出也是零。 输入：000000 预期的输出： 预期的输出：0 太小的负整数。 输入：-67561 预期的输出：“错误 无效输入” 太大的正整数。 输入：132767 预期的输出：“错误 无效输入”,2019/7/26,第7章 系统实现与维护,67,7.9.2 黑盒测试技术,空字符串。 输入： 预期的输出：“ 错误 没有数字” 字符串左部字符既不是零也不是空格 输入：XXXXXl 预期的输出：“错误填充错” 最高位数字后面有空格。 输入：1 2 预期的输出：“错误 无效输入”,2019/7/26,第7章 系统实现与维护,68,7.9.2 黑盒测试技术,最高位数字后面有其他字符。 输入：1XX2 预期的输出：“错误无效输入” 负号和最高位数字之间有空格。 输入： - 12 预期的输出：“错误负号位置错”,2019/7/26,第7章 系统实现与维护,69,7.9.2 黑盒测试技术,边界值分析 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。,2019/7/26,第7章 系统实现与维护,70,7.9.2 黑盒测试技术,补充下述测试方案： 使输出刚好等于最小的负整数。 输入： -32768 预期的输出为：-32768 使输出刚好等于最大的正整数。 输入：32767 预期的输出：32767 原来用等价划分法设计出来的测试方案5最好改为：使输出刚刚小于最小的负整数。 输入： -32769 预期的输出：“错误无效输入”,2019/7/26,第7章 系统实现与维护,71,7.9.2 黑盒测试技术,补充下述测试方案： 原来的测试方案6最好改为：使输出刚刚大于最大的正整数。 输入： 32768 预期的输出：“错误无效输入”,2019/7/26,第7章 系统实现与维护,72,7.9.2 黑盒测试技术,错误推测法 人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。 错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。,2019/7/26,第7章 系统实现与维护,73,7.9.2 黑盒测试技术,Myers提出了使用各种测试方法的综合策略: 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。 必要时用等价类划分方法补充一些测试用例。 用错误推测法再追加一些测试用例。 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。,2019/7/26,第7章 系统实现与维护,74,7.10 软件调试技术,软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。,2019/7/26,第7章 系统实现与维护,75,7.10 软件调试技术,从技术角度来看，查找错误的难度在于： 现象与原因所处的位置可能相距甚远。 当其它错误得到纠正时，这一错误所表现出的现象可能会暂时消失，但并未实际排除。 现象实际上是由一些非错误原因(例如，舍入不精确 )引起的。 现象可能是由于一些不容易发现的人为错误引起的。 错误是由于时序问题引起的，与处理过程无关。 现象是由于难于精确再现的输入状态（例如，实时应用中输入顺序不确定）引起。 现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。 现象可能是由分布在许多任务中的原因引起的，这些任务运行在不同的处理机上。,2019/7/26,第7章 系统实现与维护,76,7.10 软件调试技术,几种主要的调试方法 蛮干法：这种调试方法目前使用较多，效率较低。它不需要过多的思考，比较省脑筋。 例如： 通过内存全部打印来调试； 在程序特定部位设置打印语句；,2019/7/26,第7章 系统实现与维护,77,7.10 软件调试技术,几种主要的调试方法 回溯法调试 这是在小程序中常用的一种有效的调试方法。一旦发现了错误，人们先分析错误征兆，确定最先发现“ 症状” 的位置。 人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。,2019/7/26,第7章 系统实现与维护,78,7.10 软件调试技术,原因排除法 对分查找法 如果已经知道每个变量在程序内若干个关键点的正确值，则可以用赋值语句或输入语句在程序中点附近 “注入”这些变量的正确值，然后运行程序并检查所得到的输出。如果输出结果是正确的，则错误原因在程序的前半部分；反之，错误原因在程序的后半部分。对错误原因所在的那部分再重复使用这个方法，直到把出错范围缩小到容易诊断的程度为止。,2019/7/26,第7章 系统实现与维护,79,7.10 软件调试技术,原因排除法 归纳法 是从个别现象推断出一般性结论的思维方法。使用这种方法调试程序时，首先把和错误有关的数据组织起来进行分析，以便发现可能的错误原因。然后导出对错误原因的一个或多个假设，并利用已有的数据来证明或排除这些假设。当然，如果已有的数据尚不足以证明或排除这些假设，则需设计并执行一些新的测试用例，以获得更多的数据。,2019/7/26,第7章 系统实现与维护,80,7.10 软件调试技术,原因排除法 演绎法 是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员首先根据已有的测试用例，设想及枚举出所有可能出错的原因做为假设；然后再用原始测试数据或新的测试，从中逐个排除不可能正确的假设；最后，再用测试数据验证余下的假设确是出错的原因。,2019/7/26,第7章 系统实现与维护,81,7.10 软件调试技术,在动手改正错误之前，软件工程师应该仔细考虑下述3个问题： 是否同样的错误也在程序其他地方存在? 将要进行的修改可能会引入的“下一个错误” 是什么? 为防止今后出现类似的错误，应该做什么?,2019/7/26,第7章 系统实现与维护,82,7.11 软件维护,软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 软件维护的分类： 改正性维护（Corrective maintenance） 适应性维护（Adaptive maintenance） 完善性维护（Perfective maintenance） 预防性维护（Preventive maintenance）,2019/7/26,第7章 系统实现与维护,83,7.11 软件维护,2019/7/26,第7章 系统实现与维护,84,7.11 软件维护,结构化维护与非结构化维护差别巨大 维护的代价高昂 维护的问题很多,2019/7/26,第7章 系统实现与维护,85,7.11 软件维护,结构化维护： 有完整的软件配置，能够提高维护的整体质量。 非结构化维护： 缺少相关文档使得维护的代价巨大。,2019/7/26,第7章 系统实现与维护,86,7.11 软件维护,有形的维护代价：费用。 无形的维护代价有更大的影响： 贻误良机； 一些合理的修复或修改请求不能及时安排，使得客户不满意； 变更的结果引入新的故障，使得软件整体质量下降； 把软件人员抽调到维护工作中，干扰了软件开发工作。,2019/7/26,第7章 系统实现与维护,87,7.11 软件维护,生产率大幅下降： 维护工作量包括生产性活动（如分析和评价、设计修改和实现）和非生产性活动（如力图理解代码功能、解释数据结构、接口特性、性能限度等）,2019/7/26,第7章 系统实现与维护,88,7.11 软件维护,维护工作量的模型： M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是复杂程度 d是维护人员对软件熟悉程度的度量,2019/7/26,第7章 系统实现与维护,89,7.11 软件维护,与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点： 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。 需要维护的软件往往没有合格的文档，或者文档资料显著不足。 当要求对软件进行维护时，不能