51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3554|回复: 16
打印 上一主题 下一主题

[原创] 【风雨八年】在测试行业打酱油

[复制链接]
  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2012-5-13 13:10:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    在网上看到马云先生的一篇文章《给雅虎员工的演讲》,提到一个核心思想:懒。
         马云语录一:这个世界实际上是靠懒人来支撑的。世界如此地精彩都拜懒人所赐。
         马云语录二:懒不是傻懒,如果你想少干,就要想出懒的方法。要懒出风格,懒出境界。
         所以,测试行业也需要打酱油的人来支撑。从我五年测试工作中,也跟过不少测试同行沟通。提到一个重点就是测试用例应该设计成什么样子。有人说测试用例要尽可能全面覆盖,宁可多不可少。这个观点有点像“宁可错杀一万,不可漏网一人”的味道,而我认为测试用例应该是越少越好,前提是:达到全面覆盖。
         在测试执行阶段,对于测试难度较高存在缺陷的概率较低的功能,是否需要执行测试的时候,我也曾与同事发生过争执。有人的思想是凡是属于测试范围内以及可能影响的周边模块都需要测试,不管难度有多大。而我的观点是可以分析该模块存在缺陷的概率有多小,通过测试前的分析以及测试过程中的结果进行二次分析以及与开发和配合方分析如果概率极小,不建议测试,因为投入产出比不划算。
         一些“偷懒”的做法引起了很大的争议,因为这些做法可能残存了上线风险。但我认为如此做法可以将80%的时间花在20%的重要工作上,再者任何时候测试都是需要思考的活儿,哪些用例应该重点测试,哪些用例甚至不需要执行。--比只考虑是否漏测多了一个思考点!
         做多了是一种成本的投入,是一种严重浪费。作为测试经理、想成为优秀的测试工程师除在思考是否存在漏测的基础上,应该同时考虑如何“打酱油”以达到节约测试时间、节约人力、成本。建立一种如何花最少的人力做别人相同的工作,把酱油打出境界来。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏1
    回复

    使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2012-5-13 20:39:38 | 只看该作者
    许久不见,千里文风大变了。我们本来还想看续集,再续集叫经,结果文变了,内容也变了。嘿嘿,不过现在说出来的话有点别味儿,千里终于在打酱油的过成中成长了不少。各方面。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2012-5-13 21:16:03 | 只看该作者
    回复 2# 月上百合


        又见百合妹妹,鸡冻……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2012-5-13 21:16:32 | 只看该作者
    老千开始折腾新故事了……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2012-5-13 23:21:49 | 只看该作者
    支持楼主的观点,测试做到一定程度之后,关键是需要解决效率问题!只有“懒人”才会用“懒招”,因为他们面对超负荷的工作必须完成时,就会停下来思考,是不是有更便捷的方法来完成工作。测试用例的重用性就是“懒招”的代表作。面向对象的测试用例可谓是“懒招”极致,可惜,不是每家公司都有能力执行的。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    7 小时前
  • 签到天数: 1052 天

    连续签到: 2 天

    [LV.10]测试总司令

    6#
    发表于 2012-5-14 10:48:21 | 只看该作者
    别有风味的,来支持下!
    回复 支持 反对

    使用道具 举报

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

    连续签到: 1 天

    [LV.9]测试副司令

    7#
    发表于 2012-5-14 11:20:56 | 只看该作者
    喲,千里老兄终于忍不住啦
    回复 支持 反对

    使用道具 举报

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

    连续签到: 1 天

    [LV.9]测试副司令

    8#
    发表于 2012-5-14 11:22:15 | 只看该作者
    写的真的不错呢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2012-5-14 12:57:13 | 只看该作者
    一直认为测试用例需要的是精简。
    1、有些用例,即使他真的可以发现问题,但是如果那些问题真的是要经过如此复杂的操作,或者用户极少有这种使用方式,相信最后也很难推动开发解决这类问题的(除非是不可恢复的错误)。最后就带着这类问题发布了。
    2、同样一个测试点,不同的人可能有不同的测试方法,为何一定要死死的限定测试步骤呢?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    10#
    发表于 2012-5-14 13:53:18 | 只看该作者
    回复 3# 愚人


    哈哈,好久不见了愚人
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2012-5-15 11:59:20 | 只看该作者
    在有限的测试时间里,“打酱油”是必需的。支持。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2012-5-15 22:30:10 | 只看该作者
    我是来打酱油的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2012-5-16 12:02:51 | 只看该作者
    继续打酱油
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    14#
     楼主| 发表于 2012-5-17 18:39:01 | 只看该作者
    支持楼主的观点,测试做到一定程度之后,关键是需要解决效率问题!只有“懒人”才会用“懒招”,因为他们面 ...
    清风随雨 发表于 2012-5-13 23:21



        哈哈,多谢支持。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2012-5-17 22:49:10 | 只看该作者
    现在就碰到设计测试用例冗余的问题,坐等期待中……
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    16#
     楼主| 发表于 2012-5-20 10:28:13 | 只看该作者
    现在就碰到设计测试用例冗余的问题,坐等期待中……
    zacaooo 发表于 2012-5-17 22:49



        没有很多可期待的,这个问题我认为需要自己去解决。看到有冗余的用例肯定是想着如何精减了,有这个目标并朝这个目标努力是最重要的。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-5-22 10:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    17#
    发表于 2012-5-20 10:32:23 | 只看该作者
    有了懒,才想用自动化,才有了自动化。。。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-27 16:38 , Processed in 0.088743 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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