测试报告缺陷分析范例6篇

前言:中文期刊网精心挑选了测试报告缺陷分析范文供你参考和学习,希望我们的参考范文能激发你的文章创作灵感,欢迎阅读。

测试报告缺陷分析

测试报告缺陷分析范文1

自动化测试系统在敏捷开发、持续集成和持续交付中起着非常重要的作用。它对加快新功能,缩短现场问题解决时间,提升用户感受度,乃至提高企业竞争力都至关重要。本文结合笔者在自动化测试系统建设中的实践,具体描述了利用Python语言设计完成的基于机器人框架,关键字驱动的案例。最后指出了这套系统进一步改进的方向。

【关键词】自动化测试系统 机器人框架(Robot Framework,RF) 关键字驱动 Python

1 自动化测试系统实现简介

笔者参与开发的自动化测试系统,和编译服务器关联,由系统扫描侦测,实现基于某种策略的版本自动下载(最大频度测试,最相关版本测试,如包含本测试组发现的软件缺陷版本优先,或指定版本测试等),然后分发到相应设备,进行版本升级安装,触发测试用例的运行,生成测试报告,发送邮件给项目干系人,更新测试记录等。

自动化测试系统,能实现在第一时间触发测试,能更频繁地测试各个版本,能运行更多、更繁琐的测试,进而在缺陷出F时及时发现,帮助开发团队缩小缺陷出现的代码范围,便于定位问题,解决问题,这为敏捷开发持续集成,持续提供了强有力的支撑。

自动化测试系统,基于机器人框架(robot Framework,RF),RF有丰富的库,使用关键字驱动技术,可以实现循环,选择等逻辑,测试用例中支持变量的使用,测试人员可以创建自己需要的关键字,具有很大的灵活性和可扩展性,可以实现定制的复杂或特殊的功能。ride 是RF的编辑工具,测试用例可以用表格输入,使得测试人员以类似于自然语言的方式(关键字)来描述测试用例, 即使没有编程基础的测试人员也容易上手,而RF会将关键字转化为测试动作(底层即Python类方法,函数的调用)。

Python是一种面向对象、解释型、跨平台的高级程序设计语言,可以应用于自动化测试,数据分析等众多领域,Python用代码缩进来代替花括号,表示语句块逻辑层次,既使得源程序风格接近,又提高了可读性;Python的类库齐全并且产出率高,实现相同的功能,Python 比很多其他语言代码量少,这意味着易维护,出现问题的概率也下降。RF就是一种基于Python的可扩展关键字驱动的通用自动化测试框架。

2 Python语言在自动化测试系统中的应用

利用RF编写定制的测试用例,需要开发自己的关键字,编写自定义python库。下文通过一个实例来介绍这个过程。

首先,在python安装目录c:\Python27\Lib\site-packages\下新建一个文件夹NewUE,文件夹名就是库名,然后,在该文件夹内创建一个python文件ueclass.py,代码中定义一个UEClass类,类中定义了一个ue1Behavior方法,该方法即RF中的新关键字。

在NewUE文件夹内再创建文件名 __init__.py 文件,RF通过这个初始化文件获取新关键字类。它的类名和库名相同, 括号里的类是ueclass.py中定义的类:

fromueclass import UEClass

classNewUE(UEClass):

ROBOT_LIBRARY_SCOPE = 'GLOBAL'

自定义的NewUE库就创建好了,在RF的编辑器ride中导入这个库,然后即可使用新创建的关键字。如果要新增关键字ue2Behavior,只要在UEClass类中增加名为ue2Behavior的方法即可。

导入新库,若库名显示为黑色,表明导入成功,若红色则表明导入失败。可以通过在一个python文件中import NewUE来调试,通常可以根据出错消息提示框,排除源文件中的错误。修正错误后,把原来的 *.pyc 全删除,运行如下命令编译,然后重新导入:

python -m compileallueclass.py

python -m compileall __init__.py

如图1所示。

自动化测试系统的理想目标是全自动,在策略和任务定义好后,免予人工干预。为达到这一目标,需要实现RF和其他系统的配合。下文介绍在这套系统中开发的三个重要模块:下载,定制测试报告,邮件分发模块。

编译随时可能完成,系统需要有自动下载功能(关键字Auto_DL)以免浪费时间, 基本的过程如下, 首先系统处于空闲状态,即还未开始测试或上次测试任务已完成, Auto_DL会定时登录到指定服务器,检测是否有新版本编译完成,并判断该版本是否可用:按上文提及的某种特定的策略选择新版本,判断该版本是否符合自动化测试的最低要求,例如已通过冒烟测试,通过则可下载该版本,退出Auto_DL, 触发下一个环节,升级安装该版本。这个过程循环往复,以达到尽快测试符合策略的版本或尽可能多地测试各种版本等目的.本系统用Python 自带的标准模块urllib2, re实现新版本侦测和判断是否为可用版本,发送HTTP request,在获取的返回信息中,利用正则表达式标准模块re中的搜索函数findall和符合指定特征的正则表达式判断是否需要下载新版本;用Python 自带的标准模块ftplib实现文件下载, 直接导入ftplib,生成一个FTP对象,连接到ftp服务器, 以写模式在本地打开接收文件, 接收服务器上的文件并写入本地文件,最后关闭文件,完成下载工作。

下载完成后,系统自动安装并执行测试用例。RF能产生测试报告,但是无法定制测试报告,新开发的定制测试报告模块就是根据测试管理团队的特殊要求,提供符合需求的报告, 可以包括测试团队名字,测试时间,测试环境的硬件配置,软件版本信息, 测试用例运行结果汇总情况, 是否更新测试记录或需要进一步分析等。测试结果由网页和附件的形式发送给指定接收人。同时,除了测试结果文件,还提供超链接,可以查看测试日志等,特别是当测试用例失败后,测试人员可以进一步分析日志,确定是哪个领域出现了软件缺陷,对应的开发人员也可以根据日志,修正软件缺陷,提供新版本给测试人员再次验证。

