界面测试是否需要编写测试用例？（2009-3-2 ）获奖名单已公布

默默巫

背景描述：界面测试中有相当大一部分并不针对软件的运行，而是用“看”的，即布局是否美观、字体是否统一、控件是否对齐、提示是否标准等等，这些内容在测试的时候是必须要考虑的，而且每一个页面都要“看”，工作量不大，但是工作面很大，那么针对这类型界面测试是否还需要写测试用例呢？

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

奖项	获奖名单	奖励	答案连接
最佳话题PK手	beryl_lin	当当购物卡50元+最佳PK手勋章	5#

peterz

首先我想说的一个问题就是，软件测试的最终目的是什么，其实就是追求一个软件质量和成本之间的平衡点。把握好了这个观点，我们就可以谈论下面的这个问题了。
1 老板给我们多长时间，要我们进行测试的页面有多少，粒度是多大
如果老板给我们的时间够长，比如1个月，页面不是很多。那我觉得对于用户使用性的测试是可以接受的。但是时间紧任务重，那么我觉得用户使用性的问题就可以不用测试，或者说是不是重点测试的对象。
2 要看需求，如果需求说明书规定了，这部分是上线内容要求的，那我们就进行测试。如果不是，有时间可以测试一下，没有时间可以大概浏览一下就可以了。

sogoc

从我个人来说，界面测试是必须的，但要分清轻重！
1.客户对产品的评价第一就是界面，第二就是易用性，其他的关心比较少（比如非法测试、特殊字符测试....这类的，因为客户是人，从常理上看，他不会那么无聊去输入一个非法来检查软件是否健壮，当然为了软件的健壮性，我们还是需要测试非法字符这类的测试的）
2.从公司的成本角度来考虑，测试界面是个大工程，绝对不会比功能测试简单，而且更单调，比如字体的统一，全中文显示或者全英文显示，提示窗口大小位置，输入框长度，大小，左分页、右分页、上下分页的分割比例多少，17，19，22...各个尺寸显示器的显示如何，普屏宽屏的显示如何，IE6,IE7如何显示.......这类的太多了，如果做到规范，也是值得考虑的，这些都需要公司能做出一个标准化的框架才能节约成本。
3.另外公司毕竟是以盈利为目的的，对待不同的项目，界面测试应该分等级，比如第一个等级是只要页面不显示错别字，整体字体合适...这类的，第二等级再第一个等级要求基础上加入其他的元素........这样一层一层下去，知道最高等级就是什么都测试，当然这个部分一定要项目经理在成立的时候就跟客户说明白讲清楚，因为界面测试不会比功能测试所耗的工作量少，所以一定要考虑到成本和客户的承受能力。整体的综合考虑！

YY下我个人感觉，因为我这公司也开始要求要界面测试了。

weifei1031

编写用例只是为了更好地、规范的执行某项测试活动！但是界面这个与用户接触最近，且也是最容易变动的组件，对于用例的维护是很浪费时间的事情。可以列出该界面的元素，具体标准参考界面设计规范，测试人员要做的只是截下当前设计版本的状态图。

ZhuCrystal

软件测试为的是提高软件的质量！因此只要关乎软件的质量的方面我们都必须要测试。但是任何一项测试都是需要时间以及成本的，因此在有效的时间把握好测试是很重要的。在时间充足的情况下，我们可以对界面进行详细的测试，根据规范的流程一步一步往下走；在时间紧迫的情况下，我们要从客观考虑，对于界面测试挑重要的去测试就可。

beryl_lin

一、关于界面测试

用户界面测试，英文是User interface testing。又称UI测试。

用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

第二，关于测试用例

测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。其重要性体现在如下方面：

1、测试用例构成了设计和制定测试过程的基础。

2、测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。

3、判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。

4、测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

5、测试设计和开发的类型以及所需的资源主要都受控于测试用例。

第三，现实情况

在传统的软件开发过程中，测试似乎总显得没有开发重要。前期的需求分析、系统设计阶段会生成的相应的文档，开发持续的时间也会比较长，而且在开发过程中仍然会有需求文档的变更，所以，测试用例一般要到后期集中测试阶段才来编写，但是到那个时候往往时间不会很充裕，更多的精力需要集中在功能测试方面，相对来说，用户界面是否友好似乎显得不是那么重要，而且很多人认为直接根据需求文档凭借测试员自己的经验来执行就可以，UI测试用例的编写也就被忽略。

