软件总代码行数_软件注释率_分析
软件测试报告

XX软件测试报告1 范围本文档适用于XX软件的单元/集成测试..1.2 系统概述1.3 文档概述本文档用于对XX软件的测试工作阶段成果的描述..包括对软件测试的整体描述;软件测试的分类和级别;软件测试的过程描述;软件测试的结果等内容..2 引用文档《XX软件需求规格说明》《XX软件设计说明》《XX系统接口协议》3 测试概述3.1被测软件的基本概况使用的编程语言:XXX 汇编语言程序行数:1590子程序个数:11单行注释行数:669注释率:约为42%3.1.1. 测试小结本次测试对XX软件进行了静态分析和动态测试..测试工作分为两个阶段..第一阶段进行了软件静态分析;软件测试人员和开发人员分别对软件V1.00版本的代码进行走读..在此基础上软件开发人员对代码走查中发现的问题进行了修改;做了97处代码变更并提交了V1.01版本进行动态测试..在测试过程中针对发现的软件缺陷进行了初步分析;并提交程序设计人员对原软件中可能存在的问题进行考查..在软件测试中首先根据软件测试的规范进行考核;将书写规范;注释等基础问题首先解决;其次考核软件测试中的问题是否存在设计上的逻辑缺陷;如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障..软件开发人员在以上基础上对软件的不足做出相应的修改;同时通过软件回归测试验证软件修改后能够得到的改善结果..从上表可以看出;注释变更一共有15处;主要排除了对原程序的理解错误问题;根据程序的书写规范要求;一行多条语句改为一行一条语句的更改一共有42处;命令字大小写变更一共有7处;在代码走查中对冗余和无用的代码作了更改;将这些代码注释掉;此类更改一共有14处..上述4类更改一共有78处;这些更改对程序本身的功能没有任何影响;但从软件规范的角度来看提高了程序的可读性和规范性..其余19处变更为代码变更;主要是在软件测试中发现原程序的可靠性不足;在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性..在动态测试阶段进行了单元测试和集成测试..此阶段发现的软件问题经软件测试人员修改;提交了V1.02版本;软件测试人员对此版本的软件代码进行了回归测试;确认对前阶段发现的软件问题进行了修改;消除了原有的软件问题并且确认没有引入新的软件问题..认定V1.02版为可以发行的软件版本..3.1.1.1 静态分析小结静态测试采用人工代码走查的方式进行..参加代码走查的软件开发人员有:略;参加代码走查的软件测试人员有:略..代码走查以代码审查会议的形式进行..静态分析过程中共进行了四次会议审查..静态测试阶段的主要工作内容是:●根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图见附件1;●对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析;●对软件汇编源代码进行编程规范化分析..通过静态测试查找出软件的缺陷18个;其中轻微的缺陷4个;占所有缺陷的22.2%中等的缺陷11个;占所有缺陷的61.1%严重的缺陷:3个;占所有缺陷的16.7%上述软件缺陷见附件《软件问题报告单》3.1.1.2 动态测试小结动态测试使用的测试工具为XXX软件集成开发环境..总共的测试用例数:143个..全部由测试人员人工设计..其中单元测试用例138个;集成测试用例5个..发现的软件缺陷有2个;都是在单元测试过程中发现的..集成测试阶段未发现新的软件缺陷..在发现的软件缺陷中:中等的缺陷1个;占所有缺陷的50%严重的缺陷1个;占所有缺陷的50%上述软件缺陷见附件《软件问题报告单》动态测试中代码覆盖率:代码行覆盖率100%分支覆盖率100%程序单元调用覆盖率100%3.1.1.3 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改;并对更改后的代码进行了回归测试..本报告中的数据是回归测试后的测试数据..3.1.1.4 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析..1.静态测试中的缺陷分析:1)4个轻微缺陷属于代码冗余;由于在程序设计中加入了部分调试程序;在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余;但对程序本身的功能并无影响..修改后程序的效率得到提高..2)11个中等缺陷属于注释变更;在原程序代码的注释中存在注释不准确的问题;会影响程序员对程序的理解;修改后的程序提高了程序的可读性..3)重点分析3个严重缺陷:第一个严重缺陷属于XX号的无效判别和相应的处理问题;程序对XX号进行无效判别时;判别界限并不完全;在本跟踪程序中XX号的有效数为01-10用4位表示;而判别无效时只判了为00的情况;没有判别大于10的情况..而且在为00时也没有作相应的处理;修改后的程序对设计进行了改进;详见改进设计分析3..第二个严重缺陷属于程序设计中读取地址错误问题;经分析在调试中读取的数据是正确的;但是读取的地址与设计初衷不相符;修改后问题得到了解决;详见改进设计分析1..第三个严重错误是近区/远区子程序判断与进入条件反了;经分析对程序的影响不大;但与设计初衷不一致;修改后问题得到了解决;详见改进设计5..2.动态测试中的缺陷分析:1)中等缺陷1个;在程序的注释中出现错误;将近区注释为远区;修改后问题得到了解决;提高了程序的可读性..2)严重缺陷1个;在XX号无效的判别中;本应判断大于10;但误设计为0;修改后经回归测试问题得到了解决..3.改进的设计分析:因和产品相关;略3.1.2 测试记录a 测试时间:2005年8月5日至2005年9月17日..b 地点:略..c 硬件配置:P4CPU/2.0G;内存256M;硬盘1Gd 软件配置:Wondows 98;e 被测软件版本号:V1.0;V1.01;V1.02f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档..4 测试结果在两个阶段测试过程中共发现软件缺陷20个;经软件开发人员确认的缺陷为20个;经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试..因测试条件所限;未能进行软件的确认测试和系统测试..5 评估和建议5.1 软件评估5.1.1 软件编码规范化评估经过回归测试;未残留的软件编码规范性缺陷..软件代码文本注释率约为42%;代码注释充分;有利与代码的理解和维护..5.1.2软件动态测试评估被测软件单元的总数:11个使用的测试用例个数:143个达到软件测试出口准则的软件单元数为11个;通过率100%通过单元和集成测试得知:软件代码逻辑清晰、结构合理、程序单元间接口关系一致;运行稳定..5.2 改进建议a. 建议在软件开发项目中全面实施软件工程化;加强软件开发的管理工作..b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化..特别是应该将系统中的硬件研制和软件研制分别管理;软件文档编制的种类和规格按照相关标准执行..c. 尽早开展软件测试工作..在软件研制计划安排上给软件测试留有必要的时间;在资源配置上给软件测试必要的支撑..d.建议结合系统联试;开展软件的确认和系统测试..附件:软件问题报告单略软件更改通知单略软件测试记录略。
软件质量度量如何评估软件的质量

