ImageVerifierCode 换一换
格式:DOCX , 页数:54 ,大小:1.51MB ,
资源ID:9022240      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/9022240.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(软件测试知识点.docx)为本站会员(b****7)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

软件测试知识点.docx

1、软件测试知识点软件测试的概论1.什么是软件质量 是指满足用户需求的程度A.明确定义的功能和性能需求B.明确定义的开发标准和准则C.隐含要求的其他特性2.软件的组成 文档、数据和程序的集合。3.测试 Testing 引申:度量、检测。4.什么是软件测试?(有争议) 是对数据、文档和程序的一种度量和检测。5.软件测试和软件质量之间的关系是什么? 软件测试是为了提高软件质量而服务的,是保证软件质量的手段6.软件测试的目的是什么?A.验证 (软件是否正确的实现了用户的某一特定功能 (挑错)B.确认 (软件符合用户需求)7.软件测试的对象 文档、数据和程序 文档(需求规格说明书、概要设计说明书、详细设计

2、说明书、用户手册(帮助文档)等等) 数据(还包括图片、视频等) 程序(源码、模块、部件、软件)8.软件测试的原则是什么?A.所有的测试活动都应以用户需求(软件需求规格说明书)为标准B.应尽早地和不断的进行软件测试 (和看病一个道理)C.完全测试是不可能的 (例如:计算器)D.应充分注意测试中的集群现象(第一个:2 . 8 定律 20%的错误有80个 80%错有20个)E.程序员应避免检查自己的程序F.尽量避免测试的随意性9.软件测试工程师的作用是什么? 尽可能早的发现软件缺陷,并确保其得以修复10.软件测试的衡量标准是什么? 多、快、好、省11.总结:从最初的软件质量-引申出软件测试-了解软件

3、测试需要了解什么内容就是我们关心的了软件质量-软件测试-软件的组成-测试- -对象-目的-原则-软件测试工程师-衡量标准软件测试的基础1.软件生存周期模型 阶 段 基本任务 基本任务 问题定义 理解问题 生产电冰箱 可行性研究 理解工作范围 产值、产量、技术能力等 需求分析 定义用户要求 市场调研 概要设计 建立软件结构 主体设计 详细设计 各模块的功能实现 图纸设计 编码 编写程序 制造 测试 发现和排除错误 检验检测 维护 运行和管理 保质保修2.软件需求分析 需求是 用户对系统提出的要求,这种要求可能是原始的、笼统的,也可能是抽象的太细节化的 软件需求分析的主要目的是:在综合分析用户对系

4、统提出的一组需求(基本功能、性能、数据等方面)的基础上,构建一个从抽象到具体的逻辑模型表达软件将要实现的需求。 并以“软件需求规格说明书”的形式作为本阶段工作地结果,为下一个阶段的软件设计提供设计的基础3.概要设计 又称总体设计,即确定系统的具体实现方案、给出软件的模块结构、编写总体设计说明书4.详细设计 又称过程设计,这一步的工作,就是要对系统的每个模块给出足够详细的过程性描述。这种描述不是程序的书写,而是用一些工具来表示每个模块,所以这种描述是不能够在计算机上运行的。5.什么是Bug? Bug一词的原意是“臭虫”或“虫子”。现在泛指计算机硬件和软件中的缺陷或错误6.缺陷的特征: 1、软件未

5、实现需求说明书要求的功能 2、软件出现了需求说明书指明不该出现的错误 3、软件实现了需求说明书未提到的功能 4、软件未实现需求说明书未明确提及但应该实现的目标 5、软件难以理解、不易使用、运行缓慢等。7.为什么会产生缺陷? 信息传递的错误 1、用户想要的 2、用户所说的 3、需求人员理解的 4、系统需求规格说明书 5、开发人员理解的 6、实际软件 实际软件及用户想要的有偏差。8.缺陷的分布: 第二个: 2 . 8 定律 (60%需求 20%设计 ) 8 . (15%编写 5%其他)29.缺陷修复的成本 需求设计 设计阶段 编码阶段 支付阶段10.软件测试的模型: 什么是软件测试的模型: 测试模

6、型是对测试工作活动的总结及归纳。 它告诉了我们在软件开发过程中,测试人员应该做什么、怎么做。第一大关键问题 V模型:最常见的测试模型: 下降的是开发过程各阶段 右边上升的是测试活动的各阶段局限性 软件测试作为需求分析、概要设计、详细设计和编码之后的一个阶段,而前期需求 的问题要到测试活动的后期(验收测试)才会暴露出来。 W模型: 是V模型的一种发展 它强调了测试应该伴随着整个开发周期,及开发同步进行。优点 试的不仅仅是程序,需求分析和概要设计同样需要测试 更符合“尽早地和不断地进行软件测试 ”的原则 H模型: 单元(模块)测试 针对软件设计中最小的单位进行正确性校验集成测试 在单元测试的基础上

7、,将程序模块进行有序的、递增的组装测试11.单元测试: 目标: 检验程序最小单元有无错误(类、文件、窗口、菜单、报表或一个存储过程) 接口、数据结构、便捷、覆盖、逻辑 检验单元编码及设计是否吻合 依据: 详细设计,编码 方法: 白盒测试 测试执行人: 开发工程师12.软件测试的分类-按开发阶段分 验收测试: 系统(确认)测试: System Testing 测试两个或多个单元 是为了验证和确认系统是否达到了用户的原始目标。 检验组成整个系统的代码、以及系统的软硬件配合有无错误 代码实现的系统及用户需求是否吻合 检验系统的文档等各种是否完整、有效 模拟验收测试的要求,检查系统是否符合用户的验收标

8、准 单元测试:Unit Testing 检查应用程序的小单元和模块 集成测试:Integration Testing 测试整个系统 系统测试: 性能测试:所有的活动都作为性能测试的一部分执行,且及白盒测试紧密联系。彻底检 查并监控系统,通过所有可能的输入和预期的输出结果来测量系统 可用性测试:检查输出结果和错误消息以判断其是否有意义、是否简单 开发界面时要考虑用户的教育背景和理解能力 GUI 测试:窗体测试、空间测试、菜单测试 图形用户界面是基础代码的前端,是用户和软件交互的工具 配置和安装测试:检查软件安装,这个流程也判断系统是否能在不同的平台上安装或卸载 恢复测试:有意使系统发生故障 如果

9、系统自我恢复,将确认重新初始化和检查点机制是否正确 安全性测试:拒绝XX的访问 都是经过身份验证的用户13.验收测试: 又称交付测试,即当软件完成单元测试、集成测试、系统测试之后,我们依据软件需求规格说明书,对软件进行一次全面的测试,完成对软件整体质量的评估 1.有效性测试 是在模拟的环境运用黑盒测试的方法,验证软件是否满足需求规格说明书列出的需求。 2.软件配置复查 保证软件配置的所有成分都齐全,各方面的质量都符合要求,文档内容及程序完全一致。 测试:先在公司内部的环境上运行,由公司员工先试用,提出反馈意见和发现缺陷。 测试:让少数用户或者公司合作伙伴使用,提出反馈意见和发现缺陷。(微软和Q

10、Q) 正式验收:用户根据验收测试报告独立完成或者在测试人员指导下完成。14.软件测试的分类-按测试实施者分: 开发方测试 开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求。 用户测试 用户通过运行和使用软件,检测及核实软件实现是否符合自己预期的要求。 第三方测试 介于开发方和用户之间的测试组织的测试。15.软件测试的分类-按测试技术分: 白盒测试 通过对程序内部结构的分析、检测来寻找问题。 黑盒测试 通过软件的外部表现来发现其缺陷和错误。 灰盒测试 结合了以上两种测试方法。16.测试分类测试策略黑盒测试 白盒测试手动测试 自动测试静态测试 动态测试总结:第一章了解到了软件测试的概

11、论 那么这章了解到了软件测试的基础首先了解到得是软件生存周期模型,在了解软件生存周期模型上,了解到了什么是软件需求设计,概要设计,详细设计等软件测试?我们要发现的是什么?我们要发现的Bug。在了解Bug之后,必须要了解为什么会有Bug?它的特征是什么?分布?修复的成本那么我们怎么样能更加好的测试呢?由此引出了模型(V模型 、 W 模型 、 H 模型)软件测试的分类软件生存周期-软件需求分析-概要设计-详细设计Bug-为什么会产生-特征是什么-怎么分布的-修复的成本模型-V模型-W模型-H模型软件测试的分类-按开发阶段分(验收测试、系统(确认)测试、集成测试、单元测试)-按实施者分(开发方测试、

12、用户测试、第三方测试)-按技术分(黑盒测试、白盒测试、灰盒测试)-测试策略(黑盒测试、白盒测试 - 手动测试、自动测试 - 静态测试、动态测试)软件测试功能测试用例设计1.测试用例的定义: 测试用例就是记下我们要进行什么测试,进行测试的具体步骤,以及测试执行是否正确的标准 测试用例是一个包含输入和预期输出并及实际输出有关的标志 解决要测什么、怎么测和如何测的问题 所有的预期输出缺一不可2.测试用例的用途和目的: 执行测试,发现缺陷 重新执行测试,重现缺陷 管理测试过程 回归测试,验证缺陷是否修复 使测试更加方便的执行 提高测试效率 便于进行回归测试 使测试过程更方便管理3.影响测试用例测试的主

13、要因素 需求目标 用户实际使用场景 软件功能需求规格说明书 测试的方法 测试的对象4.测试用例的编写原则: 准确性:测试用例的设计确实符合测试需求,并且必须准确地说明测试的内容 简洁性:测试用例的设计中必须包含完成测试必要的步骤、要素,不需要加入多余的、可有 可无的步骤、要素 可重用性:测试用例的设计要求测试是可控的,它能够使任何人在任何时间进行测试都能获 得同样的结果 适用性:测试用例对于当前的测试环境和测试者而言是可以执行的 纯净性:不会因为执行该测试用例而影响其它测试用例的执行,用例中应说明如何将应用系 统恢复到最初状态,而不影响后续测试的进行。5.测试用例的编写有三种主要格式: Ste

14、p-by-step (按步骤) Matrix (矩阵表) Automated script (自动化脚本) 前两种是测试用例最基本的格式,最后一种是自动执行前两种测试用例的软件脚本。6.测试用例设计的方法: 黑盒测试方法:1)等价类划分法2)边界值分析法3)场景法4)错误推测法5)因果图法6)判定表驱动法7)正交试验设计法8)功能图法白盒测试:1)语句覆盖2)判定覆盖3)条件覆盖4)判定/条件覆盖5)路径覆盖7.编写有效的测试用例 使用合理的语言: 测试人员该做什么,系统输出什么应该写得很清楚明白,也就是说首先要分清楚测 试用例的输入和预期输出 避免含义混淆,方法:在操作步骤中采用动词+名词的

