如何对软件的界面操作进行有效的测试？(10-12-27)（获奖名单已公布）

默默巫

如何对软件的界面操作进行有效的测试？例如快捷键，菜单，工具条

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	狩猎者	300论坛积分	4#

crazy715

界面操作的有效测试，个人觉得至少应该从易用和功能2方面考虑
易用性包括快捷键操作、界面操作的向导性、鼠标操作距离
功能基本就是考察菜单功能是否实现正确，是否合理，是否满足用户最基本的操作

对于易用性中测试，其实最根本的出发点在于需求，很多测试过多的偏重于快捷操作等等，但是站在用户的立场去考虑，是否有必要做这样的设计？这样的设计是否会给测试和开发带来成本的投入？

有效的测试不光需要去验证对错好坏，更要站在宏观角度去认识软件在实际操作中的意义，取精华，去糟粕，这才是有效最终目标吧。。

阿七

占位..

狩猎者

1、人机交互性
（1）界面设计简单明了，布局符合用户业务需求，使用户能够很容易找到自己想要使用的功能。页面设计复杂，无疑会对用户操作

效率造成影响。如果我们把所有功能都罗列在一个界面中，用户使用起来只能感觉眼花缭乱，无所适从。
（2）功能名称命名使用用户行业专业术语和常用计算机语言，相同功能命名要统一。名称命名不规范，常常会使用户不知道如何进

行操作，容易造成误操作。
（3）图标、标识符合通俗易懂，特别是打开、保存、关闭这些常用按钮图标，不要追求出新和另类。

2、易用性

（1）菜单设计最好不要超过3层，超过3层菜单，用户使用都会觉得比较复杂。
（2）快捷键设计采用常用快捷键设计，如：F5刷新，Ctrl+C复制。
（3）TAB键的顺序符合业务需要，特别是录入页面，根据用户工作习惯进行顺序设置。
（4）浮动工具条位置、长度、大小，不要遮挡界面主要内容。
（5）减少页面跳转，尽量一个功能在一个页面内完成。
（6）鼠标右键功能和右键菜单的设计。

3、用户的使用习惯
针对不同行业，用户都有不同的使用习惯，界面的操作要符合用户的习惯，特别是产品升级时，界面设计一定要考虑老用户的使用习惯。
4、行业特点
有很多行业具有一定的特殊性，界面操作必须要考虑到这点，比如提供给客户服务热线电话登记的软件，就要考虑让用户尽快少的点击鼠标和使用键盘。一个下拉菜单选择项，需要点击鼠标两次，而一个单选框只需要点击一次，这样的设计虽然很微小，但对用户实际操作会起到很大的帮助。
5、特殊需要
对用户的特殊需要，是否能够很好的实现。例如更换登录用户，大部分软件都是使用者退出，返回登录界面，然后使用另一个用户登录，有的用户就会提出在主界面可以直接登录另一个用户，当前使用的用户自动退出。

582357212

测试的思想就是要贯穿整个软件生命周期，因此我们测试也就需要根据软件各个阶段的产出物进行。
界面测试也是当今功能自动化实践效果比较好的一个测试活动阶段。因此也需要分为自动化和非自动化方面考虑。
一、手工测试方面
1.  界面的需求，概要设计，详细设计文档测试，确保需求和设计统一。当然如果公司没需求文档就需要测试人员的测试经验来了。
2.  用例设计方面，需要考虑
（1）本地化方面：软件是否支持多国语言，例如，软件界面是否使用资源文件。
（2）交互方面：页面各个控件能否正常响应，界面是否美观，整体风格是否一致，操作控件排版是否合理，是否符合使用者习惯，用户范围，用户行业，系统界面提供的内容是否正确。
（3）有效性方面：界面所有的输入框是否都进行了有效性验证，有效验证的提示文字，颜色，风格是否符合需求。
（4）安全性方面：是否存在SQL注入式漏洞。
二、 自动化测试方面
1. 在系统界面出来的时候（不同公司产出阶段不同，一般为概要设计出来，界面也就出来了），针对开发给出的程序界面，或说明文档，测试界面所有控件的名称和相关识别熟悉，具体方法可参照静态测试相关理论，结合公司自己相关规范。最后提炼出界面所有控件的唯一识别属性，并记录为文档。
2. 建立对象库，或者将对象属性导入到数据库中，根据手工测试用例设计需要考虑的方面，编写自动化测试脚本（此部分一般公司都有特定的自动化脚本用来重用）。
当然想达到界面操作的有效测试，还有关键的一块就是需要变更的管理与跟踪，要确保需求即时，准确的到达负责测试的人员手中。就是项目信息的高效共享，各个公司有各自的规范和手段。如果有一个好的管理者，那么能够激发测试人员的激情，那么测试效果更好。
这就是我对软件界面操作进行有效测试的一点点个人看法，纯属抛砖引玉。

