软件复杂度的复杂度的种类

软件复杂度的复杂度的种类

有模块、类和程序三类复杂度。模块复杂度包含了关于模块的复杂度信息；类复杂度是针对那些使用McCabe面向对象特性的程序，它包含了关于类的复杂度信息；程序复杂度包含了关于程序的复杂度信息。
集成复杂度报告
对应于三种复杂度的是三种复杂度报告。如果一个报告的复杂度信息不只一种，那么就把这些复杂度信息组合成新的报告。
集成复杂度信息只收集一个部件及其下级的信息。例如：如果一个程序级报告包含一个类复杂度，那么只报告组成程序的类的信息，而不包含类组成的信息。McCabe复杂度是对软件结构进行严格的算术分析得来的，实质上是对程序拓扑结构复杂性的度量，明确指出了任务复杂部分。McCabe复杂度包括：圈复杂度、基本复杂度、模块设计复杂度、设计复杂度、集成复杂度、行数、规范化复杂度、全局数据复杂度、局部数据复杂度、病态数据复杂度。
McCabe复杂度的用途
在软件工程中，有三种使用McCabe复杂性度量的方式。
作为测试的辅助工具。McCabe复杂性度量的结果等于通过一个子程序的路径数，因而需要设计同样多的测试案例以覆盖所有的路径。如果测试案例数小于复杂性数，则有三种情况一是需要更多的测试；二是某些判断点可以去掉；三是某些判断点可用插入式代码替换。
作为程序设计和管理指南。在软件开发中，需要一种简单的方式指出可能出问题的子程序。保持子程序简单的通用方法是设置一个长度限制，例如50行或2页，但这实际上是在缺乏测试简明性的有效方法时无可奈何的替代方法。不少人认为McCabe度量就是这样一种简明性度量。但是要注意，McCabe度量数大的程序，不见得结构化就不好。例如，Case语句是良结构的，但可能有很大的McCabe度量数（依赖于语句中的分支数），这可能是由于问题和解决方案所固有的复杂性所决定的。使用者应当自己决定如何使用McCabe度量所提供的信息。
作为网络复杂性度量的一种方法。Hall和Preiser提出了一种组合网络复杂性度量，用于度量可能由多个程序员组按模块化原理建立的大型软件系统的复杂性。他们提出的组合度量公式为
式中 C1,...,Ck是各个模块的复杂性；CN是网络复杂性；W1和W2为权值。
McCabe复杂度即可用于度量各个模块的复杂性，也可用于度量网络复杂性。圈复杂度是用来衡量一个模块判定结构的复杂程度，数量上表现为独立路径的条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，经验表明，程序的可能错误和高的圈复杂度有着很大关系。
独立路径组成的集合称为基本路径集合，独立路径数就是指基本路径集合中路径的数量。基本路径集合不是唯一的，独立路径数也就不唯一。因此，圈复杂度是最大独立路径数。
计算方法
节点是程序中代码的最小单元，边代表节点间的程序流。如果一个模块流程图有e条边n个节点，它的圈复杂度V(G)=e-n+2，典型的V(G)max=10。图1中示例的圈复杂度是2。
优点
避免软件中的错误倾向；指出极复杂模块，这样的模块也许可以进一步细化；度量测试计划，确定测试重点；在开发过程中通过限制程序逻辑，指导测试过程；指出将要测试的区域；帮助测试人员确定测试和维护对象；与所用的高级程序设计语言类型无关。
应用
圈复杂度指出为了确保软件质量应该检测的最少基本路径的数目。在实际中，测试每一条路经是不现实的，测试难度随着路径的增加而增加。但测试基本路径对衡量代码复杂度的合理性是很必要的。McCabe & Associates建议圈复杂度到10，因为高的圈复杂度使测试变得更加复杂而且增大了软件错误产生的概率。
提示：
圈复杂度度量是测量在一个软件模块中的分支数目，在所有的开发周期中都要使用。
圈复杂度度量以软件的结构流程图为基础。控制流程图描述了软件模块的逻辑结构。一个模块在典型的语言中是一个函数或子程序，有一个入口和一个出口，也可以通过调用/返回机制设计模块。软件模块的每个执行路径，都有与从模块的控制流程图中的入口到出口的节点相符合的路径。
“Cyclomatic”来源于非直接连接基本测试周期的数目，更重要的是，也通过直接相连的图表给出独立路径的数目。通过图表的相关性，一个节点可到达另一个节点。
圈复杂度度量也可作为模块基本流程图路径的数目，其重点在于模块线形组合后，所产生的路径数目是最小的。
对圈复杂度的限制
现在有许多好方法可以用来限制圈复杂度。过于复杂的模块容易出错，难于理解、测试、更正，所以应当在软件开发的各个阶段有意识地限制复杂度，许多开发者已经成功地实现把对软件复杂度的限制作为软件项目的一部分，尽管在确切的数目上略微有些争议。最初支持的数目是10，现在支持数目可达15。但是，只应当在条件较好的情况下使数目大于10，例如开发者非常有经验，设计合乎正式标准，使用现代化的程序语言、结构程序、代码预排和先进的测试计划。换句话说，开发团队可以选择超过10的限制数目，但是必须根据经验进行一些取舍，把精力花在比较复杂的模块上。基本复杂度是用来衡量程序非结构化程度的，非结构成分降低了程序的质量，增加了代码的维护难度，使程序难于理解。因此，基本复杂度高意味着非结构化程度高，难以模块化和维护。实际上，消除了一个错误有时会引起其他的错误。
计算方法
将圈复杂度图中的结构化部分简化成一个点，计算简化以后流程图的圈复杂度就是基本复杂度。
优点
衡量非结构化程度；反映代码的质量；预测代码维护量，辅助模块划分；与所用的高级程序设计语言类型无关。
应用
当基本复杂度为1，这个模块是充分结构化的；当基本复杂度大于1而小于圈复杂度，这个模块是部分结构化的；当基本复杂度等于圈复杂度，这个模块是完全非结构化的。
Module Design Complexity (iv(G))模块设计复杂度
模块设计复杂度是用来衡量模块判定结构，即模块和其他模块的调用关系。软件模块设计复杂度高意味模块耦合度高，这将导致模块难于隔离、维护和复用。
计算方法
模块设计复杂度是从模块流程图中移去那些不包含调用子模块的判定和循环结构后得出的圈复杂度，因此模块设计复杂度不能大于圈复杂度，通常是远小于圈复杂度。
优点
衡量模块对其下层模块的支配作用；衡量一个模块到其子模块进行集成测试的最小数量；定位可能多余的代码；以复杂的计算逻辑和设计来区分模块；是设计复杂度（S0）和集成复杂度(S1)计算的基础；与所用的高级程序设计语言类型无关。设计复杂度以数量来衡量程序模块之间的相互作用关系，它提供了系统级模块设计复杂度的概况，有助于衡量进行自底向上集成测试的效果，而且提供了全面衡量程序设计规格和复杂度的数据，不反映独立模块的内部情况。高设计复杂度的系统意味着系统各部分之间有着复杂的相互关系，这样系统将难以维护。
S0是程序中所有模块设计复杂度之和，计算公式如下：
优点
可应用于完整的软件，也可应用于任何子系统；衡量代码的质量；指出一个模块整体的复杂度，反映了每个模块和其内部模块的控制关系；揭示了程序中模块调用的复杂度；有助于集成复杂度的计算。集成复杂度是为了防止错误所必须进行的集成测试的数量表示，另一种说法是程序中独立线性子树的数目，一棵子树是一个有返回的调用序列。就像圈复杂度是测试路径的数目，而集成复杂度是程序或其子系统的独立线性子树。
计算方法
一个程序的集成复杂度和一个模块的圈复杂度是非常相似的，必须计算对程序进行完全测试所需集成测试的数目。S1的计算公式：
S1=S0-N+1
N是程序中模块的数目。
优点
有助于集成测试的实施；量化集成测试工作且反映了系统设计复杂度；有助于从整体上隔离系统复杂度。
Number of Lines (nl)行数
行数是模块中总的行数，包括代码和注释。
优点：
计算简单；与所用的高级程序设计语言类型无关；指出了模块的行数（即模块的规模），规模小的模块易于理解和维护。规范化复杂度是圈复杂度除以行数。
计算方法
nv=v(G)/nl
优点
与所用的高级程序设计语言类型无关；定义那些有着显著判定逻辑密度的模块，这些模块相对于其他常见规范模块需要做更多的维护工作。全局数据复杂度（需有McCabe Data）量化了模块结构和全局数据变量的关系，它说明了模块对外部数据的依赖程度，同时度量了全局数据的测试工作，也描述了模块之间的耦合关系，能反映潜在的维护问题。
对于如何跟踪全局数据使用情况的更多信息，可以参考《McCabe Data in Using McCabe IQ Add-Ons》。局部数据复杂度（需有McCabe Data）量化了模块结构和用户局部数据变量的关系，同时度量了局部数据的测试工作。
我们能够使用McCabe Data的数据字典选择单独的数据元素，指出每个数据元素具体的数据类型。局部数据复杂度还提供了其他的数据选择准则，量化了每个模块中相应数据对模块控制结构的影响。
关于数据字典的更多信息，参考文档《McCabe Data in Using McCabe IQ Add-Ons.》。病态数据复杂度衡量一个模块包含的完全非结构化成份的程度，标出向循环内部跳入的问题代码，而这些部分具有最大的风险度，通常需要重新设计。
计算方法
所有的非结构部分除去向循环内跳入的结构，转化为线结构，病态复杂度就等于简化以后流程图的圈复杂度。
优点
与所用的高级程序设计语言类型无关；指出了可靠性的问题，降低了维护风险；帮助识别极不可靠的软件。
（Halstead 复杂度）
McCabe QA能够为所选择的语言产生Halstead Metrics复杂度。Halstead复杂度是以程序中出现的运算符和运算元为计数对象，以它们出现的次数作为计数目标（直接测量指标），然后据以计算出程序容量、工作量。
优点
不要求对程序结构进行深层次分析；能够预测错误率；预测维护工作量；有利于项目规划，衡量所有程序的复杂度；计算方法简单；与所用的高级程序设计语言类型无关；众多研究结构研究表明Halstead复杂度对于预测程序工作计划和程序的Bug非常有用。
Line Count复杂度描述了Line Count复杂度并列出了它们的优点
Line Count Metrics（Line Count复杂度）
优点
软件物理规模的度量；定义了具体的Line Count数据，例如注释行和空行；协助指出难于理解的模块。