15、结构,动词总是测试人员要 做得事情,名词总是测试人员操作的对象、事物 制定命名规则,同一种事物只有一种名称 使用模版: 编写测试用例更方便 提高测试用例的组织性 提供了标准 格式统一美观 有助于测试人员寻找信息 能够包括很多有关测试过程的选项 使用克隆: 模仿某个测试用例来写别的测试用例 某些用户手册中的步骤、文字也可以被克隆 保存以前写过的测试用例,以便以后进行克隆 Matrixes测试用例也可以克隆,特别是在表结构相同的情况下,只需要改变一些列 的名称和值就可以 测试用例的依赖关系: 具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用 例 考虑是否真的需要其他的测试的结

16、果作为数据输入,如果是,那么测试必需是累积 的。应尽量避免这种情况,以免让测试变得繁琐 保持测试用例依赖关系的正确性和一致性 以一种合理的顺序来安排测试用例的顺序8.测试用例示例 1.测试用例标识 2.测试步骤 3.输入 4.预期输出 5.实际输出 6.特殊过程的要求 7.及其他测试用例的依赖关系 8.环境要求 8.1 硬件 8.2 软件 8.3 其他9.测试模板包含的内容项目名称 程序版本测试坏境编制人 编制时间功能名称功能特性测试目的预制条件参考信息 特殊规程说明用例编号 测试步骤 边界值 输入数据 预期结果 测试结果总结:为什么有测试用例?怎么样把它做到最好从测试用例的定义到怎么编写一个

