51Testing软件测试论坛

标题: 界面测试是否需要编写测试用例？（2009-3-2 ）获奖名单已公布 [打印本页]

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

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

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

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

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

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

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

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

作者: beryl_lin 时间: 2009-3-3 13:43
标题: 界面测试需要测试用例
一、关于界面测试

用户界面测试，英文是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 编辑 ]

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

作者: cuixiaoyan1020 时间: 2009-3-3 15:48
应该每个测试都需要写测试用例,就算测试不重要,也要写测试用例,不能省的.

作者: peterz 时间: 2009-3-3 16:13

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

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

作者: hdtest001 时间: 2009-3-3 16:48
这个是需求时候谈的吧页面定的差不多就不要浪费时间去写那些用例了成本很大的

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

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

作者: peterz 时间: 2009-3-3 18:20

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

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

作者: 兆隆8032 时间: 2009-3-3 19:00
标题: 界面的不友好直接影响最终的心情
界面的不友好直接影响最终的心情，保证最终用户的心情愉悦的方法就是保证界面的高质量性，这种高质量界面的保证就是界面测试的测试用例。

作者: peterz 时间: 2009-3-4 13:36

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

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

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

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

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

作者: peterz 时间: 2009-3-4 16:10

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

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

作者: 郁闷的我 时间: 2009-3-4 16:39
大多数情况下是不需要。

作者: centurystone 时间: 2009-3-4 17:14
标题: 支持正方
借用一句士兵突击上的话:"是事情就有它的程序".
测试无小事, 不是过家家,
对于一些想不到的地方都要进行测试,那摆在我们面前的界面我们有什么理由去忽视它的存在

作者: ifoxmulder 时间: 2009-3-4 20:27
标题: 测试是持续的
测试其实根本上是一种对软件的保证.
界面测试不是一件容易的事情,测试人员对界面测试的时候随便看看固然可以,也许也能发现很多的问题,但这一切都是建立个人的英雄主义上的,这样除了我们自己别人怎能了解我们这样做的原因和意义,一段时间后如果项目再开或类似项目再来,也许连我们自己都不知道我们以前做了什么,为什么这样做了,又要重新开始思考.如此我们到底做了什么?.
测试用例的存在却能让整个团队和后来的人员有一个整体的认识,知道我们已经做了什么,这样做是想发现什么问题,这样不仅可以在团队发言中有据可依,也是后来的一种宝贵财富,及对自己也对自己的接班人,甚至对整个公司后来的项目也许同样有种参考价值.
界面测试确实不够重视,情况很多,价值不高,麻烦重重,但做了就让我们努力发挥一些作用
所以我支持编写测试用例.

作者: CHOUYUNHAT 时间: 2009-3-5 11:50
标题: 界面测试也很重要
首先，用户最先看到的就是界面，一个界面都做不好的软件用户肯定不会有好印象，必然对产品产生更多的怀疑。其次，测试是比对需求。软件的界面也不会是凭空想象出来的，必然也要满足用户的需求。具体到界面的细节，比如是弹出式还是嵌入式、是否要最大化、字体的大小、标题的位置、显示的内容、button的规格等等，软件开发实际上都必须有统一要求的，这些也必然构成需求。这些测试也应该由测试用例来体现。

作者: komado 时间: 2009-3-5 13:47
标题: 需要
界面测试，文档测试有一些通用的的规则，各只编写一份，所有被测软件都适用，不用每个软件都些！

作者: asprit 时间: 2009-3-5 15:12
标题: 个人觉得还是需要编写界面测试的测试用例的。
对于界面测试，有的人可能担心浪费时间什么的，觉得没有必要写，有的人觉得产品功能性能测试OK了就好了。
首先，界面测试很重要，有的产品功能很强大，但是界面很粗糙，所以销量并不好，这点就不多说了。所以，对于测试人员老说，除了功能和性能测试以外，提出了界面的测试。
其次，UI测试可以从以下角度考虑设计，这方面的资料很多，大家可以参考。例如控件测试：包括编辑框，单选按钮，复选框，组合列表框，滚动条控件等等，还有一些易用性细则，规范性细则，合理性细则，美观与协调性，独特性等等。
最后，所有的界面测试用例整理了以后，我们可以以Public的方式整理出来，就不用针对每个产品做单独设计。这样既不会浪费时间，下个新人来了，就可以直接学习，参考，不会因为不知道这方面的测试而漏测。大家测试时，也可以参考，添加积累。最后形成比较完善的测试用力，方便以后的测试。

