软件系统常规测试过程概述_第1页
软件系统常规测试过程概述_第2页
软件系统常规测试过程概述_第3页
软件系统常规测试过程概述_第4页
软件系统常规测试过程概述_第5页
已阅读5页,还剩109页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、技术创新,变革未来软件系统常规测试过程概述2软件系统测试执行阶段软件系统测试用例执行软件系统测试软件缺陷记录、跟踪软件系统测试日报写作软件系统测试报告写作软件系统测试缺陷的回归测试ST3单元测试和系统测试的区别单元测试早期测试;白盒测试;单元的具体实现、内部逻辑结构、数据流向;允许多个单元的测试同时开展。系统测试后期测试,错误定位困难;黑盒测试;基于需求规格说明书;站在用户角度。4系统测试,是将已经集成好的软件系统,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的测试活动。系统测试(System

2、Testing)5系统测试的目的通过与系统的需求定义做比较,发现软件与系统定义不符合或与之矛盾的地方验证系统功能是否符合需求规格定义验证系统的可靠性、可维护性、可用性、稳定性、容错性等其他属性系统测试的测试用例应根据需求分析说明书来设计,并在实际使用环境下运行。6系统测试的对象系统测试的对象是软硬件集合在一起的系统,不应是独立的软件与硬件环境。验证时应尽可能模拟实际的运行环境与条件。7单元、集成、系统测试比较考察范围不同单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等集成测试主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能系统测试主要测试整个系统相对于需求的符合度评估

3、基准不同系统测试的评估基准是测试用例对需求规格的覆盖率单元测试评估的主要是逻辑覆盖率集成测试评估的主要是接口覆盖率8配置主测试环境遵循的原则主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。选用比较普及的OS和软件平台例如:一个软件若声称支持“Windows9X/ME/NT/2000 professional”和“MS Office97/2000/XP”,一般我们会采用如“Windows2000 professionalMS Office2000”的流行环境营造相对简单、独立的测试环境。除了OS,测试机上只安

4、装软件运行和测试必需的软件,以免不相关的软件影响测试实施。无毒的环境利用有效的正版杀毒软件检测软件环境,保证测试环境中没有病毒。9配置辅测试环境遵循的原则兼容性测试在满足软件运行要求的范围内,可选择一些典型的OS和常用应用软件对其安装卸载和主要功能进行验证。模拟真实环境测试有些软件,特别是面向大众的商品化软件,在测试时常常需要考察在真实环境中的表现。横向对比测试利用辅测试环境“克隆”出完全一致的测试环境,从而保证各个被测软件平等对比。10软件特性和常用系统测试类型的对应关系:功能性:功能测试、安全性测试、互连测试可靠性:可靠性测试、启动/停止测试、恢复测试、健壮性测试、备份测试易用性:可用性测

5、试、文档测试、安装测试效率:强度测试、性能测试、指标测试、内存泄漏测试、容量测试、压力测试维护性:可维护性测试可移植性:配置测试、兼容测试、安装测试11系统测试用例编写原则系统测试用例的设计根据是系统的需求规格说明书、各种规范系统测试用例的依据不是软件本身系统测试用例不仅仅包括功能测试用例,同时还应该包含属性测试用例12系统测试用例编写思路(1)为系统功能性设计用例为系统可靠性设计用例为系统易用性设计用例为系统可移植性设计用例为系统可维护性设计用例为系统效率设计用例为系统异常设计用例13系统测试用例编写思路(2)一、根据ISO9126质量模型分析需求规格说明书,将需测试的需求项归纳到各特性、子

6、特性下质量特性质量子特性测试项功能性适合性准确性互操作性安全性功能依从性效率时间特性资源利用性14系统测试用例编写思路(3)二、对分析出来的测试需求项进行归纳、总结,确定需要进行何种类型的测试,并把各测试项归类到各测试类型下:功能测试性能测试压力测试容量测试安全性测试GUI测试可用性测试安装测试配置测试异常测试(恢复性测试)备份测试健壮性测试文档测试在线帮助测试网络测试系统测试用例编写思路(4)三、对各测试类型下的测试项细分,形成为测试子项:需求标识需求描述系统测试项标识系统测试项描述系统测试子项标识系统测试子项描述Router_V100_SRS_001路由管理Router_V100_ST_A