定制报告生成后,需要发送测试结果,邮件发送模块利用Python 自带的标准库,smtplib, configparser, email等。为把数据和业务逻辑分离, 通常把邮件服务器地址,用户名,密码,发件人等写入配置文件, 在主程序中这些信息由configparser来解析,可以把主机名传递给SMTP构造函数,然后用smtplib.SMTP()创建一个smtp对象,用smtp.login()进行登录操作, 最后用smtp.sendmail()l送邮件,用smtp.quit()方法关闭连接。

Sendmail(sender,recipients,message)方法可用于发送电子邮件,参数Sender,recipients分别是邮件发送者和接收者地址列表,从配置文件中读取,参数Message是一个长字符串格式的消息,本模块中将网页形式的测试报告解析后作为邮件正文发送给接收方。创建MIMEMultipart对象,获取邮件主题等信息,创建MIMEText对象,读取网页文件内容,再用MIMEMultipart对象的attach,把网页文件内容包含到MIMEMultipart对象中。Sendmail()方法最终完成邮件发送。

改进方向:

本测试系统主要是回归测试,不可能完全取代手工测试,有些情况下不适合自动化测试,例如探索性测试,软件版本很不稳定,测试仪表未提供脚本控制接口等。产品新的功能开发完成后,一般先经手工测试,所以通常自动测试比手工测试发现的缺陷要少些,但由于RF的可扩展性,我们可以方便地将新测试用例加入到自动化测试系统里来,不断提高该系统的测试覆盖率。

另一方面,可以进一步提高自动化测试系统的智能,实现对日志文件的分析。测试专家了解预期测试结果,熟悉日志和缺陷的映射关系,根据日志可推断可能的错误分支,出错模块等。本系统拟增加日志分析模块,用于替代人工判断,利用Python强大的文本分析和正则表达式搜索功能,结合业务知识及测试专家的经验,对失败的测试用例日志进行分析,由系统给出日志分析结果。

3 结论

本测试系统主要用于发现已知的缺陷,确保新功能加入后原有功能不受影响。同时,由于自动化系统很方便进行相同测试用例的大量重复,进而可能发现手工测试不易检出的偶发问题。

由于新关键字易于扩展,随着产品功能的不断增加,测试用例集合也可以不断地扩充。由于RF的可扩充性,可以在自动化测试系统中增加新的模块,进一步提高系统的智能,大大提高测试效率并降低测试工程师重复劳动的强度。测试人员把精力放在深入理解业务逻辑,设计新测试用例,再把新用例应用于自动化测试系统中,进而形成测试工作的良性循环。

测试报告缺陷分析范文2

1 . 软件测试 的目的是尽可能多的找出软件的缺陷。( Y)

2 .Beta 测试是验收测试的一种。( Y)

Acceptance testing

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

3 .验收测试是由最终用户来实施的。( N )

是由测试人员来实施的

4 .项目立项前测试人员不需要提交任何工件。( Y ) 工件:加工过程中生产对象

5 .单元测试能发现约80% 的软件缺陷。( Y )

6 .代码评审是检查源代码是否达到模块设计的要求。( N )

代码评审也称代码复查,是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

7 .自底向上集成需要测试员编写驱动程序。( Y )

自顶向下综合测试的具体步骤为:

1 以主控模块作为测试驱动模块,把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;

2 依据所选的集成策略(深度优先或广度优先),每次只替代一个桩模块;

3 每集成一个模块立即测试一遍;

4 只有每组测试完成后,才着手替换下一个桩模块;

5 为避免引入新错误,须不断地进行回归测试(即全部或部分地重复已做过的测试)。

自底向上综合测试的步骤分为:

1 把低层模块组织成实现某个子功能的模块群(cluster);

2 开发一个测试驱动模块,控制测试数据的输入和测试结果的输出;

3 对每个模块群进行测试;

4 删除测试使用的驱动模块,用较高层模块把模块群组织成为完成更大功能的新模块群。

8 .负载测试是验证要检验的系统的能力最高能达到什么程度。( N )

负载测试(Load testing),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征。例如,响应时间、事务处理速率和其他与时间相关的方面。

9 .测试人员要坚持原则,缺陷未修复完坚决不予通过。( N )

10 .代码评审员一般由测试员担任。( N )

11 .我们可以人为的使得软件不存在配置问题。( N )

是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道,在软件建立时变更是不可避免的,而变更加剧了项目中软件开发者之间的混乱。

12 .集成测试计划在需求分析阶段末提交。( N )

执行阶段

1)时间安排 单元测试已经完成后就可以开始执行集成测试了

2)输入 需求规格说明书 概要设计 集成测试计划 集成高度设计 集成测试例 集成测试规程 集成测试代码(如果有) 集成测试脚本 集成测试工具 详细设计 代码 单元测试报告

3)入口条件 单元测试阶段已经通过基线化评审

4)活动步 骤 执行集成测试用例 回归集成测试用例 撰写集成测试报告

5)输出 集成测试报告

6)出口条件 集成测试报告通过集成测试阶段基线评审

二、选择题

1 .软件验收测试的合格通过准则是:(ABCD)

A . 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。

B . 所有测试项没有残余一级、二级和三级错误。

C . 立项审批表、需求分析文档、设计文档和编码实现一致。

D . 验收测试工件齐全。

2 .软件测试计划评审会需要哪些人员参加?( ABCD )

A .项目经理

B .SQA 负责人

软件质量保证(SQA)是建立一套有计划