在敏捷开发中，测试是整个团队中非常重要的一个角色。往往在开发之前就已经介入，测试用例是依附于每个story。story的功能需求基本在AC（验收条件）里边会有详细的描述，测试用例来自于AC，这种情况的测试用例可能不会写的很细，但是一般story的功能、性能和UI方面都会涉及到的。

总之，用户界面是系统与用户交互的唯一接口，是系统的门头，是非常重要的一个组成要素，对用户界面的测试，对其质量的保证也就至关重要；另一方面，用户界面包含很多复杂的元素，易用与否，是否满足需求都会影响到整个系统的质量，没有完整的测试用例，不经过系统的测试显然是没法保证这个质量的。不管现实情况是否对UI测试编写测试用例，无规矩不成方圆，只有严格的编写测试用例，并依据测试用例执行严格的测试才能尽量提高系统的质量，获得用户的青睐。最佳情形是，不管是传统的还是敏捷的开发方式，测试人员都要尽早的介入，一旦需求确定就开始编写测试用例，以确保等开发完成的时候有足够的时间来执行测试。如果PM不能认识到这一点，我们作为测试人员应该有明确的意识，要争取在团队中的地位，扩大测试的整个开发流程的影响，和团队成员共同来提高软件的质量。

[ 本帖最后由 beryl_lin 于 2009-3-5 11:11 编辑 ]

小草

不论是现在的定制开发项目还是产品，都十分关注人际交互的页面，除了功能的实现外，页面的美观和友好会影响客户的使用，从而影响客户对你产品的质量的反馈。严重一点会影响到你项目的成败，进而导致客户对生产单位的技术水平失去信心。我曾经经历过这样的项目，由于忽略了页面的设计和测试，导致客户高层非常不满意，险些单子都都掉了。设计页面的测试用例，重点是要提醒你面对每一个页面都要关注那些地方。对于复杂的页面尤其显的重要，提前规划好页面的测试，肯定是需要设计测试用例的，简简单单的用眼睛看，肯定会遗漏某些内容，这样风险会更大。当然对于页面测试用例的执行，由于工作量很大，在回归测试阶段可以依据优先级综合考虑。

cuixiaoyan1020

应该每个测试都需要写测试用例,就算测试不重要,也要写测试用例,不能省的.

peterz

原帖由 cuixiaoyan1020 于 2009-3-3 15:48 发表
应该每个测试都需要写测试用例,就算测试不重要,也要写测试用例,不能省的.

原则是这样，可是当成本和质量冲突时，老板选择了成本，请问你如何处理。

hdtest001

这个是需求时候谈的吧 页面定的差不多就不要浪费时间去写那些用例了 成本很大的

candy_83

软件质量特性分为六个方面：功能性，可靠性，易用性，效率，可维护性，可移植性
界面测试和功能性，易用性，可移植性都有联系。
所以为了保证软件质量，界面测试是必不可少的。界面测试如果没有测试用例，就好像猴子测试，测试的有效性不会高的。
只有从界面必须简洁，一致，易用的原则出发去设计测试用例，这样不光对于测试者测试时有依据，也会起到启发和抛砖引玉的作用。

qrz2000

在项目启动阶段，对这个项目的可用性就应该有一个基本的评判，它应该到什么程度。
然后再针对这个基准，去判断是否需要编写界面的测试用例。
其实界面测试用例大多数会是一些公用的测试用例，如果每个都写是非常浪费时间且无效的。

peterz

原帖由 candy_83 于 2009-3-3 17:22 发表
软件质量特性分为六个方面：功能性，可靠性，易用性，效率，可维护性，可移植性
界面测试和功能性，易用性，可移植性都有联系。
所以为了保证软件质量，界面测试是必不可少的。界面测试如果没有测试用例，就好像猴 ...

你说的很好
可是软件的质量是通过需求规格说明书来限制的，需求规格说明书是根据软件的进度来实时进行调整的。如果有时间，那是最好。可是在我接触的10几个项目中，界面测试是优先级最低的，往往为了赶工期，最低优先级的往往是最容易忽略的。

兆隆8032

界面的不友好直接影响最终的心情，保证最终用户的心情愉悦的方法就是保证界面的高质量性，这种高质量界面的保证就是界面测试的测试用例。

peterz