7、ddRoute路由增加Router_V100_ST_AddRoute_HostRoute_增加主机路由Router_V100_ST_AddRoute_NetRoute_增加网络路由Router_V100_ST_AddRoute_SpecRoute_增加特殊路由Router_V100_ST_DelRoute路由删除Router_V100_ST_InqRoute路由查询Router_V100_SRS_002路由协议Router_V100_ST_OSPFOSPF协议测试Router_V100_ST_RIPRIP协议测试16系统测试用例编写思路(5)四、对各测试子项对应的具体需求规格进行分析,利用各种

8、系统测试用例设计方法,从各角度设计用例去对需求规格进行覆盖,从而达到对需求的充分覆盖:等价类划分法边值分析法状态迁移图法决策表正交试验法错误猜测法17系统测试过程测试过程计划设计实现执行;测试过程体现了测试设计和实现的分离测试实现测试执行系统测试计划阶段:完成系统测试计划系统测试设计阶段:完成系统测试方案系统测试实现阶段:完成系统测试用例和脚本、系统测试规程、系统测试预测试项系统测试执行阶段:执行系统测试预测试项、提交系统预测试报告;执行系统测试用例,提交测试日报,发现问题并提交缺陷报告、系统测试报告;进行回归测试18系统测试执行的概念按一定的系统测试计划,依据系统测试用例,完成测试的各项操作

9、任务;系统测试执行阶段应完成:环境准备、测试操作、测试记录、测试报告19系统测试预测试目的:验证软件系统基本功能或预测主要的系统功能,以确保其后的系统测试执行能顺利进行20系统测试日报的写作目的测试人员总结每天的测试工作,便于了解自己的测试进度和测试情况,用以调整下一天的工作计划测试人员对被测对象每天给出评估结果,用以调整后续工作中的测试策略测试人员向测试经理反映测试中的困难,保证测试的顺利进行测试经理通过测试日报,了解每个测试人员的工作进度,把握测试的整体进度,发现进度上的风险及时调整计划21测试经理通过测试日报,了解各模块缺陷发展趋势,判断测试是否可以退出开发经理可以通过软件测试日报了解当

10、前被测试软件的质量情况,并可以调整缺陷修改的人力资源如果产品有多个测试组并行测试,测试日报可以提供彼此测试交流的手段项目ID标题版本执行者测试阶段日期概述执行用例数总用例数计划执行用例数累计已执行用例数本日发现问题数累计发现问题数致命问题数问题单号严重问题数问题单号一般问题数问题单号困难系统测试日报的格式23测试报告的写作目的软件测试人员完成对上一个测试阶段的总结,完成对被测试对象的评估,并对下一阶段的测试工作给出建议测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量软件开发项目经理通过软件测试报告了解开发产品的质量情况,并在下阶段的开发工作中采取应对措施在软件测试报告中,软件测试人

11、员做出的软件产品质量评估,可以作为产品是否商用发布的重要参考依据。24系统测试报告写作要点概述测试时间、地点、人员环境描述总结和评价测试结果统计测试评估测试总结和改进建议遗留问题报告附件25系统测试结果统计工作量数据统计(规模:KLOC、测试执行:人时、工作量投入比例:人时/KLOC)缺陷统计(致命、严重、一般、提示)版本缺陷统计(V1、V2、V3、V4)累计遗留问题统计(V1、V2、V3、V4)26系统测试评估(1)静态分析:效率分析测试活动持续时间:X人时执行用例数:Y个发现缺陷总数:Z个平均每小时用例数执行用例数/测试活动持续时间Y/X平均每小时发现缺陷数发现缺陷总数/测试活动持续时间Z

12、/X影响测试效率的原因分析:对影响测试的各种因素进行分析,如:测试环境,物料,突发任务等。27系统测试评估(2)静态分析:充分性分析千行代码用例数:根据用例统计对测试充分性进行点评分析执行结果统计根据结果统计对系统质量和测试过程进行点评28系统测试评估(3)测试对象的整体质量:质量稳定,适合大规模应用;存在少数严重问题,但有规避措施,可以使用;基本功能可用,但问题较多;基本功能不可用。也可采用打分方式。29系统测试总结和改进建议总结本次测试活动的经验教训,总结主要的测试活动和事件总结资源消耗数据,如总人员、总机时,每个主要测试活动花费的时间提供对本次测试过程活动的测试设计和操作的改进建议在测试