目标 1: 软件质量保证工作是有计划进行的。

目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。

目标 3: 将软件质量保证工作及结果通知给相关组别和个人。

目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。

C .配置负责人

D .测试组

3 .下列关于alpha 测试的描述中正确的是:( AD )

A .alpha 测试需要用户代表参加

B .alpha 测试不需要用户代表参加

C .alpha 测试是系统测试的一种

D .alpha 测试是验收测试的一种

4 .测试设计员的职责有:( BC )

A .制定测试计划

B .设计测试用例

C .设计测试过程、脚本

D .评估测试活动

5 .软件实施活动的进入准则是:( ABC )

A .需求工件已经被基线化

工件加工过程中的生产对象。

基线化 一个文档如果经过讨论被通过了,被固定了,就可以说这个文档被“基线化”了,然后所有人就可以在这个“基线”的基础上工作。

B .详细设计工件已经被基线化

C .构架工件已经被基线化

D .项目阶段成果已经被基线化

三、添空

1. 软件验收测试包括:_正式验收测试,alpha测试,beta测试。

2. 系统测试的策略有:功能测试,性能测试,可靠性测试,负载测试,易用性测试,强度测试,安全测试,配置测试,安装测试,卸载测试,文挡测试,故障恢复测试,界面测试,容量测试,兼容性测试,分布测试,可用性测试

(有的可以合在一起,分开写只要写出15 就满分哦)

3. 设计系统测试计划需要参考的项目文挡有:_软件测试计划,软件需求工件和迭代计划。

4. 对

面向过程的系统采用的集成策略有:自顶向下,自底向上两种。

5. 通过画因果图来写测试用例的步骤为:

(1)根据程序规格说明书描述,分析并确定因(输入条件)和果(输出结果或程序状态的改变),画出因果图。

(2)将得到的因果图转换为判定表。

(3)为判定表中每一列所表示的情况设计一个测试用例。

四、简答

1. 区别阶段评审的与同行评审

答:

同行评审目的:发现小规模工作产品的错误,只要是找错误;

阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性

同行评审人数:3-7人 人员必须经过同行评审会议的培训,由SQA指导

阶段评审人数:5人左右 评审人必须是专家 具有系统评审资格

同行评审内容:内容小 一般文档 < 40页, 代码 < 500行

阶段评审内容: 内容多,主要看重点

同行评审时间:一小部分工作产品完成

阶段评审时间: 通常是设置在关键路径的时间点上!

2. 什么是软件测试

答:测试是为发现错误而执行程序的过程

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。

3 简述集成测试的过程

答:系统集成测试主要包括以下过程:

1. 构建的确认过程。

2. 补丁的确认过程。

3. 系统集成测试测试组提交过程。

4. 测试用例设计过程。

5. 测试代码编写过程。

6. Bug的报告过程。

7. 每周/每两周的构建过程。

8. 点对点的测试过程。

9. 组内培训过程。

5 白盒测试有几种方法

答:总体上分为静态方法和动态方法两大类。

静态:关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

动态:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

6 系统测试计划是否需要同行审批,为什么

答:需要,系统测试计划属于项目阶段性关键文档,因此需要评审。

7Alpha 测试与beta 的区别

Alpha测试(α测试)是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

