软件测试实例 课件.ppt

上传人:牧羊曲112 文档编号:1848169 上传时间:2022-12-21 格式:PPT 页数:80 大小:608.01KB
返回 下载 相关 举报
软件测试实例 课件.ppt_第1页
第1页 / 共80页
软件测试实例 课件.ppt_第2页
第2页 / 共80页
软件测试实例 课件.ppt_第3页
第3页 / 共80页
软件测试实例 课件.ppt_第4页
第4页 / 共80页
软件测试实例 课件.ppt_第5页
第5页 / 共80页
点击查看更多>>
资源描述

《软件测试实例 课件.ppt》由会员分享,可在线阅读,更多相关《软件测试实例 课件.ppt(80页珍藏版)》请在三一办公上搜索。

1、第 8 章 软 件 测 试 实 例,8.1 被测试软件项目介绍8.2 HIS测试过程概述8.3 测 试 计 划8.4 测 试 用 例8.5 缺 陷 报 告8.6 测试结果总结分析8.7 应 用 测 试 工 具8.8 文 档 测 试,本章介绍的被测试软件项目是医院信息管理系统(HIS,Hospital Information System)。HIS是一个集成度很高的项目,因为行业的关系其中有一些词汇可能不被大家所了解,但这并不妨碍说清楚它的测试过程。,本章要重点描述的测试过程是HIS的集成测试,该阶段的测试重点在功能测试上,也有必要的性能测试。后面依次给出了HIS集成测试阶段的测试计划、测试用例

2、、缺陷(错误)报告、测试结果总结与分析等内容。测试用例将针对HIS的一个子系统门诊挂号管理子系统来设计。该子系统不但包含了对数据库的应用,对系统的并发性、安全性、准确性、高效性都有很高的要求,可谓麻雀虽小,五脏俱全,适合将其进行剖析。,8.1 被测试软件项目介绍,8.1.1 软件背景 医院信息管理系统(HIS)包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统,用于管理医院日常运作的整个过程。各子系统所处理的业务前后衔接,数据共享。 医院信息管理系统的系统结构如图8-1所示。,图8-1 HIS1.0系统结构图,8.2 HIS测试过程概述,HIS的测试按照一般测试

3、过程,将其分为单元测试、集成测试、系统测试和验收测试4个阶段。,8.2.1 单元测试 单元测试常常是动态测试和静态测试两种方式并举的。动态测试可由开发人员去运行局部功能或模块以发现系统潜藏的错误,也可以借助测试工具去测试。静态测试即是代码审查。审查的内容包括代码规则和风格,程序设计和结构,业务逻辑等。,HIS系统中涉及到许多的费用计算问题,逻辑性很强,需要程序结构也很复杂。面对复杂的业务流程,面对管理各异的用户需求,没有白盒测试是不可想像的。最简单的例子:HIS中要处理很多类的患者,普通患者、医保患者、内部职工、公费患者等,每类患者的费用处理流程和计算方法都不相同,开发人员就要严格地依照系统设

4、计去检查代码的逻辑结构,选取有代表性的测试用例去测试相关的模块。,又如医嘱分解,药房摆药等,必须知道系统的详细设计和程序的逻辑结构才能设计好测试用例。,8.2.2 集成测试 集成测试(有时被分为集成测试和确认测试两个阶段)是指将各模块组装起来进行测试,以检查与设计相关的软件体系结构的有关问题,并确认软件是否满足需求规格说明书中确定的各种需求。 HIS系统的集成测试是指开发人员完成了所有系统模块的开发并通过了单元测试后,将编译好的软件交付给测试部门进行测试的过程。,这个阶段的测试需要一个完备的测试管理过程。集成测试过程可以分为测试准备、测试计划、测试设计、测试执行和测试总结5个阶段。 测试准备阶

5、段是指测试人员准备测试资源,熟悉系统的过程。,测试计划阶段包含制定测试策略、资源分配、风险预警和进度安排等内容,此项工作由测试负责人来做。8.3节中给出了HIS集成测试的测试计划。测试计划的模板各不相同,这个取决于软件的特殊性和管理的规范性。,测试设计阶段包括设计测试用例及相关管理工具的设计。8.4节将给出HIS集成测试过程中挂号管理子系统部分的主要测试用例,侧重于系统的功能和性能测试。测试用例设计之前一般要有一个测试用例的设计大纲。 完成测试设计工作后,就开始执行实际的测试工作了。,测试时另外一项非常重要的工作就是做好系统缺陷记录。本章8.5节将给出系统生成缺陷报告的注意事项以及缺陷报告的实