13、过程中形成的对测试方案、测试用例的修改和补充的具体改进内容可列在本测试报告文档的附录中30系统测试遗留问题报告遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。测试报告时已经得到解决,并已经过回归验证的测试问题不记入其中可对遗留问题数和级别进行统计要列出每个遗留问题的详细情况,包括问题单号、问题级别、详细描述、问题分析与对策等317.1 线索(Thread)的概念一、线索的看法和层次线索的看法:使用场景;系统级测试用例;激励/响应对;系统级输入序列产生的行为;端口输入/输出事件交替序列(系统级);机器指令序列 ;MM-路径序列(集成级);源指令序列(单元级);原子系统功能序

14、列(系统级);32线索的层次:单元级:DD-路径集成级:MM-路径/模块执行和消息交替序列系统级:ASF序列(端口输入/输出事件的交替序列)线索提供三层测试的统一视图:单元测试:单个函数测试;集成测试:单元之间的交互;系统测试:检查原子系统功能之间的交互。33四个侯选线索数字输入(激励/响应对,最小原子系统功能,集成测试)PIN输入(激励/响应对,原子系统功能,系统测试起点)简单事务处理(多个原子系统功能交互,系统级线索)ATM卡输入、PIN输入、选择事务处理类型、提供帐户细节、引导操作、报告结果ATM会话(一系列线索之间的交互)二、系统级线索的例子-SATM系统注意:不应该集成大于原子系统功

15、能的单元,也不对小于原子系统功能的单元进行系统测试。34ASF由事件静止点区分开,自然端点事件静止的Petri网解释:死锁和激活 三、系统线索ASF:在系统层可以观察得到的端口输入输出事件的行动。 ASF由端口输入事件开始,端口输出事件结束;例:SATM的数字输入,ATM卡输入,现金支付,会话关闭 ASF是集成测试的最大测试项和系统测试的最小测试项(可在两个级别上测试ASF);例:SATM的数字输入35定义ASF图:有向图,节点表示ASF,边表示串行流;源/汇ASF:例, SATM的ATM卡输入和会话结束系统线索: ASF图从源ASF到汇ASF的路径线索图:有向图,节点表示系统线索,边表示单个

16、线索顺序执行36 7.2 需求规格说明所有需求规格说明由五个基本概念表示:一、数据:经过初始化、存储、更新、销毁的信息二、行动:转换、处理、活动三、设备:端口、传送器、现金给付器、收据打印机四、事件:发生在端口设备上的系统级输入/输出。 注意:与语境有关的端口事件五、线索37六、采用五个基本概念建立需求模型结构模型(表示功能、数据的分解和组件接口,用于开发);语境模型(强调行动)行为/控制模型(需求的基础)常用模型描述手段:决策表(转换式)计算系统;有限状态机(交互式)菜单驱动系统;Petri网并发系统;38基本结构之间建模关系结构模型语境模型数据事件行为线索设备行为模型39例:函数F在E1,

17、E2都发生了才发生的模型外部实体1事件存储1外部实体2事件存储2F函数F的事件划分视图E1E2缺点:不能通过模型区分到底是哪个事件先发生,只知道两个事件一定发生。40空闲E1已发生准备执行FE1E2E2已发生E2E1函数F的有限状态机显式地显示事件的两种顺序,两种模型都描述了F的相同前提,但状态机对测试人员来说更有用。41 7.3 SATM的系统线索首先讨论状态机的层次结构顶层状态机(通过线索进行状态切换)过程的阶段划分状态转移由逻辑事件引起421、卡输入2、PIN输入3、等待事务选择有效卡/显示屏幕2显示屏幕1卡错/显示屏幕S1,退回卡成功PIN/显示屏幕5PIN失败/显示屏幕4图14-5

