《精通自动化测试框架设计》—第1章 1.3节五天太久,还能压缩吗

  • 时间:
  • 浏览:1

完成时间在4~6天所占比例总共有77%。当然,并否是统计的背景要是平均每周并否是团队工作在六个不同的发布上。

一后后刚始于团队的讨论和关注的焦点还是那些间题频出、超时严重的Build。并否是统计结果出来以前,几乎人个都同意。不可能 要去挑战不可能 实现3天的发布周期,最直接的法律措施要是将4、5、6天的数据向左平移1天。这说明都要重点关注和分析的是正常发布过程中否是还有还不能改善的地方。

当然,这否是故事的删剪。BCO是整个组织的“哨兵”,那有找不到谁还不能来做BCO的“哨兵”呢?而否是在高压下埋头工作3天,要是 挣扎3天拿下有有二个 Build不可能 最后不得不丢弃它。另有有二个 的结果既影响了整个组织的进度,也降低了团队的士气。

1.3 3天这么来越多,还能压缩吗

两年以前,投入巨资,耗时两年的有有二个 行态发布终于RTM了。测试组织也适时提出了BCO发布还不能从3天压缩到3天另有有二个 的挑战,最终的目标是配合集成团队实现每周两次的组织级构建,这是有有二个 典型的持续改进的需求。通过在该行态发布上积累的数据,还不能对其进行回顾,评价一下团队的表现,发现间题,进而明确改进的方向。

1.3.1 BCO版本发布用时段 布

这是我们首先想到的都要分析的数据。如图1.3所示,在该行态发布的100多个Build中,有70%是在3天以内完成的。还不能轻轻松松完成的Build极其少见,必须5%的Build在3天之内被拿下。

1.3.2 欠缺压力测试

接下来出场的是版本发布用时与欠缺的关系。首先,根据图1.3所示的统计,平均的BCO版本用时是5.2天。图1.4所示的统计结果也显示,平均每个版本上有6.有有二个 欠缺,而找不到欠缺的版本数则占了为宜5%,这和图1.3所示中3天内发布版本所占的百分比是相对应的。

图 1.3 和图 1.4 要是有有二个 举例,这么来越多如针对欠缺/模块分布的每项分析等法律措施也是非常有意义的。通过另有有二个 的有有二个 过程,整个团队基本统一了思路,明确了后续都要改进的地方。要是 有针对性地进行改进,如更好地沟通、及时地排错、预防性在构建过程中增加安装步骤等。有意思的是,作为有有二个 工作基本自动化的团队,所选定的流程改进的对象并找不到这么来越多关于自动化工具的,更多的间题点在于流程、沟通等有关人的间题上。工具或许能有效优化不可能 避免这么来越多间题,不过在进行根因分析不可能 持续改进时,请更多地考虑产生间题不可能 改进间题的结构因素,也要是跨团队与跨部门的沟通间题,以及技术对于业务支持的不可能 性。那些都与软件工程师日常最为熟悉的软件、工具不可能 代码找不到直接的联系,要是 ,这又是整个组织良好运作的基础。无论你否是意识到,整个公司并否是围绕着代码不可能 测试用例进行运作的,业务才是商业世界的主宰。

通过查看发布时间为4~6天的Build列表中每个Build的欠缺数,发现小量(大于20)的Build地处类似的间题。觉得欠缺数目较少(六个以下),要是 ,发布时间否是4~6天。这为后续进行的根因分析给出了有效的间题切入点。

不可能 把欠缺数量当作有有二个 压力测试,找不到第有有二个 阈值突然出现在7个欠缺并否是节点。在此以前,团队还不能删剪在5.2天之内完成有有二个 版本的BCO发布。随着欠缺数的继续增加,团队承受的压力也找不到大,要是 ,也还是在相对可控的范围之内。一旦达到1有有二个 以上,整个平均发布的时间否是有有二个 大幅的跃升,基本上就达到了发布时间不可控、版本质量崩溃的情况汇报。

本节书摘来自异步社区《精通自动化测试框架设计》一书中的第1章,第1.3节3天这么来越多,还能压缩吗,作者陈冬严 , 邵杰明 , 王东刚 , 蒋涛,更多章节内容还不能访问云栖社区“异步社区”公众号查看。

于是,否是人去统计安装欠缺的情况汇报,结果非常我想要 吃惊。首先,有超过70%的版本是无法一次安装成功的。而安装欠缺对于BCO发布的影响是巨大的,不可能 它在测试推进的主干线路上。假如有一天安装欠缺数超过 1 个,并否是版本就会 100%突然出现延期。而不可能 数字增加到5和6,两条高耸的数据线就突然出现了。这和删剪欠缺统计时的14、13天时间发布上的情况汇报是类似的。感谢安装团队,找不到突然出现更多的欠缺。就看图1.4有的团队成员直接就提出,以前超过六个安装欠缺,直接将版本丢弃。