mcfnhm

菜鸟留名.

zyq_799

手工测试的多一些，先保证功能、其次就是用户体验方面的。新手，多多指教

caoase

如何对软件的界面操作进行有效的测试？例如快捷键，菜单，工具条

下班前10分钟来回答一个问题。
首先，界面设计的测试以前，你要熟悉这个软件界面设计需求，知道这个界面是做什么，每个快捷键，菜单，工具条是干什么的。这个叫做Scope.
其次，最好能和别人讨论一下，大家做一下coverage，搞搞评审。不要以为你自己多强，强人都是mgr了。
然后，开始干活，什么测试计划，测试方案还没写了。有些人说，敏捷了，这些不用写了。我的意见是，一定要写，但是可以写的简略，自己和别人能看懂就行了。
准备工作做好了，开始干活吧。想想快捷键，菜单，工具条有哪些，他们有没有子菜单，在测试计划里面和测试方案里面想去怎么测试它们。
一般对于界面，要注意合理性，容易被用户接受，和以前的版本要保持一定的延续性，要符合软件的整体界面设计，要美观大方。这方面的东西，自己先去想，然后再去百度看看别人还有什么要你注意的。（其实，这些东西都是写在你的测试方案里的）。
那么，事情算完了吗？假如你是负责人，你敢说该界面设计过关了吗？你要承担怎样的压力？OMG，所以，你要上班想，吃饭想，下班想，班车上想，洗澡想（我单身，想工作的时候比较多）。
然后，你怎么都想不到办法去找到新的BUG，那么OK，这个界面测试过关了。
BTW，有时候，你想不到新的方法的时候，试着去写一些你所做测试的测试用例，这样你可能会有灵感。
最后，引用一句话：
You can't solve a problem using the same mindest that created that problem.

theyoungest

回复 8# caoase
说的很具有可行性，是从实践中总结出来的。顶。

actrei

个人认为，首先应该明确软件针对的用户群，根据用户群去划分需要进行的界面操作测试。我现在的工作中用户群有两大类：外部用户（一般指对外使用的客户）、内部使用（一般指公司内部的员工）。划分出用户群后，针对用户群的特点进行有针对性、侧重点的测试，在一般的软件项目中满足以上的了解就算界面操作测试合格、有效。
   外部使用：界面操作要求高
   对于外部用户群，往往需要极高的用户体验感。在保证软件功能质量的前提下，针对不同的外部用户群需求，去制定相对应的界面操作测试点，例如软件的易用性（包括功能的适用、不冗余、快捷键习惯等）、界面的友善（界面风格、交互信息等）。另外因为有不同特色的外部用户群，所以需要设置界面操作测试侧重点（例如娱乐型软件，侧重界面友善、视觉冲击力；电子商务网站前台，侧重业务流程明晰、简洁方便）。在测试计划中必须增加界面操作的测试工作。
   内部使用：界面操作要求偏低
   对于内部用户群，对界面操作要求偏低。一般只需要保证软件功能质量，进行简单的易用性测试。针对不同的内部用户群需求，只需要侧重软件功能的实现流程是否简洁清晰、无误导（例如电子商务后台采销系统、财务软件）。
   <全文完>   
   上班
   请拍砖