作者: zhengxiangjun86 时间: 2009-3-5 15:25
标题: 以符合需求为重要
为什么以需求为重要呢，软件的质量好坏无非就是满足用户需求的。就算个人觉得再好，用户不满意，那还是不合格。
用户需求决定了测试优先级，当然测试重点就很明了了。当然软件的作用还是主要在功能、性能。没有那个用户不希望自己经常面对的软件更美观，需求中或多或少都会提及到界面的一些要求。而且界面有时也会影响到功能，比如链接和下拉框等。。。
其实在很多时候功能测试用例中已经包涵的界面的一些操作，如果需求中界面要求较高，例：某公司的宣传网站。那GUI的等级就不言而喻了。
当然公司在实际操作时候肯定由于成本和进度的关系会忽略GUI，不过本着负责的原则，编写测试用例时候把GUI考虑进去无疑会更让客户满意。

作者: 沉默风云 时间: 2009-3-5 16:27
标题: 界面测试是否需要编写测试用例视具体情况而定
1.编写测试用例的利与弊：
利处：便于版本控制，便于用例管理、可以提高测试的效率和有效性。
弊端：要花费一定的时间、人力、财力；延长测试时间、延长项目进度；

2.界面测试是否需要编写测试用例？这个需要根据具体的项目、具体的用户需求来定。如果项目比较紧，要考虑到成本时；或者考虑到界面测试的特殊性，不利于编写测试用例；或者开发的系统对界面要求不严格，界面功能过于简单。那可以不编写测试用例，但是在测试的过程中，测试工程师心中应该有一份测试用例。不能无计划、盲目的测试。
如果界面测试功能多、复杂；如果用户特别关注界面测试，需求严格；如果编写界面测试用例对项目进度影响不大，有比较充足的时间；如果公司是CMM，ISO认证企业，必须有相应的文档或者客户必须要测试用例文档；那么为了保证测试的质量、测试的有性，我们应该编写测试用例。

3.有没有编写测试用例，最终的目的只有一个：能保证测试的质量、满足用户的需求。

[ 本帖最后由沉默风云于 2009-3-5 16:34 编辑 ]

作者: mytoyliu 时间: 2009-3-5 16:59
标题: 测试用例是一种宝贵的资源
要讨论这个问题，我们首先要知道测试用例的读者有哪些。
1、测试人员。因为测试人员需要使用它来进行测试。没有测试用例的测试有极大的可能会遗漏一些重要的测试。
2、策划人员。自己的设计是否被正确的理解了，策划人员通过测试用例得到答案，甚至策划人员也能在测试用例中发现自己在设计中的遗漏。
3、程序员。程序员可以通过测试用例来检查一遍自己的代码还存在什问题。
4、测试经理。测试用例是经历考察下属工作内容的一个方面。
5、其他管理人员......
这就不一一说了。
同时各个公司都面临有人员流动的情况，如果上一个测试人员走了，且他负责测试的部分没有任何测试用例留下，那么后来的测试人员就需要再次设计测试用例，那样就浪费了大量的时间和工作量。
即使是界面测试也不例外。
所以测试用例对整个游戏来说都是一个宝贵的资源，不能因为自己认为的简单而忽略。

作者: 月野幻儿 时间: 2009-3-5 17:33
大家说的都很精彩啊！
界面测试也很重要的，需要编写

作者: richieleely 时间: 2009-3-5 20:55
标题: 我觉得好像偏题了点点
这里讨论是：界面测试需要不需要编写用例
而不是：界面测试需要不需要

测试是一定需要的
但是用不用编写用例，要看实际的时间和项目要求
如果是一个客户内部管理软件，可能对界面的要求就要比门户网站低
要求不同，测试的力度不同，对测试用例的要求也不同

另外，我不是很明白这里所谓的测试用例的真正涵义
列出测试点，算不算是用例呢？

所以，我认为，要具体情况具体对待

[ 本帖最后由 richieleely 于 2009-3-5 20:57 编辑 ]

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

作者: fflastjay 时间: 2009-3-6 17:54
标题: checklist的准备和用例的准备
对于页面的界面测试,如果没有需求对界面有规定,那么大可不必准备测试用例,但是根据经验和按照一般页面界面要求准备的checklist是非常必要的,如果说,简单的看看,谁知道你看了还是没看,就算你真的看了,你能保证不漏什么吗,所以一个时时更新的checklist是必须的,这样也便于你测后的工作报告制作.

如果需求对界面有严格规定,那么这个页面等于有了区别于其他页面的特殊要求，这个我认为需要写测试用例来覆盖这些需求

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

题目的意思是针对工作量不大但工作面很大的界面测试是否需要写测试用例，我认为这才是这次辩论的主题，而不是什么测试成本之类的

