学堂在线选择题汇总
- 初识软件工程
- 软件工程方法是( )。
- 为了获得高质量软件而实施的一系列活动
- 为开发软件提供技术上的解决方法
- 为支持软件开发、维护、管理而研制的计算机程序系统
- 为了理解问题和确定需求而采取的一些技术和方法
- 下面的( )是正确的。
- 运行正确的软件就是高质量的软件。
- 软件质量是在开发过程中逐渐构建起来的。
- 软件产品质量越高越好,最理想的情况是达到“零缺陷”。
- 软件质量是由产品的功能、性能、易用性等外在特性决定的。
- 在Garvin多维度模型中,可靠性是指( )。
- 软件产品提供了让用户产生惊喜的特性
- 软件实现了用户需要的功能和性能
- 软件在规定时间和条件下无故障持续运行
- 软件符合国家或行业的相关标准
- ( )是软件从一个硬件或软件环境转换到另一环境的容易程度。
- 易用性
- 可维护性
- 可移植性
- 性能
- 下面的( )说法是正确的。
- 由于软件是产品,因此可以应用其他工程制品所用的技术进行生产
- 购买大多数计算机系统所需的硬件比软件更昂贵
- 大多数软件系统是不容易修改的,除非它们在设计时考虑了变化
- 一般来说,软件只有在其行为与开发者的目标一致的情况下才能成功
- 造成大型软件开发困难的根本原因在于( )。
- 开发人员缺乏足够的开发经验
- 对软件开发的资金投入不足
- 项目开发进度不合理
- 软件系统的复杂性
- 软件会逐渐退化而不会磨损,其原因在于( )。
- 软件通常暴露在恶劣的环境下
- 软件错误在经常使用之后会逐渐增加
- 不断的变更使组件接口之间引起错误
- 软件备件很难订购
- “软件工程”术语是在( )被首次提出。
- Fred Brooks的《没有银弹:软件工程中的根本和次要问题》
- 1968年NATO会议
- IEEE的软件工程知识体系指南(SWEBOK)
- 美国卡内基·梅隆大学的软件工程研究所
- Ariane 5火箭发射失败的事例告诉我们( )。
- 系统环境的变化可能影响软件采集数据的精度、范围和对系统的控制
- 软件后备系统可以通过复制生成
- 软件重用必须重新进行系统论证和系统测试
- 选项A和C
- 选项A、B和C
- 软件工程的基本目标是( )。
- 开发足够好的软件
- 消除软件固有的复杂性
- 努力发挥开发人员的创造性潜能
- 更好地维护正在使用的软件产品
- 编写高质量代码
- 下面的( )不是良好编码的原则。
- 在开始编码之前建立单元测试
- 建立一种有助于理解的直观布局
- 确保注释与代码完全一致
- 保持变量名简短以便代码紧凑
- 下面的( )是错误的。
- 在程序设计中使用括号以改善表达式的清晰性
- 不要修补不好的程序,要重新写
- 在程序设计中应尽可能对程序代码进行优化
- 不要在注释中重复描述代码
- 为了保证软件的质量,使其具有较好的可维护性,关键在于( )。
- 选择合适的程序设计语言
- 选择好的程序设计风格
- 具有好的数据结构
- 选择好的运行环境
- 下面的( )是对提高程序编码效率没有影响的。
- 变量名的使用
- 选择良好的设计方法
- 选择良好的算法
- 选择良好的数据结构
- 下面的( )不是一种好的做法。
- 好的注释应解释为什么,而不是怎么样。
- 好的命名应一目了然,不需要读者去猜,甚至不需要注释。
- 如果项目中原有代码不符合新的规范,应允许其存在,同时在新的代码中要延续原有的风格。
- 如果项目中原有代码不符合新的规范,应允许其存在,但不应在新的代码中延续旧的风格。
- 下面的( )不是模块化设计的目的。
- 降低程序设计的复杂性
- 清楚地描述系统的功能和性能
- 易于维护和功能扩展
- 提高模块的可靠性和复用性
- 下面的( )说法是错误的。
- 代码审查用于检查源代码是否达到模块设计的要求
- 代码在审查之前必须要成功地编译通过
- 代码审查比运行程序进行测试的效率低
- 代码审查可以发现不符合团队代码规范的地方
- 关于代码性能优化,下面( )是错误的。
- 任何优化都不能破坏代码的正确性
- 应以提高程序的全局效率为主,局部效率为辅
- 应先通过测试找出限制效率的真正瓶颈
- 要优先改进耗时最多的部分
- 下面的Python语句中,( )是没有错误且写得最规范的。
- import os, sys, random, math
- n += 1; m += n; print(m)
- class = Class()
- return [i ** 2 for i in range(n)]
- 下面的( )语句风格是最不利于维护的。
- return s['name'] if s['age'] >= 18 else s['nickname'] if s['age'] > 14 else 'anonymous'
- main(sys.argv[1:])
- from my_module import (Class1, Class2, Class3, Class4)
- a, b = b, a
- 单元测试
- 在单元测试中,( )是用来代替被测模块的子模块的。
- 驱动模块
- 桩模块
- 通讯模块
- 代理模块
- 在下面列举的测试覆盖中,( )是最强的逻辑覆盖准则。
- 语句覆盖
- 条件覆盖
- 判定覆盖
- 条件组合覆盖
- 一个判定中的复合条件表达式为(A>2)or(B≤1),为了达到100%条件覆盖率,至少需要设计( )测试用例。
- 1
- 2
- 3
- 4
- 条件覆盖要求( )。
- 每个判定中每个条件的所有取值至少满足一次
- 每个判定至少取得一次“真”值和一次“假”值
- 每个判定中每个条件的所有可能取值组合至少满足一次
- 每个可执行语句至少执行一次
- ( )要求每个判定中所有条件的可能取值至少执行一次,而且每个判定的可能结果也至少执行一次。
- 判定覆盖
- 条件覆盖
- 判定条件覆盖
- 条件组合覆盖
- 单元测试内容不包括( )。
- 出错处理
- 全局数据结构
- 独立路径
- 模块接口
- 下面的( )是错误的。
- 静态测试是不运行被测程序,仅通过检查和阅读等手段来发现程序中的错误
- 动态测试是实际运行被测程序,通过检查运行的结果来发现程序中的错误
- 动态测试可能是黑盒测试,也可能是白盒测试
- 白盒测试是静态测试,黑盒测试是动态测试
- 关于等价类划分,下面的( )说法是正确的。
- 等价类划分是将输入域划分成尽可能少的若干子域
- 同一输入域的等价类划分是唯一的
- 用同一等价类中的任意输入对软件进行测试,软件都输出相同的结果
- 对于相同的等价类划分,不同测试人员选取的测试用例集是一样的
- 白盒测试是根据程序的( )来设计测试用例。
- 功能
- 性能
- 内部逻辑
- 内部数据
- 关于测试覆盖率,下面的( )说法是错误的。
- 测试覆盖率是度量代码质量的一种手段
- 测试覆盖率是度量测试完整性的一种手段
- 测试覆盖率意味着有多少代码经过测试
- 不要盲目地追求100%测试覆盖率
- 软件开发过程
- 下面的( )决策是在需求分析时做出的。
- 自动售票机系统的开发时间预计是6个月
- 自动售票机系统由用户界面子系统、价格计算子系统以及与中心计算机通信的网络子系统组成
- 自动售票机系统已经达到交付的要求
- 自动售票机系统将为使用者提供在线帮助
- 下面的( )决策是在系统设计时做出的。
- 自动售票机系统的开发时间预计是6个月
- 自动售票机系统由用户界面子系统、价格计算子系统以及与中心计算机通信的网络子系统组成
- 自动售票机系统已经达到交付的要求
- 自动售票机系统将为使用者提供在线帮助
- 下面的( )是软件构造活动的任务。
- 构建软件组件
- 设计用户界面
- 实施组件的单元测试
- 评估组件的质量
- 选项A和C
- 选项A、B、C和D
- 瀑布模型是( )。
- 适用于需求被清晰定义的情况
- 一种需要快速构造可运行程序的好方法
- 一种不适用于商业产品的创新模型
- 目前业界最流行的过程模型
- 增量模型是( )。
- 适用于需求被清晰定义的情况
- 一种需要快速构造核心产品的好方法
- 一种不适用于商业产品的创新模型
- 已不能用于现代环境的过时模型
- 原型化模型是( )。
- 适用于客户需求被明确定义的情况
- 适用于客户需求难以清楚定义的情况
- 提供一个精确表述的形式化规格说明
- 很难产生有意义产品的一种冒险模型
- 开发一个支持3D打印的操作系统最适合采用( )。
- 瀑布模型
- 原型化模型
- 增量开发
- 可转换模型
- 开发一个铁路信号控制系统最适合采用( )。
- 瀑布模型
- 原型化模型
- 增量开发
- 可转换模型
- 下面的( )不是敏捷开发方法的特点。
- 软件开发应该遵循严格受控的过程和详细的项目规划
- 客户应该和开发团队在一起密切地工作
- 通过高度迭代和增量式的软件开发过程响应变化
- 通过频繁地提供可以工作的软件来搜集人们对产品的反馈
- 关于Scrum的每一次冲刺(Sprint),下面的( )是正确的。
- Sprint是一个不超过4周的迭代,其长度一旦确定,将保持不变。
- Sprint的产出是一个可用的、潜在可发布的产品增量。
- Sprint在进行过程中,其开发目标、质量验收标准和团队组成不能发生变化。
- 以上所有选项
- 团队开发管理
- 在软件开发的各种资源中,( )是最重要的资源。
- 开发工具
- 方法
- 硬件环境
- 人员
- 在攻克技术难题时,最佳的开发团队组织模型是( )。
- 民主式结构
- 主程序员式结构
- 矩阵式结构
- 以上所有选项都不是
- 在选择开发团队组织结构时应考虑( )因素。
- 沟通的复杂程度
- 最终程序的规模大小
- 发布日期的严格程度
- 项目预算的多少
- 选项A,B和C
- 选项A,B和D
- 下面的( )很有可能会促进高效项目团队的建设。
- 团队成员超过 20 人
- 团队成员部分时间参与项目
- 团队成员向多个经理汇报
- 团队成员被指派到项目中
- 以上选项都不是
- 下面的( )沟通方式最利于协助解决复杂的问题。
- 口头
- 书面
- 电子邮件
- 即时通讯工具
- 下面的( &