测试用例每个公司都有用心分析和评审吗？
不知道为什么进的两家公司项目都接近尾声，要么就是维护阶段。用例都不是很全。测试时基本上都是自由发挥的感觉。很纳闷在项目早期为什么不建一些相对完善的用例库呢？难道实现起来有很多难点？现在都用迭代开发模型，频繁的需求变更是不是给设计用例带来一定的难点。而且不易管理用例？规范的流程或你们公司都是具体怎样实施的？？ 大家讨论下！ :( 我们公司的项目压根没有测试用例，连功能列表都没有呢 原帖由 青青 于 2008-5-27 17:53 发表 http://bbs.51testing.com/images/common/back.gif
不知道为什么进的两家公司项目都接近尾声，要么就是维护阶段。用例都不是很全。测试时基本上都是自由发挥的感觉。很纳闷在项目早期为什么不建一些相对完善的用例库呢？难道实现起来有很多难点？现在都用迭代开发模型 ...
我觉得这和公司领导是否重视测试流程，项目资源等相关的。
花精力去写用例，如果以后项目是相似的就可以有重用的价值，但如果接的是外包的那些项目，或者做的项目没有相似性，比如说，这次做网站项目，下一个做电子产品项目，这样花精力去做用例，没什么好处（至少短期的好处看不到），管理层当然不会去重视这些了。 至于，频繁的需求变更，可以引入需求变更管理来解决，但如果想从根本上解决问题，应该从测试流程的规范化来入手。
首先你要先清楚的了解自己公司测试流程的现状是什么，然后借鉴一下V MODEL的一些东西来一点一点的做起来
我记得好像郑仁杰的那本书里写了些这些东西，可以看一下。 原帖由 AlexanderIII 于 2008-5-27 23:24 发表 http://bbs.51testing.com/images/common/back.gif
我觉得这和公司领导是否重视测试流程，项目资源等相关的。
花精力去写用例，如果以后项目是相似的就可以有重用的价值，但如果接的是外包的那些项目，或者做的项目没有相似性，比如说，这次做网站项目，下一个做 ...
如你所说，如果项目没有相似性，花精力去做的用例则没有重用的价值，是否为了方便不去写用例？但没有用例作为指导怎么判断测试的覆盖面？ 如果产品没有相似性，用例真的一点价值都没有吗？ 用例,真正实现起来是苦难的，特别是要按照别人的用例来执行自己的测试的时候,
头疼的去看别人写的思路。..而且还不定对。..
长篇的根据人家的鼻子,牵着走很不爽.的。.过于规范的流程也不定能解决问题。 “很纳闷在项目早期为什么不建一些相对完善的用例库呢？难道实现起来有很多难点？现在都用迭代开发模型，频繁的需求变更是不是给设计用例带来一定的难点。而且不易管理用例？”
第一个问题，我给予的回答就是，这些工作需要你去完成，以你的见解去给公司提出一些可行的方案，这些方案要符合公司的实际情况，描述这样做的优势在哪儿，不这样做的劣势在哪儿，这也是公司招你进去的原因。
第二个问题，这个问题也是问你自己，你觉得有什么难点？难点在哪儿？你要如何去解决这些难点。
第三个问题，需求平凡变更 1）你们的PM与客户沟通不够良好，而且在需求变更后要与客户及时沟通，表明这样的变更会有什么样的影响，进度会有多大的延迟。 2）需求分析的时候你们没有和PM沟通好，没有在最初发现那些隐秘的问题。 3）如果需求突然有很大的变动如何去完善 请参考这个贴（http://bbs.51testing.com/viewthread.php?tid=114483&highlight=%D0%E8%C7%F3%B1%E4%B8%FC）
规范的流程或你们公司都是具体怎样实施的？？
这个你要先了解公司现有的流程，并能找出哪几方面是不足的需要加入哪些流程、活动，参考V流程逐步改善
至于如何在有限的时间里做到高品质还需要每个测试人员自己摸索啊。
望高人继续指点。 我经历过的几个公司的情况也是如此------测试用例并不真正在测试时完全执行，甚至有些无效用例。
我觉得测试人员在写测试用例时就是一个熟悉需求，并将自己的理解写到用例中去的过程，在用例评审通过后，也就是说测试人员可以按这样的需求理解去检验产品。在测试时，往往会因为进度的关系，测试人员以在头脑中形成的业务流程来检查，可能会比写的测试用例范围小些。这时最好提倡使用一些测试管理工具，记录测试用例和执行后的实际成果，这样测试用例执行的覆盖率能提高很多。 我目前的公司的测试用例从来没有人进行评审的,走流程走到测试经理那也没有认真的审核,只是看看测试报告情况如何就通过的,觉得自己花精力写这些东西别人都不重示的,觉得可浪费呢,只是大部份人都重结果的原因吧,不过对于测试人员来说,测试过程特别重要的,不过领导是不会看测试用例的,只要测试结果通过能按时上线就没问题的,:lol
每次都是这样的流程的,觉得没有什么发展方向及目标的,现在公司又要修改流程了,真不知到什么程度.......:) 大家都彼此彼此,.现在真的明白什么是现实了:( 我采取的方法是测试需求\测试计划\测试用例都通过评审会来评审,实践证明效果还不赖 是没有具体实施阿，太痛苦了，都是按照自己想的测试。。。。 评审时领导们都懒得参与 其实现在统计的测试覆盖度都是测试用例和代码行数的比值，这个值其实有效性不是和很好，因为这里面有没有没有包含的测试用例，有没有无效的测试用例，当然评审是一方面，虽然现在每个公司肯定无论是潜意识还是真正的规定了，对这些工作产品的评审，但是真正去做的不多，很多基于形式，就像楼上所说，领导都不参与，这其实就是问题，领导都不支持，如何去做，这些都是中国的特色，只要进度不要质量，只要返工不要评审导致的。评审的人员其实是个很重的因素，主要是输入是否正确，过程是否正确，规定的参与人员都参与了。就说我们公司，在需求和设计阶段，要求是高层，项目经理，非该项目的项目经理，技术人员等参与，但是结果是只有该项目经理参与，别的都说忙，所以QA的路不好走，还有很长的路需要走。 我觉得主要是测试用例的复用度来决定公司对测试用例的重视程度。特别是集成测试阶段的测试用例管理。 1、审核需求和设计—〉设计测试—〉实施运行测试
审核需求包括：
（1）由PM根据用户要求（信息来源于市场部门，用户支持部门、游戏设计部门、美术部门、程序部门等等）而编写的需求文本（Requirement Specification）；
（2）由Team Leader根据需求文本和开发团队(游戏设计、美术、程序)而编写的功能设计文本（Functional DesignSpecification）；
（3）由Test CaseOwner根据功能文本而编写的实施设计文本（Implementation DesignSpecification）
(4)由Test CaseOwner完成测试用例设计,一般设计两套用例;一套只检查基本功能,另一套检查内容详细,从端到端,点到点都不放过,极其苛刻,尽可能做到最大覆盖。
对这些文件的管理与调配,TL完成功能设计文本,通过邮件发送给PM,并抄送手下组员,目的让大家了解这个Mliestone测试重点和相关测试功能模块;PM对功能设计文本进行审核,并与设计团队和开发团队一起会审,评审所写的所有Case。发现问题或者有不清楚的地方,进行Review动作。一般一个用例从设计到最后被确定使用,会经过2~4次Review。
测试人员也要参与所有这些文本的审核,主要是与开发沟通,和成员内部进行交叉评审。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动。
2、当确定下测试用例后,定义优先级,用例的分配(分配到测试小组),由每个组的TL放入专门服务器,PM设置访问权限和修改权限,由PM统一管理,测试开始时会依据测试进度分发Case。
Mliestone开始之前,会召集所有测试人员进行战前部署,告诉大家这次测试的功能模块,自动化的测试、性能都会涉及。让每一个测试人员清晰了解测试的功能模块有哪些,需要注意什么,等等。
3、实施运行测试是最长最复杂的一个阶段。就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试脚本、反复运行自动化测试脚本，也包括阶段性执行手动测试用例。在Mliestone中,自动化测试和性能测试与手动测试同时进行,自动化测试这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，就是为了防止质量回归。
另外,非自动化的测试用例要进行维护,非常烦琐的工作,比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时，所涉及的测试用例当然也要相应地修改。
我们是游戏公司的测试,希望各位讨论下这种方法的利弊。 问你几个问题.
是否可以真正解决需求不变更的问题？如果你是产品人员在设计一个复杂产品的话，是否所有的东西可以在前期全部定下来且不受质疑？
测试的时间成本是否有考虑过？采用各类模型是否可以给有效的帮助公司节约成本，更快更好的推出产品？
用例库如何组织？复用度有多高？
建议你真正的跳出来思考这些问题
项目早期的用例应当是准备健全的，我们会分为测试分析，测试用例设计，测试用例撰写三个阶段来完成用例分析，用例质量直接决定的产品的质量。
产品的需求变化是不可预测的，但是用例的需求跟踪和维护也是必须得，在我们公司这些都是有要求的。
页:
[1]
