摘要：随着科学技术的飞速发展，软件的功能越来越强大，软件的复杂性也越来越高，从而大大增加了软件测试与可靠性评估的难度。为了保证一个软件系统的质量，有必要针对软件的测试与可靠性评估方法进行专门地研究。本文就是针对这一领域所做的一些研究。

　　关键词：软件测试 可靠性 软件评估

　　一.软件测试的定义

　　软件测试（Software testing）是软件生存期（Software life cycle）中的一个重要阶段，是软件质量保证的关键步骤。通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。

　　从用户的角度来看，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，所以软件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误或缺陷。

　　二.软件测试的生命周期

　　测试主要依据是被试系统的研制任务书和技术规格书，是对软件整体功能和性能的综合测试与评估。测试原理是软件测试活动的理论基础，测试方法是测试原理的实际应用和获得测试数据的手段。基于软件的共性，对于软件的测试要遵循一般软件的测试原理和方法。同时，针对软件的特性，必须找到合适的测试方法。测试用例的合理性对于软件的测试与评估具有关键作用，而如何使设计的用例合情、合理并且典型有效并不容易。所以应该与软件的研制人员以及最终用户一起，有针对性地研究实际操作环境并加以描述，形成合理的测试用例集。另一方面，软件运行环境的复杂程度对软件评估具有重要作用，所以应产生尽量逼真的运行背景以便于研究。软件测试的周期如图1所示。

　　实践证明，尽管人们在开发软件的过程中使用了许多保证软件质量的方法和技术，但开发出的软件中还会隐藏许多错误和缺陷。这对于规模大、复杂性高的软件更是如此。所以，严格的软件测试对于保证软件质量具有重要作用。

　　

　　图1 软件测试的生命周期

　　软件测试在软件生存期中横跨两个阶段。在软件编码阶段，当编写出一个模块后，通常要对它进行必要的测试（称为单元测试），这时测试与编码属于同一个阶段。在编码阶段结束后，对软件系统还要进行各种综合测试（集成测试与系统测试），这是一个独立阶段，即软件测试阶段。在这个测试阶段又有两种性质不同的测试：研制单位内部进行的集成测试和系统测试与用户（或第三方）进行的验收性测试。

　　在软件测试生命周期内，错误在软件开发的每个阶段都可能被带入。在软件测试中，某些错误被发现、分类、隔离，最终被纠正。由于软件不断被修改，所以这个过程是一个反复进行的过程。

　　三.测试方法和流程

　　软件测试方法主要有黑箱测试方法与白箱测试两类。黑箱测试又称功能测试、数据驱动测试或基于规格说明的测试，是在完全不考虑程序内部结构和内部特性的情况下，检查输入与输出之间关系是否符合要求。白箱测试又称结构测试、逻辑驱动测试或基于程序的测试，是在已知程序内部结构的情况下设计测试用例的测试方法。显然，白箱测试适合在单元测试中运用，而在独立测试阶段多采用黑箱测试方法。

　　测试用例（Test case）实际上是对软件运行过程中所有可能存在的目标、运动、行动、环境和结果的描述，是对客观世界的一种抽象。设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。测试用例应该体现软件工程的思想和原则。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

　　软件测试所得到的数据经过处理以后，可以用来作为评估软件系统是否满足用户需求的依据。软件测试阶段的信息流如图2所示：

　　

　　图2 软件测试信息流

　　四.软件评估理论及其发展现状

　　软件的评估理论是进行评估的理论依据，评估方法是评估理论的实际应用和处理测试数据的方法。对于评估指标体系中的不同指标，应该根据测试数据的不同，选取相应的评估理论和方法。软件评估（Software assessment）的实质是对软件质量的度量与评价。

　　我们对软件质量评估的定义是：“为了确定一特定的软件模块、软件包或软件产品是否验收合格或发布而把特定的评估准则应用到该软件模块、软件包或软件产品上去的活动”。

　　可见，软件评估的对象是“软件模块、软件包或软件产品”，软件评估的目的是“确定被评对象是否验收合格或发布”。定义中提到的评估准则是“根据特定的软件产品和质量需求，确定产品是否通过验收或发布的一组成文的规则和条件的集合”。从广泛意义上讲，评估准则已经包括了评估方法和指标体系，即如何处理获得的测试数据与如何应用评估准则到被评估软件上。

　　软件可靠性评估（Software reliability assessment）的完整含义是：根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。