作者: puchonghui 时间: 2009-3-6 22:50
要不要写测试用例和测试类型无关
重要的因素是进度和工作量
任何测试都是一样，如果要求的进度根本不够写所有测试用例的，那当然不可能去写。
所以关键问题就在于如何去估算工作量。。。

作者: yxf 时间: 2009-3-7 16:53
标题: 活学活用
有用例固然是好，问题是写用例所付出的代价与最终用例起到的作用比起来有多大？如果定义 “ X = 测试所付出的代价/ 用例起到的作用 ”，对于界面测试，X的值相对来说就太大了，所以俺反对写界面测试用例。

作者: peterz 时间: 2009-3-9 11:18

原帖由 chengxq 于 2009-3-6 16:08 发表
画面的布局的测试，现在很多都有相应的要求，但是个人感觉这个东西，本身就比较感性，每个人由于自己的成长和经历不同，对自己的审美感觉也不同，所以很难说清楚是好还是坏，唯一的评判标准是客户，如果客户说好，那 ...

任何的测试都是需要有测试计划，测试要求和测试用例的。

作者: tangking1 时间: 2009-3-9 13:47
标题: 界面是软件的脸皮，需要除问题
界面测试除了查看界面一致性还是友好性外，还有就是功能的连接问题，界面的连接按钮直接是调用内部代码的，如果只是走查试的看看漂不漂亮的话，相当于不要做测试勒！黑盒测试的重要性是不言而喻的！

作者: 风中一片雪 时间: 2009-3-9 14:22
标题: 测试用例很重要
界面测试非常繁琐及枯燥，很容易产生心里疲惫。即使你不想偷懒，可实际测试过程中很容易流于形式。故用例非常重要，1：它给你了测试的主题框架2：写用例的过程就是你对测试点汇总创造过程，有用例的测试远比随便看看要全面及深入3：测试用例本身也是对测试者工作肯定的一种度量。
当然了，根据工作量，灵活安排用例详细程度才是王道。但用例绝对不能省略不写。

作者: joannaready 时间: 2009-3-9 16:11
标题: 界面测试不是小事
人的心态，容易以貌取人，软件产品也一样。苹果的成功在于它给用户的视觉等体验，同样我们公司做与苹果相关的项目，界面测试的权重最高；而其他项目，产品的亮点不同，可能某些功能的权重更高。这不是一概而论的，但是界面体验绝对是高级要求，产品做到一定程度上功能和性能完全满足用户需求，能提高的就是用户体验，就是界面等效果。一句话，好东西大家都喜欢！但是现实中，最大的障碍是资源，包括时间、人力等，需要平衡一个点罢了。中国人是很擅长中庸之道的。
但必须强调的是：开发人员往往做出来的东西是功能强大，使用很麻烦、界面也是“灰不溜秋”的东东；测试需要写好用例要求美工和开发配合做出可以世人比较愉悦接受的界面、体验，测试该尽自己的职责给产品打扮好“出嫁”。界面测试不是做不做的问题，是做多少，做到什么程度的问题。

作者: peterz 时间: 2009-3-9 18:06
如果从测试人员的角度考虑，我建议写测试用例。如果从测试经理或者PM的角度考虑，记得从整体项目的角度考虑。一般不会建议写测试用例。或许是站的角度不一样吧。

作者: Kity_88 时间: 2009-3-9 19:01
标题: 界面测试应该根据实际情况
我认为每个公司都有每个公司的实际情况，公司人数足够，资源比较丰富和项目要求比较严格的情况下，把界面测试做得越仔细，软件就越好，用户使用起来感觉就越友好；相反而言，公司测试人员不足和时间紧迫，界面测试可以减少一些，可以把主要的测试用例写出来就可以了，但详细的测试还是要做的。但这些情况都要根据公司的体制而执行不同的测试标准，我想不太会完全照搬书上那一套完整的测试流程进来的。

作者: ahu201 时间: 2009-3-10 11:54
标题: 為什么要寫測試用例
1. 測試用例的定義是什么?作用是什么?
2. 界麵測試的重點是什么?
3. 界麵測試之外需要攷慮的東西是什么?
4. 項目管理角度.

作者: 纽约的西瓜 时间: 2009-3-11 12:37
我觉得界面测试，要有着重点
先功能，后美观。
比如先测试界面是否能注册，下发，等诸如此类的功能。
然后是统计，查询等功能。
最后是美观等。
还是需要测试用例的。