软件质量度量如何评估软件的质量软件的质量对于任何一个软件项目来说都是至关重要的。
而在软件开发生命周期的各个阶段,软件质量度量是评估软件质量的重要手段之一。
本文将从软件质量的定义入手,介绍软件质量度量的概念、方法和一些常用的度量指标,以帮助读者更好地评估和提升软件的质量。
一、软件质量的定义软件质量是指软件产品或系统在满足特定需求的同时,具备一定的可靠性、可用性、可维护性、可移植性、可测试性等特性。
软件质量度量旨在量化和评估这些特性,以确定软件的功能完整性、性能、可靠性、安全性等方面的质量水平。
二、软件质量度量的概念软件质量度量是指通过收集、分析和解释一系列相关数据,对软件产品或系统的特定特征进行量化评估的过程。
度量的结果可以帮助开发团队和管理层了解软件的质量状况,从而及时采取改进措施。
在软件开发过程中,常用的软件质量度量方法包括静态度量和动态度量。
静态度量主要基于文档或代码的特征,如代码行数、注释比例、代码复杂度等;而动态度量则基于软件运行过程中的性能指标、异常处理情况、系统可用性等。
三、常用的软件质量度量指标1. 功能完整性在评估软件的功能完整性时,可以考虑以下度量指标:- 功能点计算:通过对软件的功能进行分类和赋值,计算出软件的功能点数,是一种常用的度量软件规模的方法;- 业务规则覆盖率:统计每个业务规则在测试用例中的覆盖率,以了解软件的功能是否能够满足实际需求。
2. 性能在评估软件的性能时,可以考虑以下度量指标:- 响应时间:记录用户发送请求后,系统返回响应的时间长度,用于评估系统的响应速度;- 并发性能:通过模拟多个用户同时对系统发起请求,并测量系统的处理能力,评估系统能否承受多用户并发访问;- 吞吐量:表示单位时间内系统能够处理的请求或事务数量,用于评估系统的处理能力。
3. 可靠性在评估软件的可靠性时,可以考虑以下度量指标:- 故障率:记录软件在一定时间内出现的故障次数,用于评估软件的稳定性和可靠性;- 可恢复性:评估软件在出现故障后的恢复能力,包括故障检测、故障诊断和故障恢复等方面。
软件开发中的编码规范和代码注释规范

