Software Testing
2017-09-28 21:06:36 2 举报AI智能生成
software Testing
作者其他创作
大纲/内容
黑白盒测试
黑盒测试的定义
把程序看作一个黑盒子，在完全不考虑程序内部结构和内部特性的情况下检测每个功能是否正常使用。
白盒测试的定义
又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试
静态测试的定义
不运行程序，只是对程序进行检查和审核
动态测试的定义
使用和运行程序进行检查
通过性测试的定义
审查软济南，描绘状态，尝试各种合法可能性，确认状态及其转换正常
失效性测试的定义
为破坏软件而设计和执行的测试用例
等价类测试的定义
依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试。
等价类满足的条件
被测系统对该等价类中的每个数据的处理方式相同（保证等价）
各等价类之间互不相交，即每个数据唯一隶属于一个等价类（保证不冗余）
所有等价类的并集是整个输入域（保证完备）
有效等价类的定义
对于SRS而言，合理有意义的输入数据构成的集合
无效等价类的定义
.对于SRS而言，不合理无意义的输入数据构成的集合
强组合的定义
最终得到的测试用例完全覆盖所有输入条件的有效等价类的所有组合情况
弱组合的定义
测试用例仅需覆盖所有输入条件的有效等价类即可
引入等价类划分的原因
避免测试工作量过大，并且测试不合理
等价类划分的定义
依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试
等价类测试的目标
目标是从理论上追求测试的完备性和无冗余性
基于：独立性假设和单缺陷假设而使用等价类测试
边界值分析法的定义
在被测对象的边界及边界附近设计测试用例
边界值测试的原因
大量缺陷发生在被测对象的输入域或输出域的边界上
整体输入域
多个输入条件共同构成的具有一定实际意义的输入域
个体输入域
输入条件分别构成的单个输入域的集合
邻域
对于每个输入条件的每个边界点(设为P点)，需在该点附近确定大小为1的邻域
穷举法：在每个边界点的邻域范围内取所有数据
强边界法
测试用例覆盖所有输入条件的所有边界组合可测试到所有的边界组合，但不利于缺陷的隔离和定位
弱边界法
基于单缺陷假设，仅覆盖输入条件的单个边界点即可
全边界法
强边界+弱边界
最好的测试用例的设计
典型值法+弱边界法
测试用例的设计
1.输入域的确定2.边界点的确定3.确定邻域4.测试用例的设计
正交表的特点
均衡分散整齐可比
正交试验法
正交试验法是指安排组织试验的一种科学方法。它利用一套规格化的表格，即正交表来设计试验方案和分析试验结果，能够在很多的试验条件中，选出少数几个代表性强的试验条件，并通过这几次试验的数据，找到较好的生产条件，即最优的或较优的方案
使用正交表设计测试用例
1.选择个体输入域，确定所有输入条件及其最大取值范围2.确定每个输入条件的取值个数3.选择合适的正交表4.建立正交表5.生成测试用例
基于正交表的测试用例
当输入条件较多，并且条件中参数值较多，若组合设计用例数量较大，则考虑使用正交实验法设计测试用例
决策表
是一个用表格形式来整理逻辑关系的工具，由横向的条件（因）和动作（果）和纵向的规则（测试用例）组合而成
使用决策表生成测试用例
1.分析条件和动作2.生成决策表3.简化决策表4.转成测试用例
场景设计的基本原则
最少的场景数等于事件流的总数，基本流与备选流的总数2.有且唯一有一个场景仅包含基本流3.对应某个备选流，至少应有一个场景覆盖，且在场景中应该避免覆盖其他备选流
基于场景的测试基本思想
通过分析不同事件的触发顺序和处理结果；构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同的场景，最终基于场景设计测试用例
基本流
从系统的某个初始状态开始，经一系列状态变化后到达终止状态的过程中最主要的一个业务流程。
备选流
以基本流为基础，在经过基本流每个判定节点处满足不同的触发条件从而导致其他事件流
因果图
用图解的方法表示输入输出之间的各种组合关系，写出判定表，从而设计相应的测试用例
因果图测试
1.分析需求2.找出因果关系，原因与原因之间的关系，画出因果图3.将因果图转换成决策表4.根据（3）中的决策表，设计用例的输入数据和预期输出
因果图的使用场景
应用的输出结果依赖于各种输入条件的组合或各种输入条件之间有某种相互制约关系时
因果图法
从需求中找出因(输入条件)和果(输出或程序状态的改变)，通过因果图转化成判定表，通过判定表生成测试用例的方法。
状态迁移图法
是一种基于产品规格分析，对系统的每个状态及与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程
有限状态机，可以用状态图，状态表，状态树表示
状态迁移图的使用步骤
1.根据需求，理解关键字段，获得主要的状态2.绘制状态迁移图3.画出状态迁移树4.抽取测试用例规则（每个状态至少到达一次）
白盒测试
白盒测试基于软件的源代码和程序结构
白盒测试的优点
针对性强、测试效率高、成本低
对测试人员的技术要求较高
被测对象是函数
对函数代码和结构的测试
引入白盒测试覆盖指标来评估黑盒测试方法的覆盖率
静态白盒测试概述
不需要实际运行被测软件，而是直接对软件源代码的形式和结构进行分析
静态白盒测试包括
代码检查、静态结构分析、代码质量度量
代码检查
代码检查主要是通过同行评审(Peer Review)来发现缺陷
以评审会议的形式，通过多人对软件交付物进行检查，从而发现缺陷，或者获得改进优化的机会。
同行评审往往需要大量投入时间和人力资源
同行评审的优势
促使参与者在有监督压力下工作，提高责任心、有助于在开发早期发现需求和设计中的缺陷、有助于帮助程序员发现不足，提高工作质量
检查方法
审查、团队评审、走查、结队编程、同行桌查、轮查、特别检查
一般原则
优先测试根节点、然后叶子节点、然后接口数量多的节点
图直观反映函数的内部逻辑结构、展示程序中明显缺陷、揭示程序是否隐含缺陷
静态结构分析的局限性
在远离代码的条件下对程序进行分析、需要通过源代码评审、后续的动态白盒测试来进一步对源代码进行测试覆盖，以期找到更多潜伏的软件缺陷
语句覆盖：设计测试用例时应保证程序的每一条可执行语句至少执行一次
判定覆盖：设计测试用例时应保证程序中每个判定节点的取真和取假分支至少执行一次。局限性：未彻底分析每个简单判定条件的取值情况，仍然会导致遗漏部分缺陷
条件覆盖：设计测试用例时应保证程序中每个复合判定表达式中，每个简单判定条件的取真和取假情况至少执行一次。局限性：条件覆盖不能保证100%的判定覆盖
测试用例的设计应满足判定节点的取真和取假分支至少执行一次，且每个简单判定条件的取真和取假情况也应至少执行一次，即判定覆盖+条件覆盖。局限性：考虑条件的组合情况and错写为or，判定/条件覆盖是无法发现这种缺陷
条件组合覆盖：测试用例的设计应满足每个判定节点中，所有简单判定条件的所有可能的取值组合情况应至少执行一次。实质是通过列出真值表的方式来得到完全的覆盖，即以冗余换取方法的简单性
修正的判定/条件覆盖：在满足判定/条件覆盖的基础上，每个简单判定条件都应独立地影响到整个判定表达式的取值实质是利用简单判定条件的独立影响性来消除测试用例的冗余
对判定的测试
列出所有简单判定条件；构建真值表；对每个简单判定条件，找到能对整个判定结果产生独立影响的测试用例集合（简称独立影响对），即在真值表中依次固定其他简单判定条件，找到该条件的独立影响对；抽取能体现所有简单判定条件独立影响性的最少独立影响对。
常见的判定测试覆盖指标
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、修正的判定/条件覆盖
测试用例优化
尽量选择边界测试数据、应避免与或关系的屏蔽现象
路径覆盖
设计测试用例，是被测程序中每一条路径至少执行一次（不一定能满足条件覆盖，一定满足判定覆盖）
程序图
压缩后的控制流图、特殊形式的有向图
环复杂度
程序结构复杂度的度量模型（不能超过10）
直接观察法：封闭区域个数+1
公式计算法：V(G)=e-n+2
e图中的边数n图中节点个数
判定节点法
V(G)=P+1
基本复杂度
通过对程序图中结构化设计节点不断进行压缩
对循环的测试
在循环的边界和运行的界限内对循环体的执行过程进行测试
循环结构的分类
串联、嵌套、非结构化的循环
对循环的测试一方面对测试过程进行静态检查，另一方面通过控制循环的边界来观察执行结果是否和预期输出保持一致
定义/引用异常缺陷
变量在使用之前未被定义、变量被定义但未被使用、变量在使用之前被多次定义
子主题
Software Testing
软件测试核心概念
软件的定义
软件（Software）= 程序（P）+数据（库）（DB）+文档(D)+服务(S)
程序的定义
程序是表示能够完成预定功能和性能指令的集合。
数据的定义
数据（库）是依照某种数据模型组织起来并存储在二级存储器中数据的集合。
文档的定义
文档指软件在开发、使用和维护过程中产生的文字和图形的集合。
服务的定义
服务指通过提供必要的手段和方法，满足接受服务的对象需求的过程。
软件的特点
（1）软件靠人的智力劳动创造出来，并且还有较大的随意性。
（2）软件必须依托于具体的硬件设备才能运行，硬件的改变很可能导致软件的不可用。
（3）软件不会磨损，但会经常维护和升级，测试升级后的软件注意对旧版本的兼容性
软件测试的定义
软件测试是使用人工和自动化手段来运行或测试某个系统的过程，其目的在于检验被测试软件系统是否满足规定的需要，或是弄清楚被测系统的预期结果与实际结果之间的差别。
软件测试的目的
软件测试的根本目的是确保软件满足用户需求。
软件测试的目的是要衡量软甲产品是否符合预期。
软件测试是一个持续进行的过程。
软件测试的原因
提高软件质量、确保软件满足需求。
软件测试不一定提高软件质量
软件测试不负责修复缺陷，并且受到时间、成本等方面的限制，不是所有发现的缺陷都能及时被修复
软件缺陷的定义
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好、软件未达到需求规格说明书中指明的功能、软件出现了需求规格说明书中指明不该出现的错误、软件功能超出需求规格说明书中指明的范围、软件未达到需求规格说明书中虽未指出但应达到的目标。
软件测试用例的定义
一组测试输入执行条件和预期效果
测试用例的目的：满足特定的目标
测试用例=输入+输出+测试环境
自动化测试的定义
通过测试工具、测试脚本等手段，按照测试工程师的预定计划对软件产品，进行自动化调试，从而验证软件是否满足用户的需求。
自动化测试的好处：良好的可重复性、可操作性、高效率
软件测试背景
软件测试的发展历程
初始阶段、定义阶段、集成阶段、管理、测量和最佳化阶段
软件测试的现状
国外现状
（相当成熟，已成为一个独立的产业）、软件测试在公司中的地位非常重要、软件测试的理论研究蓬勃发展、软件测试市场繁荣
国内现状
（萌芽中的市场正在起步）对软件测试的认识和重视程度在不断提高、对软件产品化测试的技术研究从手动向自动化方式转变、软件测试人员需求大，人员素质不断提高、测试服务体系初步形成规模
总体职业特点
人才需求大、职业稳定、无性别歧视、但仍需掌握一定的业务能力和技术能力
外包测试的模式
现场测试模式
内部测试模式
完全离岸外包模式
现场增援与离岸结合模式
设立联合研究中心模式
学习软件测试的意义
软件测试工程师有扎实的理论基础、软件开发工程师帮助分析复杂需求，提高代码质量
软件开发模型的定义
软件开发的全部过程、活动、任务和管理的结构框架。
开发模型的常见类型
瀑布模型、边做边改模型、喷泉模型、快速原型模型、RAD模型、基于构件的开发模型
大爆炸模式
优点：思路简单
缺点：开发过程是非工程化的，随意性大，结果不可预知，除此之外开发任务完成之后，修复较困难
边写边改模式
简单考虑到了软件的需求，产品周期短
没有计划和文档的编制 但测试工作由于新的版本不断产生，测试工作长期循环
瀑布模型
瀑布模型的使用步骤
需求分析、系统设计、程序设计、编码、测试、运行及维护
瀑布模型的优点：结构性强、将软件生存周期各个活动规定为依次线性顺序连接的若干阶段的模型、易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板
瀑布模型的缺点：线性严格，成果晚出，风险大、阶段固定，反复迭代不合适，灵活性差、单次需求，需求变更多，适应性差、测试滞后，缺陷晚查，代价大
瀑布模型适合在功能、性能明确完整，需求固定，无重大变动的场景，如操作系统，数据库管理系统
敏捷开发模型
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，同时软件项目在构建初期被切分成多个子项目，各个子项目成果都经过测试，具备可视、可集成和可运行使用的特征
软件测试流程
熟悉需求、拟定测试计划、设计测试用例/开发测试脚本、搭建测试环境、实施测试、测试评估、测试总结
熟悉需求的方法
阅读相关说明、阅读有关资料、提出疑问、站在用户角度进行需求评审
软件测试计划
在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试。
测试用例的定义
为实施测试而向被测试系统提供的输入数据、操作或各种环境设置及期望结果等信息的一个特定集合
设计测试用例的原因
理解测试思路，避免遗漏
自由主题
收藏
0 条评论
回复 删除
下一页