Beta测试(β测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

答:Alpha 测试 在系统开发接近完成时对应用系统的测试;测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成,不能由程序或测试员完成。

Beta 测试 当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成,不能由程序员或测试员完成。

8 比较负载测试,容量测试和强度测试的区别

答:负载测试:在一定的工作负荷下,系统的负荷及响应时间。

强度测试:在一定的负荷条件下,在较长时间跨度内的系统连续运行给系统性能所造成的影响。

容量测试:容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据 的,并且它的目的是显示系统可以处理目标内确定的数据容量。

9 测试结束的标准是什么?

答:用例全部测试。

覆盖率达到标准。

缺陷率达到标准。

其他指标达到质量标准。

10 描述软件测试活动的生命周期?

答:

测试周期分为计划、设计、实现、执行、总结。其中:

计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;

设计:完成测试方案,从技术层面上对测试进行规划;

实现:进行测试用例和测试规程设计;

执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。

总结:记录测试结果,进行测试分析,完成测试报告。

11 软件的缺陷等级应如何划分?

A 类— 严重错误,包括以下各种错误:

1 . 由于程序所引起的死机, 非法退出

2 . 死循环

3 . 数据库发生死锁

4 . 因错误操作导致的程序中断

5 . 功能错误

6 . 与数据库连接错误

7 . 数据通讯错误

B 类— 较严重错误,包括以下各种错误:

1 . 程序错误

2 . 程序接口错误

3 . 数据库的表、业务规则、缺省值未加完整性等约束条件

C 类— 一般性错误,包括以下各种错误:

1 . 操作界面错误(包括数据窗口内列名定义、含义是否一致)

2 . 打印内容、格式错误

3 . 简单的输入限制未放在前台进行控制

4 . 删除操作未给出提示

5 . 数据库表中有过多的空字段

D 类— 较小错误,包括以下各种错误:

1 . 界面不规范

2 . 辅助说明描述不清楚

3 . 输入输出不

规范

4 . 长操作未给用户提示

5 . 提示窗口文字未采用行业术语

6 . 可输入区域和只读区域没有明显的区分标志

E 类— 测试建议

4 怎么做好文档测试

仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例。

检查文档的编写是否满足文档编写的目的

内容是否齐全,正确

测试报告缺陷分析范文3

申请者进行西瓜品种登记,首先需在中国种业信息网()下载填写西瓜品种登记申请表,同时充分准备的相关申请文件,向所属地(法人以注册地、自然人以身份证所在地为归属地)的省级农业主管部门提出申请(一般是省级种子管理站或局)或者直接在中国种业信息网的非主要农作物品种登记页面实名注册通过后进行申报。申请文件在省级农业主管部门受理后,一般20个工作日内,审查符合要求的,通知申请者提交申请品种的种子标样。在收到种子标样验收回执后,经农业部主管部门的审核批准,即可取得农业部核发全国有效、编号唯一的品种登记证书。

1 准备申请文件

申请品种登记需准备的文件材料,主要有以下内容:

1.1 品种选育情况说明

新选育的品种,在品种选育情况中需主要说明包括品种来源以及亲本血缘关系、选育方法、选育过程、特征特性描述、栽培技术要点等内容。同时,法人单位选育的品种,须由选育单位加盖公章确认;个人选育的品种,由选育者本人签字确认。已经在生产上大面积推广的地方品种或来源不明确的品种在进行标明后,也可不作品种选育说明。

1.2 品种特性说明

1.2.1 品种适应性 应根据不少于2个生产周期(试验点数量与布局应当能代表拟种植的适宜区域)的品种试验数据,如实描述以下内容:品种的形态特征、生物学特性、产量、品质、抗病性、抗逆性、适宜种植区域(注明县级以上行政区地名)及季节,品种的主要优点、缺陷、风险及防范措施等注意事项。

1.2.2 品质分析 应根据品质分析的结果,如实描述以下内容:品种的果实可溶性固形物含量、果皮硬度、果实肉质口感,以及其他特殊果实性状。

1.2.3 抗病性鉴定 应根据对品种的枯萎病抗性以及其他区域性重要病害的抗性进行鉴定,并如实填写鉴定结果。

枯萎病的抗性分5级标注:高抗(HR)、中抗(MR)、抗(R)、感(S)、高感(HS)。

1.2.4 转基因成分检测 目前西瓜品种登记需做品种不含有转基因成分的书面承诺。

1.3 特异性、一致性、稳定性测试报告

新选育品种的申报,需依据《植物品种特异性、一致性和稳定性测试指南--西瓜》的要求进行测试并取得测试报告。西瓜测试指标主要有以下内容:

植株:第1雌花节位、形态。叶片:颜色、裂刻程度。

果实:纵切面形状、重量、表面蜡粉有无/多少、表皮底色、条纹主要颜色、条纹类型、果皮硬度、果皮厚度、果肉颜色、果肉硬度。

种子(仅二倍体和四倍体):长度、种壳底色、种壳复色类型,果实单瓜种子数量(仅二倍体和四倍体),种壳大小(仅三倍体),倍性。

生育期及其他与特异性、一致性、稳定性相关的重要性状,形成测试报告。

品种标准图片:种子、果实外观及纵横剖面、成株植物等实物彩色照片。

1.4 其它有关申笄榭

对于申报品种登记所需的品种适应性数据;品质分析数据;抗病性鉴定数据和品种特异性、一致性和稳定性测试及品种性状关联基因的检测报告,具备试验、鉴定、测试和检测条件与能力的单位(或个人)可自行组织实施,取得相关数据后进行申报,单位(或个人)不具备上述条件和能力的,可委托具备相应条件和能力的单位组织进行试验后取得有关试验报告,相关报告由被委托单位的试验技术负责人签字确认,由出具报告的单位加盖公章。

已获得植物新品种保护授权的品种,在申请品种登记时,还需要取得品种权人同意登记的书面认可。

2 提交种子样品

申请品种登记的文件经省级农业主管部门书面审查符合要求的,申请者接到通知后需及时提交种子样品。对申请了植物新品种保护且已受理的品种,按规定可不需再提交种子样品。

每个申报品种提交的种子样品数量为300 g。提交的种子样品,必须是遗传性状稳定、与登记申请的品种性状完全一致、未经过药物或包衣处理、无检疫性有害生物、质量符合国家种用标准的新收获种子。

种子样品要求用有足够强度的纸袋包装,并用尼龙网袋套装;包装袋上标注作物种类、品种名称、申请者等信息。提交的种子样品,还须附有申请者签字盖章的种子样品品种真实性承诺书及种子样品清单。申请者须对其提供种子样品的真实性负责,并承担因提供虚假样品所产生的一切法律责任。

测试报告缺陷分析范文4

关键词:国产化平台;信息系统;软件测试

计算机软硬件实现自主可控是国家重要的发展规划,近年来国产化软件平台取得了长足发展,操作系统、数据库、办公软件、中间件等均已出现不少商用国产化产品,为信息系统能够采用国产化平台进行研发奠定了基础。软件测试作为软件研发领域中的重要一环,直接影响软件产品质量,一直备受重视[1]。软件测试与软件开发紧密相连,软件研发采用国产化平台实现,这对软件测试有着重要的影响,决定着软件测试所需要的技术,因此研究国产化平台下的软件测试具有重要意义。相比于非国产化软件平台,国产化软件平台起步晚,发展时间短,其对应的软件测试技术也比较欠缺,尤其是在配套的测试软件方面。本文通过分析软件测试关键活动,根据国产化软件测试技术现状,提出一种适应于国产化平台信息系统软件测试技术。

1信息系统软件测试分析

信息系统软件测试在不同研发模型中所分阶段不同,而区别于不同的研发模型,整个软件测试过程一般都需要经过测试策划、测试设计、测试执行、测试总结四个基本活动。测试策划活动主要进行需求分析,识别软件测试项、测试所需软硬件、人力资源等;测试设计活动主要根据识别的软件测试项设计测试用例,包括手工测试用例、自动化测试用例等;测试执行活动通过手工、自动执行测试,发现软件缺陷,进行软件缺陷归零验证;测试总结活动对测试执行结果进行整理分析,编写测试报告。同样的,基于国产化平台研发的信息系统软件测试亦需要经过测试策划、测试设计、测试执行、测试总结四个活动。1)测试策划活动进行需求分析、识别软件测试项依赖于软件自身需求,其与研发平台具有无关性,识别测试所需的软硬件则取决于研发平台。目前国产化平台的测试工具也面临着起步晚、发展时间短的问题,应用于国产化平台的软件测试工具种类远没有丰国产化平台软件测试工具丰富[2]。测试策划过程中需要识别出可用于国产化平台的测试软件是其要解决的重要问题,一方面取决于已有的测试软件,另一方面取决于信息系统的技术实现。2)测试设计活动所编写的手工测试用例取决于被测信息系统软件自身,而编写自动化测试用例则取决于所使用的自动化测试平台,不同的自动化测试平台所适用的软件类别不同。基于国产化的自动化测试平台选择范围小,且成熟度相比于非国产化平台并不高。因此测试设计阶段所面临的是被测信息系统软件的可实现自动化测试的用例覆盖程度问题。3)测试执行活动一方面是执行测试用例,另一方面还需要对软件缺陷进行分析定位,对被测信息系统的内存、CPU、网络、磁盘IO等指标进行监控,其对国产化平台依赖性较高。国产化平台的操作系统、数据库、中间件乃至办公软件所提供的分析、监控工具直接影响着软件测试的执行和软件缺陷的分析定位。目前,国产计算机环境的应用面、规模相对较小,应对复杂环境时,兼容性、综合性能、可靠性验证不充分,缺乏有效的诊断分析工具和测试评估环境[1]。测试执行过程中面临着如何充分利用国产化平台所提供的分析和监控工具完成测试执行、如何通过第三方辅助软件解决国产化平台自身不具备的功能完成测试执行的问题。4)测试总结活动为测试过程的最后一个活动,对测试执行的结果进行整理分析。对于国产化平台研发的信息系统,测试总结需要分析前几项测试活动的结果形成测试报告,还需要对测试技术形成积累,为基于国产化平台信息系统的软件测试持续发展提供经验。图1为信息系统软件测试活动图以及基于国产化平台进行软件测试活动的所要解决的关键问题。