　　目前，软件可靠性工程是一门虽然得到普遍承认，但还处于不成熟的正在发展确立阶段的新兴工程学科。国外从60年代后期开始加强软件可靠性的研究工作，经过20年左右的研究推出了各种可靠性模型和预测方法，于1990年前后形成较为系统的软件可靠性工程体系。同时，从80年代中期开始，西方各主要工业强国均确立了专门的研究计划和课题，如英国的AIVEY（软件可靠性和度量标准）计划、欧洲的ESPRIT（欧洲信息技术研究与发展战略）计划、SPMMS（软件生产和维护管理保障）课题、Eureka（尤里卡）计划等。每年，都有大量人力物力投入软件可靠性研究项目，并取得一定成果。

　　国内对于软件可靠性的研究工作起步较晚，在软件可靠性量化理论、度量标准（指标体系）、建模技术、设计方法、测试技术等方面与国外差距较大。国内多数软件的生产方式还处于计算机时代的早期阶段，缺点很明显，主要表现在：1、透明度差；2、软件交付系统联调前只靠自检，质量得不到保证；3、用户对交付的软件可靠性缺乏信心。多数所谓的“软件测试”仅仅对几个预先指定的用例进行一下表演就算通过。目前还没有像硬件那样完善的检验体系，交付软件的质量不高。典型统计表明，“开发阶段平均每千行代码有50-60个缺陷，交付后平均每千行代码有15-18个缺陷”，有时会留下严重隐患。

　　目前，软件可靠性管理方面还没有建立起具有权威性的管理体系和规范。比如，如何描述软件可靠性、如何测试、如何评估、如何设计、如何提高等。由于目前国内外对于软件可靠性模型的研究多集中在软件的研制阶段，而很少有涉及测试与评估阶段的可靠性模型，所以从事软件可靠性测试与评估研究是一个有理论价值和实际意义、并且存在一定难度的课题。

　　随着计算机软件编制的规范化，必然要将软件可靠性考核纳入科学、规范的轨道。具体表现在：1、在软件系统研制任务中，制定软件可靠性量化指标，使软件考核有明确的标准；2、建立完善的软件测试、可靠性信息收集系统，使在计算机软件开发中通过科学的软件测试不断减少缺陷；3、通过研究软件可靠性考核方法，制定相应的软件考核规程、标准；4、开发软件可靠性评估软件，使软件鉴定更加方便。

　　五.软件可靠性评估的定义

　　可靠性（reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。

　　软件可靠性（software reliability）是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的正确程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。但是实际上任何软件都不可能达到百分之百的正确，而且也无法精确度量。一般情况下，只能通过对软件系统进行测试来度量其可靠性。

　　这样，给出如下定义：“软件可靠性是软件系统在规定的时间内及规定的环境条件下，完成规定功能的能力”。根据这个定义，软件可靠性包含了以下三个要素：

　　1.规定的时间

　　软件可靠性只是体现在其运行阶段，所以将“运行时间”作为“规定的时间”的度量。“运行时间”包括软件系统运行后工作与挂起（开启但空闲）的累计时间。由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。

　　2.规定的环境条件

　　环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素，如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其它一切因素都是理想的。有了明确规定的环境条件，还可以有效判断软件失效的责任在用户方还是研制方。

　　3.规定的功能

　　软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，软件的运行剖面会有所区别，则调用的子模块就不同（即程序路径选择不同），其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。

　　在讲到软件可靠性评估的时候，我们不得不提到软件可靠性模型。软件可靠性模型（Software reliability model）是指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。

　　六.软件的缺陷和失效

　　缺陷（defect/fault）是指软件的内在缺陷。在软件生命周期的各个阶段，特别是在早期设计和编码阶段，设计者和编程人员的行动（如需求不完整、理解有歧义、没有完全实现需求或潜在需求、算法逻辑错、编程问题等）会使软件在一定条件下不能或将不能完成规定功能，这样就不可避免地存在“缺陷”。

　　软件一旦有缺陷，它将潜伏在软件中，直到它被发现和正确修改。反之，在一定的环境下，软件一旦运行正确，它将继续保持这种正确性，除非环境发生变化。此外，软件中的缺陷不会为因使用而“损耗”。所以缺陷是“无损耗”地潜伏在软件中。

　　如果软件在运行时没有用到有缺陷的部分，软件就可以正常运行且正确工作；若用到了有缺陷的部分，则软件的计算或判断就会与规定的不符从而使软件丧失执行要求的功能的能力。软件不能完成规定功能即“失效”（failure）或“故障”。对于无容错设计的软件而言，局部失效则整个软件失效。对于采取容错设计的软件，局部故障或失效并不一定导致整个软件失效。

