终极答案--两边别吵了
理论上讲，如果测试用例做得全面，能够保障软件功能上面没有问题；对于UI界面的测试用例，有经验的测试人员知道，按照测试方法和策略，写完整了，需要耗时NNN久，而实际完整使用这份呕心沥血出来的用例的几率几乎是0。原因是在国内软件开发流程中，测试时间占的比例很小，而且很容易被压缩；测试并没有被国内企业完全接受，想要做好谈何容易。个人意见UI测试用例是否需要写，要根据具体项目决定，不单是UI测试用例，软件项目生命周期中的任何产出物，都不是绝对需要的，而是根据项目本身决定是否需要裁剪。如果时间充分，可以写得很详细，如果时间不足，可以裁剪（但一定要有相关的UI测试规范等指导相关测试。）
反问一下问题：界面开发是否需要写代码？
界面开发是否需要写代码？如果开发要写代码，测试就要测。
如果要测试就要有用例。
没有用例就能上手测试，怕是又被人说成是随便点点就是测试的工作。
也许一个好的界面测试用例库可以省去不少的时间，提高不少的工作效率。
[ 本帖最后由 rolei 于 2009-3-17 12:53 编辑 ]
写一个提纲就得了
写一个提纲就得了界面这东西，你没法完全按照需求来写。写一个大致的提纲，边做边修改吧。呵呵 每一个页面都要“看”，工作量不大，但是工作面很大。试想这么大的工作量，如果你刚写完测试用例，需求变更了。页面调整了。那将是灾难性的。所以，我还是觉得以软件设计需求说明书为准。如果需要测试，且写测试用例。那就要注明合理的工期。而不是搞成一个不可能完成的任务。 界面测试可以不用写测试用例
1.并不是所有的测试都要写测试用例
2.界页测试的标准并不是完全统一，需求方面也不尽相同
3.对于界面测试可以使用界面检查单代替测试用例
[ 本帖最后由 liyayaliutao 于 2009-3-18 16:29 编辑 ] 用例能写死你，谁也不会在测的时候去看。:lol
嗯，工作量太大了，而且很多无用功
嗯，工作量太大了，而且很多无用功 首先不同意题目中的“UI测试不针对软件运行”，当然在下所处的行业属于.COM，所以UI测试也是绝对重要的，CSS，JS难道不是软件运行？其次UI的测试用例问题完全是根据公司、项目性质而定的，好比说做产品的，UI有固有范式，用例的重用性能够得到体现；但是像互联网，UI的变化太快，细节繁多，那用例的成本就过于昂贵。如果你处在测试管理的职位，凡事都需要以结果为导向，用例绝不是为做而做，而是做了有什么用，有多大用的问题。如果不需精量成本，或者对测试人员起一个理思路的作用，我觉得写也未必不可，在下甚至还在试用期要求新人们写过“网站功能描述”这种毫无意义的东东，作用是在帮助其更快理解内容，发现问题。所以写不写用例完全关乎于其结果导向的 我认为不用界面测试不用写测试用例，界面测试用CHECKLIST来检查比较好，按CHECKLIST一项一项检查。因为用例设计时很有可能界面都还没定稿，这样如果写用例的话是写不出具体的测试用例来的。硬要写测试用例的话，有可能会因写不具体测试用例而让测试工作停滞不前或写出来的用例也不是很适用。造成为了写用例而写用例。与其这样，还不如不写具体测试用例，而是用CHECKLIST指出从哪些方面来做界面测试有意义。所以我的观点是界面测试不用写测试用例。 界面测试的规范，其实网上有不少，在测试之前，可以根据需求（或项目研发制定的规范）对这些规范进行补充，然后根据这些规范来进行测试即可。 刚才忘记选了，我是持反方观点。:lol 把问题一分为二，对简单的界面编写测试用例.对复杂界面就没必要了吧，我相信有很多人会描述不清楚的
需要的很
需要 这个话题本身就很可笑，不好意思，个人是这么认为的很多问题本身不是问题，到了最后一环测试这了，才发现不得不去重视，那么，我们为什么不好好分析一下，让大家好好思考一下如何避免这些问题呢？ 只是测试内部讨论，下次还会遇到，还会继续郁闷，BOSS还会不时把Leader叫到办公室里说教，这可就不好笑了
回到正题，在项目组内部没有对界面进行定义与规范的前提下，我们能期待它能通过测试吗？ 无论是有没有界面测试用例
所以，这一期，我不支持任何一方，算一个中立吧 界面测试是否需要编写测试用例，不是测试人员想写就能写的，也要考虑其它因素：
1、项目要求，也可以说是项目重点吧，每一个项目都有一个或多个核心的功能，测试用例的设计也要遵循优先、主次之分
2、项目时间，不敢说全部，起码大部分项目都是项目后期，研发才将开发完毕的系统交付给测试小组进行测试，在有限的时间内，测试重点都是围绕最主要的功能开展测试，编写测试用例，所以对于界面测试，往往都是在测试其它功能时捎带进行了测试
3、项目内容，例如是做门户的，还是做软件的，我个人认为做软件界面要求不如做门户的，所以也要看待项目内容是如何确定的。
等等。
综上所述，界面测试是否需要编写测试用例，不是个人来决定的，能影响的外在因素太多了，有时候不能最求十全十美，但是在时间充裕的情况下，我推荐写测试用例。
所以，我持中立。
用checklist方式来测试界面
首先，任何事情不能一概而论，我选反方，是因为这个情况是针对中小公司。因为：一，我想很多公司，其实根本就没有界面设计的概念，很多的软件一看界面上基本上都是一样的。所以说本身就没有办法设计出很好的界面。二，界面上的东西基本上就是一些文字错误，排版等，这个可以不用设计用例。而至于易用性，这个就更不好说了。本身测试人员设计出来的用例就很难保证用例的质量。因此，我们测试小组会依据开发经常出现的界面问题，做个总结，并把一些常用的界面测试规范加入到这些条款中。让开发人员在开发这前就参照这份准“界面规范”去设计，到时测试人员也是依据这份“规范”再去提一些不符合“规范”的问题。
当然，如果公司规模很大，测试技术很强大，追求完美，设计肯定比不设计好。我们这是退而求其次。不可能让一个饭都吃不饱的人谈论参加PARTY要穿多高档多漂亮的衣服，一样的道理。
男人的第7感啊。
男人的第7感啊。不用写啊 呵呵需要。
需要。其实习惯之下道理和其他测试需要用力是一个道理。:call:
严谨的情况下需要写，时间紧的情况下可以不写
UI测试写不写测试用例，我认为要看具体的项目情况而定1.完整的流程决定质量，我坚信。但是这个是在时间和人员充足的情况下，在功能测试用例设计完成的情况下，从满足客户质量的情况下，测试人员非常有必要编写UI测试用例，特别是针对Web的测试，对于不同浏览器页面的显示、JS对页面元素的影响、颜色的搭配、用户易用性等人性化操作程度……
2.小系统需要对流程进行裁剪，我坚持。一方面小系统页面元素不是很多，在有一定经验的测试人员可以不用写UI的测试用例，这样更节约成本；另外一方面就是在工作量大、而人员不充足且时间紧凑的情况下，可以不些UI测试用例，而直接进行UI测试即可
所以写不写UI测试用例要看具体的情况而定
世事无绝对,按项目具体情况来吧
不同公司不同项目情况都不一样,是否写测试用例,要按照项目时间,进度,需求完整情况等具体分析.如果界面测试的范围比较大,并且整体风格按照客户的不同可能有较大较频繁的变化的话,可以不写测试用例.
不过这种情况下,需求文档的质量,测试计划和测试方案就会更加重要.
绝大多数情况还是需要写用例的.不过我也不建议把每个界面点都写成一个用例,纯粹为了用例看着数量多?
测试用例只要把标准的东西写清楚就可以了,比如字体多大,颜色如何,各界面元素的标准,这些都是要有公司统一规定或客户详细需求为前提的.并且要求开发人员按标准研发,有好的编程习惯.
UI用例某些情况写太多了耽误时间,白白浪费人力还没有效果.如果Boss给你一个测试任务,但根本没有写界面测试用例的时间,难道因为没写用例你就不测试了?直接辞职?
测试的主要目的是找到产品缺陷,提高产品质量等等等等,但绝对没有写测试用例这个目的!!!
[ 本帖最后由 xxjgogogo 于 2009-3-30 17:20 编辑 ]
