• 【转载】测试时间估算


    关于时间评估,有很多非常专业的评估方法 & 评估公式

    实际执行的情况是:没有那么多时间给你去估算(也许,从接到项目到上线,总共只有两天时间;你期望用1天时间去估算测试需要多长时间,明显不现实)。而且,不同的项目、不同的团队、不同的质量要求、不同需求的紧急度,需要的测试时间,完全不同 。

    在需求都不完全清楚的情况下,怎么估算测试时间呢 ?
    简单粗暴的评估方法:「三分之一」大法 。

    根据开发评估的整体时间,除以3 ,得到测试总时间 。再结合经验 ,适当加减20%时间即可 。

    如果需要把每个模块的时间,细分呢 ?还是保持如上的原则:总时间不变,等比拆分,得到每个模块的时间 。

    四点建议

    1. 测试估算的时间,只需考虑测试的执行时间。如果中途,由于开发延期提测,或者开发修改Bug时间过长,等待新版本测试。在时间评估的时候,需考虑这个时间,把此块时间加上(或者,发版时间,顺延) 。

    2. 自己估算的时间,如果后续发现时间不够,自己加班,想办法消化 。另外,版本结束后,吸取经验,总结下,是哪个点消耗时间过多,是否可加速(自己总结的经验,终身受益) 。如果确实不可加速,说明整个团队的效能,是低于「三分之一」评估大法的,下次估算,在之前评估时间的基础上,再加上20%的时间 。

    3. 项目过程中,不接受临时新增需求的测试,如果有临时需求,需要增加对应的测试时间(这块,理论上是这样,实际情况是,很多同学,经常被强塞任务,时间却没有增加)。

    4. 现实情况是,估算好的测试时间,已确定的上线时间,往往由于一些外部因素,提前上线,这个时候,测试同学,需列出已知风险,并做好本职工作,避免背锅 。

    文章转载自公众号为 IDO老徐 简尚 文章: “测试时间估算”的现状 及 4点建议 文章地址: https://mp.weixin.qq.com/s/wGnWcSUhhWIvThgOd1-j2A

  • 相关阅读:
    还原 | revert (Cascading & Inheritance)
    过滤器 | filter (Filter Effects)
    过渡时间 | transition-duration (Animations & Transitions)
    过渡延时 | transition-delay (Animations & Transitions)
    过渡属性 | transition-property (Animations & Transitions)
    过渡定时功能 | transition-timing-function (Animations & Transitions)
    过渡 | transition (Animations & Transitions)
    ProxySQL 读写分离
    《抛弃learning rate decay吧!》
    《Tensorflow 中 learning rate decay 的奇技淫巧 》
  • 原文地址:https://www.cnblogs.com/BigTian/p/13839053.html
Copyright © 2020-2023  润新知