软件开发中的编码规范和代码注释规范软件开发中的编码规范和代码注释规范随着计算机技术的不断发展,软件开发作为一门重要的技术也越来越受到人们的关注。
而在软件开发的过程中,编码规范和代码注释规范是非常重要的一环。
编码规范和代码注释规范的标准化不仅可以提高代码的可读性和可维护性,而且可以使得多人协同开发更加得心应手。
本文将从编码规范和代码注释规范两个方面来探讨其在软件开发中的重要性及应用方法。
一、编码规范编码规范是指在软件开发中制定的一套规定,用于规范代码的书写方式。
有了编码规范,开发人员可以更加高效地、统一地编写代码,从而降低开发过程中的错误率,节省时间和精力。
编码规范需要对一些书写细节进行标准化规范,下面我们来看一些常见的规范。
1.命名规范命名规范是指在命名变量、函数和类时的规则。
通常来说,命名应该反映变量、函数或类的作用和含义,应该采用有意义的词语,同时应该符合语言的命名规范,例如:1)变量名应该是一个名词,采用小写字母和下划线组成,如student_name。
2)函数名应该是一个动词,采用小写字母和下划线组成,如get_student_name。
3)类名应该是一个名词,采用大写字母开头的驼峰命名法,如StudentInfo。
2.注释规范注释规范是指在代码中添加注释,以便于代码的阅读和维护。
在注释时应该注意以下几点:1)注释应该使用简洁、明了的语言。
2)注释应该放在代码的上面或者右侧,而不是内嵌在代码中。
3)注释应该尽可能地详细描述代码的作用和逻辑,尤其是一些复杂的代码片段。
3.缩进规范缩进规范是指在编写代码时,应该按照一定的规则对代码进行缩进,以便于代码的可读性和可维护性。
通常来说,缩进应该按照以下原则进行:1)应该采用4个空格的缩进。
2)每个代码块应该有单独的缩进级别。
3)缩进应该注意对齐和排列方式。
二、代码注释规范在编写代码的同时,代码注释也是很重要的一环。
代码注释可以帮助其他人更好地理解代码和维护代码,在注释的时候应该遵循以下规范:1.注释类型通常来说,代码注释可以分为两种类型:行注释和块注释。
软考中项计算题公式