作者: chengzilovechen 时间: 2009-3-11 20:05
标题: 支持正方
软件测试和程序是相辅相成的，
你写完一个给测试员测试。
还可以休息会。而不是一直在写代码/
这样也会狠累。还要调试找错误。
也许你达不到交付的时间。

作者: hqchen_23 时间: 2009-3-12 14:22
标题: 需要测试用例
1.UI测试确实是一个繁琐的工作，但是正是因为这样才需要一个好的测试用例进行规范，便于后期的往返测试而不至于遗漏。
2.如果有了很好的测试用例，并且验证点清晰，那么在条件允许的条件下可以开发自动化测试，因为对于UI的自动化测试的设计是比较容易的，并且可以为测试带来很大的效率提高，不但提高的测试成功率更加减少了测试重复性。
因此，设计一个规范的测试用例不仅仅是保证测试的不遗漏性，也是为了后期的自动化测试奠定基础。

作者: atomtiger 时间: 2009-3-12 14:23
不用写了吧。工作那么多。。多累啊。。。

作者: 橙色苹果 时间: 2009-3-12 14:38
标题: 界面测试需要编写测试用例
我认为界面测试需要编写测试用例！
界面测试是必须做的，因为这是直接面向用户的，而且一般用户挑毛病也是很多跟界面有关，因为客户的水平大部分都不是很高，他们界定软件的好坏很大成分是看软件的界面好坏。你要解释项目时间紧或什么理由，他们不会理解。（如果客户水平高的话，他们会理解）而软件的界面就好比人的外表。如果界面做的好，无论是对公司还是对软件都有一个好的影响，这也是公司能力的体现！
那要做好界面，就必须写界面的测试用例。其实软件的每一部分都应写测试用例，只有这样才能最大程度的保证软件的质量。可是这又不现实，只是有轻有重罢了！但是往往由于人们的不重视，或者项目时间的紧张，都只是简单的进行测试或不进行测试，这都对软件的质量，公司的信誉造成了影响！其实这都是国内企业的做法，因为我们还没完全意识到测试的重要性！当然这也与国内软件落后有关！

作者: frieday 时间: 2009-3-12 15:28

原帖由 richieleely 于 2009-3-5 20:55 发表
这里讨论是：界面测试需要不需要编写用例
而不是：界面测试需要不需要

测试是一定需要的
但是用不用编写用例，要看实际的时间和项目要求
如果是一个客户内部管理软件，可能对界面的要求就要比门户网站低
要求 ...

大家跑题了。
这里讨论是：界面测试需要不需要编写用例
而不是：界面测试需要不需要

作者: BigStones 时间: 2009-3-12 15:31
写用例是很必须的！
如果要问测功能的时候是否要写用例，很多人的答案应该是肯定的。其实UI的测试比功能更重要，是用户直接接触的方面。假如你的UI 上有个词语错了，或者显示不完全，可以想象用户对软件的印象会是什么样。
另外用例也是对你测试结果的一个记录，从规范的角度讲，这也是必须的。
还有，写UI 用例的话不会花费太多的时间，只要写好了一块，其余的完全可以复制粘贴，只是界面不一样罢了。

作者: keevinl 时间: 2009-3-12 16:56
肯定是需要的,因为页面肯定也是有需求的,而且还是用户最看重的之一,有些界面,也许你一时可能会记不住,写过用例后,对你以后的测试工作,会有很大的帮助.先讲这些

作者: mr.bee 时间: 2009-3-12 20:25
个人觉得界面测试是不需要用例的，但是界面规范不可缺。
关于界面测试，应该采用界面规范去指导执行。开发人员中很少人对自己所设计的界面表示不满，他们在界面设计的也许会考虑到界面的易用、简洁、美观，但这更多是从他们本身的主观意识出发去思考，界面说到底就是为了易用，一套从用户角度出发的规范在提高用户工作效率上、提高产品品牌价值上有很积极的作用。

作者: kukumaru 时间: 2009-3-13 15:38
需要！对以后工作有帮助．

作者: bonniey 时间: 2009-3-13 16:10
我认为需要写测试用例。
实际上对我们做功能测试的人来说，界面测试也是重要的一部分。
比如message box的字体不统一，拼写错误，语法错误，背景色不协调等等其实非常影响到用户的使用。
而这些是靠人来看的，这是决定性的一点，既然靠人来看，必然有人作为测试工具的缺陷。
做测试为什么要写测试用例，从根本上来讲，是做一个记录，也是做一个list，这样tester才能更全面得添加测试方法。
就像人喜欢做计划一样，计划一个功能是用来计算好时间，另一个也是做一个记录，让你不要忘记你要做的事情。
测试用例也是如此，应该把能想到的地方都加入进去，这样在下一次使用或者是对提交上来的修改做re check的时候能够没有遗漏得测试。
测试是一个精准的东西，不能因为界面是看看的就可以随便测试。
有人说没时间。所谓磨刀不误砍柴工，写一个用例也花不了多长时间，而当你下一次使用或者给你的下一任使用的时候，你会发现用例上有很多你现在没想到的测试点，幸亏你写了用例。
规范是一种习惯，习惯了就是个细致的tester了。呵呵