原帖由 兆隆8032 于 2009-3-3 19:00 发表
界面的不友好直接影响最终的心情，保证最终用户的心情愉悦的方法就是保证界面的高质量性，这种高质量界面的保证就是界面测试的测试用例。

如果时间允许，当然是越精越好。如果连功能流程都走不通，界面在漂亮又有何用那。

jiao_leo

我是初学测试，感觉测试用例就是要将测试条理化。在方案中我们可能已经将测试模块划分出来，在用例中就要细化方案的执行。有些执行的顺序也会影响测试的结果，这时我们就需要不同的用例来验证方案中的一个功能点。在方案的提供者和用例的执行者不是同一个人的时候，问题就更会显现。只以最常用的方式去验证一种情况，和在某些特殊条件下验证一个功能点是完全不同的。这时候细化的用例就可以给我们提供帮助。所以我支持用例。虽然界面的用例比较简单，但是也是非常重要的

zhyb_2008

无论做软件,项目开发,还是一些WEB网站的开发.都有一个最初的,也是一个根基阶段,就是需求分析.再往软件工程领域的大纳上看,就是概要设计,详细设计,以及开发......
而做为测试这个对产品质量做技术性检测的一个独立的部门,从一开始,已经介入
一个完整的测试过程执行时,也会有测试需求分析,各个阶段的文档的评审.然后,才是一个测试用例的编写 以及测试实施过程.
了解上面的后:
我从时间和结果来简要阐述一下自己的观点
从时间上看,如果周期长.那在测试用例设计之初的各类文档,已经很细化.做为测试部门,只需要跟进那些文档,和其他的部门,如一些策划,设计,开发等部门做文档评审时,很多问题就会在评审过程中而解,不会到最后还需要在测试用例中去列出单独的界面测试.当然,界面测试用例没必要写出来,界面走查工作还是要做的.
另外有了充分的时间.可能一些比较正规的文档中,甚至都会利用一些类似VISIO,FLASH等辅助软件,把详细设计文档做到最精了.接下来开发编码时,所做的可能就只是按着这个去做而已.所以,测试用例在中后期的重点,也应该是功能,性能等方面的测试,不必要做太多的界面方面的文章.主要一方面的还有,很多公司,在时间上.往往前期时间很宽,最后面的集中测试时,加上一些回归测试,性能分析测试等.时间往往在测试这里时,捉襟见肘.

从最后的结果看.很多时候,不去写界面的测试用例,按部就班的执行,只是做界面的走查后,也不会有什么问题.当然,也不是全没问题,比如现在的人可能因为对文字的认识,会用错一些不当字,词,句.这些,在走查是,应该是可以发现的,如果没有发现,也只能说大家都认为他是对的.只能进行所谓的"一错到底",到现在,我甚至不知道到底是"登录"还是"登陆".估计很多人和我一样吧.
毕竟有时候要求不同,对用例的一个评审级别也不同.
不过,我还是认为,大多数情况,估计没人刻意去对所有的界面做一个用例,然后再做详细测试.除非一些测试部门,要求一些测试员每天必须做多少用例,才能拿到多少奖金之类的.应该才会拿着一个界面测试用例去充数吧.
我们做测试的目的,是发现问题,可是,发现问题除了根据用例执行发现之外,可能有时凭的是经验,瞬间闪现,以及对整个产品从整体到细微的一个把握.而不是纯粹体现到用例上.

peterz

原帖由 zhyb_2008 于 2009-3-4 14:57 发表
无论做软件,项目开发,还是一些WEB网站的开发.都有一个最初的,也是一个根基阶段,就是需求分析.再往软件工程领域的大纳上看,就是概要设计,详细设计,以及开发......
而做为测试这个对产品质量做技术性检测的一个独立的 ...

说的很透彻，很符合现在软件公司的实际情况。
其实，大家都知道界面测试是必须做的，但是到最后有几个能做那。正常的软件流程是开发占总工期的30%，测试占30%。可是实际那。相信大多数公司都不会太高。
如果测试部门是独立于开发部门的情况还稍好一点，如果测试隶属于开发，那么测试时间到后期会被压的很少。
说的不好，欢迎拍砖

郁闷的我

大多数情况下是不需要。

centurystone

借用一句士兵突击上的话:"是事情就有它的程序".
测试无小事, 不是过家家,
对于一些想不到的地方都要进行测试,那摆在我们面前的界面我们有什么理由去忽视它的存在