　　判断软件是否失效的判据有：系统死机、系统无法启动、不能输入输出显示记录、计算数据有误、决策不合理以及其它削弱或使软件功能丧失的事件或状态。

　　七.软件的可靠性测试过程

　　完整的测试过程包括测试前的检查、设计测试用例、测试实施、可靠性数据收集和编写测试报告5个步骤，下面逐一对这5个步骤进行说明。

　　1.测试前的检查

　　在进行应用软件的可靠性测试前有必要检查软件需求与研制任务书是否一致，检查所交付程序和数据以及相应的软件支持环境是否符合要求，检查文档与程序的一致性，检查软件研制过程中形成的文档是否齐全、文档的准确性和完整性以及是否通过了有关评审。

　　根据软件行业的有关标准，我们知道，软件研制过程中形成的文档共有十六种：《系统和段设计文件》、《软件开发计划》、《软件需求规格说明》、《接口需求规格说明》、《接口设计文档》、《软件设计文档》、《软件产品规格说明》、《版本说明文档》、《软件测试计划》、《软件测试说明》、《软件测试报告》、《计算机系统操作员手册》、《软件用户手册》、《软件程序员手册》、《固件保障手册》、《计算机资源综合保障手册》。

　　应该注意：这里的《软件测试计划》、《软件测试说明》和《软件测试报告》是指研制方在研制过程中进行测试所形成的测试文档。原则上若软件规模不太大，某些文档可以合并。

　　这些检查虽然增加了工作量，但对于在测试早期发现错误和提高软件的质量是非常必要的。

　　2.设计测试用例

　　设计测试用例就是针对特定功能或组合功能设计测试方案，并编写成文档。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

　　一个典型的测试用例应该包括下列详细信息：

　　a.测试目标；

　　b.待测试的功能；

　　c.测试环境及条件；

　　d.测试日期；

　　e.测试输入；

　　f.测试步骤；

　　g.预期的输出；

　　h.评价输出结果的准则。

　　所有的测试用例应该经过专家评审才可以使用。

　　设计与选取测试用例集的第一步是对测试用例进行描述，这种描述是否权威、完整、可理解与规范化，则决定了该测试用例能否或多大程度上可以被操作人员、软件研制人员和试验鉴定人员所理解接受。所以，规范化的测试用例描述在软件测试与评估中具有重要的作用。

　　3.测试实施

　　做好上述准备工作后，就可以实施测试了。研制方交付的任何软件文档中与可靠性质量特性有关的部分，包括产品说明书、用户文档、程序以及数据都应当按照需求说明和质量需求进行测试。在项目合同、需求说明书和用户文档中规定的所有配置情况下，程序和数据都必须进行测试。

　　在测试中，可以考虑进行“强化输入”，即输入比正常输入更恶劣（合理程度的恶劣）的输入。如果软件在强化输入下可靠，只能说明比正规输入下可靠得多。

　　为了获得更多的可靠性数据，应该采用多台计算机同时运行软件，以增加累计运行时间。

　　4.可靠性数据收集

　　软件可靠性数据是可靠性评估的基础。应该建立软件错误报告、分析与纠正措施系统。按照相关标准的要求，制定和实施软件错误报告和可靠性数据收集、保存、分析和处理的规程，完整、准确地记录软件测试阶段的软件错误报告和收集可靠性数据。

　　用时间定义的软件可靠性数据可以分为四类：1、失效时间数据，记录发生一次失效所累积经历的时间；2、失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；3、分组数据，记录某个时间区内发生了多少次失效；4、分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。

　　每个测试记录必须包含充分的信息，包括：

　　a.测试时间；

　　b.含有测试用例的测试计划或测试说明；

　　c.所有与测试有关的测试结果，包括所有测试时发生的故障；

　　d.参与测试的个人身份。

　　5.编写测试报告

　　测试活动结束后必须编写《软件可靠性测试报告》，对测试项及测试结果在测试报告中加以总结归纳。编写时可以参考GJB 438A-97中提供的《软件测试报告》格式，并应根据情况进行剪裁。测试报告应具备下列内容：

　　a.产品标识；

　　b.使用的配置（硬件和软件）；

　　c.使用的文档；

　　d.产品说明、用户文档、程序和数据的测试结果；

　　e.与需求不相符的项的列表；

　　f.测试的最终日期。

　　这种规范化的过程管理控制有利于获得真实有效的数据，为最终得到客观的评估结果奠定基础。

　　八.结束语