作者: stepper 时间: 2009-3-13 19:47
标题: 要根据测试流程规范度与界面特点来看
我是新手，说一下我的观点，我认为要从两个两个方面考虑，第一要看公司的规模及对测试的重视程度，也就是测试流程是否规范，软件开发流程是否有固定的模式，有规范的测试流程的公司会严格要求按照软件测试的规范设计测试用例，同时也会预留出足够的设计测试用例的时间和资源投入，反之小公司对这方面的要求可能就低一些，即便是设计了界面测试用例也未必能在后面执行。第二要看界面元素的复杂程度，首先界面测试的重要性不用多说，作为用户最直接的互动模块，一定要保证他的可用性，易用性，友好性，但是对于页面元素复杂，但业务流程简单的项目，就没有费大力气写详细界面测试的必要了，可以写几个大类别的用例覆盖全测试的几个方面就可以了。界面测试可以按照界面元素逐一测试，这样没有用例也不会有太大的风险。来看

作者: crazysusan 时间: 2009-3-13 21:58
标题: 因项目而异,因公司而异,
界面测试:站在测试角度,个人认为是很有必要的.首先,界面的美观,整齐.是给用户最直接的感觉.只有这样,用户才能会继续操作下去,才会考虑其它的..第一感觉.的确是很重要的.

至于用例,则是根据因项目而异,因公司而异,的.在测试计划中有明确指出的则要有对应的测试用例....

作者: gdou_wzy 时间: 2009-3-14 18:07
标题: 个人觉得界面测试是不可缺少的！
首先，界面是客户交互最多的。客户首先检查的部分也是在此；（如果客户不通过，老板不想测试又怎么能行呢？）
其次，软件质量中GUI也是一个不可或缺的部分；
再者，测试用例的编写是让你更全面的去测试，也是需求跟踪的依据。

当然，测试的过程肯定有重点和非重点之分，而界面测试来说也有此之分。
另外，对于界面容易改变的更需要进行这方面的测试。（可作为回归测试一个部分）

测试点：界面元素是否符合规格（大小、颜色、形状等），界面元素的排列是否符合规格，界面元素层次是否正确等等。

基于以上的原因个人觉得界面测试需要编写测试用例。

作者: alec1208 时间: 2009-3-15 11:14
标题: 用例乃测试之母
测试用例不论是做项目还是做产品（本人是做产品测试的），也不论是功能测试还是界面测试，都是一个必不可少的环节。软件测试注重的是结果，但是结果也是有好的测试过程产生的。我从以下几个方面阐述我的观点：
1  以产品测试为例，没有需求文档，甚至有的公司没有设计文档，这样很多的功能乃至引发的界面问题也很多，加之时间紧，产生的软件界面的控件功能不统一、操作不人性化、提示不友好等问题也会随着开发的过程越积越多，虽说每个公司都有自己对界面的要求和标准，但大多数的公司更注重的是功能的实现，从而忽略了界面的影响，测试部门编写界面测试用例，无论从流程上还是从公司的重视程度上，都会起到约束的作用。
2  针对界面测试用例，究其本质，还是引导测试的作用。我想每个测试人员编写测试用例时，总会产生或多或少的测试体会，甚至会引导自己从另一个角度更简单地找到缺陷。界面测试虽然简单，但是在没有测试用例的情况下，你也会有测不到的地方。
3  从严重程度上讲，界面属于次要的等级，从使用的人性化角度确是较高的等级。可能你做的测试比较全面，却也不能完全保证有界面疏漏的地方，更主要的是测试员对有些界面缺陷视而不见，根本不予记录，这样做多少留下了一些隐患，比如说用户反应有些界面不是很好用，虽然影响不大，对公司而言，一没有测试用例，二没有缺陷报告，这样对自己的工作会受影响。
4  从编写技巧上说，界面测试用例虽说必须要写，但也不是按部就班地编写，可以适当地对一些类似的界面写成公用测试，把标准和易用性的方面写在一起，既节省了时间也不会影响测试。