软考中项计算题公式软考中的计算题公式软考是指软件职业资格考试,是由中国电子学会主办的一项全国性的技术职业资格认证考试。
其中,项计算题是软考中的一种题型,要求考生掌握各个领域的计算公式。
本文将介绍软考中项计算题常见的公式。
1. 网络技术计算公式1.1 带宽计算公式带宽(kbps) = 8 * 带宽(bps)其中,带宽为bit/s,可通过将其转换为kbps来方便计算。
1.2 时延计算公式时延(s) = 数据长度 / 带宽其中,数据长度以bit为单位,时延以秒为单位。
2. 数据库计算公式2.1 总记录数计算公式总记录数 = (平均记录长度 * 块长度) / (块内记录长度)其中,平均记录长度为每条记录的平均长度,块长度为块的大小,块内记录长度为每个记录在块中占据的空间。
节点数 = 总记录数 / 每个节点的最大键数其中,总记录数为数据库中的总记录数,每个节点的最大键数为树节点中能够包含的最大键的数量。
3. 软件工程计算公式3.1 代码行数计算公式代码行数 = 注释行数 + 空白行数 + 有效代码行数其中,注释行数为代码中的注释行数,空白行数为代码中的空行数,有效代码行数为代码中的实际执行代码行数。
3.2 平均构造率计算公式平均构造率 = 实际构造率 / 理想构造率其中,实际构造率为实际构造的代码行数占全部代码行数的比例,理想构造率为按照预估时间应该构造的代码行数占全部代码行数的比例。
4. 操作系统计算公式4.1 磁盘存储容量计算公式存储容量 = 磁道数 * 每条磁道的扇区数 * 每个扇区的字节数其中,磁道数为磁盘上的磁道数量,每条磁道的扇区数为每个磁道上的扇区数量,每个扇区的字节数为每个扇区上可存储的字节数。
页面引用串长度 = 总访问命令数 * 每个命令访问的页面数其中,总访问命令数为对页面的总访问命令数量,每个命令访问的页面数为每个访问命令需要访问的页面数量。
以上是软考中项计算题常见的公式,掌握这些公式能够帮助考生在考试中更好地解决计算题。
软工常用公式

软工常用公式软件工程是一门关于开发、维护和测试软件的学科,其中常常涉及到一些公式来帮助工程师解决问题或进行计算。
本文将介绍几个软工常用公式,包括软件度量、效能评估和项目管理方面的公式。
一、软件度量1. 代码行数(LOC, Lines of Code)LOC公式用于衡量软件开发中源代码的规模。
它可以用来评估项目的工作量和代码质量。
LOC = (源代码的总行数) - (空行数 + 注释行数)例如,一个软件项目总共有1000行源代码,其中有200行是空行,100行是注释行,则该项目的LOC为700行。
2. 原始缺陷密度(D, Defect Density)原始缺陷密度公式用于衡量软件开发过程中发现的缺陷数量与代码规模之间的关系,以评估软件的质量。
D = (项目中发现的总缺陷数) / LOC例如,一个软件项目总共发现了50个缺陷,而代码规模为1000行,则该项目的原始缺陷密度为0.05。
二、效能评估1. 可靠性(R, Reliability)可靠性公式用于评估软件系统的可靠程度,即系统正常运行的概率。
R = (系统正常运行时间) / (系统正常运行时间 + 系统故障时间)例如,一个软件系统正常运行了1000小时,而发生故障的时间为200小时,则该系统的可靠性为0.833。
2. 故障密度(FD, Failure Density)故障密度公式用于衡量单位时间内发生的故障数量,以评估软件的健壮程度。
FD = (系统故障次数) / (系统正常运行时间 + 系统故障时间)例如,一个软件系统在1000小时内发生了10次故障,其中系统正常运行时间为800小时,则该系统的故障密度为0.01。
三、项目管理1. 进度偏差(SD, Schedule Deviation)进度偏差公式用于衡量项目进度实际完成情况与计划完成情况之间的差异。
SD = (实际完成时间) - (计划完成时间)例如,一个项目计划在10天内完成,但实际上需要了12天才能完成,则该项目的进度偏差为2天。
软件工程中的软件度量与评估方法

