知识改变命运

发布新日志

  • centos 6.3使用yum安装mysql

    2013-12-17 17:02:14

    1.查看有没有安装过

    yum list installed mysql*
    rpm -qa | grep mysql*

    2.如果有安装包 可以用rpm 命令强制卸载

    rpm -e --nodeps (不检查依赖性 ) 数据包名

    3.安装mysql客户端:
             
    yum install mysql
     
    4.安装mysql 服务器端:
    yum install mysql-server
     
    yum install mysql-devel

    5.启动

    service mysqld start或者/etc/init.d/mysqld start

    6.登陆

    创建root管理员:
    mysqladmin -u root password 123456

    登录
    mysql -u root -p输入密码即可

    7.开启mysql远程连接

    将相应用户数据表中的host字段改成'%';

    登入mysql

    mysql -u root -p123456
    use mysql

    mysql> select host, user from user;
    +-----------+------+
    | host      | user |
    +-----------+------+
    | 127.0.0.1 | root |
    | ::1       | root |
    | localhost |      |
    | localhost | root |
    +-----------+------+
    4 rows in set (0.00 sec)

    可以看出没有%这一项

    mysql> update user set host='%' where user='root';

    ERROR 1062 (23000): Duplicate entry '%-root' for key 'PRIMARY'

    这里报了一个错误,我们不予理会。

    mysql> select host, user from user;

    +-----------+------+

    | host      | user |

    +-----------+------+

    | %         | root |

    | 127.0.0.1 | root |

    | ::1       | root |

    | localhost |      |

    +-----------+------+

    4 rows in set (0.00 sec)

  • Linux-dd命令

    2010-04-29 14:05:27

    1. 命令简介

    dd 的主要选项:

    指定数字的地方若以下列字符结尾乘以相应的数字:

    b=512, c=1, k=1024, w=2, xm=number m

    if=file

    输入文件名,缺省为标准输入。

    of=file

    输出文件名,缺省为标准输出。

    ibs=bytes

    一次读入 bytes 个字节(即一个块大小为 bytes 个字节)。

    obs=bytes

    一次写 bytes 个字节(即一个块大小为 bytes 个字节)。

    bs=bytes

    同时设置读写块的大小为 bytes ,可代替 ibs 和 obs 。

    cbs=bytes

    一次转换 bytes 个字节,即转换缓冲区大小。

    skip=blocks

    从输入文件开头跳过 blocks 个块后再开始复制。

    seek=blocks

    从输出文件开头跳过 blocks 个块后再开始复制。(通常只有当输出文件是磁盘或磁带时才有效)。

    count=blocks

    仅拷贝 blocks 个块,块大小等于 ibs 指定的字节数。

    conv=conversion[,conversion...]

    用指定的参数转换文件。

    转换参数:

    ascii 转换 EBCDIC 为 ASCII。

    ebcdic 转换 ASCII 为 EBCDIC。

    ibm 转换 ASCII 为 alternate EBCDIC.

    block 把每一行转换为长度为 cbs 的记录,不足部分用空格填充。

    unblock 使每一行的长度都为 cbs ,不足部分用空格填充。

    lcase 把大写字符转换为小写字符。

    ucase 把小写字符转换为大写字符。

    swab 交换输入的每对字节。

    noerror 出错时不停止。

    notrunc 不截短输出文件。

    sync 把每个输入块填充到ibs个字节,不足部分用空(NUL)字符补齐。

     

    2.实例分析

    2.1.数据备份与恢复

    2.1.1整盘数据备份与恢复
    备份:

    dd if=/dev/hdx f=/dev/hdy
    将本地的/dev/hdx整盘备份到/dev/hdy


    dd if=/dev/hdx f=/path/to/image
    将/dev/hdx全盘数据备份到指定路径的image文件


    dd if=/dev/hdx | gzip >/path/to/image.gz
    备份/dev/hdx全盘数据,并利用gzip工具进行压缩,保存到指定路径
                 


    恢复:
    dd if=/path/to/image f=/dev/hdx
    将备份文件恢复到指定盘


    gzip -dc /path/to/image.gz | dd f=/dev/hdx
    将压缩的备份文件恢复到指定盘

     


    2.1.2.利用netcat远程备份


    dd if=/dev/hda bs=16065b | netcat < targethost-IP > 1234
    在源主机上执行此命令备份/dev/hda


    netcat -l -p 1234 | dd f=/dev/hdc bs=16065b
    在目的主机上执行此命令来接收数据并写入/dev/hdc


    netcat -l -p 1234 | bzip2 > partition.img
                    netcat -l -p 1234 | gzip > partition.img
    以上两条指令是目的主机指令的变化分别采用bzip2  gzip对数据进行压缩,并将备份文件保存在当前目录。

     

    2.1.3.备份MBR
    备份:

    dd if=/dev/hdx f=/path/to/image count=1 bs=512
    备份磁盘开始的512Byte大小的MBR信息到指定文件
                  


    恢复:

    dd if=/path/to/image f=/dev/hdx
    将备份的MBR信息写到磁盘开始部分

     

     

    2.1.4.备份软盘

    dd if=/dev/fd0 f=disk.img count=1 bs=1440k
    将软驱数据备份到当前目录的disk.img文件

     

    2.1.5.拷贝内存资料到硬盘

    dd if=/dev/mem f=/root/mem.bin bs=1024
    将内存里的数据拷贝到root目录下的mem.bin文件

     

    2.1.6.从光盘拷贝iso镜像

    dd if=/dev/cdrom f=/root/cd.iso
    拷贝光盘数据到root文件夹下,并保存为cd.iso文件     

     

    2.2.增加Swap分区文件大小

    dd if=/dev/zero f=/swapfile bs=1024 count=262144
    创建一个足够大的文件(此处为256M)


    mkswap /swapfile
    把这个文件变成swap文件


    swapon /swapfile
    启用这个swap文件


    /swapfile swap swap defaults 0 0
    在每次开机的时候自动加载swap文件, 需要在 /etc/fstab 文件中增加一行

     

    2.3.销毁磁盘数据

    dd if=/dev/urandom f=/dev/hda1
    利用随机的数据填充硬盘,在某些必要的场合可以用来销毁数据。执行此操作以后,/dev/hda1将无法挂载,创建和拷贝操作无法执行。


    2.4磁盘管理

    2.4.1.得到最恰当的block size

    dd if=/dev/zero bs=1024 count=1000000 f=/root/1Gb.file
                    dd if=/dev/zero bs=2048 count=500000 f=/root/1Gb.file
                    dd if=/dev/zero bs=4096 count=250000 f=/root/1Gb.file     
                    dd if=/dev/zero bs=8192 count=125000 f=/root/1Gb.file
    通过比较dd指令输出中所显示的命令执行时间,即可确定系统最佳的block size大小

                  
    2.4.2测试硬盘读写速度

    dd if=/root/1Gb.file bs=64k | dd f=/dev/null
                    dd if=/dev/zero f=/root/1Gb.file bs=1024 count=1000000
    通过上两个命令输出的执行时间,可以计算出测试硬盘的读/写速度     


    2.4.3.修复硬盘

    dd if=/dev/sda f=/dev/sda
    当硬盘较长时间(比如1,2年)放置不使用后,磁盘上会产生magnetic flux point。当磁头读到这些区域时会遇到困难,并可能导致I/O错误。当这种情况影响到硬盘的第一个扇区时,可能导致硬盘报废。上边的命令有可能使这些数据起死回生。且这个过程是安全,高效的

  • 数据库测试检查点

    2010-02-02 10:06:00

    1.       数据备份与恢复测试

    检查备份内容的正确性(通过事先准备的测试数据在恢复后验证);

    检查备份到不同介质上,并考虑介质空间已满的情况;

    检查是否会出现数据备份失败的现象

    检查备份过程中是否会产生其他出错信息的现象

    检查是否会大数据量备份记录条数丢失的现象

    检查数据库备份,恢复后能否正常工作

    检查是否会出现数据备份恢复失败的现象

    备份恢复数据比较,检查是否会出现设置内容不正确的现象

    备份恢复数据比较,检查是否会存在记录丢失的现象

    检查在各个数据库中,是否会出现数据小数位长度不一致的现象

    检查数据库中原有数据的,是否会产生恢复后部分数据未覆盖的现象

    检查备份恢复过程中是否会产生其他出错信息的现象

    检查集中备份恢复与普通备份恢复结果是否会不同的现象

    检查是否会大数据量备份恢复记录条数丢失的现象

    检查备份与恢复过程本身的正确性;

    检查备份与恢复过程中对异常情况的处理(掉电、网络不通等);

    检查在原始机上的恢复;

    检查在非原始机上的恢复;

    检查在裸机(只有操作系统和必要的数据库或第三方产品)上的恢复;

    检查在一台机器上进行若干次的备份与恢复;

    检查如果是支持多数据库的软件,备份与恢复是容易出错的地方。

    检查备份T日的数据,进行操作,然后恢复,查看恢复的数据是否正确;

    检查用系统提供的恢复功能进行恢复:

    用数据库进行恢复;

    在备份和恢复还没有结束的时候,终止(掉电,网络不通等)备份和恢复;

    有操作的时候,进行备份和恢复;

    没有任何操作的时候,进行备份,恢复;

    部分备份,全部备份,部分恢复,全部恢复有选择的备份和恢复;

    检查进行备份,恢复操作是否有权限限制 A : 分别用有权限的用户和没有权限的用户进行操作 B 没有:单个用户进行备份,恢复;多个用户同时进行备份和恢复。

    2.       故障转移和恢复测试

    检查客户机断电:关闭 PC 的电源

    检查服务器断电:模拟或启动服务器的断电过程。

    检查通过网络服务器产生的通信中断:模拟或启动网络的通信中断(实际断开通信线路的连接或关闭网络服务器或路由器的电源)。

    检查DASD / DASD 控制器被中断、断电或与 DASD /DASD 控制器的通信中断:模拟与一个或多个 DASD 控制器或设备的通信,或实际取消这种通信。

    一旦实现了上述情况(或模拟情况),就应该执行其他事务。而且一旦达到第二个测试点状态,就应调用恢复过程。

    检查周期未完成(数据过滤进程被中断,数据同步进程被中断)。在测试不完整的周期时,所使用的方法与上述方法相同,只不过应异常终止或提前终止数据库进程本身。

    检查数据库指针或关键字无效、数据库中的数据元素无效或遭到破坏:对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时,应该以手工方式在数据库中(通过数据库工具)直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行,并且应执行完整的周期。

    完成标准:在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏,以及表明进程或事务因中断而未被完成的报表。

    需考虑的特殊事项:

    恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法(模拟断电或通信中断)可能并不可取或不可行。可能会需要采用其他方法,例如诊断性软件工具。

    需要系统(或计算机操作)、数据库和网络组中的资源。

    这些测试应该在工作时间之外或在一台独立的计算机上运行。

    3.       数据迁移文档测试

    借鉴数据模型规范,厂商提供数据字典,行文档测试验证.以人工验证为主。

    检查数据迁移前后实体相应的变化

    检查新老系统中概念、实体是否符合相应的规范

    4. 数据迁移界面测试

    通过系统程序的界面,利用设计好的测试用例,来验证数据的逻辑存储是否符合数据模型规范的要求

    检查数据实体的存储正确性

    检查验证数据迁移后数据量是否与老系统一致

    检查验证数据迁移后是否存在遗漏数据或者错误数据

    4.       数据迁移倒换脚本

    逻辑关系的转换,表数据倒换顺序:从老系统迁移到新系统中,脚本中新老系统相应的实体名称、表字段名称以及实体,表之间的关系等都将一一对应。

    检查实体的新老字段、实体间属性关系转换的准确性

    检查关联表数据的倒换顺序

    异常处理机制:在老系统中存在少量的异常数据,主要有以下两种种异常数据:某张表中一条数据的某个字段没有值,某个实体相关联的几张表一一对应的表数据不完整(几张表中有一张表没有该实体的数据),当出现这类数据,需要脚本能够自动处理,纠错或者记录相应的数据; 另外,当出现外界的异常信息时候,需要脚本能够以日志形式记录异常信息。

    检查脚本中对异常错误数据是否有异常信息抛出

    检查是否可以自动处理相应的错误数据;

    数据迁移脚本性能:脚本性能主要包括脚本函数的时间复杂度和空间复杂度。

    时间复杂度:主要从执行时间效率来考虑,脚本执行时间脚本执行时间长短决定数据迁移的最终时间。

    空间复杂度:主要从脚本执行时消耗的资源(比如cpu,内存)来确定脚本的空间复杂度

    通过相应的工具(比如pl/sql)检查数据迁移脚本中函数空间复杂度和时间复杂度,根据不同情况再修改脚本性能

    检查脚本中出现的死循环,数据表之间的死锁等

    5. 数据迁移数据操作测试

    通过数据库产品的客户端或者第三方数据库操作客户端产品,利用设计好的程序脚本或者SQL脚本,通过新老系统数据实体的对比,来检测数据迁移后相应的数据实体是否符合数据模型规范的要求。

    检查数据迁移后数据的是否存在遗漏或者有错误数据,验证数据是否符合新系统中相应的规范。

    5.       数据迁移准确性和完整可靠

    检查数据准确性和完整性,包括新老数据量的对比,异常错误数据的容错纠错性

    检查新系统能否正常运行,检查各项的业务过程中是否有关于数据错误的信息报出

    编写脚本或者存储过程,直接从数据库中捞取数据,检查表数据中各个数据字段或者业务逻辑已经符合新的业务规范中描述的实体关系

    检查相应的实体及实体关系信息是否准确,验证实体表中是否有数据错误或者数据遗漏

    新系统能否正常运行,业务办理后能否正常跑完整个流程

    检查前台是否有跟数据错误相关的信息报出

    检查业务后台处理流程中是否出现跟数据相关的错误信息,验证整个业务流程能否正常

    数据业务逻辑是否正确,是否符合正常的受理流程,通过相应的业务办理来验证其准确性。

    通过相应的业务功能点进行业务办理,检查整个业务流程能否走通,数据流向是否正确

    6.       数据迁移倒换规则

    主要内容包括:新老系统实体概念的转变,实体之间关系的转变,实体结构的转变(包括实体属性名称、属性定义、数据域等)

    概念验证,新老系统业务概念对比

    通过新老规范文档对比,检测新老实体是否已经转换

    逻辑关系对比

    通过文档检测数据模型实体之间的逻辑关系已经得到转化

    7.       数据迁移方案

    迁移方案可行性和合理性主要从以下两方面来考虑:

    硬件:存储、内存、CPU等是否达到数据迁移的要求,容灾备份设备是否已经准备好。

    软件:系统平台(包括操作系统、客户端软件安装、网络等)是否达到可以支持数据迁移的要求;相关的数据迁移工作人员是否已经到到位。

    迁移方案的合理性和可行性

    通过审核相应的规范和技术文档,检测迁移方案的合理性和可行性

  • 界面测试

    2008-07-01 09:28:23

    界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
      目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。
    1
    :易用性:
      按钮名称应该易懂,用词准确,屏弃摸棱两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
    易用性细则:
    1):
    完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
    2):
    完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。
    3):
    按功能将界面划分区域块,用Frame框括起来,并要有功能说明或标题。
    4):
    界面要支持键盘自动浏览按钮功能,即按Tab键、回車鍵的自动切换功能。
    5):
    界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    6):
    同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。
    7):
    分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab
    8):
    默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。

    9):可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點。
    10):Tab
    键的顺序与控件排列顺序要一致,目前流行总体从上到下,同时行间从左到右的方式。
    11):
    核取方塊和選項框按選擇幾率的高底而先後排列。
    12):
    核取方塊和選項框要有默認選項,並支援Tab選擇。
    13):
    選項數相同時多用選項框而不用下拉清單框。
    14):
    界面空间较小时使用下拉框而不用选项框。
    15):
    选项数較少时使用选项框,相反使用下拉列表框。
    16):
    专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词语。
    2
    规范性:
    通常界面设计都按Windows界面的规范来设计,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具厢。
    规范性细则:
    1):
    常用菜单要有命令快捷方式。
    2):
    完成相同或相近功能的菜单用横线隔开放在同一位置。
    3):
    菜单前的图标能直观的代表要完成的操作。
    4):
    菜单深度一般要求最多控制在三层以内。
    5):
    工具栏要求可以根据用户的要求自己选择定制。
    6):
    相同或相近功能的工具栏放在一起。
    7):
    工具栏中的每一个按钮要有及时提示信息。
    8):
    一条工具栏的长度最长不能超出屏幕宽度。
    9):
    工具栏的图标能直观的代表要完成的操作。
    10):
    系统常用的工具栏设置默认放置位置。
    11):
    工具栏太多时可以考虑使用工具箱。
    12):
    工具箱要具有可增减性,由用户自己根据需求定制。
    13):
    工具箱的默认总宽度不要超过屏幕宽度的1/5
    14):
    状态条要能显示用户切实需要的信息,常用的有:
    目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。
    15)
    :滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
    16)
    :状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。
    17)
    :菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。
    18)
    :菜单和状态条中通常使用5号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
    19):
    右键快捷菜单采用与菜单相同的准则。
    3
    :帮助设施:
    系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
    帮助设施细则:
    1)
    :帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)
    2)
    :打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
    3)
    :操作时要提供及时调用系统帮助的功能。常用F1
    4)
    :在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    5)
    :最好提供目前流行的联机帮助格式或HTML帮助格式。
    6)
    :用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
    7)
    :如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
    8)
    :在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。

    4:合理性:
    屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
    合理性细则:
    1)
    :父窗体或主窗体的中心位置应该在对角线焦点附近。
    2)
    :子窗体位置应该在主窗体的左上角或正中。
    3)
    :多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
    4)
    :重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
    5)
    :错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
    6)
    :与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)
    7)
    :对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    8)
    :非法的输入或操作应有足够的提示说明。
    9):
    对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
    10):
    提示、警告、或错误说明应该清楚、明了、恰当。
    5
    :美观与协调性:
    界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
    美观与协调性细则:
    1):
    长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
    2):
    布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
    3):
    按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
    4):
    按钮的大小要与界面的大小和空间要协调。
    5):
    避免空旷的界面上放置很大的按钮。
    6)
    :放置完控件后界面不应有很大的空缺位置。
    7):
    字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
    8):
    前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。
    9):
    如果使用其他颜色,主色调要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
    10):
    大型系统常用的主色有"#E1E1E1""#EFEFEF""#C0C0C0"等。
    11):
    界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
    12):
    如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
    13)
    :对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
    14):
    通常父窗体支持缩放时,子窗体没有必要缩放。
    15)
    :如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。
    6
    :菜单位置:
    菜单是界面上最重要的元素,菜单位置按照按功能来组织。
    菜单测试细则:
    1):
    菜单通常采用常用--主要--次要--工具--帮助的位置排列,符合流行的Windows风格。
    2):
    常用的有文件編輯查看等,幾乎每個系統都有這些選項,當然要根據不同的系統有所取捨。
    3):
    下拉菜单要根据菜单选项的含义进行分组,並且按照一定的规则进行排列,用横线隔开。
    4):
    一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
    5):
    没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。
    6):
    如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
    7):
    菜单深度一般要求最多控制在三层以内。
    8):
    对常用的菜单要有快捷命令方式,组合原则见8
    9):
    对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。
    10):
    菜单前的图标不宜太大,与字高保持一直最好。
    11):
    主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
    12):
    主菜单数目不应太多,最好为单排布置。

    13):菜单条是否显示在合适的语境中?

    14):应用程序的菜单条是否显示系统相关的特性(如时钟显示)?

    15):下拉式操作能正确工作吗?

    16):菜单、调色板和工具条是否工作正确?

    17):是否适当地列出了所有的菜单功能和下拉式子功能?

    18):是否可能通过鼠标访问所有的菜单功能?

    19):相同功能按钮的图标和文字是否一致?

    20):是否能够用其他的文本命令激活每个菜单功能?

    21):菜单功能是否随当前的窗口操作加亮或变灰?

    22):菜单功能是否正确执行?

    23):菜单功能的名字是否具有自解释性?

    24):菜单项是否有帮助,是否语境相关?

    25):在整个交互式语境中,是否可以识别鼠标操作?

    26):如果要求多次点击鼠标,是否能够在语境正确识别?

    27):如果鼠标有多个按钮,是否能够在语境中正确识别?

    28):光标、处理指示器和识别指针是否随操作恰当地改变?        
    7:
    独特性:
    如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    测试细则:
    1):
     安装界面上应有单位介绍或产品介绍,并有自己的图标。
    2):
     主界面,最好是大多数界面上要有公司图标。
    3):
     登录界面上要有本产品的标志,同时包含公司图标。
    4):
     帮助菜单的关于中应有版权和产品信息。
    5):
     公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

    8:快捷方式的组合
    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
    菜单中:
    1):
    面向事务的组合有:
    Ctrl-D
    删除 Ctrl-F 寻找 Ctrl –H替换;Ctrl-I 插入 Ctrl-N 新记录 Ctrl-S 保存 Ctrl-O 打开。
    2)
    :列表:
    Ctrl-R
    Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件;。
    3):
    编辑:
    Ctrl-A
    全选;Ctrl-C 拷贝;Ctrl-V 粘贴;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。
    4)
    文件操作:
    Ctrl-P
    打印;Ctrl-W 关闭。
    5):
    系统菜单
    Alt-A
    文件;Alt-E编辑;Alt-T工具;AltW窗口;AltH帮助。
    6):MS Windows
    保留键:
    Ctrl-Esc
    任务列表 Ctrl-F4 关闭窗口; Alt-F4 结束应用;Alt-Tab 下一应用 Enter 缺省按钮/确认操作 Esc 取消按钮/取消操作;Shift-F1 上下文相关帮助。
    按钮中:
    可以根据系统需要而调节,以下只是常用的组合。
    Alt-Y
    确定()Alt-C取消;Alt-N 否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。

Open Toolbar