一篇文章教你了解软件工程

1.软件工程的概述

1.1软件的定义

软件是计算机中与硬件相互依存的另一部分，是包括程序、数据及其相关文档的完整集合。

1.2.软件的分类

1.按软件的功能分:系统软件、支撑软件、应用软件
2.按软件的规模划分:微型软件、小型软件、中型软件、大型软件、极大型软件
3.按软件工作方式划分:实时处理软件、交互式软件、批处理软件
4.按软件服务对象的范围划分:项目软件、产品

1.3常见的软件

系统软件：
操作系统:Windows、Linux、macOS、UNIX等
语言处理程序:C、C++、Java和Python等
支撑软件:
开发环境(IDE):Eclipse、Visual Studio、IntelliJ IDEAGCC、Clang等C/C++编译器
应用软件:
(1)商业处理软件 如Excel
(2)工程与科学计算机软件 如CAD制图工具、仿真软件
(3)智能产品嵌入式软件，驻留在智能产品内存，控制产品工作的软件。如智能家用电器、智能手机等
(4)人工智能软件 利用非数值算法去解决复杂问题的软件。专家系统(如IBM深蓝系统)、模式识别软件(如人脸识别软件，声音识别软件)、人工神经网络软件(如DeepSeek、ChatGpt)

1.4.软件危机

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
主要表现在以下几个方面，
(1)软件开发成本严重超标，开发周期大大超过规定日期.
(2)软件不能满足用户的需求,
软件质量难于保证，可靠性差。
(3)软件难于维护。
(4)软件没有适当的文档、资料
要解决软件危机问题，需要采取以下措施
(1)使用好的软件开发技术和方法,
(2)使用好的软件开发工具，提高软件生产率
(3)有良好的组织、严密的管理，各方面人员相互配合共同完成任务。

1.5.软件工程

软件工程是把系统的、规范的、可度量的途径应用于软件开发、运行和维护的全过程，从技术和管理两方面来研究如何更好地开发和维护计算机软件的。
实施原则（6点）
1.做好用户的全面分析
2. 选取适宜的开发模型
3. 采用成熟的设计方法
4. 选择高效的开发环境
5. 保证有效的维护过程
6.重视软件过程管理

1.6.软件生命周期

软件生命周期(Software Life Cycle，SLC)是软件从产生直到报废或停止使用的时间周期。
软件工程用于软件开发的指导思想之一就是划分软件生命周期，把软件开发的全过程分阶段、定任务，按先后顺序依次完成。

软件生命周期，分为8个阶段:
1.问题定义：确定系统的目标、规模和基本任务。
2.可行性研究：解决问题是什么?有行得通解决方法?
3.需求分析：目标系统必须作什么?目标系统需求(功能、性能、可能的需求、交付标准)
4.概要设计：怎样实现目标系统?根据需求设计方案;分析推荐最佳方案;设计软件结构等
5.详细设计：该怎样具体实现系统?设计每个模块的算法和数据结构。
6.软件实现(编码和单元测试)：选择语言、工具翻译详细设计结果、测试模块。
7.综合测试：将经过单元测试模块组装起来进行测试，由用户按需求规格说明书规定进行测试。
8.软件运行、维护：通过必要维护活动（改正性维护，适应性维护，完善性维护，预防性维护）使系统持久满足用户要求。

1.7软件过程模型

软件生命周期模型：针对软件生命周期各阶段活动的一般规律，对软件开发过程进行定量度量的量化，为软件工程管理提供阶段性评价，为软件开发过程提供原则和方法提出了软件过程模型。

目前典型的软件开发模型有:（8个）
瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型、敏捷过程模型 ，渐进式交互过程模型、微软解决框架模型等。敏捷模型是使用较为广泛的软件开发模型，Scrum 是其中应用最普遍的框架。

1.8.版本控制

版本控制(Revision control)是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便査看更改历史记录，备份以便恢复以前的版本的软件工程技术。
git是世界上目前最先进的分布式版本控制系统。
具体了解git原理，如何创建远程仓库，以及git基本命令在https://blog.csdn.net/m0_75238764/article/details/147257025?spm=1001.2014.3001.5502

