1、第七章维护方法7.1 维护的基本概念7.2 维护的种类7.3 维护的步骤与方法7.4 可维护性7.5 维护的管理习题七第七章维护方法软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。一个中等规模的软件，如果其开发过程需要一到二年时间，则它投入使用以后，其运行时间可能持续五到十年之久。而这段时间正是维护阶段。在这一阶段中，人们需要着手解决开发阶段尚未解决的问题，同时，还要解决维护工作本身所产生的问题。做好软件的维护工作不仅能够排除软件中存在的错误，使它能够正常工作，而且还可以使它扩充功能，提高性能，为用户带来新的效益。但是，人们对软件维护的认识还远不如软件开发，这是因
2、为开发工作具有主动性和创造性，容易被人们所重视。但是，与软件开发工作相比，软件维护阶段的工作量和成本却要大得多。7.1 维护的基本概念维护的基本概念第七章维护方法 开发阶段结束以后，在软件运行过程中仍然存在一些原因需要对软件进行变动。这些原因主要是：1)在运行中发现软件错误和设计缺陷，这些错误和缺陷在测试阶段未能发现；2)需要改进设计，以便增强软件的功能，提高软件的性能；3)要求已运行的软件能适应特定的硬件、软件、外部设备和通信设备等的工作环境，或是要求适应已变动的数据或文件；4)为使投入运行的软件与其他相关的程序有良好的接口，以利于协同工作；5)为使运行软件的应用范围得到必要的扩充。第七章维
3、护方法 值得指出的是，软件“维护”不同于硬件“维护”。对硬件来说，“维护”包括替换已损坏的零部件、纠正缺陷、加强设计以及保养等，但这些都不会影响到设备的功能，对设备性能提高也是非常有限的。而软件的“维护”则完全不同。它不仅可以改正原设计中的错误或不当之处，而且还可以增强软件功能，提高软件性能。实践表明，大多数软件维护工作都是出于增强功能的要求，而不是由于可靠性问题进行的。第七章维护方法 软件维护工作处于软件生命期的最后阶段，在此之前完成的开发工作曾经花去了大量的人力和资源。软件交付使用以后，用户迫切希望它能正常工作，发挥效益。同时，也希望它能稳定、可靠地工作，具有较长的使用寿命。为了满足用户的
4、要求，有必要再投入一定数量的人力和资源，开展软件维护工作。统计资料表明，维护阶段的花费约占整个软件生命期花费的67。因此，如果我们不能充分认识到维护工作的重要性和迫切性，则可能会导致已开发的软件无法发挥其应有的效益。近年来，人们开始认识到维护现有软件的重要意义，并在这方面做了许多工作。第七章维护方法 1.完善完善 性维护性维护(Perfective Maintenance)当一个软件系统投入使用和成功地运行时，用户会根据业务发展的实际情况，提出增加新功能、修改已有功能以及一般的改进要求等。虽然这些内容在需求说明书中并未规定，但是，为了扩充原有系统的功能、提高原有系统的性能，满足用户的实际需要，
5、这项工作是必不可少的。例如：7.2 维护的种类维护的种类第七章维护方法修改计算工资程序，使其增加新的扣除项目；把现有的程序终端对话方式加以改造，使其具有方便用户的图形界面；增加联机求助(HELP)命令；为软件的运行增加监控设施。第七章维护方法 2.纠错性维护纠错性维护(Corrective.Maintenance)软件测试不可能找出一个软件系统中所有潜伏的错误，所以，当软件在特定情况下运行时，这些潜伏的错误可能会暴露出来。此外，软件运行时也会出现一些问题，譬如用至l了从未用过的输入数据组合，或者与其他软件、硬件接口不符。这些故障若不能及时解决，势必使软件系统的工作被迫停止。因此，纠错性维护是在
6、软件运行中发生异常或故障时进行的。然而，对所发现的程序错误进行修改，一般都应该十分谨慎，以防造成不良后果。第七章维护方法 纠错性维护工作可能是：改正原来程序中并未使开关复原的错误；解决开发时未能测试各种可能条件带来的问题；解决原来程序中遗漏处理文件里的最后一个记录的问题。第七章维护方法 3.适应性维护适应性维护(Adaptive Maintenance)计算机技术的发展日新月异。随着新的计算机硬件系统的不断发展，新的操作系统或操作系统的新版本会不断推出。此外，外部设备和其他部件也要经常修改和改进。与此同时，应用软件的使用寿命也超过了最初开发这个软件时系统环境的寿命。例如，数据库的变动、数据格式
7、的变动。数据输入输出方式的变动以及数据存贮介质的变动等，都会直接影响到软件的正常工作。适应性维护就是要使运行的软件能适应外部环境的变动。第七章维护方法 适应性维护可能是：为现有的某个应用问题实现一个数据库管理系统；对某个指定编码进行修改，从3个字符改为4个字符；缩短系统的应答时间，使其达到特定的要求；修改两个程序，使它们可以使用相同的记录结构；修改程序，使其适用于另外的终端。第七章维护方法 4.预防性维护预防性维护(Preventive.Maintenance)预防性维护是为了进一步改进软件的易维护性和可靠性，以提供更好的基础对软件进行维护。维护人员不要单纯等待用户提出维护请求，应该选择那些还
8、能使用若干年、目前虽能运行但不久就须作重大修改或加强的软件，进行预先的维护。例如，早期开发的软件有一部分仍在使用，但原来的开发方法陈旧，文档也不齐全。对它们的全部或部分程序重新设计、编码和调试，在经济上往往是合算的。从上述四种维护工作的介绍可以知道，软件维护不仅仅局限于纠正软件中的错误，更重要的是完善现有的软件系统。根据国外的统计数字得知，完善性维护约占全部维护活动的50，纠错性维护约占25，适应性维护约占21，预防性维护约占4。如图7.1所示。第七章维护方法图7.1第七章维护方法7.3.1 维护步骤维护步骤图7.2表示一般的维护步骤。对任何一项维护请求，首先要明确维护的类型。在有些情况下，用
9、户和维护人员之间 对维护类型可能会产生分歧，对于这些不同意见，必须协商解决。7.3 维护的步骤与方法维护的步骤与方法第七章维护方法图7.2第七章维护方法 对纠错性维护的请求，从评价软件错误的严重性开始。如存在严重错误(即一个关键；性的系统不能运行)，那么在系统管理人员的指导下分配人员立即进行问题分析。对于不 严重的错误，纠错性维护请求与其他软件开发任务一起，统一安排时间。适应性维护和完善性维护的请示沿着同一路径进行(见图7.2)。先确定两项请求的优先次序，如果某项维护请求的优先次序非常高，就可立即开始维护工作，否则，与其他维护任务一样，统一安排工作时间。第七章维护方法 如果出现恶性软件故障，就
10、会发生紧急维护请求。在这种情况下，立即把所有资源用来解决软件故障。虽然这项维护工作在图7.2中没有表示出来，但在遇到实际情况时，必须紧急安排处理。尽管维护请求类型不同，但都要进行同样的维护技术工作，包括：修改软件设计；设计的复审；必要的代码修改；模块测试；联合测试；系统测试；复审。第七章维护方法7.3.2 维护方法维护方法 1.基本工作基本工作 首先，让我们看一下软件维护人员所面临的基本工作，这些工作有先后顺序：1)检查用户需求说明书，对用户原来的需求做到心中有数；2)同用户和开发人员商讨，明确维护的类型；3)检查程序和相应的文档；4)确定程序错误的性质与位置，或要增加功能的部分；5)研究程序
11、修改可行性和修改可能引起的副作用；6)对改变的部分进行编码；7)修改相应的程序文档和程序库。第七章维护方法 实践证明，不管软件开发工作和预防性维护工作做得多好，大量的维护工作是不可避免的。虽然由于软件质量的改进，纠错性和适应性维护可以减少或者不做，但是完善性维护必须进行，取消全部维护工作是不可能的。在这样的情况下，怎样改进维护的方法，提高维护的效率和质量，是摆在我们面前的实际问题，下面就改进维护的方法提出一些建议：使用结构化程序设计技术来修改程序；鼓励维护人员与用户和开发人员互相商讨问题；建立和加强程序设计和文档标准；第七章维护方法改进现有软件的文档；为检查维护工作的质量严格执行维护复审；提高
12、用户对维护工作的重视；应以成批方式处理维护请求，而不是以分散的方式处理维护请求；当软件被修改后，应该特别重视重复测试和重复确认；应对维护人员加强应用领域新知识和新技术的培训，有利于搞好维护工作。理解现有系统、修改现有系统、重新确认修改后的系统成为维护工作的主要过程，下面将要分别介绍在这3个过程中所采用的维护方法。第七章维护方法2.理解现有系统理解现有系统 在进行修改系统之前，必须先理解系统的功能、系统的内部结构以及系统的操作文要求。1)自顶向下理解现有系统：首先应该了解系统的总功能、总结构，然后了解基本数据结构和程序的组成部分。在理解系统的过程中，必须将所理解的内容整理成文档，以供修改之用。现
13、有系统有两方面的信息来源，一方面是程序清单，另一方面是系统文档。所以，程序清单的可读性和系统文档的正确性、一致性和完整性是非常重要的。第七章维护方法 维护人员和开发人员应建立程序清单管理库，使清单便于维护人员存取使用。系统文档是维护人员理解现有系统强有力的工具。这里的文档指的是系统的高层文档而不是语句级的注释。2)维护人员应该参与系统的开发工作：实际工作表明，维护人员参与系统开发工作好处很多。他们可以向开发人员提供可维护性指导，收集测试和错误信息，以及进行系统可维护性验收等。如果等到维护阶段才了解系统，进行有关信息的收集和保障可维护性等工作，将会使维护工作变得十分困难。第七章维护方法 3修改现
14、有系统修改现有系统 在修改现有系统时，应该注意不能损害现有系统的质量。同时，要保持程序风格一致性和系统功能的完整性。除此之外，应考虑到修改现有系统将有利于将来系统的修改；而且，应对用户没有不利的影响。下面，就修改现有系统的3个过程介绍一下应采用的维护方法。1)制定系统的修改计划：通过研究系统中各个模块、模块的接口和数据库结构使维护人员能从整体观点提出修改计划的方针和策略。在此基础上，为了确定修改的范围，逐步地把要修改的模块和受修改影响的模块分离出来。仔细观察每个要修改和受修改影响的模块和数据结构的内部细节，制定修改的具体计划。第七章维护方法 在制定修改计划时，建议遵循以下原则：(1)检查修改的
15、设计，使修改的指导思想与系统原始设计思想相一致。(2)力求修改简单，即修改的模块最少，最简单和修改较少的全程变量。(3)选择满足通用性要求的修改计划，使修改满足不同的软件版本，不同的操作系统和硬件配置。(4)选择满足灵活性要求的修改计划，使修改后的特殊功能集中在一些模块中，并使模块接口有利于将来的修改。第七章维护方法(5)选择不降低系统质量的修改计划，即不降低系统的可维护性水平。(6)描述系统修改部分的可测试性(论证程序正确性的容易程度)和测试方法。(7)考虑系统的修改对计算机的处理时间、存贮要求和操作过程的影响。(8)考虑系统的修改对用户使用系统的影响，以及修改系统所需的费用和时间。第七章维
16、护方法 2)按计划修改系统：在修改系统时，建议遵循以下原则：(1)在进行任何修改之前，必须理解系统中全部控制逻辑。(2)修改时要非常谨慎，所做的修改不要比需要修改的部分更多。(3)在不破坏原来的程序设计风格和标准的前提下，尽可能采用结构化编码技术。(4)不要企图共享系统中已有的变量，相反，应该建立新的局部变量。(5)对相似的功能应建立各自独立的子程序，不要建立公用子程序。第七章维护方法 (6)应该充分利用自动工具进行系统修改。(7)应该利用防御错误的程序设计方法来修改系统，即在系统中插入错误检查机制，使系统能对错误进行自查。(8)坚持进行修改后的复审，以检查系统的质量和标准。(9)在修改过程中
17、要建立文档，记录已做了什么修改、修改的原因、可能引起的新问题，并对将来的修改提出建议和进行其他必要的注释。(10)要注意在修改系统的同时修改相应的系统文档，以保持系统和文档的一致性，并保存修改前的系统和文档版本。第七章维护方法 在进行系统修改时可能会产生维护的副作用。所谓维护的副作用是指由于修改而导致的错误或其他多余的动作。这些副作用可能是：修改代码的副作用。对一个语句的简单修改有时可能带来灾难性的后果。例如：由于粗心把一个“，”写成一个“”，又没能检查出来，竟导致阿波罗宇宙飞船的飞行控制系统失效。第七章维护方法 通过使用编程语言的源程序代码与计算机通信，产生副作用的可能性是很大的。虽然每条代
18、码的修改都有可能引入错误，但是下述的修改可能比其他修改更容易引入错误：删除或修改子程序；删除或修改语句标号；删除或修改标识符；为改进执行性能所作的修改；修改文件的打开和关闭；修改逻辑运算符；把设计的修改翻译成代码的修改；对边界测试所作的修改。第七章维护方法 修改代码所产生的副作用一般可以在退化测试过程中对其造成系统的故障进行查明和纠正。修改数据的副作用。在对一个数据结构中个别元素或数据本身进行修改以后，当数据发生变化时，该系统的数据结构可能不再“适合”这个数据，并且可能出现错误。第七章维护方法 引起数据副作用常常发生在对下述数据的修改之中：重新定义局部常量和全局常量；重新定义记录格式和文件格式
19、；增加或减少一个数组或更高阶数据结构的规模；修改全程数据；重新初始化控制标志或指针；重新排列输入输出或子程序的自变量。第七章维护方法完善设计文档资料可以限制修改数据的副作用。在文档中描述了数据结构，并提供了一种把数据元素、记录、文件以及其它结构与系统模块联系起来的交叉对照表。文档资料的副作用。对源程序代码的修改没有反映到设计文档资料和用户手册中时，就会出现文档资料的副作用。如果要对数据流、软件系统结构、模块过程和其它有关特性进行修改，就必须对相应的文档资料进行更新，否则，设计文档资料不能正确地反映软件系统的当前状态，甚至比完全没有文档资料的情况更糟，因为在以后的维护工作中阅读这些文档资料时，将
20、会导致对软件系统特性作出不正确的评价。例如，交互式输入的次序或格式的修改，如果没有相应地反映在有关的文档资料中，可能会引起严重的问题。第七章维护方法 在软件系统再次交付使用之前，对整个软件配置进行复审，将能大大减少文档资料的副作用。3)控制系统修改的波动效应：当修改系统的一部分而影响系统的其它部分时，就会出现所谓的“波动效应”。例如，系统中若干个模块可能调用一个公用子程序或引用一个全程变量。对公用子程序或全程变量的任何改变都可能影响所有这些模块的处理结果，系统模块间的互相依赖性(块间联系)越大，修改系统所引起的波动效应也越大。第七章维护方法为了控制由于修改系统所产生的波动效应，应该注意以下的几
21、个方面：(1)修改部分应尽可能小。(2)减少对变量的修改，特别是全程变量的修改要减少到最小程度。(3)当一个公共子程序被修改后，应检查调用这个公共子程序的全部模块，确定修改。(4)当模块内一个局部变量被修改后，应检查模块内引用该变量的代码，确定模块的功能和模块所引用的其它变量是否受到影响，因为一个变量的修改可能会间接地影响其它变量的值。第七章维护方法(5)当系统中的全程变量被修改后，应检查引用这个全程变量的全部模块，确定它们是否受到修改的影响。如果要对软件系统进行多处修改，应该遵循以下的原则：(1)按模块把修改分类。(2)自顶向下地安排修改模块的顺序：首先修改顶层模块，其次修改下属模块。(3)
22、每次只修改一个模块。(4)对每个已修改的模块，在安排修改下一个模块之前，确定这个已修改模块所产生波动效应。第七章维护方法4.重新确认修改后的系统重新确认修改后的系统当修改系统完成后，应该重新确认修改后的系统，以证实所作的修改是正确的。有一些研究报告指出，一次修改的成功率是较低的。例如，修改的范围不超过10条语句，一次修改的成功率是50%。若修改的范围为50条语句，一次修改的成功率仅为20%。所以，如果维护人员不对修改部分进行测试，那么引入新的错误是肯定无疑的。重新确认类似于原来系统的确认过程。可以利用在系统开发阶段所使用的测试用例对修改后的系统进行重新测试，并比较两种测试结果，这样能发现许多未
23、预料到的错误。第七章维护方法在进行重新确认修改后的系统时，要注意以下几个方面：(1)为了防止只注意修改部分，不应该把从事修改工作的维护人员作为进行重新确认 (2)应该首先对系统的故障做测试，然后再对系统的未修改部分做测试，最后再测试。(3)准备好标准的测试用例，并利用开发阶段使用过的测试用例，必要时再补充一些特殊的测试用例。(4)尽量利用自动工具来帮助进行重新确认工作。第七章维护方法(5)在重新确认过程中应该邀请用户参加，并鼓励他们独立地确认。(6)要对重新确认过程中发现的错误数量和类别进行记录，并把这些结果同以前进行测试的结果相比较，以估算系统由于修改而受到的损害的程度。综上所述，可以知道：
24、维护是一项涉及面很广的活动，必须按照一定的步骤，采用稳妥、可靠的方法来进行。在维护工作开展之前，要制定维护方案，在维护过程中应该严格按方案去实施；在维护工作结束前还要进行复审，以保证维护工作的质量。第七章维护方法 软件的可维护性(Maintainability)是指维护人员为纠正软件系统出现的错误或缺陷，以及为满足新的要求而理解、修改和完善软件系统的难易程度。提高可维护性是决定软件工程方法论所有步骤的关键目标。7.4 可维护性可维护性第七章维护方法 决定可维护性的因素主要有3个：1)可理解性(understandability)：可理解性被定义为人们通过阅读源代码和相关文档了解软件系统的结构、
25、接口、功能、内部过程以及如何运行的难易程度。一个可理解的系统应具备如下一些特性：模块化；程序设计风格的一致性；不使用令人捉摸不定或含糊不清的代码；第七章维护方法使用有意义的数据名和过程名；采用结构化的程序设计方法；具有正确、一致和完整的文档。2)可测试性(Testability)：可测试性被定义为诊断和测试系统的难易程度。一个可测试的系统应具备下列特性：具有模块化和良好的结构；具有可理解性；具有可靠性；能显示任意的中间结果；以清楚的描述方式说明系统的输出；第七章维护方法 能根据要求显示所有的输入；能跟踪及显示逻辑控制流程；能适应软件开发每一阶段结束的检查要求；能显示带说明的错误信息；具有正确、
26、一致和完整的文档。3)可修改性(Modifiability)：可修改性被定义为修改软件系统的难易程度。一个可修改的系统应具有以下的特性：第七章维护方法具有模块化和良好的结构；具有可理解性；避免在算术、逻辑表达式、表数组的大小以及输入输出设备命名符中使用文字常数；具有用于支持系统扩充的附加存贮空间；具有评价修改系统所带来的影响以及修改部分说明的资料；建立公用模块子程序以取消冗余的代码；使用提供常用功能的标准库程序；尽可能固定每一变量的使用；具有通用性和灵活性。第七章维护方法 上述3个可维护性的因素是密切相关的。可理解性是基础，维护人员在正确理解一个系统之前根本不可能去修改它；如果不能进行完善的诊
27、断和测试，则表面正确的修改可能引进其他错误。文档是影响软件可维护性的另一决定因素。一个好的文档应具有简明性和书写风格的一致性。这样，就能提高系统的可读性和可修改性，而质量低劣的文档比没有文档更糟糕。可维护性是所有软件系统都应具备的特点。在软件工程的每一阶段都应该努力提高系统的可维护性，在每个阶段结束前的审查和复审中，应着重对可维护性进行复审。第七章维护方法 在需求分析阶段的复审中，应对将来要扩充和修改的部分加以注明。在讨论软件可移植性问题时，要考虑可能影响软件维护的系统界面。在软件设计的复审中，应从便于修改、模块化和功能独立的目标出发，评价软件的结构和过程，还应对将来可能修改的部分预先作准备。
28、在软件代码复审中，应强调编码风格和内部说明文档这两个影响可维护性的因素。第七章维护方法在软件系统交付使用前的每一测试步骤中都应给出需要做预防性维护部分的提示。在完成每项维护工作后，都应该对软件维护本身进行仔细认真的复审。为了从根本上提高软件系统的可维护性，人们正试图通过直接维护软件规格说明来维护软件，同时也在大力发展软件重用技术。第七章维护方法 软件系统的维护工作不仅是技术性的，它还需要大量的管理工作与之相配合，才能保证维护工作的质量。由7.3可知，维护工作从理解软件系统开始。这种理解包括对功能、性能的分析和理解。在此基础上，如果有明确的维护任务，例如，改正错误、适应性修改或完善性修改，都应该
29、提出维护修改建议，并在管理部门的参与和控制下来完成维护工作。图7.3表示了软件维护的管理流程。7.5维护的管理维护的管理第七章维护方法管理部门应对提交的修改建议进行分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予以撤销。通过审批的修改方案，经修改后应做严格的测试，以检验修改的质量。经管理部门再次审查后，方可对主文档进行更新。为确保维护中修改的正确性，消除因修改不当给用户带来的不良影响，要求对修改工作持谨慎的态度。例如，维护修改建议常常提得不够具体，或是用户提出的修改要求不一定恰当，有些要求则超出了软件维护工作的范围。在这种情况下，维护人员应和用户仔细讨论，在说明情况、弄清要求的基础
30、上，提出修改建议。第七章维护方法 由谁来承担维护工作是软件维护管理的另一个问题。一般认为应该由开发软件的人员去维护。这样做的好处是他们对自己开发的软件最熟悉，维护起来更方便。但是，他们也有可能认为反正由自己去做维护工作，从而不认真编写文档。当然，由开发人员做维护工作势必使得他们的新项目开发工作受到影响。另一种做法是安排专职的维护人员负责维护工作，而开发人员不管维护。这样做的好处是开发人员可以集中精力做好开发工作，有利于坚持实施开发标准，有利于保证文件的编制质量。而专职的维护人员可以把被维护的软件分析得非常透彻，成为这个软件的专家。第七章维护方法还有一种较好的做法是安排软件人员实行开发任务和维护
31、任务定期轮换，这样可以使软件人员体会到开发和维护工作的具体技术要求，以及两者之间的相互关系，有利于提高软件人员的技术水平和软件系统的质量。无论采用上述哪一种维护工作的组织方法，当考虑如何安排软件人员的工作时，对每个软件系统至少应指定两人负责维护工作，这就避免了对某个人过分依赖，防止出现由于某人工作调动而使维护工作受到影响的情况。第七章维护方法 软件维护阶段所产生的文档主要有两个。一个是软件问题报告，另一个是软件修改报告。软件问题报告是由用户或维护人员提出的，其主要内容是：登记号和登记日期；软件名称、编号、版本号；开发单位名称；报告人姓名、单位、电话；报告时间；问题来源(程序、数据库、文件或其他
32、来源)；第七章维护方法问题描述(包括运行环境、测试用例、问题特征及其影响)；处理意见(包括负责人签名和签名日期)；附注。软件修改报告是由维护人员对软件进行修改、测试，并经审查以后填写的，其主要内容是：登记号和登记日期；上次修改登记号；修改日期；第七章维护方法 软件名称、编号、版本号；开发单位；“软件修改申请报告”登记号和登记日期；修改时的运行环境(包括硬件、软件和其他环境)；修改内容(包括程序、数据库、文件等)；测试情况(包括测试项目、测试用例和测试成功与否)；修改的影响(包括对软件系统、运行环境和使用者)；第七章维护方法 修改时的资源消耗(包括人工数和计算机时数)；附注；修改者和校审者姓名；
33、标准化情况；批注者姓名。软件工程的实践表明，维护工作远不如开发工作对软件人员有吸引力。而且，要做好维护工作又是十分困难的。第七章维护方法但是，仔细地分析一下就会发现：这种困难正是由于在开发阶段未严格按软件工程标准和规范去做而造成的。所以，一方面要提高软件开发人员对软件可维护性的认识，另一方面还必须认真组织专职的维护人员队伍，在软件系统运行中尚未暴露出问题时，他们应该熟悉掌握系统的有关文档，以便在维护任务提出来时能高质量地完成维护工作。第七章维护方法1为什么要进行软件系统的维护?2维护工作的种类有哪些?其中哪一类维护是最主要的?3为什么要在维护工作开始前先明确维护的类型？4在维护工作中怎样防止维护的副作用?5有人认为，提高可维护性是决定软件工程方法论所有步骤的关键目标。你同意这 观点吗?试说明理由。6什么是软件配置?为什么要在维护工作结束前进行配置复审?7在维护工作管理中，怎样妥善安排维护人员的工作?习习 题题 七七
