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

ifoxmulder

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

CHOUYUNHAT

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

komado

界面测试，文档测试有一些通用的的规则，各只编写一份，所有被测软件都适用，不用每个软件都些！

asprit

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

zhengxiangjun86

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

沉默风云

1.编写测试用例的利与弊：
       利处：便于版本控制，便于用例管理、可以提高测试的效率和有效性。
       弊端：要花费一定的时间、人力、财力；延长测试时间、延长项目进度；

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

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

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

mytoyliu

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

月野幻儿

大家说的都很精彩啊！
界面测试也很重要的，需要编写

richieleely

这里讨论是：界面测试需要不需要编写用例
而不是：界面测试需要不需要

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

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

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

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

chengxq

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

fflastjay

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

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

fflastjay

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

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

puchonghui

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

yxf

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

peterz

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

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

tangking1

界面测试除了查看界面一致性还是友好性外，还有就是功能的连接问题，界面的连接按钮直接是调用内部代码的，如果只是走查试的看看漂不漂亮的话，相当于不要做测试勒！黑盒测试的重要性是不言而喻的！

风中一片雪

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

joannaready

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

peterz

如果从测试人员的角度考虑，我建议写测试用例。如果从测试经理或者PM的角度考虑，记得从整体项目的角度考虑。一般不会建议写测试用例。或许是站的角度不一样吧。

Kity_88

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