软件测试的特性

o 测试是不完全的(测试不完全)
很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有 逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我 们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃 至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一 条必经之道。
o 测试具有免疫性(软件缺陷免疫性)
软件缺陷与病毒一样具有可怕的“免疫性”，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率 论我们可以推出这一结论。假设一个50000行的程序中有500个软件缺陷并且这些软件错误分布时均匀的，则每100行可以找到一个软件缺陷。我们假设测 试人员用某种方法花在查找软件缺陷的精力为X小时/100行。照此推算，软件存在500个缺陷时，我们查找一个软件缺陷需要X小时，当软件只存在5个错误 时，我们每查找一个软件缺陷需要100X小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明 了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。
o 测试是“泛型概念”(全程测试)
软件测试不仅仅存在于程序编写完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大 效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ”。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一 个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试 本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。
o 80-20原则
80%的软件缺陷常常生存在软件20%的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发“地段”。在那 里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而 愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免80%的软件缺陷，此后 的系统测试能够帮助我们找出剩余缺陷中的80%，最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试 只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。
80-20原则还能反映到软件测试的自动化方面上来，实践证明80%的软件缺陷可以借助人工测试而发现，20%的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。
o 为效益而测试
为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件 测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价 值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化。
o 缺陷的必然性
软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的 软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何 况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折 中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。
o 软件测试必须有预期结果
没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期 的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的 东西作为正确的结果来判断，因此常常出现误测的现象。
o 软件测试的意义——事后分析
软件测试的目的单单是发现缺陷这么简单吗？如果是“是”的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得 好，“不知道历史的人必然会重蹈覆辙”。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力 和物力来再次查找软件缺陷。

