软件工程实验5.云大
云南大学软件学院
实验报告
课程名称：软件工程学期：2009年秋季学期指导老师：
学号：姓名: 班级：软件工程日期：成绩：
实验五软件检验和有效性验证
【实验目的和要求】
1明确软件检验和有效性验证的相关基本概念、方法和两者间区别
2掌握单元测试、集成测试、发布测试、压力测试、性能测试、组件测试、测试案例设计和自动化测试的相关基本方法
3了解形式化方法在软件检验和有效性验证中的作用和基本方法。
[实验内容]
1概述软件检验和有效性验证的基本概念，并阐述两者区别。
验证(verification)和确认( validation )是软件测试的两个主要工作内容。
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立
的需求的过程；
2.程序正确性的形式证明，即采用形式理论证明程序符号设一计规
约规定的过程；
3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、
服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)
1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来
证明软件的正确性；
2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实
软件是否存在问题。
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细
设计文档，当然软件测试的主要对象还是源程序。
从不同的角度出发，软件测试可以划分为不同的分类：
从是否关心软件内部结构和具体实现的角度划分
A.白盒测试
B.黑盒测试
C.灰盒测试
从是否执行程序的角度
A.静态测试
B.动态测试。
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.验收测试
E.系统测试
2讨论并回答单元测试、集成测试、发布测试、压力测试、性能测试、组件测试、测试案例设计和自动化测试的基本概念和基本方法。
单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各
种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块
可以平行地独立进行单元测试。
单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错
误处理通路测试。
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：
(1) 输入的实际参数与形式参数的个数是否相同；
(2) 输入的实际参数与形式参数的属性是否匹配；
(3) 输入的实际参数与形式参数的量纲是否一致；
(4) 调用其他模块时所给实际参数的个数是否与被调模块的形参个相
同；
(5) 调用其他模块时所给实际参数的属性是否与被调模块的形参属性
匹配；
(6) 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲
一致；
(7) 调用预定义函数时所用参数的个数、属性和次序是否正确；
(8) 是否存在与当前入口点无关的参数引用；
(9) 是否修改了只读型参数；
(10) 对全程变量的定义各模块是否一致；
(11) 是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
(1) 文件属性是否正确；
(2) OPEN/CLOSE语句是否正确；
(3) 格式说明与输入输出语句是否匹配；
(4) 缓冲区大小与记录长度是否匹配；
(5) 文件使用前是否已经打开；
(6) 是否处理了文件尾；
(7) 是否处理了输入/输出错误；
(8) 输出信息中是否有文字性错误；
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
(1) 不合适或不相容的类型说明；
(2) 变量无初值；
(3) 变量初始化或省缺值有错；
(4) 不正确的变量名（拼错或不正确地截断）；
（5）出现上溢、下溢和地址异常。
除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因
错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径
测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包
括：
（1）误解或用错了算符优先级；
（2）混合类型运算；
（3）变量初值错；
（4）精度不够；
（5）表达式符号错。
比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：（1）不同数据类型的对象之间进行比较；
（2）错误地使用逻辑运算符或优先级；
（3）因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
（4）比较运算或变量出错；
（5）循环终止条件或不可能出现；
（6）迭代发散时不能退出；
（7）错误地修改了循环变量。
一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出
错处理通路同样需要认真测试，测试应着重检查下列问题：
1)输出的出错信息难以理解；
2)记录的错误与实际遇到的错误不相符；
3)在程序自定义的出错处理段运行之前，系统已介入；
4)异常处理不当；
5)错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
单元测试过程
一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。
提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
集成测试方法
集成测试应该考虑以下问题：
1) 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢
失；
2）各个子功能组合起来，能否达到预期要求的父功能；
3）一个模块的功能是否会对另一个模块的功能产生不利的影响；
4）全局数据结构是否有问题；
5）单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
压力测试:
压力测试主要是为了发现在一（任意）定条件下软件系统的性能的变化情况。通过改变应用程序的输入以对应用程序施加越来越大的负载（并发，循环操作，多用户）并测量在这些不同的输入时性能的改变，也就是通常说的概念：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也可以称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
压力测试方法:
压力测试分为如下大概
（1）确定存量数据的规模（用户一般会要求制造出3－5年的存量数据）；（2）确定需要进行压力测试的业务（一般是用户使用最频繁，或者业务操作复杂的业务）；
（3）确定操作用户的的数量、各类操作用户的比例；
（4）峰值业务量的要求（一般是1个小时内最多要处理的笔数）；（5）对实时业务响应时间的要求（如在峰值情况下，单笔业务的处理时间（如小于60秒））；
（6）对于批量处理过程的时间要求（如进行日终（月终、年终）处理、与外系统间批量数据传输时的时间）。
以上信息，通常需要业务人员来确定。、
为了进行压力测试的技术准备，需要如下资料：
（1）系统概要设计（了解系统技术架构，确定测试方法）；
（2）如果自己开发接口程序，需要了解接口报文规范；
（3）数据库设计（我们需要据此编写程序，准备存量数据）。
为了开发脚本需要了解如下信息：
（1）操作手册（脚本录入或者手工开发脚本）；
（2）参数化脚本（动态化数据需要进行关联）；
（3）脚本回放（验证脚本是否可以成功的创建数据）。
测试场景：
（1）单用户运行压力测试场景；
（2）多用户运行测试场景
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
性能测试方法
在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。
开发阶段后期，在应用程序中的bug已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试(peak-rest test)，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。
但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间(think-time)），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。
基准测试
基准测试的关键是要获得一致的、可再现的结果。
性能规划测试
对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。
渗入测试
渗入测试是一种比较简单的性能测试。
峰谷测试
峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。
自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
自动化测试方法：
1. 自动化测试的前提条件
1) 软件需求变动不频繁。
2) 项目周期足够长。
3) 自动化测试脚本可重复使用。
2. 自动化测试的过程
1) 自动化测试需求分析。
2) 自动化测试框架的搭建。
a. 公用的对象。
b. 公用的环境。
c. 公用的方法。
d. 测试数据。
3) 自动化测试脚本的编写
4) 脚本的测试与试运行
功能性自动化测试的主流工具：HP-Mercury QTP, Rational Robot, IBM Functional Tester, Selenium, SilkTest等。
每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。
回归测试策略方法：
1、测试用例库的维护
(1)、删除过时的测试用例
(2)、改进不受控制的测试用例
(3)、删除冗余的测试用例
(4)、增添新的测试用例
2、回归测试包的选择
(1)、再测试全部用例
(2)、基于风险选择测试
(3)、基于操作剖面选择测试
(4)、再测试修改的部分
3、回归测试的基本过程
(1). 识别出软件中被修改的部分；
(2). 从原基线测试用例库T中，排除所有不再适用的测试用例，
确定那些对新的软件版本依然有效的测试用例，其结果是建
立一个新的基线测试用例库T0。
(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。
(4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分
测试的软件部分。
(5). 用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证修改工作本身。
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别测试输入、操作步骤、预期结果.
测试用例设计方法：
1）等价类方法
2）边界值方法
3）因果图方法
4）流程图方法
3结合第14章内容，回答怎样对气象台系统进行单元测试测试、集成测试、压力测试、回归测试和如何设计测试案例。
面相对像的测试方法：
气象数据采集系统描述如下：气象台发送概要气象数据，这些数据由仪器采集并被送到气象数据采集系统；这些数据包括地面和空气中温度的最大、最小和平均值，气压的最大、最小和平均值，风速的最大、最小和平均值，总的降雨量以及每隔5 分钟采样的风向；气象数据采集系统通过调制解调器建立与气象台间的联系，并整理和请求传输数据；
气象台每隔一个小时就会接到一个报告请求，但这个频度在不同的气象
台间可能是不一样的，而且会随着技术和需求发生变化。系统中的对象我们给出具有代表性的5个类实例如图2所示，其中Ground thermometer、WeatherData和Ground thermometer代表了应用域对象，而Anemometer和Barometer是从系统描述和脚本描述中识别出来的。
这些对象应用于系统体系结构中的不同层次。Weatherstation对象提供气象台与其环境之间的基本接口。它的操作反映在图3 中给出的交互。它使用一个单一对象类来封装所有这些交互，而在其他设计中，使用多个类提供系统接口。Weatherstation对象只有一个属性，即它的标识符。这是一个常量，在气象台安装时被设定。因此，只需要检查它是否已经被设置。你需要为reportWeather、calibrate、test、startup 和shutdown设计测试用例。理想情况下，应该孤立地测试这些方法，但是，在某些情况下，还需要对操作序列进行一些测试，举例来说，为测试shutdown操作，需要先执行startup方法。
为了要测试气象台的状态，需要使用如图3 所示的状态模型。
图3气象台状态图
使用这个模型就能识别出要测试的状态的变迁序列，并定义事件序列来强制执行这些变迁。原则上，应该测试每个可能的状态变迁序列，虽然实际执行起来成本很高。该系统中应该测试到的状态序列的例子包括：
Shutdown->waiting->shutdownWaiting->calibrating->testing->transmitting->waitingWaiting —>collecting->waiting->summarising->transmitting->waiting如果使用了继承，对象类测试的设计就更加复杂。超类中提供的操作被多个子类继承，测试要求所有的子类都要得到测试，每个子类中的所有继承的操作也要得到测试。原因在于继承的操作是基于对其他操作的假设，而这些操作会在继承时发生改变。同样，当一个超类操作被覆盖时，重写的操作一定要测试。在面向过程软件测试中使用的等价划分的概念也可以应用到对象类上。那些使用对象相同属性的测试会归入相同的等价划分集合中。因此，对对象类属性进行初
始化、访问、更新的等价划分就能被识别出来。
2.2 对象集成测试
当面向对象的系统时，集成的层次并不明显。明显的是操作和数据被集成到对象和对象类中了，对这些对象类的测试与单元测试是一致的。在面向对象的系统中，没有与模块测试直接等同的测试过程。然而，Murphy 认为一组对象类通过组合行为提供一组服务，它们应该一起测试，即所谓集群测试。在面向对象的系统中，不存在自顶向下的和自底向上的集成。在这些系统中，没有一个明显的“顶层”为集成提供目标，也不存在一个清晰的层次结构来组织对象。因而集群需要根据对象操作以及对象属性的关联来构成。在面向对象系统的集成测试中有3 个可用的方法：①用例或基于场景的测试用例或场景描述了对系统的使用模式。测试可以根据场景描述和对象集群来制定，对象集群支持用例，用例反映使用模式；②线程测试线程测试根据系统对特别输入或一组输入事件的响应来进行。面向对象的系统通常是事件驱动的，因此，这是一个特别合适的测试形式。为了使用这个方法，需要了解清楚事件处理是如何在系统中进行的；③对象交互测试测试交互对象组的相关方法是由Jorgensen和Erickson提出来的。他们提出了集成测试的中间层概念，这个中间层是通过找出“方法-消息”路径来完成的。这些路径是对象交互序列。他们还找出一个相关的结构，称之为“原子系统功能(ASF)”。一个A S F 由一些输入事件跟随一个M M ( M e t h o d —Message)路径构成，该路径终止于一个输出事件。这与实时系统中的线程概念相一致。基于
场景的测试通常是这些方法中最有效的方法，因为它是这样组织测试过程的，先测试那些最
平常的场景，不寻常的或异常的场景放在稍后测试。这样做符合测试的基本原理，即最大的测试努力应该用于系统最常用到的部分。
图4收集气象数据的顺序图
为了说明基于场景的测试，使用气象台系统作为例子。场景可以从设计的用例中来，但是这些用例包含的测试信息不够，为了补充这些用例使之可用于测试规划，需要用交互图来更详细地说明对象是如何完成一个场景的。图 4 给出了气象台在响应一个采集数据请求时的操作序列。你可以使用交互图找出将要测试的操作和测试用例的设计。由此能看到发出一个上报数据请求产生以下方法线程来执行：
commsController:reques->WeatherStation:report->WeatherData:wummarise
当选择场景设计系统测试时，保证对每个类中的每个方法至少执行一遍是非常重要的。因此，应该做一个对象类及其方法的核对清单，当选择了一个场景时，得到执行的方法用记号标记出来。当然，不可能运行完方法的所有组合，但这样做至少保证了所有的单个方法已经被测试过。
同样，序列图也能用来找出测试中需要的输入和输出，方法包括：①输入一个上报数据请求，应该得到一个确认的回复，而且最后要有一个报表返回。在测试的时候应该产生汇总数据用来检查报表的数据是否正确。②向WeatherStation发出上报数据输入请求，eatherStation将产生一个汇报表。它可以隔离地测试这个过程，通过事先构造对commsController测试用的原始数据，这数据与汇总表使用的原始数据是一致的，检查WeatherStation对象产生的汇总是否正确。③这个原始数据也用来测试WeatherData对象。
图 4 中给出的是一个经过简化的顺序图，去掉了异常情况，一个完全的场景测试一定要将这考虑进去而且保证这异常能被对象正确的处理。
（说明：本体参考了论文：《面向对象软件测试在气象数据采集系统中的应用》作者王海燕，吴晓燕）
软件工程习题及详细答案
个人收集整理勿做商业用途 软件工程习题及答案 一、选择题： 1. 为了提高测试的效率，应该。 A、随机地选取测试数据 B、取一切可能的输入数据作为测试数据 C、在完成编码后制定软件的测试计划 D、选择发现错误可能性大的数据作为测试数据 2. 与设计测试数据无关的文档是。 A、需求说明书 B、设计说明书 C、源程序 D、工程开发设计 3. 结构设计是一种应用最广泛的系统设计方法，是以为基础、自顶向下、逐步求精和模块化的过程。 A、数据流 B、数据流图 C、数据库 D、数据结构 4. 概要设计的结果是提供一份。 A、模块说明书 B、框图 C、程序 D、数据结构 5. 需求分析是由分析员经了解用户的要求，认真细致地调研、分析，最终应建立目标系统的逻辑模型并写出。 A、模块说明书 B、软件规格说明书 C、工程开发计划 D、合同文档 6. 注释是提高程序可读性的有效手段，好的程序注释占到程序总量的。 A、1/6 B、1/5 C、1/4 D、1/3 7. 变换型和事务型是程序结构的标准形式。从某处获得数据，再对这些数据作处理，然后将结果送出是属于。 A、变换型 B、事务型 8. PAD（Problem Analysis Diagram）图是一种工具。 A、系统描述 B、详细设计 C、测试 D、编程辅助 9. 分层数据流图是一种比较严格又易于理解的描述方式，它的顶层描绘了系统的。 A、总貌 B、细节 C、抽象 D、软件的作者 10. 数据流图中，当数据流向或流自文件时，。 A、数据流要命名，文件不必命名 B、数据流不必命名，有文件名就足够了 C、数据流和文件均要命名，因为流出和流进数据流是不同的 D、数据流和文件均不要命名，通过加工可自然反映出
软件工程实验1-软件测试
电子与信息工程学院实验报告 班级学号姓名吴前斌同组 实验课程：软件工程 实验项目：软件测试 实验日期：2019 年10 月22 日
程序执行流程图如下图1所示； 1 2 3 4 5 6 7T F T F 图1 路径1：1、4、6、7 测试用例不存在 路径2：1、4、5、6、7 测试用例a= -1,b=0,x=3路径3：1、2、4、6、7 测试用例a=2,b=1,x=3 路径4：1、2、3、4、6、7 测试用例a=2,b=0,x=4
路径5：1、4、5、7 测试用例a=-1,b=0,x=0 P42-1: 首先点击工具条的【连接到文件夹】按钮，打开连接到文件夹对话框，选择实验数据所在目录，单击【确定】按钮，实现所需要的文件夹在目录树中显示出来，如下图1所示； 图1 接着在该文件夹下建立个人地理数据库单击【新建】、【个人地理数据库】，并且命名为“沈阳”，之后在该个人地理数据库中新建一个要素集，右击个人地理数据库单击【新建】、【要素数据集】，在打开的对话框中输入“shenyang”，如下图2所示； 图2 接着在要素集下选择一个为“Xi‘an 1980”地理坐标系，如下图3所示；
图3 接着点击个人地理数据库，新建一个要素类命名为“路灯”，如下图4所示； 图4 点击新建好的路灯要素集，选择【导入】、【要素类（多个）】，导入实验所需要的实验数据\1\vector文件夹下的street.shp，donut.shp（shift多选）单击确定即可，展示的效果如下图5，图6、图7、所示； 图5 图6
图7 P42-2: 首先打开arcmap连接个人地理数据库TEXT1.mdb，接着在图层中添加库中的road、street、river这个三个要素，使用滚轮放大缩小进行查看，如下图1、图2所示； 图1 图2 点击图标arctoolbox工具进行添加一个新的工具箱，工具箱命名为“personal”，接着导入一些常规的工具即可，如下图3、图4所示。 图3 图4
软件工程实验报告
软件工程实验报告 姓名：冯巧 学号 实验题目：实验室设备管理系统 1、系统简介: 每天对实验室设备使用情况进行统计，对于已彻底损坏的作报废处理，同时详细记录有关信息。对于有严重问题（故障）的要即时修理，并记录修理日期、设备名、修理厂家、修理费用、责任人等。对于急需但又缺少的设备需以“申请表”的形式送交上级领导请求批准购买。新设备购入后立即对新设备登记（包括类别、设备名、型号、规格、单价、数量、购置日期、生产厂家、购买人等），同时更新申请表的内容。 2、技术要求及限定条件: 采用C#语言设计桌面应用程序，同时与数据库MySql进行交互。系统对硬件的要求低，不需要网络支持，在单机环境下也能运行，在局域网环境下也能使用。方案实施相对容易，成本低，工期短。 一：可行性分析 1、技术可行性分析 计算机硬件设备，数据库，实验室设备管理软件与实验室设备管理系统的操作人员组成，能够实现实验室设备管理的信息化，提高工作效率，实现现代化的实验室设备管理。系统需要满足实验室设备管理（包括对实验设备的报废、维修和新设备的购买）、实验室设备信息查询（包括按类别进行查询和按时间进行查询）、实验室设备信息统计报表（包括对已报废设备的统计、申请新设备购买的统计和现有设备的统计）。这些功能框图如下图所示： 2、经济可行性分析 依据用户的现实需求、技术现状、经济条件、工期以及其他局限性因素等等因素，考虑到工期的长短、技术的成熟可靠、操作方便等因素，本方案具备经济可行性。
3、系统可选择的开发方案 ①方案A用C#开发系统的特点是：开发工具与数据库集成一体，可视化，开发速度较快，但数据库能够管理的数据规模相对较小。系统对硬件的要求低，不需要网络支持，在单机环境下也能运行，在局域网环境下也能使用。方案的实施相对容易，成本低，工期短。 ②方案B：以小型数据库管理系统为后台数据库，该前台操作与数据库分离，也能够实现多层应用系统。系统对硬件的要求居中，特别适合在网络环境下使用，操作方便。但系统得实现最复杂，成本最高，工期也较长。 二：软件需求分析 1．软件系统需求基本描述： 实验室设备管理系统是现代企业资源管理中的一个重要内容，也是资源开发利用的基础性工作。实验室设备在信息化之前，在用户系统管理、设备维修管理、设备的增删改查管理等方面存在诸多不利于管理的地方，不适应现代的企业管理形势和资源的开发利用。 2．软件系统数据流图（由加工、数据流、文件、源点和终点四种元素组成）： 1)顶层数据流图 2）二层流程图 3)总数据流图
软件工程实验报告4
软 件 工 程 项 目 分 析火 车 票 售 票 系 统 姓名：杨如意 学号: 111100 班级：2010级JA V A一班 院系：计算机与信息工程学院软件工程（JA V A方向）
火车票售票系统 一、项目概述 1.1项目简介 火车票售票系统是一款针对全国各大乘客集散地，方便工作人员和乘客顺利抵达目的地的便捷操作软件，乘客集散地只需安装本系统，配备专业的操作人员，即可安全、有序地完成人员输送任务。 1.2项目功能 火车票售票系统可登记全国各地的客运专线、包括发车时间、到达时间、经过各中转站时间、在各中转站等待时间及发车时间、各站点间距离、票价、各列车车厢容量、座位分布、列车类型、列车车号、车票信息、预定信息、乘客身份信息、乘客携带物品限定信息、车票代售点信息、网络购票、货运信息、网络购票常见问题解决方式、铁路常识等。 1.3功能模块介绍 车票票面信息：包含乘车区间（始发站、终点站）、发车时间、发车日期、乘客身份信息（身份证号、姓名）、乘客所乘列车座位信息（列车车厢号、座位号）、乘客乘车须知、票价、座位类型（硬座、硬卧、软座、软卧）。网络购票信息：查询列车信息（列车时刻表、列车车次）、余票信息、票价信息、退票信息、列车正晚点信息、车票代售点信息、预订信息、货运运费、货运业务咨询。 列车信息：列车车次、列车所属类型（普快、动车、空调特快等）、列车始发站、终点站、中转站、始发时间、到达时间、各站点停靠时间、乘车区间及价格、列车运行时长、已运行时长。 候车室信息：列车车次、列车运行时间（发车时间、到达时间）、对应车次所在候车区域、对应区域所要发车车次。 1.4系统运行要求 该系统主要是针对输送长途旅客。对于后台程序的运行，只需植入到电脑中，由经过培训的售票员操作，熟悉操作流程，对各问题所需操作及应用到的模块等综合问题的解答。 二、可行性研究 2.1可行性研究过程 本系统是针对全国各地的旅客，因此这一问题的解决，这一项目的实现，将更简化整个操作流程，减少人工操作以及由人工操作所引起的人为失误，大大降低了对数据的操作量。本系统所需的是项目人员的研究及整个
软件工程习题及答案
软件工程习题及答案
软件工程习题及答案 一、选择题： 1. 为了提高测试的效率，应该。 A、随机地选取测试数据 B、取一切可能的输入数据作为测试数据 C、在完成编码后制定软件的测试计划 D、选择发现错误可能性大的数据作为测试数据 2. 与设计测试数据无关的文档是。 A、需求说明书 B、设计说明书 C、源程序 D、项目开发设计 3. 结构设计是一种应用最广泛的系统设计方法，是以为基础、自顶向下、逐步求精和模块化的过程。 A、数据流 B、数据流图 C、数据库 D、数据结构 4. 概要设计的结果是提供一份。 A、模块说明书 B、框图 C、程序 D、数据结构 5. 需求分析是由分析员经了解用户的要求，认真细致地调研、分析，最终应建立目标系统的逻辑模型并写出。 A、模块说明书 B、软件规格说明书 C、项目开发计划 D、合同文档 6. 注释是提高程序可读性的有效手段，好的程序注释占到程序总量的。 A、1/6 B、1/5 C、1/4 D、1/3 7. 变换型和事务型是程序结构的标准形式。从某处获得数据，再对这些数据作处理，然后将结果送出是属于。 A、变换型 B、事务型 8. PAD（Problem Analysis Diagram）图是一种工具。 A、系统描述 B、详细设计 C、测试 D、编程辅助 9. 分层数据流图是一种比较严格又易于理解的描述方式，它的顶层描绘了系统的。 A、总貌 B、细节 C、抽象 D、软件的作者 10. 数据流图中，当数据流向或流自文件时，。 A、数据流要命名，文件不必命名 B、数据流不必命名，有文件名就足够了 C、数据流和文件均要命名，因为流出和流进数据流是不同的 D、数据流和文件均不要命名，通过加工可自然反映出
软件工程测试实验
淮海工学院计算机科学系实验报告书 课程名：《软件工程》 题目：软件测试实验 班级：软件121 学号：2012122722 姓名：朱德坤
软件测试验报告要求 1目的与要求: 1）系统学习和理解结构化软件工程实现阶段的基本概念、原理、技术和方法； 2）掌握软件测试的基本技术和方法，特别是白盒测试与黑盒测试技术和方法； 3）通过实验，要逐步提高白盒测试与黑盒测试技术的实际应用能力； 4）熟悉C++编程环境下编写、调试单元代码的基本操作技术和方法； 5）按照实验题目要求独立完成本次试验任务，严禁拷贝、抄袭他人设计成果； 6）认真书写实验报告（要求给出完整的测试信息，如测试程序、测试用例，测试结果分析等），并于5月5日以前提交。 2 实验内容或题目 1.选择结构化详细设计试验中自己设计的某一具有代表性控制结构模块（含有分支和循环结 构），并用C语言实现（提前准备好，每种测试用例分别写在作业本上，上机时带上检查），而后分别完成下述2、3、4各题测试用例设计和测试结果分析； 2.采用白盒测试技术中逻辑覆盖方法（至少包含语句覆盖、判定覆盖、条件覆盖、条件组合 覆盖）设计测试用例，完成测试（测试屏幕截图）和测试结果分析； 3.采用白盒控制结构测试技术的基本路径测试和边界测试方法设计相应测试用例，并完成测 试和测试结果分析； 4.采用黑盒测试技术中的等价类划分方法设计相应测试用例（可重选适合黑盒测试技术的模 块），并完成程序测试和测试结果分析； 3 实验步骤与源程序 程序流程图:
流图：
程序: //拥有超级用户superuser，密码zdk #include
软件工程实验报告最终版
合肥师范学院实验报告册 2012 / 2013 学年第一学期 系别计算机科学与技术系 实验课程软件工程 专业计算机科学与技术 班级2010级计算机应用 姓名马军福董国运李思贤 学号1010411024 1010411008 1010411076 指导教师范庆春
实验一：结构化方法建模的基本应用 1．实验目的 （1）了解Visio工具软件的功能特色、安装、工作环境和基本操作等基本知识； （2）掌握应用Visio工具的基本使用方法和基本绘图操作； （3）熟悉结构化分析建模的基本应用。 2．实验内容 （1）使用Visio 建立期刊管理系统的实体-关系图； （2）使用Visio 建立期刊管理系统的数据流图。 3. 实验要求 使用Visio 建立期刊管理系统的实体-关系图、数据流图。数据流图要绘 制三层。 4.实验结果和体会 （1）需求陈述 在图书管理系统中，管理员要为每个读者建立借阅账户，，账户内存储读者的个人信息和借阅记录信息。持有借阅卡的读者可以通过管理员借阅、归还期刊，读者可通过互联网或图书馆内查询终端查询期刊信息和个人借阅情况，以及续借期刊。 借阅期刊时，先输入读者的借阅卡号，系统验证借阅卡的有效性和读者是否可继续借阅图书，无效则提示其原因，有效则显示读者的基本信息。然后输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息。最后提交借阅请求，若被系统接受则存储借阅纪录，并修改可借阅图书的数量。归还期刊时，输入读者借阅卡号和期刊号，系统显示读者和期刊的基本信息供管理员人工审核。如果有超期借阅或丢失情况，先转入过期罚款或期刊淘汰处理。然后提交还书请求，系统接受后删除借阅纪录，并登记修改可借阅期刊的数量。 期刊管理系统包括：1.读者信息管理a:借阅请求b归还请求c:查询请求d：修改自身信息2.期刊管理a：修改书目、出版日期、编辑b：增加书目数据、删除书目数据。3.期刊借阅a：增加所借读者信息b：删除所借读者信息4.期刊查询a：已借出图书列表b：未借出图书列表5.期刊的征订6.期刊内容登记题目、作者姓名、作者单位7.期刊内容查询
软件工程实验报告(总)
信息工程学院 软件工程实验报告 专业： 班级： 学号： 姓名： 指导老师：
实验一：软件开发的过程计划 实验课时：2课时 一、实验目的 项目计划的目的是为项目的研发和管理工作制定合理的行动纲领，以便所有相关人员按照计划有条不紊地开展工作。 ⑴估计项目的总体规模、工作量和成本。 ⑵制定项目计划，重点放在产品生命周期中的主要关键任务。 ⑶制定项目时间表和预算。 二、实验环境 1.硬件环境 P4以上的个人计算机环境，要求内存不少于512MB，硬盘不小于20G.。 2.软件环境 操作系统：Windows XP 数据库：Sql Server 2000以上或Access 2003以上 3.通用工具软件 通用绘图工具：MicroSoft V isio 2003以上 文本编辑工具：MicroSoft Word 2003以上 4.CASE工具 UML建模工具：Rational Rose 2000 三、实验要求、实验内容 1、实验要求： 在进行实验之前，必须掌握软件开发过程的一些基础知识，准备参考资料和阅读相关的过程模型的文档。 2、实验内容 熟悉RUP（Rational Unified Process）软件开发统一过程的思想，RUP（Rational Unified Process）是由Rational公司（现已是IBM公司的一部分）提出的过程模型，它软件工程史上最完整、最成熟、最优秀的过程模型之一。 学习软件开发的组织和管理，将项目开发各阶段的任务明确，掌握各阶段的里程碑，并熟悉相应的工具。
四、思考题 1、项目开发首先要做的事是什么？ 答：进行需求分析和定义，了解客户或用户的需求，然后再进行后续。 2、你认为该软件应具备的最重要的特性是什么。 答：安全性、实用性、灵活性。 3、你认为怎样分工是最合理的？ 答：该项目已经采取项目经理制，但是在具体开发过程中，情况也许会比预计的复杂，因此，在了解了各组员的工作风格的情况下，根据性格类型进行工作分配，比如：外向而且善于交流的，可以给他安排和客户交流沟通，让客户随时了解我们 的工作情况，并且反应客户的需求改变；为了让项目更好的组织和管理，可以采取 主程序员负责制；这样，在项目经理的带领下，内部安排主程序员和副程序员，工 作员有问题的话，内部自己解决，只要按时汇报工作就可以了。 五、实验内容： 项目背景 项目名称：银行计算机储蓄系统 随着社会经济的发展，XX银行的业务不断增长，传统的依靠手工的存取款业务办理方式已经不能满足不断增长的业务需求。其一，业务需求的增加需要消耗大量人力物力资源；其二，业务复杂化导致人工处理方式出错率增加，从而引起储户不满。一方面可以减轻银行业务员的工作量，另一方面可以减少工作的出错率，从而提高工作效率。现在计算机网络的告诉发现使越来越多的人更喜欢在网购物、在家存款取款。在这样的背景下，很明显现在的银行储蓄系统已经不能满足人们越益增长的需求，急切需要建立一个新的、高效的、方便的、互联的计算机储蓄系统。为解决此问题，拟为其开发计算机储蓄系统。 项目进度： 项目在项目经理的制度下，在整个开发过程中，树立“里程碑”，而且严格按照计划进行，各阶段任务必须完成，现把任务进度历程绘制如下：
(上课)软件工程实验一
实验指导书课程名称软件工程导论 学院信息工程学院 班级 学号 姓名 2018年 2 月 24 日
系统简介:某单位准备开发一个购买办公用品与设备的总务办公管理系统。办公用品的购买申请由各科室提出,由负责总务工作的办公室统一收集。其中,购买申请的金额低于500元(含500元)可以由总务办公室直接审批,而高于500元的购买申请由机构主管领导审批,批准的购买申请形成采购清单由采购员负责购买,同时应记录每次实际购买清单,进行入账。在提出购买申请时要包括下述数据:申请单位、物品名称、物品数量、预计价格、物品用途等。每次购买完成后应记录以下数据:物品名称、物品数量、价格、总金额、购买日期、经办人等。 案例二:火车票预订系统 系统简介:某高校后勤集团为了学生寒暑假返乡,办理代学生预订返乡火车票事务,订票必须提前三天办理,后勤订票处提前三天向火车站办理购票事务。订票处使用一台微机处理订票后购票事务,学生订票一次称为一个事务,由订票员将其输入在微机中,系统核实订单后,将订票信息记录放在订票库中。系统每天打印预订三天的购票单,并更新订票库。 请对以上系统进行业务流程分析后,绘制出该系统的系统流程图。 实验原理: 系统流程图就是描绘物理系统的传统工具。就是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等等)。表达的就是信息在系统各部件之间流动的情况,而不就是对信息进行加工处理的控制过程。 系统业务流程图的符号:
基本符号 系统符号实验过程与结果: 一、操作步骤: 1．运行Microsoft Office Visio 2010
2．选择流程图中的基本流程图模板 3．用鼠标选拉图标进行绘图 二、实验结果:
软件工程实验报告
1.1 实验一结构化需求分析 一．实验类型 图书馆管理系统 假定校图书馆需要你设计一个图书馆管理系统，要求包括以下功能： ●图书管理员可以管理馆藏图书，包括每本图书的藏书编号、书名、编著者、 ISBN号、出版社、出版时间、入馆时间、馆藏数量（如果馆藏数量为1,则标明为孤本图书）、在馆数量、学科类别等（或其它你认为有用的信息）； ●管理员可以查询、统计所有图书、每一类图书或每一本书的借阅记录； ●图书管理员可以管理所有读者的信息，包括读者类型（学生、教师、社会人 士）、姓名、图书证编号、办证时间、证件状态（正常、挂失、冻结）等信息； ●图书管理员可以查询和统计所有读者、每一类读者或每一个读者的借阅记录； ●读者可以通过本系统查询馆藏图书； ●读者可以通过本系统借阅读书。但对于孤本图书或在馆数量为1的图书则不 准外借； ●管理员可以对超期未归还图书的读者发送电子邮件进行提醒，对于超期一年 不归还图书的读者冻结其图书证； ●读者可以通地本系统归还图书。如果图书超期，则自动计算罚款金额。二．实验目的 1．掌握数据流的分析技术 2．掌握软件需求分析的过程和方法。 3．熟悉项目开发计划和需求规格说明书的制定方法。 三．实验内容和要求 1．用结构化数据流分析技术进行软件系统需求分析，得出系统的数据流图和数据字典。 2．正确运用图表工具进行表示。 3．按规范正确编写软件文档。
四．实验步骤 1．理解所承担项目的业务流程和业务内容。 本软件项目是面向中小型学校、单位机构对于图书管理的基于服务的一款便捷式软件。能满足一系列常用图书管理的功能模块，提供简介、准确的操作性，可以很大程度减少人为因素带来的数据错误，统计错误，系统逻辑错误。并且规模小，很容易进行推广。 ●本项目的参与对象有图书管理员及读者。 ●对于读者，能通过该软件浏览馆藏的所有图书。读者在图书馆找到自己喜欢 的书后，能自行通过该软件操作完成借阅操作。若读者是第一次借书，必须通过图书管理员进行添加读者记录，登记读者信息。读者在登陆后方能完成借阅操作，对于孤本图书（即图书馆中馆藏只有一本的图书）则拒绝进行借阅操作。在规定期限内，读者可以通过该软件完成还书操作，对于超期的图书，应将扣除一定罚款金额，对于超期一年不归还图书的读者冻结其图书证。 并且读者能修改个人信息。 ●对于图书管理员，能管理自己和比自己低一级管理权限的管理员。一级管理 员能完成维护管理员的基本信息和二级管理员的一切操作。二级管理员则能维护自己的信息和添加读者、添加图书的功能。管理员可以对超期未归还图书的读者发送电子邮件进行提醒，对于超期一年不归还图书的读者冻结其图书证； 2．按照系统的功能及性能要求，系统的作业范围等，确定软件系统的开发环境（操作系统、开发工具、程序设计语言等）。 根据软件编程经验，本系统将采用面向对象的设计方法，使用Eclipse开发工具，java窗体应用程序，操作系统使用Win8。 3．绘制数据流图、功能分析图等。
软件工程实验内容
实验指导(Experiments) 实验题目：在以下范围内任选一道题目或自定一个题目。
题目医院病房监护系统 在医院的病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的病症信号（组合）实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根 据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。
实验内容 实验一软件需求分析 1.实验目的： 1) 根据所选定题目进行需求分析工作； 2) 通过实例掌握结构化数据流分析技术； 3) 进行业务需求分析、用户需求、功能需求、非功能需求分析； 2.实验要求: 要求做到使用结构化数据流分析技术分析课题需求，写出详细的数据流图和数据字典，数据流图的基本处理的个数不得少与2 个。 3.实验内容: 用结构化数据流分析技术进行软件系统需求分析，得出系统得数据流图和数据字典。 4.实验步骤： 1) 通过相关途径进行需求分析。 2) 综合利用Internet 网和相关书籍整理并完善需求分析。 3) 画出系统数据流图。 4) 得出系统数据字典。 5.实验学时：3学时。 6.实验结果：上交实验报告。 实验二软件设计 1.实验目的： 1) 建立初始结构图； 2) 对初始结构构图进行改进、优化； 2.实验要求: 用面向数据流的软件设计技术，对上一实验的数据流图和数据字典，进行总体设计；要求做到对上一实验的软件需求进行软件结构设计。 3.实验内容: 主要解决实现该系统需求的程序模块设计问题。(包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。) 4.实验步骤： 1．首先确定系统总体设计方案。 2．完成系统的模块结构图及模块的功能说明 3．完成系统的接口设计 4．完成系统的数据结构设计 5.实验学时：2 学时。 6.实验结果：上交实验报告。
软件工程实验(四个实验)
武汉轻工大学 软件工程实验报告 院系：数学与计算机学院 班级：软件工程１５04 姓名: 赵佳璐 学号: 1５08100065 实验一结构化分析实验 １实验目得: 通过此实验了解结构化分析得特点与步骤,以及结构化分析所采用得基本图形工具。 2、实验内容： 假设您在一所职业高中工作,负责该校信息系统得建设与维护。财务科长请您研究用学校拥有得ｐc机生成工资明细表与各种财务报表得可能性。 ３、实验要求: 1．问题定义:请在这个阶段描述您需要解决得问题。包括用户面临得问题与预期得项目规模。最后生成一份问题定义报告书。 2．可行性研究:在这个阶段产生处理工资事务得大致过程,画出高层逻辑模型，并且画出相应得数据流图,建立数据字典。 3．对此系统进行成本效益分析。
4、实验步骤： 4、１问题定义报告书 １、项目名称:工资支付 2、问题描述: 该校一直由会计人工计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。今后学校规模将进一步扩大，人工计算工资得成本还会进一步提高。 3、项目目标: 1)研究开发费用较低得新工资支付系统得可能性。 4项目规模: 1)开发成本应该不超过７、2万元 5、初步设想： 1)用学校自己得计算机系统生成工资明细表与财务报表 ６、可行性研究： 为了更全面地研究工资支付项目得可能性,建议进行大约历时两周得可行性研究。这个研究得成本不超过400０元。 4、2可行性研究: 1、处理工资事务得大致过程： 1)每月月末教师把她们当月实际授课时数登记在课时表上,由各系汇总后交给 财务科，职工把她们当月完成承包任务得情况登记在任务表上,汇总后交给财务科。 2)两名会计根据这些原始数据计算每名教职工得工资,编制工资表、工资明细表 与财务报表。然后，把记有每名教职工工资总额得工资表报送银行。 3)由银行把钱打到每名教职工得工资存折上，同时把工资明细表发给每名教职 工。 2高层逻辑模型： 3、数据流图:
软件工程习题及参考答案
软件工程习题及部分参考答案 判断题 软件也会磨损和老化。（X） 完善性维护是提高或完善软件的性能。（√） 数据字典是对数据流图中的数据流，加工、数据存储、数据的源和终点进行详细定义。 （X） 软件是指用程序设计语言（如PASCAL ,C,VISUAL BASIC 等）编写的程序，软件开发实际上就是编写程序代码。（X） 软件模块之间的耦合性越弱越好。（√） 如果通过软件测试没有发现错误，则说明软件是正确的。（X） 快速原型模型可以有效地适应用户需求的动态变化。（√） 模块化，信息隐藏，抽象和逐步求精的软件设计原则有助于得到高内聚，低耦合度的软件产品。（√） 集成测试主要由用户来完成。（X） 确认测试计划应该在可行性研究阶段制定（X） 白盒测试无需考虑模块内部的执行过程和程序结构，只要了解模块的功能即可。（X） 软件概要设计包括软件系统结构设计以及数据结构和数据库设计。（√） 软件工程采用的生存周期方法就是从时间角度对软件的开发和维护这个复杂问题进行分解，将软件生存的时期分为若干阶段。（√） 系统流程图表达的是部件的信息流程，还表示对信息进行加工处理的控制过程。（╳） 模块越多，开发成本越小。（╳） 软件测试的目的就是证明软件没有错。（╳） PAD图在设置了五种基本的控制结构后，还允许递归使用。（√） 在进行了可行性分析后，需求分析就只需要解决目标系统的设计方案。(×) ＳＡ法是面向数据流，建立在数据封闭原则上的需求分析方法。(√) HIPO 法既是需求分析方法，又是软件设计方法。(√) 在面向对象的需求分析方法中，建立动态模型是最主要的任务。(×) 加工小说明是对系统流程图中的加工进行说明。(×) 判定表的优点是容易转换为计算机实现，缺点是不能够描述组合条件。(×) 需求分析的主要方法有SD 法、OOA 法及HIPO 法等。(×) 分层的DFD 图可以用于可行性分析阶段，描述系统的物理结构。(×) 信息建模方法是从数据的角度来建立信息模型的，最常用的描述信息模型的方法是E-R 图。(√) 用于需求分析的软件工具，应该能够保证需求的正确性，即验证需求的一致性、完整性、现实性和有效性。(√) PDL经常表现为一种"混杂"的形式,他不允许自然语言如英语的词汇与某种结构化程序设计语言(如Pascal,C,Ada等)的语法结构交织在一起.(X) 设计阶段的输出是编码阶段的输入.(√) 通过软件测试,可以发现软件中所有潜伏的错误.(X) 非结构化维护用于软件的配置中只有源代码维护.(√) 系统规格说明是系统分析和定义阶段生成的一种文档.(√) 数据流图的分解速度应保持较高.通常一个加工每次可分解为10~20个子加工.(X)
软件工程白盒测试实验
实验三软件测试（白盒测试） 预习报告 一、实验目的 1掌握覆盖率的计算方法。 2 掌握语句覆盖，分支覆盖(判定覆盖),条件覆盖，条件。 分支组合覆盖，条件组合覆盖，组合覆盖的含义及区别。 3 掌握使用各种覆盖法，设计测试用例的方法。 二、实验原理 1测试覆盖率 测试覆盖率是指用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。 测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。测试覆盖率包括功能点覆盖率和结构覆盖率。 功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。 结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。 (1) 语句覆盖率 语句覆盖率=至少被执行一次的语句数量可执行的语句总数*10% (2) 判定覆盖率 判定覆盖率=判定结果被评价的次数/判定结果的总数*100% (3) 条件覆盖率 条件覆盖率=条件操作数值至少被评价一次的数量/条件操作数值的总数*10% (4) 定/条件覆盖率 判定/条件覆盖率=条件操作数值或判定结果值至少被评价一次的数量/ (条件操作数值总数+判定结果总数) *100% (5) 条件组合覆盖率 条件组合覆盖率涤件操作数值至少被评价一次的数量/条件操作数值的所有组合总数*100% 2 逻辑覆盖 根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖(条件组合覆盖)、组合覆盖。 (1) 语句覆盖 语句覆盖是选择足够多的测试数据，使得程序中的每个可执行语句至少执行一次。语句覆盖的缺点是对程序执行逻辑的覆盖率很低。 为使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了，例如选择输入数据为:A=2,B=0,X=3,就可达到“语句覆盖”标准。 为使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了，例如选择输入数据为:A=2,B=0,X=3,就可达到“语句覆盖”标准。 (2) 判定覆盖 判定覆盖是通过设计足够多的测试用例，使得程序中的每一个判定至少获得一次
软件工程实验答案
实验一 实验内容： 1.上网了解查询软件工程网站和相关软件工程知识 2.了解软件工程环境概念、层次、组成和开发要求。 3.查询现有主流的软件工程工具及其功能、用途、特点及适用范围。 4.浏览CASE工具。通过互联网了解现有软件工程主流工具，完成表的内容。 表1-2软件工程工具分类
Firefly 开源奇葩： CVS 5、 1:自动化测试工具，其中有Web的，应用软件的，还有单兀测试的?以上具有代表］性常用的软件是： Sele nium, Watir, Winrunner, Loadr unner, Junit 等等 2:软件测试管理工具。代表性常用软件 有：Testdirector , ClearQuest 和bugzilla 等 6、版本控制工具；文档 分析工具；开发信 息库工具；逆向工 程工具；再工程工 具。 7、DbgView 调试信息查 看器 8、SFRE 9、gprof 上的存储目录以供客户端访问，这将带来 F /V 虫 定安全隐忠 Firefly服务器上的存储目录不用共享，对客户端不透明，客户端不可直接访问存储目录，使 系统更安全可靠 CVS采用C/S模式，不需要共享服务器上的存储目录，安全性较好 PVCS基于文件系统共享，而且需要以"可 写"的权限共享存储目录，存在较大的安全隐患VSS基于文件系统共享实现对服务器的访问，需要共享存储目录，这将带来一定安全隐患 5、提高测试人员的工作效率和质量 6、 7、bgView调试信息查看器不仅仅能作为调试信息输出，而且可以作为一个信息输出软件，监视您的软件运行，目前支持mfc和windows 下dos信息输出. &从整体上支持该分析阶段的再工程自动化工具 9、用gprof对程序进行分析主要分以下三个步 骤： l 用编译器对程序进行编译，加上-pg 参数。 l 运行编译后的程序。 l 用gprof命令查看程序的运行时信 息 1-3
软件工程实验指导
软件工程实验指导书 适用专业：计算机科学与技术、软件工程、编写人： 信息技术学院 2012年8月
前言 软件工程实验是为计算机相关专业本科《软件工程》课程配套设置的，是《软件工程》课程讲授中一个重要的、不可或缺的实践环节。其目的是使学生能够针对具体软件工程项目，全面掌握软件工程管理、软件需求分析、软件初步设计、软件详细设计、软件测试等阶段的方法和技术，通过该课程设计使学生进一步理解和掌握软件开发模型、软件生命周期、软件过程等理论在软件项目开发过程中的意义和作用，培养学生按照软件工程的原理、方法、技术、标准和规范，进行软件开发的能力，培养学生的合作意识和团队精神，培养学生对技术文档的编写能力，从而使学生提高软件工程的综合能力，提高软件项目的管理能力。 按该课程的特点，实验内容包括软件开发的两大方法学的专题训练，即结构化（生命周期学）的方法学和面向对象的方法学，通过对一个简单项目，要求学生利用结构化软件开发技术或面向对象的软件开发技术完成对该项目的开发。因此设置五个实验项目，从项目发的准备工作，系统分析过程，系统设计过程，软件测试到系统实施，覆盖软件开发的整个过程，此外又引入我国国家《计算机开发规范》，以规范技术文档的书写标准，提高实验教学质量。 通过实验训练，达到如下目的： 使学生进一步了解和掌握软件工程原理，提高对实际项目的分析和设计能力，通过实验课程，熟悉和基本掌握软件工程方法学、软件开发的过程，文档资料的编写格式及规范，全面领会和贯通所学习的理论知识，从而培养学生综合运用所学课程知识，分析解决问题的能力，培养学生理论联系实际作风，实事求是，严肃认真的科学态度和良好的工作作风，为今后从事科学研究工作打下基础。
软件工程课后习题答案
软件工程课后习题答案 第一章 一、什么是软件危机？它有哪些典型表现？为什么会出现软件危机？ 软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。它包括两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。软件危机的典型表现： (1) 对软件开发成本和进度的估计常常很不准确。常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。这些都降低了开发商的信誉，引起用户不满。 (2) 用户对已完成的软件不满意的现象时有发生。 (3) 软件产品的质量往往是靠不住的。 (4) 软件常常是不可维护的。 (5) 软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。
(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。 (7) 开发生产率提高的速度远跟不上计算机应用普及的需求。软件危机出现的原因： (1) 来自软件自身的特点：是逻辑部件，缺乏可见性；规模庞大、复杂，修改、维护困难。 (2) 软件开发与维护的方法不当：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。 (3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。 二、假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？ 答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改， 不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”是在引入变动，当然付出的代价更高。一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
软件测试计划与测试分析报告软件工程大作业实验总结报告
河北北方学院软件件工程大作业软件测试计划与测试分析报告 [系统名称+版本]
版本变更记录
目录 第1章引言 (3) 1.1 编写目的 (3) 1.2 项目背景 (3) 1.3 参考资料 (3) 1.4 术语和缩略语 (4) 第2章测试概要 (5) 2.1 各阶段测试内容 (6) 2.2测试用例设计 (7) 2.3测试环境与配置 (7) 2.3.1功能测试 (7) 2.3.2性能测试 (7) 2.4测试方法和工具 (8) 2.5 需求的可追溯性 (8) 第3章测试内容和执行情况 (8) 3.1 项目测试概况表 (9) 3.2 功能 (9) 3.2.1 总体KPI (9) 3.2.2 模块二 (10) 3.2.3 模块三 (10) 3.3 性能（效率） (10) 3.3.1 测试用例 (11) 3.3.2 参数设置 (11) 3.3.3 通信效率 (11) 3.3.4 设备效率 (12) 3.3.5 执行效率 (12) 3.4 可靠性 (13) 3.5 安全性 (13) 3.6 易用性 (13) 3.7 兼容性 (13) 3.8 安装和手册 (14) 第4章覆盖分析 (14) 第5章缺陷的统计与分析 (15) 5.1 缺陷汇总 (15) 5.2 缺陷分析 (15) 5.3 残留缺陷与未解决问题 (15) 第6章测试结论与建议 (16) 6.1 测试结论 (16) 6.2 建议 (17)
项目基本信息
第1章引言 1.1 编写目的 [以下作为参考] 本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。 …… [可以针对不同的人员进行阅读范围的描述。什么类型的人可以参见报告XXX页XXX章节等。] 1.2 项目背景 本报告主要内容包括： [对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。] 1.3 参考资料 [需求、设计、测试用例、手册以及其他项目文档都是范围内可参考。 测试使用的国家标准、行业指标、公司规范和质量手册等等。]
软件工程实验一
实验报告（一） 课程名称_ 软件工程 __ 共页系别__ 计算机________________ 实验 1 日期年月日专业班级____ 08计算机科学与技术___ 实验报告日期年月日 姓名_ 辛杰彪 _________学号 200841402238 ___ 实验名称: 一.实验目的 借助参考资料及INTERNET的搜索功能，在更大的范围内接触多种软件开发模型实例，学会根据系统的不同功能选择合适的软件开发模型。 二.实验任务 选择列举两个或两个以上且不同的软件开发模型实例并加以分析。 三.实验要求 1、所选实例不可与教材的内容相同 2、各实例所选择的软件开发模型应不相同 3、对实例进行说明，即每个实例的阐述应包括：第一，系统概况（包括系统主 要功能及系统流程图）；第二，选用的开发模型（必须要分析选用原因） 4、书写“实验报告” 四.实验内容 案例一：基于模型设计的电池管理系统开发 1.功能分析： 功能需求：(1)对电池的电流电压、温度及模块电压进行测量; (2)对各种异常状况分级报警; (3)对电池组进行热管理; (4)与整车通过CAN进行总线通信;……
性能需求：(1)精确的计算电池的荷电状态，误差不超过10%（SOC, State of Charge）; (2)总电压的检测范围是250-440V，测量精度不低于±2V；…… 非功能需求：(1)电压电流单体电压采样周期为10ms，温度采样周期1ms; (2)电池状态信息每隔100ms发送一次; (3)电池状态信息发送满足DFEV_CAN_02标准(企标);…… 领域需求：(1)要有很强的抗干扰能力，系统要有一定的自检、自诊断、自修复功能; (2)要在很宽的电压范围内(24—14伏)工作; (3)能在-20℃—85℃下正常工作;(4)具有防尘、防潮等功能;…… 2选择快速原型的原因： 由于电池管理对于系统的要求比较高，如果用瀑布模型，什么都做好了，但是精确度例如电压的范围，如果不达到标准，不符合要求，要重做，这样的成本比较大。如果用快速原型的话， 如果发现系统不达标也可以马上改，这时候成本就比较低了。所以保险起见，还是选择快速原型的比较好。 案例二：构造银行业务模型 1.功能 用例增量 增量1：支票和储蓄账户的存款和取款 增量2：查询和转账 增量3：透支 每个增量内进行迭代：乐观的，正常的，悲观的 2.选择增量模型的原因 答：因为这个银行的业务是可以很明确分开的， 软件的每个功能之间是没什么太大联系，可以分开来做，增加了 灵活性，还有开发的难度，几个功能还可以同时开始，加快完成 的时间，风险降低，一个功能出错并不会影响到别的部分。所以 说，这增量模型是比较好的选择。
软件工程实验(四个实验)
武汉轻工大学软件工程实验报告 院系：数学和计算机学院 班级：软件工程1504 姓名：赵佳璐 学号：1508100065
实验一结构化分析实验 1实验目的： 通过此实验了解结构化分析的特点和步骤，以及结构化分析所采用的基本图形工具。 2.实验内容： 假设你在一所职业高中工作，负责该校信息系统的建设和维护。财务科长请你研究用学校拥有的pc机生成工资明细表和各种财务报表的可能性。 3.实验要求： 1．问题定义：请在这个阶段描述你需要解决的问题。包括用户面临的问题和预期的项目规模。最后生成一份问题定义报告书。 2．可行性研究：在这个阶段产生处理工资事务的大致过程，画出高层逻辑模型，并且画出相应的数据流图，建立数据字典。 3．对此系统进行成本效益分析。 4.实验步骤： 4.1问题定义报告书 1.项目名称：工资支付 2.问题描述： 该校一直由会计人工计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。今后学校规模将进一步扩大，人工计算工资的成本还会进一步提高。 3.项目目标： 1)研究开发费用较低的新工资支付系统的可能性。 4项目规模： 1)开发成本应该不超过7.2万元 5.初步设想： 1)用学校自己的计算机系统生成工资明细表和财务报表 6.可行性研究： 为了更全面地研究工资支付项目的可能性，建议进行大约历时两周的可行性研究。这个研究的成本不超过4000元。
4.2可行性研究： 1.处理工资事务的大致过程： 1)每月月末教师把他们当月实际授课时数登记在课时表上，由各系汇总后交给 财务科，职工把他们当月完成承包任务的情况登记在任务表上，汇总后交给财务科。 2)两名会计根据这些原始数据计算每名教职工的工资，编制工资表、工资明细 表和财务报表。然后，把记有每名教职工工资总额的工资表报送银行。3)由银行把钱打到每名教职工的工资存折上，同时把工资明细表发给每名教职 工。 2高层逻辑模型： 3.数据流图： 4.数据字典： 1) 名字：授课情况登记表 别名： 描述：记录每个教师的当月完成的课时及任务。 定义：授课情况登记表=教职工编号+姓名+职务+职称+基本工资+生活补贴+书报费+交通费+洗理费 位置：输出到打印机 2)