6、例,另外还设计了一个问题记录数据库表。用数据库记录缺陷的好处是测试人员和开发人员能够通过动态的信息发布和获取进行更好的交互,提高测试和修改的工作效率。 经过修改后的系统再次经过测试即是回归测试。,测试结束后要及时总结分析测试结果。测试结果的总结与分析一方面是提供一个系统功能、性能和稳定性等方面的完整的分析和结论,另外要对测试过程本身做出总结,总结成功的经验和失败的教训,以使日后的工作开展得更顺利。具体的测试总结详见8.6节。,8.2.3 系统测试 系统测试是在真实或模拟系统运行的环境下,检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接,并满足用户需求。,

7、系统测试也应该经过测试准备、测试计划、测试设计、测试执行和测试总结5个阶段,每个阶段所做工作内容与集成测试很相似,只是关注点有所不同。 在HIS系统的系统测试中,要搭建更真实的运行环境,另外还要在不同的操作系统下进行测试,如数据库服务器分别搭建在UNIX环境和WINNT环境下长时间多客户端并发运行系统的各项功能,并观测服务器的承受能力(系统的反应时间,服务器的资源占用情况等)。,8.2.4 验收测试 验收测试是指在用户对软件系统验收之前组织的系统测试。测试人员都是真正的用户,在尽可能真实的环境下进行操作,并将测试结果进行汇总,由相关管理人员对软件做出评价以及是否验收的决定。,HIS系统一般在用

8、户验收之前都需要对系统进行一段时间的试运行,因此可以说HIS的验收测试就是实际的使用(但用户一般要参与软件的系统测试,即所谓的 测试,不然用户是不会放心让系统试运行的)。 因为验收测试由用户完成,不同软件实际应用的差异性又很大,这里就不对其详加论述了。,8.3 测 试 计 划,测试计划工作的提交成果是一份完整的测试计划报告。 下面给出医院信息管理系统1.0版集成测试的测试计划报告。,8.3.1 概述 本测试项目拟对医院信息管理系统(HIS)1.0进行测试。 医院信息管理系统包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统,用于管理医院日常运作的整个过程,各子系

9、统所处理的业务前后衔接,数据共享。,测试的目标是要找出影响医院信息管理系统正常运行的错误,分别在功能、性能、安全性等方面检验系统是否达到相关要求。 本次集成测试采用黑盒和白盒测试技术(重点在黑盒测试)。测试手段为手工与自动测试相结合(主要依靠手工进行功能测试,依靠自动测试工具进行性能测试)。 本测试计划面向相关项目管理人员、测试人员和开发人员。,8.3.2 定义 质量风险:被测试系统不能实现描述的产品需求或系统不能达到用户的期望的行为,即系统可能存在的错误。 测试用例:为了查找被测试软件中的错误而设计的一系列的操作数据和执行步骤,即一系列测试条件的组合。,测试工具:应用于测试用例的硬件/软件系

10、统,用于安装或撤销测试环境、创造测试条件,执行测试,或者度量测试结果等工作。测试工具独立于测试用例本身。 进入标准:一套决策的指导方针,用于决定项目是否准备好进入特定的测试阶段。在集成测试和系统测试阶段,进入标准会很苛刻。,退出标准:一套标准,用于决定项目是否可以退出当前的测试阶段,或者进入下一个测试阶段或者结束项目。同进入标准,测试过程的后几个阶段退出标准一般很苛刻。 功能测试:集中于功能正确性方面的测试。功能测试必须和其他测试方法一起处理潜在的重要的质量风险,比如性能、负荷、容积和容量等。,8.3.3 质量风险摘要 危险性:表示故障对系统影响的大小。5致命;4严重;3一般;2轻微;1无。