软件测试原则第一条完全测试不可能。理由？解决办法?

理由？
好吧、我们就用一个输入密码框来说好了(就用你的银行卡密码来说、必须是6位的数字密码)
如果你要完成测试你可以想象一下需要输入多少次 才能把所有的可能都测试完成？ 基本上完不成的
互联网上软件有密码是只能是6位数字的么、没有吧。最少都是是数字或者英文字母、而且是没固定只能6位、好了问题来了、基本上是没有希望吧所有的情况都输入一次的
解决办法：
目前就是用边界值和等价类2种方式来编写用例减少输入
比如：密码框要求输入 6-16位数字、那么最少要测试5位6位 16位和17位的数字密码

软件工程的复杂性是指什么？ A程序复杂B问题复杂C控制复杂D数据复杂，这是一道选择题，求助啊

软件工程的复杂性是指程序复杂。

复杂性是指理解和处理软件的难易程度。是用来衡量程序非结构化程度的一个标准，非结构成分降低了程序的质量，增加了代码的维护难度，使程序难于理解。因此，复杂性高意味着非结构化程度高，难以模块化和维护。实际上，消除了一个错误有时会引起其他的错误。

扩展资料：

在软件设计中，有一条基本原则“简单就是可靠”。与功能的增多或增强相伴的是不断升级与补丁。已经有若干种软件复杂性的度量方法可供参考，其中McCabe QA是比较出色和实用的方法，它能够计算出多种软件复杂性，由此可对软件进行检查、分析和查明那些可能导致错误的代码。