作者: gujichao 时间: 2009-3-15 22:58
标题: 现实往往并不会去特意的做这个界面的测试
以下是我在真实测试中出现的：
在我们执行一些功能测试用例的同时，往往会顺便看一下其界面的显示。。。
因为我们做的是台湾的项目，所以在很多语法上描述的都是不一致的，但是在我们执行功能测试用例的同时，如果发现有一些界面上的问题也是要提交bug的，只不过等级会是比较低的。。而这些bug开发往往有得时候也不会解，会一直搁置到项目的后期。。
但是即使是这样，我们也不能因为没有专门的界面测试用例就不去关注界面的bug。毕竟界面的显示对于用户来说还是最直接的，但是因为界面的bug有的时候真的是因人而异，每个人标准不同，所以定位也不同，这就需要我们测试人员在测试时自己来度量了。

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

作者: 佐伊 时间: 2009-3-16 10:27

需要，选择正方。

作者: zynuage 时间: 2009-3-17 10:50
界面测试当然需要写测试用例了，界面测试虽然是低级的测试，但是，这个关系到一个软件的面子问题。通过界面就可以看出这个软件的质量。如果一个软件连界面都有很多错误，或是错别字，估计用户认为该软件的实际功能质量也好不了哪去。
打个比方，明星们是希望身体重要还是自己的漂亮脸蛋重要呢？其实他们肯定都是认为都重要。但是有很多女明星为了自己没不惜牺牲自己的身体，丰胸、整容，就是把自己弄得更性感些，招来更多人的夸奖和追捧。
所以，软件的界面问题是很严重的。测试用例不可缺少。

作者: 忍忍忍 时间: 2009-3-17 12:13
标题: 终极答案--两边别吵了
理论上讲，如果测试用例做得全面，能够保障软件功能上面没有问题；对于UI界面的测试用例，有经验的测试人员知道，按照测试方法和策略，写完整了，需要耗时NNN久，而实际完整使用这份呕心沥血出来的用例的几率几乎是0。原因是在国内软件开发流程中，测试时间占的比例很小，而且很容易被压缩；测试并没有被国内企业完全接受，想要做好谈何容易。
个人意见UI测试用例是否需要写，要根据具体项目决定，不单是UI测试用例，软件项目生命周期中的任何产出物，都不是绝对需要的，而是根据项目本身决定是否需要裁剪。如果时间充分，可以写得很详细，如果时间不足，可以裁剪（但一定要有相关的UI测试规范等指导相关测试。）

作者: rolei 时间: 2009-3-17 12:51
标题: 反问一下问题：界面开发是否需要写代码？
界面开发是否需要写代码？

如果开发要写代码，测试就要测。

如果要测试就要有用例。

没有用例就能上手测试，怕是又被人说成是随便点点就是测试的工作。

也许一个好的界面测试用例库可以省去不少的时间，提高不少的工作效率。

[ 本帖最后由 rolei 于 2009-3-17 12:53 编辑 ]

作者: 测动未来 时间: 2009-3-18 09:13
标题: 写一个提纲就得了
写一个提纲就得了
界面这东西，你没法完全按照需求来写。写一个大致的提纲，边做边修改吧。呵呵

作者: peterz 时间: 2009-3-18 10:20
每一个页面都要“看”，工作量不大，但是工作面很大。试想这么大的工作量，如果你刚写完测试用例，需求变更了。页面调整了。那将是灾难性的。所以，我还是觉得以软件设计需求说明书为准。如果需要测试，且写测试用例。那就要注明合理的工期。而不是搞成一个不可能完成的任务。

作者: liyayaliutao 时间: 2009-3-18 16:26
界面测试可以不用写测试用例
1.并不是所有的测试都要写测试用例
2.界页测试的标准并不是完全统一，需求方面也不尽相同
3.对于界面测试可以使用界面检查单代替测试用例

[ 本帖最后由 liyayaliutao 于 2009-3-18 16:29 编辑 ]

作者: black_tulip 时间: 2009-3-18 16:54
用例能写死你，谁也不会在测的时候去看。

作者: 搂搂兔 时间: 2009-3-19 09:18
标题: 嗯，工作量太大了，而且很多无用功
嗯，工作量太大了，而且很多无用功

作者: orange_10 时间: 2009-3-19 17:28
首先不同意题目中的“UI测试不针对软件运行”，当然在下所处的行业属于.COM，所以UI测试也是绝对重要的，CSS，JS难道不是软件运行？

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