2.软件需求工程

（1）现代软件需求工程包括问题定义、可行性分析、需求分析三个阶段。
（2）需求分析又包含需求获取、需求分析与建模、需求评审三个阶段。
（3）软件需求分析工作可以分为哪四个方面?
需求获取、分析与建模、编写需求规格说明书和需求评审软件
（4）需求分析有哪三个基本原则?
必须能够表达和理解问题的数据域和功能域必须按自顶向下
逐步分解的方式对问题进行分解和不断细化，
给出系统的逻辑视图和物理视图

2.1可行性分析

2.2需求分析

可行性分析解决的是“值不值得做”的问题,需求分析解决的是“做什么”的问题;
需求分析说明书：面向的是业务人员和用户把系统需要解决的业务逻辑、要实现的功能描述清楚(宏观)。
需求规格说明书：面向的是设计和开发人员把系统的约束、输入、输出和处理的过程定义清楚更具体。

需求分析的步骤：
1，获取用户的初始需求:包括功能需求、性能需求、领域需求和其他需求。
2，确定系统的真正需求:对于获取的原始资料，软件开发人员需要认真分析需求间的内在联系和矛盾，去除需求中不合理的和非本质的部分，确定软件系统的真正需求。同时运用描述系统需求的相应工具，绘制出系统的工作业务流程图以及数据流程图。
3，建立系统的逻辑模型:从各级数据流图与数据结构出发，去除其不合理的部分最终形成系统的解决方案，给出系统的详细的逻辑模型。
4.书写需求说明书:系统分析完成后，为了清晰准确的描述出来，要书写需求规格说明书，这也是系统分析阶段的成果。
5，进行需求复审:为了保证软件开发的质量，对软件需求阶段的工作要进行严格的复审过程，从不同的技术角度对该阶段工作进行综合评价。

需求分析的基本任务就是分析和综合已收集到的需求信息，
◆1.确定对系统的综合要求
◆2.分析系统的数据要求
◆3.导出系统的逻辑模型
常用的建模方法有数据流图、实体关系图、状态转换图、控制流图、用例图、类图、对象图等
需求描述就是指编制需求分析阶段的文档
对于复杂的软件系统需求阶段会产生3个文档:
系统定义文档(用户需求报告)
系统需求文档(系统需求规格说明书)
软件需求文档(软件需求规格说明书)
对于简单的软件系统而言，需求阶段只需要输出软件需求文档就可以了。
软件需求规格说明书主要描述软件部分的需求，它站在开发者的角度，对开发系统的业务模型功能模型、数据模型、行为模型等内容进行描述。经过严格的评审后，它将作为概要设计和详细设计的基线。

2.3需求分析建模

经过软件的需求分析建立起来的模型可以称为需求模型，也可以称为系统的逻辑模型。
系统的逻辑模型与软件开发方法有关:
◆结构化方法:采用数据流图、数据字典、状态转换图、E-R图等
◆面向对象方法:用例图、类图等
结构化分析的核心是数据。数据包括在分析、设计和实现中涉及的概念术语、属性等所有内容，并把这些内容定义在数据字典中。
围绕数据字典，完成数据模型、功能模型和行为模型的结构化建模过程。

2.4数据字典

1.数据字典是指对数据的数据流、数据存储、处理逻辑、外部实体等进行定义和描述，其目的是对数据流图中的各个元素做出详细的说明。数据字典作为分析阶段的工具，与数据流图结合构成系统的规格说明。
2.数据字典主要描述数据流图中的四类元素，即数据源点/终点、数据存储、处理(处理逻辑)和数据流。
3.数据字典的定义方法：一个复杂的数据结构是由一些简单的数据项组合而成的。数据元素的组成及符号表示。数据元素的组成关系通常包括顺序、选择、重复和可选四种:

绘制数据字典;实际开发项目时，常采用以下这种格式

2.5.数据模型：E-R图

数据模型的组成:数据对象(实体)、关系（联系）、属性
数据对象:软件必须理解的复合信息表示，复合信息是具有一系列不同性质或属性的事物。如:事务(报表)、地点(仓库)、角色(教师、学生)单位(会计科)、行为(打电话)等
属性:定义数据对象性质。如:数据对象学生的属性可为学号、姓名、班级等。
数据对象间关系:对象彼此间相互连接方式如:教师和学生间存在“教”的联系。联系分三类，1:1、1:N、M:N。

