测试报告缺陷分析范文
时间：2024-01-24 18:06:46
导语：如何才能写好一篇测试报告缺陷分析，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
【关键词】软件测试 测试报告 测试流程
1 引言
软件测试是软件开发过程的重要组成部分，是用来确认一个产品的品质或性能是否符合开发之前所提出的要求。对软件需求分析、设计规格说明和编码的最终复审，某种程度上测试工作的好坏直接影响了软件产品的交付和用户的满意度。因此，如何做好测试工作，使测试在软件工程中顺利进行，辅助软件开发工作是我们每个软件人员应该考虑的问题。
2 软件测试的目的
（1）确认软件的质量，确认软件做了你所期望的事情，确认软件以正确的方式来做了这个事件。
（2）提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。
（3）软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。软件测试的第三个目的是保证整个软件开发过程是高质量的。
3 软件测试的对象
软件测试并不等于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。
4 软件测试流程
软件测试工作并不是在软件代码开发完毕后才开始的，这一点是很多软件人员的误区，需要明确一下，它其实是在项目进入软件实现阶段就开始了，项目进入软件实现阶段的时候，就应该启动软件测试工作了。
下面根据笔者的测试经验，详细阐述一下软件测试的流程、每个阶段需要做的工作及整个测试过程产生的文档。
4.1 计划与设计阶段
4.1.1 召开测试启动会议
当项目进入软件实现阶段（编码），测试经理召集项目经理、开发经理开会确定测试交接时间，开发团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划的可行性，统一项目组的目标和测试的工作重点。进行规模预估并成立测试团队，完成《测试计划》和《测试方案》。
4.1.2 设计测试用例
明确了测试需求和测试计划，在需求分析文档确立基线以后，测试组需要针对测试需求编写全部测试用例，在实际的测试中，测试用例将是唯一实施标准。
4.2 实施测试阶段
4.2.1 实施测试用例
实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础上。当测试用例全部编写完成后，测试工程师根据测试计划中分配给自己的测试任务，实施相应的测试用例，并记录测试结果。
4.2.2 填写测试记录
测试人员在进行具体的测试工作时，需要将测试内容填写在测试记录表中，直到所有的测试执行工作结束。
4.2.3 提交BUG清单
在具体的测试过程中，测试人员发现BUG后，需要将BUG记录在清单里，并及时提交给测试经理。
4.2.4 提交测试报告
在约定的测试周期完成之后，测试工程师需要总结此测试的结果，编写测试报告。测试工程师根据此轮测试的结果，编写测试报告，主要应包含以下内容：
（1）测试报告的版本。
（2）测试的人员和时间。
（3）测试所覆盖的缺陷――测试组在这轮测试中所有处理的缺陷， 不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向。
（4）上一版本活动缺陷的数量。
（5）经过此轮测试，所有活动缺陷的数量及其状态分类。
（6）测试评估――写明在这一版本中，哪些功能被实现了，哪些还没有实现，这里只需写明和上一版本不同之处即可。
（7）急待解决的问题――写明当前项目组中面临的最优先的问题，可以重复提出。
在每轮测试结束之后应尽快将符合标准的测试报告发给测试经理。
4.3 总结阶段
测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。
4.3.1 编写测试总结报告
在测试结束之后，测试经理编写测试报告，对测试进行总结，并且提交给项目经理，为产品的后续工作提供重要的信息支持。
测试经理根据测试的结果及测试工程师提交的测试报告编写测试总结报告，测试总结报告必须包含以下重要内容：
（1）测试资源概述―多少人、多长时间。
（2）测试结果摘要―分别描述各个测试需求的测试结果，产品实 现了哪些功能点，哪些还没有实现。
（3）缺陷分析―按照缺陷的属性分类进行分析。
（4）测试需求覆盖率―原先列举的测试需求的测试覆盖率，可能 一部分测试需求因为资源和优先级的因素没有进行测试，那么 在这里要进行说明。
（5）测试评估―从总体对项目质量进行评估。
（6）测试组建议―从测试组的角度为项目组提出工作建议。
4.3.2 测试验收
测试验收工作是在以上工作全部结束后，测试经理对测试的过程、效果进行验收，签发测试验收报告，宣布测试结束。由测试经理进行测试验收，验收内容包括：
（1）测试效果验收―测试是否达到预期目的。
（2）测试文档验收―测试过程文档是否齐全，符合标准。
（3）测试评估―从总体对测试的质量进行评估。
（4）测试建议―对本次测试工作指出不足，需要在以后工作中改 进的地方。
（5）宣布测试结束―测试组成员签字宣布本次测试结束。
4.3.3 测试归档
测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档，主要包括测试计划、测试用例、测试报告、验收报告等。这些文档的编写保障了测试的顺利进行，同时作为整个测试项目的痕迹，被保留下来，供查阅。
参考文献
[1]佟伟光.软件测试[M].北京：人民邮电出版，2008.
[2]Rex Black.测试流程管理[M].北京：北京大学出版社，2001.
[3]Robert V.Binder著，华庆一等译.面向对象系统的测试[M].北京：人民邮电出版社，2001.
[4]Mark Fewster， Dorothy Graham著，舒智勇等译.软件测试自动化技术与实例详解[M].北京：电子工业出版社，2000.
[5]Karl E.Wiegers著，陆丽娜，王忠民，王志敏译.软件需求[M].北京：机械工业出版社，2000.
篇2
两年以上工作经验|男|27岁（1989年12月11日）
居住地：北京
电 话：135*******（手机）
E-mail：
最近工作[1年7个月]
公 司：XX有限公司
行 业：互联网/电子商务
职 位：系统测试工程师
最高学历
学 历：本科
专 业：计算机科学与技术
学 校：北京农学院
自我评价
本人自中学开始就养成凡事应该从基层做起，并且不能把自己的能力定位过高的性格习惯，所以我在校期间无论从事什么工作都是从基层做起，尽量把工作约束在自己的能力之内，脚踏实地的工作。但只要有机会，我一样会进行更高的尝试，让自己的能力继续升级。
求职意向
到岗时间：可随时到岗
工作性质：全职
希望行业：互联网/电子商务
目标地点：北京
期望月薪：面议/月
目标职能：系统测试工程师
工作经验
2013/10 – 2015/5：XX有限公司[1年7个月]
所属行业：互联网/电子商务
集成部
系统测试工程师
1.熟悉软件测试理论、流程和方法，有较强的逻辑分析能力、测试用例设计能力。
2.能根据系统业务需求独立完成测试用例设计、执行，缺陷跟踪，风险分析，并根据结果执行回归测试，分析测试结果，撰写测试报告。
3.能从多角度考虑模块设计的完备性，灵活性，可扩展性，并提出改进建议。
2012/6 – 2013/9：XX有限公司[1年3个月]
所属行业：互联网/电子商务
集成部
系统测试工程师
1.熟悉软件测试理论、流程和方法，有较强的逻辑分析能力、测试用例设计能力。
2.能根据系统业务需求独立完成测试用例设计、执行，缺陷跟踪，风险分析，并根据结果执行回归测试，分析测试结果，撰写测试报告。
3.能从多角度考虑模块设计的完备性，灵活性，可扩展性，并提出改进建议。
教育经历
2008/8— 2012/6 北京农学院 计算机科学与技术 本科
证书
2009/12 大学英语四级
篇3
1 简介
1.1 范围
测试用例的执行覆盖高原夏菜无公害胡萝卜栽培管理专家系统、日光温室黄瓜无公害栽培管理专家系统、特色产业决策系统（绵花产业）、特色产业决策系统（绵花羊产业）等。
系统测试自2011年9月7日起对系统的功能及业务流程、界面风格、安全访问控制等进行了黑盒测试，对系统的用户使用数、页面性能要求进行了相应的性能测试。
1.2 定义、首字母缩写词和缩略语
EXP 为特色产业专家系统与决策支持系统的英文简写。
1.3 概述
本测试评估从功能测试和性能测试的两个角度来对我省特色产业专家系统与决策支持系统进行评估。内容主要包括：基于需求的测试覆盖、建议的措施以及相关的测试结果图示说明。
2 测试设备
PC1：硬件 CPU：PIV 1.50G，内存：512M硬盘：40G，软件：Winserver 2003/IE8.0；
PC2：硬件 CPU：PIV 2G，内存：2G硬盘：300 G，软件Winxpsp2 Winserver 2003/IE8.0。
3 测试环境
3.1 硬件配置
Web服务器硬件配置：TOMCAT服务器，CPU：PIV2.80，内存：1 G；硬盘：300 G；网卡：10/100 M自适应。
数据库服务器硬件配置：PC台式机，CPU：P43G，内存：1 G；硬盘：300 G；网卡：10/100 M自适应。
3.2 软件配置
服务器软件配置：开发工具：IBMWSAD5.0；JDK环境：j2se1.5或更高；
系统环境：Windows 2000/XP/2003；
Web服务器：Apache 2.4+tomcat6.0
数据库系统：SERVER 2008。
3.3 测试方法
以黑盒测试为主，测试的重点集中在业务流程、数据提取和各功能模块间的接口。其中单元测试由开发人员直接完成；功能模块采用黑盒测试的常用方法；集成测试模块采用非渐增式测试，偏重系统的接口和数据提取方面；系统测试主要体现在业务流程的测试，主要采用回归测试。包括数据测试、功能测试、用户界面测试、性能评测、安全性和访问控制测试。
4 测试覆盖分析
需求覆盖率是指经过测试的需求/功能和系统分析中所有需求/功能的比值，通常情况下要至少达到99 %的目标。
被验证通过的需求26个，需求总数26个。
需求覆盖率=通过验证的需求/需求总数=26/(26)×100 %=100 %(详见表1)。
4.1 缺陷收敛曲线图
4.2 缺陷生命周期图
从缺陷生存周期来分析：整个缺陷数占比最多的是生存周期在1周的缺陷,总共161个，约占总数的75.23 %,说明开发组对缺陷的响应时间相对较快，能在较短的时间内对bug进行修复。
5 测试结论
5.1 安全性 做了用户登录安全访问控制测试，即各种条件下的用户登录测试，系统安全性高。
篇4
认清“第三方”的责任
第三方测试以合同的形式制约了测试方，使得它与开发方存在某种“对立”的关系，所以它不会刻意维护开发方的利益，保证了测试工作在一开始就具有客观性。第三方一般都不直接参加开发方系统的设计和编程，为了能够深入理解系统，发现系统中存在得问题，第三方测试必须按软件工程的要求办事，以软件工程的标准要求开发方和用户进行配合，从而较好地体现软件工程的理念。引入第三方测试后，由于测试方相对的客观位置，由用户、开发方、测试方三方组成的三角关系也便于处理以往用户、开发方双方纠缠不清的矛盾，使得许多问题能得到比较客观的处理。
第三方测试不同于开发方的自测试。由于他熟悉设计和编程等，往往习惯于按一定的“程式”考虑问题，以至思路比较局限，难于发现“程式”外存在的问题。因为第三方测试的目的就是为尽量多地发现程序中的错误而运行程序的过程，可以更多的发现问题。随着系统越做越大，客观上讲开发人员也无精力参与测试，同时也不符合大生产专业分工的原则。
第三方测试不同于用户的自测试。用户是应用软件需求的提出者，对于软件应该完成的功能是非常清楚的，是进行功能验证的最佳人选。客观情况是，大部分的用户都不是计算机的专业人士，很难对系统的内部实现过程进行深入的分析。对系统的全面测试，功能测试仅仅是一个方面，还要包括并发能力、性能等多种技术测试。
如何组织管理
在测试的过程中，用户、开发方与测试方形成了一个三角关系，从最终目标来讲，三方是完全一致的，都是希望保证系统稳定运行。但在测试过程中，三方的关系却是既对立又合作。
软件测试的过程
为了保证测试的顺利进行，测试方必须强化内部的组织管理。根据我们的经验，完整的测试机构必须包括业务分析部门、技术支持部门、规划设计部门和综合后勤部门。
“第三方”测试什么
根据软件的特性，第三方软件测试工程可划分为三种类型四个层次。
第一类是系统软件、环境软件和各类工具软件等的测评。对这类软件的评测重点是软件产品的功能、性能和特点评测。
第二类是面向应用软件系统的测评。这类软件，具有很强的行业应用特性，往往是要由用户与开发商签定项目合同，开发商负责开发，用户负责验收。对这类软件的评测，根据用户对第三方的依赖程度，又可分为两个层次。第一个层次只对应用软件系统进行综合、性能测试。第二个层次是对应用软件系统进行质量监理与评测。
承担该类软件质量监理评测的第三方，承担软件过程质量监理的责任，在软件生命周期过程中，从软件定义开始，要对软件过程从质量保证角度进行规范化的监督、管理和控制。评测工作不仅包括软件生命周期各阶段的评审，而且还要对程序系统，进行包括模块白盒测试在内的系统集成、系统验收等测试。
第三类是对软件企业的CMM评估认证,也是最高层次的软件评测。
了解测试评估
测试评估是软件测试的一个阶段性的结论，用所生成的测试评估报告，来确定测试是否达到完全和成功的标准。在测度评估阶段向用户提供强有力的支持，包括通过测试报告，验证测试结果是否符合测试计划中制定的测试标准；根据缺陷报告提供的测试结果数据，给出软件质量和测试完整性的评估报告；特别在以下几方面对测试的过程进行评测：
评估测试用例覆盖：测试的目标是确保100%的测试用例成功地执行。主要考虑风险和严重性、可接受的覆盖百分比。
评估代码覆盖：需要断定测试目标期望的总的测试代码行数，在测试中真正执行的代码行数及其百分比，将此结果记录在测试评估报告中。
篇5
关键词：计算机；软件测试
中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2012） 18-0000-02
1 计算机软件测试的概念
所谓软件测试，主要是以发现程序错误为目的而执行程序的过程，是结合软件开发过程中每一个阶段的规格及软件内部的结构进行认真设计的测试用例。因此，我们可以说，软件测试就是在精心搭建的环境下对程序进行执行，以更好的发现软件中的错误，对其可靠性给出鉴定。
2 软件测试的流程
2.1 设计测试方案。设计测试方案是在软件测试初始阶段进行的，在这个工作中，首先要调研所需要应对的系统框架和业务模型，对测试需求进行收集。其次，根据测试需求制订一个合理的测试计划。具体来说，我们的测试团队要对被测试项目有着提前的了解，而且开发部门也要配合测试部门的工作，提供各种系统规格书、系统总体介绍、网络拓扑结构图、用户使用手册、系统配置说明、应用部署与配置以及关键服务器及等文档。经过与业务部门协商之后，就可以确定下来这次测试的目标，然后对这一目标进行细化，制定出各个阶段的目标，并制定相应的指标要求。
2.2 开发测试场景。这主要是指开发测试脚本，是针对被测系统业务进行模拟、录制、编程、参数化、脚本定制以及调试测的工作，通过测试场景的开发，可以使测试脚本实现对现实场景的真是模拟，而且我们还可以通过改变参数来控制并发数以及思考时间等属性。
2.3 执行测试。这主要是按照预先制订的测试方案，在完成测试环境以及测试场景之后进行的工作。
2.4 测试报告及分析。这一工作主要是在执行完测试之后进行的，主要的任务是对测试过程中所暴露的问题进行收集及分析。而测试报告则主要是对测试过程中监控报告以及报表的汇总，然后对其进行一定整理之后所得到的结论性文档。
2.5 回归测试。开发部门在分析了测试报告之后，会对软件的缺陷进行了修复或者优化，使其具有更高的性能，而对于这种修复之后软件的测试就是回归测试。
3 计算机软件测试的基本方法
3.1 按照阶段进行划分。如果按照阶段对计算机软件测试方法进行划分的话，则可以分为单元测试、集成测试、系统测试、验收测试、回归测试、Alpha测试以及Beta测试。
（1）单元测试。这主要是指对软件的基本组成单位进行测试，比如一个模块。单元测试是动态测试中最基本，也是最重要的部分，它主要的目的是对软件基本单元的正确性进行验证。在单元测试中，由于需要我们了解程序的设计及编码的细节，所以这一工作主要是由程序员进行。另外，单元测试还需要开发测试驱动模块以及桩模块进行辅助。在单元测试中，主要的方法包括控制流测试、排错测试、数据流测试以及分域测试等。
（2）集成测试。集成测试主要进行于软件系统集成过程中，它的作用是对单位之间接口的正确性进行检查。一般来说，根据计划，我们将在模块集成为较大系统的过程中运行该系统，查看各个组成部分是否合拍。在这个过程中，使用的策略有自底向上以及自顶向下这两种。
（3）系统测试。这主要是针对已经集成好的系统进行测试，进而对系统的性能及正确性进行检查。由于这一测试的整体难度比较大，我们要制定合理的计划，并严格按照计划执行测试工作。在系统测试工作中，主要的方法有随机测试、性能测试以及功能测试。
（4）验收测试。这种测试的目的是主要是对软件的购买者展示软件的性能，确保其符合购买者的需求。在这个过程中，测试数据主要来自于系统测试中使用的数据。这是软件在应用之前最后的测试。
（5）回归测试。上文中已经对其概念进行了简要的分析，这里将进一步对其进行分析。回归测试的主要目的是检测所进行的修改是否合理。在这个问题上，修改有着以下内涵：首先是修改达到了预期的目的，其次是修改不能够对软件其他功能的正确性产生影响。
（6）Alpha测试。这是在软件开发即将完成的时候所进行的测试，在测试之后，一般仍然会有一些设计上的变更，在这一测试工作中，测试人员主要是最终用户而不是程序员或者测试员。
（7）Beta测试。这是指在开发及测试在根本完成之后进行的测试，这种测试的工作一般由其他人员或者最终用户来完成，不可以由测试员完成。
3.2 按照按测试方法进行划分。按照测试方法进行划分则可以分为白盒测试以及黑盒测试这两种。
（1）白盒测试。这也被我们称之为逻辑驱动测试或者结构测试，是基于覆盖所有代码、路径、分支以及条件的测试。在白盒测试中，我们是清楚程序内部工作过程的，主要的目的是检测其内部动作是否符合规格说明书的要求，至于软件的功能是否符合要求则不属于这一测试的范畴。常见的白盒测试方法有逻辑驱动以及基路测试等。
在使用白盒测试方法的时候，测试者必须对程序的内部结构进行检查，并通过对其逻辑的检查得到测试数据。在这种测试方法中，存在着以下不足：首先，对于程序是否符合设计规范，或者说程序本身就是错误程序的情况，我们是没有办法检查的。其次，对于程序中因路径遗漏而导致的错误，我们无法检查。最后，某些和数据相关的错误我们没有办法检查。在这一具体的工作中，常使用的工具有Junit Framework，Jtest等。
（2）黑盒测试。顾名思义，黑盒测试和白盒测试是相反的。在黑盒测试中，我们的测试目的不是为了检查内部设计及代码是否正确，而是检查程序能否符合功能性方面的需求，因此，这种测试也被我们称之为数据驱动测试或者功能测试。
在测试的过程中，我们将完全不考虑其内部特性，只是将程序作为一个黑盒子看待，然后在其接口进行测试，具体的工作就是检查程序在接收到输入数据之后能否产生正确的数据输出信息。在黑盒测试方法中，常见的方法等价类划分、因—果图、边值分析以及错误推测等。
由于黑盒测试方法属于穷举输入测试，我们只有将所有的输入都当成测试情况使用之后才能够检查出程序中所有的错误，而实际的测试情况有无穷多个，因此，我们除了要有合法的输入之外，还要有不合法却可能的输入。一般常用的工具有WinRunner，Rational Robot，QuickTestPro等。
4 结语
由上文我们可以看出，软件测试中的环节比较多，而且方法也有很大的差别。因此，做好计算机软件测试工作并不是一件很轻松的事情，需要我们对各种软件测试方法了如指掌。所以，我们还要不断的学习，并加强探索，以一个严谨科学的态度去面对软件测试工作，只有这样才能真正的使软件发挥其应有的作用，进而提升企业的竞争力。
参考文献：
[1]何强.通信软件自动化测试系统的研究与实现[D].中南大学，2009.
篇6
一、室内覆盖工程质量监理的重要性
室内无线网络的链路不平衡将会导致上行不足，此时手机有信号却无法接入，无法有效吸收话务，导致室内覆盖没有发挥应有作用，在定位干扰问题时，对干扰源的特点和干扰通道的理解是非常重要的，但是传统的分析只看到了表面现象，简单地认为只存在外部干扰，并认为上行干放增益会产生上行干扰。由于对干扰成因存在错误的理解，以往室内覆盖普遍采用调低上行干放增益的错误方法，导致大量的站点出现链路不平衡。由于存在以上缺陷，以往的室内覆盖实际上是在进行低水平的大量建设，存在严重的隐患。针对这些问题质量监理应该采取多种手段，从根本上定位与解决信号传输通道的质量监理问题，提高室内覆盖的质量，从而提升用户体验。
二、室内覆盖工程设计阶段的监理
在设计阶段，监理人员首先要从现场勘察，设计文件审查和信源方案审查等方面，做好设计阶段的监理工作。
（1）现场勘察监理
根据集成商提交的设计草图，监理人员需和集成商一同到现场进行现场勘查和信号模测 并注意做好以下几方面的工作。首先应该核对设计草图中的大楼结构与现场环境是否相符，在室内拟安装的天线位置处进行模拟信号测试，检查设计草图的天线密度是过密还是过疏。对地下室出口处的天线进行信号泄露测试，检查出入口处的信号泄露强度是否在标准范围内。监理还需要对大楼的平层及大楼的安全走梯进行现有信号测试，检查是否需做室内信号覆盖。在大楼地下室的各个出口处、各部电梯的中层和高层的出口处收集已有信号的导频信号PN上报给建设单位的网管中心，以便网管中心选取室内覆盖站点的施主宏基站及配置附近周围宏基站的邻区列表。对现场测试得到的数据，监理人员要做好详细的记录，以便能够更好地审核设计文件。
（2）设计文件监理审查
室内覆盖工程的施工地点多为大楼的地下室、电梯、线槽等，现场环境相对较为恶劣，且施工安全隐患较多。由于室内覆盖工程的设计和施工都是由集成商负责完成，有些集成商为了增大工程的投资规模，增加自身收入，在设计文件中修改了现场信号模测数据，以增加天线数量，馈线的走线路由出现重复走线，增加布放不必要的馈线，修改分布系统中的信号衰减数量，增加不必要的7/8馈线。直放站的安装位置设计不合理，增加不必要的干放设备。监理人员应注意根据现场勘查时已收集到的测试数据对设计图进行审查，及时发现设计图中存在的问题，并要求集成商改正，提高设计文件的质量。
（3）室内覆盖工程信源方案的审查
室内覆盖工程的信源设备主要有光纤直放站、无线直放站、微蜂窝。监理人员在审核各种信源建设方案时应注意审查光线直放站近端和远端问的光路损耗不宜过大，光路长度不宜过长。需调整施主基站的信号搜索窗，同时，光路过长也会导致光路的损耗大。在无线直放站的监理中对施主天线接收到的宏基站信号，必须进行详细测试，确定所接收的宏基站信号的主导频单一稳定、信号强度、ECIO等数值满足要求。另外，微蜂窝是本身能够提供话务容量的设备。建设完成后，在微蜂窝覆盖区域内会引入新的导频PN信号要注意对室外周围基站的临区列表做相应调整，避免出现手机切换掉话现象。
三、室内覆盖工程施工阶段的监理
室内覆盖工程施工环境特殊且大部分属于隐蔽工程，所以施工过程需和大楼业主协商进行，施工过程需一次完成。室内覆盖系统是通过馈线，耦合器和功分器，将信号均匀地传输到大楼的各个角楼。其中，馈线头的制作质量是影响整个系统运行效果的主要因素。如果馈线头制作的质量不合格，将使信号在馈线头处发生反射、折射、散射等现象，增大信号在传输过程中的损耗，引起信号发生失真，增大信号的误码率。由于CDMA属于白干扰系统，发射信号功率的增大，意味着系统容量和质量的降低。为了做好室内覆盖工程的质量控制，在工程的前期监理人员要对施工单位的施工质量，馈线头制作工艺等进行旁站监理。室内覆盖系统中，每段馈线都有两个馈线头，如果在工程前期没有对施工工艺质量和施工队伍素质进行把关或者把关不严，等到工程建设完成后再来查找室内覆盖系统的故障点，将是一件十分困难的事情。
在室内覆盖工程建设完成后，监理人员要对室内覆盖系统进行预验收。面对如此庞大，分布在大楼各个角落的室内覆盖系统，找出系统中的质量问题点可通过驻波仪对室内覆盖系统进行检查。反向高驻波信号在经过耦合器时，由于耦合端对信号功率衰减量较大，驻波信号经过耦合端时产生较大衰减，直通端对信号功率衰减量很小，可近视看作驻波信号是直接通过的。反向高驻波信号在经过功分器时，也要产生相应的衰减。当功分器位于室内覆盖系统前端时，功分器对末端高驻波信号的衰减影响较大，故位于系统前端的功分器出口端都应进行驻波测试，当功分器位于系统末端时，对驻波信号的衰减影响较小，可直接在功分器的输人口处进行驻波测试。所以，使用驻波仪对室内覆盖系统进行驻波测试时应分段进行测试，通过对分布系统的高驻波点进行整改，能够使整个室内覆盖系统的信号质量大大提高。
四、室内覆盖工程验收阶段的监理
在工程正式验收前，监理人员应组织集成商开展预验收工作，确保室内覆盖工程的质量合格后再交付验收。对交工资料的审查，应重点检查其中的测试报告，对于大楼地下室，要求进行DT测试及出入口的信号外泄测试。对每份测试数据要求要有详细全面的图表和数据，对图表和测试数据的分析结果指标应在规范要求范围内。测试报告反映了室分站点的信号覆盖效果，通过审查测试报告，能够检查室内覆盖系统的工程质量是否达到要求。除此以外，还应注意检查直放站和干放等设备的监控是否已经连接网管并工作正常。
结 语
室内覆盖工程由于具有施工环境的特殊性，隐蔽工程较多且故障点难以查找，为了更好地开展工程监理工作，监理人员除了控制好设计、实施及验收阶段的质量监理，还应注意采取措施不断增强施工人员的质量监理意识，从根本上改变以前不当的施工习惯，以达到保证施工质量的最终目的。
参考文献
篇7
关键词：可靠测试；优化；数据分析
高质量且高可靠性的企业应用程序系统是数字化时代非常重要的元素[1]。测试团队在确保企业应用程序系统满足既定标准或需求时会发挥非常重要的作用。随着系统的规模和复杂性升级，其可靠性和质量要求必然成倍增长，这意味着测试团队需要开发更有效的测试方法。一个完整的测试过程包括数据记录、数据维护、数据验证等多个方面。测试数据管理策略对于测试数据的记录必须是全面的，这也为后期的数据分析挖掘提供了支撑。
陈翔等人在文献[2]中重点阐述了回归测试中用例优先排序（test case prioritization，简称TCP）问题。从源代码、需求和模型三个角度对TCP问题进行分类，重点分析了回归测试中测试资源缺乏时的TCP问题。另外，潘伟丰等人在文献[3]中提出了基于错误传播网络的测试用例排序方法。该方法在类粒度将软件抽象成加权类依赖网络（weighted class dependency network， 简称WCDN）模型，并基于WCDN分析错误在网络上的传播行为，构造错误传播网络（bug propagation network，BPN）。实例研究表明，基于错误传播网络的测试用例排序方法在错误检出率上相比于其他经典方法有一定的提高，并且具有较好的稳定性。一个全面的用例排序方法，能准确地将当前的软件质量反映到执行用例的优先级上[4-5]。通过使用正确的TCP策略测试团队能够提供及早发现缺陷，在整个产品开发过程中，为提供更简单的方法去解决系统缺陷提供支撑。因此，拥有正确的TCP策略对测试团队乃至公司都至关重要，能加快系统周期并大幅削减成本。然而在现有的研究工作中，TCP策略问题主要集中在回归测试阶段，但是回归测试处于整个测试过程的末端[6]。由于回归测试时对于本系统缺陷分布情况有非常清晰的概念，但是由于处于末端，对于测试团队的优化毕竟有限。同时测试团队与研发团队往往是单线交流，即研发团队待测系统，测试团队极少参与提高研发团队的开发质量。
因此，可以从测试用例执行策略和测试结果反向优化开发策略两个方面展开研究，并提高系统可靠性。测试用例执行顺序问题是测试执行策略中非常重要的部分，在测试项目中持续优化测试用例执行顺序可以提早发现潜在的缺陷。同时由于测试团队对于项目整体的理解更为透彻，对缺陷的总体分析可以帮助研发团队在类似问题上处理地更为妥善。测试团队在需求分析阶段的有效介入，将从源头上提高系统的质量和可靠性。
1 测试执行策略优化
测试中的关键问题是第一时间发现被测系统不符合规范要求的内容。测试经理在测试规划时是通过大量的测试用例保证测试的覆盖率。持续优化测试用例执行顺序是在保障测试覆盖率的同时，合理地安排测试用例地执行顺序，即TCP问题。文章提出将项目测试分为三个阶段，在项目测试的初期、中期、后期三方面分别进行优化TCP，最终优化整个测试执行策略。
如图1 所示，项目测试初期，分析测试用例的历史数据得到测试用例的执行潜在价值，优先执行潜在价值高的测试用例。比如在其它项目中执行某些用例时，发现了系统不符合规范要求的部分，并提交了缺陷。在新的测试用例执行时，应首先执行这类测试用例以便快速发现系统缺陷。项目测试中期，分析本项目当前缺陷情况得到各个系统功能模块的缺陷发生概率。优先执行缺陷分布较多的功能模块相关的测试用例。项目测试后期，即回归测试阶段，需结合各个系统功能模块在本项目和历史项目中的缺陷发生概率，在保证一定回归比率的情况下，综合考虑本项目和历史项目的分析，优先回归测试缺陷发生概率较高的模块。
2 需求分析优化
项目测试工作通常被安排在项目研发工作之后，测试团队的主要工作也仅仅是将测试结果中发现的缺陷情况报告给研发团队，并没有对缺陷情况进行分析，可能使得类似的缺陷在不同的项目中反复出现。因此测试团队在提供测试报告的同时，对各个功能模块中所发现的缺陷进行分析，并在新项目立项初期给出系统模块开发时的缺陷概率，帮助研发团队在需求分析阶段重点考虑高缺陷概率的模块开发和模块间的协作，从源头上降低缺陷发生的概率。测试团队与研发团队的双向反馈将优化产品设计的需求分析阶段，提高系统的可靠性，如图2所示。
图2 测试团队和研发团队双向通道
3 结束语
文章从优化测试用例执行顺序和测试结果优化需求分析两个方面，阐述了现在系统开发中提高系统可靠性的重要方法。测试数据的管理是一座金矿，对测试数据的深入分析可以让整个测试过程不再是静止的，而是可以动态调节以应对更复杂的情况，同时深入分析测试结果也可以建立测试研发的双向通道，形成良性循环。最终可以超预期地提交高质量的系统，节约运营成本，完成市场抢占。
参考文献
[1]K.Krishna Murthy， Janardhana S Channagiri， "test data management： Enabling reliable testing through realistic test data"Building Tomorrow's Enterprise， Oct 2009.
[2]陈翔，陈继红，鞠小林，等.“回归测试中的测试用例优先排序技术述评”[J].系统软件与软件工程，2013（8）.
[3]潘伟丰，李兵，周晓燕，等.“基于错误传播网络的回归测试用例排序方法”[J].计算机研究与发展，2016（3）.
[4]朱海燕，范辉，谢青松，等.“测试用例排序的研究”[J].计算机工程与科学，2008（1）.
篇8
二年以上工作经验 |男| 29岁（1986年6月9日）
居住地：上海
电 话：153********（手机）
E-mail：
最近工作 [ 1年7个月 ]
公 司：XX计算机软件有限公司
行 业：计算机服务(系统、数据服务、维修)
职 位：软件测试
最高学历
学 历：本科
专 业：软件测试
学 校：西北大学
自我评价
本人熟悉软件开发测试流程，丰富的自动化测试经验，善于学习。能在成功与失败中完善自己，活泼开朗，乐观向上，适应力强，勤奋好学，认真负责。待人诚恳，做事踏实细心，对工作有热情有责任心。
求职意向
到岗时间： 一周之内
工作性质： 全职
希望行业： 计算机软件
目标地点： 上海
期望月薪： 面议/月
目标职能： 软件测试
工作经验
2012 /12—至今：XX计算机软件有限公司[ 1年7个月]
所属行业：计算机服务(系统、数据服务、维修)
测试部 软件测试
1.负责需求分析，制定测试计划，编写测试计划和测试案例；
2.负责测试环境的搭建；
3.负责使用JIRA 缺陷管理系统, 管理跟踪BUG；
4.负责系统的功能测试，以及处理客户的回馈，重现问题；
5.负责熟练使用LINUX脚本语言，实现测试环境的自动安装和定时运行，并进行日志的查看及排错等；
6.负责根据用户需求，编写用户使用说明手册；
7.负责系统的安装及配置,负责客户版本升级。
2011 /1—2011 /12：XX软件科技有限公司[ 11个月]
所属行业：计算机软件
事业部 软件测试
1、负责根据软件开发年度进程表，与美国微软测试及开发团队沟通，确定各阶段测试目标；
2、负责在项目测试过程中，制定测试计划，参与测试用例的编写、修改和审核；
3、负责定期组织技术交流会议，以提高组员工作效率；
4、负责及时处理客户对软件提出的问题，执行测试定位问题,以帮助产品的修复。
2010 /7—2011 /1：XX网络游戏有限公司[ 6个月]
所属行业：娱乐/休闲/体育
技术部 软件测试
1、负责了解软件的测试流程，并制定测试流程；
2、负责编写测试用例，BUG提交给开发人员；
3、负责开发人员修复，进行回归测试；
4、负责根据需求写测试大纲、编写测试用例、测试报告。
教育经历
2006 /9--2010 /7 西北大学 软件测试 本科
证 书
2009 /6 大学英语六级
2008 /12 大学英语四级
篇9
关键词：软件代码审查；代码审查过程；代码审查问题
中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2012) 03-0000-02
Discussion on the Code Review of Software Static Testing
Yuan Zhengjiang
(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)
Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.
Keywords:Software code review;Code review process;Code review problem
一、引言
软件测试常用方法可分为动态测试和静态测试，只有动态测试和静态测试有效结合，才能更好的完成软件测试工作。代码审查是软件静态测试中常用的软件测试方法之一，代码审查时，只要测试人员方法得当、足够细心，往往能够产生意想不到的效果。
二、代码审查的作用
代码审查是在不执行软件的条件下有条理的仔细审查软件代码，从而找出软件缺陷的过程。
代码审查可以找出动态测试难以发现或隔离的软件缺陷。在开发过程初期让测试人员集中精力进行软件代码审查非常有价值：可以提高代码质量；在项目的早期发现缺陷，将损失降至最低；促进团队沟通、促进知识共享、共同提高。
代码审查还可以为动态测试时设计和执行测试用例提供思路。通过代码审查，可以确定有问题或者容易产生软件缺陷的特性范围。
三、代码审查的过程
代码审查过程可分为：代码审查策划阶段、代码审查实施阶段以及代码审查总结阶段。
（一）代码审查策划阶段
1.项目负责人分配代码审查任务；
2.确定代码审查策略：依据软件开发文档，确定软件关键模块，作为代码审点；将复杂度高的模块也作为代码审查的重点；
3.项目负责人确定代码审查单，审查内容一般可包括：
（1）可追溯性：
――代码是否遵循详细设计？
――代码是否与需求一致？
（2）逻辑：
――表示优先级的括号用法是否正确？
――代码是否依赖赋值顺序？
――“if…else”和“switch”使用是否正确清晰？
――循环能否结束？
――复合语句是否正确地被花括号括起来？
――case语句是否所有可能出现的情况均已考虑？
――“goto”是否使用？
（3）数据：
――变量在使用前是否已初始化？
――变量的声明是否按组划分为外部的和内部的？
――除最明显的声明外，是否所有声明都有注释？
――每个命名是否仅用于一个用途？
――常量名是否都大写？
――常量是否都是通过“#define”定义的？
――用于多个文件中的常量是否在一个头文件中定义？
――头文件中是否存在可执行的代码？
――定义为指针的变量是否作为指针使用（而不是作为整数）？
――指针是否初始化？
――释放内存后是否将指针立即设置为NULL（或0）？
――传递指针到另一个函数的代码是否首先检查了指针的有效性？
――通过指针写入动态分配内存的代码是否首先检查了指针的有效性？
――宏的命名是否都大写？
――数组是否越界？
（4）接口：
――在所有的函数及过程调用中，参数的个数都正确吗？
――形参与实参类型匹配吗？
――参数顺序正确吗？
――如果访问共享内存，是否具有相同的共享内存结构模式？
（5）文档：
――软件文档是否与代码一致？
（6）注释：
――注释与代码是否一致？
――用于理解代码的注释是否提供了必要的信息？
――是否对数组和变量的作用进行了描述？
（7）异常处理：
――是否所有可能的错误都已加以考虑？
（8）内存：
――在向动态分配的内存写入之前是否检查了内存申请是否成功？
――若采用动态分配内存，内存空间分配是否正确？
――当内存空间不再需要时，是否被明确的释放？
（9）其它：
――是否检查了函数调用返回值？
――所有的输入变量都用到了吗？
――所有的输出变量在输出前都已赋值了吗？
4.确定代码审查进度安排，项目负责人负责安排代码审查的进度。
（二）代码审查实施阶段
1.代码讲解：软件开发人员详细向测试人员讲解如何以及为何这样实现，测试人员提出问题和建议。通过代码讲解，测试人员对被审查的软件有了一个全面的认识，为后续代码审查打下良好的基础。
2.静态分析：一般采用静态分析工具进行，主要分析软件的代码规模、模块数、模块调用关系、扇入、扇出、圈复杂度、注释率等软件质量度量元。静态分析在代码审查时应优先进行，有利于软件测试人员在后续代码审查时对软件建立宏观上认识，在审查中容易做到有的放矢，更易于发现软件代码中的缺陷。
3.规则检查：采用静态分析工具对源程序进行编码规则检查，对于工具报出的问题再由人工进行进一步的分析以确认软件问题，是一种比较有效的方法。
4.正式代码审查：代码审查可分两步进行：独立审查和会议审查。根据情况，这两步可以反复进行多次。
（1）独立审查：测试人员根据项目负责人的工作分配，独自对自己负责的软件模块进行代码审查。测试人员根据代码审查单，对相关代码进行阅读、理解和分析后，记录发现的错误和疑问。
（2）会议审查：项目负责人主持召开会议，测试人员和开发人员参加；测试人员就独立审查发现的问题和疑问与开发人员沟通，并讨论形成一致意见；对发现的问题汇总，填写软件问题报告单，提交开发人员处理。
5.更改确认：开发人员对问题进行处理，代码审查人员对软件的处理情况进行确认，验证更改的正确性，并防止出现新的问题。
（三）代码审查总结阶段
代码审查工作结束后，项目负责人总结代码审查结果；编写测试报告，对软件代码质量进行评估，给出合理建议。
把代码审查提出的所有问题、亮点及最终结论详细的记录下来，供其他软件项目代码审查借鉴。必要时，可建立常见软件代码缺陷数据库，为软件代码审查人员培训和执行代码审查提供数据支持，也可以为软件编码规则制定规范提供实践依据。
四、代码审查中的常见问题
如果软件测试人员熟悉常见的软件代码审查问题，对代码审查效率是很有帮助的。笔者根据自己的应验，列举部分常见软件代码审查问题如下（仅供参考）：
（1）浮点数相等比较：可能造成程序未按设计的路径执行；
（2）因设计原因导致某些代码不能执行：如逻辑表达式永远为真（或假）造成某分支不能执行、代码前面有return语句、某模块从未被调用等；
（3）switch语句没有break语句（有意如此设计时除外）；
（4）数组越界使用：数组越界容易发生在数组下标是计算得到的情况下，而且审查时很难发现这种代码缺陷，应加以重视；
（5）变量未初始化就使用或者是条件赋值就使用；
（6）程序中存在未使用的多余变量；
（7）复合逻辑表达式没有使用括号造成运算顺序错误；
（8）有返回值的函数中return没有带返回值；
（9）逻辑判别的表达式不是逻辑表达式；
（10）动态分配的内存没有及时释放：忘记写内存释放代码或由于其它逻辑缺陷导致内存释放代码未得到执行；
（11）没有对缓冲区溢出进行必要的防护；
（12）访问空指针，即指针未初始化就使用；
（13）指针指向的内存释放后，未将指针置为NULL：其它函数访问该指针时，判断指针不为空，当作有效指针使用，会造成内存访问错误；
（14）注释说明与程序代码实现不一致，甚至相反；
（15）循环存在不能跳出的可能，程序中没有相应的保护机制。
五、结束语
篇10
关键词： 软件潜在分析； 软件可靠性； 软件安全性； 故障树分析； 调试器
中图分类号： TN915.04?34； TM417 文献标识码： A 文章编号： 1004?373X（2016）15?0081?05
Abstract： In the process of C programming language software potential analysis， the management of the defect generating process is often neglected， and the progress of the defect analysis work is slow. In order to solve the above problems， the software potential analysis tool based on C programming language was designed and developed. In the paper， the process from the generation source causing C programming language software defect to accident occurrence is decomposed， in which the static analysis method is used to find out the source code defect， the reliability defect is analyzed with failure modes and fault tree method， and the security defect is tracked with dynamic test. The corresponding tool was designed and implemented after the determination of analysis method. The tool was tested and verified with an instance. The verification results show that the tool， in each stage of the defect， can manage and analyze the potential defects effectively and improve the efficiency of the software potential analysis， and provides the guarantee for the quality of critical software safety.
Keywords： software potential analysis； software reliability； software security； fault tree analysis； debugger
0 引 言
在航空、航天等安全关键领域，软件承担的任务包括数据采集、导航控制和通信指挥等任务。随着科技的发展，软件已经成为这些系统的神经中枢，发挥着越来越重要的作用。在安全关键系统的运行过程中，若其软件一旦发生故障，就可能造成十分严重的后果[1]。然而，目前的软件缺陷分析方法及工具均从某个单一的角度检测软件缺陷。在实际的可靠性和安全性测试中，不可能只采用其中的一种分析方法来断定软件的缺陷，而需要将多种分析方法有效结合，在最大程度上保证安全关键软件的质量[2]。
1 需求分析
1.1 设计目标
首先，系统能够提供以XML为接口的缺陷导入，并对工程项目代码的静态分析结果进行处理，对代码的安全缺陷进行等级划分，实现层次化的缺陷识别，统一缺陷类型。其次，该平台能够建立准确的故障分析模式和故障树分析方法，在测试过程中提高软件故障分析及安全性测试的高效性和全面性，实现全数字仿真测试环境的无缝集成[3]。并提供便利的辅助功能，实现测试脚本的生成、测试用例的生成、测试报告单的生成。
1.2 业务流程
基于C语言的潜在分析工具共有两条主线流程，如图1所示。静态分析结束后，通过XML接口将缺陷导入本系统，可以查看缺陷所在的源文件、根据已整理完成的缺陷分级获得缺陷严重等级、对缺陷进行处理并填写问题报告单、编写测试用例等。使用系统提供的工具在故障模式辅助下的故障树建模，并计算故障树的最小割集，生成测试用例[4]。以上2个步骤生成测试用例后，在全数字仿真测试平台的基础上编写测试脚本，使用调试器进行动态测试，在测试过程中可进行单步跳过和单步进入等，并观察寄存器状态、内存值和变量值，测试结束后分析测试数据。
1.3 功能分析
系统是在全数字仿真测试环境采用软件仿真技术的基础上构建的，仿真平台能够模拟SPARCV7处理器以及其他片上与片外设备的功能和时序关系，为最终的测试脚本运行提供仿真的运行平台[5]。在此基础上，本平台包含下述4个系统，为软件的潜在问题分析与处理提供服务，功能结构如图2所示。
1.4 静态分析结果处理
静态分析结果处理需要具备的功能包括项目管理、缺陷分析处理、测试用例管理、问题报告单管理和测试结果分析。其中，项目管理的作用是对每个软件程序可以在该模块建立相应的项目来管理该软件项目的问题；缺陷分析处理用于提供工具辅助测试人员对缺陷结果进行处理；测试用例管理主要管理测试用例，对缺陷对应测试用例的管理，包括添加、删除和查询缺陷测试用例的功能；能够通过提供的测试用例模板辅助生成测试用例。
1.5 故障模式及故障树分析
静态分析结果处理需要具备的功能包括故障树建模、辅助建立故障树及故障树分析。其中故障树建模提供用户绘制故障树的平台，包括建模、导入保存节点属性的编辑和故障树工具集管理等。辅助建立故障树指故障树建模过程中，使用知识库中已经保存的故障模式及其对应的故障树，辅助用户使用故障树分析方法建立故障树模型，该功能模块分为故障树对齐、完整性检查、根据故障树节点搜索故障树、根据故障模式搜索故障树、保存节点对应的故障模式。故障树分析是分析可靠性缺陷的主要模块，是故障树分析方法最核心的部分，包括：生成最小割集、计算事件概率、故障树解析和测试用例生成[6]。
2 系统设计
2.1 硬件整体架构
缺陷分析工具的设计采用基于服务器?客户端的设计方案。其中服务器主要提供静态分析服务和测试数据的存储。静态分析服务一般由静态分析软件提供，包括静态分析服务、数据存储服务。客户端主要负责进行实际的测试，包含：静态分析结果处理、故障模式及故障树分析、基于故障注入的动态测试功能。软硬件的整体架构如图3所示。
2.2 软件设计
客户端软件实现了平台的主要功能，其设计分为三层，其结构见图4。其中用户层为用户提供直接的服务；功能层实现了本安全性测试平台的主要功能，供用户层模块使用。
软件是基于EclipseRCP进行开发的，采用GEF框架进行建模。
2.3 功能设计
根据系统的需求，将工具的功能划分为静态分析结果处理、故障模式及故障树分析、动态测试调试器和基础数据管理。
静态分析结果包括项目管理、缺陷分析模块、测试用管理模块、问题报告单模块和测试结果分析。
故障模式及故障树分析包括故障树建模、辅助建立故障树及故障树分析。
动态测试调试器包括工程管理、断点管理、调试过程控制及调试信息管理。
基础数据管理的划分包括用户管理、角色管理、缺陷分级管理及故障模式的管理。
3 系统实现
3.1 功能实现
3.1.1 静态分析结果处理
静态分析结果处理需要具备的功能包括项目管理、缺陷分析处理、测试用例管理、问题报告单管理和测试结果分析[7]。
缺陷分析处理：按文件划分显示缺陷通过SQL的group by file查询实现。
测试用例管理：根据测试用例模板辅助生成测试用例时，首先要根据缺陷代码查询其对应的所有用例模板，点击模板后，将模板内容填充至界面中，点击添加即可添加。另外，测试用例模板的字段与测试用例的字段相同。
问题报告单管理：问题报告单和测试用例的导出通过iText完成。问题报告单和测试用例的表现形式为word中的表格，生成报告的核心是表格的创建。在表格的创建过程中，需根据用户的处理自动填写至相应位置。
测试结果分析：首先按照给定条件查询数据，再使用JfreeChart包绘制饼图或柱状图。
3.1.2 故障模式及故障树分析
故障树建模采用GEF实现，GEF是一个图形编辑框架。根据实际需要，系统提供了事件节点、门节点、转入转出三类节点和节点间的连线。
辅助建立故障树，该模块的实现涉及较多的数据库操作，故障树采用Sftree类描述，其包括多个表示节点的SftElement类，节点之间的关系为SftRelation类。
最小割集的生成是根据用户构建的故障树进行分析，查找导致顶事件发生的所有基本事件的集合。其步骤大致为：输入故障树，判断故障树是否合法，若不合法则直接返回，否则进行下一步；利用“下行法”求该故障树的最小割集；输出得到的最小割集，并显示在对话框中。
3.1.3 基础数据管理
基础数据管理模块用于数据库管理员对辅助测试数据的编辑，系统在与数据库进行交互过程中采用了Hibernate包[8]。对于数据库表的增删改，本系统采用了Common框架的实现方式。Common框架的流程如图5所示。
3.2 SNMP协议网络设备管理模块的实现
3.2.1 最小割集生成算法
故障树完整性检查完毕，需要求出最小割集，采用“下行法”进行计算，其步骤如下：
（1） 创建保存最小割集的列表cutset，cutset保存了若干个AnalysisNode对象，该对象保存了一个最小割集，包括这个最小割集中的所有节点nodes及每个节点到达根节点的路径path；
（2） 从顶事件root开始，若root为null，则返回结束；不为null，则将创建AnalysisNode对象set，将root加入set的节点列表，并设置root的path为root，将set加入cutset列表；
（3） 获得最小割集cutset中不全为根节点的currentset，若其为null，则转步骤（7），否则转步骤（4）；
（4） 将currentset从cuteset中移除，获得currentset的首个非叶节点dealnode及门节点gatenode。若gatenode为“与门”，转步骤（5）；若为“或门”，转步骤（6）；
（5） 创建一个新的最小割集newset，遍历currentset和“与”门的所有子节点inode，若其为dealnode则continue；将inode加入到newset的节点中，其路径不变；遍历gatenode的子节点gnode，将gnode加入到newset的节点中，并设置其路径为dealnode的path与gnode之和，将newset加入到最小割集列表cutset中，转步骤（3）；
（6） 遍历“或”门的所有子节点snode，并创建一个新的最小割集newset，遍历currentset的所有子节点inode，将其加入到newset的节点中；并获得inode的路径path，也加入到newset的path中；遍历结束后将snode加入newset节点中并设置其path为dealnode路径，将newset加入最小割集列表cutset，转步骤（3）；
（7） 返回cutset，cutset即为该故障树的最小割集列表。
3.2.2 混编文件生成算法
数字仿真测试平台记录了源代码与混编码的对应方式，需要根据接口生成源代码与汇编代码的混合代码，其中一条源代码可能对应着多个汇编代码块，需要一次读取源文件，查找其相应的混编文件并进行显示。生成混编文件的步骤如下：
（1） 获得源文件，将其路径添加到数组，保证创建混编文件的线程只有一个；
（2） 创建混编文件输出流及源文件的输入流；
（3） 遍历源码行号[i，]根据文件名和行号得到自[i]开始合理的第一条源码行号[j，]若[j=0]或[i=j+1，]则将[i][到]lineSum行源文件写入混编文件输出流，转步骤（6）；否则，将[i]至[j]行内容写入混编文件输出流中；
（4） 根据源码行对应的目标码代码的数组，获得代码块的数组，遍历代码块，获得起始目标码地址m_start_address，设置address_temp为m_start_address，转步骤（5）；
（5） 遍历代码块，根据PC地址address_temp获取该行汇编文件，加入混编文件输出流，并设置address_temp为下条指令的地址（因为存在多条代码块时为call指令）；
（6） 将混编文件输出流写入文件，混编文件生成过程完成。
4 测试与验证
4.1 测试准备
（1） 测试环境包括服务器和客户端两个部分，硬件环境和软件环境如表1所示。
（2） 在服务器上安装数据库系统，采用Klocwork作为静态分析软件，因此也需要安装Klocwork的服务器端软件。在客户端上，需要安装本系统和Klocwork的客户端。
4.2 测试实例
（1） 静态分析结果处理部分的验证
如采用Klocwork9进行静态代码分析，对其加入了支持GJB9369的扩展规则，分析结果通过K9提供商提供的软件，已经转为本工具可接受的XML文件。导入后发现存在源代码缺陷的文件共有4个，总计10个缺陷。由于在基础数据中设置代码为“UNINIT.STACK.MUST”的缺陷严重度为等级1，对其进行缺陷确认并填写问题报告单，对于等级2的确认为非缺陷，等级3的缺陷忽略。
在对静态分析结果进行处理后，可通过两种途径对处理结果进行验证，一是通过打印问题报告单和测试用例与填写内容进行比较确认；二是通过数据统计进行。经过对比和验证，静态分析出的源代码缺陷处理结果正确的生成了报告和统计图。
（2） 故障模式和故障树分析验证
故障模式和故障树分析验证中，将“火箭发动机误点火”作为顶事件进行分析，造成顶事件发生的事件是外部因素或提前点火，其中外部因素不做分析，仅对提前点火事件进行分析。提前点火事件可能由硬件故障或软件故障造成，硬件故障的原因有蓄电池接通和点火电路允许，而软件故障可能是由内存溢出或线程非法造成。在故障树的分析过程中，可根据节点名称或故障模式辅助建模，在建模结束后，为每个基本事件设置发生的概率。建模结束后对故障树进行完整性检查后即可进行故障树分析，分析结果如表2所示。
（3） 动态调试的验证
首先需要针对前两步添加的测试用例编写相应的测试脚本。在源代码缺陷分析中遇到的未初始化变量 unsigned int [x，]对于该缺陷的验证可通过两种方式：一是在非故障注入的脚本运行过程中，可通过单步调试查看[x]变量的变化；二是通过针对该问题编写测试脚本，需按上述格式填写，再从调试器中打开运行，观察测试记录文件。首先，在 rs232.c的第36行加入断点，点击run运行至该行号后，单步跳过至37行。然后，下文为脚本的片段，首先在2～3内取变量[x]的值，再通过故障注入改变[x]的值，再次取出变量[x]的指令。
源代码缺陷可能导致内存变量发生故障，因此，需要对静态分析处理中构建的测试用例进行确认。在动态测试结束之后，还需要根据结果对测试用例进行确认，即确认静态分析或故障树分析的软件缺陷的测试用例是否通过。通过基于故障注入的动态测试，可在测试过程或其记录的文件中观察出故障发生时系统的运行状态，从而保证系统的安全性。而其他分析，如源代码缺陷的分析和故障模式及故障树分析可以在安全性缺陷分析采用的基于故障注入的动态测试中进行验证，验证过程即跟踪了缺陷的产生到故障的出现。
5 结 论
航天航空等关键领域，软件缺陷直接影响着整个系统。本文由缺陷产生到发生故障的过程着手，进行了全程跟踪，并对这些安全关键软件测试中使用的分析方法进行了深入的整合。工具采用接口化的方法，使得各种分析方法能够灵活组合；并模型化数据，建立了统一的数据管理平台，使得分析数据以标准化形式表示，增加了数据使用的延展性，便于多领域的故障数据管理；建立了多阶段的分析概念，把缺陷分析流程化，多维化。在可靠性和安全性测试流程中辅助分析人员针对C语言缺陷进行完整的分析和记录。
参考文献
[1] 陈静.Klocwork在嵌入式软件静态测试中的应用[J].电子与电脑，2013，38（5）：89?92.
[2] 樊林波，吴映程，赵明.软件可靠性与安全性的区别分析及其证明[J].计算机科学，2008，35（9）：285?288.
[3] 何鑫，郑军，刘畅.软件安全性测试研究综述[J].计算机测量与控制，2011，19（3）：493?496.
[4] 仉俊峰，洪炳，乔永强.基于软件方法故障注入系统[J].哈尔滨工业大学学报，2011，38（6）：873?876.
[5] 漆莲芝，张军，谢敏.故障树分析测试用例生成技术研究与应用[J].信息与电子工程，2010（8）：594?597.
[6] 姜兴杰，杨峰辉.软件可靠性分析与设计[J].现代电子技术，2011，34（7）：135?137.
