测试总结.docx
《测试总结.docx》由会员分享，可在线阅读，更多相关《测试总结.docx（21页珍藏版）》请在冰豆网上搜索。
测试总结
软件的概念
1、软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档的完整集合。
它是以程序数据加文档的完整集合
2、软件=程序+数据（库）+文档+服务
1、客户需求、市场需求文档软件规格说明书技术设计文档测试文档在线帮助产品发布注释产品软件包
2、软件的特征
软件是硬件的灵魂，硬件是软件的基础
3、软件开发过程
需求分析：
根据客户的要求，清楚了解客户需求中的产品功能，特征、性能、界面和具体规格等，然后进行分析确定软件产品功能所能达到的目标。
设计：
根据需求分析的结果，考虑如何在逻辑、软件上去实现所定义的产品功能、特征等。
可分为概要设计和详细设计，也可分为数据结构设计，软件体系结构设计，
为什么需要测试？
是否需要进行软件测试却就业与软件开发过程是否存在缺陷，前期的缺陷导致缺陷放大，使软件质量度低，进度、成本无法控制异常的庞大。
从而得出的结论是：
要尽早测试，尽早发现问题。
根源：
1、客户需求度；2、软件系统复杂性（多人合作）；3
软件开发的要素主要有人员，过程，工具三个要素
人员：
分析人员，设计人员，开发人员，测试人员，配置管理人员，质量保证人员（SQA）
软件测试的定义
软件测试就是为了发现错误而审查软件文档，检查软件数据的过程。
软件测试和质量保障的区别
测试的目的：
相依最少的时间和人力，系统的找出软件中潜在的各种错误和缺陷，如果我们成功的实施了测试，我们就能后发现软件中的错误。
测试附带收获是，它能够证明软件的功能和性能
软件测试的原则：
所有的软件测试都应追溯到用户需求。
应当把尽早的和不断的进行软件测试，作为软件测试者的座右铭。
完全测试是不可能的，测试需要终止。
测试无法显示软件潜在的缺陷，也就是说测试只能证明软件存在错误而不能证明软件没有错误。
ISO9126质量模型
六大特性:
功能性可靠性易用性效率维护性可移植性
功能性：
所提供用户的功能是用户所需要的，用户所需要的功能软件系统已提供。
准确性：
软件系统提供给用户的功能是否满足用户对该功能的精确度要求。
互操作性：
软件系统和一个或多个周边系统进行信息交互的能力。
保密安全性：
软件系统保护信息和数据的能力
1、防止未得到授权的人或系统访问相关的信息或数据
2、保证得到授权的人或系统能正常访问襄垣的信息或数据。
不同的系统对于安全性的需求差别很大
常见的安全性测试
1、用户验证:
登录密码验证，IP地址访问限制等
2、用户权限管理:
验证低级别用户是否具有高级别用户的权限，各级别
解决办法：
限制请求次数
分析系统业务处理中哪些是消耗大量资源、哪些是响应时间非常长的，针对这类业务有目的地去验证系统是否有防DOS攻击防范手段。
防溢出攻击：
加密、解密：
在计算机通讯录中，采用密码技术将信息隐藏起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全。
防病毒：
功能性的依从性：
遵循相关的标准（国际标准、国家标准行业标准企业标准的内部规范等）约定或者法规以及类似规定的能力。
软件的可靠性
1、成熟性软件系统防止内部错误扩散而导致失效的能力
子系统、模块、单元模块
2、容错性软件系统防止外部接口错误扩散而导致系统失效的能力。
3、易恢复性系统失效后重新恢复原有功能，性能的能力。
设计人员应该充分分析外部接口可能产生的错误，然后在设计上对这些意义予以防范，防止这些外部闯入的错误破击自身而失效。
原有能力恢复的程度；原有能力恢复的速度
软件的易用性
1、易理解性：
用户在使用软件系统的过程中，系统交互给用户的信息是否准确，清晰，易懂，能帮助用户准确理解系统当前真实的状态，指导其进一步操作。
2、易学性：
软件系统提供相关的辅助手段
3、吸引性：
美观：
GUI界面、手机外观等
新颖：
如夏新手机来电跳舞功能
4、易用性的依从性：
遵循相关的标准
软件效率（性能测试）
1、时间效率：
系统在各业务场景下完成用户指定的业务请求所需的响应时间
2、资源效率 ：
系统在各业务场景下完成用户指定的业务请求所消耗的系统资源，
软件的可移植性
1、适应性：
软件系统无需做任何
产生原因：
工期短，任务大
程序设计错误
文档不完善
需求不断变化
沟通交流不够
软件的复杂性
软硬件支持不完善
软件缺陷的主要类型
功能特性没有实现或部分实现
设计不合理，存在缺陷
实际结果和预期结果不一致
运行出错
数据结果不正确，精度不够
用户不能接受的其他问题如存取时间长，界面不美观
软件缺陷严重性级别
致命的：
致命的错误，造成系统或应用程序崩溃，死机，系统
再现与优化缺陷的方法
不要想当然的接受任何假设
查找时间依赖和竞争条件的问题
与压力和负荷相关的边界条件软件缺陷，内存泄漏和数据溢出缺陷的发生由一定的前提条件。
缺陷报告：
准确清晰简洁完整一致
软件测试分类
按测试范围分类单元测试组件测试系统测试验收测试安装测试
按测试目的分类正确性分类白盒测试黑盒测试性能测试可靠性测试
按测试过程分类需求阶段测试
按技术和方法测试回归法压力法恢复测试安全测试兼容性测试
黑盒测试实用技术
黑盒测试技术是软件测试的主要方法之一，黑盒测试的基本概念、方法、操作步骤、功夫剧等内容是必须掌握的，
黑盒测试的基本概念：
黑盒测试就是把程序看做一个不能打开的黑盒子。
由于黑盒测试不考虑程序内部结构，只关心软件输入输出的功能。
所以许多搞成的测试如确认测试、系统测试、验收测试都采用黑盒。
是否有不正确或遗漏的功能？
界面是否有错误？
在接口上，输入能否正确地接受？
能否输出正确的结果？
是否有数据结构错误或外部数据库访问错误？
性能上是否满足要求？
初始化或终止性错误？
黑盒测试的优缺点
优点：
从产品功能角度测试可以最大程度满足用户的需求。
相同动作可重复执行，最枯燥的部分可由机器完成。
依据测试用例针对性地找寻问题，定位更准确，容易生成测试数据。
将测试直接和程序/系统要完成的操作相关联。
缺点：
代码得不到测试
如果规格说明设计有误，很难发现。
测试不能充分的进行
结果取决于测试用例的设计
黑盒测试方法
等价类划分法；边界值分析法；因果图法、判定表
场景法；功能图法；错误推测法；正交测试设计法。
测试用例原则
根据程序的需求和一旦发生故障将造成的损失。
策略
1、首先进行等价划分，包括舒服条件和输出条件的等价划分，将无限测试变成有限测试，
有效等价类：
无效等价类：
边界值分析方法：
常见的边界值
常见的边界值通常表现在
条件桩动作项
场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的地表示触发顺序和处理结果就形成事件流。
功能图法
功能图分析使用功能图形象地表示功能的程序说明。
错误推测法
基于以往经验和直觉来，参照以往的软件系统出现的错误，推测程序中所有可能存在的各种缺陷和错误，从而有针对性的设计测试用例。
错误推错法的基本思路是：
列举出陈旭中所有可能有的错误和容易发生错误的特殊情况，根据可能出现的错误情况选择测试用例。
正交实验设计法
黑盒测试方法正交实验设计法：
通过正交实验理论来指导测试用例的选取，仪表能够用较少的测试用例使测试充分，本方法在系统测试用例的设计中不常用。
正交实验设计法依据Galois。
设计步骤：
1、有哪些因素
2、每个因素有哪几个水平
3、选择一个合适的正交表
4、把变量的值
黑盒测试步骤
缺点：
在传统的软件开发中，测试工作往往被放在整个开发过程的后期进行，当应用程序的编码已经完成后，才开始进行测试，这样做有缺点：
1、不利于发现早期设计过程（概要设计、初步设计、系统设计）中存在错误；
2、如果早期设计过程存在错误没有被发现，在程序编码进行单元测试才发现是早期设计过程中产生的错误，这给才测试工作带来的工作是相当大的，同样也增大了测试成本。
从某种程度上说，部分工作就需要重做。
3、不利于提高工作效率，影响开发进程。
运维开机方式：
直接开机远程开机物理开机
白盒测试：
1、结构测试，逻辑驱动测试，透明盒子测试和基于代码的测试。
按照程序内部的结构、逻辑驱动测试程序，通过测试来检测产品内部动作是否按照设计说明书的规定正常进行，检验程序的每条路径是否都能按预定要求正确工作。
白盒测试的基本概念、检查方法、测试方法、
动态测试
静态测试
原则：
先静态测试再动态测试得组合方式，然后进行覆盖测试
保证一个模块中所有路径至少被测试一次
多有逻辑值
8大类：
软件公用问题的测试
语言测试
SQL语句测试
数据类型测试
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
测试依据：
软件需求报告
软件需求规格说明
程序设计文档
软件界面设计
编码规范
开发命名标准
静态测试
静态方法是指不运行被测程序本身，仅通过分析或检查程序的文法、结构、过程、接口等来检查程序的正确性
正式审查程序结构化分析
正式审查基本条件
确定问题：
审查的目的是找出软件的问题不仅是出错的项目，还包括遗漏的项目。
要注意对事不对人。
遵守规则:
要遵守一套固定的规则，规则可能设定要审查的代码量、花费多少时间、哪些内容要做评价等。
准备：
每一个参与者都为审查做准备，并尽自己的力量。
编写报告：
审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成员使用。
进行正式审查要按照已经建立起来的过程执行。
随意“聚在一起复查代码”是不够的，实际上还会造成危害
正式审查方法：
检验
同事审查
走查
同行审查
检验：
Preparation:
评审，如果评审没有通过，召开第三小时会议；还是解决不了怎么办？
再开会
最正式的审查类型
按照定义好的过程执行
Overviewpreparationinspectionmeetingreworkfollow-up
代码审查应涵盖的下列方面
业务逻辑的审查：
主要审查是否是按照实现设计的规格说明展开编程，逻辑是否正确且简单，思路是否清晰
算法的效率：
无论是内存处理还是通缉排序算法，或者SQL语句，都需要精心设计算法，确定最优化的方法
代码风格：
代码的命名规则、注释行、嵌套次数、书写格式等直接影响了软件的可读性、可维护性和可靠性等方面的质量
编程规则：
包括语句的完整性、数据定义的准确性、常量和变量的定义、函数调用、参数的使用、内存管理、逻辑表达式等。
执行规则保证程序运行的正确性、准确性、性能、稳定性可可扩充性等。
通过代码审查清单
数据引用错误
数据声明错误
计算错误
比较错误
控制流程错误
输入输出错误
其他检查
控制流分析
非结构化程序会给测试、排错和成宿的维护带来许多不必要的
对程序结构的基本要求
SQL语句测试
语句的检查
类型的转换
代码检查的分析与评价
代码检查的分析与评价主要注意一下两大点；
1、能力
陈述经代码检查证实了的本软件的能力
2、缺陷和限制
什么是数据流的分析
数据流问题
如果程序中某一个语句执行时能够改变某个程序变量v的值，则称v是被该语句定义。
如果一语句的执行引用了内存中变量v的值，则说该语句引用的变量v。
该程序中两个错误
1语句2使用了变量W
引用为定义变量
条件覆盖法
测试覆盖准则
测试用例敏感分析
测试覆盖率计算
覆盖率=（至少被执行一次的item数）/item的总数
语句覆盖率=（至少被执行一次的语句数量）/（可执行的语句总数）
判定覆盖率=（判断结果被评价的次数）/（判定结果的总数）
条件覆盖率=（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）
判定条件覆盖率=（条件操作数值或判定结果至少被评价一次的数量）/（条件操作数值总数+判定结果总数）
路径覆盖率=（至少被执行一次的路径数）/（总的路径数）
需求覆盖率=（被验证到的需求数量）/（总的需求数量）
继承上下判定覆盖率=（累加每个上下文内执行到的判定分支数）/（上下文数*上下文内的判定分支总数）
基于状态的上下文入库覆盖率=（累加每个状态内执行到的方法数）/（状态数*类内方法总数）
函数覆盖率=（至少被执行一次的函数数量）/（系统中指令块总数）
指令块覆盖率=（至少被执行一次指令块的数量）/（系统中指令块总数）
DDP覆盖率=（至少被执行的一次的半段路劲数量）/（系统中判断路径总数）
分支条件组合覆盖率=（被评测到的分支条件组合数）/（分支条件组合数）
Ppp覆盖率=（至少被执行的一次的ppp数量）/（系统中ppp总数）
案例编号：
（HR.GR.KF.T.0001）
需求编号
前置条件:
（进入华润银行个人银行演示版）
测试路径:
（华润银行/）
测试目的
测试步骤（需要标明123步骤）
预期结果（每一步都要对应预期结果：
正案例，反案例）
用例设计人
用例优先级
调整是否通过
程序插桩
软件动态测试中，插桩测试是一个被广泛应用的测试方法。
插桩测试就是向源程序中国插入语句然后执行程序，通过打印语句，获得动态信息。
程序插桩技术的研究设计下列几个问题：
1、探测哪些信息？
2、程序的什么位置设置探测点
3、需要多少探测点
4、程序中特定位置插入某些用以判断特性的语句
插桩类型：
用于测试覆盖率和测试用例有效性度量的程序插桩。
基本路径测试法
基本路径测试法是在程序
程序插桩：
1、当出现需要for循环语句，while虚化语句中进行插入信息时，很可能导致程序预期时间非常长，是否有办法改进‘插桩’机制？
2、是否可以由用户进行机制，比如for语句，while语句或者制定的御酒前不允许进行插桩，怎么实现？
3、如果对于一个庞大的系统软件，我们需要进行
基本步骤
1、程序的控制流图：
描述程序控制流图是对程序流程图进行简化后得到的，他吐出表示程序控制流的结构，程序控制流图是描述程序控制流的一种方式，
2、导出基本路径，画出测试用例
基本路径测试方法是在控制流图的基础上，
将程序流程图简化成控制流图时，应注意：
在选择或多分支结构
域测试法
域测试是一种基于程序结构的测试方法，基于对程序输入空间的分析，选择测试点进行测试，主要为：
域错误：
程序的控制流程存在错误，对于某个特定的输入可能执行的是一条错误路径，这种错误成为路径错误，
计算型错误：
对于特定输入执行的路径正确，但赋值语句的错误导致输出结果错误，
丢失路径错误：
由于程序中某处缺少了一个判定谓词而引起的丢失路径错误
符号测试：
符号测试基本思想是允许程序的输入不仅仅是具体的数值数据，而是包括符号值，符号值可以是基本的符号变量值，也可以是符号变量值的表达式。
1、符号测试执行的是代数运算，可以作为普通测试的一个扩充；
2、符号测试可看做是程序测试和程序验证的一个折中办法
3、符号测试程序中仅有有限的几条执行路径
2.分支问题：
当采用符号执行方法进行到某一点分支处，分支谓词是符号表达式，这种情况下通常无法决定谓词的取值，也就不能决定
二义性问题
数据项的符号值可能是有二义性的，这种情况通常出现带有数组的程序中，如果i=j,则x=3,否则x=2+a，但由于使用符号值运算，这是无法知道i是否等于j.
3.大程序问题
符号测试中总是要处理符号表达式。
随着符号执行继续，一些变量的符号表达式会越来越庞大。
特别是当符号执行数如果很大
Z路径覆盖法
分析程序中的路径是指检验程序从入口开始，执行过程中经历的各个语句，直到出口
Z路径覆盖 对循环机制进行简化，减少路径的数量，使得覆盖所有路径成为可能，简化循环意义下的路径覆盖称为Z路径覆盖（循环简化：
限制循环次数，只考虑循环一次或零次情况），循环简化的目的是限制循环的次数，无论循环的形式和循环体实际执行的次数，简化后的循环测试只考虑执行循环体一次和零次（不执行）两种情况，即考虑执行时进入循环体一次和跳过循环体这两种情况。
开发：
单元测试集成
测试：
部分集成，系统测试冒烟测试主要功能
测试的功能点测试点写测试用例
全面测试步骤界面输入输出
开发修改
回归测试
确认测试
验收测试
α测试
β测试
再循环简化的思路下，循环与判断
程序变异测试法
程序变异是一种错误驱动测试。
错误驱动测试是指该方法针对某类
基本思想：
对于给定的程序p，先假定程序中存在一些小的错误，每假设一个错误，程序p就变成p，
存在测试数据Ci
程序强变异测试
变异测试的缺点是它需要大量的计算机资源来完成测试充分性分析。
对于一个中等规模的软件，需要的存储空间也是巨大的，运行变异因子也导致了时间上巨大的开销。
程序弱变异测试
弱变异和强变异有很多相似之处。
其这组要差别在于：
弱变异强调的是变异程序的组成部分，根据弱变异准则，只要实现确定导致C与C’产生不同值得测试数据组，则可将程序在测试数组上运行，而并不实践产生其变异因子。
弱变异测试方法主要优点是开销较小，效率较高
流程图符号
梳理结构
选择结构
多重选择结构（二元选择结构变化结构）
重复结构
流程图绘制原则
流程图重心主轴及胖纸说明，主轴内个流程图文字请就键入keyword,个细部流程若需补充说明，请精简条例以虚线胖纸说明，每点以下不超过二行为原则
各项细部流程有办理期程者，应注明
各项步骤有选择或决策结果，如（可，否）、（通过、不通过）或其他相对文字时，
相同流程图符号宜大小一致
同一路径符号之间指示箭头应只有一个
开始符号在流程图中只能出现一次，但结束符号则不限，若流程图能一目了然，则开始符号及结束符号可省略
选择结构及重复结构之间选择
Web专题
Web测试的特点
Web测试：
用户通过计算机中安装的浏览器就可以访问指定的URL网页进行测试
Client测试：
在系统中安装一个客户端软件才能运行测试
Mobile测试：
需要用手机设备才能测试
Web确定路径访问页面没有问题
获取浏览器版本：
cat/
手机测试：
用户界面测试
文字重叠、剪切、对齐
界面测试其他问题
各个界面的演示风格是否统一
各个页面的辩题是否正确
导航处是否按相应的栏目级别显示导航文字是否在同一行显示
文章列表页左侧的栏目是否与一级、二级栏目的名称，顺序一致
提示、警告或者错误说明应清楚移动，用词准确，没有模棱两可的字眼
所有的图片是否都被正确装载，在不同的浏览器，分辨率下都是否正确显示
切换窗口大小，缩小窗口后，页面是否按比例缩小或者出现滚动条，各个页面缩小的分割是否一致（Ctrl+鼠标滚动缩小；Ctrl+0还原）
在窗口中按键盘上的tab键，观察移动聚焦是否按顺序移动从左到右，从上到下
按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置
菜单项的措词准确，能够表达出所要进行设置的功能，菜单项的顺序合理具有逻辑
关联的项目集中放置。
特殊输入域测试常见验证点
日期填充域常见验证点
输入不符合格式的数据，检查程序是否正确校正
无效日期处理（判断时间点标准是什么是否大于当前时间等）
出生日期填写为未来日期（选择错误）
将结束日期设置在开始日期之前（对比点，约束条件）
电话号码填充域常见验证点
电话号码应该由一组数字组成，不能包含英文字母
如果有分机号，中间用破折号分隔
（后台怎么做分隔：
）
电子邮箱的格式：
***@***.***（顶级域名和二级域名）
Client测试特点
安装测试
正常情况：
首次安装测试、升级安装测试、完整安装测试、自定义安装测试、
异常情况：
磁盘空间不足、缺少目录创建权限
首次安装测试：
软件协议安装路径、
重复测试：
在本机安装程序并运行、保持程序正在进行，再次安装客户端程序
预期结果：
提示退出当前正在运行程序
卸载安装：
通过程序自身
UI测试：
用户界面：
是指软件见得可见外观及其底层与用户交互部分（菜单、对话框、窗口和其他控件）
测试用户的分割是否满足客户要求
字体、颜色，风格是否符合设计标准
页面的排版，格式是否美观一致，是否符合一般操作习惯
不同分辨率下，显示效果是否符合设计要求
菜单权限检查
功能权限检查数据权限检查
同一用户是否允许同事登陆系统
页面清单是否完整
页面特别效果
页面菜单项总计数是否超过三级
页面布局检查
字体、颜色、风格是否符合设计标准
页面的排版，格式是否美观一致、是否符合一般操作习惯
不同浏览器中，显示效果是否符合设计要求
不同分辨率，
权限检查
菜单权限检查
边界测试注意测试关键点
操作项为空，非空、不可编辑
操作项的唯一性
字符长度、格式
数字、邮政编码、全额、电话~
页面元素注意点
实现功能需要列出的按钮、单选按钮、复选框、列表框、
翻页功能点
首页：
上一页、下一页、伟业：
在存在数据时，
表格测试
验证表格是否设置正确
表格细节信息是否正确
是否可以
特定格式类型：
日期格式
升级会员 