绘制E-R图步骤：
（1）确认实体（2） 确定属性 （3）确认关系 （4）确定关系的基数（5）完善E-R图

2.6.数据流图

数据流图是描绘信息流和数据从输入流动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。数据流图是系统逻辑功能的图形表示，是分析员与用户之间较好的通信工具。

数据流图特点
1.数据流图的基本要点是描绘“做什么”而不考虑“怎样做”
2.通常在数据流图中不描述流动条件。忽略出错处理，也不包括诸如打开或关V闭文件之类的内部处理。
3.数据流图是交流信息的工具，用户可以理解，也是分析员进行系统分析设计的工具。
4.数据流图中的命名应尽可能地清楚、具体。

2.7.状态转换图（Status Transition Diagram）

状态转换图是通过描述系统状态及引起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。STD图主要由状态、转换和事件的图形符号构成。
状态是可观察到的行为，是同一数据对象在系统的不同运行时刻所具有的行为属性值，是事件触发后一系列动作的结果。
事件:箭头表示状态转换，箭头上标事件名。后跟〔条件】，表状态转换。

3.软件设计

软件设计是软件工程的重要阶段，它将软件的编码往后推迟了一个阶段体现了软件工程“推迟实现”的原则。
软件设计主要回答软件“如何做”的问题，为软件开发提供“如何实现软件需求”的决策
1.数据设计，是软件设计的基础，是由数据字典和数据模型提供信息
2.体系结构设计，是由数据流图(系统信息流动和处理情况)提供信息
3.接口设计，研究分析数据流图。数据流在不同模块中转换，提供了模块接口设计,人机交互界面设计的数据结构或控制信息
4.过程设计，依据控制规格说明书和状态转换图、处理规格说明，描述模块内部的具体算法流程。

