51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: rice_mouse
打印 上一主题 下一主题

[原创] 给经理关于测试方案及测试用例的建议

[复制链接]

该用户从未签到

41#
发表于 2007-12-10 11:03:22 | 只看该作者
国内的测试水平关注程度不够高是现实,大家要坚持。
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2007-12-10 18:14:28 | 只看该作者
原帖由 小小丫 于 2007-5-16 10:43 发表
我觉得还是应该让公司高层先重视起测试这块,这样测试的一些工作才能顺利的开展sdlkfj3


你应该先做出点成绩来,给大家看.还有不断的加长buglist,这样开发还是有压力的...老大看到你的成绩才能支持你呀.
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2007-12-10 18:20:05 | 只看该作者
定期汇总buglist,因为项目有移植代码,很多的项目有共同的bug,修复的过程浪费了很大的人力资源,抄份给老大,他会去思考的.老大比你更清楚软件质量的重要性
楼主最好的办法是先实行后建议...

[ 本帖最后由 sangrou 于 2007-12-10 18:23 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

44#
发表于 2007-12-11 09:04:51 | 只看该作者
"测试组成员可依照统一标准共同编制一个测试用例库,将公用的、常用的数据建立数据库,可重复调用,逐渐积累,将会很大程度上减轻测试用例的编写工作。"
还有你说的bug库

楼主,你说的这两个我早在1年前就尝试过的。一般bug库是大家都有的。测试用例库当初是我自己开发(asp.net + sqlserver 2005)。

但是,效果呢?我觉得只能用一句话说明“看起来很美”。 尤其是测试用例库。需求变化了,会导致很多测试用例根本就是无效的。如果你建立一个公用的测试用例库,你会发现你需要修改清理很多公用的测试用例,这样时间会占用很多。你的初衷是将很多基本,复用性高的测试用例存起来供大家使用。但是测试用例本身就在变化,所以你这样的“封装”是无用的。
至于bug库,我倒觉得你可以这么做。找出bug是如何被发现的。是测试人员在测试中随意测出来的,还是用户日积月累后发现,是根据测试用例发现的,还是别的什么因素发现的。然后你要统计,将测试人员的随意变成你们的测试方法论。而且,通过统计,你能发现你们的测试用例是否真的有效。如果无效,你需要跟整个测试组去找出无效的原因。

呵呵,楼主,这只是个人观点。如有冒犯或者说的不对的地方,望指出:)
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    45#
    发表于 2007-12-22 16:25:06 | 只看该作者
    同意楼上的说法,BUG库的确很重要,就拿我们公司来说,没有好好利用BUG库,每次送测的新的应用都存在着以前提过的类似的BUG

    (因为我们的应用很多,又是不同的开发人员负责,在上一个应用中遇到的问题,在下一个应用中还会有)如果好好的整理BUG,让每个开发人员都知道,他们在开发的时候就会注意,就减少出现类似BUG的机率,从而减少测试的工作量!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    46#
    发表于 2007-12-28 18:47:54 | 只看该作者
    想法挺好,执行很难,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    47#
    发表于 2008-1-3 17:16:40 | 只看该作者
    境况类似....唉,执行起来太不易了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    48#
    发表于 2008-2-2 12:02:19 | 只看该作者
    学习了
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2016-6-30 10:56
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    49#
    发表于 2008-2-22 17:03:10 | 只看该作者
    我觉得大家天天都在说重视测试,但是对于测试,大多数人还是处于初级认识阶段,关键是看公司领导对测试是否有更新的认识,当认识多了,也就重视起来,测试也就有了最大的保证,不过就国内现状,还得等待。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    50#
    发表于 2008-2-25 12:18:51 | 只看该作者
    想法都不错,应用性不高。
    bug库的整理还是有必要的,将重复出现的bug找出来并归结原因,在测试组内建立自己的检查表是有一定的指导意义的。也可以将该表转化为项目组其他成员可用的形式发出。
    至于说测试案例的评审希望项目组全体参加,这个基本上不可能,如果是业务逻辑复杂的应用,拉整个项目组的时间来做评审,项目组成员答应老板也不会答应。控外不如控内,关键是让手下的测试人员多熟悉系统架构和应用需求。
    测试用例的复用,个人建议是针对核心模块(保证正常流程的一定要写)来做测试用例的编写,外部的功能或表现实现结合用检查表的形式进行检查,一;充分保证80%的缺陷在20%的代码中发现,二;提高测试效率,减少无谓的用例维护和测试时间。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    51#
    发表于 2008-4-3 11:21:33 | 只看该作者
    收藏,学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    52#
    发表于 2008-4-11 16:28:41 | 只看该作者
    测试用例如果没时间全部评审的话,可以列出一些测试点来评审,把测试用例的位置放到只是对于测试点内容的细化上,这样我想对于BA,Dev应该可以节省更多的时间。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    53#
    发表于 2008-4-19 14:24:16 | 只看该作者

    回复 6# 的帖子

    不错,支持!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    54#
    发表于 2008-4-19 15:36:06 | 只看该作者
    原帖由 刘洪鹏 于 2007-7-12 17:15 发表
    测试方案和测试计划你认为那个重要啊 ?

    aaaa
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    55#
    发表于 2008-4-19 15:36:58 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    56#
    发表于 2008-4-19 15:38:08 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2008-4-19 15:38:24 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2008-4-21 15:59:57 | 只看该作者
    现在,测试没这么正规。项目需求评审的很少。并且,在时间不充裕的情况下,不写测试用例。就直接凭借测试人员积累的经验,直接执行测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    59#
    发表于 2008-4-25 16:30:00 | 只看该作者

    偶感

    其实很多东西都要从实际出发,楼主说的建议确实不错,但也要分公司,还有什么重要什么不重要,没有开始哪来结束,所以测试计划和测试方案都很重要,只是阶段不同
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2008-5-27 15:34:18 | 只看该作者

    学习一下

    对楼主的想法很认同,正在想同样的问题。
    测试用例有两种:
    一种是操作结果可保存的,这种测试尽量用自动化测试。
    一种是操作结果不可保存的,是一种过程测试,需要手动测试。
    自动化测试的执行能够很大程度的提高工作效率,保证测试质量。避免回归测试的疏忽。

    测试没有不变的规则,不同行业,不同软件的测试是灵活的。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-25 05:09 , Processed in 0.077793 second(s), 20 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表