第四部分白盒测试

第四部分白盒测试内容摘要：

合 覆盖条件 执行路径 1 6 3 2 1,5 t1 t2 t3 2 4 3 1 2,5 t1～ t2t3 3 7 2 2 3,6 ～ t1t2 ～ t3 ～ t1～ t2 ～ t3 4 7 2 1 4,6 四 、 路 径 分 析 基本路径测试归纳  基本路径测试方法把覆盖的路径数压缩到一定限度内， 程序中的循环体最多只执行一次 ——独立路径覆盖。  它是在程序控制流图的基础上， 分析控制构造的环路复杂性 ， 导出基本可执行路径集合 ， 设计测试用例的 方法。 设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。 167。 4 程序插桩  程序插桩（ program instrumentation）是一种基本的测试手段，在软件测试中有着广泛的作用。  一、方法简介  程序插桩方法简单的说是借助于往被测程序中插入操作来实现测试目的的方法。  以计算整数 X和 Y的最大公约数程序为例，说明插桩方法的要点。 167。 4 程序插桩 图中的虚线框并不是原来的内容，而是为了纪录语句执行次数而插入的。 这些虚线框要完成的工作都是计数语句。 C(i)=C(i)+1 在程序入口处插入对计数器 C(i)的初始化语句 在程序出口处加入打印语句 即构成完整的插桩程序 167。 4 程序插桩  二、设计程序插桩时序考虑的问题  （ 1）探测哪些信息。  （ 2）在程序的那些地方设置探测点；  （ 3）需要设置那些探测点。 2需结合具体的问题解决 可根据控制结构考虑 在没有分支结构的程序段只需一个插桩语句 167。 4 程序插桩 167。 4 程序插桩  三、断言（ assertions）语句 这里仅对断言做一个简单的说明，以后我们还要进一步讨论 167。 4 程序插桩 167。 4 程序插桩 粗略的观测和分析可以用一下 167。 4 程序插桩 167。 4 程序插桩 167。 4 程序插桩 167。 4 程序插桩 167。 5 界面测试考虑  目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 1：易用性 2： 规范性 3：帮助设施 4：合理性 5：美观与协调性 6：菜单位置 7:独特性 8：快捷方式的组合 9:安全性考虑 10:多窗口的应用与系统资源 167。 5 界面测试考虑  1：易用性  按钮名称应该易懂 ， 用词准确 ， 要与同一界面上的其他按钮易于区分 ， 能望文知意最好。 理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。  易用性细则：  1):完成相同或相近功能的按钮用 Frame框起来 ， 常用按钮要支持快捷方式。  2):完成同一功能或任务的元素放在集中位置 ， 减少鼠标移动的距离。  3):按功能将界面划分区域块 ， 用 Frame框括起来 ,并要有功能说明或标题。 167。 5 界面测试考虑  4):界面要支持键盘自动浏览按钮功能 ， 即按 Tab键 、 回車鍵的自动切换功能。  5):界面上首先要输入的和重要信息的控件在 Tab顺序中应当靠前 ,位置也应放在窗口上较醒目的位置。  6):同一界面上的控件数最好不要超过 10个 ， 多于 10个时可以考虑使用分页界面显示。  7):分页界面要支持在页面间的快捷切换 ， 常用组合快捷键 Ctrl+Tab  8):默认按钮要支持 Enter及选操作 ， 即按 Enter后自动执行默认按钮对应操作。 167。 5 界面测试考虑  9):可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點。  10):Tab键的顺序与控件排列顺序要一致 ， 目前流行总体从上到下 ， 同时行间从左到右的方式。  11):核取方塊和選項框按選擇幾率的高底而先後排列。  12):核取方塊和選項框要有默認選項 ， 並支援Tab選擇。  13):選項數相同時多用選項框而不用下拉清單框。 167。 5 界面测试考虑  14):界面空间较小时使用下拉框而不用选项框。  15):选项数較少时使用选项框 ， 相反使用下拉列表框。  16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词语。 167。 5 界面测试考虑  2： 规范性  通常界面设计都按 Windows界面的规范来设计 ，可以说：界面遵循规范化的程度越高 ， 则易用性相应的就越好。 小型软件一般不提供工具厢。  规范性细则：  1):常用菜单要有命令快捷方式。  2):完成相同或相近功能的菜单用横线隔开放在同一位置。  3):菜单前的图标能直观的代表要完成的操作。  4):菜单深度一般要求最多控制在三层以内。 167。 5 界面测试考虑  5):工具栏要求可以根据用户的要求自己选择定制。  6):相同或相近功能的工具栏放在一起。  7):工具栏中的每一个按钮要有及时提示信息。  8):一条工具栏的长度最长不能超出屏幕宽度。  9): 工具栏的图标能直观的代表要完成的操作。  10):系统常用的工具栏设置默认放置位置。  11):工具栏太多时可以考虑使用工具箱。 167。 5 界面测试考虑  12):工具箱要具有可增减性 ， 由用户自己根据需求定制。  13):工具箱的默认总宽度不要超过屏幕宽度的1/5。  14): 状态条要能显示用户切实需要的信息 ， 常用的有：  目前的操作 、 系统状态 、 用户位置 、 用户信息 、提示信息 、 错误信息等 ， 如果某一操作需要的时间较长 ， 还应该显示进度条和进程提示。  15)：滚动条的长度要根据显示信息的长度或宽度能及时变换 ， 以利于用户了解显示信息的位置和百分比。 167。 5 界面测试考虑  16)：状态条的高度以放置五号字为宜 ， 滚动条的宽度比状态条的略窄。  17)：菜单和工具条要有清楚的界限。 菜单要求凸出显示 ， 这样在移走工具条时仍有立体感。  18)：菜单和状态条中通常使用 5号字体。 工具条一般比菜单要宽 ， 但不要宽的太多 ，否则看起来很不协调。  19): 右键快捷菜单采用与菜单相同的准则。 167。 5 界面测试考虑  3：帮助设施：  系统应该提供详尽而可靠的帮助文档 ， 在用户使用产生迷惑时可以自己寻求解决方法。  帮助设施细则：  1)：帮助文档中的性能介绍与说明要与系统性能配套一致。 (我们的系统帮助文档都是系统的祖先时期的说明 ， 让人困惑 )。  2)：打包新系统时 ， 对作了修改的地方在帮助文档中要做相应的修改。  3)：操作时要提供及时调用系统帮助的功能。 常用 F1。 167。 5 界面测试考虑  4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。 也就是说帮助要有即时针对性。  5)：最好提供目前流行的联机帮助格式或 HTML帮助格式。  6)：用户可以用关键词在帮助索引中搜索所要的帮助 ， 当然也应该提供帮助主题词。  7)：如果没有提供书面的帮助文档的话 ， 最好有打印帮助的功能。  8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。 167。 5 界面测试考虑  4：合理性：  屏幕对角线相交的位置是用户直视的地方 ， 正上方四分之一处为易吸引用户注意力的位置 ， 在放置窗体时要注意利用这两个位置。  合理性细则：  1)：父窗体或主窗体的中心位置应该在对角线焦点附近。  2)：子窗体位置应该在主窗体的左上角或正中。  3)：多个子窗体弹出时应该依次向右下方偏移 ，以显示窗体出标题为宜。 167。 5 界面测试考虑 4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。 5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。 横排开头或最后与竖排最后为易点位置。 6)：与正在进行的操作无关的按钮应该加以屏蔽 (Windows中用灰色显示 ， 没法使用该按钮 )。 7)：对可能造成数据无法恢复的操作必须提供确认信息 ,给用户放弃选择的机会。 167。 5 界面测试考虑 8)：非法的输入或操作应有足够的提示说明。 9): 对运行过程中出现问题而引起错误的地方要有提示 ， 让用户明白错误出处 ， 避免形成无限期的等待。 10): 提示、警告、或错误说明应该清楚、明了。