程序僵化：给用户适当的自由

·         用户可调整：

1)     可以关闭噪音

2)     可以关闭大小写区分

3)     适合通用硬件接口

4)     支持改变设备初始化状态

5)     不能改变滚动速度

6)     改变定制命令的保存

·         控制方式

1)       对新手和老手都友好

2)       必需信息过剩

3)       步骤重复

4)       限制过多

性能：

·         程序速度

·         用户吞吐量

·         感觉到的性能：

1)       应给出某个输入时间会很长的警告

2)       不要有太多提问和询问

3)       尽量使用简单命令和提示

输出：

·         不能输出某类数据

·         不能重定向输出

·         必须输出的很少或很多

·         不能控制输出布局   ·       荒谬的精度输出级别

命令结构和录入：

·         测试实践要标注出所有发现的不一致性，无论多么微不足道都要如此

·         优化界面设计：

1)       缩写要一致

2)       终止规则要一致

3)       同一命令的不同形式表现取名应当要一致

4)       要保持命令在同一子菜单中的位置，而不是让它东搬西迁在其他的子菜单中停留

5)       功能键的意义在程序中应始终保持一致

6)       错误处理规则要一致

7)       编辑处理规则要一致

8)       数据保存规则要一致

9)       避免曲折路径，通常完成一个操作不得超过三步

10)    命令不能模糊不清带有个人风格

·         菜单：应该尽量简洁

1)       菜单层次不宜过多，嵌套不宜超过三层

2)       到达相同位置的路径不得超过3个

3)       相关的命令归属到相同的菜单下

4)       功能键要标准使用，如F1表示帮助，ESC表示退出

5)       可过滤无效键

遗漏命定：

·         状态转换：可以在任何时候退出

·         危机预防：

1)     有备份工具或手段

2)     撤销或删除可用

3)     有是否确定类提示

·         由用户进行的错误处理：不能包含注释，不能显示变量关系

其他：保证隐私和安全、可隐藏菜单支持通配符、名字长度印有限制

帮助文本和错误信息：

• 帮助文本和错误信息应该尽量措辞简单明了，多用主动语态，尽量少使用技术术语
• 帮助信息不要太冗长了，多使用“下一步”，“步骤一 ……”
• 不使用不合适的情绪语气及感叹号
• 错误来源描述应指出是什么情况，而且还要指出为什么有些东西出了错，以及如何处理此类错误的方法
• 测试出的错误应当可以重现
• 当资源不足时，测试无法通过，应说明具体原因

显示缺陷：

• 数据写到了错误的屏幕位置
• 未能清除部分屏幕
• 未能突出显示部分屏幕
• 显示的字符串错误或不完整
• 显示信息过长或长度不够

界面布局的显示：

• 从美学角度看界面不对称，行或列排列不整齐
• 菜单布局错误：选择一个菜单项通常应该独立，通过键入其首字母来选择菜单项，在同一栏下面不要出项重复的字母
• 对话框布局错误：

1)       对话框应该一致：一致使用大小写，字体和文本对齐规则；<ESC>不应取消某些对话框

2)       对话框中的控件布局应使用必要的间隔把组隔开

3)       选择和录入区域应该垂直和水平排列

4)       计量减少对话框之间的相互依赖性

• 少用特效，注意颜色的搭配
• 整体风格一致
• 可以取消/恢复一些工具或状态栏

功能测试（functional testing）、性能测试（preformance testing）、黑盒测试（black-box testing）、白盒测试（white-box testing）、回归测试（regression testing）

Functional testing：主要针对用户所要使用的功能，测试功能能不能通过。

Performance testing：主要针对服务器性能和可以承受的负荷。

Black-box testing：主要在于以用户眼光验证软件的结果。

White-box testing：关注范围（控制结构），单元测试和代码测试

Regression testing：对曾经测出bug的地方进行复测，及全部功能全部再次测试

用户对于软件的看法依赖点：

• 功能性（实现软件应具备的基本功能）
• 易用性（用户学习掌握该软件所耗费的时间及在具体业务流程上的简化）
• 执行速度（多数是启动速度，查询速度，刷新速度及响应时间等因素）
• 用户使用时产生错误的比率（在允许用户任意使用的情况下，越少越好）
• 用户满意度（这里指的是用户界面设计与功能设计的用户评价）

黑盒测试试图发现以下几类错误：

• 功能错误或遗漏
• 界面错误
• 数据结构或外部数据库访问错误
• 性能错误
• 初始化错误和终止错误

天气一天天的转热，很多人隐埋在心底欲望又开始腾腾上涌了出来。我们常常笑谈春天是恋爱的季节，殊不知，夏季一如它的热情似火，许多人冲昏了头脑，大玩起暧昧的游戏来。

暧昧，辞海是这样解释的：①（态度、用意）含糊；不明白：态度暧昧。②（行为）不光明；不可告人：关系暧昧。其实暧昧原本出于情感，在以前要是一对男女彼此有了好感，又在彼此不断的接触，我们就说他们关系比较暧昧了，大有像情侣发展下去的潜力。然而到了这个时代，暧昧随着人们对感情放任的认知变了味，暧昧、一夜情仿佛像被502粘住一般，它们的衍生就象小时候出的疹子，每个人不出都不算完，有所不同的是，疹子出过有自身产生免疫力而不再出，而暧昧、一夜情，出过一次还想出，有瘾。

有的暧昧，也许是一方会错意了。他（她）出于礼貌不拒绝你的好意，或者关心你，令你想入非非了。有的暧昧，则是借着“暧昧”的屏障玩着感情的游戏。更有甚者，他（她）给你一种似是而非的暗示，让人深陷其中，为他（她）所利用，到了关键时刻，他（她）推脱责任来个矢口否认，让你哑巴吃黄莲有苦说不出。

有人说真正的爱情与暧昧无关，这个说法也并不是不对，关键是看你怎么转换，如果男女间没有一点暧昧是不可能进一步交往下去的，但是一旦证实了自己的心，我们就要抛掉所谓的暧昧，真真正正的谈一场恋爱。在这个日渐开明，又世风日下的社会，只有深藏的欲望，没有见不得人的情感。
 
所以，正视“暧昧”的眼神，不要在想入非非中沉沦。

提及真实的情感，我不由得想起一段话来：如果一段爱情中有着别人的牺牲，受着社会的责难，和忍受着自己良心上的不安，那它就不会成为持久而又可爱的爱情。这就像我常常劝慰自己和别人的一样，如果一份感情不能使自己和对方都感到快乐，那么两人在一起也不会幸福，既然不会幸福，不如分开享受一个人的自在，虽然这个时候他（她）中的一人忍受着相思的苦闷，但是至少在身体和灵魂上都是自由的……

所以，让我们过平淡真实的日子，做个清澈可鉴的人吧！