11、影响:5一定影响所有用户;4可能影响一些用户;3对有些用户可能的影响;2对少数用户有限的影响;1在实际使用中难以觉察的影响。,优先级:表示风险可以被接受的程度。5很紧急,必须马上纠正;4不影响进一步测试,但必须修复;3系统发布前必须修复;2如果时间允许应该修复;1最好修复。,8.3.4 测试进度计划8.3.5 进入标准 (1)“测试小组”配置好软硬件环境,并且可以正确访问这些环境。 (2)“开发小组”已完成所有特性和错误修复并完成修复后的单元测试。 (3)“测试小组”完成“冒烟测试”,程序包能打开,随机的测试操作正确完成。,8.3.6 退出标准 (1)“开发小组”完成了所有必须修复的错误。 (

12、2)“测试小组”完成了所有计划的测试。没有优先级为3以上的错误。优先级为2以下的错误少于5个。 (3)“项目管理小组”认为产品实现稳定性和可靠性。,8.3.7 测试配置和环境 服务器1台:HP Pentium 550,1GB内存,8.4GB硬盘;软件环境:Windows NT,Oracle。 客户机10台:Pentium MMX 166,1.2GB硬盘,32MB内存;软件环境:Oracle客户端。 打印机1台:Panasonic KX-P1131。 地点:58号楼101室。,8.3.8 测试开发 设计测试用例以进行手工测试。 准备使用MI LoadRunner,以检测系统对并发性的控制和系统的

13、强壮性。 设计开发问题记录及交互工具,包括问题存取控制系统及所对应的数据库,以对测试结果做很好的记录并提供相关测试和开发人员的交互平台。,8.3.9 关键参与者 测试经理:宋欣欣(制定测试计划及部署、监督相关工作)。 测试人员:蔡亮,邱实,崔进,赫北松,洪怡,武刚,沙盼盼,王军妹(负责相关子系统测试)。 开发人员:王铁全,李云帆,夏淼,张铁(及时解决影响测试进行的系统问题)。 项目管理人员:王斌(跟踪项目进展)。,8.3.10 预算8.3.11 参考文档,8.4 测 试 用 例,测试用例应由测试人员在充分了解系统的基础上在测试之前设计好,测试用例的设计是测试系统开发中一项非常重要的内容。集成测

14、试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容,而且测试人员要与开发人员充分交互。另外有一些内容由测试人员的相关背景知识、经验、直觉等产生。,测试用例的设计需要考虑很周全。在测试系统功能的同时,还要检查系统对输入数据(合法值、非法值和边界值)的反应,要检查合法的操作和非法的操作,检查系统对条件组合的反应等。好的测试用例让其他人能够很好地执行测试,能够快速地遍历所测试的功能,能够发现至今没有发现的错误。所以测试用例应该由经验丰富的系统测试人员来编写,对于新手来说,应该多阅读一些好的测试用例,并且在测试实践中用心去体会。,在编写测试用例之前,应该给出测试大纲,大

15、纲基本上是测试思路的整理,以保证测试用例的设计能够清晰、完整而不是顾此失彼。测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。 本节给出“医院信息管理系统1.0”的“门诊挂号管理子系统”的测试大纲和测试用例的主体部分。,8.4.1 挂号管理子系统测试大纲8.4.2 其他可用性测试检查标准 软件产品的可用性是指软件产品能否让用户更快更容易地完成工作,即软件是否易学、易用,并使用户感到满意。软件产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现,提高用户工作效率,增加用户满意度。,对于开发商而言可以缩减服务和培训费用,提高用户满意度。软件可用性已经越来越引起用户和开发商的

16、关注。可用性测试对所有功能模块来说,检测标准是相同的,而这些检测在功能测试的同时即可检验,所以不再设计单独的测试用例。,8.4.3 功能测试用例1普通挂号,要病历本的测试用例 2预约挂号,老患者,不要病历本的测试用例 3预约挂号,不要病历本,无挂号费有诊察费的测试用例,4有挂号费无诊察费,要病历本的测试用例 5退号,不退病历本的测试用例 6退号测试用例,包括病历本的测试用例 7挂号员结算的测试用例8挂号员结算补打的测试用例,8.4.4 性能测试用例,8.5 缺 陷 报 告,这里给出一个利用数据作缺陷记录报告的实例。错误跟踪数据库可以自己开发,也可以购买现成的产品。,8.5.1 建立缺陷报告数据

