软件工程
更新: 2021-07-02 11:03:24
1. 关键路径算法
最早开始时间：按照Dijkstra最长路的方法往前走。
最晚开始时间：通过最早开始时间求出终点的时间来之后，所有边反向，按照那个时间从终点往回求dikstra最短路，实质就是更新在正向dij的时候被抛弃的那些废边的时间。
软工的表示方法：AB (1,2) 代表在A的最早开始时间和B的最晚开始时间。第一遍的时候填括号第一个数，第二遍回来的时候填括号的第二个数。
关键节点组成关键路径：最早开始时间和最晚开始时间相等的点，也就是第一遍的最长路。
事件是节点，活动是线。
彪哥资料
所谓关键路径，是项目中诸多活动安排中不能拖延（最费时）的活动路径，一旦拖延则导致整个项目拖延，非关键路径上的活动时间有宽松度，可以晚开始。
求法：
先了解里程碑（节点）的业务顺序，编号。线代表活动，（最早开始时间，最晚开始时间）实际是指该线条的最早、最晚开始时间，应标在该线条的开始处。
（1） 从前往后，确定最早开始时间（从1开始）。对于汇集点，在各分支路径中找出最晚(大)的最早开始时间作为从该汇聚点向后活动线条的最早开始时间。（等前面活动都完成）
（2） 终点处的最早开始时间等于最晚开始时间，-1=整个项目时间。
（3）从终点开始由后往前，减去个活动耗费时长算出各活动的最晚开始时间。对于汇集点，在各分支路径中找出最早(小)的最晚开始时间作为以该汇聚点作为前一活动线条结束点的(或下一阶段各活动中)最小最晚开始时间向前推算。(不耽误后面的最小最晚开始时间)
关键路径：（A-->C-->F-->G-->J-->L）
增加关键路径：再整一条最长路，比如把上图的AE改成10。
2. 故障树和割集树
故障撒播：
3. 白盒测试路径
4. 故障树割集树
知识点整理
按重点分
改变软件开发的因素 图1-11 1-12 1-17
习题1.1 1.3 1.5 1.8
表3-4 图3.6
习题2.11
数据流图
图6-13
7种设计模式
编程规范标准
编程过程：小组协同
集成测试策略6种
修改后自顶向下图8-11
两小组测试例
配置管理
按题目分
传统软工生命周期模型，即瀑布模型，模型图如下：
瀑布模型的优点：
（1）它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
（2）每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
（3）瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。
瀑布模型的优点：
（1）它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
（2）每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
（3）瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。
瀑布模型的缺点：
（1）除了一些理解非常充分的问题之外，实际上软件是通过大量的迭代进行开发的。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（2）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。
现代软工开发模型，取敏捷开发模型，敏捷开发的流程图如下：
敏捷方法的特点（原则）：
（1）个体和交互的价值胜过过程和工具。
（2）可以工作的软件胜过面面俱到的文档。
（3）客户合作胜过合同谈判。
（4）响应变化胜过遵循计划。
传统软工生命周期模型（瀑布模型）与现代软工开发模型（敏捷方法）的不同：
（1）传统软工生命周期模型十分庞大，而敏捷方法打破了这种局面。
（2）敏捷方法强调灵活性在快速有效的软件生产中所发挥的作用，而瀑布模型强调线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。
（3）敏捷方法强调尽可能早的，持续的对有价值的软件的交付活动，以客户满意。瀑布模型强调线性的安排每一个阶段，保证最终交付。
德米特法则又叫做最少知识原则，最初是用来作为面向对象的系统设计风格的一种法则。是一个类对自己依赖的类知道的越少越好，一个对象应当对其他对象尽可能少的了解。德米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。
从迪米特法则的定义和特点可知，它强调以下两点：①、从依赖者的角度来说，只依赖应该依赖的对象。②、从被依赖者的角度说，只暴露应该暴露的方法。
因此，在运用迪米特法则时要注意六个方面：
（1） 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标；
（2） 在类的结构设计上，尽量降低类成员的访问权限；
（3） 在类的设计上，优先考虑将一个类设置成不变类；
（4） 在对其他类的引用上，将引用其他对象的次数降到最低；
（5） 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）；
（6） 谨慎使用序列化（Serializable）功能。
软件开发团队的组织结构有Chief Programmer Team、Egoless Approach等。
Chief Programmer Team即主程序员负责制，由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。特点是：可以使交流最小化、迅速做出决定，缺点是创造性低、对主程序员要求高，个人主观性强。
Egoless Approach即忘我方法，每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。
本学期每次实验任务的最后一条为：“记录项目及小组的最新进度及工作量。记录项目及小组每个人最新的工作的进度、里程碑、工作量的跟踪图或表。每周更新。每人向组长汇报自己工作。组长汇总进度里程牌，提交小组共同报告。”，属于软件工程的软工计划和管理项目领域以及编写程序中文档化领域。
意义： 项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
难点：
(1) 小组里的5个人的时间规划不一，比较难找到交集的片段空闲时间，所以要努力缩短讨论会议时间，在尽可能短的时间内，完成全部的规划和总结。
(2) 工作进度、工作量不好体现，每个人的工作都不相同，难以指定一个相同的量纲。
(3) 大家都不是熟练的软件开发者，都需要一定时间的磨合，并且也需要一定的时间才能上手写代码，很难快速的推进工作进度。
软件文档的作用：
（1）用来记录、描述、展示实施过程中一系列信息的处理过程，通过书面或图示的形式对项目活动过程或结果进行描述、定义、规定及报告
（2）项目文档有助于项目管理水平的提高，在SDUOJ项目文档中，体现了SDUOJ开发进度，实时调整每周目标。
（3）项目文档是项目成果的体现形式，在SDUOJ项目文档中，体现了SDUOJ的架构和开发进度。
（4）提高项目实施过程的能见度。
（5）提高项目的实施效率。
（6）便于项目成员之间的交流与合作，在SDUOJ的对齐文档中，体现了SDUOJ的团队成员的交流和合作。
（7）操作指南文档可帮助最终用户规范化操作，强化培训效果，在SDUOJ外部文档文档中，对用户有培训作用。
（8）有利于项目实施的监控作用
l 工厂模式
l 抽象工厂模式
l 单例模式
l 建造者模式
l 原型模式
l 策略模式
l 责任链模式
l 装饰器模式
按章节分
红蓝色字体没有本质区别，只是题目来源不同和好看罢了😁
第一章
定义：软件工程即用系统科学的工程性方法解决软件开发时遇到的问题，也就是，将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护。
目的：规范软件开发流程，推出高质量的软件产品。
方法：面向对象模式、结构化开发模式、基于过程模式、某种定制的模式等。
作用：降低开发成本，达到要求的软件功能、提高软件性能、提高软件的可移植性、降低维护费用、按时完成工作并交付使用。
**含义：**错误：软件开发过程中⼈为产⽣的错误。（⽐如，代码写错了）
缺陷（故障）：在实现软件功能的时候存在的问题。（一个错误产生多个故障，是静态的）
失败：在运⾏时，软件违背了它应该有的⾏为。（⽐如，使⽤者发现某个计算功能算不出结果，是动态的）
联系：⼈为原因导致错误，错误导致软件缺陷，⽤⼾在使⽤这样的软件时，因为软件缺陷⽽导致软件失败。缺陷 故障 是开发者⻆度的名词，是静态的。失败是⽤⼾⻆度的名词，是动态的。
⼀个好的软件要从三⽅⾯衡量：1、产品质量。2、过程质量。3、商业质量。
1、产品质量：衡量标准有两⽅⾯：⽤⼾和开发者。⽤⼾：⾜够的功能，上⼿简单，易⽤。开发者：从软件的内部特征来衡量，⽐如缺陷的数量。
2、过程质量（软件⽣产过程的质量）：很多事件都会影响过程的质量，并且终影响到软件的质量。量化⽅法：CMM等。
3、商业质量：
技术价值：各种技术指标。（运⾏时间，维护费⽤等）
商业价值：机构对于软件是否与其战略利益相吻合的⼀种战略评估。
⽬标：将技术价值和商业价值进⾏统⼀。
1、重⽤※?重复采⽤以前开发的软件系统中具有的共性部件，⽤到新的开发项⽬中去。2、抽象※?基于某种层次归纳⽔平的问题描述。它使我们将注意⼒集中在问题的关键⽅⾯⽽⾮细节。
3、分析、设计⽅法和符号描述系统?使⽤标准来对程序进⾏描述，利于交流和建模并检查其完整性和⼀致性，利于重⽤。
4、⽤⼾界⾯原型化?建⽴系统的⼩型版,?通常具有有限的关键功能,以利于⽤⼾评价和选择，证明设计或⽅法的可⾏性。
5、测度和度量?通⽤的评价⽅法和体系，有助于使过程和产品的特定特性更加可⻅，包括量化描述系统、量化审核系统。
6、⼯具和集成环境?通过框架⽐较软件⼯程环境提供的服务，以决定其好坏。
1、需求分析完成需求规格说明书（SRS）。
2、系统设计：完成系统结构图（SAD）。
3、程序设计：完成模块功能与数据描述文档。
4、软件开发：完成开发记录文档。
5、单元测试：按照程序设计中的要求进行测试，完成单元测试文档。
6、集成测试：按照SAD测试，完成集成测试文档。
7、系统测试：按照SRS进行测试，完成系统测试文档。
8、系统提交：提交系统说明文档。
9、维护：提交维护记录文档。
第二章
软件开发过程中产生某种期望结果的一系列有序任务，涉及活动、约束和资源。
重要性：
1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。
2、指导性：软件过程使我们可以分析、检查、理解、控制和改善软件开发活动。
3、可以把获得的经验传递给其他人。
1、需求分析和定义 2、系统设计 3、程序设计 编写程序 4、软件开发 5、单元测试 6、集成测试 7、系统测试 8、系统交付 9、维护
需求分析——SRS系统设计——SAD
程序设计——算法和数据描述文档
编码——源程序及注释
单元测试和集成测试——单元测试报告
系统测试——系统测试报告
验收测试——验收测试报告
运行与维护——维护报告
优点：
1、简单性：很容易向用户解释。
2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。
3、每个过程都有相应的提交产物，方便进度评估。
缺点：
1、面对需求变动时，该模型无法实际处理重复开发问题。
2、文档转换时有困难。
概念：⼀种部分开发的产品，⽤来让⽤⼾和开发者共同研究，提出意⻅，为最终的产品定型。
特点：1、原型化设计可以使开发者更容易地提⾼软件质量。2、原型化设计可以提供多种解决⽅案供⽤⼾选择。
UP模型即统⼀过程模型，是⼀种⽤例驱动的，以基础架构为中⼼的，迭代式，增量式的软件开发模型。
该模型的四个阶段：开始阶段、确⽴阶段、构建阶段和移交阶段。
该模型的六道核⼼⼯序：业务模型⼯序、需求⼯序、分析设计⼯序、实现⼯序、测试⼯序和部署⼯序。
RUP模型是IBM提出的提供⽀持和包装的UP模型。
迭代开发是统⼀过程模型（RUP）的关键实践。开发被组织成⼀系列固定的短期⼩项⽬。每次迭代都产⽣经过测试、集成并可执⾏的局部系统。?每次迭代都具有各⾃的需求分析、设计、实现和测试。随着时间和⼀次次迭代，系统增量式完善。
系统被设计成部分提交，每次用户只能得到部分功能，而其他部分处于开发过程中。
基本分类及特点：
1、增量式开发：开始建造的版本是规模小的部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含所有功能的子系统集合。
2、迭代式开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。
3、增量式+迭代式结合开发：一个新发布的版本可能包含新功能，并对已有功能做了改进。
极限编程
十二条原则：？？小版本、重构、结对编程、每周40小时
描述一个过程如何由输入转换为输出。
推演一个过程,用户和开发人员可以看到中间产品和最终产品如何随着时间的推移进行转换。
第三章
项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
活动是项目的一部分，一般占用项目进度计划的一段时间。
里程碑是特定的时间节点，标志着活动的结束，通常伴随着提交产物。
软件开发团队的组织结构有Chief Programmer Team、Egoless Approach等。
Chief Programmer Team其他的成员向其汇报，主程序员对每一个决定有绝对决策权。特点是：可以使交流最小化、迅速做出决定，缺点是创造性低、对主程序员要求高，个人主观性强。Egoless Approach这个要会做题
专家估算法：使用专家的知识和经验，对软件项目的工作量进行评估，是一种经验性的猜测。
一般使用三种方法：
1、类推法：做出三种估计，乐观的、悲观的、最可能的估计，加权平均。
2、Delphi法：几组专家预测，取平均值。
3、Wolverton法：通过计算老问题（O），新问题（N）和容易的（E），适中的（M），困难的（H）这2x3的组合，形成矩阵进行估计。
算式估算法：
E = ( a + bSc ) m (X)
E为工作量，a，b，c都为常数，S是估算的系统规模，X 是一个从X1到Xn的n维度成本因素向量，m是基于该因素的调整因子。
基本模型 （Basic Model）。 是一个静态单变量模型，它用一个以已估算出来的源代码行数 （LOC） 为自变量的函数来计算软件开发工作量。
中间模型 （Intermediate Model）。 则在用 LOC 为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
详细模型 （Detailed Model） 包括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。
COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。
在阶段一，项目通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。
在阶段二，即早期设计阶段，已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念。
在阶段三，即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。
软件开发过程中不希望看到的，有负面结果的事件。
风险管理活动：
风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解
降低风险的策略：
1、避免风险：改变功能和性能需求，使风险没机会发生。
2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。
第四章
1、功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、 实体状态变化、输出结果、设计约束、过程约束等。
2、设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。
3、过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。
4、非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。
第五章
软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。
设计：将需求中的问题转变成软件解决方案的创造性过程。
设计模式：一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。
设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。
分解是把大的系统分解成为更小的部分使问题变得更易于处理，是一种自顶向下方法；另一种自底向上的方法是将笑的模块以及小的构件打包成一个更大的整体，被认为其设计出来的系统更加易于维护。
六种设计方法
(1) 功能性分解 Functional decomposition:按照功能和需求进行分解
(2) 面向特征的分解 Feature-oriented design:功能性分解的一种，为各个模块指定了各自的特征
(3) 面向数据的分解 Data-oriented decomposition :关注如何将数据分解成模块
(4) 面向进程的分解 Process-oriented decomposition:将系统分解成为并发进程
(5) 面向事件的分解 Event-oriented decomposition:将事件分给不同的模块
(6) 面向对象的设计 Object-oriented design:将对象分配给模块
模块化 Modular:只有当系统的每个活动都仅由对应的软件单元实现，并且每个软件单元的输入和输出都已经明确的被定义时，这个设计才是模块化的
(1) 模块化设计 modularity 也称作关注点分离，是一种把系统中各不相关的部分进行分离的原则。在模块化的设计中，构件清晰地定义了输入和输出，设计目标明确，功能独立，可以做独立测试。
(2) 抽象 abstraction：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，是我们集中于问题的关系。当探讨或分析两个模块共享某数据时,模块各自的私有细节应隐藏
(3) 模块都以某种不同层次结构的抽象的形式出现, 越上层、越早期的模块层次或框架是越抽象的设计。将模块化部件和抽象层次结合，顶层模块通过隐藏细节可以给出解决方案，其他层次模块显示主要职能和实施细节，就可以用不同的方式设计不同构件的能力。
1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。
3、文档化：确定各个不同的模型视图。
4、复审：检查文档是否满足了所有需求。
5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。
设计界面要注意解决的要素:
1、隐喻：可识别和学习的基本术语、图像和概念等。
2、思维模型：数据、功能、任务的组织与表示。
3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。
4、外观：系统向用户传输信息的外观特征。
5、感觉：向用户提供有吸引力的体验的交互技术。
文化问题：
设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。
1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。
2、采用定制界面，使不同用户看到不同的界面 。
用户偏好：为具有不同偏好的人选择备选界面。
内聚：
1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。
2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。
3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。
4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。
5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。
6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。
7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。
8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。
耦合：
1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。
2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。
3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。
4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。
5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。
6、非耦合：模块相互之间没有信息传递，但是不太现实。
第六章
第七章
在代码中保持设计质量
- 全局化的输入和输出：分离！
- 包含伪代码：不直接实现
- 改写和重写，而不是打补丁
- 复用：① 生产者复用是指正在设计的构件要在以后的应用中进行复用 ② 消费者复用是指正在使用的构件是原先为其他项目开发的构件。
需要添加其他程序注释——
（1）解释性注释：本段源代码是在做什么的注释。
（2）分解性注释：通过注释将代码分解成多个段。
（3）版本注释：随着时间进行修改的记录。
注意的问题：
1、分段注释。
2、注释和代码要一并更改。
3、注释要有意义。
4、一边写代码一边写注释，不要写完代码回过头来添加注释。
极限编程（XP）：是一种轻量级的软件开发方法，属于敏捷开发方法。它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
派对编程：一种敏捷开发方法，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。
第八章
1、算法缺陷算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。
2、计算和精度缺陷：算法或公式在实现时出现错误，或计算结果的精度达不到要求。
3、文档缺陷：文档和程序不一致。
4、过载缺陷：程序运行时，对数据结构的使用超过了其承载能力。
5、能力缺陷：程序活动到达极限时，其性能会变得不可接受。
6、时序性缺陷：多个同时执行或者一个仔细定义的顺序执行的进程之间协调不当。
7、性能缺陷：系统性能达不到要求。
8、恢复性缺陷：系统运行失败后无法恢复。
9、硬件和系统软件缺陷：提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。
10、代码的标准和规程缺陷。代码没有遵循组织机构的标准和过程。
1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。
2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。
3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。
4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。
5、验收测试：确定系统是按照用户的期望运转的。
6、安装测试：确保系统在实际环境中按照应有的方式运转。
7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。
1、黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。
2、白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。
黑盒测试方法：
1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。
2、边界值分析法：把测试值选在等价类的边界上进行测试。
3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。
4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。
驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。
桩：用于模拟测试时缺少构件时的活动的程序。可以使测试能够正常的进行下去，即代替下层模块的应答程序。
1、自底向上集成
先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。
2、自顶向下集成
先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。
3、一次性集成
先测试每一个模块，之后将所有模块一并集成。
4、三明治集成
将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。
第九章
分类：1、压力测试：短时间内加载极限负荷，验证系统能力
2、容量测试：验证系统处理巨量数据的能力。
3、配置测试：测试各种软硬件配置(最小到最大)。
4、兼容性测试：测试接口等。
5、回归测试：如果这个系统要替代现有系统时需要进行此测试。
6、安全性测试
7、计时测试
8、环境测试
9、质量测试
10、恢复测试
11、维护测试
12、人为因素测试
更新: 2021-07-02 11:03:24
原文: https://www.yuque.com/qer233/sdu_note/se