【软件测试与质量保证】期末复习笔记：
第一部分：质量保证相关内容
内容来源于授课ppt以及云班课题目
更多复习资料在下方链接获取；包括复习笔记（有具体习题）、习题答案以及设计题示例
链接：复习资料
复习笔记里的习题不包含答案，具体答案在【云班课答案】文件夹中，顺序都是一一对应的，喜欢刷题可以刷一刷（hhh）
【如果对于文章以及资料的内容有任何问题，或者对于考试的内容有任何问题，欢迎在评论区留言或者私聊我，需要考试真题也可以找我（虽然感觉参考意义不太大）】
第一章-质量
填空+选择
- 与质量相关的概念：组织、过程、产品、服务、客户、体系
- 质量的定义：
a. ISO 9000的定义：质量是一组固有特性满足要求的程度
b. IEEE的定义：质量是系统、部件或过程满足客户或用户明确需求或期望的不同程度 - 质量不仅要满足明示的需求，而且要满足暗示的需求
- 质量属性：客户属性、成本属性、社会属性、可测性、可预见性
- 客户分为内部客户和外部客户
a. 内部客户分为4种：职级客户、职能客户、工序客户和流程客户 - 不同的质量观点：
a. 制造者的观点：质量是产品性能和规格要求的符合度
b. 产品观点：质量是联结产品固有性能的纽带
c. 用户观点：质量是产品满足使用目的之程度
d. 基于价值观点：质量依赖于顾客愿意付给产品报酬的数量 - 质量概念的发展：符合性质量——>适用性质量——>广义质量
- 质量管理： 是指在质量方面指挥和控制组织的协调的活动
- 著名的质量管理专家朱兰提出的质量管理三步曲是指 ：质量策划、质量控制、质量改进
a. 质量策划：致力于制定质量目标并规定必要的运行过程和相关资源以实现质量目标
b. 质量控制：是消除偶发性问题，使产品质量保持规定的水平
c. 质量改进：质量管理的一部分，致力于增强满足质量要求的能力 - 质量方针是一个组织总的质量宗旨和方向，应由组织的（ 最高管理者 ）批准。
- 在质量控制、质量保证和质量管理之上的是质量方针
- 由于组织的顾客和其他相关方对组织的产品、过程和体系的要求是随着时间不断变化的，这体现了质量的（ 时效性）
- 从适合顾客需要的角度对产品质量下定义被称为（ 适用性质量 ）
- 质量是一组固有（ 特性 ）满足要求的程度
判断
- 质量检验是对产品质量特性进行检验，以确定每项质量特性合格情况的管理性检查活动（×）
- 持续改进总体业绩应当是组织应追求的目标（√）
- 质量改进是质量管理的一部分，致力于增强满足质量要求的能力（√）
- 质量控制是按照一个设定的标准去实施检验（×）（概念错误）
- 服务是产品类别中的一类（√）
- 质量特性是指产品、过程或体系与标准有关的固有特性（×）
- “符合标准”就是合格的产品质量（×）
- 不合格品控制时，请示领导决定是否可用（×）
- 质量管理体系是为实现质量方针和质量目标而建立的管理工作系统（√）
- 珍视顾客抱怨，把它作为我们研发产品、改善质量、提升服务的动力源泉（√）
- 质量改进和质量控制都是为了保持产品质量稳定（×）（质量改进不是）
- 当生产过程处于受控制状态时，产品质量就不会波动（×）
- 质量控制是消除偶发性问题，使产品质量保持规定的水平（√）
- 质量管理是指在质量方面指挥和控制组织的协调的活动（√）
第二章-软件质量
ppt内容：
1.软件特点
2. 软件过程
3. 软件缺陷
4. 软件质量
5. 软件质量的内容
填空＋选择
- 软件开发的基本过程：需求分析、设计、编程、测试、维护
- 软件开发过程模型：瀑布模型、原型模型、螺旋模型、并发模型、V模型、构件组装模型
- V模型中设计与测试之间的对应关系：
a. 需求分析定义——验收测试
b. 系统、结构设计——系统测试
c. 详细或程序设计——功能测试
d. 编码——单元测试 - V 模型造成需求分析阶段隐藏的问题一直到后期的验收测试才被发现
- 需求分析要确定软件产品所能达到的目标
- 测试是对设计、编程进行验证和用户需求确认的过程
- 极限编程适合：小团队、高风险、快速变化或不稳定的需求、强调可测试性
- 极限编程的主要特点有：简单的分析设计、频繁的客户交流、增量式开发和连续的测试
- 据权威部门统计，软件错误产生的原因分布图表中，（软件需求规格说明错误）是导致软件错误的主要原因
- 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题
- 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背
- 软件错误是缺陷的一种，属于内部缺陷，往往是软件本身的问题
- ANSI/IEEE STD729给出了软件质量定义：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。
- SEI的Watts Humphrey认为软件质量是在实用性、需求、可靠性、可维护性等方面，达到优秀的水准
- 用户要求在性能方面包含哪些质量特性：效率性、安全性、正确性、互操作性
- 用户要求在功能方面包含哪些质量特性：完整性、可靠性、生存性、可用性、便利性
- 软件质量的3维特性指的是：功能性、可靠性、性能
- 软件质量的3A特性指的是：可说明性、有效性、易用性
- 软件质量的定义包含三个方面：软件产品的质量、软件开发过程的质量、软件在其商业环境中的质量
判断
- 有关质量的好坏最终评价依赖于用户的反馈（√）
第三章-软件质量工程体系
ppt内容：
1 概述
2 软件质量因素和指标
3 软件质量模型分析
4 软件质量工作层次（质量管理、质量方针等概念）
5 软件质量成本
6 软件质量标准和度量
填空＋选择
- 系统工程学是为了研究多个子系统构成的整体系统所具有的多种不同目标的相互协调，以期系统功能的最优化、最大限度地发挥系统组成部分的能力而发展起来的一门科学
- 软件工程概念的提出是由于（ 软件危机的出现 ）
- 质量指标是衡量那些可识别的软件质量特性的项目
- 影响软件质量特性或影响软件指标的参数叫做软件质量因素；分为软件产品的质量因素和软件过程的质量因素
- ISO9126将各种质量属性归纳为6个质量特征，其中包括：功能性、可靠性、可使用性、效率、可维护性、可移植性
- 软件的6个品质要素包括：正确性、可靠性、易用性、效率、可维护性、可移植性
- 系统可维护性的评价指标包括：可理解性、可测试性、可修改性（不包括可移植性）
- 软件质量指标和软件质量因素的分析是为了建立软件模型
- 软件模型是描述他们之间的关系，分析软件质量因素究竟如何影响质量指标的
- 软件质量模型有McCall 软件质量模型、Boehm 模型和ISO简化的软件质量模型
- McCall模型产品修订纬度的质量因素有可维护性、 灵活性、可测试性
- 在质量控制、质量保证和质量管理之上是质量方针
- 软件质量工程包括软件质量方针、软件质量控制 、软件质量保证和软件质量管理四大方面
- 软件质量保证分为内部质量保证和外部质量保证
a. 内部质量保证：组织向自己的管理者提供信任
b. 外部质量保证：组织向外部客户或其它方提供信任 - 软件质量保证包括复审和内审环节
- 六西格玛模型分为5个阶段，分别是：界定、测量、分析、改进、控制
- IDEAL模型将质量改进过程划分为5个阶段，分别是：初始化、诊断、建立、行动、学习
- 质量成本包括保证成本和损失成本，保证成本包括预防成本和评价成本
- 劣质成本：故障成本、过程成本、损失成本
- 软件质量度量包括项目质量度量、产品质量度量、过程质量度量
- 采用定量软件工程，制定软件产品质量的度量准则，可以提高软件开发过程管理的可视性 ，降低劣质成本 ，提高软件产品的质量
判断
- 软件可靠性是指一个系统或组件在某个特定时期、特定条件下完成所需完成的功能的能力（√）
第四章-软件质量度量
ppt内容：
1测量基础
2软件开发生命周期的度量活动
3软件项目的质量度量
4软件产品的质量度量
5软件过程的质量度量
6软件质量度量中的统计分析
填空＋选择
- 语法构造方法计算缺陷率：缺陷率= 0.15 + 0.23 DO WHILE + 0.22 SELECT + 0.07 IF-THEN-ELSE
- McCabe环形计算公式为：
a. V(G) = D (D:区域数)
b. V(G) = E – N + 2 (E:流图中边的条数; N:流图中结点数)
c. 例题： 该题的图示对应着以下程序： - 度量是对软件产品进行范围广泛的测度，它给出一个系统、构件或过程的某个给定属性的度的定量测量
- 测量是对产品过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指标
- 测量标准中最重要的指标是：有效性和可靠性
- 度量尺度包括：分类尺度、序列尺度、间隔尺度、比值尺度
- 软件质量度量按其研究对象可分为3类：项目质量度量、产品质量度量、过程质量度量
- 软件项目质量度量的主要内容包括： 规模度量、 复杂度度量、 缺陷度量、 进度度量、 风险度量、 工作量度量以及其他一些度量项目
- 软件产品质量度量包括软件规模大小、产品复杂度、设计特征、性能、质量水平
- 软件过程质量度量要素分为共性过程质量要素和个性过程质量要素两大类
- 对软件过程质量的改进围绕改善软件质量、提高生产效率和降低成本这三方面展开
- 修复软件缺陷费用最高的是（ 发布 ）阶段
a. 对于应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来
判断
- 质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现（√）
- McCabe度量、语法构造方法只适合独立模块内部进行测量，不能考虑系统各个模块间相互耦合的关系（√）
- 软件度量应基于分析模型、设计模型或程序本身的结构进行，而独立于编程语言的句法和语法之外（√）
- 测量的目标是不断提高有效性和可靠性，测量可以避免出现偏差或误差（×）
- 可靠性差一般意味着测量方法在技术上有待改进（√）
a. 可靠性指的是使用同样的测量方法对同样的事物进行多次测量，得到值的一致性。多次测量的值越接近，可靠性就越高；反之则可靠性越低 - 有效性差一般意味着测量k方法在原则性上有错误（√）
a. 有效性指的是测量的结果正确反映了被测试对象的实际状况和程度、或合乎事务的发展、变化的规律 - 度量是为了获取指标评估量化结果的重要手段和方法（√）
- 软件度量具有相对性强，绝对性弱的特点（√）
- 软件质量度量就是用来衡量软件质量控制和保证的过程和结果的（√）
第五章-软件质量标准
ppt：概述＋CMMI（能力成熟度）模型
填空+选择
- 根据软件工程标准制定的机构和标准适用的范围，可将其分为5个级别：国际标准、国家标准、行业标准、企业规范、项目规范
- CMM将整个软件改进过程分为：初始级、可重复级、已定义级、已管理级、优化级
- CMMI的内容主要有3个级别：必需的、期望的、提供信息的
a. “必需的"级别，是模型和过程改进的基础；“必需的”级别的构件 ：目标
b. “期望”在过程改进中起到主要作用，但是某些情况不是必须的、可能不会出现在成功的组织模型中；“期望的”级别的构件 ：方法
c. "提供的信息"构成了模型的主要部分，为过程改进提供了有用的指导，在许多情况下他们对"必需"和"期望"的构件做了进一步说明 - CMM模型将软件过程的成熟度分为 5 个等级，在（ 管理级 ）使用定量分析来不断地改进和管理软件过程
- CMM的意义不仅仅是对软件开发的过程进程控制，还是一种高效的管理方法，有助于企业最大程度的降低成本、提高质量和用户满意度
- 软件设计需要注意哪些问题：（减少耦合、代码重用、功能分解）
- 根据CMMI规范，每一个软件企业均具有（ 等级五 ）成熟度
- CMMI流程改进基本上可归纳为：
a. 确定流程改进的总体框架
b. 细化框架内的要求
c. 明确流程改进的度量方法与标准
判断
- 软件过程能力成熟度是指一个特定过程被明确定义、管理、测量、控制并且是有效的程度（√）
- 为了达到一个成熟度等级，必须实现该等级上的全部关键过程区域（√）
- 优化级说明已管理的过程，定义了评估软件过程和产品质量的度量。利用此度量对软件过程和产品做出推断和控制（×）（是已管理级的功能）
第六章-软件评审
ppt内容：
1 为什么需要评审
2 评审的内容
3 评审的方法和技术
4 评审会议
5 如何实施成功的评审
填空＋选择
- 评审分为：管理评审、技术评审、文档评审和过程评审
- 管理评审由最高管理者发起
- 管理评审要求各部门对管理体系目前的状况，包括：适宜性、有效性、充分性
- 技术评审是对产品以及各个阶段的输出内容进行评估
- 技术评审的作用：
a. 揭示软件在逻辑、执行以及功能和函数上的错误
b. 验证软件是否符合需求
c. 确保软件的一致性 - 文档评审包括：需求评审、设计评审、代码评审、质量验证评审
- 过程评审是对软件开发过程的评审，主要任务是通过对流程的监控，保证SQA组织定义的软件过程在项目中得到了遵守，同时保证质量方针能得到更快更好地执行
- 过程评审的目的（作用）：
a. 评估主要的质量保证流程
b. 考虑如何处理/解决评审过程中发现的不符合问题
c. 总结和共享好的经验
d. 指出需要进一步完善和改进的地方 - 评审的方法：临时评审、轮查、走查、小组评审、审查（从不正式到正式）
a. 审查是评审方法中最正式、最严格、最有效的评审方法 - 选择评审方法最有效的标准是：对于最可能产生风险的工作成果，要采用最正式的评审方法
- 评审会议的主要步骤（3步）：
a. 由评审员/作者进行演示或说明。
b. 评审员会就不清楚或疑惑的地方与作者进行沟通
c. 协调人或记录员在会议过程中完成会议记录 - 需要评审的资料有（4部分）（最危险和最复杂的部分）：
a. 基础性和早期的文档，如需求说明和原型等
b. 与重大决策有关的文档，如体系结构模型
c. 对如何做没有把握的部分，如一些挑战性模块、不熟悉的或复杂的算法等
d. 将不断被重复使用的部件 - 对评审组长的要求如下：
a. 善于制定和执行评审计划
b. 评审是公平、公正的
c. 具有丰富的技术技能和知识
d. 积极带领评审组员按时保质的完成评审任务 - 评审小组的角色构成：协调人、SQA人员、评审员
- 在软件设计中，设计复审是和软件设计本身一样重要的环节，其主要的目的和作用是为了能够（ 避免后期付出高代价 ）
判断
- 发现缺陷的平均成本不应该超过该缺陷遗留给客户的商业成本（√）
- 评审报告可以看作是评审会结束的标志（√）
- 规则集列出了容易出现的典型错误，是评审的一个重要组成部分（×）（不是规则集，应是缺陷检查表）
a. 规则集：类似于缺陷检查表，通常是业界通用的规范或者企业自定义的各种规则的集合 - 过程评审的评审对象是质量保证流程，以及针对产品质量或其他形式的工作产出（×）
a. 过程评审是对软件开发过程的评审，主要任务是通过对流程的监控，保证SQA组织定义的软件过程在项目中得到了遵守，同时保证质量方针能得到更快更好地执行；通过定义可以看到，评审对象不是质量保证流程 - 文档评审分为格式评审和内容评审（√）
- 管理评审是对产品以及各阶段的输出内容进行评估（×）（技术评审是对产品以及各个阶段的输出内容进行评估）
- 管理者、开发人员、客户有时都反对评审，因为评审会浪费时间，减缓项目的进度（×）
- 评审是对软件元素或者项目状态的一种评估手段（√）
- 评审是质量控制方面一种非常有效的方法（√）
- 同行评审的主要目标在于检测错误、核对与标准的偏离（√）
- 代码评审是检查源代码是否达到模块设计的要求（×）（还有编码规范、代码结构等等）
- 技术评审即是一种技术手段，也是一种质量管理手段（√）
第七章-SQA（软件质量保证）组织活动
ppt内容：
1 软件质量管理组织介绍
2 SQA组织结构和角色
3 SQA组织的目标和责任
4 SQA人员的培养
填空＋选择
- 为了保证项目组能够采用合适的技术和工具，我们应该进行（ 软件工具的评估 ）
- 独立的SQA部门的优缺点：
a. 优点：①保护SQA工程师的独立性和客观性；②有利于资源的共享
b. 缺点：①难于深入项目并发现关键问题；②SQA工程师发现的问题不能及时解决 - 独立的SQA工程师（非独立SQA小组）的优缺点：
a. 优点：①能够深入项目发现实质性问题②SQA工程师发现的问题能够及时解决
b. 缺点：①SQA工程师之间缺乏沟通和交流②独立性和客观性不足 - SQA组织不负责生产高质量的软件产品、制定质量计划
- SQA组织的目标：
a. 以独立的审查方式监控软件生产任务的执行
b. 提供反映产品质量的信息和数据
c. 辅助软件工程组得到高质量的软件产品 - SQA组织的责任：
a. 审计软件经理和软件工程组的质量活动
b. 鉴别活动中出现的偏差 - SQA计划的实施步骤：
a. 了解项目的需求，明确项目SQA计划的要求和范围
b. 选择SQA任务
c. 估计SQA的工作量和资源
d. 安排SQA任务和日程
e. 形成SQA计划
f. 协商、评审SQA计划
g. 批准SQA计划
h. 执行SQA计划 - SQA评审和审核：
评审：过程进行时，SQA对过程的检查
审核：在软件工作产品生成时，对其进行的检查 - 主要的SQA评审有：软件需求评审、概要设计评审、详细设计评审、管理评审、软件验证与确认评审
- 主要的SQA审核有：功能审核、物理审核、综合审核
- SQA计划实施步骤的第一步是 （ 了解项目的需求，明确项目SQA计划的要求和范围 )
- SQA评估任务主要是在软件开发前期对项目的软件和硬件资源进行评估，以确保其充分性和适合性；包括软件工具的评估和项目设施的评估
- 六西格玛组织从上到下分为：倡导者、黑带主管(大师)、黑带、绿带
a. 黑带大师是6σ管理专家的最高级别
b. 统计学方面的培训必须由黑带大师来主持 - （ 项目的进度管理 ）是一个动态的过程，需要不断调度、协调，保证项目的均衡发展
判断
- 任何不符合客户需求的地方都可以认为是缺陷（√）
- 审核是对工作流程的评审，而评审则主要侧重产品本身（×）（说反了）
a. 评审：过程进行时，SQA对过程的检查
b. 审核：在软件工作产品生成时，对其进行的检查 - SQA组织负责生产高质量的软件产品和制定质量计划，责任是审计软件经理和软件工程组的质量活动并鉴别活动中出现的偏差（×）（SQA不负责该部分内容）
- SQA人员与开发工程师本质上是对立的（×）
- 为了让SQA人员可以全心投入本职工作，所以SQA人员必须是全职的（×）
- 创建SQA部门的时候，与企业本身实际相比，更重要的是参考业界流行的各种标准（如ISO、CMMI等）（×）
- 软件工程过程组类似于一个“立法”机构，而SQA则类似于一个“监督”机构（√）
- 所有SQA活动和项目里程碑的完成或项目里程碑的检验是同时发生的（×）
- 在整个机构中使用基础设施防护与改进部件的主要目标是在机构积累的SQA经验基础上消除或至少降低出错率（√）
- 软件质量系统之间各不相同，说明机构SQA系统构建存在固有灵活性（√）
- 在软件产品制定生产计划阶段,不必进行重大的SQA活动（×）
第八章 提高软件设计质量
ppt内容：
1 软件设计
2 软件体系结构
3 软件设计模式
4 软件设计优化
5 一些典型的系统设计
6 数据库设计质量
填空＋选择
- 软件设计的两个阶段：软件体系结构设计、详细设计
a. 体系结构设计：高层次设计，将软件需求转化为数据结构和软件的系统结构，并定义子系统和它们之间的通信或接口
b. 详细设计：通过对结构表示进行细化得到软件软件详细的数据结构和算法，包括对所有的类都详尽地进行描述，给编写代码的程序员一个清晰的规范说明 - 软件体系结构设计的基本任务：
a. 设计软件系统结构
b. 数据结构及数据库设计
c. 编写概要设计文档
d. 概要设计文档评审 - 详细设计就是考虑在技术上如何实现以设计好的体系结构
- 软件设计评价3类标准：实体空间标准、过程空间标准、形式空间标准
- 软件设计的基本原则：设计过程中，始终以质量为目标而展开、设计越简单越好
- 软件设计的指导思想：降低模块耦合度、提高模块内聚性
a. 耦合度从低到高排序：非直接耦合、数据耦合、特征耦合、控制耦合、外部耦合、公共环境耦合、内容耦合（耦合度越高，模块独立性就越低）
b. 内聚性由低到高排序：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、信息内聚、功能内聚（内聚性越高，模块独立性就越高） - 软件设计的总体原则：
a. 用户需求远比技术重要
b. 需求其实很少改变，改变的是对需求的理解
c. 接受变化
d. 不要低估软件规模的需求
e. 在软件设计中没有捷径可以走
f. 任何体系结构都有它自身的优点和缺点，设计模式也一样
g. 沟通对设计质量的提高同样重要
h. 工具只是手段，不能代替一切
i. 理解完整的软件开发过程
j. 常作验证，早作验证 - 软件设计的技术原则：
a. 开－闭原则：一个软件系统应该对开展是开放的，对修改是关闭的
b. 单一职责原则：一个类只有一个引起它变化的原因
c. 里氏代换原则：任何基类可以出现的地方，子类一定可以出现
d. 依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象
e. 接口隔离原则：根据客户需求不同，为不同的客户端提供不同的服务
f. 合成/聚合复用原则：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分
g. 迪米特法则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解 - 开闭原则：一个软件系统应该对开展是开放的，对修改是关闭的
a. 开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；
b. 开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码 - 体系结构的模型有：
a. 结构模型：以体系结构的构件、连接件和其他概念来刻画结构
b. 框架模型：主要以一些特殊的问题为目标建立只针对和适应该问题的结构
c. 动态模型：是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如描述系统的重新配置
d. 过程模型：研究构造系统的步骤和过程
e. 功能模型：由一组功能构件按层次组成，下层向上层提供服务 - 体系结构的分类：
a. 单用户体系结构：是早期最简单的信息系统，整个信息系统运行在一台计算机上，由一个用户占用全部资源，不同用户之间不共享和交换数据
b. C/S软件体系结构：用户操作模块布置在客户机上，数据存储在服务器上的数据库中
c. B/S软件体系结构：即浏览器服务器结构，用户工作界面通过浏览器来实现，极少部分事务逻辑在前端实现，主要事务逻辑在服务器端实现
d. 中间件的多层分布式的体系结构：具有客户端的表示层、中间的业务逻辑层和数据库服务器的三层或多层体系结构；多层体系结构将客户和资源分开，降低了服务器的负载 - B / S 和 C / S的比较：B/S结构是对C/S结构的一种改进；B/S结构和C/S结构比较接近，但也具有自己的特点
- 设计模式的分类（3类）：创建型模式、结构型模式、行为型模式
- 设计模式有4个基本要素：模式名称、问题、解决方案、效果
- 设计模式的作用：
a. 设计模式在工程小组成员之间提供了通用的语义
b. 设计模式可以更加简单方便的复用成功的设计和体系结构
c. 有助于作出有利于系统复用的选择，避免设计损害系统复用性
d. 可以帮助设计者更快更好的完成系统设计 - 模块设计准则：
a. 模块的划分是合适、模块与模块之间是否具有一定的独立性
b. 每个模块的功能和接口定义是否正确
c. 数据结构的定义是否正确
d. 模块内的数据流和控制流的定义是否正确 - 详细设计的目标任务：
a. 为每个模块确定采用的算法
b. 确定每一模块使用的数据结构
c. 确定模块接口的细节
d. 为每一个模块设计出一组测试用例 - 用户界面设计原则：
a. 用户界面必须保持一致性
b. 用户界面应有自助功能
c. 用户界面易懂性
判断
- 需求分析是将用户需求准确转化为软件系统的唯一途径（×）
- 软件设计的基本原则是设计越简单越好（√）
- 软件设计的指导思想是降低模块内聚性，提高模块耦合度（×）（说反了）
- 任何体系结构都有它自身的优点和缺点，所以我们要有针对性的选择使用（√）
- 软件设计的时候技术远比用户需求重要的多（×）（软件要基于用户需求进行设计）
- 常作验证，早作验证是软件设计的原则之一（√）
- 里氏代换原则中说，任何基类可以出现的地方，子类不一定可以出现（×）（子类一定可以出现）
- 框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构（√）
- C/S与B/S软件体系结构相比，除了用户界面的实现方式不同以外，其他没什么差别（×）
- 中间件的多层分布式的体系结构将客户和资源分开，降低了服务器的负载（√）
- 设计模式使得人们可以更加简单和方便地去复用成功的软件设计和体系结构，从而帮助设计者更快更好地完成系统设计（√）
- UML语言先建模再编写代码，从一开始就保证系统结构合理（√）
- 数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明（√）
第九章-高质量编程
填空＋选择
- Windows程序命名规则：
a. 对于一般标示符，适当的使用简写形式，以最短的组合词表达所需要表达的意义。
b. 程序中不要仅靠大小写来区分相似的标识符。
c. 程序中尽量不要出现与标示符完全相同的局部变量和全局变量。
d. 变量的名字应当使用“名词”或者“形容词+名词”
e. 全局函数的名字应当使用“动词”或者“动词+名词”
f. 类的成员函数应当只使用“动词”，被省略掉的名词就是对象本身
g. 用正确的反义词组命名具有互斥意义的变量或者相反动作的函数
h. 类名和函数名用大写字母开头的单词组合而成；变量和参数用小写字母开头的单词组合而成；常量全用大写的字母，用下划线分割单词。
i. 静态变量加前缀s_。如果必须定义使用全局变量，则在全局变量前加g_。
j. 类的数据成员加前缀m_，可以避免数据成员与成员函数的参数同名。
k. 为了防止某一软件库中的一些标识符和其他软件库中的标识符冲突，可以为各种标识符加上反映软件性质的前缀。
l. 使用i、j、k、l、m作为循环计数变量。 - 函数处理规则：
a. 参数的书写要完整，不要只写参数的类型而不写参数名。
b. 函数没有参数时用void填充。
c. 参数命名要恰当，顺序要合理。
d. 如果参数是指针且仅做输入用，应该在类型前面加const，以防止该指针在函数体内被意外修改。
e. 如果输入参数以值传递的方式传递对象，宜改用“const & ”方式来传递，这样可以省去临时对象的构造和析构过程，从而提高效率。
f. 避免参数太多，参数的个数尽量控制在5个以内。
g. 不要省略返回值的类型。
h. 函数名字与返回值类型在语义上不可冲突。
i. 不要将正常值和错误标志混在一起返回。正常值用输出参数获得，错误标志用return语句返回
j. 有时函数原本不需要返回值，但是为了增加灵活性，如支持链式表达，可以附加返回值
k. 如果函数的返回值是一个对象，要注意”引用传递”、”值传递”的不同使用。
l. 在函数体的”出口处”，对return语句的正确性和效率进行检查 - 定义文件的结构由三部分组成：定义文件开头处的版权和版本声明、对一些头文件的引用、程序的实现体（包括数据和代码）
a. 头文件中只存放“声明”而不存放“定义” - 类的版式的两种方式：
a. 将private类型的数据写在前面，而将public类型的函数写在后面。采用这种版式的程序员主张类的设计“以数据为中心”，重点关注类的内部结构
b. 将public类型的函数写在前面，而将private类型的数据写在后面。采用这种版式的程序员主张类的设计“以行为为中心”，重点关注的是类应该提供什么样的接口 - 内存分配方式：
a. 从静态存储区域分配：内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static变量
b. 在栈上创建：例如函数内局部变量的存储单元，函数执行结束时这些存储单元自动被释放
c. 从堆上分配：动态内存分配；程序在运行的时候用malloc或new申请任意多少的内存，程序员自己负责在何时用free或delete释放内存
判断
- 注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方（√）
- 不要将正常值和错误标志混在一起返回。正常值用输出参数获得，错误标志用return语句返回（√）
- 边写代码边注释，修改代码同时修改相应的注释（√）
- 尽可能在定义变量的同时初始化该变量（√）（就近原则）
- 建议将浮点变量用“==”或“！=”与数字比较（×）（整型变量）
- 不可将布尔变量直接与TRUE、FALSE或者1、0进行比较（√）
- 不可将浮点变量用“==”或“！=”与任何数字比较（√）
- 无论是float还是double类型的变量，都有精度限制；所以一定要避免将浮点变量用“==”或“！=”与数字比较，应该设法转化成“>=”或“<=”形式
- 应当将指针变量用“==”或“！=”与NULL比较（√）
- 在每个类声明、每个函数定义结束之后都要加空行。（√）
- 在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔（√）
【还有软件测试的部分，未完待续~】