2软件测试技术应用

2.1测试策划

国产化平台信息系统软件测试策划活动所面临的主要问题是识别测试所需软件项,应用于项目,需要结合项目自身特点。每个项目的系统架构、软件开发语言、运行环境等各不一样,因此在识别时结合被测软件,从三个方面解决测用所需软件:开源软件[3]、商用软件、自研软件。图2所示在项目测试过程中开源软件、商用软件、自研软件选择比重,其中开源软件选择优先,其次可通过自研软件、商用软件覆盖测试所需。1)开源软件具有成本低、灵活性高、自由的优势,国产化平台信息系统识别测试所需软件项可以优先从开源软件中选择,获取满足项目软件功能测试、性能测试、接口测试、安全测试、可靠性测试等测试类型的开源软件。2)开源软件在支持方面、文档方面、稳定性方面不如商业软件,对于测试软件要求高的项目可选择商用软件进行支撑。商用软件具有支持度高、日常更新、技术难度低的优势,采用商用软件可以避免测试过程中的一些无法解决问题。3)商用软件所提供的是适用于大多数用户需求的接口,对于被测软件,在不同的测试阶段、不同测试类型中,存在商用软件无法实现测试内容的场景,需要项目通过研发专用测试工具以实现测试覆盖,解决测试软件问题。

2.2测试设计

测试设计过程中可以通过编写自动化测试用例代替手工测试的反复操作,自动化测试用例覆盖率高可以有效地提高测试用例复用率和执行效率。基于国产化平台信息系统软件自动化测试在采用的自动化测试平台上,可以通过不同维度的测试用例设计增加自动化测试用例覆盖率,即分别从单元测试、接口测试、GUI测试分别设计自动化测试用例[4]。自动化软件测试用例设计一般遵循图3所示的三角形用例覆盖率比例,单元测试与代码直接相关,软件代码改动对单元自动化用例的影响较小,单元测试自动化用例覆盖率最高,其次是接口测试自动化用例。GUI自动化测试用例实现难度高,且受代码改动影响大,因此其自动化测试用例覆盖率最低。国产化平台信息系统软件自动化测试平台缺少QTP、Loadrunner等工具,目前只有少数自动化平台支持国产化操作系统,如kylinTOP自动化测试工具,除此之外,还可以采用Selenium、Python等实现自动化测试。此类软件对于GUI自动化测试与非国产化软件类似,因此国产化平台信息系统自动化测试用例亦需要遵循图3的测试用例覆盖率。

2.3测试执行

在测试执行过程中需要对信息系统软件缺陷进行分析定位、对信息系统的指标进行监控。信息系统的缺陷分析和指标监控包括两部分,一部分与依赖的国产化平台相关,另一部分与信息系统软件自身相关。与国产化平台相关的缺陷分析和指标监控可以采用国产化平台自持软件,目前国产操作系统、国产数据库软件、国产中间件软件等均具备满足监控平台自身指标的工具[5]。基于国产化平台的第三方测试工具如WGCLOUD、PIGOSS、SugarNMS等可以实现多平台、分布式监控。表1为这三款工具软件可支持的国产化平台以及可用于信息系统软件测试的监控项。

2.4测试总结

测试总结活动是对之前几项测试活动的总结,在测试执行完成后对各项测试活动进行整理分析,形成测试报告。基于国产化平台的信息系统软件研发还未广泛开展,对应的软件测试技术也需要不断的探索与研究,相比于非国产化平台的软件测试,国产化平台信息系统的软件测试不再仅限于单一项目,还需要与其他项目的测试策划相关联。因此测试总结活动还需要以资源池的形式进行技术积累,将整个测试过程中的软件测试方法、测试工具、测试分析等进行技术储备与传播,为其他国产化平台的软件测试提供借鉴。同样的,在其他项目的软件测试策划活动中,可以从资源池中的技术储备选取用于支撑整个项目测试的技术。