18、顶层SATM状态机43“PIN输入”状态机输入事件是逻辑事件、输出事件是真正的端口事件状态分解(图14-6)端口事件(表14-1)端口输入事件端口输出事件有效卡显示屏幕1错卡显示屏幕2正确的PIN显示屏幕3错误的PIN显示屏幕4取消显示屏幕5442.1第一次PIN输入尝试2.2第二次PIN输入尝试2.3第三次PIN输入尝试3、等待交易选择1、卡输入屏幕1卡正常,屏幕S2正确PIN/屏幕S5卡错/屏幕S1退卡PIN错/屏幕S4PIN错/屏幕S3PIN错/屏幕S3正确PIN/屏幕S5正确PIN/屏幕S5图14-6 PIN输入有限状态机ab1234545“PIN输入尝试”有限状态机状态分解(图14-

19、7)端口事件(表14-2)端口输入事件端口输出事件数字回显“X”取消回显“XX”回显“XXX-”回显“XXXX”462.x.1收到0数字2.x.2收到1数字2.x.3收到2数字2.x.4收到3数字2.x.5收到4数字2.x.6按下“取消”正确PIN x5不正确PIN x6数字/回显“X”x1数字/回显“XX-”x2数字/回显“XXX-”x3数字/回显“XXXX”x4x7取消x8取消x9取消x10取消x11已取消图14-7 PIN输入尝试有限状态机 GetPIN47有限状态机的层次结构,使线索的数量成倍增长。例:状态2.1到3或1的线索(路径)数量错误的数字或按下cancel(5X5X5)最终正

20、确的PIN输入(1+5+25)共156条不同的路径(图14-6与图14-7的结合)48例:走通层次状态机的两条路径端口输入事件端口输出事件屏幕2显示“”按下1屏幕2显示“X”按下2屏幕2显示“XX-”按下3屏幕2显示“XXX-”按下4屏幕2显示“XXXX”(正确的PIN)显示屏幕51.第一次PIN输入正确的端口事件序列(设PIN是1234)492.第三次PIN输入正确的端口事件序列(设PIN是1234)端口输入事件端口输出事件屏幕2显示“”按下1屏幕2显示“X”按下2屏幕2显示“XX-”按下3屏幕2显示“XXX-”按下5屏幕2显示“XXXX”(错误的PIN)显示屏幕350端口输入事件端口输出事

21、件(第二次尝试)屏幕2显示“”按下1屏幕2显示“X”按下2屏幕2显示“XX-”按下3屏幕2显示“XXX-”按下cancel(第二次尝试结束)显示屏幕351端口输入事件端口输出事件(第三次尝试)屏幕2显示“”按下1屏幕2显示“X”按下2屏幕2显示“XX-”按下3屏幕2显示“XXX-”按下4屏幕2显示“XXXX”(正确的PIN)显示屏幕552 7.4 线索测试的结构测试策略根据线索生成测试用例,用有向图选择线索。(按照状态机层次)自底向上组织线索例:SATM系统“PIN输入尝试”有限状态机线索路径(表14-5)“PIN输入”状态机线索路径(表14-6)测试问题:分层机制使单独测试不可行。53输入事

22、件序列转移的路径1234x1 x2 x3 x4 x51235x1 x2 x3 x4 x6Cx7 x111Cx1 x8 x1112Cx1 x2 x9 x11123Cx1 x2 x3 x10 x11 “PIN输入尝试”有限状态机中,共有6条路径。经过路径的线索以输入键描述。表14-5 “PIN输入尝试”有限状态机线索路径54 上升到“PIN输入”有限状态机中,共有4条路径。输入事件序列转移的路径12341123512342 31235C12342 4 5CCC2 4 6表14-6 “PIN输入”有限状态机线索路径55节点(状态)与边(转换)的覆盖指标上层状态机以下层状态机作为输入和返回。SATM系

23、统一个线索的节点和边的遍历(表14-7)线索/状态的关联(表14-8)线索/转换的关联(表14-9)输入事件2.12.x.12.x.22.x.32.x.42.x.52.x.62.22.3311234xxxxxxx12351234xxxxxxxxC1234xxxxxxxxx1C12C1234xxxxxxxxxx123C1C1Cxxxxxxxxx表14-8 线索/状态的关联输入事件x1x2x3x4x5x6x7x8x9x10 x111234561234xxxxxx12351234xxxxxxxxC1234xxxxxxxxx1C12C1234xxxxxxxxxxx123C1C1Cxxxxxxxxx表1

24、4-9 线索/转换的关联58 7.5 线索测试的功能测试策略基于事件的线索测试适合:以事件驱动的系统(“反应式”系统)端口输入事件的五个覆盖指标:每个端口输入事件发生;端口输入事件的常见序列发生;每个端口输入事件在所有“相关”数据语境中发生;按下B1在5种单独的语境种发生,3种不同含义对于给定语境,所有不合适的输入事件发生;对于给定语境,所有可能的输入事件发生。59端口输出事件的两个覆盖指标:每个端口输出事件发生;每个端口输出事件在每种原因下发生。难以定量描述,给定输出事件只有少量原因,没有被怀疑到的原因引起的输出最难发现。出现屏幕10的原因:终端储备现金可能用完、可能要连接到中央银行获得帐户

