哈哈哈哈哈哈哈哈还好吧
11
软件测试所遵循的原则
质量、人员、资源
再测试一下
测试
3-2 软件测试类型-性能测试
2-2 软件测试手段
2-1软件测试阶段
需要学习jUnit测试可搜以下课程:
1-1软件测试概要
*
敏捷测试
测试遵循原则
Script-based Testing
Script Testing(ST)
Linux 命令怎么使用
定义:软件本身的兼容性(对历史版本的配置或数据兼容)
不同平台下的兼容性(ubuntu centos redhat等)
运行设备的兼容性(32位的 平板电脑 小型机等)
软件的互操作性(与一些主流的应用是否兼容)
浏览器内核
浏览器兼容性测试工具
Browsershots browsersandbox Google浏览器兼容性测试插件(页面代码层面测试)
定义:对软件产品进行测试以确保符合产品安全需求和质量标准
渗透测试:通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试(取得了用户的授权)
安全测试vs安全测试
渗透测试:攻 、薄弱点
安全测试:防 、面、难度高
OWASP:Open Web Application Security Project(开放web应用安全项目)
前10名的漏洞问题:
注入:脚本或sql注入 页面输入构造
失效的身份漏洞或身份管理
跨站脚本:使用户浏览器能执行动态的内容
不安全的对象的直接引用:在url中修改参数
安全配置错误:如框架、服务有默认密码
敏感信息泄露:没对关键信息加密
功能级别的访问控制缺失:能够导航到用户没有权限的地方
跨站请求伪造:外部的一个恶意的网站获取到正常的数据
使用了已知的有漏洞的组件:没有及时打补丁
未被验证的重定向或转发:重定向没有没验证 可以被黑客转移到钓鱼网站
安全测试工具:
Appscan(Web 应用)
Webinspect
Nessus(服务器 主机类)
Nmap
MetaSploit(著名攻击软件)
WebScarab
Fortify(源代码静态分析)
W3AF(Web应用)
敏捷测试
Agile Testing
宣言:强调了个体的沟通重于过程,对于软件看重结果轻文档,客户视角与客户合作创造更多的价值,拥抱变化
特点:
强调从客户的角度测试
重点关注迭代测试新功能,不在强调测试阶段
尽早测试,不间断测试,具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷(给整个研发提出建设性的意见,质量改进的建议,全方位的参与到软件研发的各个层面,提升整个团队的工作效率和保证产品质量)
与传统测试的区别:
传统测试是质量的最后保护者;开发和测试人员是紧密合作的,大家都有责任对软件负责
传统测试有严格的变更管理;变更是可接受的,拥抱变更
预先的计划和细节的准备(测试计划、测试方案、测试用例、规程文档);敏捷计划随着进展时常调整;
重量级文档;只需要绝对必要的文档
各个阶段测试严格的入口与出口标准;各迭代之间已经没有明显的入口与出口标准
更多在回归测试时进行重量级的自动化测试;所有阶段都需要自动化测试,每个人都需要做
严格依赖流程执行;流程不再需要严格执行(注重测试结果,规则就是被打破的)
测试团队和开发团队是相互独立的;团队合作是无缝隙的合作(整个测试持续不断的质量反馈的过程,从研发生命周期的开始,就把测试过程中的问题持续不断的反馈给我们的开发人员、项目经理,及时知晓研发过程中的质量现状并且及时的进行改正)
基于脚本的测试-SBT
Scripted Testing(ST)
Exploratory Testing(探索式测试):
完全抛开测试脚本的测试 探索被测系统,带着问题使用系统,在探索的过程中发现测试要点,找出被测系统的问题,在测试过程中测试设计和测试执行是并行的,更自由;
它是一种测试风格、思维而不是一种测试技术
局部探索式测试:
输入:接收输入 产生输出 存储数据 进行运算 输入顺序 输出内容 输出异常
状态:临时状态(运行时有效 阶段性有效) 永久状态(数据库保存 文件保存)
代码路径:对代码的覆盖率
用户数据:模拟真实用户数据
执行环境:软件运行的操作系统 网络拓扑 三方系统 系统的配置数据 硬件设备
全局探索式测试:
像游客游览一样测试系统
商业区:软件从启动到关闭用户可能使用到的一些功能
旅馆区:软件在没有运行时的功能如定时任务、一些后台进程
历史区:历史遗留的功能
旅游区:新用户使用或关注的功能(新手指引等)
娱乐区:辅助功能
破旧区:隐藏或遗弃的功能,用户看不到
执行探索式测试:
Konw You Mession:了解测试任务的重点 主要测试方向 系统的环境
Learnging Session:详细学习和探索被测系统 业务逻辑 系统功能
Coverage Session:测试执行阶段 完成测试点的覆盖
Deep Session:更深入的发散式的测试
Close Session:总结 整理 复盘阶段
基于风险的测试-RBT
Risk-based Testing
风险:
质量风险(功能 易用性 性能 软件功能缺失 数据的转换)
管理风险(人员的技能不足 人力不足 测试环境不具备 被测系统的需求不够清晰 三方系统有问题等)
风险级别:风险的可能性*风险的严重度
识别风险:
可能性:复杂性(越复杂风险越大)时间压力 高变更率 技能水平 地理分散度(研发团队太分散 集成上有潜在的问题)
严重程度:使用频率 失效可视性 商业损失(支付功能 计费功能) 组织负面影响和损害 社会损失和法律责任
优点:优先测试的都是高风险的部分 对质量信心的提升非常明显
基于模型的测试-MBT
按软件测试模式来分类
1、瀑布模型
项目计划:制定研发计划,确定里程碑节点,输出项目计划书
需求分析:明确用户的需求定义,并对定义进行清晰的描述,充分理解客户需求明确产品功能,输出需求规格说明书
软件设计:根据需求确定产品实现的方案,概要设计、详细设计的多个文档
程序开发
软件测试:独立的测试的小组,评估产品是否满足需求,输出测试报告
集成维护:根据用户使用情况对产品进行修改
优点:强调需求、设计的作用;前一阶段完成后。只需关注后续阶段;为项目提供了按阶段划分的检查点,里程碑清晰;文档规范
缺点:难以适应需求的频繁变化;项目周期后段才能看到成果;强制里程碑、完成时间点;文档工作量大
没有体现出测试的地位和价值,测试阶段只是补救的阶段,缺陷发现太晚,修改成本高
2、V模型
使用最广泛的模型
明确表明了测试过程的不同阶段,描述了测试阶段与开发阶段的对应关系
单元测试、集成测试:检测程序是否满足设计上的要求
系统测试:软件在功能、性能上是否满足系统要求的指标
验收测试:是否满足用户的要求和合同的标准
在V模型里强调了软件开发的协作和速度,反应测试活动和分析设计的关系,并且将软件的实现和验证有机的结合起来。
局限性:仅仅把测试过程作为在编码后面的阶段,需求和系统设计的验证只能在验收测试中发现
3、W模型
V模型的改进模型
测试伴随整个开发周期,对需求和设计都全面测试,有利于尽早的发现问题
及时了解项目风险
局限性:开发与测试仍然是线性关系
4、X模型
5、H模型
将测试流程看成是一个独立的模型,与软件其他流程并发进行
按照测试手段分类:黑盒测试、白盒测试;静态测试、动态测试;手工测试、自动化测试
一、黑盒测试
不考虑程序内部结构和特性下,通过相关暴露出的接口,对程序进行测试
只检查程序的功能是否按照需求规格说明的规定正常使用
程序是否能正常的接收输入数据并产生输出数据
一般针对软件界面或可见的功能
从用户的视角,通过不同的数据驱动系统,通过输出来判断
优缺点:
优点:容易实施,不需要关注内部的实现;更贴近用户的使用角度
缺点:测试覆盖率较低,一般只能覆盖到代码量的不到40%
针对黑盒的自动化测试,复用率较低,维护成本较高(关注功能,变化多的也是功能 自动化测试代码维护成本高)
黑盒测试主要测试什么:
1)是否有不正确或遗漏的功能;
2)在接口上,输入是否能正确的接受,能否输出正确的结果;
3)数据结构错误或外部信息(文件数据)访问错误;
4)性能是否满足要求
设计方法:
1)等价类划分法:输入条件等价的归为一类,形成几组代表性的输入
2)边界值分析法:关注边界条件
3)错误推测法:基于经验或直觉来判断程序中可能出现错误,针对性的设计测试用例(文件超大或文件不存在;界面输入时考虑特殊字符)
4)因果图法:对多种输入条件组合的测试方法
5)正交试验分析法:筛选代表性的输入数据
6)状态迁移图法:梳理软件功能点中的状态关系,画出状态变迁图设计测试用例
7)流程分析法:梳理程序的逻辑执行的路径来设计测试用例
二、白盒测试(结构化测试 透明盒测试)
1、根据程序的逻辑结构来设计测试用例,用逻辑的覆盖率来衡量测试的完整性,强调逻辑
2、逻辑的单位:
语句 :语句覆盖指的是用例设计出来保证每一条语句至少执行一次
条件 :保证每一个条件表达式执行一次
条件组合: 覆盖所有不同条件的组合成果
分支 :每个分支执行一次
路径:每一个可能的路径至少执行一次
优点:迫使测试人员去仔细思考软件的实现,理解原理;可以检测代码中的每条分支和路径;揭露隐藏在代码中的错误;对代码的测试比较彻底
缺点:追求高覆盖率导致成本高;无法检测代码中遗漏的路径和数据敏感性(数据处理的有问题)的错误;不能直接验证需求的正确性
测试方法:
代码检测法:多面检查 走查
静态结构分析法:测试工具分析源代码的内部逻辑结构
静态质量度量法
逻辑覆盖法
基本路径测试法
三、灰盒测试
介于黑白盒测试之间的,关注输出对于输入的正确性,同时也关注内部表现
四、静态测试
不运行被测程序,直接看文档或代码,来发现程序的不足
互审 走查 会议
五、动态测试
动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等
六、手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用于针对深度的测试和强调主观判断的测试(探索性测试)
七、自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查(单元测试 接口测试 性能测试)
八、手动测试与自动化测试区别
1、手工测试的优缺点
易发现缺陷(创造性 主观性)
容易实施(只要环境具备 人员到位)
创造性、灵活性
覆盖量化难(人对测试做到什么程度很难量化、覆盖率能达到多少不好量化)
重复测试效率低
不一致性、可靠性低
人力资源依赖(依赖人能力的高低)
2、自动化测试
高效率、速度快
高复用性
覆盖率容易度量
准确、可靠
不知疲劳
机械、发现缺陷率低
一次性投入大(从测试工具的选型、框架的设计、脚本的编写与维护投入大)
其他测试
回归测试
Monkey测试
冒烟测试
AB测试
文档测试
可靠性测试
易用性测试
本地化测试
部署测试
无障碍测试
兼容性测试
安全测试
渗透测试
性能测试
软件测试类型
敏捷测试(Agile Testing)
遵循敏捷宣言的一种测试实践
探索式测试的优点:
更能激发测试人员的创造性和工作乐趣
增加了发现新的或较深入Bug的可能性
在较短的时间内找到更多Bug以及对SUT做一个快速的评估
有利于更加有效地实施自动化
更加适用于敏捷项目
减少了在简单、繁复上用例的无谓编写时间
探索式测试的缺点:
测试管理上有局限性,较难协调和控制
对于Bug的重复利用和重现上作用有限
对测试人员的测试技能和业务知识深度依赖较大
只有在SUT已完全可用的前提下才更有作用
ET的生产率很难定义
ET本身较难进行自动化
软件测试的分类
按阶段分类:单元测试、集成测试、系统测试、验收测试
单元测试
定义:对软件中的最小可测试单元进行检查和验证
原则1:尽可能保证各个测试用例时互相独立的
原则2:一般由代码的开发人员来实施,用以检验所开发的代码功能符合自己的设计要求
益处:能尽早发现缺陷、有利于重构、简化集成、文档、用于设计
集成测试
定义:是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装城模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
主要实施方案:Big bang、自顶向下、自底向上、核心系统集成、高频集成
与单元测试对比:测试的对象、依据、方法不同
系统测试
定义:是将经过集成测试的软件,作为计算机系统的一个部分,与系统中其他部分结合起来,在实际运行环境下对计算机系统进行一系列严格有效地测试,以发现软件潜在的问题,保证系统的正常运行
关注点:系统本身的使用、与其他相关系统的连通、在不同使用压力下的表现、在真实使用环境下的表现
与集成测试的对比:
验收测试
定义:也称交付测试。针对用户需求、业务流程的正式的测试,确定系统是否满足验收标准,由用户、客户或其他授权机构决定是否接受系统。
细分:用户验收测试、运行验收测试、合同和规范验收测试、alpha测试、Beta测试
软件测试的分类
软件测试模式