测试报告缺陷分析范文5

关键词:软件工程;教学改革

软件工程是一门综合性程度高、知识面广、实践性强的系统学科。开设软件工程学科的目标,是为了培养具有工程能力、综合素质、扎实专业技术基础、良好团队协作能力及职业道德的复合型人才。

一、教学现状

学生因缺乏项目实施经历,在软件工程课堂内并没有体会,到了工作岗位,经历几年实践,才会对软件工程学有领悟。软件工程入门要求较高,学生在前期必须掌握程序语言、数据库技术、开发工具、系统平台等,如何针对不同专业方向的学生开展教学工作是一个巨大考验。本文改革涉及教学内容与学生工程能力评定、教学实践等方面。

二、教学改革探讨

1.教学内容与学生能力评价体系:根据美国计算机学会制定的软件工程学科要求,掌握软件工程理论的最小子集包括软件过程与生命周期模型、需求分析、软件设计与进化、测试与评估、项目管理、软件工具和环境。现有的教材,极少在一本教材上对上述内容进行全面覆盖。按照上述教学内容,对学生在实践项目中的表现做出如下能力等级认定。1.1软件过程与生命周期模型1。软件过程定义包括项目类型定义、项目规模定义、项目风险识别、项目文档的规范模板。根据需求类型、项目风险、项目类型、用户类型、团队类型进行项目生命周期选择。分为如下5个等级:1.1.1理解软件过程流程图,理解风险识别与分析活动,理解常见软件生命周期模型;1.1.2根据教师提供的项目生命周期模型选择表,从瀑布型、迭代型、增量型模型中做出选择;1.1.3选用适合的标准过程文档模板,包括过程管理类、项目研发类、项目管理类,并采用svn等工具对文档进行版本控制;1.1.4理解风险管理活动,确定风险来源,识别风险,确定风险优先级别,建立风险行动计划,跟踪风险;1.1.5分解工作任务,制定完整的项目计划书,采用project、Git等工具进行跟踪管理。1.2需求分析与需求管理2。包括开展需求调研活动,理解用户需求,产生《用户需求说明书》。进行需求分析与定义,形成基于UML建模的产品需求规格说明书。对《产品需求规格说明书》进行评审与确认。需求管理内容包括对《用户需求说明书》、《产品需求规格说明书》进行评审。需求管理员建立与维护《需求跟踪矩阵》,确保需求一致性。需求管理员建立和维护需求跟踪矩阵,管理需求变更。根据上述知识范畴,分为如下5个等级:。1.2.1理解用户需求,理解需求规格说明书内容;1.2.2通过访谈、调查、网络收集、同类类比、征询建议等方式进行需求调查,形成《用户需求说明书》;1.2.3采用UML用例图、活动图、顺序图等方式进行建模,形成符合模板的《产品需求规格说明书》;1.2.4能识别需求描述不一致、有二义性的地方,根据需求检查单确认;1.2.5能根据需求跟踪矩阵,按照已建议、已接受、已分析、已实现、已验证需求项的状态来跟踪管理,在系统设计、编程、测试等阶段对工作产品进行跟踪,更新和维护《需求跟踪矩阵》。1.3软件设计与软件进化4。可通过强调设计规范、增设设计模式内容,以极小易懂的程序为出发点,通过持续改进,让学生理解版本改动的原因,会评价一个设计的好与坏。分为如下5个等级:1.3.1理解软件设计活动,理解概要设计、详细设计、数据库设计方案;1.3.2理解面向对象方法设计原则,能用UML类图表达设计;1.3.3根据需求文档,能产生实体-联系图,将实体间关系转化为表间约束,尽量优化表结构;1.3.4能够基于复用、可维护的考虑,进行一定程度的软件重构;1.3.5撰写数据库设计、概要设计说明书,执行设计规范、编程规范。1.4测试与评估。制定测试计划,编写测试用例,规定输入与预期输出结果、测试步骤。执行测试用例,进行测试分析,形成测试报告。分如下5个等级:1.4.1理解需求,编写系统测试用例,合理运用等价类分析、边界值分析等设计方法;1.4.2理解设计,编写集成测试用例和单元测试用例,能搭建测试环境,手动执行,并记录测试结果。理解缺陷管理,发现缺陷,填写测试报告并执行回归测试;1.4.3能使用自动化测试工具,编写测试脚本,运行脚本执行测试,将发现的问题进行报告。使用Bugfree等工具管理和维护缺陷,确保项目提交时,缺陷的状态均为关闭;1.4.4能使用大型测试管理工具进行测试计划、测试管理、跟踪需求、设计等变更对测试的影响;1.4.5采用工具进行性能测试、安全性测试、压力测试等方面,能够进行测试场景设计、脚本编写、执行和报告。1.5软件工具和环境。工具包括建模工具、开发工具、测试工具、配置管理工具、项目管理工具等6。分为如下3个等级。1.5.1在工程类活动中采用建模工具、开发工具、测试工具;1.5.2在管理活动中采用配置管理工具、项目管理工具进行项目策划、风险监控、项目监控活动;1.5.3能够根据团队人数和项目情况,选择适合项目特点的工具。1.6项目管理。强调人员、产品、过程、质量的关系,包括项目策划、项目跟踪与监控、项目风险与管理、软件质量保证、项目配置管理等。分为如下2个等级:1.6.1理解项目过程管理,定期召开例会,编写个人周报,会议纪要,进行问题追踪,坚持执行规范;1.62理解项目立项策划、项目监控、风险及结项管理,并从团队实践项目中进行组织级总结。上述六个关键内容上,不要求学生在每个活动上能力认定都达到几,可通过每个关键活动上分别评定,最后计算加权平均值的方法,折算学生的最终成绩。2.教学措施。避免一言堂式教学方式,创造引导和探讨式、学生自启发式教学模式。可采取以下措施:2.1教学采用小班制教学,学生分为三五人制团队,自我管理和团队合作完成实践项目。2.2引导学生自拟实践题目,协助定义软件过程,协助制定软件进度计划,并提供软件标准文档模板和工程标准规范。2.3引导学生在每周召开例会,完成对项目跟踪追溯。例会的内容可加入软件技术的规范、风险意识的培养和训练、软件文档写作等内容。2.4教学案例可选用一般信息管理案例讲述,项目知识不宜超出学生认知范围。2.5专家来访,引入课堂。营造良好的学习氛围,企业工程师与学生分享和交流工程应用、企业管理方面的最佳实践和教训,培养学生工程意识。2.6结合学生不同专业方向,对实践案例做出选择。软件测试方向重在理解需求、掌握软件测试工具、软件测试管理工具、自动化测试、性能测试工具和测试报告写作。嵌入式方向重在嵌入式平台使用、设计模式、UI设计、UML与软件设计、手机客户端和服务器设计实现、嵌入式数据库应用方面。游戏设计方向重在游戏策划、工程标准和规范、游戏引擎工具、项目管理工具、版本控制工具、游戏测试等方面。2.7启发学生学习新技术,包括大数据、交互设计、CMMI能力成熟度模型及标准。