jrq1224

如何对软件的界面操作进行有效的测试？例如快捷键，菜单，工具条
很高兴和大家一起探讨一下这个问题。
一、界面操作的有效性保证功能没有问题是根本；
界面操作的有效性测试首先要保证界面类菜单，快捷键 ，按钮，工具提示等项满足了用户功能性需求文档；
设计测试用例时可重点考虑：
1.快捷键功能是否可用 ，是否满足用户常用的习惯，是否存在快捷键与自身系统和操作系统的冲突；
2.菜单，按钮，样式B/S 程序要考虑浏览器的兼容性，常用的IE6 IE7 IE8 FIREFOX CHROME;C/S程序重点考虑与OS的交互；
3.菜单功能描述要明确，菜单标题分组要合理，菜单项最好不要超过三级；
4.工具条要考虑工具栏图标的形象化，达到看图明意，还要考虑工具栏的工具提示；

二、界面易用性是提高用户黏度的一个重要手段；
从用户易用性操作入手 考虑界面的风格 样式是否达到了易学易用互操作性和吸引性；
测试用例可考虑：
1.菜单工具条按钮等元素的 图标，字体，文字大小，色调，文字描述信息是否满足多数人的使用习惯；
2.用户的互操作性；
3.考虑系统内元素对用户的吸引性，常用方法有：
   （1）行业类系统应考虑主要针对的用户群，量体裁衣；（如百度提供的有专门的老年版本访问页面http://123.baidu.com/，动感地带主要色为橙色；）
   （2）针对不同的用户群体做一个用户体验，每一个控件都尽量做到微创新（代表软件360安全卫士，微创新觉得没的说了。。）


欢迎大家继续讨论~

jrq1224

如何对软件的界面操作进行有效的测试？例如快捷键，菜单，工具条

很高兴和大家一起探讨一下这个问题。

一、界面操作的有效性保证功能没有问题是根本；
界面操作的有效性测试首先要保证界面类菜单，快捷键 ，按钮，工具提示等项满足了用户功能性需求文档；
设计测试用例时可重点考虑：
1.快捷键功能是否可用 ，是否满足用户常用的习惯，是否存在快捷键与自身系统和操作系统的冲突；
2.菜单，按钮，样式B/S 程序要考虑浏览器的兼容性，常用的IE6 IE7 IE8 FIREFOX CHROME;C/S程序重点考虑与OS的交互；
3.菜单功能描述要明确，菜单标题分组要合理，菜单项最好不要超过三级；
4.工具条要考虑工具栏图标的形象化，达到看图明意，还要考虑工具栏的工具提示；


二、界面易用性是提高用户黏度的一个重要手段；

从用户易用性操作入手 考虑界面的风格 样式是否达到了易学易用互操作性和吸引性；

测试用例可考虑：

1.菜单工具条按钮等元素的 图标，字体，文字大小，色调，文字描述信息是否满足多数人的使用习惯；

2.用户的互操作性；

3.考虑系统内元素对用户的吸引性，常用方法有：
   （1）行业类系统应考虑主要针对的用户群，量体裁衣；（如百度提供的有专门的老年版本访问页面http://123.baidu.com/，动感地带主要色为橙色；）

   （2）针对不同的用户群体做一个用户体验，每一个控件都力求微创新（代表软件360安全卫士，微创新觉得没的说了。。）





欢迎大家继续讨论~(为什么我发了一次自己看不到呢？、)

neubird

网站易用性，用户体验，借用我们这某开发的话-是无底洞。

界面上的易用性以什么为标准？

582357212