软件工程中的软件度量与评估方法在软件工程领域,软件度量和评估是非常重要的环节。
软件度量是指对软件开发过程和软件产品进行量化和衡量的方法,而软件评估则是对软件度量结果进行分析和判断的过程。
本文将介绍软件工程中常用的软件度量和评估方法,并探讨其在软件开发中的应用。
一、软件度量方法1. 静态度量方法静态度量方法主要通过对软件文档、源代码和设计模型等进行分析,来评估软件的质量和复杂度。
其中,代码行数、注释行数和空行数等是常用的度量指标。
通过统计这些指标,可以了解软件的规模和复杂性,以便进行进一步的分析和评估。
2. 动态度量方法动态度量方法主要通过对软件运行时的行为进行观察和分析,来评估软件的性能和可靠性。
常用的动态度量指标包括代码覆盖率、执行时间和内存占用等。
通过对这些指标的测量,可以了解软件在不同条件下的运行情况,从而优化软件的性能和可靠性。
3. 结构度量方法结构度量方法主要通过对软件的结构进行分析,来评估软件的模块化程度和可维护性。
常用的结构度量指标包括模块间的耦合度、模块内的内聚度和代码的复杂度等。
通过对这些指标的测量,可以了解软件的结构是否合理,从而提高软件的可维护性和可扩展性。
二、软件评估方法1. 静态评估方法静态评估方法主要通过对软件文档、源代码和设计模型等进行分析和检查,来评估软件的质量和符合性。
常用的静态评估方法包括代码审查、软件质量度量和软件质量模型等。
通过这些方法,可以发现和修复软件中的潜在问题,提高软件的质量和可靠性。
2. 动态评估方法动态评估方法主要通过对软件运行时的行为进行观察和分析,来评估软件的性能和可靠性。
常用的动态评估方法包括性能测试、压力测试和安全测试等。
通过这些方法,可以了解软件在不同条件下的运行情况,从而优化软件的性能和可靠性。
3. 用户评估方法用户评估方法主要通过对软件用户的反馈和需求进行收集和分析,来评估软件的用户满意度和可用性。
常用的用户评估方法包括用户调研、用户体验测试和用户反馈分析等。
5 个常用的软件质量指标

5 个常用的软件质量指标在软件开发中,软件质量是衡量软件是否符合需求、标准的重要体现。
除了代码质量外,影响软件整体质量的因素还有很多。
因此,要确保软件的整体质量,就需要在各个环节严格控制。
本文列出了衡量软件质量的5个最常用的指标。
1、SLOC(Source Lines of Code,源代码行)计算代码行数可能是最简单的衡量指标,主要体现了软件的规模,并为项目增长和规划提供了相关数据。
例如,如果每月统计一次代码的行数,就可以绘制一个项目发展概览图。
当然,由于存在项目重构或是设计阶段等因素,这种方式并不太可靠,但是可以为项目的发展提供一个视角。
可以只统计逻辑代码行(Source Logical Line of Code,SLLOC),这样可以获得稍准确的信息。
逻辑代码行不包含空行、单个括号行和注释行。
可以使用Metrics 工具来统计。
代码行数不应该用来评估开发者的效率,否则,可能会产生重复、不可维护的或不专业的代码。
2、每个代码段/模块/时间段中的bug数要想实现更好的测试以及更高的可维护性,bug 跟踪是必不可少的。
每个代码段、模块或时间段(天、周、月等)内的 bug 可以很容易通过工具统计出来(如 Mantis)。
这样,可以及早发现并及时修复。
Bug 数可以作为评估开发者效率的指标之一,但必须注意,如果过分强调这种评估方法,软件开发者和测试者可能会成为敌人。
在生产企业中,要保证员工彼此之间的凝聚力。
为了更好的实现评估,可以根据重要性和解决成本将 bug 划分为低、中、高三个级别。
3、代码覆盖率在单元测试阶段,代码覆盖率常常被拿来作为衡量测试好坏的指标,也用来考核测试任务完成情况。
可以使用的工具也有很多,如 Cobertura 等。
代码覆盖率并不能代表单元测试的整体质量,但可以提供一些测试覆盖率相关的信息,可以和其他一些测试指标一起来使用。
此外,在查看代码覆盖率时,还需注意单元测试代码、集成测试场景和结果等。
软件技术指标和参数

