北京吉威数源信息技术有限公司
2.3.1 人机界面测试
我们知道：“不立规矩无以成方圆”。在软件界面设计强调张扬个性的同时，我们不能忘记软件界面的设计先要讲求规矩－简洁、一致、易用，这是一切软件界面设计和测试的必循之道，是软件人机界面在突出自我时的群体定位。美观、规整的软件人机界面破除新用户对软件的生疏感，使老用户更易于上手、充分重用已有使用经验，减少使用错误。由此我们在对软件人机界面进行测试时（设计评审阶段和系统测试阶段结合进行），不妨从下列一些角度测试软件的人机界面。 1) 一致性测试
一致性是软件人机界面的一个基本要求。目的是使用户在使用时，很快熟悉软件的操作环境，同时避免对相关软件操作发生理解歧义。这要求我们在进行测试时，需要判断软件的人机界面是否可以作为一个整体而存在。下面是进行一致性测试的一些参考意见：
a) 提示的格式是否一致； b) 菜单的格式是否一致； c) 帮助的格式是否一致；
d) 提示、菜单、帮助中的术语是否一致； e) 各个控件之间的对齐方式是否一致；
f) 输入界面和输出界面在外观、布局、交互方式上是否一致；
g) 同一层次的文字在同一种提示场合（一般情况、突显、警告等）在文字大小、字体、
颜色、对齐方式方面是否一致。
2) 信息反馈测试
假设系统的使用者是一个初出茅庐的生手，这要求我们的人机界面有足够的输入检查和错误提示功能。通过信息反馈，用户得到出错提示或是任务完成的赞许之语。下面是这类测试的一些参考意见：
a) 系统是否拒绝客户的错误输入并做出提示（例：弹出警告框，声响）；
b) 系统显示用户的错误输入的提示是否正确，浅显易懂（例：“ERR004”这样的提示
让人不知所云）；
c) 注意系统界面中是否存在错别字（例：“请选则删除的文件！”其中的“则”应改为
“择”）；
d) 系统在界面（主要是菜单、工具条）上是否提供突显功能（比如鼠标移动到控件时，
3
北京吉威数源信息技术有限公司
控件图标变大或颜色变化至与背景有较大反差，当移动开后恢复原状）。
3) 界面简洁性测试
a) 用户界面是否存在空白空间（没有空白空间的界面是杂乱无章的，易用性极差）； b) 各个控件之间的间隔是否一致； c) 各个控件在垂直和水平方向上是否对齐；
d) 菜单深度是否在三层以内（建议不要超出三层，大家可以参考微软的例子）； e) 界面控件本身是否需要通过滑动条的滑动来显示数据（建议采用分页显示并提供数
据排序显示功能）。
4) 用户动作性测试
a) 是否允许动作的可逆性（Undo，Redo）； b) 系统的反应速度是否符合用户的期望值； c) 不同显示分辨率下窗体内容是否正确； d) 缩放窗体，窗体上的控件是否随着窗体而缩放； e) 用户在使用时任何时候是否能开启帮助文档（F1）；
f) 系统是否提供模糊查询机制和关键字提示机制减少用户的记忆负担（地名查询的模
糊设定）；
g) 是否采用相关控件（如：日历，计算器等）替代用户手工键盘输入； h) 选项过多的情况下是否采用下拉列表或者关键字检索的方式供用户选择； i) 系统出错是是否存在恢复机制使用户返回出错前状态（如：Office XP的文件恢复）； j) 在用户输入数据之前，用户输入数据后才能执行的操作是否被禁止（如特定的按钮
变灰）。
2.3.2 健壮边界值测试
采用略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值等共7个值进行测试。如取值区间为[min,max]，可用公式表示如下：min-、min、min+、normal、max-、max、max+.
上面描述是针对数值型、日期型的输入，对于其他类型，可依照处理，可能会有所取舍,如：
对于字符型，则将值对应成字符串的长度即可
对于列表框、下拉列表等控件，则将值对应成控件中的列表项。
4
北京吉威数源信息技术有限公司
2.3.3 回归测试
在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
2.4软件测试工作的输出
一般软件测试输出的主要成果是测试用例与缺陷报告。由于我们对于测试用例还没有找到合适有效的方式来编写、使用和管理，所以暂不采用，缺陷报告是目前是测试工作的主要输出成果。
2.5软件测试过程
软件测试是驱动软件开发过程的两大源动力之一，所以需要将软件测试活动与软件开发活动进行有效的结合，对测试的活动过程要进行设计与管理。目前的测试过程是按照 《 提交代码-——〉测试——〉记录发现的缺陷——〉修复缺陷——〉提交修改后的代码——〉验证修复 》做为基本流程来开展测试活动的。当然，这个基本流程中间，测试人员还需要进行阅读需求、设计文档，与开发人员沟通等等其他活动。
在软件测试过程中，对于基本的、常见的界面布局及输入控制等缺陷可以很容易的进行快速测试并得到结果，而对于模块的功能性的验证，则需要测试人员预先了解被测模块的设计目标，所以测试人员最好能在模块的需求分析与设计阶段就能有一定程度的参与。
另外，目前我们使用ClearQuest、SourceSafe进行软件测试过程的辅助管理。
5
北京吉威数源信息技术有限公司
第三章
3.1
测试过程中的几点要求
明确期望结果
了解系统功能，对系统的每一个功能按钮和菜单测试之前都应该先有一个明确的期望结果。
试想一下如果自己都不明确什么是正确的结果，也就无从谈错误的概念了，同时由于程序员本身对需求理解可能有偏差，实现过程也可能引入更多的偏差，所以测试人员在测试之前既要同程序员交流，了解他们的设计思路和期望输出结果，也需要从具体的功能需求出发（例如各种需求分析文档），更直接的了解功能设计上的期望结果。
3.2 多参考其他系统，提出优化建议
除了直接引起系统崩溃和功能异常的各种错误和Bug以外，在测试的过程中还需要测试人员能够多站在用户的角度去考虑系统在易用性、合理性和界面设计方面的欠缺，给程序员提供建议，以便能够不断的完善和优化系统。 举例来说：
? 系统构建平台中的用户管理功能，管理员应该设置为保留用户不能删除。 ? 系统构建平台中数据目录管理中图层属性缺省设置哪几项更便于用户使用。
? 在动态表单的设计中，某字段设置了他的关联字段后则字段类型也应该默认保持一致。 ? 制图输出界面，颜色选择框，字体类型和大小选择框和当前添加或者选中的文字、元素
的状态的关联。
从以上例子中我们可以看出，这些bug记录都不属于程序编码错误引起异常的范畴，但测试人员可以通过学习oracle系统的用户管理功能，ArcMap的制图部分，向系统设计人员了解关联字段的具体涵义和用途，了解业务上最基本的图层属性设置，从而发现和提出这些问题。即使有时候这些问题可能并不合理，或者存在技术实现方面的困难，或者是测试人员自己对需求和业务的理解偏差。
6
北京吉威数源信息技术有限公司
3.3 不断学习，培养严谨、细致的工作习惯
对被测系统进行深入的了解，多参考其他系统，增广知识，积极思考，培养严谨、细致的工作习惯，这样才能在测试工作中目光如炬，洞察先机。
3.4 建立最短、最快的反馈环路
程序员提交代码后，应该及时测试，发现问题及时反馈，并且及时验证程序员的修改，尽可能建立最短、最快的反馈环路。测试员的反馈有助于帮助程序员避免相似的问题再次发生，而且，越早发现问题，代码修改的代价也越小。
但频繁的打断程序员工作，演示发现的问题并不合适，应该怎样达到平衡还需要测试人员根据不同程序员的性格习惯自己把握好频度。
3.5 注意边界值
基本的测试理论强调“健壮边界值测试”，想阐述道理也就是程序错误和异常的高发“地带”就是在一些边界情况，或者更广义的理解为极端的情况。举例来说：
? 在地图上绘制实体：一般方式的添加，程序员在开发时候必然也试验过，而当我们将鼠
标移动超出地图边界范围后，程序员如果没有考虑到这种情况，问题可能就出现了。 ? 系统构建平台系统中我们可以进行添加、删除用户、角色、权限、表单、组织结构等等
很多类似的操作，而这些操作我们都可以找到它共有的一些极端的边界情况进行测试。比如 （1）删除所有记录后添加；（2）记录已经添加到一定数量需要分屏显示的情况继续添加是否有问题；（3）单个添加和删除都没有问题，那么多个呢？比如说同时给角色增加两个权限。
? 地图一般的放大、缩小没异常，那当放大缩小到较剧烈的程度会怎么样呢？
3.6 观察数据库记录的实际变化是否正确
程序对数据库的添加，删除等操作可能牵涉到不止一张表，程序执行数据库操作时候很有可能出现外在表现正常，但数据库没有完成全部要求的操作的情况。测试人员可以打开数据库表进行比较，掌握程序是否对数据库进行了正确的操作。
7