17、好的测试用例定义-用途和目的-编写原则-影响因素-编写格式-方法-有效的测试用例-测试用例的模板最主要的是理解 - 方法软件测试功能测试用例设计(黑盒测试 等价类方法)1.测试用例:预期输入不同就写一个测试用例2.黑盒测试 内部实现不可见 关注的只有输入和输出 (这两个条件是否满足需求)3.黑盒测试发现的常见错误A.功能不正确或遗漏B.界面错误C.数据库访问错误D.性能错误4.黑盒测试的特点 从理论上来讲,黑盒测试只有采取 穷举输入 测试,把所有可能的输入都作为测试情况考虑,才能查出所有的错误 实际上测试情况是无穷多的,完全测试是不可能的。 如何解决 把黑盒测试加以分类 1、节约测试实施的时间

18、和资源 2、避免盲目测试、提高测试效率 3、使测试的实施重点突出、目的更明确5.分类 1、等价类划分法 2、边界值分析法 3、错误推测法 4、因果图法 5、判定表驱动法 6、正交试验设计法 7、功能图法(把软件分解为相对独立的功能单元 8、场景法 结合一起使用6.等价类划分 讲程序的输入域分成若干部分,然后从每个部分中选取少数代表性数据作为测试数据 特点:代表性数据在测试活动中的作用等价于这一类中其他的数据 分类:有效和无效等价类 有效等价类: 对于程序的需求说明来说是合理的,有意义的输入数据所构成的集合 利用它可以检验程序是否实现了预期的功能和性能 无效等价类: 对于程序的需求说明来说是不合

19、理的,没有意义的输入数据所构成的集合 利用它可以检验程序对于无效数据的处理能力7.划分等价类的方法: A . 在输入条件规定了取值范围的情况下,则可以确立以个有效等价类和两个无效等价类 如:输入值是学生成绩,范围是 0100 有效: 0 =成绩=100 无效:成绩100 B . 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效 等价类和一个无效等价类; 如:填写验证码 C . 在输入条件是一个布尔量(true和false)的情况下,可确定一个有效等价类和一个无效等价类。 如:我同意条款才能执行下一步 QQ安装 D . 在规定了输入数据的一组值(假定n个),并且程

20、序要对每一个输入值分别处理的情况下,可确立n 个有效等价类和一个无效等价类。 如:密码查询问题 默认的“请选择密码查询问题”是无效等价类 E . 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等 价类(从不同角度违反规则); 如:申请邮箱号码 F:在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划 分为更小的等价类。(细分) 如:数据 : 数值 和 非数值 / 数值:非服数值 和 负实数 / 数值: 字母 和 空格8.等价类划分的特点和注意事项 等价类的特点 测试内容相同 如果等价类中的一个测试能够捕获一个缺陷,那么选择

21、该等价类中的其他测试也能 捕获该缺陷 如果等价类中的一个测试不能够捕获一个缺陷,那么选择该等价类中的其他测试也 不能捕获该缺陷 两类划成一类,结果? 一类划成两类,结果? 注意 考虑无效等价类 仔细划分9.怎么设计测试用例 1)为每一个等价类规定一个唯一的编号; 2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步, 直到所有的有效等价类都被覆盖为止; 3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到 所有的无效等价类都被覆盖为止。黑盒测试(边界值分析法)1.边界值分析法 对程序输入或输出的边界值进行分析和测试,是对等价类划分法的一种补