17、库 缺陷报告数据库应该在测试工作的准备配置阶段就建立起来,测试执行阶段,测试人员、开发人员和项目管理评估人员可以采用各种方式通过缺陷报告数据库进行交互,而可以自行开发一个小系统,使得数据库能够记录下人们访问数据库的一切活动。 先设计一个缺陷记录的数据表结构。,8.5.2 编写缺陷报告 关于测试人员、系统开发人员和相关问题评审人员打开、读取和写入缺陷报告数据库,以何种形式并不重要,重要的是对于问题的描述应该是完整的、严谨的、简洁的、清晰的和准确的。,下面列出编写好的错误报告的几个要点(也是测试执行应该遵循的一些原则)。 (1)再现:尽量三次再现故障。如果问题是间断的,那要报告问题发生频率。 (2

18、)隔离:确定可能影响再现的变量,例如配置变化、工作流、数据集,这些都可能改变错误的特征。,(3)推广:确定系统其他部分是否可能出现这种错误,特别是那些可能存在更加严重特征的部分。 (4)压缩:精简任何不必要的信息,特别是冗余的测试步骤。 (5)去除歧义:使用清晰的语言,尤其要避免使用那些有多个不同或相反含义的词汇。,(6)中立:公正表达自己的意思,对错误及其特征的事实进行陈述,避免夸张、幽默或讽刺。 (7)评审:至少有一个同行,最好是一个有丰富经验的测试工程师或测试经理,在你递交错误报告之前先读一遍。 为了说明一个基本的测试缺陷报告应该具有的内容,截取了本章所介绍案例HIS1.0中挂号管理子系

19、统集成测试缺陷报告中的一页,如图8-5所示。,图8-5 测试缺陷报告示例,8.6 测试结果总结分析,8.6.1 测试总结报告 图8-6所示的是测试总结报告的一个模板,各行业、各阶段的软件测试会有具体不同的总结报告,但基本上应该有本模板所展示的项目。,图8-6 测试总结报告的一个模板,8.6.2 测试用例分析 对工作的及时总结,会及时调整方向,大大提高工作效率。测试工作的效果要直接依赖测试用例的编写和执行状况,所以在测试过程中和测试结束后都要对关于测试用例的一些重要值进行度量。,关于测试用例的分析,通常包括以下的内容: 计划了多少个测试用例,实际运行了多少? 有多少测试用例失败了? 在这些失败的

20、测试用例中,有多少个在错误得到修改后最终运行成功了? 这些测试平均占用的运行时间比预期的长还是短?,有没有跳过一些测试?如果有,为什么? 测试覆盖了所有影响系统性能的重要事件吗?等等。 这些问题都可以从相关的测试用例的设计和测试问题记录中找到相应的答案。当然,如果使用了数据库,这些问题就更能轻松地被解答了。测试用例的分析报告可以以多种形式体现出来:文字描述、表、图等。,8.6.3 软件测试结果统计分析 软件问题统计与分析,在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基础上,由全体参与测试的人员完成“软件问题倾向分析表”,对该软件或该类型系统软件产品在模块、功能及操作等方面出错倾向

21、及其主要原因进行分析。软件问题倾向分析表将为以后开发工作提供一个参考,使开发人员根据软件问题倾向分析表明确在开发过程中应注意和回避的问题。该表也可为以后的测试工作明确测试重点提供依据。,图8-7表达的是软件的不同版本在测试时检测出的缺陷(Bug)数的对应关系。这里的版本指的是同一软件经过不同的测试阶段并修复Bug及作必要的调整后所产生的软件产品。显然,该图所表达的测试结果的变化是非常理想的。,图8-7 按版本统计结果示例,图8-8表达的是在一个测试阶段所发现的缺陷数与测试日期之间的对应关系。测试过程中所发现的缺陷是随着时间的推移而增多的,但一段时间后,测试所发现的缺陷增加会渐缓,甚至没有增加,