25、余额、取款通道可能阻塞。60开发模型全状态状态关键原子系统功能ATM卡输入、PIN输入、事务处理、会话管理前提数据带有PAN、PIN和帐户余额的实际帐户,ATM初始显示S1,现金给付器总现金$500 7.6 SATM测试线索61SATM测试数据PAN预期PIN支票余额(美元)储蓄余额(美元)10012341000.00800.002004567100.0090.00300678925.0020.0062 线索描述形式表格线索一余额查询线索二支票帐户存款线索三储蓄帐户取款线索1 ATM卡输入 PIN输入 事务处理请求 会话管理(余额) (PAN) 端口输入 100 1234 B1,B1 B2 端

26、口输出 S2 S5 S6,S14,$1000.00 S15,退卡,S1线索2 ATM卡输入 PIN输入 事务处理请求 会话管理(存款) (PAN) 端口输入 100 1234 B2,B1,25.00 B2 端口输出 S2 S5 S6,S7,S13,存款通道开 S15,退卡, S14,$1025.00 S1线索3 ATM卡输入 PIN输入 事务处理请求 会话管理(取款) (PAN) 端口输入 100 1234 B3,B2,30.00 B2 端口输出 S2 S5 S6,S7,S11,取款 S15,退卡,S1 通道开,3张10,S14,$770.00线索4 ATM卡输入(PAN) PIN输入 事务处

27、理请求 会话管理 端口输入 400端口输出 退出ATM卡,S1线索5 ATM卡输入 PIN输入 事务处理请求 会话管理(余额) (PAN) 端口输入 100 12351234 与线索1相同端口输出 S2 S3,S2,S5 线索6 ATM卡输入 PIN输入 事务处理请求 会话管理(余额) (PAN) 端口输入 100 C1234 与线索1相同端口输出 S2 S3,S2,S5线索7 ATM卡输入 PIN输入 事务处理请求 会话管理(余额) (PAN) 端口输入 100 1C12C1234 与线索1相同端口输出 S2 S3,S2,S3,S2,S5线索8 ATM卡输入 PIN输入 事务处理请求 会话管

28、理(余额) (PAN) 端口输入 100 123C1C1C 与线索1相同端口输出 S2 S3,S2,S3,S2,S4,S1线索9 ATM卡输入 PIN输入 事务处理请求 会话管理(提取) (PAN) 端口输入 100 1234 B3,B2,15.00,取消 B2 端口输出 S2 S5 S6,S7,S9,S7 S15,退卡,S1线索10 ATM卡输入 PIN输入 事务处理请求 会话管理(提取) (PAN) 端口输入 300 6789 B3,B2,50.00,取消 B2 端口输出 S2 S5 S6,S7,S8 S15,退卡,S1非10元整数倍多于余额线索11 ATM卡输入 PIN输入 事务处理请求

29、 会话管理(提取) (PAN) 端口输入 100 1234 B3,B2,510.00,取消 B2 端口输出 S2 S5 S6,S7,S10 S15,退卡,S1多于机器总额线索12 ATM卡输入 PIN输入 事务处理请求 会话管理(余额) (PAN) 端口输入 100 1234 B1,B1 B1,取消 端口输出 S2 S5 S6,S14,$1000.00 S5,S15,退卡,S1硬件失效线索13:覆盖输出屏幕12(存款不能被处理)语境有关输入事件线索1422(表14-11)各输出屏幕上的Cancel键,B1、B2功能键测试线索 按下的键 屏幕 逻辑含义6 取消 2 PIN输入错误14 取消 5

30、事务处理选择错误15 取消 6 帐户选择错误16 取消 7 金额输入错误17 取消 8 金额输入错误18 取消 13 取款信封未就绪1 B1 5 余额1 B1 6 支票19 B1 10 是(暂时无法取款)20 B1 12 是(暂时无法存款)12 B1 14 是(另一个事务处理)2 B2 5 存款3 B2 6 储蓄21 B2 10 否(没有其他事务处理)22 B2 12 否(没有其他事务处理)1 B2 14 否(没有其他事务处理)70伪结构系统测试将基于图的指标用作功能线索的一种交叉检查。基于系统控制模型导出功能线索边和节点的覆盖指标决策表设计每个规则的测试用例(转换式)有限状态机设计覆盖每个状