22、充。2.边界值分析法的特点: 1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。 2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。 通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、尺寸、空间等。 相应地,以上类型的边界值应该在:最大/最小、首位/末位、最短/最长、 空/满等情况下。3.边界值方法小结 输入或输出的边界最容易产生错误 确定边界值的方法 对取值范围进行界定 对取值个数进行界定 有序集合 分析规格说明,找出其他边界条件 隐含的边界值 2的乘方 ASCII表4.边界值分析法的使用 1)如果输入条件规定了值的范围,则

23、应取刚达到这个范围的边界的值,以及刚刚超越这个 范围边界的值作为测试输入数据。 如果程序的规格说明中规定:“重量在10公斤至50公斤范围内的邮件, 其邮,其费计算公式为:货物重量*费率=邮费”。 有效等价类边界值(10、10.01、50、49.99) 无效等价类边界值(9.99、50.01) 2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作 为测试数据。 比如,一个输入文件应包括1255个记录,则测试用例可取1和255,还应取0及256等。 3)将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。 问题:某程序的规格说明要求

24、计算出“每月保险金扣除额为0至1165.25元”,如何取其测 试数据? 有效等价类边界值(0.00、0.01、1165.24、1165.25) 无效等价类边界值(-0.01、1165.26) 4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个 元素作为测试用例。 5)分析规格说明,找出其它可能的边界条件。黑盒测试(功能图法、错误推测法、场景分析法)1.功能图法 就是用功能图形象地表示程序的功能说明,并机械地生成功能图的测试用例。 功能图模型由状态迁移图和逻辑功能模型组成。 例如:Windows的屏幕保护程序测试(有密码保护功能)2.错误推测法 是基于经验和

