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

默默巫

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

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

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

zhyb_2008

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

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

郁闷的我

大多数情况下是不需要。

chengxq

画面的布局的测试，现在很多都有相应的要求，但是个人感觉这个东西，本身就比较感性，每个人由于自己的成长和经历不同，对自己的审美感觉也不同，所以很难说清楚是好还是坏，唯一的评判标准是客户，如果客户说好，那我们就认为是好，哪怕我们认为很难看，如果客户说不好，那就是不好，所以我们的依据是客户
但是对于画面的layout虽然理论上都要求量化，都有严格的要求，但是我几年的经历，认为这个可执行性不是很高，公司以前搞过，但是现在没有看到项目组在实施，都是根据开发流程来避免出现不适用的过程，这里我也不希望大家把网上的理论搬到这里来进行讨论
个人认为，对于画面layout，我们在开发的过程中，一定要客户进行参加，并且要多做几个不同方案，让客户进行选择，对客户提出的建议要进行收集，根据客户的建议以及选中的一个方案，进行修改，设计出最后的几个方案，让客户在进行选泽，这样基本上能达到客户的满意。当然这里要注意，我这里说的客户一定是能说上话的客户，我们以前就遇到过问题，我们一个项目都是很一个非责任人就行沟通，到最后责任人认为不满意，造成很大的返工！
当然可以采取原型开发也可
当然也可能出现很多软件公司是出的产品，这里就要做好相应的市场调查，让用户进行确认！

yxf

有用例固然是好，问题是写用例所付出的代价与最终用例起到的作用比起来有多大？如果定义 “ X = 测试所付出的代价/ 用例起到的作用  ”，对于界面测试，X的值相对来说就太大了，所以俺反对写界面测试用例。

atomtiger

不用写了吧。工作那么多。。多累啊。。。

3155530

界面测试，跟需求的设计一致即可，到时做出来的跟设计的对照对应。设计大量界面用例没什么必要，但要是实现闲的没事也可以去用例库中补充起来。
现在讨论的是要不要写界面测试的用例而不是要不要界面测试，发现好多人没看清楚话题还是怎末的。界面当然要测试，用例还是没必要。

测动未来

写一个提纲就得了
界面这东西，你没法完全按照需求来写。写一个大致的提纲，边做边修改吧。呵呵

black_tulip

用例能写死你，谁也不会在测的时候去看。

搂搂兔

嗯，工作量太大了，而且很多无用功

orange_10

首先不同意题目中的“UI测试不针对软件运行”，当然在下所处的行业属于.COM，所以UI测试也是绝对重要的，CSS，JS难道不是软件运行？

其次UI的测试用例问题完全是根据公司、项目性质而定的，好比说做产品的，UI有固有范式，用例的重用性能够得到体现；但是像互联网，UI的变化太快，细节繁多，那用例的成本就过于昂贵。如果你处在测试管理的职位，凡事都需要以结果为导向，用例绝不是为做而做，而是做了有什么用，有多大用的问题。如果不需精量成本，或者对测试人员起一个理思路的作用，我觉得写也未必不可，在下甚至还在试用期要求新人们写过“网站功能描述”这种毫无意义的东东，作用是在帮助其更快理解内容，发现问题。所以写不写用例完全关乎于其结果导向的

lansnor

界面测试的规范，其实网上有不少，在测试之前，可以根据需求（或项目研发制定的规范）对这些规范进行补充，然后根据这些规范来进行测试即可。

maclehappy13

刚才忘记选了，我是持反方观点。

江南飞雪

首先，任何事情不能一概而论，我选反方，是因为这个情况是针对中小公司。
因为：一，我想很多公司，其实根本就没有界面设计的概念，很多的软件一看界面上基本上都是一样的。所以说本身就没有办法设计出很好的界面。二，界面上的东西基本上就是一些文字错误，排版等，这个可以不用设计用例。而至于易用性，这个就更不好说了。本身测试人员设计出来的用例就很难保证用例的质量。因此，我们测试小组会依据开发经常出现的界面问题，做个总结，并把一些常用的界面测试规范加入到这些条款中。让开发人员在开发这前就参照这份准“界面规范”去设计，到时测试人员也是依据这份“规范”再去提一些不符合“规范”的问题。
当然，如果公司规模很大，测试技术很强大，追求完美，设计肯定比不设计好。我们这是退而求其次。不可能让一个饭都吃不饱的人谈论参加PARTY要穿多高档多漂亮的衣服，一样的道理。

majun915

男人的第7感啊。不用写啊 呵呵