北京快三开奖

  • <tr id="U9YkSO"><strong id="U9YkSO"></strong><small id="U9YkSO"></small><button id="U9YkSO"></button><li id="U9YkSO"><noscript id="U9YkSO"><big id="U9YkSO"></big><dt id="U9YkSO"></dt></noscript></li></tr><ol id="U9YkSO"><option id="U9YkSO"><table id="U9YkSO"><blockquote id="U9YkSO"><tbody id="U9YkSO"></tbody></blockquote></table></option></ol><u id="U9YkSO"></u><kbd id="U9YkSO"><kbd id="U9YkSO"></kbd></kbd>

    <code id="U9YkSO"><strong id="U9YkSO"></strong></code>

    <fieldset id="U9YkSO"></fieldset>
          <span id="U9YkSO"></span>

              <ins id="U9YkSO"></ins>
              <acronym id="U9YkSO"><em id="U9YkSO"></em><td id="U9YkSO"><div id="U9YkSO"></div></td></acronym><address id="U9YkSO"><big id="U9YkSO"><big id="U9YkSO"></big><legend id="U9YkSO"></legend></big></address>

              <i id="U9YkSO"><div id="U9YkSO"><ins id="U9YkSO"></ins></div></i>
              <i id="U9YkSO"></i>
            1. <dl id="U9YkSO"></dl>
              1. <blockquote id="U9YkSO"><q id="U9YkSO"><noscript id="U9YkSO"></noscript><dt id="U9YkSO"></dt></q></blockquote><noframes id="U9YkSO"><i id="U9YkSO"></i>
                企业空间 推销商城 存储论坛
                北京快三开奖全闪存阵列 IBM云盘算 Acronis 安克诺斯 安腾普 腾保数据
                首页 > 散布式存储 > 注释

                散布式存储产物的测试理论及心得

                2019-04-02 16:02泉源:中国存储网
                导读:包罗:测试脚色在整个散布式存储产物开展进程中的变革;散布式存储产物的测试理论;测试理论遇到的题目及一点心得分享。

                配景引见

                这几年我不断从事散布式存储产物的测试开辟任务,随同着产物的第一次上线,第一次晋级,不断到明天。时期到场公布了有数个版本,支持着海量的用户对我们存储产物的需求。

                想写一篇文章,总结下本人的任务,记载任务中的一些心得。

                假如有人能从中取得一些启示或许播种,那将是我莫大的荣幸。

                次要讲几个方面:

                • 测试脚色在整个散布式存储产物开展进程中的变革
                • 散布式存储产物的测试理论
                • 测试理论遇到的题目
                • 一点心得

                测试脚色的改动

                普通来说,一个项目中会有如下几种脚色:

                产物司理,开辟工程师,测试工程师,运维工程师和项目司理。

                项目标开辟流程:

                • 产物司理搜集用户的需求,剖析用户的业务场景,反应给开辟和测试工程师
                • 开辟和测试工程师讨论需求,界说上线的功用以及验收规范。
                • 项目司理订定项目方案,跟踪项目进度。
                • 开辟工程师开辟完代码后交给测试工程师。
                • 测试工程师测试完成后,交给运维工程师上线。
                • 运维工程师公布上线。

                我的测试脚色在产物的差别时期有着差别的分工。

                一:测试脚色在差别产物时期的差别分工

                整个散布式存储产物的开展次要分为两个阶段:

                • 阶段一:产物初期的疾速迭代与公布

                1
                
                1个集群
                2个开辟, 1个测试, 1个运维, 1个产物兼项目司理
                1个星期每天公布
                
                特点:集群少,用户量少,拜访量少,功用少
                
                偏重点:疾速开辟和迭代,次要是满意功用需求,容许试错。
                在这个阶段根本都因此疾速公布为准。
                开辟的功用比拟单一,1个测试根本能满意业务需求。
                
                题目:
                由于工夫紧急,测试只能有所弃取。
                没有标准的流程,招致题目也比拟多,需求修复。
                再加上新需求,引入更频仍的晋级和测试。
                堕入一个恶性循环。
                
                测试脚色:
                这个阶段,测试次要是实行测试用例。开辟在完成单位测试后,根本不承当测试义务。
                

                • 阶段二:产物波动期的迭代与公布

                1
                
                数十个集群
                10+开辟, 1个测试, 3个运维, 2个产物, 1个项目司理
                2个月公布一次
                
                特点:集群多,用户量多,拜访量多,功用多
                
                偏重点:产物的波动性。不容许试错。
                
                题目:
                不克不及再是之前的玩法。由于集群多,晋级就变得很费事。开辟,测试,运维分属差别的部分,
                关于开辟来说,需求越快上线越好。最好每天都能公布一局部代码。KPI是功用上线。
                关于测试来说,测试工夫缺乏,屡次公布会带来质量危害。KPI是产物质量。
                关于运维来说,公布越少越好。每次公布都能够带来误操纵的危害。KPI是公布波动性。
                各方的长处需求纷歧致,很容易发生抵牾。
                
                测试脚色:需求发作改动,由于一团体再也无法完成那么多的测试义务。
                

                以是最初各方面约定的后果便是:

                1
                
                延伸公布周期,低落公布频率。
                
                开辟进程的改良:引入设计和代码评审,引入静态代码扫描,引入测试掩盖率的要求,尤其是UT测试掩盖率的要求。行掩盖率和功用分支掩盖率。
                
                测试进程的改良:引入提测规范,加强主动化测试,不再承当一切的测试义务,将测试义务分派给其他开辟同窗,次要停止测试范畴评价,评审测试方案及测试用例。
                
                运维进程的改良:引入主动化公布流程,增强线上监控。
                这个阶段,测试次要是树立一套测试的机制,让每个开辟都来做测试,开辟需求承当测试义务。
                

                二:公司层面临测试脚色的定位

                在产物开展的进程中,公司对测试的定位也在不时发作变革

                • 一开端,测试和开辟是在一个团队。
                • 厥后,测试和开辟离开,属于差别的团队。
                • 再厥后,测试和开辟又属于统一个团队。
                • 再厥后,推行全栈工程师,没有专职的测试工程师。

                全栈工程师,每团体的了解能够纷歧样。我的复杂了解便是全干工程师,对开辟,测试,运维都无能的工程师。

                这个观点有人支持,有人支持。都有原理,就像我们需求大而全的百货阛阓,也需求小而美的专卖店。

                公司一切的决议都因此能支持业务需求为条件。我们需求做的不是讨论对不合错误,而应该是片面拥抱。

                高兴做到一专多能,顺应这个疾速变革的情况。

                散布式存储产物的测试理论

                在散布式存储产物的测试进程中,测试究竟做了些什么事变呢?

                一:测试任务内容

                • 需求,设计评审

                  测试需求到场到每一个进程中

                  在设计评审的时分就需求晓得验收的规范,这是最紧张的开端。由于这个时分假如没有了解用户的需求,验收规范就会跑偏。

                  用户的需求是测试的基准点。

                • 测试范畴

                  需求确定测试范畴。上线的工夫都是牢固的,在无限的工夫内能够无法掩盖一切的测试,得指定测试范畴。

                  这一方面取决于测试对整个零碎的理解水平,另一方面也是磨练和开辟相同和交换才能。

                • 测试用例的设计与开辟

                  次要是依据需求编写测试东西或许测试用例代码。一些测试册本上也引见了一些罕见的办法。这里未几讲。

                • 主动化测试框架的设计与维护

                  只要主动化测试才干把人从复杂,反复,繁琐的休息中束缚出来。

                  引入继续集成机制,实时发明代码中存在的题目。

                • 测试工具确定

                  次要是确定需求测试的版本,以包管最初上线的版本便是测试的版本。

                • 测试施行及反应

                  完成测试方案,编写测试陈诉,在Bug跟踪零碎上记载测试中发明的题目。

                  搜集这些后果给项目司理做质量评价。固然不片面,但也是紧张参考。

                  统计测试后果,剖析。

                  统计测试掩盖率,跟踪未掩盖到的中央。

                  这里需求阐明的是,测试掩盖率达标了,不料味着测试达标了,只是表现一切的代码都掩盖到了。还需求人工剖析测试的齐备性。

                • 上线确认及写公布备忘录

                  上线版本及设置装备摆设文件的终极确认。将一切上线的功用以邮件的方式告诉给协作同伴。

                • 上线题目跟踪及反应

                  前期线上题目的反应与追踪,以防止在下个版本中呈现异样的题目。

                散布式存储产物的开辟和测试是个巨大的工程,所触及到的测试需求分类及分级。为此,引入了测试分级的观点。

                二:测试的分级

                测试分级 测试资源 测试目标 测试频率
                一级:单位测试 单机完成 不需求依赖其他情况,完成代码函数级另外测试。会接纳一些Mock手腕去失对情况的依赖 每次提交接码
                二级:功用测试 小集群 模仿真实场景,完乐成能级另外测试。对其他模块有依赖 每次提交接码
                三级:零碎测试 小集群 模仿真实场景,完成零碎级另外测试,是功用的组合。对其他模块有依赖 每次提交接码
                四级:一级功能测试 中型集群 模仿真实场景,完成功能测试。次要存眷Latency,QPS,毛刺率,吞吐量等目标。对其他情况有依赖 每次公布
                五级:二级功能测试 中型集群 模仿真实场景,完成压力测试,强健性测试(Failover测试)。次要存眷CPU,内存,网络等资源耗尽或许不行用的状况下,零碎的体现 每次公布
                六级:数据兼容性及晋级测试 小集群 模仿真实场景,完成存储及上线公布相干测试。 每次公布
                七级:端到端模仿用户场景测试 大集群 模仿用户的场景,取得测试数据 每次公布

                这个分级的目标次要是为了:

                • 分工

                  开辟需求担任单位测试和功用测试都经过,

                  才表现代码可测了。才干走到前面的测试流程。

                • 在告急上线的时分,有所弃取

                  差别的级别意味着差别的测试工夫,一次单位测试和一次功能测试的工夫是纷歧样的。一级和二级是必需要全经过。往上的级别可以有选择性地经过。

                • 测试资源的分派

                三:测试用例范例

                散布式存储产物的特点:

                • 1 存储海量的数据,差别范例
                • 2 集群中呆板的破坏是常态
                • 3 海量的用户拜访

                以是在设计测试用的时分依据散布式存储产物的特点设计了如下的测试用例:

                • 数据兼容性测试

                  代码不断在变,会有差别的数据范例呈现,怎样包管数据兼容性?

                  普通来说都需求思索新旧版本写入数据的兼容性。

                  理论中可以每天模仿用户写入差别巨细,差别范例的文件,在每次晋级之前预公布,来校验这些数据。以做到数据兼容测试。

                  开辟也会在UT中包括这局部内容。只不外是在差别的级别来测试这一点。

                • 数据完好性测试

                  作为散布式存储产物,用户的数据是不克不及丢的。这点是做存储的底裤。

                  在理论中会每天扫描新增的数据以反省数据的完好性。

                  活期还会做全量数据扫描。

                • 功能测试

                  每次版本公布的时分,我们需求晓得这个版本和上一个版真相比,功能能否有提拔。这个也是用户比拟能直观感觉到的。

                  功能测试是一个比拟庞大的话题,这里不睁开。

                  功能测试和测试的客户端,运用的代码,恳求的范例,集群数据的几多都有干系。理论中是选定差未几的测试情况,停止比照,以增加多个测试变量对功能后果带来的影响。

                • 压力测试

                  模仿网络,磁盘,CPU等资源耗费完,测试零碎的体现才能。对零碎设定报警阈值。一旦超越这个才能,零碎开端报警。也可以供运维同窗参考集群的负载才能。

                • 波动性测试

                  测试零碎在临时运转下,察看内存,网络,CPU资源耗费的状况。罕见的题目便是内存泄漏,假如每次泄漏一点,短工夫测试是无法发明题目的。以是普通要求零碎能延续运转7天以上。

                • 平安测试

                  慢衔接打击测试

                  大并发模仿打击测试

                  其他打击模仿

                • 零碎强健性测试

                  也指Failover测试,理论中也是分层的头脑

                  先分模块:

                  模仿零碎各个模块生效的状况。比方历程重启,历程不再启动等。

                  再分呆板:

                  关于散布式零碎来说,呆板资源呈现情况几乎是肯定的,比方CPU不敷用,内存超了,网卡无法运用,磁盘破坏,呆板断电等状况。主动化测试可以经过软件来模仿这些状况。

                  在实践上线的时分,照旧需求做一些模仿毛病演练。比方:一台或许多台呆板呈现断电。

                  再分集群:

                  整个集群失电后重启,数据能否丧失。

                  不行效劳的工夫,重启后多久规复效劳。

                  集群中交流机不行用。这些测试还得依赖于运维工程师的协作。

                四:测试东西

                工欲善其事必先利其器,测试东西的选择也很紧张。

                在我们理论的进程中没有接纳贸易软件,大少数也没有现成东西,大多是经过工程理论探索,开辟而来。

                东西 目标
                集群监控形态搜集与自检东西 用于测试进程中搜集监控数据和主动判别能否非常以协助测试赶早发明题目
                bug、case的报表剖析东西 用于经过从bug或case的多个维度来判别以后产物的质量危害点
                测试后果报表剖析东西 将测试后果用于比拟和剖析,方便功能题目的观察
                功能压力测试东西 该功用可以模仿用户的恳求压力,恳求范例,方便地获取功能数据
                零碎测试框架 该东西可以很好地定制测试需求,完成测试义务,收回测试陈诉,提交测试后果
                pre-check-in东西 该东西可以确保代码在提交前可以主动跑通相干测试聚集
                代码掩盖率报表剖析东西 代码掩盖率陈诉剖析东西,可以方便给出掩盖率缺乏的各组件代码
                静态代码反省东西 可以确保代码在提交前可以跑通静态代码反省并提供报表功用
                协议层、东西层的掩盖率反省东西 可以对组件的协议层和东西下令层停止掩盖率反省,来包管测试的掩盖面

                五:做好灰度公布

                即便在做了云云多测试的状况下,照旧能够会有丧家之犬。怎样办?

                在理论中,我以为比拟卓有成效的办法是做好灰度公布。

                这里说的灰度公布指的是,公布的时分只公布一局部呆板,察看。没有题目,再逐渐分批次公布,直至终极全部上线。

                做好灰度公布的条件:

                • 1 零碎是有兼容性的

                  也便是说,整个零碎应该是可以兼容新旧版本同时存在,且不会互相影响。

                  假如新版本写入的旧版本不克不及读,那么需求公布到两头的兼容版本。

                • 2 要有好的监控东西

                  呆板资源的可视化与监控。比方CPU,内存,网络等能否正常

                  各层模块的可用性目标可视化与监控。比方乐成率,行列步队长度,安康度等能否正常

                  要害业务数据目标的可视化与监控。恳求的准确率,功能,QPS等业务目标等能否正常

                  引入大数据东西对每天的拜访恳求停止剖析,失掉真正的业务恳求。

                  做好及时监控,以确定零碎的波动性

                • 3 有责任心的工程师

                  一个有责任心的工程师会在公布当前去存眷功用能否准期任务,那些日记能否正常,线上呆板,业务能否都运转正常。

                六:做好上线后的跟踪回忆

                假如上线后有丧家之犬,应该实时地发明,并在缺陷零碎中跟踪,直至修复上线,而且在测试用例中掩盖。以防止反复的错误呈现。

                七:产物质量的保证

                怎样保证产物公布的质量是一个很大的话题。

                总结本人在产物中的办法有:

                • 1 静态代码扫描
                • 2 测试掩盖率
                • 3 代码及测试评审
                • 4 实行好测试
                • 5 灰度公布
                • 6 公布总结,添加测试掩盖,构成精良的闭环。

                测试理论中遇到的题目

                在详细的测试理论中,照旧遇到了许多题目。

                • 1 测试用例不波动

                  由于测试不波动,招致测试常常失败。各人都失败偶然候都视而不见了。典范的破窗原理。

                • 2 测试情况的题目

                  单一的情况无法满意几个层级的测试需求,但测试资源偶然候是无限的。需求做好计划。

                • 3 测试服从的题目

                  由于产物功用的不时叠加,回归的聚集原来越巨大,越来越庞大。回归一次的工夫变得越来越长。需求重构测试用例。

                • 4 多个版本同时公布的题目

                  由于产物在公布的时分能够会有多个分支在回归,比方正在开辟的代码分支,线上需求修复的代码分支。

                  但回归服从不高,只能列队等候。照旧需求进步测试服从。增加回归的工夫

                • 5 测试观察题目困难

                  测试用例的要求没有开辟代码要求高,测试框架中对日记支持不敷敌对,都形成了观察题目困难。需求改良日记。

                我们照旧需求做许多任务,让测试更快,更无效地发作。

                一点心得

                有几点感觉吧:

                • 1 人靠谱了,事才靠谱

                  晓得了和做到了之间还差十万八千里。

                  用韩寒的话说便是:我明白了很多原理,却仍然过欠好这终身。

                  用针言说便是:知易行难。

                  但靠谱的人总是能在种种不靠谱的情况下,把事变做靠谱。

                • 2 质量不是仅靠测试工程师来保证

                  好的测试工程师就像良好的守门员,时辰防备着Bug的防御,守住质量这扇门。

                  但再好的守门员没有先锋,后卫的团队共同,单枪匹马也无法制止Bug的防御。

                  质量贯串在每一次评审,代码Review,单位测试,上线察看,灰度公布中等关键中。只要每一个关键都做到位,才会有好的质量。

                  质量是需求开辟,测试,运维一同保证的。

                • 3 质量很紧张

                  没有质量的代码上线便是运维噩梦的开端。

                  它能够随同着中午报警,连夜修复,彻夜告急公布。

                • 4 要引入全员评审

                  尽能够多的眼睛,就可以让一切的题目显现。每团体的视角纷歧样,就像是手术台上的无影灯一样,从各个角度照射下去,Bug就无所遁形。

                  每团体的头脑在碰撞,大概他人的一句提示或许一个题目,就可以发明本人的视野盲区。

                转自:

                猫头鹰技能博客

                http://mtydev.net/2016/01/27/%E5%88%86%E5%B8%83%E5%BC%8F%E5%AD%98%E5%82%A8%E4%BA%A7%E5%93%81%E7%9A%84%E6%B5%8B%E8%AF%95%E5%AE%9E%E8%B7%B5%E5%8F%8A%E5%BF%83%E5%BE%97/

                持续阅读
                中国存储网声明:此文观念不代表本站态度,若有版权疑问请联络我们。
                相干阅读
                产物引荐
                头条阅读
                栏目热门

                Copyright @ 2006-2019 ChinaStor.COM 版权一切 京ICP备14047533号

                中国存储网

                存储第一站,存储流派,存储在线交换平台