25、直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例 错误推测法本身不是一种测试技术,而是一种可以应用到所有测试技术中产生更加有效 的测试的一种技能。3.错误推测法基本思想 列举出程序中所有可能有的错误和容易发生错误的特殊情况来设计测试用例 例如: 以前测试时曾出现过错误的地方,包括单元测试、集成测试、系统测试、前几次回 归测试 输入数据的问题,如是否可为空,是否可以有特殊字符,是否可以小于0、等于0 等等 一些问题的范围或边界4.场景分析法的定义 用例场景是通过描述流经用例的路径来确定的过程,这个流经过程要从用例开始到结束 遍历其中所有基本流和备选流。5.为什么引入用例场景 现在

26、的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同 一事件不同的触发顺序和处理结果形成事件流。 这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情 景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。6.场景分析法实例 上图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用 例的最简单的路径。备选流用不同的彩色表示,一个备选流可能从基本流开始,在某个 特定条件下执行,然后重新加入基本流中(如备选流 1 和 3);也可能起源于另一个备 选流(如备选流 2),或者终止用例而不再重新加入到某个流(如备选流 2 和

27、 4)。 场景分析法实例 遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将 基本流和备选流结合起来,可以确定以下用例场景: 场景 1 基本流 场景 2 基本流 备选流 1 场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3 场景 5 基本流 备选流 3 备选流 1 场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 场景 8 基本流 备选流 3 备选流 4 注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。7.测试用例8. 生成每个场景的测试用例是通过确定某个特定条件来完成的,这个

28、特定条件将导致特定用例场景的执行。 每个场景写一个测试用例总结: 选择测试用例的综合策略 首先进行等价类的划分,包括输入条件和输出条件的等价类划分 在任何情况下都必须使用边界值分析方法 可以使用错误推测法追加一些测试用例 对照程序逻辑,检查已设计的测试用例的逻辑覆盖程度 如果程序的功能说明中含有输入条件的组合情况,则一开始就选用因果图法和判定表驱动法对于参数配置类的软件,要用正交试验法选择较少的组合方式达到最佳效果 功能图法也是很好的测试用例设计方法,可以通过不同时期条件的有效性设计不同的测试数据 对于业务流清晰的系统,可以利用场景法贯穿整个测试案例过程,在案例中综合运用各种测试方法 白盒测试

29、在测试时,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特征的情况下,在程序接口进行测试,他只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能够适当地接受输入数据产生正确的输出信息。通常情况下使用工具测试1. 白盒测试方法: 语句覆盖:使程序中每个语句至少执行一次 语句覆盖是最弱的逻辑覆盖 判定覆盖:使每个判定的真假分支都至少执行一次 判定覆盖仍是弱的逻辑覆盖 条件覆盖:使每个判定的每个条件的可能取值至少执行一次 条件覆盖不一定包含判定覆盖 判定覆盖也不一定包含条件覆盖 判定/条件覆盖:选取足够多的测试用例,使判断中的每个条件的所有可能取值至 少执一次,同时每个判断本身的所有可能判断结果至少执行一次. 能同时满足判定、条件两种覆盖标准。 路径覆盖:(想到及场景法)最好的一种2.白

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1