rien2128 2007-11-19 23:00
都差不多..
jackleipm 2007-12-10 11:03
国内的测试水平关注程度不够高是现实，大家要坚持。:victory: :victory:
sangrou 2007-12-10 18:14
[quote]原帖由 [i]小小丫[/i] 于 2007-5-16 10:43 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=523870&ptid=75739][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
我觉得还是应该让公司高层先重视起测试这块，这样测试的一些工作才能顺利的开展sdlkfj3 [/quote]
你应该先做出点成绩来,给大家看.还有不断的加长buglist,这样开发还是有压力的...老大看到你的成绩才能支持你呀.
sangrou 2007-12-10 18:20
定期汇总buglist,因为项目有移植代码,很多的项目有共同的bug,修复的过程浪费了很大的人力资源,抄份给老大,他会去思考的.老大比你更清楚软件质量的重要性
楼主最好的办法是先实行后建议...
[[i] 本帖最后由 sangrou 于 2007-12-10 18:23 编辑 [/i]]
Wheatlee 2007-12-11 09:04
"测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。"
还有你说的bug库
楼主，你说的这两个我早在1年前就尝试过的。一般bug库是大家都有的。测试用例库当初是我自己开发（asp.net + sqlserver 2005）。
但是，效果呢？我觉得只能用一句话说明“看起来很美”。 尤其是测试用例库。需求变化了，会导致很多测试用例根本就是无效的。如果你建立一个公用的测试用例库，你会发现你需要修改清理很多公用的测试用例，这样时间会占用很多。你的初衷是将很多基本，复用性高的测试用例存起来供大家使用。但是测试用例本身就在变化，所以你这样的“封装”是无用的。
至于bug库，我倒觉得你可以这么做。找出bug是如何被发现的。是测试人员在测试中随意测出来的，还是用户日积月累后发现，是根据测试用例发现的，还是别的什么因素发现的。然后你要统计，将测试人员的随意变成你们的测试方法论。而且，通过统计，你能发现你们的测试用例是否真的有效。如果无效，你需要跟整个测试组去找出无效的原因。
呵呵，楼主，这只是个人观点。如有冒犯或者说的不对的地方，望指出：）
msnshow 2007-12-22 16:25
同意楼上的说法，BUG库的确很重要，就拿我们公司来说，没有好好利用BUG库，每次送测的新的应用都存在着以前提过的类似的BUG
（因为我们的应用很多，又是不同的开发人员负责，在上一个应用中遇到的问题，在下一个应用中还会有）如果好好的整理BUG，让每个开发人员都知道，他们在开发的时候就会注意，就减少出现类似BUG的机率，从而减少测试的工作量!
testman 2007-12-28 18:47
想法挺好，执行很难，
r_sunny 2008-1-3 17:16
境况类似....唉,执行起来太不易了
11ling 2008-2-2 12:02
学习了:)
free_xiaoyu 2008-2-22 17:03
我觉得大家天天都在说重视测试，但是对于测试，大多数人还是处于初级认识阶段，关键是看公司领导对测试是否有更新的认识，当认识多了，也就重视起来，测试也就有了最大的保证，不过就国内现状，还得等待。
takiro 2008-2-25 12:18
想法都不错，应用性不高。
bug库的整理还是有必要的，将重复出现的bug找出来并归结原因，在测试组内建立自己的检查表是有一定的指导意义的。也可以将该表转化为项目组其他成员可用的形式发出。
至于说测试案例的评审希望项目组全体参加，这个基本上不可能，如果是业务逻辑复杂的应用，拉整个项目组的时间来做评审，项目组成员答应老板也不会答应。控外不如控内，关键是让手下的测试人员多熟悉系统架构和应用需求。
测试用例的复用，个人建议是针对核心模块（保证正常流程的一定要写）来做测试用例的编写，外部的功能或表现实现结合用检查表的形式进行检查，一；充分保证80%的缺陷在20%的代码中发现，二；提高测试效率，减少无谓的用例维护和测试时间。
vicky_yan 2008-4-3 11:21
收藏,学习
leo_hu_100 2008-4-11 16:28
测试用例如果没时间全部评审的话，可以列出一些测试点来评审，把测试用例的位置放到只是对于测试点内容的细化上，这样我想对于BA，Dev应该可以节省更多的时间。
naonao 2008-4-19 14:24
回复 6# 的帖子
不错,支持!
数码宝贝 2008-4-19 15:36
[quote]原帖由 [i]刘洪鹏[/i] 于 2007-7-12 17:15 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=606721&ptid=75739][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
测试方案和测试计划你认为那个重要啊 ? [/quote]
aaaa
hxf 2008-4-21 15:59
现在，测试没这么正规。项目需求评审的很少。并且，在时间不充裕的情况下，不写测试用例。就直接凭借测试人员积累的经验，直接执行测试。
linuxsky2008 2008-4-25 16:30
偶感
其实很多东西都要从实际出发，楼主说的建议确实不错，但也要分公司，还有什么重要什么不重要，没有开始哪来结束，所以测试计划和测试方案都很重要，只是阶段不同
yaozhongji 2008-5-27 15:34
学习一下
对楼主的想法很认同，正在想同样的问题。
测试用例有两种：
一种是操作结果可保存的，这种测试尽量用自动化测试。
一种是操作结果不可保存的，是一种过程测试，需要手动测试。
自动化测试的执行能够很大程度的提高工作效率，保证测试质量。避免回归测试的疏忽。
测试没有不变的规则，不同行业，不同软件的测试是灵活的。
IreneMaria 2008-6-6 13:28
ClearQuest，测试人员每提交一个BUG，都会给项目组的每个成员发mail的
sheepliyong 2008-6-26 00:58
有个完善的计划个人觉得是必须的!~
echo5410 2008-7-7 09:44
学习一下
xmluo 2008-7-11 16:44
学习了
syn106 2008-7-15 16:20
回复 30# 的帖子
同感
elainehoo 2008-7-16 16:20
"测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。"
还有你说的bug库
楼主，你说的这两个我早在1年前就尝试过的。一般bug库是大家都有的。测试用例库当初是我自己开发（asp.net + sqlserver 2005）。
但是，效果呢？我觉得只能用一句话说明“看起来很美”。 尤其是测试用例库。需求变化了，会导致很多测试用例根本就是无效的。如果你建立一个公用的测试用例库，你会发现你需要修改清理很多公用的测试用例，这样时间会占用很多。你的初衷是将很多基本，复用性高的测试用例存起来供大家使用。但是测试用例本身就在变化，所以你这样的“封装”是无用的。
我也做过同样的事情，维护起来简直是。。。
正在研究QC，希望可以解决这类问题。
[[i] 本帖最后由 elainehoo 于 2008-7-16 16:24 编辑 [/i]]
从小到大 2008-7-30 16:02
而测试用例在测试任务较紧张的时候可以暂不编写，由测试人员根据经验自行判断在测试活动中应该运用何种数据。
lz的这点建议我不认同，这种场合只适合于 有经验的测试团队，当你的下属中有几个新人或者工作经验不多的 ，这种测试出现错误的几率是很大的，个人建议
lavender2004 2008-7-30 21:58
楼主公司的情况跟我公司非常类似，我看了楼主分享的这些想法也很认同。好在我们项目组现在也逐渐重视起测试了。。支持一下！！
joytea 2008-7-31 11:41
几点感想：
1.不论管他叫测试方案也好叫测试用例也好，不管写的详细也好，简单也罢，总之在测试之前测试思路是必须要整理清楚的，否则测试就变得漫无目的了。测试用例或者测试方案是测试的指导和核心，抓不住它测试的质量就无从谈起。
2.从我们测试组的实际情况来看，根据测试任务的时间要求，我们的确会考虑不同的方式。
～首先，每个功能的测试都必须要有明确的责任人，可以有多个人参与，但是责任人只能有一个，他要负责事先了解清楚相关需求，编写测试方案和用例，并在测试评审过程中回答评审参与者的问题。
～测试用例的评审是必需的，不论采取会议的形式还是走查的形式，一个人的思路难免偏颇，事实证明再有经验的测试人员一个人的思路也必然会有遗漏。
～在时间比较宽裕的情况下我们会先编写测试用例，测试组内评审，必要时要求开发人员参与评审，从业务和测试双重角度把关测试用例，而后实施测试，并根据测试情况补充用例。
～时间比较紧张时，我们会安排先写出测试思路，进行一轮测试，而后时间稍微宽裕，在根据测试情况补充测试用例和测试数据，并进行评审，而后测试人员根据评审意见补充用例，并进一步补充测试。
～测试用例未必写的很详细，只要说明了测试的目标和预期结果，步骤和数据均可根据实际情况权衡。但是那些数据和逻辑很复杂的测试，用例中则必须包含测试数据。
xiaozhai 2008-8-10 14:00
踩过
ruanyongjie 2008-8-22 08:26
不错，值得学习！
许诺10928 2008-8-22 14:53
我们公司是做地产的，网络部也是刚刚成立几个月，而我们测试部更是时间短也就两个月，刚开始到公司的时候是我们经理写用例，我们执行。到后来项目紧的时候根本就没有测试用例了，我们每天都是直接上手就测，测出来问题就提交bug。更为郁闷的是我们根本就没有需求，发现问题后先报给经理，经理确认是bug就提交。再或者经理也不知道的时候就只能问开发了。感觉我们测试部也很没有地位，被开发牵着鼻子走，郁闷！:Q
blinkday 2008-9-4 15:11
LZ说得很有道理，但不管是测试方案也好还是测试用例也好，其实是关于测试用例颗粒度的问题，先抓主干、业务流的全面覆盖再慢慢细化各个功能点。
对于很多应用系统来说，更重要的业务流程的覆盖，对于业务流简单的功能来说更容易组织起所谓标准的输入/输出模式的测试用例。