1、运算器：由算术逻辑单元（ALU）、累加寄存器、数据缓冲寄存器和状态条件寄存器组成。是数据加工的处理部件，完成计算机的各种算术和逻辑运算。
2、控制器：用于控制整个CPU的工作，决定了计算机运行过程的自动化，不仅要保证程序的正确执行，而且要能狗处理异常的事件。控制器包好：程序计数器（PC）、指令寄存器（IR）、地址寄存器（AR）、指令译码器（ID）、时序部件等。
3、浮点数：能够表示的数的范围是由其【阶码】的位数决定的。
4、网桥：用来连接不同网段。
5、集线器：是对接收到的信号进行再生整形放大，以扩大网络的传输距离，同时把所有节点集中在以它为中心的节点上。集线器是物理层设备，而网桥是数据链路层设备
6、路由器：连接因特网中各局域网、广域网的设备，它会根据信道的情况自动选择和设定路由，以最佳路径，按前后顺序发送信号。能隔离局域网中广播风暴、提高带宽利用率。
7、交换机和路由之间的主要区别就是：交换机发生在OSI参考模型第二层（数据链路层 ），路由发生在第三层（网络层）。
8、交换机：为接入交换机的任意两个网络节点提供独享的电信号通路。交换机可用于划分数据链路层广播，即冲突域。
9、管理距离决定了路由的优先，管理距离越低说明路由优先级更高。
10、适配器模式：将一个类的接口适配成用户所期待的，一个适配允许通常因为接口不兼容而不能在一起工作的类工作在一起。
11、命令模式：将一个请求封装成一个对象，从而使得可以用不同的请求对客户进行参数化，队请求排队或记录请求日志，以及支持可撤销的操作。
12、装饰模式：在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能。
13、代理模式：为一个对象提供代理以控制该对象的访问。
14、桥接模式：将抽象部分与它的实现部分分离，使他们都可以独立的变化。（将一个抽象与其实现分离开，以便两者能够各自独立的演变）
15、策略模式：定义一系列的算法，把他们一个个封装起来，并且使它们可以相互替换。
16、观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
16、瀑布模型：要求开发人员经过的事件序列。
17、原型模型：允许开发人员快速的构造整个系统或系统的一部分。
18、创建型模式：单例、抽象工厂、建造者、工厂、原型
19、结构型模式：适配器、桥接、装饰器、组合、外观、享元、代理
20、行为型模式：模板方法、命令、迭代器、观察者、中介者、备忘录、解释器、状态、策咯、职责、责任链、访问者
21、数据流图是在【需求分析】阶段产生的成果。
22、一般来说模块内聚性由低到高有：巧合内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚和功能内聚七种类型。
①逻辑内聚：一个模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。
②时间内聚：一个模块完成的功能必须在同一时间内执行（如：系统初始化），但这些功能只是因为时间因素关联在一起的内聚模式。
③功能内聚：一个模块中各个部分都是完成某一个具体功能必不可少的组成部分。
④通信内聚：模块内所有处理元素都在同一个数据结构上操作，或者指各处理使用相同的输入结构或产生相同的输出数据。
23、一般来说，模块之间的耦合有七种类型，根据耦合性从低到高为：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合和内容耦合。
①内容耦合：一个模块直接访问另一个模块的内部数据、一个模块不通过正常入口转到另一个模块内部、两个模块有一部分程序代码重叠或者一个模块有多个入口。
②标记耦合：一组模块通过数据结构本身传递。
③控制耦合：模块间传递的信息不但有数据，还包括控制信息。
④数据耦合：一个模块访问另一个模块时，彼此之间通过数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的。
24、软件维护一般包括正确性维护、适应性维护、完善性维护和预防性维护。
①正确性维护是指改正在系统开发阶段已经发生而在系统测试阶段尚未发生的错误。
②适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
③完善性维护为扩充功能和改善性能而进行的修改。
④预防性维护是为了适应未来的软硬件环境的变化，主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。
25、瀑布模型适合需求确定的应用；原型模型适合于需求不确定的情况，开发一个大型软件产品的图形用户界面；V模型只是将瀑布模型中的测试部分做了细化，其最大特点（可能也是最大的缺点）就是“线性执行”，测试的工作在编码完成后才开始进行；螺旋模型结合了瀑布模型和原型模型两类模型，并加入了风险分析，适合于大型复杂软件系统的开发。
26、软件评价过程的特性包括可重复性、可再现性、公正性和客观性。①可重复性：由同一评价者按同一评价规格说明对同一产品进行重复地评价，应产生同一种可接受的结果；②可再现性：由不同评价者按同一评价规格说明对同一产品进行评价，应产生同一种可接受的结果；③公正性：评价应不偏向任何特殊的结果；④客观性：评价结果应是客观事实，不带有评价者的感情色彩或主观意见。
27、按照开发阶段软件测试可以分为单元测试、集成测试、系统测试、确认测试和验收测试。①单元测试是针对软件程序模块进行正确性检验的测试工作；②集成测试是检验程序单元或部件的接口关系，即针对软件体系结构的构造进行的测试；③系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试；④确认测试是检验与证实软件是否满足软件需求说明书中规定的要求；⑤验收测试是按照项目任务书或合同、约定的验收依据文档等进行的整个系统的测试与评审，决定是否接收或拒收系统。
28、负载测试：是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的情况；
29、压力测试：是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试；
30、疲劳强度测试：是采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程；
31、大数据量测试：包括独立的数据量测试和综合数据量测试，独立数据量测试是指针对系统存储、传输、统计、查询等业务进行的大数据量测试；综合数据量测试是指和压力测试、负载测试、疲劳强度测试相结合的综合测试。
32、单元测试：是针对软件程序模块进行正确性检验的测试工作
33、集成测试：是检验程序单元或部件之间的接口关系，即针对软件体系结构的构造进行测试。
34、系统测试：是为验证和确认系统是否达到原始目标，而对集成的硬件和软件系统进行测试。
35、确认测试：是检验与证实软件是否满足软件需求说明书中规定的要求。
36、验收测试：按照项目任务书或合同、约定的验收依据文档等进行的整个系统的测试与评审，决定是否接收或拒收系统。
37、软件错误：指软件在生存周期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。
38、软件故障：软件运行过程中出现的一种不希望或不可接受的内部状态
39、软件失效：软件运行时产生的一种不希望或不可接受的外部行为结果。
40、软件缺陷：是存在于软件（文档、数据、文档）之中的那些不希望或不可接受的偏差。
41、缺陷探测率（DDP）：是衡量测试投资回报的一个重要指标。
42、需求规格说明书：是导致软件缺陷的最大原因。
43、IEEE829标准，《测试案例说明》包含的内容为：输入说明、环境要求、特殊要求
44、测试执行过程的阶段为：初测期、细测期、和回归测试期
45、软件成本控制的目标是：使测试开发成本、测试实施成本和测试维护成本最小化。
46、程序运行过程中常使用参数在函数（过程）间传递信息，引用调用传递的是实参的：地址。
47、后缀式的特点：是将运算符号写在运算数的后面。对于表达式，其计算次序是相减、相乘、相加
48、“中间代码”是一种简单且含义明确的记号系统，建立在对程序的控制流和数据流分析的基础之上进行优化，与具体的机器无关。
49、段页式存储：页的大小=2的页内地址长度次方=***K，比如：页内地址的长度是12位，2的12次方＝4096，所以页的大小为4K。每个段最大允许有4096个页。 段号的地址长度为8位，2的8次方，最多可有256个段。
50、隧道协议将其它协议的数据帧或包重新封装然后通过隧道发送，两个IPv6结点可以使用隧道技术将IPv6的数据包封装并在IPv4的信道上传输。翻译技术用于解决两种不同协议间的互联互通，纯IPv6结点与纯IPv4结点可以经过翻译技术进行通信。
51、POP3协议是邮局协议，采用C/S模式进行通信，运行在TCP连接上。
52、类是一组具有相同结构、相同服务、共同关系和共同语义的对象集合。
53、软件可靠性度量活动属于：概要设计阶段
54、软件可靠性活动属于：需求分析阶段
55、软件的易用性包括：①易理解性；②易学习性；③易操作性；④吸引性；⑤依从性。
56、MD5、SHA-1、SHA-256均属于典型的生成消息摘要的算法，而RSA是常用的公钥加密算法。
继承关系:表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。图示:带空心三角箭头的实线，箭头指向父类。
关联关系:是一种拥有的关系，它使一个类知道另一个类的属性和方法。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。图示:带普通箭头的实心线，指向被拥有者。组合关系:是整体与部分的关系，但部分不能离开整体而单独存在。图示:带实心菱形的实线，菱形指向整体。
依赖关系:是一种使用的关系，即一个类的实现需要另一个类的协助。图示:带箭头的虚线，指向被使用者。因为是依赖关系，在代码实现时，EmployeeRecord应为Employee某个方法的参数/返回值/局部变量。
瀑布模型:是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
瀑布模型有以下优点:
1、为项目提供了按阶段划分的检查点
2、当前一阶段完成后，您只需要去关注后续阶段
3、可在迭代模型中应用瀑布模型。
4、它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型有以下缺点:
1、各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2、由于开发模型是线性的，用户只有等到整个过程的未期才能见到开发成果，从而增加了开发风险
3、通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4、瀑布模型的突出缺点是不适应用户需求的变化。
适配器模式:将一个类的接口适配成用户所期待的。一个适配允许通常因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包裹在一个已存在的类中。
桥接模式:将抽象部分与它的实现部分分离，使它们都可以独立地变化。
装饰模式:指的是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。
代理模式:为一个对象提供代理以控制该对象的访问。
类之间的关系主要有以下几种:
(1)继承（泛化）关系:是指子类自动地具有其父类的全部属性与操作，也称为父类对子类的泛化。在UML建模语言中，采用空心三角形表示，从子类指向父类。
(2)关联关系:是指两个或多个类之间的一种静态关系，表现为一个类是另一个类的成员变量。在UML类图中，用实线连接有关联的对象所对应的类
(3)聚合关系:是整体与部分之间的关系，是强的关联关系。在UML中，聚合关系用带空心菱形的实心线，菱形指向整体
(4)依赖关系:也是类之间的一种静态关系，表现为一个类是另外一个类的局部变量。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的方。
瀑布模型：将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段的过程。
原型模型中，开发人员快速地构造整个系统或者系统的一部分以理解或澄清问题。
螺旋模型将开发活动和风险管理结合起来，以减小风险。
喷泉模型开发过程模型以用户需求为动力，以对象为驱动，适合于面向对象的开发方法。
(1)按照测试目的可以划分为:功能自动化测试工具，性能自动化测试工具和信息安全自动化测试工。
(2)按测试工具所访问和控制的接口划分可分为:用户界面自动化测试工具，接口自动化测试工具。
(3)按测试工具所重点对应的测试阶段划分可分为单元自动化测试工具，集成自动化测试工具和系统自动化测试工具(通常系统级别自动化测试为用户界面自动化测试);
(4)按照测试对象所在操作系统平台划分可分为:Web 应用测试，安卓移动应用测试，ios 移动应用测试。Linux 桌面应用测试，Windows 桌面应用测试
(1)按照研发阶段:单元测试、集成测试、确认测试、系统测试、验收测试
(2)按照测试实施组织划分: 开发方测试、用户测试和第三方测试。
(3)按照测试方式划分:静态测试和动态测试
(4) 按照测试技术划分:黑盒测试、白盒测试和灰盒测试。
单元测试是针对软件程序模块进行正确性检验的测试工作;
集成测试是检验程序单元或部件的接口关系，即针对软件体系结构的构造进行的测试;
系统测试是为验证和确认系统是否达到其原始目标而对集成的硬件和软件系统进行的测试;
确认测试是检验与证实软件是否满足软件需求说明书中规定的要求;
验收测试是按照项目任务书或合同、约定的验收依据文档等进行的整个系统的测试与评审，决定是否接收或拒收系统。
易用性测试不仅是针对应用程序的测试，而且还包括用户手册等系列文档。
安装测试就是按照用户安装手册安装软件，来评估安装过程的易用性、正确性。
辅助系统测试包括帮助测试、向导测试、信息提示测试等。
界面整体测试是指对界面的规范性、一致性、合理性等进行测试和评估。
1、极限编程XP是激发开发人员创造性、使得管理负担最小的一组技术。
2、水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论。
3、并列争球法(Scrum)使用迭代的方法，其中把每30天一次的迭代称为个冲刺，并按需求的优先级来实现产品多个自组织和自治小组并行地递增实现产品，协调是通过简短的日常情况会议进行。
4、自适应软件开发(ASD)有六个基本的原则D在自适应软件开发中，有一个使命作为指导，它设立了项目的目标，但不描述如何达到这个目标;
2特征被视为客户键值的关键，因此，项目是围绕着构造的构件来组织并实现特征;
3过程中的迭代是很重要的，因此重做与做同样重要，变化也包含其中;
4变化不视为是一种更正，而是对软件开发实际情况的调整;
5确定的交付时间迫使开发人员认真考虑每一个生产版本的关键需求;
6风险也包含其中，它使开发人员首先跟踪最艰难的问题。
XP的12个最佳实践为: 计划游戏、小型发布、隐喻简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准