tag 标签: 覆盖率

相关博文
  • 热度 3
    2019-5-27 15:33
    651 次阅读|
    2 个评论
    以往家中使用网络的设备只局限在笔记本电脑或手机等个人设备,而近年来随着物联网产品的崛起与发展应用,家庭里会有越来越多的设备需要联机到网络,例如智能电视、智能灯泡、智能音箱、扫地机器人或其他温湿度计等IoT设备。然而,当我们在构建家中的无线网络时,常常会考虑到以下两种问题: 家中的无线基地台(Access Point;AP)信号真的能够覆盖到每个角落吗? 所有联网的设备都能在每个角落保持联机顺畅与良好的网络质量吗? 在接下来的文章中,百佳泰将在一般常见的独栋居民楼做实际测试,从设备 使用距离、AP覆盖范围 以及 吞吐量表现 的方式,探讨性能与其间的关系。 图说:智能家居中许多装置都有联网的功能 当我们在构建家中网络时首先会申请宽带网络,业者会把网络接点拉好,并提供无线路由器做使用。然而,由于网络的接点已经固定,加上业者提供的路由器并不是理想中的机型,因此大部分的用户会另采购功能更强大的AP并安置在网络接点附近。但是,当我们购入价格高昂、功能齐全的AP时,我们还是存有疑虑: 网络信号与品质范围就足以覆盖整间房子吗? 我们还需要再选购第二台AP来保持家中网络的稳定性吗? 图说:家中的AP到底要放哪才能性能最大化? 在第一项测试中,我们透过Heatmap量测家中的AP在5GHz信号覆盖分布的情形,其次我们在房子平面图中设计定位点来模拟家中可能会使用Wi-Fi联网的角落点,并观察这些点上网络吞吐量的表现。 图说: 上图为居民房1楼平面图,下图为AP 在5GHz (dBm) 信号表现 (越红信号越好,越蓝信号越差) 从上图得知,在Heatmap的量测中有一些蓝绿色的区块(蓝绿色信号较差),造成这个区块信号较弱的原因是水泥隔间的存在。Wi-Fi信号中的5GHz传输速率虽快,但穿墙能力差,因此可以发现AP信号在穿过水泥墙时有较大的衰减,而造成联机质量不佳。 另一方面,从我们模拟的G、J、K、M这四个点可以发现不仅此区块的颜色为蓝绿色外,接收的信号强度指示 (Received Signal Strength Indication;RSSI)值也衰减到-60~-70dBm。举例来说,通常RSSI值在-60dBm以下时,手机的Wi-Fi信号显示会变薄弱(只显示1格信号);而当RSSI值达到-65~-70dBm时就会产生Wi-Fi断线的状况。 倘若用户在这些信号不佳的地方使用手机、平板观看在线视频、玩在线游戏或是视频通话时,会因Wi-Fi信号强度不足导致延迟(delay)甚至是断线的情况发生。 图说: 平面图中各点的5GHz讯号强度与速度对照表 量测完一楼的结果,我们也来观察在二楼的5GHz信号状况。我们发现只有一楼到二楼的楼梯间有微弱的信号(浅蓝色区块,RSSI值约为-60dbm以下),其余部分区块为深蓝色且信号是小于-70dBm甚至到-90dBm,而白色区块则是完全没有任何信号。 图说:居民房2楼平面图,下图为AP信号表现 由于5GHz本身的特性造成穿墙能力不足,因此二楼基本上可以说是收不到一楼的Wi-Fi信号。当使用者在二楼联机时,往往会因信号强度的不足让设备难以联机。百佳泰建议如家中有较多楼层时,为了让无线信号不中断,可考虑在每一楼层建置另一台AP或Mesh AP。 第二项测试,我们同样使用Heatmap量测AP在2.4GHz信号的覆盖分布情况。 图说:居民房1楼 AP在2.4GHz (dBm) 信号表现 图说:居民房2楼 AP在2.4GHz信号表现 图说: 2.4GHz各点信号强度与速度对照表 从测试结果我们得知,房屋1楼的无线信号覆盖情况良好,用户在1楼各处都能顺利联机上网;而在2楼则同样有信号质量偏弱(基本偏浅蓝至深蓝色)的情形,反映出用户在实际使用无线网络时会有速度慢或是经常断线等状况发生。 在量测完5GHz与2.4GHz的数据后一定也会想到,那RSSI值越好PHY Rate是不是也越好? 答案是不一定。在第一项测试的结果中发现,AP在5GHz信号下,H点的RSSI值为-49dBM、PHY rate为866Mbps,但是同为-49dBm的E’点其PHY rate却降了一阶,PHY rate只有780 Mbps。同一地点,PHY rate却相差了86Mbps,因此我们得知关于RSSI跟吞吐量,可以说这两者是有相关性,但不是完全正相关的关系。 图说:RSSI与吞吐量未有正关联性 第三项测试,我们在这个场域中以一般常用的几个应用程式APP来看看其表现以及实际使用状况。这些应用程序涵盖视频通话、语音通话、在线视频、网页浏览以及档案下载等。 从表中的结果可以知道这些应用程式在家中的1楼使用是没问题的,但是在2楼中使用时,不同的应用程式会出现不同的状况,包含延迟、网络联机质量不佳、断线等问题,造成用户体验不佳的情形。 透过以上三种测试我们发现如果家庭面积较大、隔间较复杂等因素都会影响到无线信号的强度。百佳泰蕴含多年无线测试技术,可提供专业咨询与客制化测试方案,帮助您在场域中找出信号弱点,完整规划无线场域,确保您的IoT产品可正常联网及互通。 在接下来的文章中,我们会介绍设备本身的无线信号接收与传递性能的比较,透过数据化的方式来让大家了解各产品在RF性能上的差异。 如您有关于无线信号的问题,欢迎联系百佳泰。
  • 2014-7-6 18:41
    650 次阅读|
    0 个评论
      关于覆盖率,网络上最常见的两个词应该是“测试覆盖率”(Test Coverage)和”代码覆盖率“(Code Coverage)。今天就来探探这两个东西。     在测试里面,一般会将测试覆盖率分为两个部分,即”需求覆盖率“和”代码覆盖率“。可以看到,代码覆盖率其实是测试覆盖率的一部分而已。其中,最常讨论和关心的是”代码覆盖率“,代码覆盖率又分为程序语句和代码行覆盖,分支覆盖和条件覆盖。对于这些概念,我们逐个解释。     需求覆盖率:如果需求已经定义好,这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是,这里的需求不仅仅是指功能需求,还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点,我们有多少性能点要求,这些将作为分母;我们写了多少测试用例,覆盖了多少模块,多少功能点,我们的性能测试用例考虑了待测程序多少性能点,这些作为分子。     代码覆盖率:为了更加全面的覆盖,我们可能还需要测试程序的流程,我们可能会考虑到一个函数的数据的输入与输出,甚至是每一行代码的执行情况,代码的每一条逻辑和分支,这个时候我们的测试执行情况就以代码覆盖率来衡量,这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。     语句覆盖率:换个名字叫做代码行覆盖率,这就是监视每行代码是否在用例(当然之所有的)中是否被执行到,准确点说是我们的用例里面大概执行了百分之多少的语句/代码行数。需要注意的是,即使所有的语句都被执行到,也不一定执行到了所有的路径。比如有五条语句:ABCDE,如果我们执行了用例覆盖了ABCDE,另外一个用例这个时候我们覆盖了所有语句,但是可能还存在一个路径(如ABC)没有执行,例如:     public verifyToken(string yourname, string yourtitle)     {     A   output(”Hello, my dear friends“);     B   if(yourname == "uniquestudiowcd")     {     C      output("Hello, Aaron");     }     D   if(yourtitle == "tester")     {     E     output("Hello, my dear tester");     }     }     这个时候我们输入参数”uniquestudiowcd“和”tester“覆盖到了所有的语句,但是我们漏掉了一个路径:即输入参数”uniquestudiowcd“和”coder“。     分支覆盖率:我们也给它换个名字即”路径覆盖率“,尽管并不完全对。在上面的例子中,如果我们仅考虑了第一个用例(即输入参数”uniquestudiowcd“和”tester“),我们的语句覆盖率为100%,带式路径覆盖率可就低了,因为它存在ABD,ABCD,ABCDE,ABDE等等很多路径。     条件覆盖率:这也就是为什么不能说”分支覆盖“不同于”路径覆盖“的原因所在。如果我们在一个IF语句中加入了判断组合,那就要考虑更多的问题了,因为主要出现在条件语句中,所以我们称之为”条件覆盖“。我们更改上述示例代码:     public verifyToken(string yourname, string yourtitle,string gendar)     {     A   output(”Hello, my dear friends“);     B   if(yourname == "uniquestudiowcd" gendar == ”man“)     {     C      output("Hello, Aaron");     }     D   if(yourtitle == "tester")     {     E     output("Hello, my dear tester");     }     }     很明显即使我们输入参数”uniquestudiowcd“”tester“,”woman“和”uniquestudiowcd“”tester“”man“,这两个用例的路径走的分支是一样的,但是条件覆盖不一样,实际上两者的”路径“也是不一样的。     上面主要介绍的测试覆盖率的一些基本知识,在关于测试覆盖率的第二篇文章中,我将介绍归纳一下测试覆盖率的用处,或者说测试覆盖率的意义。  在上一篇文章里面我们介绍了测试覆盖率的分类,举例揭示了需求覆盖率,语句覆盖率,分支覆盖率很条件覆盖率这些问题,在这篇文章里面,则主要介绍为什么要千方百计来找“测试覆盖率”。(关于上一篇文章,参见测试覆盖率之一——测试覆盖率分类)     关于测试覆盖率讲的最多的地方应该实在测试停止标准里面。在测试停止标准里面经常出现这样的语句“测试覆盖率达到或超过95%”之类的概念。其实,如果你看了我前一篇文章中提到的测试覆盖率分类的话,就知道这是一个不准确的描述。关于更准确的描述,我认为应该是“性能测试需求覆盖率达到100%,功能需求测试覆盖率达到100%,语句覆盖率达到85%”这样的句子。“测试覆盖率”本来就包含了很多子部分,所以提测试覆盖率是不明智的一种做法。而我所说的语句覆盖率85%相对于性能测试需求覆盖率这个数据来讲似乎更难获得准确数值,不过现在已经有了很多工具用于测试“语句覆盖率”,而不用我们自己去计算已执行的测试用例覆盖到了数万或者更多代码中百分之多少,也有一些工具可以帮助我们得到代码覆盖率中“分支覆盖率”等其它数据。关于覆盖率检测工具,我将在本系列的后续文章中给予介绍。     测试覆盖率是测试结束标准中的一部分,这显然不是我们今天讨论的重点——测试覆盖率有什么用?直观上讲,我们可以这样理解:     - 性能测试覆盖率如果没达到100%,表示我们有些性能测试点没有覆盖到,这在一个对于性能有所要求系统显然是不可取的,这表示我们应该增加用例来覆盖到所需要的性能测试点。     - 重要模块的语句覆盖率和条件覆盖率很低,表示我们测试用例过少,我们应当增加用例;如果我们已经写了很多用例(相对于代码行数来讲),但是这两项数据还是很低,那我们得检查一下我们的用例了,是否有重复的用例?是否应该重新设计用例结构?     对于测试覆盖率,我们有这样一个简单的算式,如果A模块的条件覆盖率为80%,B模块也为80%,C模块也为80%,那么我们的总覆盖率则是 51.2%,而不是我们想当然的80%。至于为什么这样,我就不解释了。因此在我们审查覆盖率报告时候,我们关注的是覆盖率低的模块,我们要检查为什么低,我们要思考怎么提高,对于覆盖率低的地方,是不是有一个等价类被我们忽略了?     测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要,但是如果在螺旋式开发模式中,如果我们没有控制好我们上一个迭代中的测试覆盖率,当一个版本一个版本累加下来后,你就很难确定我们哪些模块在开发过程中没有给予足够的测试;在近些年兴起的持续集成浪潮中,由于要求短迭代(有人建议3-5天一个迭代),如果没有很好的测试覆盖率保证,很难在这么快的代码变迁中保证测试的质量。在持续集成工作中,代码提交频繁,我们可以通过测试覆盖率来了快速对应新写的,没有对应测试的代码。     总之,测试覆盖率可以提供给我们两个方面的信息:测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块,可以帮助我们了解重要模块的测试情况,以此来衡量我们测试用例的质量乃至测试的质量。 上一篇文章中,介绍了测试覆盖率的意义之类的东西。测试覆盖率可以帮助我们检查测试质量,检查测试用例的有效率。如果有兴趣的话,可以阅读测试覆盖率之二——测试覆盖率有什么用?     关于测试覆盖率,我个人的感觉是说的多,用的少。最近在网络上看到一篇文章,讨论一个问题“测试需要100%的覆盖率吗?”被转载了很多次,有兴趣的同行可以找来看看。的确,一想到测试覆盖率,立马就有完美主义者跳出来说100%。100%的测试覆盖率有什么好处呢?     1、100%的覆盖率表示我们的测试覆盖到了所有语句,分支,条件     2、100%的覆盖率表示我们测试考虑的很完全,我们可以回去睡大觉了~~     测试仿佛在这里变得不那么可怖了,但是我们至少遗漏了两个重要的地方:怎么达到100%的测试覆盖率或者说是否能够达到100%的测试覆盖率,另外一个就是100%的测试覆盖率到底能告诉我们什么信息。     首先来讲,我们是否可以达到100%的测试覆盖率?如果我们简单的将测试覆盖率理解为需求覆盖率,代码覆盖率,那么我想这是可以达到的,只要拥有足够的时间,我们的测试覆盖到每一个需求点,我们的测试覆盖到每一条语句,每一个条件,每一个分支,看起来的确没有问题。但是我们还要考虑另外一个问题,是否由我们未曾列入到需求分析中的需求呢,这种情况是存在的,如果我们计算需求覆盖率是根据Feature Spec来的(实际上如果我们需要计算的话,一般就是这样计算得来的),那么当我们有需求没有被写入Feature Spec并且我们也没有在测试中考虑相关的测试,那么我们实际的“需求覆盖率”就不是100%了。在实际开发过程中,是不可能在Feature Spec中将需求全部列出来的,所以我们得到的100%的需求覆盖率是存在水分的。     另外,对于一个应用程序(除了一些极其简单的程序)来讲,要覆盖到所有的语句。条件,分支是极其困难的,甚至可以说是不可能的。笔者在经历的一个项目中花了一整天写一个模块的单元测试,当我忙完一天并运行了所有的用例之后,我发现我的代码覆盖率仅仅增加了2%,而且是从35%到37%,不要说100%,连80%我当时都觉得是奢望。     对于第二个问题,100%的测试覆盖率能代表什么?我在上面讲到,100%的测试覆盖率表示覆盖到了所有的语句,分支和条件,但是这又说明什么呢?这是否说明了我们做到了完全测试一个软件呢?很抱歉,答案是否定的。给出下面这一段代码:     private int add(int a,int b)     {     return a+b;     }     够简单的一段代码了吧,我们可以很轻松的达到100%的覆盖率,比如我们使用用例 add(3,4)就可以覆盖所有的语句,分支,条件(当然这里面是不存在分支和条件的,所以只需要覆盖语句就可以达到代码覆盖率100%了),但是聪明的你一定会发现我们的测试远远不够:如果输入的是add(2147483647,2),这个应用程序是会出现问题的,如果我们仅仅满足于100%的代码覆盖率,是不能保证我们的软件的质量的。     关于代码覆盖率,由一个很有趣的现象:高覆盖率有时候比低覆盖率还“没用”。注意“没用”是打了引号的,我的意思是高覆盖率不能说明我们做了完全的测试,低覆盖率却可以说明我们测试远远不够,从这一点来讲,低覆盖率似乎更有意义。当然我不是在讲我们不去追求高覆盖率,我的意思是与其把A模块覆盖率从85% 提高到90%,还不如把与其类似的B模块的覆盖率从30%提高到50%更有意义。绕一大圈说回来,在任何时候高覆盖率都比低覆盖率好,但是作为一个软件,我们要顾及软件整体的测试质量,我们还要估计成本,时间等等很多问题。     上面说了不少,最后总结一下我的观点:     1、测试覆盖率100%是一个理想的情况,是很难达到的;     2、测试覆盖率100%不能说明我们做了完全的测试;     3、较低的测试覆盖率能说明我们的测试还不够,反之是不成立的,参考第二条;     4、同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试;     5、测试覆盖率达到多少要考虑到软件整体的覆盖率情况,以及项目成本,包括人力,时间等等。     个人观点,仅供参考。如果问题或意见,请联系 unique.wuchaodong@hotmail.com 或直接留言~     关于测试覆盖率100%的问题的讨论还会继续下去,如果必要的话,笔者将在本系列文章的后期继续总结,根据计划,在下一篇文章中我将介绍自己使用过的相关工具,以及我未使用但是可以从网上找到相关资料的工具,帮助大家总结一下,以备查看。
相关资源
广告