51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4011|回复: 13
打印 上一主题 下一主题

[讨论] 如何时刻的关注测试进度?

[复制链接]
  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    跳转到指定楼层
    1#
    发表于 2011-2-23 15:41:52 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    本帖最后由 zhong3269 于 2011-2-23 15:43 编辑

    主要我想解决我部门各个项目的测试人员有计划性的去做测试。
    我的想法如下:
    1做近期的测试任务计划,主要以产品为主,其中内容包括:性能测试、功能测试、兼容测试、用例的完善等大体测试策略没有太详细的东西,特别功能测试,没有详细写出界面、等价类、边界值等等,每一项策略都规定启动时间和截至时间、负责人等信息,这是大体的计划,给领导看的。
    2.以上是大体计划,毕竟没有特别详细的测试方案,所以我想在这份计划中执行到哪块,就对这块做个详细测试计划,也就是说计划中的计划,例如:性能测试这块 我包括的内容就特别多了,执行什么脚本用什么工具、我的场景设计、测试方法等,功能就分基本功能、界面、等价类边界值等等。

    以上的想法不知道可行不可行?因为我找了一些资料,说最好不要有计划中的计划这个流程,不知道各位能有什么好的建议吗?
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2011-2-23 15:58:58 | 只看该作者
    本帖最后由 Jackc 于 2011-2-23 16:00 编辑

    呃,不建议弄得如此复杂,如使用何种测试方法(等价、场景..),与测试跟踪没什么关系。想知道测试执行效果,跟一下泄漏缺陷图就可以了(若负责整个产品,可跟踪各个小团队的泄漏)。(若公司人头够多,可以考虑细分测试人员职责,如分为 策略/用例设计和 测试执行。若人头一般,不建议过分限制测试人员思想)

    对于子计划,SMAT还是需要遵循的,如,考虑针对各个测试类型(功能、性能) 安排 具体的时间点/工作/资源(如下面还有leader,这部分还可以弄的简单些)。

    而对于后期测试跟踪的重心,建议放到报告/图表分析以及相关部门反馈上。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    3#
     楼主| 发表于 2011-2-23 16:36:46 | 只看该作者
    呃,不建议弄得如此复杂,如使用何种测试方法(等价、场景..),与测试跟踪没什么关系。想知道测试执行效果 ...
    Jackc 发表于 2011-2-23 15:58



        我能理解为,这个大计划,简略一些就可以是吧,不用特别详细!!!!其实这些测试方法不是我给予他们的,这个权利我给他们让他们自由发挥,主要我想知道他们所想的,是否全面,我是否可以分析他们的想法并给予自己的主导建议,我是想做这个事。我们的人都是灵活运用,换句话说只要功能机制变了,没准就是谁自己来写这个用例,但写用例我会主导叫上相关角色讨论。

    对于子计划的话,我也可以增加这个流程是吧!!!没也弊端,当然这个我不会写,我会把模版列出来,开个讨论会,在做下一步的详细“作战计划”,具体安排当然相关人员来共同完成,周期在1~2日
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    4#
     楼主| 发表于 2011-2-23 16:42:09 | 只看该作者
    我的想法也是!!通过去年一年发生的许许多多的事情,其中包括:我们自身能力有限、测试没有全面所导致的,基本出现这样的原因就是没有计划执行,形成一种盲测,只保证功能,实际上客户反馈的问题都在兼容性上,策略上出现问题,说白了,功能测试只要有点计算机思想都可以做,所以只做功能这个团队永远无法提高,所以今年的目标尽可能的在客户那不会反馈特别严重的bug。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2011-2-23 16:58:03 | 只看该作者
    你们的测试规范建立的还不完善呀。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2011-2-23 16:58:48 | 只看该作者
    慢慢的形成一个测试体系就更好啦。但是这需要一个很长的一个时间、经验积累。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    7#
     楼主| 发表于 2011-2-23 17:33:12 | 只看该作者
    目前在软件测试行业,我想完善的公司用手指头就能数出来吧,这方面我在做这方面的努力工作,真正找出可行的方法来,我想就完善了。至少在我们公司这样做是可行的。
    回复 支持 反对

    使用道具 举报

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

    连续签到: 1 天

    [LV.7]测试师长

    8#
    发表于 2011-2-23 18:06:09 | 只看该作者
    进度的把控还是需要建立在对需求的了解基础上,将测试工作进行细分,跟进每一步的进度,否则很难把控真实进度
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2011-2-23 23:29:32 | 只看该作者
    你们的测试规范建立的还不完善呀。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    10#
     楼主| 发表于 2011-2-24 09:11:54 | 只看该作者
    进度的把控还是需要建立在对需求的了解基础上,将测试工作进行细分,跟进每一步的进度,否则很难把控真实进 ...
    msnshow 发表于 2011-2-23 18:06



        比如说呢?能有个详细建议吗?
    回复 支持 反对

    使用道具 举报

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

    连续签到: 1 天

    [LV.7]测试师长

    11#
    发表于 2011-2-24 13:43:43 | 只看该作者
    这样说吧,你需要把一个系统按一种或多种方式进行划分,分到具体的某一块能确定有多少工作量,需要多少时间
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-11-8 12:09
  • 签到天数: 547 天

    连续签到: 1 天

    [LV.9]测试副司令

    12#
    发表于 2011-2-24 16:25:25 | 只看该作者
    赞同jackc的说法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2011-2-28 12:45:34 | 只看该作者
    这是一个系统工程,把测试的工作量估算的再准确也不能保证计划不变更,毕竟测试的很多工作有时候不在测试的掌控范围内,需要整个项目团队达到相当的水平
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-9-20 16:54
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    14#
     楼主| 发表于 2011-3-14 21:43:11 | 只看该作者
    up
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 03:14 , Processed in 0.078568 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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