软件测试知识点Word文件下载.docx
《软件测试知识点Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试知识点Word文件下载.docx（54页珍藏版）》请在冰豆网上搜索。
概要设计建立软件结构主体设计
详细设计各模块的功能实现图纸设计
编码编写程序制造
测试发现和排除错误检验检测
维护运行和管理保质保修
2.软件需求分析
需求是用户对系统提出的要求，这种要求可能是原始的、笼统的，也可能是抽象的太细节化的
软件需求分析的主要目的是：
在综合分析用户对系统提出的一组需求（基本功能、性能、数据等方面）的基础上，构建一个从抽象到具体的逻辑模型表达软件将要实现的需求。
并以“软件需求规格说明书”的形式作为本阶段工作地结果，为下一个阶段的软件设计提供设计的基础
3.概要设计
又称总体设计，即确定系统的具体实现方案、给出软件的模块结构、编写总体设计说明书
4.详细设计
又称过程设计，这一步的工作，就是要对系统的每个模块给出足够详细的过程性描述。
这种描述不是程序的书写，而是用一些工具来表示每个模块，所以这种描述是不能够在计算机上运行的。
5.什么是Bug？
Bug一词的原意是“臭虫”或“虫子”。
现在泛指计算机硬件和软件中的缺陷或错误
6.缺陷的特征：
1、软件未实现需求说明书要求的功能
2、软件出现了需求说明书指明不该出现的错误
3、软件实现了需求说明书未提到的功能
4、软件未实现需求说明书未明确提及但应该实现的目标
5、软件难以理解、不易使用、运行缓慢等。
7.为什么会产生缺陷？
信息传递的错误
1、用户想要的
2、用户所说的
3、需求人员理解的
4、《系统需求规格说明书》
5、开发人员理解的
6、实际软件
实际软件及用户想要的有偏差。
8.缺陷的分布：
第二个：
2.8定律
（60%需求20%设计）8.（15%编写5%其他）2
9.缺陷修复的成本
需求设计<
设计阶段<
编码阶段<
支付阶段
10.软件测试的模型：
什么是软件测试的模型：
测试模型是对测试工作活动的总结及归纳。
它告诉了我们在软件开发过程中，测试人员应该做什么、怎么做。
第一大关键问题
V模型：
最常见的测试模型：
下降的是开发过程各阶段右边上升的是测试活动的各阶段
局限性
软件测试作为需求分析、概要设计、详细设计和编码之后的一个阶段，而前期需求的问题要到测试活动的后期（验收测试）才会暴露出来。
W模型：
是V模型的一种发展
它强调了测试应该伴随着整个开发周期，及开发同步进行。
优点
试的不仅仅是程序，需求分析和概要设计同样需要测试
更符合“尽早地和不断地进行软件测试”的原则
H模型：
单元（模块）测试
针对软件设计中最小的单位进行正确性校验
集成测试
在单元测试的基础上，将程序模块进行有序的、递增的组装测试
11.单元测试：
目标：
检验程序最小单元有无错误（类、文件、窗口、菜单、报表或一个存储过程）
·
接口、数据结构、便捷、覆盖、逻辑
检验单元编码及设计是否吻合
依据：
详细设计，编码
方法：
白盒测试
测试执行人：
开发工程师
12.软件测试的分类-按开发阶段分
验收测试：
系统（确认）测试:
SystemTesting测试两个或多个单元
是为了验证和确认系统是否达到了用户的原始目标。
检验组成整个系统的代码、以及系统的软硬件配合有无错误
代码实现的系统及用户需求是否吻合
检验系统的文档等各种是否完整、有效
模拟验收测试的要求，检查系统是否符合用户的验收标准
单元测试：
UnitTesting检查应用程序的小单元和模块
集成测试：
IntegrationTesting测试整个系统
系统测试：
性能测试：
所有的活动都作为性能测试的一部分执行，且及白盒测试紧密联系。
彻底检查并监控系统，通过所有可能的输入和预期的输出结果来测量系统
可用性测试：
检查输出结果和错误消息以判断其是否有意义、是否简单
开发界面时要考虑用户的教育背景和理解能力
GUI测试：
窗体测试、空间测试、菜单测试
图形用户界面是基础代码的前端，是用户和软件交互的工具
配置和安装测试：
检查软件安装，这个流程也判断系统是否能在不同的平台上安装或卸载
恢复测试：
有意使系统发生故障
如果系统自我恢复，将确认重新初始化和检查点机制是否正确
安全性测试：
拒绝XX的访问
都是经过身份验证的用户
13.验收测试：
又称交付测试，即当软件完成单元测试、集成测试、系统测试之后，我们依据软件需求规格说明书，对软件进行一次全面的测试，完成对软件整体质量的评估
1.有效性测试
是在模拟的环境运用黑盒测试的方法，验证软件是否满足需求规格说明书列出的需求。
2.软件配置复查
保证软件配置的所有成分都齐全，各方面的质量都符合要求，文档内容及程序完全一致。
α测试：
先在公司内部的环境上运行，由公司员工先试用，提出反馈意见和发现缺陷。
β测试：
让少数用户或者公司合作伙伴使用，提出反馈意见和发现缺陷。
（微软和QQ）
正式验收：
用户根据验收测试报告独立完成或者在测试人员指导下完成。
14.软件测试的分类-按测试实施者分：
开发方测试
开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。
用户测试
用户通过运行和使用软件，检测及核实软件实现是否符合自己预期的要求。
第三方测试
介于开发方和用户之间的测试组织的测试。
15.软件测试的分类-按测试技术分：
白盒测试
通过对程序内部结构的分析、检测来寻找问题。
黑盒测试
通过软件的外部表现来发现其缺陷和错误。
灰盒测试
结合了以上两种测试方法。
16.测试分类
测试策略
黑盒测试白盒测试
手动测试自动测试
静态测试动态测试
总结：
第一章了解到了软件测试的概论那么这章了解到了软件测试的基础
首先了解到得是软件生存周期模型，在了解软件生存周期模型上，了解到了什么是软件需求设计，概要设计，详细设计等
软件测试？
我们要发现的是什么？
我们要发现的Bug。
在了解Bug之后，必须要了解为什么会有Bug？
它的特征是什么？
分布？
修复的成本
那么我们怎么样能更加好的测试呢？
由此引出了模型（V模型、W模型、H模型）
软件测试的分类
软件生存周期---软件需求分析---概要设计---详细设计
Bug---为什么会产生---特征是什么---怎么分布的---修复的成本
模型---V模型---W模型---H模型
软件测试的分类---按开发阶段分（验收测试、系统（确认）测试、集成测试、单元测试）---按实施者分（开发方测试、用户测试、第三方测试）---按技术分（黑盒测试、白盒测试、灰盒测试）---测试策略（黑盒测试、白盒测试---手动测试、自动测试---静态测试、动态测试）
软件测试功能测试用例设计
1.测试用例的定义：
测试用例就是记下我们要进行什么测试，进行测试的具体步骤，以及测试执行是否正确的标准
测试用例是一个包含输入和预期输出并及实际输出有关的标志
解决要测什么、怎么测和如何测的问题
所有的预期输出缺一不可
2.测试用例的用途和目的：
执行测试，发现缺陷
重新执行测试，重现缺陷
管理测试过程
回归测试，验证缺陷是否修复
使测试更加方便的执行
提高测试效率
便于进行回归测试
使测试过程更方便管理
3.影响测试用例测试的主要因素
需求目标
用户实际使用场景
软件功能需求规格说明书
测试的方法
测试的对象
4.测试用例的编写原则：
准确性：
测试用例的设计确实符合测试需求，并且必须准确地说明测试的内容
简洁性：
测试用例的设计中必须包含完成测试必要的步骤、要素，不需要加入多余的、可有可无的步骤、要素
可重用性：
测试用例的设计要求测试是可控的，它能够使任何人在任何时间进行测试都能获得同样的结果
适用性：
测试用例对于当前的测试环境和测试者而言是可以执行的
纯净性：
不会因为执行该测试用例而影响其它测试用例的执行，用例中应说明如何将应用系统恢复到最初状态，而不影响后续测试的进行。
5.测试用例的编写有三种主要格式：
Step-by-step（按步骤）
Matrix（矩阵表）
Automatedscript（自动化脚本）
前两种是测试用例最基本的格式，最后一种是自动执行前两种测试用例的软件脚本。
6.测试用例设计的方法：
黑盒测试方法：
1）等价类划分法
2）边界值分析法
3）场景法
4）错误推测法
5）因果图法
6）判定表驱动法
7）正交试验设计法
8）功能图法
白盒测试：
1）语句覆盖
2）判定覆盖
3）条件覆盖
4）判定/条件覆盖
5）路径覆盖
7.编写有效的测试用例
使用合理的语言：
测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出
避免含义混淆，方法：
在操作步骤中采用动词+名词的结构，动词总是测试人员要做得事情，名词总是测试人员操作的对象、事物
制定命名规则，同一种事物只有一种名称
使用模版：
编写测试用例更方便
提高测试用例的组织性
提供了标准
格式统一美观
有助于测试人员寻找信息
能够包括很多有关测试过程的选项
使用克隆：
模仿某个测试用例来写别的测试用例
某些用户手册中的步骤、文字也可以被克隆
保存以前写过的测试用例，以便以后进行克隆
Matrixes测试用例也可以克隆，特别是在表结构相同的情况下，只需要改变一些列的名称和值就可以
测试用例的依赖关系：
具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例
考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积的。
应尽量避免这种情况，以免让测试变得繁琐
保持测试用例依赖关系的正确性和一致性
以一种合理的顺序来安排测试用例的顺序
8.测试用例示例
1.测试用例标识
2.测试步骤
3.输入
4.预期输出
5.实际输出
6.特殊过程的要求
7.及其他测试用例的依赖关系
8.环境要求
8.1硬件
8.2软件
8.3其他
9.测试模板包含的内容
项目名称程序版本
测试坏境
编制人编制时间
功能名称
功能特性
测试目的
预制条件
参考信息特殊规程说明
用例编号测试步骤边界值输入数据预期结果测试结果
为什么有测试用例？
怎么样把它做到最好
从测试用例的定义到怎么编写一个好的测试用例
定义---用途和目的---编写原则---影响因素---编写格式---方法---有效的测试用例---测试用例的模板
最主要的是理解------方法
软件测试功能测试用例设计（黑盒测试等价类方法）
1.测试用例：
预期输入不同就写一个测试用例
2.黑盒测试
内部实现不可见关注的只有输入和输出（这两个条件是否满足需求）
3.黑盒测试发现的常见错误
A.功能不正确或遗漏
B.界面错误
C.数据库访问错误
D.性能错误
4.黑盒测试的特点
从理论上来讲，黑盒测试只有采取穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出所有的错误
实际上测试情况是无穷多的，完全测试是不可能的。
如何解决
把黑盒测试加以分类
1、节约测试实施的时间和资源
2、避免盲目测试、提高测试效率
3、使测试的实施重点突出、目的更明确
5.分类
1、等价类划分法
2、边界值分析法
3、错误推测法
4、因果图法
5、判定表驱动法
6、正交试验设计法
7、功能图法（把软件分解为相对独立的功能单元
8、场景法
结合一起使用
6.等价类划分
讲程序的输入域分成若干部分，然后从每个部分中选取少数代表性数据作为测试数据
特点：
代表性数据在测试活动中的作用等价于这一类中其他的数据
分类：
有效和无效等价类
有效等价类：
对于程序的需求说明来说是合理的，有意义的输入数据所构成的集合
利用它可以检验程序是否实现了预期的功能和性能
无效等价类：
对于程序的需求说明来说是不合理的，没有意义的输入数据所构成的集合
利用它可以检验程序对于无效数据的处理能力
7.划分等价类的方法：
A.在输入条件规定了取值范围的情况下，则可以确立以个有效等价类和两个无效等价类
如：
输入值是学生成绩，范围是0~100有效：
0<
=成绩<
=100无效：
成绩<
0成绩>
100
B.在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类；
填写验证码
C.在输入条件是一个布尔量（true和false）的情况下,可确定一个有效等价类和一个无效等价类。
我同意条款才能执行下一步QQ安装
D.在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
密码查询问题默认的“请选择密码查询问题”是无效等价类
E.在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
申请邮箱号码
F：
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
（细分）
数据：
数值和非数值/数值：
非服数值和负实数/数值：
字母和空格
8.等价类划分的特点和注意事项
等价类的特点
测试内容相同
如果等价类中的一个测试能够捕获一个缺陷，那么选择该等价类中的其他测试也能捕获该缺陷
如果等价类中的一个测试不能够捕获一个缺陷，那么选择该等价类中的其他测试也不能捕获该缺陷
两类划成一类，结果？
一类划成两类，结果？
注意
考虑无效等价类
仔细划分
9.怎么设计测试用例
1）为每一个等价类规定一个唯一的编号；
2）设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
3）设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。
黑盒测试（边界值分析法）
1.边界值分析法
对程序输入或输出的边界值进行分析和测试，是对等价类划分法的一种补充。
2.边界值分析法的特点：
1）边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2）边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
通常情况下，软件测试所包含的边界检验有几种类型：
数字、字符、尺寸、空间等。
相应地，以上类型的边界值应该在：
最大/最小、首位/末位、最短/最长、空/满等情况下。
3.边界值方法小结
输入或输出的边界最容易产生错误
确定边界值的方法
对取值范围进行界定
对取值个数进行界定
有序集合
分析规格说明，找出其他边界条件
隐含的边界值
2的乘方
ASCII表
4.边界值分析法的使用
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
如果程序的规格说明中规定：
“重量在10公斤至50公斤范围内的邮件，其邮，其费计算公式为:
货物重量*费率=邮费”。
有效等价类边界值（10、10.01、50、49.99）
无效等价类边界值（9.99、50.01）
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。
3）将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
问题:
某程序的规格说明要求计算出“每月保险金扣除额为0至1165.25元”，如何取其测试数据?
有效等价类边界值（0.00、0.01、1165.24、1165.25）
无效等价类边界值（-0.01、1165.26）
4）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
5）分析规格说明,找出其它可能的边界条件。
黑盒测试（功能图法、错误推测法、场景分析法）
1.功能图法
就是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。
功能图模型由状态迁移图和逻辑功能模型组成。
例如：
Windows的屏幕保护程序测试（有密码保护功能）
2.错误推测法
是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例
错误推测法本身不是一种测试技术，而是一种可以应用到所有测试技术中产生更加有效的测试的一种技能。
3.错误推测法基本思想
列举出程序中所有可能有的错误和容易发生错误的特殊情况来设计测试用例
例如:
以前测试时曾出现过错误的地方，包括单元测试、集成测试、系统测试、前几次回归测试
输入数据的问题，如是否可为空，是否可以有特殊字符，是否可以小于0、等于0等等
一些问题的范围或边界
4.场景分析法的定义
用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
5.为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。
这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。
6.场景分析法实例
上图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。
备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；
也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和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.生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
每个场景写一个测试用例
选择测试用例的综合策略
首先进行等价类的划分，包括输入条件和输出条件的等价类划分
在任何情况下都必须使用边界值分析方法
可以使用错误推测法追加一些测试用例
对照程序逻辑，检查已设计的测试用例的逻辑覆盖程度
如果程序的功能说明中含有输入条件的组合情况，则一开始就选用因果图法和判定表驱动法
对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
功能图法也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据
对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合运用各种测试方法
白盒测试
在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特征的情况下，在程序接口进行测试，他只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能够适当地接受输入数据产生正确的输出信息。
通常情况下使用工具测试
1.白盒测试方法：
语句覆盖：
使程序中每个语句至少执行一次
语句覆盖是最弱的逻辑覆盖
判定覆盖：
使每个判定的真假分支都至少执行一次
判定覆盖仍是弱的逻辑覆盖
条件覆盖：
使每个判定的每个条件的可能取值至少执行一次
条件覆盖不一定包含判定覆盖
判定覆盖也不一定包含条件覆盖
判定/条件覆盖：
选取足够多的测试用例，使判断中的每个条件的所有可能取值至少执一次，同时每个判断本身的所有可能判断结果至少执行一次.
能同时满足判定、条件两种覆盖标准。
路径覆盖：
（想到及场景法）最好的一种
2.白
升级会员 