31、态、转换、路径的测试用例(交互式)Petri网设计覆盖每个地点、转移、转移序列的测试用例(并发系统)7.7 系统测试原则解决线索爆炸问题71运行剖面Zipfs law(80%的活动发生在20%的空间中)以系统线索出现的频率选择测试用例;以决策树确定系统运行剖面(图14-10)给定转移概率,线索的总概率就是各转移概率的乘积。有效卡:0.95 卡错:0.05PIN正确:0.90 PIN不正确:0.10B1:0.05 B2:0.10 B3:0.85现金不足:0.10 正常:0.85 余额不足:0.0572常见线索 概率有效ATM卡 0.95PIN第一次尝试正确 0.90取款 0.85正常 0.85

32、0.617737573罕见线索 概率有效ATM卡 0.95PIN第一次尝试错误 0.10PIN第二次尝试错误 0.10PIN第三次尝试正确 0.90取款 0.85现金不足 0.10 0.0007267574功能测试性能测试稳定性测试负载测试压力测试安全性测试恢复性测试备份测试GUI测试健壮性测试兼容性测试可用性测试可安装性测试文档测试在线帮助测试数据转换测试可靠性测试Web网站测试7.8 系统测试方法751.功能测试功能测试是系统测试中最基本的测试,主要根据产品的需求规格说明书和测试需求列表,验证产品的功能实现是否符合产品的需求规格。为了发现以下几类错误:是否有不正确或遗漏了的功能?功能实现是

33、否满足用户需求和系统设计的隐藏需求?能否正确地接受输入?能否正确地输出结果?要求测试设计者对产品的规格说明、需求文档、产品业务功能都非常熟悉,测试用例设计方法也要掌握。762.性能测试性能测试用来检查系统是否满足在需求说明书中规定的性能。特别是针对嵌入式实时系统。性能测试可以在测试过程的任意阶段进行,但只有当整个系统的所有成分都集成到一起后,才能检查一个系统的真正性能。性能测试必须要有工具支持,用于GUI或Web的性能测试工具在市面上能见到。773.稳定性测试是指连续运行被测系统,检查系统运行时的稳定程度。通常用mtbf(mean time between failure)来衡量系统的稳定性,

34、mtbf越大,系统的稳定性越强采用24*7(24小时*7天)的方式让系统不间断运行,至于具体运行多少天,是一周还是一个月,视项目的实际情况而定。78负载测试是指让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。负载测试需要给被测系统施加其刚好能承受的压力 。负载测试为测试系统在临界状态下运行是否稳定提供了一种办法。 795.压力测试压力测试:是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。比如不断增加并发的登录用户数,20,30,50,当增加到70个用户并发登录时,系统崩溃了,就可以知道163邮箱所能承载的最大登录并发数为70个左右

35、。 806.安全性测试安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时软件如何进行处理,是否仍能保证数据的安全。测试人员可以学习一些黑客技术,来对系统进行攻击。81 破坏系统的保护机构以进入系统的主要方法:正面攻击或从侧面、背面攻击系统中易受损坏的那些部分;以系统输入为突破口,利用输入的容错性进行正面攻击;申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统;故意使系统出错,利用系统恢复的过程,窃取用户口令及其它有用的信息;通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令

36、,安全码,译码关键字等信息;浏览全局数据,期望从中找到进入系统的关键字;浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。827.恢复性测试恢复测试的目标是验证系统从软件或者硬件失败中恢复的能力;恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后,系统能否正常地继续进行工作,并不对系统造成任何损害。可采用各种人工干预的手段,模拟硬件故障,故意造成软件出错。掉电测试:测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据,然后在电源恢复时从保留的断点处重新进行操作。838. 备份测试备份测试是恢复性测试的一个补充,并且应当是恢复性测试的一个部分。备份测试的目的是验证系统在软

37、件或者硬件失败的事件中备份它数据的能力。849.GUI测试为了让软件能够更好地服务于用户,进行GUI测试变得非常重要了。GUI测试包括:界面实现与界面设计的吻合情况;确认界面处理的正确性。GUI系统分为:界面层、界面与功能的接口层、功能层。界面的美学具有很大的主观性,如何才能代表大部分客户的意见是界面测试的一个难点。8510. 健壮性测试也叫容错性测试(Fault ToleranceTesting),主要用于测试系统在出现故障时,是否能够自动恢复或者忽略故障继续运行。必须小心地设计实现系统,尤其是在系统的异常处理方面。一个健壮的系统是设计出来的而不是测试出来的。8611.兼容性测试检查软件之间