10. 测试覆盖率: • 测试覆盖率表示测试用例覆盖代码的百分比,是衡量测试质量的一个指 标。
11. 版本控制指标: • 这包括版本历史、提交频率、分支管理等,用于衡量代码的变更和演进。
6. 安全性: • 软件安全性是一个关键指标,涉及到对抗潜在的威胁和保护用户数据的能 力。
7. 可靠性: • 可靠性衡量软件在特定条件下执行任务的能力,通常通过软件的错误率和 稳定性来衡量。
8. 可扩展性: • 可扩展性指软件在应对不断执行时间和性能: • 软件执行时间和性能是衡量软件运行效率的关键参数。这包括响应时间、 吞吐量和资源利用率等。
4. 内存占用: • 内存占用是指软件在运行时占用计算机内存的大小,对于资源受限的环境 尤为重要。
5. 可维护性: • 可维护性衡量软件易于理解、修改和维护的程度,涉及到代码的结构、注 释、文档等因素。
在软件开发和计算机科学领域,有许多技术指标和参数,用于评估和衡量软件的 性能、质量和其他方面。以下是一些常见的软件技术指标和参数:
1. 代码行数(Lines of Code,LOC): • 代码行数是衡量软件规模的一种指标,但它并不总是能够准确反映软件的 复杂性或质量。
2. 圈复杂度(Cyclomatic Complexity): • 圈复杂度是衡量代码复杂性的一种方法,它考虑了程序中的控制流结构的 数量和复杂性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
文档名称:软件总代码行数_软件注释率分析作者:日期:1. cncc1.1 工具简介度量工具名称cncc网址/操作方式命令行实现语言C++适用的操作系统Windows可以度量的属性code-lines, empty-lines, comment-lines, total-lines备注1.2 工具优缺点总结最新版本 cncc-1-3-1,在sourceforge中2004年已经停止更新。
最大的优点是源代码全部存于一个cpp文件,便于集成。
缺点:1.代码基本没有注释。
2.下载的代码编译有9个错误。
3.费了2个多小时也没搞定。
1.3 使用例程无。
2. CodeCount2.1 工具简介度量工具名称CodeCount网址/downloads421/sourcecode/windows/control/detail1783204.html操作方式GUI实现语言C++适用的操作系统Windows可以度量的属性total-lines, empty-lines, comment-lines, code-lines,备注2.2 工具优缺点总结优点:工具比较精简,统计源文件总行数、代码行数、空白行数、注释行数,代码有一定的注释。
缺点:下载的源码是vc7工程,由于机器并没有vc7,利用工具进行工程类型转换,将vc7的工程转换为vc6的工作,编译出错。
核心代码如下:BOOL bCommentSet = FALSE; //注释行统计标识有"/*"时TRUE, "*/"时FALSEBOOL bQuatoSet = FALSE; //字符串统计标识首次一行有奇数个"时TRUE, 下一行有奇数个"时FALSEint nLength = (int)file.GetLength();CString bufRead;int nLineCommentBegin = 0;while(file.ReadString(bufRead)!=FALSE){BOOL bStatedComment = FALSE;//本行作为注释行是否已统计过BOOL bStatedCode = FALSE; //本行作为代码行是否已统计过nLines++;bufRead.TrimLeft(); //先将文件头的空格或制表符去掉if(bufRead.GetLength()==0) //为空白行{nBlankLines++;continue;}if(bCommentSet && bufRead.Find(_T("*/"))==-1){nCommentLines++;continue;}if(bufRead.Find(_T("//"))==-1 && bufRead.Find(_T("/*"))==-1 &&bufRead.Find(_T("*/"))==-1){//如果本行根本就无注释符,则要不是注释符,要不是代码行if(bCommentSet){nCommentLines++; continue;}else{if(bufRead.Find('"')==-1){nCodeLines++; continue;}}}if(bufRead.Find(_T("//"))==0 && !bCommentSet && !bQuatoSet){nCommentLines++;continue;}BOOL bDoubleSplashFound = FALSE;BOOL bSplashStarFound = FALSE;for(int i=0; i<bufRead.GetLength()-1; i++){//char cTemp = bufRead[i];wchar_t cTemp = bufRead[i];if(bufRead[i]=='/' && bufRead[i+1]=='/' && !bCommentSet && !bQuatoSet){if(!bStatedComment && (m_nStatMethod==1 || m_nStatMethod ==2)){bStatedComment = TRUE;nCommentLines++;}bDoubleSplashFound = TRUE;//i++;//应该+1,但也没有什么用处break;}else if(bufRead[i]=='/' && bufRead[i+1]=='*' && !bCommentSet && !bQuatoSet) {if(!bStatedComment && (m_nStatMethod==1 || m_nStatMethod ==2)){bStatedComment = TRUE;nCommentLines++;}bCommentSet = TRUE;bSplashStarFound = TRUE;i++;}//计算代码行必须在bCommentSet关闭之前else if(bufRead[i]!=' ' && bufRead[i]!='\t' && !bCommentSet){if(!bStatedCode){bStatedCode = TRUE;nCodeLines++;}if(bufRead[i]=='\\'){//\之后的字符要跳过i++;continue;}if(bufRead[i]=='\''){if(bufRead[i+1]=='\\')i+=2;elsei+=1;continue;}if(bufRead[i]=='"'){//"必须引起重视,感谢ltzhoubQuatoSet = !bQuatoSet;}}else if(bufRead[i]=='*' && bufRead[i+1]=='/' && bCommentSet && !bQuatoSet){if(!bStatedComment && (m_nStatMethod==1 || m_nStatMethod ==2)){bStatedComment = TRUE;nCommentLines++;}bCommentSet = FALSE;bSplashStarFound = TRUE;i++;}}if(bDoubleSplashFound){if(m_nStatMethod==2 && bStatedCode) //如果统计方法为第三种,且同时有代码行与注释行,则只计注释行{nCodeLines--;}if(m_nStatMethod==0 && !bStatedCode)//如果统计方法为第一种,且未作为代码行统计过,那么必为注释行{nCommentLines++;}continue;}if(bufRead[bufRead.GetLength()-1]=='"'&&!bCommentSet){//若某行最后一个是",则必定用来关闭bQuatoSet,记代码行一行,否则报错bQuatoSet = !bQuatoSet;if(!bQuatoSet){if(!bStatedCode){bStatedCode = TRUE;nCodeLines++;}}else{CStdioFile fileLog;if(fileLog.Open(m_strLogFile,CFile::modeCreate|CFile::modeWrite|CFile::modeNoTruncate)==TRUE){CString strMsg;if(fileLog.GetLength()==0){strMsg.Format(_T("文件\t行\t问题\n"), strFileName, nLines);fileLog.WriteString(strMsg);}strMsg.Format(_T("%s\t%d\t字符串换行未用\\\n"), strFileName, nLines);fileLog.WriteString(strMsg);fileLog.Close();}}continue;}if(bufRead[bufRead.GetLength()-1]!=' ' && bufRead[bufRead.GetLength()-1]!='\t'&& !bCommentSet&& bufRead[bufRead.GetLength()-2]!='*' && bufRead[bufRead.GetLength()-1]!='/') {//如果最后一个字符非空格或制表符,且前面无/*,最后两个字符不是*/,则为代码行if(!bStatedCode){bStatedCode = TRUE;nCodeLines++;}}if(bSplashStarFound){if(m_nStatMethod==2 && bStatedCode) //如果统计方法为第三种,且同时有代码行与注释行,则只计注释行{nCodeLines--;}if(m_nStatMethod==0 && !bStatedCode && !bStatedComment) //若该行无代码如/*abc*/ //222//但是统计方法是第一种,则需要追加注释行计数一次{bStatedComment = TRUE;nCommentLines++;}}if(!bStatedComment && bCommentSet)//可能是前面有/*,在第一种统计方法中,未作为代码行计算过,那么本行肯定是注释行{if(m_nStatMethod==0 && !bStatedCode){bStatedComment = TRUE;nCommentLines++;}}if(bQuatoSet && bufRead[bufRead.GetLength()-1]!='\\'){CStdioFile fileLog;if(fileLog.Open(m_strLogFile,CFile::modeCreate|CFile::modeWrite|CFile::modeNoTruncate)==TRUE){CString strMsg;if(fileLog.GetLength()==0){strMsg.Format(_T("文件\t行\t问题\n"), strFileName, nLines);fileLog.WriteString(strMsg);}strMsg.Format(_T("%s\t%d\t字符串换行未用\\\n"), strFileName, nLines);fileLog.WriteString(strMsg);fileLog.Close();}}}file.Close();2.3 使用例程通过分析其源代码,抽取解析源文件部分的功能代码,构建独立的工程,经测试可以完成代码行等数据的统计工作,但仍需要进一步测试。