22、如果测试还在进行,那么表明,在现有测试用例、软硬件环境及相关条件下已经很难再发现新的缺陷了(虽然可以肯定系统中仍然存在缺陷),那么这个测试阶段应该考虑停止了。,图8-8 按日期统计结果示例,图8-9表达的是测试中所发现的不同等级的缺陷的数目。关于A、B、C、D等级(或者还有E、F、G、)所表达的不同含义由相关测试和开发人员来制定,而这种按等级的统计结果可以清楚地反映开发工作中的薄弱之处。,图8-9 按等级统计结果示例,图8-10表达的是测试所发现的缺陷数目与究其原因缺陷所属的软件工程的不同阶段之间的关系。这个图表会又一次验证软件工程的任何阶段都会有导致程序中产生错误的因素,只是程度和数目不同而

23、已。通过该图表的分析,可以清楚地看到,软件工程中的哪个阶段更应该加强控制。,图8-10 按原因统计结果示例,图8-11表达的是程序的不同模块与在其中所发现的缺陷数目之间的关系。缺陷的产生有多方面的原因,但也可以从该图中反映出哪些程序员所开发的模块中Bug很多,而另一些程序员的则很少,那么在相同的系统设计和工作条件下,这也反映了程序员的工作能力或者责任感的不同。,图8-11 按模块统计结果示例,图8-12表达的是在测试过程中每日发现的错误报告公开、关闭的对应关系图。公开是指错误被发现并被公告,关闭则指错误已被处理完毕的状况。图中中间两条粗线反映的是错误累计公开和累计关闭的实际状况。随着时间的推移

24、,累计公开和累计关闭的错误数目都是渐增的,但到某个时间点,两条曲线会会合,即累计公开的数目等于累计关闭的数目,那就是说所有发现的错误都得到了处理。,图8-12 按公开/关闭日期统计图表,图8-13表达的是错误原因分析,其中纵轴表达的是每类测试发现错误占所有错误的百分比。可以看出,只有每个错误都被明确细致地归类后才能得到这样的分析图表,也才能知道该从哪里去控制以减少错误的产生。,图8-13 错误原因分析,图8-14表达的是对系统性能测试所产生的分析数据、图和简单的结论。这种分析是在系统经过性能测试后所必不可少的。性能测试的分析一般从并发用户数、系统响应时间以及CPU的利用率几方面来表述。,图8-

25、14 系统响应时间与用户数对比分析(性能测试结果分析),8.7 应 用 测 试 工 具,实际测试需要投入大量的时间和精力,测试工作同样也可以采用其他领域和行业中运用多年的办法开发和使用工具,即自动化测试使工作更加轻松和高效。采用测试工具不但能提高效率,节约成本,还可以模拟许多手工无法模拟的真实场景。,当建立一个新的测试项目时,测试工具会自动生成测试代码,用户可以根据需要进行修改,自动测试工具再执行这些代码。图8-15显示的是测试工具在建立一个新的测试项目时产生的原始代码和测试执行记录,只是截取了其中的片断。这些代码很冗长,可不用担心,一切都是自动测试工具为你生成的。,图8-15 自动测试工具所

26、生成的代码,为了测试挂号管理子系统的并发性控制,按照前面的测试用例,选择10用户并发执行,每用户连续执行200次停止。如图8-16所示的是增加用户进程控制界面。10用户可以一起加入,而模拟3000用户时,可以批量加入用户,如每5分钟加入600用户,这样可能更接近于实际场景。,图8-16 增加用户进程的界面,脚本开始运行后,Load Runner会跟踪被测试系统的运行状况以及监控被测试设备的资源使用情况,如图8-17所示。,图8-17 自动测试监控场景,8.8 文 档 测 试,广义地说,文档测试也是软件测试的一项内容。文档测试包括对系统需求分析说明书、系统设计报告、用户手册以及与系统相关的一切文档、管理文件的审阅、评测。,系统需求分析和系统设计说明书中的错误将直接带来程序的错误;而用户手册将随着软件产品交付用户使用,是产品的一部分,也将直接影响用户对系统的使用效果,所以任何文档的表述都应该清楚、准确,含糊不得。,文档测试时应该慢慢仔细阅读文字。特别是用户手册,应完全根据提示操作,将执行结果与文档描述进行比较。不要任何假设。耐心补充遗漏的内容,耐心更正错误的内容和表述不清楚的内容。,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号