作者: maclehappy13 时间: 2009-3-19 17:56
我认为不用界面测试不用写测试用例，界面测试用CHECKLIST来检查比较好，按CHECKLIST一项一项检查。因为用例设计时很有可能界面都还没定稿，这样如果写用例的话是写不出具体的测试用例来的。硬要写测试用例的话，有可能会因写不具体测试用例而让测试工作停滞不前或写出来的用例也不是很适用。造成为了写用例而写用例。与其这样，还不如不写具体测试用例，而是用CHECKLIST指出从哪些方面来做界面测试有意义。所以我的观点是界面测试不用写测试用例。

作者: lansnor 时间: 2009-3-19 17:59
界面测试的规范，其实网上有不少，在测试之前，可以根据需求（或项目研发制定的规范）对这些规范进行补充，然后根据这些规范来进行测试即可。

作者: maclehappy13 时间: 2009-3-19 18:00
刚才忘记选了，我是持反方观点。

作者: 51testing_zhj 时间: 2009-3-19 18:21
把问题一分为二，对简单的界面编写测试用例.对复杂界面就没必要了吧，我相信有很多人会描述不清楚的

作者: sunxy5291 时间: 2009-3-20 10:45
标题: 需要的很
需要

作者: coolkisses 时间: 2009-3-22 15:08
这个话题本身就很可笑，不好意思，个人是这么认为的

很多问题本身不是问题，到了最后一环测试这了，才发现不得不去重视，那么，我们为什么不好好分析一下，让大家好好思考一下如何避免这些问题呢？　只是测试内部讨论，下次还会遇到，还会继续郁闷，BOSS还会不时把Leader叫到办公室里说教，这可就不好笑了

回到正题，在项目组内部没有对界面进行定义与规范的前提下，我们能期待它能通过测试吗？　无论是有没有界面测试用例

所以，这一期，我不支持任何一方，算一个中立吧

作者: mumurain 时间: 2009-3-23 09:51
界面测试是否需要编写测试用例，不是测试人员想写就能写的，也要考虑其它因素：
1、项目要求，也可以说是项目重点吧，每一个项目都有一个或多个核心的功能，测试用例的设计也要遵循优先、主次之分
2、项目时间，不敢说全部，起码大部分项目都是项目后期，研发才将开发完毕的系统交付给测试小组进行测试，在有限的时间内，测试重点都是围绕最主要的功能开展测试，编写测试用例，所以对于界面测试，往往都是在测试其它功能时捎带进行了测试
3、项目内容，例如是做门户的，还是做软件的，我个人认为做软件界面要求不如做门户的，所以也要看待项目内容是如何确定的。
等等。
综上所述，界面测试是否需要编写测试用例，不是个人来决定的，能影响的外在因素太多了，有时候不能最求十全十美，但是在时间充裕的情况下，我推荐写测试用例。
所以，我持中立。

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

作者: majun915 时间: 2009-3-25 17:52
标题: 男人的第7感啊。
男人的第7感啊。不用写啊呵呵

作者: daggbby 时间: 2009-3-27 17:02
标题: 需要。
需要。
其实习惯之下道理和其他测试需要用力是一个道理。

作者: himily 时间: 2009-3-27 19:30
标题: 严谨的情况下需要写，时间紧的情况下可以不写
UI测试写不写测试用例，我认为要看具体的项目情况而定
1.完整的流程决定质量，我坚信。但是这个是在时间和人员充足的情况下，在功能测试用例设计完成的情况下，从满足客户质量的情况下，测试人员非常有必要编写UI测试用例，特别是针对Web的测试，对于不同浏览器页面的显示、JS对页面元素的影响、颜色的搭配、用户易用性等人性化操作程度……
2.小系统需要对流程进行裁剪，我坚持。一方面小系统页面元素不是很多，在有一定经验的测试人员可以不用写UI的测试用例，这样更节约成本；另外一方面就是在工作量大、而人员不充足且时间紧凑的情况下，可以不些UI测试用例，而直接进行UI测试即可
所以写不写UI测试用例要看具体的情况而定

作者: xxjgogogo 时间: 2009-3-30 17:07
标题: 世事无绝对,按项目具体情况来吧
不同公司不同项目情况都不一样,是否写测试用例,要按照项目时间,进度,需求完整情况等具体分析.
如果界面测试的范围比较大,并且整体风格按照客户的不同可能有较大较频繁的变化的话,可以不写测试用例.
不过这种情况下,需求文档的质量,测试计划和测试方案就会更加重要.
绝大多数情况还是需要写用例的.不过我也不建议把每个界面点都写成一个用例,纯粹为了用例看着数量多?
测试用例只要把标准的东西写清楚就可以了,比如字体多大,颜色如何,各界面元素的标准,这些都是要有公司统一规定或客户详细需求为前提的.并且要求开发人员按标准研发,有好的编程习惯.
UI用例某些情况写太多了耽误时间,白白浪费人力还没有效果.如果Boss给你一个测试任务,但根本没有写界面测试用例的时间,难道因为没写用例你就不测试了?直接辞职?

