《第15~18章习题课》.ppt

第15~18章习题课 * 第15章 15.2 给出两个附加的“置用户于控制之下”的设计原则。 对所有可能造成损害的动作，坚持要求用户确认，例如提问“你确定……?”等，对大多数动作应允许恢复(UNDO)，对用户出错采取宽容的态度。 用户界面应能对用户的决定做出及时的响应，提高对话、移动和思考的效率，最大可能的减少击键次数，缩短鼠标移动距离，避免使用户产生无所适从的感觉。 第15章 15.3 给出两个附加的“减少用户记忆负担”的设计原则。 提供用户使用的求助系统，让用户及时获得帮助，尽量用简短的动词和动词短语提示命令。 对常用的菜单命令在工具栏上增添图标按钮以方便用户直接使用。 第15章 15.4 给出两个附加的“保持界面一致性”的设计原则。 在同一用户界面中，所有的菜单选择、命令输入、数据显示和其他功能应保持风格的一致性。不同用户界面外观布局也应该一致。风格一致的人机界面会给人一种简洁、和谐的美感。 产品在不同版本升级过程中保持界面一致。 第15章 15.5 为大学自动课程注册系统开发用户界面的设计模型、用户模型、系统感觉和系统映像。 设计模型（B/S模式）(P296) 身份注册：用户输入用户名（学号）、密码在系统上注册。 身份认证：用户输入学号、密码，系统核实。 课程信息：课程介绍、上课时间、任课教师、可选人数等等。 课程状态：可选或不可选、已选人数。 选课操作：选、改选 选课状态：已选的课程列表 第15章 用户模型：在校本科生（院系、年级等限制） 系统感觉：（系统外观布局略） 不能正常进入系统时给予提示，比如时间过期； 由于网络繁忙等原因不能成功操作时给予提示； 数据库实时更新以保证进行的操作有效； 对复选、多选等错误操作给予提示。 第15章 系统映像： 第15章 15.7 在任务分析之后定义界面对象和动作。 任务： 访问选课系统。（未注册者先注册） 输入学号、密码。 显示系统状态。 启动或关闭选课系统。 显示备选课程信息。 打印课程详细信息。 显示已选课程信息。 选择课程。 删除课程。 显示操作相关提示信息。 第16章 16.2 所有现代编程语言都实现结构化编程元素。给出来自三个语言的例子。 结构化的构成元素：逻辑块 逻辑块的构成元素：顺序、条件和循环结构。 语言代码示例（略） 第16章 16.5 试为基本所得税信息查询的交互界面进行过程设计。 第16章 第17章 17.12 穷举测试是否能保证程序100%正确，即便是非常小的程序。 白盒测试：遍历所有逻辑路径，从理论上可以彻底检查程序的正确性。 黑盒测试：穷举输入数据来测试输出，此时的输入很可能是无穷的以致无法穷举。 结 论：穷举测试是一种简单的测试方法但不可行。 第17章 17.13 用等价划分法为SafeHome系统导出测试案例集 等价划分是对系统的输入数据划分出有效和无效等价类，而不是对不同功能进行划分。 SafeHome系统数据 传感器的编号、类型 主人密码 警报电话号码 启动和关闭系统的命令 。。。 第17章 主人密码 类型 布尔（存在/不存在） 值（6位数字的字符串） 测试案例 输入空密码 输入错误密码 输入正确密码 第18章 18.4 在单元测试过程中选择三种测试用例设计方法 对穿越模块接口的数据流的测试 控制结构测试（对执行路径的选择性测试＋循环测试） 边界测试 第18章 18.5 紧耦合的模块对单元测试的影响 单元测试在隔离的前提下，分别对各个代码单元进行测试，因此，单元测试是一种有效的保证代码具有良好的整体结构的约束机制。 随意的不合理的紧耦合会造成难于进行单元测试。下面以图形界面为例进行说明。 第18章 如果一个模块必须要通过图形界面才能够触发它的应用逻辑，那么要对这个模块进行测试时就必须要使用图形界面。但图形界面又是很难测试的。其实我们真正想要测试的是模块本身的应用逻辑，而不是图形界面的触发逻辑。如果在设计时能把模块本身进行封装，定义良好的接口，就可以绕过图形界面进行模块的单元测试。 第18章 18.9 所有情况下，单元测试都是可能的或是值得做的吗 值得但有时很难执行。 单元测试是集成测试、用户测试的基础，只要有单元模块的代码就应该进行单元测试。但是对于耦合很紧的多个模块，单元测试也许就变得成本太大也很难执行。 * *