51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6765|回复: 18
打印 上一主题 下一主题

[原创] 新鲜的测试工作规范及评估标准

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-5-27 14:04:52 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
刚制定的测试部门工作规范及评估标准,各位同仁帮忙看下有哪些不适合的地方。本没有学过测试,但已经做过了几年的测试管理,凭着经验写的,欢迎大家拍砖

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-5-27 17:15:50 | 只看该作者
支持一下。
回复 支持 反对

使用道具 举报

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

    连续签到: 1 天

    [LV.7]测试师长

    3#
    发表于 2010-5-28 09:03:43 | 只看该作者
    看看先
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-6-2 11:22:12 | 只看该作者
    测试在集成之后就结束了?个人看来,集成和系统测试两个的侧重点还是有一点点区别的。此外测试计划的制定应该让项目经理参与进来。让测试负责人和项目经理共同编写,有利于为测试团队赢得时间等资源上面的优势。
    此外,单元测试和集成测试,测试人员参与的程度很高,这要求测试人员拥有很高的编码能力和丰富的集成测试经验,而且对需求和设计的文档要求非常高。各个公司的人员能力不同,看实际情况而定。

    此外,文档的管理加个编号吧,方便你们管理的。

    个人见解,不负法律责任,哈哈。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-6-2 11:31:45 | 只看该作者
    用户手册由测试人员编写有利有弊。个人感觉弊大于利。主要考虑测试人员对系统整体的把握不一定非常OK,而且用户手册的编写有很多文字的东西,可以考虑安排个专门的写手。
    评估标准中对于完成质量的好坏如何判断?这一块应该不怎么好评判。依靠Defects流失率,还是依靠其它的什么。我感觉缺少量化的标准。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2010-6-3 10:49:07 | 只看该作者
    原帖由 caine 于 2010-6-2 11:22 发表
    测试在集成之后就结束了?个人看来,集成和系统测试两个的侧重点还是有一点点区别的。此外测试计划的制定应该让项目经理参与进来。让测试负责人和项目经理共同编写,有利于为测试团队赢得时间等资源上面的优势。
    此 ...

    是的,目前是在集成测试之后就结束了,当然过程中穿插无数次的回归测试。
    另外,测试计划是由项目经理评审的,所以也适当参与了一些。
    单元测试其实是指模块测试,不涉及开发的。涉及编码的单元测试由开发人员自行测试
    谢谢你的意见,欢迎再次讨论

    [ 本帖最后由 wcp_856 于 2010-6-3 10:50 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
     楼主| 发表于 2010-6-3 10:52:04 | 只看该作者
    原帖由 caine 于 2010-6-2 11:31 发表
    用户手册由测试人员编写有利有弊。个人感觉弊大于利。主要考虑测试人员对系统整体的把握不一定非常OK,而且用户手册的编写有很多文字的东西,可以考虑安排个专门的写手。
    评估标准中对于完成质量的好坏如何判断?这 ...

    我个人认为用户手册还是由测试人员来写比较合适,测试人员应该对整个系统比开发人员要熟悉的全面,我们有内部的文档审核员,但不负责文档编写,只负责审核
    评估标准中我觉得太量化的东西容易误导,所以我现在努力完善这个标准向不太量化的方向发展,希望能够充分调动积极性。
    谢谢你的意见~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2010-6-3 13:52:28 | 只看该作者
    hi,再多嘴几句哈。
    如果标准不能够被量化,我个人认为不要使用。模糊的东西会让人很难去操作,受执行者的个人感觉影响较大。而且结果出来后,也很难有说服力。一定程度上会降低标准的威信力。不知道这个评估标准执行后会不会有money上的奖励。如果有的话更要注意不要搞模糊的东西。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-6-24 16:24:14 | 只看该作者
    谢谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2010-6-24 21:51:22 | 只看该作者
    谢谢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-7-15 17:42:23 | 只看该作者
    不错不错,下载研究一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2010-7-16 20:51:12 | 只看该作者
    看看先..................
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2010-9-28 15:05:40 | 只看该作者
    hi,再多嘴几句哈。
    如果标准不能够被量化,我个人认为不要使用。模糊的东西会让人很难去操作,受执行者的 ...
    caine 发表于 2010-6-3 13:52


    嗯嗯,确实太模糊的东西给人不真实的感觉
    量化的东西体现在绩效评估中了,制度和规范中没有体现
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    14#
    发表于 2010-9-28 15:27:56 | 只看该作者
    本帖最后由 archonwang 于 2010-9-28 15:28 编辑

    粗看了下,方向方面比较明确,需要从整个工程角度考虑测试方面的相关工作,但是从规范上看,具体实施方面可能存在难度,着眼于相关项目测试经理的个人能力。

    尤其要注意对测试工作成果的体现。

    规范上需要体现的是各项工作的操作细则、交付内容说明及对应的处理规则,汇报机制以及评审和相关审核。

    有点乱,参考。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-9-28 19:51:56 | 只看该作者
    还是不错的
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-10-14 16:15
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    16#
    发表于 2010-10-15 15:04:29 | 只看该作者
    谢谢分享 下了看看
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2011-3-14 15:51:37 | 只看该作者
    看看先...
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2011-3-14 15:51:44 | 只看该作者
    看看先...
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2017-6-28 10:54
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    19#
    发表于 2011-3-15 11:15:45 | 只看该作者
    做为部门体系文档,首先文档模板不够规范,如,页眉缺少公司logo,缺少流程图,角色
    其次,缺少量化的质量目标和方针
    建议楼主学习下cmmi,会有帮助的
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-8 06:07 , Processed in 0.080105 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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