测试的主要目的是找到产品缺陷,提高产品质量等等等等,但绝对没有写测试用例这个目的!!!

[ 本帖最后由 xxjgogogo 于 2009-3-30 17:20 编辑 ]

作者: SMALLCAI 时间: 2009-4-1 12:05
我也觉得界面测试应该编写测试用例，这样我们可以在测试的过程中，了解到那些是必须重点注意的。当然凭我们的经验，可能可以立即知道哪些地方处了问题，但是我们不可能时时刻刻保持最好的“警惕”状态，所以，没有一份好的测试用例，在测试过程中难免会有遗漏，即使测试人员经验再足也是难以避免的。

作者: 87950461 时间: 2009-4-2 13:57
需要测试用例,但凡涉及到界面的东西都不会是简单的东西,即使客户以及你自己都很少用到这个界面,但是一旦用到,如果有出现一些问题,比如不明了的提示信息\非常模糊的错误提示\有歧义的提示信息,等等.首先给客户的第一影像就是,你的软件有BUG,那接下来你就要去对客户解释,解决等等一大堆问题.这后面产生的成本是无法估量.这就不多说了.如果经常出现这样的问题会造成什么样的结果,相信在坐的个位都清楚.

作者: ylq2250 时间: 2009-4-3 23:23
根据我所做项目的经验总结，我觉的还是有必要写测试用例。因为在执行测试的过程中一般的工作量都是比较大的，如果不写用例，就只能在执行的过程中想到什么测什么，由于工作量大，时间紧，一般不会考虑得很周全，这样漏测的点会比较多。还要一点是一般公司都会安排3-4轮的测试，没有写测试用例，每一轮都是在执行的时候想到什么测什么，那么一般经过3-4轮测试，你每次想到要测试的点都会是一样，那漏测点就会一直都没有时间去挖掘出来。所以我觉的还是有必要写好用例，那么执行测试的时候就可以按照测试用例去执行，这样比起没有写用例，反而可以省下很多执行测试的时间，而且漏测的机率也会降低。

作者: Yuyao_ddm 时间: 2009-4-4 14:14
标题: 当然需要！
用例有粒度粗细之分，可以写些粒度适中的可重用的用例，针对具体项目补充一些用例即可。

为何要写用例？让测试人员知道具体要测试什么，让测试管理者知道界面到底有没有问题，用例是后续工作的依据。
为何要控制粒度？因为要追求质量成本线的最优点（期间的道理不说了）。
为何提到可重用的用例？因为对专业公司来说，web界面都有一套成文的标准（相应的应该也有界面用例），遵循这个标准的产品界面基本类似，有些细微的不同，补充一些用例（或其他形式的说明）即可。

这里要强调界面测试是必须的，尤其是WEB界面，好比是手机的外壳，如果你手机的外壳有些问题，你会相信这个手机的质量是一流的么？

作者: hongyan 时间: 2009-4-7 11:35
界面测试当然需要编写测试用例,但是,就国内的大多数软件公司来看是很难实现的.

作者: kf11859 时间: 2009-4-24 10:33
界面测试按理论上说应该是用例最多的。。。
顺便问下，这是谁出的题目，丫做过测试吗？

作者: ma_xiaobo2008 时间: 2010-5-21 13:23
也没有讲出界面测试是否应该写测试用例呀？！

作者: suiyuanfei83 时间: 2010-11-22 22:34
写的不错，支持！

淘宝网登陆
淘宝网首页
http://www.taobaomtv.com

作者: Michael0112 时间: 2011-3-13 10:55
需要编写

作者: 春天梅花 时间: 2011-5-5 13:42
需要

作者: 春天梅花 时间: 2011-5-5 13:43
{:4_84:}

作者: yxx8012 时间: 2011-6-26 17:31
界面是功能还是纯功能,如果涉及功能必须要有用例.
如果仅是界面,用例可以简化,例如形成一些通过或适合这个UI设计的一些checklist用例对测试的检查.

作者: rachel1991814 时间: 2012-4-11 14:16
界面相当于一个人的穿着打扮，一个好的装扮总会给人美的感受，所以UI测试是必不可少的，而界面测试用例是给出的一个标准，可以在有限的时间内给出一个满意的结果

作者: iyxnm 时间: 2012-11-10 12:49
难得好贴，赞一个，继续努力啊

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)