　　本文针对软件的测试与可靠性评估方法进行了专门地研究。当然，最好的软件可靠性评估方法是完全用现场试验的方法。评估软件的可靠性受到许多客观条件限制，其中最大的限制就是可靠性信息不足。所以应该利用构成软件的各个模块的历史可靠性试验信息统计评估全系统的可靠性。这需要：收集到足够的软件以及各个模块的历史可靠性试验信息；各个模块与软件的可靠性关系明确；各模块寿命类型已知；以及软件研制部门的配合（因为软件历史信息数据主要由研制方掌握）。

 

第二篇：软件工程大作业选题

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.

44. 进销存管理系统 仓储管理系统 实验室设备管理系统 学校门诊管理信息系统 学校后勤物资管理系统 书店销售管理系统 游泳馆会员管理系统 车辆租赁管理系统 在线考试系统 学生成绩在线发布系统 网上教学系统 选课管理系统 班主任工作管理系统 网上校友通讯系统 电视节目查询系统 网上购物系统 客户资源管理系统 保险信息管理系统 报纸发行员投递管理系统 毕业设计管理系统 学生公寓管理系统 学校卫生管理系统 田径运动会管理系统 中学生档案管理系统 工资管理系统 职工考勤管理系统 外聘教师管理系统 客房信息管理系统 物流公司管理系统 企业人事档案管理系统 社区管理系统 劳务代理收费系统 数字图书馆系统 远程教学平台系统 网上机票订阅系统 网上投稿系统 BBS系统 网上书店 小区物业管理系统 人才市场管理系统 邮局订报管理系统 教学管理系统 客户用电管理系统 人力资源管理系统

要求：学生根据选题设计一个数据库应用系统，并编写系统设计报告，内容包括：设计一个数据库应用系统，编写系统设计报告，

设计过程如下：

1 项目准备

1.1 项目选题

1.2 组建团队

1.3 团队工作方式

1.4 项目进度安排

2 项目管理（自学教材第13章）

2.1 项目管理的范围

2.2 利用Microsoft Project对项目进行时间管理

3 需求分析

3.1 需求分析的基本概念

3.2 需求分析阶段的具体实施过程

3.2.1 确定项目的大体方向

3.2.2 详细获取需求

3.2.3 讨论并确认需求

3.2.4 以需求规格说明书为基点，将需求文档化

3.2.5 整合需求规格说明书

3.3 Kernel会议管理系统需求规格说明书

4 软件设计

4.1 软件设计的基本概念

4.2 软件设计的具体实施过程

4.2.1 功能模块设计

4.2.2 系统数据设计

4.2.3 需求迭代

4.3 Kernel会议管理系统设计说明书

5 软件实现

5.1 软件实现的基本概念

5.2 软件实现的具体实施过程

5.2.1 程序的注释

5.2.2 规范化的源代码布局和命名规范

5.2.3 挖掘IDE的强大功能

5.2.4 软件的目录划分

5.3 Kernel会议管理系统编码规范

6 软件测试

6.1 软件测试的基本概念

6.2 软件测试的具体实施过程

6.2.1 第一阶段：测试准备阶段

6.2.2 第二阶段：单元测试阶段

6.2.3 第三阶段：集成和系统测试阶段

6.3 Kernel会议管理系统测试报告

7 用户手册

7.1 一切从用户的角度出发

7.2 用户手册应该写些什么

7.3 编写用户手册的技巧

7.3.1 图文结合

7.3.2 操作截图

7.4 Kernel会议管理系统用户手册

8 配置管理

8.1 配置管理的基本概念

8.2 为什么需要配置管理

8.3 配置管理的方式

8.3.1.一种原始的文件共享的方式

8.3.2 采用专业的软件配置管理工具

8.4 配置管理需要注意的问题

8.4.1 一天一个版本

8.4.2 日志和记录

8.4.3 上传操作文件之前一定要确保正确性

四、设计成果的编制

1、设计报告一份；

课程设计报告撰写的基本要求是报告原则上不少于8000字，其正文至少包括如下几个方面的内容：

封面：包含的内容：

《软件工程 项目设计》

设计题目：

指导教师：

正文部分：

（1）系统概述（现状分析，系统目标等）

（2）系统分析部分（必需）

1）需求分析

2）业务流程图（重点）

3）数据流程图（重点）

4）数据字典

（3）系统设计部分（必需）

1）ER图设计（重点）

2）逻辑结构设计（关系模式）

3）存储文件格式设计（数据库结构设计）写出建立数据库及每个表的建表程序，包括约束（主键、外键、自定义）、索引、视图。

4）制定该项目的备份恢复计划 （写出代码）

（4）详细设计

（5）实现和测试