软件测试定义Word文件下载.docx
- 文档编号:21032237
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:11
- 大小:22.57KB
软件测试定义Word文件下载.docx
《软件测试定义Word文件下载.docx》由会员分享,可在线阅读,更多相关《软件测试定义Word文件下载.docx(11页珍藏版)》请在冰豆网上搜索。
A.
B.
C.
从是否执行程序的角度
B.。
从软件开发的过程按阶段划分有
D.
E.
*测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。
*开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
*集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
*确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
*系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
单元测试(UnitTesting)
*单元测试又称模块测试,是针对软件设计的最小单位─程序模块,进行正确性检验的测试工作。
其目的在于发现各模块内部可能存在的各种差错。
*单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
1.单元测试的内容
*在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
(1)模块接口测试
*在单元测试的开始,应对通过被测模块的数据流进行测试。
测试项目包括:
–调用本模块的输入参数是否正确;
–本模块调用子模块时输入给子模块的参数是否正确;
–全局量的定义在各模块中是否一致;
*在做内外存交换时要考虑:
–文件属性是否正确;
–OPEN与CLOSE语句是否正确;
–缓冲区容量与记录长度是否匹配;
–在进行读写操作之前是否打开了文件;
–在结束文件处理时是否关闭了文件;
–正文书写/输入错误,
–I/O错误是否检查并做了处理。
(2)局部数据结构测试
*不正确或不一致的数据类型说明
*使用尚未赋值或尚未初始化的变量
*错误的初始值或错误的缺省值
*变量名拼写错或书写错
*不一致的数据类型
*全局数据对模块的影响
(3)路径测试
*选择适当的测试用例,对模块中重要的执行路径进行测试。
*应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
*对基本执行路径和循环进行测试可以发现大量的路径错误。
(4)错误处理测试
*出错的描述是否难以理解
*出错的描述是否能够对错误定位
*显示的错误与实际的错误是否相符
*对错误条件的处理正确与否
*在对错误进行处理之前,错误条件是否已经引起系统的干预等
(5)边界测试
*注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。
对这些地方要仔细地选择测试用例,认真加以测试。
*如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。
2.单元测试的步骤
*模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。
–驱动模块(driver)
–桩模块(stub)──存根模块
*如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。
必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。
*对支持某些标准规程的程序,更要着手进行互联测试。
有人把这种情况特别称为模块测试,以区别单元测试。
集成测试(IntegratedTesting)
*集成测试(集成测试、联合测试)
*通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。
这时需要考虑的问题是:
–在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
–一个模块的功能是否会对另一个模块的功能产生不利的影响;
–各个子功能组合起来,能否达到预期要求的父功能;
–全局数据结构是否有问题;
–单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
在单元测试的同时可进行集成测试,
发现并排除在模块连接中可能出现
的问题,最终构成要求的软件系统。
*子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
*通常,把模块集成成为系统的方式有两种
–一次性集成方式
–增殖式集成方式
1.一次性集成方式(bigbang)
*它是一种非增殖式组装方式。
也叫做整体拼装。
*使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
2.增殖式集成方式
*这种集成方式又称渐增式集成
*首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统
*在集成的过程中边连接边测试,以发现连接过程中产生的问题
*通过增殖逐步组装成为要求的软件系统。
(1)自顶向下的增殖方式
*这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。
*自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
*选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。
(2)自底向上的增殖方式
*这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
*因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。
在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
*自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
*一般来讲,一种方式的优点是另一种方式的缺点。
(3)混合增殖式测试
*衍变的自顶向下的增殖测试
–首先对输入/输出模块和引入新算法模块进行测试;
–再自底向上组装成为功能相当完整且相对独立的子系统;
–然后由主模块开始自顶向下进行增殖测试。
*自底向上-自顶向下的增殖测试
–首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
–然后对含写操作的子系统做自顶向下的组装与测试。
*回归测试
–这种方式采取自顶向下的方式测试被修改的模块及其子模块;
–然后将这一部分视为子系统,再自底向上测试。
关键模块问题
*在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。
*关键模块的特征:
①满足某些软件需求;
②在程序的模块结构中位于较高的层次(高层控制模块);
③较复杂、较易发生错误;
④有明确定义的性能要求。
确认测试(ValidationTesting)
*确认测试又称有效性测试。
任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
*对软件的功能和性能要求在软件需求规格说明书中已经明确规定。
它包含的信息就是软件确认测试的基础。
1.进行有效性测试(黑盒测试)
*有效性测试是在模拟的环境(可能就是开发的环境)下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。
*首先制定测试计划,规定要做测试的种类。
还需要制定一组测试步骤,描述具体的测试用例。
*通过实施预定的测试计划和测试步骤,确定
–软件的特性是否与需求相符;
–所有的文档都是正确且便于使用;
–同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试
*在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类:
–测试结果与预期的结果相符。
这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。
–测试结果与预期的结果不符。
这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
2.软件配置复查
n软件配置复查的目的是保证
u软件配置的所有成分都齐全;
u各方面的质量都符合要求;
u具有维护阶段所必需的细节;
u而且已经编排好分类的目录。
n应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。
验收测试(AcceptanceTesting)
*在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。
*验收测试是以用户为主的测试。
软件开发人员和QA(质量保证)人员也应参加。
*由用户参加设计测试用例,使用生产中的实际数据进行测试。
*在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、、可维护性、错误的恢复功能等进行确认。
*确认测试应交付的文档有:
–确认测试分析报告
–最终的用户手册和操作手册
–项目开发总结报告。
系统测试(SystemTesting)
*系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
*系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方。
软件测试网站推荐
中国软件测试:
介绍:
中国软件测试网是中国IT实验室核心技术频道,致力于打造国内最大最全的软件测试技术文献平台。
51testing软件测试论坛:
软件测试网包括软件测试论坛、软件测试博客和文章资料精选三大模块,提供学习、交流、教材下载以及求职、招聘信息的发布、检索等服务。
技术文献目录:
手机测试:
测试工具介绍:
是国内第一款自动化测试工具,可以用来完成、、每日构建测试与自动回归测试等工作。
是具有脚本语言的、提供针对完善的跟踪和调试功能的、支持IE测试和Windowsnative测试的自动化测试工具。
是一款功能强大,它可以帮助您:
实现的过程管理,对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。
实现测试用例的标准化即每个测试人员都能够理解并使用标准化后的测试用例,降低了测试用例对个人的依赖;
提供测试用例复用,用例和脚本能够被复用,以保护测试人员的资产;
提供可伸缩的测试执行框架,提供自动测试支持;
提供测试数据管理,帮助用户同意管理测试数据,降低测试数据和测试脚本之间的。
(TerminalAutoRunner)适用于VT100、VT220等标准的应用系统,支持命令行模式和窗口模式(使用Cursors编写的应用程序),支持自动录制脚本、所见即所得的资源和脚本编辑,稳定的自动同步功能。
是目前国内最好的银行业务测试工具.
LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner能够对整个企业架构进行测试。
通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。
目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。
难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢,系统崩溃等问题。
这些都不可避免地导致公司收益的损失。
测试用例编写规范
1目的:
统一测试用例编写的规范,以保证使用最有效的测试用例,保证测试质量。
2范围:
适用于公司对产品的业务流程、功能测试测试用例的编写。
3术语解释
3.1测试分析:
对重要业务、重要流程进行测试前的分析。
3.2业务流程测试用例:
关于产品业务、重要流程的测试用例。
4业务流程测试用例编写原则
4.1系统性
4.1.1对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;
4.1.2对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系;
4.2连贯性
4.2.1对于系统业务流程来说,各个子系统之间是如何连接在一起,如果需要接口,各个子系统之间是否有正确的接口;
如果是依靠页面链接,页面链接是否正确;
4.2.2对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系统,其内部功能接口是否连贯;
5测试用例设计的方法
5.1等价类划分法
5.1.1确定等价类的原则
5.1.1.1如果输入条件决定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。
5.1.1.2如果输入条件规定了输入值的集合,或者规定了“必须如何”的条件,此时可确立一个有效等价类和一个无效等价类;
5.1.1.3如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类;
5.1.1.4如果规定了输入数据的一组值,而且程序对每个输入值分别进行处理,此时可为每一个输入值确立一个有效等价类,此外,针对这组值确立一个无效等价类,它是所有不允许输入值的集合;
5.1.1.5如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同的角度违反规则)。
5.1.1.6如果确知,已划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类。
5.1.2测试用例的选择原则
5.1.2.1为每一个等价类规定一个唯一的编号;
5.1.2.2设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步,直至所有的有效等价类都被覆盖过;
5.1.2.3设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直至所有的无效等价类都被覆盖为止。
5.2边界值分析法
5.2.1测试用例的选择原则
5.2.1.1如果输入了条件规定了值的范围,则应取刚达到这个范围的边界值,以及刚刚超越这个边界范围的值作为测试输入数据;
5.2.1.2如果输入条件规定了值的个数,则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据;
5.2.1.3根据规格说明的每个输出条件,使用前面的原则;
5.2.1.4如果程序的规格说明给出的输入输出域是有序集合,则应选取集合的每一个元素和最后一个元素作为测试用列;
5.2.1.5如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例;
5.2.1.6分析规格说明,找出其他可能的边界条件。
6测试用例设计的原则
6.1全面性
6.1.1应尽可能覆盖程序的各种路径
6.1.2应考虑存在跨年、跨月的数据
6.1.3大量数据并发测试的准备
6.2正确性
6.2.1输入界面后的数据应与测试文档所记录的数据一致
6.2.2预期结果应与测试数据发生的业务吻合
6.3符合正常业务惯例
6.3.1测试数据应符合用户实际工作业务流程
6.3.2兼顾各种业务变化的可能
6.4仿真性
人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例;
不允许出现与知名人士、小说中人物名等雷同情况。
6.5可操作性
测试用例中应写清测试的操作步骤,不同的操作步骤相对应的操作结果。
7测试用例编写格式细则
7.1测试用例内容
7.1.1具体实施可以采用EXCEL和图形相结合,可用EXCEL编写测试用例的同时插入图形来加以说明。
测试用例设计的内容可由:
模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组成。
7.1.2在测试用例设计模版中有“业务流程测试用例设计模版”(包含整体业务流程)和“功能测试用例设计模版”两个模板可按需要选择。
7.2测试用例表格格式
7.2.1表格内容的字体为宋体;
7.2.2表格内容的字型为12号;
8测试用例优先级
测试用例优先级描述
A测试计划中重要的模块功能和业务流程
B测试计划中比较重要的模块功能和业务流程
C测试计划中次重要的模块功能和业务流程
D测试计划中不重要的模块功能和业务流程
E系统小单元、系统容错功能
对于A、B级应重点考虑
9BUG级别
参考软件测试停止标准中的错误级别
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 定义