回复 13# neubird
准确的说是你们公司测试测到什么时候结束，测试深入到什么地步，这是由谁说的算？是客户，开发，还是项目经理，还是你自己。明白项目的大小，项目的成本，项目遗留Bug对产品交付的影响等条件，那么易用性的标准也就很好定义了，测试的范围和准则也就好定义了。这是一个有关联的问题，脱离实际谈易用性，用户体验等就是一句空谈，即时加到计划中只会让计划缺少可执行性和让这个易用性，用户体验方面的目标变成放在那儿的一段文字 没有任何作用。例如你们就是个小项目，客户说我不要求你的质量怎么好，只要保持基本功能能用，不能收我太多钱，但是时间必须在几号前交付版本  不然我就扣钱，那所有的一切测试准则都是纸上谈兵，结果就是质量很差，客户抱怨很多，但客户永远是对的，这也是所有为了生存而迁就客户的普遍问题。

neubird

回复 14# 582357212

谢谢您的回复~~
其实呢，一些大道理，我们都明白，但是有些事是当局者迷。一切以用户为第一位。但真正设计-开发-测试的过程中，就会出现推诿的现象，毕竟，用户在这个周期内，是不参与任何活动的。这样的情况下，如何判定？其实这就是另一个话题了，权责分配的问题。但是好像现在很多公司都是这样，设计不管，开发不管，都堆到测试上或者根本就没人管，上了线，出了问题，才开始无休止的推卸责任....唉....

582357212

回复 15# neubird
呵呵 工作中很多问题就很难说的，软件过程不规范，神马都是浮云。这种情况下，我个人觉得最好就是想好怎么样做才不至于出了问题会把屎盆子扣在我们测试头上，这也是另外一个话题了。。。呵呵，兄弟淡定，一切看得开些

582357212

我个人觉得LZ这个问题，是让我们思考一个方向，一个理论上比较高效的做法，而不是实际上你怎么做，有了方向，我们可以努力，而不是说现在就要达到，很多公司不同，做法就不同，更何况，如今软件测试说了这么多理论，这么多技术，真正用在工作中的能有几家？大家工作还是按照我们想的那么做，就像很多人都知道设计测试用例的8种方法，但真正写时候还一般都是根据自己经验，最多考虑等价类和边界值就不错了，其实写多了后根据写的经验写出来的也就包括可等价类，边界值，但绝对不会真的根据理论上的8种方法，每一种进行推敲来写，为什么不这么做，不是作为用例设计人员没有这个水平，或者不想用这8种理论，而是很多限制问题，相信工作过一段时间都明白限制条件是什么，不过如此而已。更何况。。。。。明白的人都明白的

lxgandsywy

假如公司有专门的用户体验工程师，那么界面的测试主要是针对输入、输出的规范性，如输入长度，输入字符限制等进行测试。
如果公司没有用户体验工程师，也要看软件是给谁用的，如果是客户是那种专业柜员，就要考虑输入的快捷性、统一性，常用功能是否都有对应的快捷键。如果客户是普通人员，就要考虑界面的友好性、易用性等

helloone

有效测试的前提是： 对软件有深入的了解； 用户如何用软件， 怎么用。

测试离不开具体的应用实例。 个人认为， 如果测试用例里包括了实际的用户使用， 这个测试就是有效的。

sunlight426

回复 15# neubird


    我们公司倒是会考虑项目组各环节的问题，不会把所有责任推给某个人。不过测试还是忠于需求，但是有时候各方面人员的能力问题，导致一些隐含的需求或者业务逻辑没有整理清楚，这时候一般都是开发、需求和测试一起来评审，也能解决一部分问题。
    另外，测试如果团队不大，十几个人，一般都是取决于组长和经理的能力，都是组长和经理指定一系列的规范和通用的测试用例，通过跟踪测试人员的一些过程产物来保证测试过程的有效。这些都只是尽量的保证，无法做到规范。本来就不规范的东西，如何能够规范下来呢，只能说是尽量。。。哎~~