复杂性的优点是能衡量非结构化程度，反映代码的质量，预测代码维护量，辅助模块划分，与所用的高级程序设计语言类型无关。

软件测试学习难度大吗？

软件测试课程其实并不难学，但是这是建立在有专业老师指导下的。如果自学的话，难度还是不小的，而且也没有测试的系统和平台，没有办法进行实操练习。建议去【达内教育】学习，该机构与多家企业签订人才培养协议，全民助力学员更好就业。感兴趣的话点击此处，免费学习一下
现在国内的软件测试人才缺口达到30-40万，与开发人数比为1:4，而在国外能达到1:1，随着互联网产品的迭代更新，产品更新周期缩短，各种复杂性功能不断出现，面对这样的发展现状，传统的功能测试已经不能够满足企业的测试需求，所以需要技术水平更全面一些的【测试开发工程师】，但是由于我国目前还没有专门培养这方面人才的渠道，所以目前呈现供不应求的状态，企业的招聘数量可是一说是呈现直线上升的趋势。
想了解更多有关软件测试课程的相关信息，推荐咨询【达内教育】。该机构致力于面向IT互联网行业，培养软件开发工程师、测试工程师、UI设计师、网络营销工程师、会计等职场人才，拥有行业内完善的教研团队，强大的师资力量，确保学员利益，全方位保障学员学习；更是与多家企业签订人才培养协议，全面助力学员更好就业。达内IT培训机构,试听名额限时抢购。

软件测试java类圈复杂度是什么意思

圈复杂度(Cyclomatic Complexity)是一种代码复杂度的衡量标准。它可以用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数，也可理解为覆盖所有的可能情况最少使用的测试用例数。圈复杂度大说明程序代码的判断逻辑复杂，可能质量低且难于测试和维护。程序的可能错误和高的圈复杂度有着很大关系。
两个方法是指类里面有两个函数对吧?!
是的
是要有4个elseif语句么?
不是的，但是如果你写成嵌套的四个else if，那么圈复杂度肯定超过4，圈复杂度的计算用很多工具可以辅助完成，比如eclipse metrics,java ncss等。
人工计算圈复杂度比较复杂，限于篇幅无法详细介绍，网上相关介绍很多，可以直接baidu检索

软件测试要在编程完成后才能开始，这种观点对吗

这种观点是不正确的，软件测试的原则之一就是尽早介入，就是在项目开始的时候软件测试人员就要参加进来。对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多。

可对软件测试起到一定帮助。因软件测试因此类因素具有一定程度的免疫性。测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效。

扩展资料：

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。

参考资料来源：百度百科-软件测试

关于软件复杂度的复杂度的种类的介绍就到这里，以上就是小编整理的软件复杂度的复杂度的种类全部内容了，欢迎大家留言讨论。访问学分高考了解更多相关内容（本文共9381字）