软件设计可以分为**概要设计(也称总体设计)和详细设计(也称过程设计）**两个子阶段。
概要设计的主要目的是从总体角度，确定系统整体结构划分子系统和模块，确定系统各个模块或子系统之间的关系,
详细设计的主要目的是在概要设计基础上，确定应该怎样具体地实现各个软件元素，对目标系统的所有内容进行详细的过程描述，以便在编码阶段完成软件程序代码的实现。

软件设计原则
（1）分而治之:把大问题划分成若干小问题解答，降低了问题的复杂度。即块化思想。
（2）重用设计模式:指软件设计模式不做修改或稍作修改就能多次使用，提软件设计质量。
（3）可跟踪性:确定系统各部分、各模块之间的关系，在修改问题时能够追到问题根源。
（4）灵活性:设计具有易修改性。当需求变更、设计存在缺陷时、设计优化能够灵活更改。
（5）一致性:使用同一的规则和约束来规范设计，确保在不同阶段、不通版的设计中能够统一。如界面设计一致性。

3.1概要设计

软件体系结构确定了系统的组织结构和拓扑结构，显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
接口设计的内容应包括功能描述、接口的输入输出的定义、错误处理等。
在概要设计中的软件接口设计主要包括3个方面
软件模块间的接口设计;(内部接口)
模块与其他外部实体的接口设计:(外部接口)
用户界面设计
模块间的接口也叫做内部接口
模块与外部实体之间的接口叫做外部接口

3.2详细设计

详细设计的任务
1.模块的算法设计
2.模块的数据设计
3.模块的接口设计
4.模块的测试用例设计
5.编写详细设计说明书
详细设计中描述模块处理过程常用3种工具是:图形、表格和语言。
图形工具包括:程序流程图、盒图和问题分析图
语言包括:过程设计语言;
表格包括:判定表、判定树。
程序流程图中的5种基本控制结构
（1）顺序结构(Sequential Structure)
（2） 选择结构(Selective Structure)
（3）多分支选择结构(Case Structure）
（4）先判定型循环结构(While-LoopStructure)
（5） 后判定型循环结构(Until-Loop Structure）

3.3判定表（树）

当模块逻辑中含有复杂的条件组合时，用判定表与判定树更加清楚地描述复杂的条件组合与其对应的行为之间的关系。
通常，一张判定表由四部分组成，左上部分列出所有条件;右上部分是表示各种条件组合的一个矩阵;左下部分是所有可能做的动作，右下部分是与每种条件组合相对应的执行动作。

判定树是判定表的变种，它也能清晰地表示复杂的条件组合与对应处理之间的关系。

3.4软件设计评审

在软件设计完成之前，必须编写软件设计规格说明、数据设计说明和接口设计说明，并确定软件界面设计方案，并按照评审标准对软件设计过程和说明书进行评审，目的是发现并消除其中存在的遗漏错误和不足，使得说明书符合标注及规范的要求
通过了评审的软件设计规格说明、数据设计说明、接口设计和界面设计方案，就成为基线配置项，纳入项目管理的过程

软件评审标准
1.与软件需求规格说明书的契合度
2.对整个软件设计合理性的评审标准

4.软件实现

4.1程序设计语言

1.程序设计语言的分类：
第一代计算机语言–机器语言，机器语言是由二进制代码0、1指令构成。
第二代计算机语言–汇编语言
第三代计算机语言–高级语言
2.程序设计语言的特性
(1)一致性:程序语言用法的一致性
(2)二义性:在面向对象程序中，由于提供了运算符重载机制，因而会有符号的多重理解。
(3)局部性:对模块化支持的程序，如，描述程序段
(4)易编码性:对常用算法，常用数学计算能力等的支持。
(5)可移植性:源代码跨平台支持。
(6)可维护性:没有不需要维护的软件系统。系统需要及时有效的维护。
(7)配套的开发工具:优秀的开发支撑环境便于良好的代码编写。

2.程序设计风格

1.编码规范要求
基本要求：
（1）编码规范要求程序结构清晰，简单易懂，一般单个函数的程序行数不得超过100行。
（2）代码要精简，避免出现垃圾程序
（3）尽量使用标准库函数和公共函数。
（4）为避免二义性尽量使用括号。
（5）不要随意定义全局变量，尽量使用局部变量。
2.可读性要求
（1）可读性第一，效率第二。
（2）保持注释与代码完全一致
（3）每个源程序文件，都有文件头说明。
（4）每个函数，都有函数头说明。主要变量(结构、联合、类或对象)定义或引用时，注释能反映其含义。
（5）常量定义(DEFINE)有相应说明。
（6）处理过程的每个阶段都有相关注释说明。
（7）在典型算法前都有注释。
（8）利用缩进来显示程序的逻辑结构。
（9）循环、分支层次不要超过五层，
（10）注释的作用范围可以为:定义、引用、条件分支以及一段
代码。
（11）注释行数(不包括程序头和函数头说明部份)应占总行数的 1/5 到 1/3。
3.正确性与容错性要求
（1）程序首先是正确，其次是优美
（2）所有变量在调用前必须被初始化。
（3）对所有的用户输入，必须进行合法性检查。
（4）不要比较浮点数的相等
（5）程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。

4.3代码复用

软件复用是提高软件开发效率，提高软件质量的重要方法，也是软件工程发展的必然之路。
软件复用包括代码复用、设计模式复用、软件开发过程复用等抽象级别。
代码复用是利用己有的代码来构造或编写新的软件系统，代码的形式主要有二进制的目标代码(库文件)和源代码。

4.4代码评审

代码评审，也称为代码复查，是指在软件开发过程中，通过阅读源代码和相关设计文件，对源代码编码风格、编码标准以及代码质量等活动进行系统性检查的过程。
代码评审主要分为正式评审和轻量级评审
(1)正式评审:正式评审是针对代码编写完成之后召开的评审会议。评审会议由评审小组组织完成，成员包括组长、评审员、质量过程管理员和程序员。
(2)轻量级评审：主要采取非正式的代码走查方式，不需要组织正式会议，因此它成本小、灵活性高。

5.软件测试

软件测试是在软件投入运行使用之前，对软件需求、软件设计和软件程序进行的一种检查，是保证软件质量的关键步骤，也是软件评测的重要依据。
测试目的：
(1)测试是为了发现程序中的错误而执行程序的过程
(2)好的测试方案是极有可能发现迄今尚未发现的尽可能多的
错误的测试;
(3)成功的测试是发现了迄今尚未发现的错误的测试。

5.1软件测试原则

1.应尽早地和不断地进行测试避免出现软件错误的放大效应。
2.开发人员应尽量避免参加测试。
2.注重测试用例的设计和选择测试用例由输入数据、设计条件和预期结果组成。测试用例需满足以下特性:有效性、高效性、可行性。

5.2软件测试模型

5.2.1.V模型

V模型的重要价值在于，它定义了软件测试如何与软件工程各阶段相融合，它清楚地描述了各级别软件测试与软件开发各阶段的对应关系
V模型的局限性是把软件测试作为编码之后的活动;需求分析等前期产生的错误直到后期的验收测试才能发现。

5.2.2.w模型

W模型的重要贡献在于，明确软件开发各阶段都要进行测试，而不仅仅是在编码结束后才开始。这样，测试的对象不仅是代码，还可以是文档(需求规格说明、设计规格说明等)

5.3软件测试阶段

伴随着基本的开发过程，基本的测试行为都是先从单元测试开始，然后是集成测试、系统测试和验收测试。
(1)单元测试(Unit Testing)
单元测试是最小规模的测试，目的是检查每个软件单元能否正确的实现设计说明书中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种差错。
软件单元测试的对象是可独立编译或汇编的程序模块(或称为软件构件或在面向对象设计中的类)。
软件单元测试一般由软件的供方或开发方组织并实施，因为它需要知道内部程序设计和编码的细节。
（2）集成测试(Integration Testing)
软件集成测试的目的是检验软件单元之间，软件单元和已集成的软件系统之间的接口关系，并验证已集成软件系统是否符合设计要求，集成测试是单元测试的逻辑扩展，测试的技术依据是软件设计文档
(3)系统测试(System Testing)
系统测试是基于系统整体说明书的黑盒测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的要求，找出与需求规格不相符合或者与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的软件产品，还要包含系统运行所依赖的软硬件环境、数据和人员等，要检验整个系统是否可以协调工作。
(4)验收测试(Acceptance Testing)
验收测试是部署软件之前的最后一个测试操作，也称交付测试。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。
验收测试是以需方为主的测试，其对象是完整的、集成的计算机系统。验收测试的结论是软件的需方确定是否接收该软件的主要依据。
每一个阶段的测试，一般都包括:
(1)测试规划
(2)测试需求分析
(3)测试用例设计
(4)测试用例执行
(5)测试总结报告等五个环节的活动。
测试设计:根据测试需求分析结果编写测试用例(或测试案例)，主要任务包括:设计测试用例，编写自动化测试脚本等
所谓测试用例:是为某个特殊目标而编制的(1)一组测试输入(2)执行条件以及(3)预期输出结果
测试执行:在搭建的测试环境中运行测试用例的一系列活动，通过手工或者自动化的方式执行测试用例，记录测试执行的结果和测试环境标识，提交缺陷及回归测试。
执行测试前需要准备:测试环境，测试数据等
测试总结是从已完成的测试活动中收集和分析有用的信息的一系列活动，包括:测试工作产品、测试经验和教训等。
测试总结报告 ：是本阶段的重要产品。编写测试报告的目的是发现并消除其中存在的遗漏、错误和不足，使得测试用例、测试预期结果等内容符合标注及规范的要求。通过了评审的软件测试报告成为基线配置项，纳入项目管理的过程。

5.4软件测试类型

5.4.1.功能测试

功能测试是在测试环境下，对软件需求规格说明或设计文档中的功能需求逐项进行的测试，以验证其功能是否满足要求。所有系统都需要进行功能测试。
功能测试又可以细分为:针对**(1)业务功能的测试、(2)业务流程的测试、(3)业务规则的测试、(4)界面测试、(5)接口测试**等。
(1)功能测试及用例编写方法包括:
等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交分解方法等。
功能测试时一般都要做到以下几点:
(1)用正常值的等价类输入数据值测试。
(2)用非正常值的等价类输入数据值测试。
(3)对每个功能的合法边界值和非法边界值作为输入进行测试
(4)对控制流程的正确性、合理性等进行验证。

(2)界面测试
界面测试，也称U测试。界面测试是对界面操作和显示进行的测试，以检验是否满足用户的要求。
界面测试将对界面的规范性、易用性、设计合理性、美观与协调性、独特生及安全性等进行测试
(3)接口测试
接口测试是对软件需求规格说明或设计文档中的接口需求逐项进行的，测试系统组件间接口的一种测试。
测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

5.4.2非功能测试

（1）性能测试
① 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。
②识别体系中的弱点，受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
③系统调优，重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
④ 检测软件中的问题，长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
⑤性能测试需求分析是性能测试最关键的过程。该阶段性能测试需求分析人员必须把客户的需求明确化。
之外还需要明确使用该系统的用户数量;每天、每年等业务量;关键业务处理客户关心的响应时间及其服务器资源的利用情况等。
(2)安全性测试
安全性测试是检验软件安全性、保密性的测试，是验证应用程序的安全等级和识别潜在安全性缺陷的过程测试应尽可能在符合实际使用的条件下进行。安全性测试主要目的:查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力
安全性测试方法
**① 静态的代码安全测试:**主要通过对源代码进行安全扫描，根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。
②动态的渗透测试:使用自动化工具或者人工的方法模拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。
总结：
1.静态测试用于早期发现代码和设计缺陷；
2.动态测试验证系统在真实攻击下的防御能力；
3.合规性测试确保系统符合安全规范。
(3)安装测试
安装测试:对安装过程是否符合安装规程的测试，以发现安装过程中的错误。
(4)兼容性测试
兼容性测试范围包括:
① 硬件兼容:与整机兼容、与外设兼容;
②)软件兼容:操作系统/平台、应用软件之间的兼容、不同浏览器的兼容;
数据库的兼容、软硬件配合兼容:
数据兼容:不同版本间的数据兼容、不同软件间的数据兼容。

5.5软件测试技术

5.5.1静态测试

静态方法:指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。
例如:不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。

5.2.2动态测试

动态测试:指通过运行软件 来检验软件的动态行为和运行结果的正确性。
动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。在软件测试后期，系统测试阶段和验收测试阶段往往用动态测试方法。

5.3.3黑盒测试

又称:功能测试或者 数据驱动测试。是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。
黑盒发现错误类型:
(1)功能不正确或遗漏
(2)界面错误
数据结构或外部数据库访问错误(3)
(4)性能错误
(5)初始化或终止错误
具体的黑盒测试用例设计方法包括:
等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
1.等价类划分法
把程序的输入域划分成若干数据类，从每一数据类选取少数有代表性数据做为测试用例。
在各数据类中，各输入数据对揭露程序中的错误等效。
1.划分等价类
有效等价类:合理，有意义输入数据构成集合。
无效等价类:不合理，无意义输入数据构成的集合。

2.边值分析法
等价类划分补充。
确定边界情况;
选正好等于边界值做测试数据;
选临近边界合法数据,刚超过边界非法数据

3.错误推测法
靠经验和直觉推测程序可能存在错误，有针对性编写检查这些错误的测试用例。
注意:
1.输入数据或输出数据为零
2.输入或输出数目为零(如表空或只1项)
3.缺省值
4.空白
5.空值
6.多个数据的组合效应
7.错误的群集现象

5.4.4白盒测试

白盒测试又称结构测试、逻辑驱动测试或基于代码的测试
利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。
白盒测试的测试方法:代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
1.基本路径测试法
(1)根据过程设计结果画出相应流图
(2)确定线性独立路径的基本集合
(3)设计测试用例覆盖基本集合的路径
2.逻辑覆盖法
(1)语句覆盖
选择测试数据，使被测程序中每个语句至少执行一次。
(2)判定覆盖
每个语句至少执行一次，每个判定的真假分支至少执行一次
(3)条件覆盖
每个语句至少执行一次，判定表达式每个条件取各种可能结果。

6.软件维护

6.1软件维护概述

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程，同时通过软件维护，保证软件的日常良好运行。
软件维护工作处于软件生命期的最后阶段，维护阶段是软件生存期中最长的一个阶段，其费用高达整个软件生命期花费的约60%-70%。

进行软件维护的目的:
(1)在软件系统运行过程中发现测试阶段未能发现的、潜在的软件错误和缺陷。
(2)随着软硬件环境的改变，与系统交互的外部系统的改变，网络通信技术的发展，系统数据或文件格式、存储方式、读取步骤的变迁，要求软件系统适应这些变化。
(3)根据实际情况的发展，用户操作、流程发生改变，需要改进软件设计，增强软件功能，提高软件性能。
(4)不断扩大软件系统的应用范围
软件维护特点： 长期性、复杂性、高成本
(1)软件维护阶段是软件生命周期中，时间最长、工作量最大的活动
(2)软件维护虽立足于解决系统问题，改进系统功能和性能，但它不可避免地会会引入新问题，直接影响软件质量。
(3)软件维护实际上是一个简化的软件生命周期开发过程
软件的可维护性:
指软件能够被理解，并能纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。
一个软件的可维护性又取决于以下几个属性:
可理解性、可修改性、可测试性、可靠性、可移植性、可适用性与效率

6.2软件维护管理

1.按照不同的维护目的，维护工作可分成4类。
（1）纠错性维护(Corrective Maintenance)
（2）完善性维护(Perfective Maintenance)
（3）适应性维护(Adaptive Maintenance)
（4）预防性维护(Preventive Maintenance)


文档是软件可维护性的决定性要素之一。具有规范详细的文档，软件才具有较高的可维护性。软件系统的文档可分为用户文档、系统文档两类。
(1)用户文档
用户文档主要描述系统功能和使用方法;包括:功能描述、安装说明、使用说明、操作手册等;用户文档不体现功能具体的实现方法。
(2)系统文档
系统文档主要描述系统设计、实现、测试等各方面的内容;
包括:安装部署维护文档;接口规范和协议;设计文档(包括系统各个模块的详细设计说明书，主要是业务流程方面的，数据库设计文档及说明)等资料。
软件维护面临的困难
（1）文档缺失、不充分或过期;
（2）软件升级频繁:
（3）软件维护人员变动;
（4）未严格遵守软件开发标准。
软件生命周期各阶段需要明确与维护相关的内容:
在需求分析阶段的评审中，需要在需求规格说明中对将来可能修改以及能加以改进的部分进行注明，
在设计阶段的评审中，应从易于维护和提高系统设计总体质量的角度对设计进行全面评审。
在实现阶段的评审中，应主要审查编码风格、代码注释等直接影响代码可维护性的影响。
在测试阶段的评审中，应进行测试的配置复审，目的是确保配置中所有成分的完整、移植、易于理解且便于修改维护。

7.总结

(1)现代软件需求工程包括问题定义、可行性分析、需求分析等阶段。
(2)可行性分析解决的是“值不值得做”的问题，需求分析解决的是“做什么”的问题
(3)需求分析又包含需求获取、需求分析与建模、需求评审
(4)需求分析阶段常用的建模方法有哪几种?
数据流图、实体关系图、状态转换图
(5)实体关系图的用处?
描述数据对象间关系，刻画系统的静态特征。
(6)数据流图的用处?
描绘数据在软件中移动、变换及相应功能。
(7)状态转换图的用处?
描绘系统状态和在不同状态间转换方式。
(8)从测试的不同阶段，软件测试可分为:
单元测试、集成测试、系统测试、验收测试;
(9)从是否需要执行软件的角度，软件测试可以分为:
静态测试、动态测试
(10)从测试是否针对软件结构与算法的角度，又可以分为:
白盒测试、黑盒测试。
(11)软件的可维护性属性:
可理解性、可修改性、可测试性、可靠性、可移植性、可适用性(12)与效率软件维护的类别:
纠错性维护、完善性维护、适应性维护、预防性维护
(12)软件维护常见的工作:
程序维护、代码维护、数据维护、设备维护

如果觉得有一点点用的话给孩纸点个赞吧！！！球球啦！