三、结语

本次课程改革集中在教学内容、教学措施、能力认定等方面。软件工程课程改革是一个长期和持续过程。在实施中取得的成效值得我们不断思考和总结。

参考文献:

[1]方智.面向对象编程思维的建立和培养[J].实验科学与技术,2013年06期.

[2]张海藩.软件工程导论(第6版)[M].北京:清华大学出版社,2013.

测试报告缺陷分析范文6

【关键词】软件测评 测评过程 测评方法

1 审计信息平台介绍

为了落实制约机制和监督权力作为审计的核心,加强反腐败体制机制创新和制度保障的要求,需要建设审计信息平台。该平台的总体目标是建立一个“统一、高效、实用”的工作信息系统,使其成为总公司及所属单位审计人员开展日常审计的平台,成为总公司和所属单位信息共享和信息交互的通道。审计信息平台系统主要是以信息化手段实现总公司及所属单位部分审计流程的规范化和标准化,固化业务流程,辅助各级领导和审计人员管理业务工作,衔接工作界面,细化操作实务,辅助审计工作,提升工作质量。

对于这样大规模的应用系统,具备了相当高的复杂程度、技术水平和开发成本。如果该系统存在缺陷,在使用过程中发生故障,都将造成不良影响。软件测评就是帮助用户解决应用系统的质量问题,作为系统上线前检查必要的质量保证手段,从而提高系统质量。软件测评不是系统开发方内部测试,也不是用户测试,而是由具有相关资质的独立的第三方测评机构,根据被测系统方的需求,依据相关国家标准、行业标准或国际标准对被测软件的质量进行全面的测试和评价。

2 软件测评

软件测评主要是利用人工或者自动化的方式,站在客观、第三方的角度,系统的尽可能多的发现被测系统中的错误,检查被测系统是否满足需求规格说明书或是达到预期结果,从而提高被测系统的质量。

软件测评相比软件测试更注重评审过程,在测试的每个阶段以及产生的相关文档都需要组织专家对其结果进行评审,对测试结果进行深入分析总结,制定应对措施积累经验。根据软件测试质量控制体系对测评活动全过程进行质量控制。因此要确保软件测评的充分性,获得良好的测评效果,建立一个完善的软件测评体系具有现实的紧迫性和重要性。

3 审计信息平台软件测评过程

针对审计信息平台的项目特点,根据越早测试越好的原则,本次软件测评的过程按照:软件需求制定、测评项目建立、测试需求分析和策划、测试设计和实践、测试执行和回归测试、测试总结和交付归档来进行。

3.1 软件需求制定

软件需求为软件开发奠定了基础,也是软件测评的重要依据,一份完善的需求规格说明书对开发和测试工作都是至关重要的。测评项目组引入了软件需求规格说明书的国家标准,并根据本企业和本项目特点对国家标准的需求规格说明书进行了落地,通过多方评审确定了最终版本。通过讨论会对需求规格说明书反复修改,协助研制方按照系统功能模块的划分逐步完成需求规格说明书。

3.2 测评项目建立

测评项目组按照测评任务和合同情况建立测评项目。首先项目组制定项目计划;项目组长与质量保证人员共同制定质量保证计划;项目组长与项目组配置管理员共同制定配置管理计划。然后项目组接受被测件,梳理测评需求,建立需求基线并进行配置管理。同时,质量保证人员对项目建立阶段进行符合性检查。

3.3 测试需求分析和策划

测评项目组开展测试需求分析,确定测试类型及其测试要求,分解测试项。建立测试项与测评需求的追溯关系,通过需求追溯表的形式实施。项目组进行测试策划,确定测试策略、技术方法、测试工作产品等。

3.4 测试设计和实践

该阶段主要是设计并编写测试用例。建立测试用例与测试项的追溯关系,通过需求追溯表的形式实施。按文档编制要求进行测试计划文档的编写。测试计划完成后需进行评审,并对经评审的测试计划进行修订,填写测试问题处理单进行变更控制。此外要对测试环境、测试工具等测试设备进行确认,对测试设备的配置、状态进行确认。还需开展就绪评审工作,对测评需求、项目进度、测试设备等情况进行跟踪,确定是否可以转入测试执行阶段。