38、是否正确地交互和共享信息兼容性包括向前兼容或向后兼容不同版本间的兼容标准和规范 MS Windows认证徽标,为了得到这个徽标,软件必须通过独立测试实验室的兼容性测试,确保在Windows OS 上能平稳可靠的运行。数据共享兼容如:Windows环境下,对某个程序进行兼容性测试就要确认其数据能够利用剪切板与其他程序进行相互复制8712.可用性测试可用性测试是为了检测用户在理解和使用系统方面到底有多好,包括:系统功能、系统发布、帮助文本和过程,以保证用户能够舒适地和系统交互。可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查,发现人为因素或使用上的问题。88一些应当关注的可用性问题包

39、括:过分复杂的功能或者指令;困难的安装过程;错误信息过于简单,如:“系统错误”非标准的GUI接口;用户被迫去记住太多的信息;难以登录;帮助文本上下文不敏感或者不够详细;默认不够清晰;接口太简单或者太复杂8913.可安装性测试一个软件的安装程序应当平滑地集成用户的新软件到已有的系统中去,对话窗口提供简单、容易理解的安装选项和支持信息,完成安装过程。可安装性测试的目的是验证成功安装系统的能力,不是找软件错误,而是找安装错误。清晰并且简单的安装过程是系统文档中最重要的部分。901 文档测试这种测试是验证用户文档是正确的并且保证操作手册的过程能够正确工作。用户文档中所使用的例子必须在测试中一一试过,确

40、保叙述正确无误。有助于发现系统中的不足/使系统更可用;可减少客户支持成本。9115. 在线帮助测试一个糟糕的在线帮助会大大打击用户对系统的信心。一个好的系统,必须要有完备的帮助体系,包括用户操作手册,实时在线帮助等。在线帮助测试用于验证系统的实时在线帮助的可用性和正确性。9216. 数据转换测试实际应用环境中,经常遇到环境需要升级的问题,新系统使用老数据是否会出现问题?据转换测试的目标在于验证已存在数据的转换并载入一个新的数据库是否是有效的。9317.可靠性测试软件可靠性:在规定环境,规定时间内,一个系统或其功能无故障运行的可能性。如果系统需求说明书中有对可靠性的要求,则需进行可靠性测试。软件

41、可靠性指标: 平均失效间隔时间 MTBF (Mean Time Between Failures) 是否超过规定时限? 因故障而停机的时间 MTTR (Mean Time To Repairs) 在一年中应不超过多少时间。9418.Web网站测试功能测试链接测试表单测试Cookies测试设计语言测试数据库测试性能测试连接速度测试容量测试压力测试可用性测试导航测试 图形测试 内容测试 整体界面测试客户端兼容性测试平台测试 浏览器测试安全性测试95Web网站测试 - 功能测试(1)1.链接测试目的 测试所有链接是否按指示的那样确实链接到了该链接的页面;测试所链接的页面是否存在;保证Web应用系统上

42、没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。 链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。 96Web网站测试 - 功能测试(2)2.表单测试 当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的

43、某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。97Web网站测试 - 功能测试(3)3.Cookies测试 Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。 98Web网站测

44、试 - 功能测试(4)设计语言测试Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。99Web网站测试 - 功能测试(5)5.数据库测试在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。100Web网站测试 - 性能测试(1)1.连接速度测试用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带

45、上网;当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样;有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。 101Web网站测试 - 性能测试(2)2.容量测试容量测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求? 102We

46、b网站测试 - 性能测试(3)3.压力测试压力测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。Intranet的用户数目总是有限的,只有放在Internet上,接受负载测试,其结果才是正确可信的。 压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。压力测试的区域包括表单、登陆和其他信息传输页面等。103Web网站测试 - 可用性测试(1)1.导航测试 考虑下列问题:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? Web应用系统的用户趋向于目的驱动,很少有用户愿意花时间去熟悉

47、Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。 Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。 104Web网站测试-可用性测试(2)2.图形测试:在Web应用系统中,适当的图片和动画可以美化页面。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小

48、,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。 验证所有页面字体的风格是否一致。 背景颜色应该与字体颜色和前景颜色相搭配。 图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。105Web网站测试-可用性测试(3)3.内容测试:内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的“拼音与语法检查”功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般W

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论