3.5 测试执行和回归测试

测试执行阶段由测试执行人员在系统实际测试环境中执行测试用例,并记录测试结果。测试人员需判定测试用例是否通过,对不通过的测试用例进行判定,确认是否为软件问题。对于确认为软件问题的测试用例,经研制方修改后,测试方接收修改后的被测件。测试项目组复用或新增回归测试用例,开展软件更改的影响域分析,实施回归测试。质量保证人员对测试执行阶段进行符合性检查。

3.6 测试总结和交付归档

全部测试执行完毕,测试项目组整理测试记录并分析测试结果:编制需求追溯表,建立测试执行情况、软件缺陷与测试用例的追溯关系。之后测试项目组对测试工作和被测系统进行分析评价以及测试总结评审工作,包括对测评需求、项目进度、测试设备等情况进行跟踪,为编写测试报告做准备。准备完毕按照文档编制要求进行编写测试报告,并对报告评审。最终向客户交付测试报告正本,测试项目组对本项目全部文档记录进行整理归档。

4 审计信息平台软件测评方法

由于审计工作流程的复杂度高,因此对该平台的易用性要求也相应提高。故测评的测试类型主要体现在功能性、效率性、安全性、兼容性和易用性等质量特征上。

4.1 功能性测试

功能性测试主要检测软件是否符合《审计信息平台业务蓝图设计报告》和《审计信息平台系统开发需求规格说明书》中提出的用户功能需求。对于一般的用户测试而言,用户仅测试自己关心的功能点,且是正常使用,测试覆盖率往往只能达到20%左右。而对于非用户方和非开发方的第三方测试者来说,需要尽可能多的发现和使用软件的全部功能,对需求文档中的功能性需求逐项进行测试,要求输入值覆盖正常值的等价类、非正常值的等价类和边界值。因此,测试者不但要深入了解审计信息平台的各项功能用法和目的,还要熟悉审计业务流程。

根据审计信息平台系统功能特点,本系统分为综合管理模块、审计模块、内控制度管理模块和举报模块四部分。根据该软件需求规格说明书,为了保证测试的充分性,经过分析共有功能性需求27项。其中,审计模块为该系统的核心功能,在加强反腐败治理工作的今天,审计业务流程更为复杂、重要。审计管理主要包括审计项目管理、审计作业管理、审计治理管理、基础数据和统计报告五个功能。由此设计的测试项共16个,包括审计计划、项目归档、项目启动、人员考核、审前调查等。

4.2 效率性测试

效率性测试也就是我们平常所说的性能测试。性能测试的目的主要是获取审计信息平台在不同压力下系统的性能数据,寻找系统的瓶颈点;验证审计信息平台在30并发用户下系统的性能表现。在测试之前需要进行需求访谈,根据访谈结果制定测试计划和测试方案。根据用户提供系统交易量占比最高的前10个功能、业务逻辑比较复杂的功能,设定测试场景。例如:用户登录响应情况,大小附件上传下载,审批业务流程,以及上述场景的混合场景,混合场景的测试更能模拟系统在实际使用时的情景。测试时的环境也是至关重要的,测试环境要求与生产环境一致,否则测试结果就失去意义。因此需要在系统开发完毕,功能测试之后系统上线之前,在生产系统进行测试,且测试时测试系统需要与其他系统隔离,避免对其他系统造成影响。

4.3 安全性测试

企业的生产运行活动越来越离不开网络,很多重要的信息资料都在网络上传输,由此安全问题也越来越得到人们关注。不论是为了设计,还是为了实现所产生的安全漏洞,对于用户来讲都是无法容忍的。在审计信息平台系统上线前,对其进行安全测试是十分必要的。采取的测试安全测试方法主要有两种:利用Fortify进行静态的代码安全扫描,找出底层代码中存在的安全漏洞;利用AppScan进行动态渗透测试,这种方法是利用自动化测试工具模拟黑客入侵,从而找到系统在运行时会出现的安全漏洞,找出的问题真实有效。

4.4 兼容性测试

目前大多数办公软件都不需要安装,通过浏览器使用。审计信息平台用户只需在浏览器输入系统地址可直接登陆系统。因此对该系统的兼容性测试需测试:操作系统的兼容性和浏览器的兼容性。

操作系统的兼容性主要是测试Windows平台和Linux平台。浏览器的兼容性主要是测试IE浏览器、火狐浏览器、谷歌浏览器。一般在测试时,在不同平台和浏览器上,首先系统功能能够正常使用,其次界面和操作应基本相同。

4.5 易用性测试

审计信息平台作为审计监察部日常的办公软件,其易用性是不可忽视的。用户之前习惯使用监察管理系统、风险管理系统和内审作业管理系统。整合、统一后的审计信息平台应该符合用户已经形成的使用习惯。同时是否满足相关文档如软件需求规格说明书中规定的易用性要求,符合一般软件操作的隐含易用性要求也是需要测试的。在测试中从用户的角度出发,考查人机交换界面的设计,以非常规操作、误操作、快速操作来检验人机界面的健壮性。

参考文献

[1]王峰,郑彦兴,包阳.软件第三方测评[J].计算机研究与发展,2008(45):345-350.

[2]古乐,史九林.软件测试技术概论[M].北京:清华大学出版社,2004.

[3]沈昌松,朱建方等.软件测试用例设计[J].微计算机信息,2001,17(2).

作者简介

田雅(1982-),女,江苏省人。大学本科学历,学士学位。现为中海油信息科技有限公司北京分公司工程师。主要研究方向为计算机应用系统软件测评。