软件测试理论课程2.docx
《软件测试理论课程2.docx》由会员分享，可在线阅读，更多相关《软件测试理论课程2.docx（29页珍藏版）》请在冰豆网上搜索。
软件测试理论课程2
课程介绍
1.软件测试的类型（重要）
2.软件测试的方法（重要）
3.缺陷管理（重要）
4.软件质量（重要）
5.敏捷开发（了解）
1.软件测试的类型（重要）
1.1.功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
1.2.性能测试
相对于当前软件消耗的资源，它的产出能力。
一天吃3顿吼一天、一天吃2顿吼二天
性能测试是通过自动化的测试工具模拟多种正常、异常的条件来对系统的各项性能指标进行测试。
1.3.接口测试
接口测试是测试系统组件间接口的一种测试。
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
1.4.兼容性测试
兼容性测试（CompatibilityTestSuite）简称CTS，指对所设计程序与硬件、软件之间的兼容性的测试。
分为浏览器兼容测试和分辨率兼容测试两类。
IE,firefox,google,苹果
内核:
发动机
1.5.用户体验测试
用户体验测试（userexperience）顾名思义就是测试人员在将产品交付客户之前处于用户角度进行的一系列体验使用，如：
界面是否友好（吸引用户眼球，给其眼前一亮）、操作是否流畅、功能是否达到用户使用要求等。
1.6.安全测试
验证软件是否只能让授权用户提供功能使用。
ATM机：
不用输密码？
输错3次吞卡？
2.软件测试的方法（重要）
一、按测试对象进行分类：
白盒测试，黑盒测试
二、按测试对象是否执行：
静态测试，动态测试
三、按测试手段进行分类：
手工测试，自动化测试
2.1.白盒测试
白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试，也可称为程序员测试，主要应用于结构化开发环境,基于代码的测试
白盒测试的常用测试方法：
Ø代码检查法-静态测试
Ø逻辑覆盖法-动态测试
Ø基本路径测试法-动态测试
2.2.黑盒测试
黑盒测试又称功能测试、数据驱动测试或基于需求规格说明的测试.
黑盒测试它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序外部进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
2.3.静态测试
静态测试,不执行被测试的软件。
类似于汽车检查。
静态测试（statictesting）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
Ø对于代码测试，主要测试代码是否符合相应的标准和规范。
Ø对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。
Ø对于文档测试，主要测试用户手册和需求说明是否符合用户的实际需求。
2.4.动态测试
动态测试是在测试过程中执行被测试软件，类似于试车。
动态测试（dynamictesting），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程.
所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。
2.5.手工测试
由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境。
2.6.自动化测试
所谓自动化主要有两种形式，一种是自己写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。
优点就是可以高效率的去执行一些人工无法实现的操作。
3.软件质量（重要）
3.1.什么是软件质量？
质量就是一个实体的所有特性满足明显的或隐含需求的程度。
3.2.软件质量体现在哪些方面？
ISO质量模型：
1.功能性:
能满足明确和隐含需求的功能
2.可靠性:
成熟可靠,容错能力,易恢复
3.易用性:
易理解、易学习、易操作,颜值
4.效率性:
资源占用少,响应时间快
5.可维护性:
可被修改的能力
6.可移植性:
从一种环境迁移到另外一种环境的能力
【功能靠用，效率可”以”】
3.3.软件质量管理（SQM）由哪些构成？
软件质量管理分为软件质量保证（SQA）与软件质量控制（SQC）
软件质量保证（SQA）：
SQA：
事先的质量保证活动，以预防为主，通过制定相应的体系，流程，规范降低出错几率，通过控制流程，检查输出来确保品质是否满足于标准。
软件质量控制（SQC）：
SQC：
事后的质量检验活动，以测试为主，期望并发现错误，以体系要求运作，通过具体实施来检验产品来确保符合规定
软件质量保证（SQA）与软件质量控制（SQC）的主要区别：
SQC是保证产品质量符合规定,SQA是建立体系并确保体系按要求运作.
4.软件缺陷管理（重点）
4.1.软件缺陷的定义（了解）
4.1.1.软件缺陷的示例
系统蓝屏:
Win10系统在浏览器的地址栏中或使用其他Windows命令打开特定路径，即可使电脑系统崩溃并显示蓝屏。
\\.\globalroot\device\condrv\kernelconnect
4.1.2.Bug名称的由来
“名留青史”的飞蛾：
4.1.3.软件缺陷的定义
前面我们看到了软件失败所发生的事件的一些实例。
其后果也许是带来不便，比如电脑游戏玩不了，也可能是灾难性的，会导致人员的伤亡。
改正软件缺陷也许花费很小，也可能需要花费上百万。
在这些事件中，显然软件未按预期目标运行。
软件缺陷的官方定义：
只有至少满足以下5个规则之一才称发生了一个软件缺陷。
1）软件未实现需求规格说明书要求的功能。
（预期:
加法功能;实际:
没有实现加法功能）
2）软件出现了需求规格说明书指明不应该出现的错误。
（需求:
永不崩溃；实际：
死机）
3）软件实现了需求规格说明书未提到的功能。
（需求:
加减乘除;实际:
加减乘除、开平方根）
4）软件未实现需求规格说明书虽未明确提及但应该实现的目标。
（ECshop电子商城订单查询需求中未规定，要不要实现？
）
5）软件难以理解、不易使用、运行缓慢或者---从测试员的角度看---最终用户会认为不好。
小结：
软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
IEEE729-1983对缺陷有一个标准的定义:
Ø从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；
Ø从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
4.2.软件缺陷的属性（重要）
4.2.1.缺陷属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因、缺陷产生可能性。
序号
属性名称
说明
01
标识（Identifier）
标记某个缺陷的唯一符号，可以使用数字、字母组合来表示。
02
类型（Headline）
缺陷的分类定义
03
描述（Description）
对缺陷进行的详细的描述，以便缺陷重现
04
严重程度（Severity）
指因缺陷引起的故障对软件产品的影响程度
05
优先级（Priority）
缺陷必须被修复的紧急程度
06
状态（State）
缺陷通过一个跟踪修复过程的进展情况
表格2-2缺陷属性列表
4.2.2.缺陷类型
缺陷种类：
根据缺陷的自然属性来划分。
编号
缺陷类型
描述
子类型
编号
名称
01
功能问题
F-Function
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如指针循环，递归，功能等缺陷。
0101
功能错误
0102
功能缺失
0103
功能超越
0104
设计的二义性
0105
算法错误
02
接口问题
I-Interface
与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。
0201
模块间接口
0202
模块内接口
0203
公共数据使用
03
逻辑问题
L-Logic
需要进行逻辑分析，进行代码修改，如循环条件等。
0301
分支不正确
0302
重复的逻辑
0303
忽略极端条件
0304
不必要的功能
0305
误解
0306
循环不正确
0307
计算顺序错误
0308
逻辑顺序错误
04
计算问题
C-Computation
等式、符号、操作符或操作数错误，精度不够、不适当的数据验证等缺陷。
0401
等式错误
0402
缺少运算符
0403
错误的操作数
0404
括号用法不正确
0405
精度不够
0406
舍入错误
0407
符号错误
05
数据问题
A-Assignment
需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷。
0501
初始化错误
0502
存取错误
0503
引用错误变量
0504
数组应用越界
0505
数据单位不正确
0506
变量类型不正确
0507
数据范围不正确
0508
操作符错误
0509
数据覆盖
0510
输出数据错误
0511
输入数据错误
06
用户界面问题
U-Userinterface
人机交互特性：
屏幕格式，确认用户输入，功能布局，页面排版等方面的缺陷。
0601
界面风格不统一
0602
屏幕上的信息不可用
0603
屏幕上的错误信息
604
界面功能布局和操作不合常规
07
文档问题
D-Documentation
影响发布和维护，包括注释等缺陷。
0701
描述含糊不清
0702
项描述不完整
0703
项描述不正确
0704
项缺少或多余
0705
项不能验证
0706
项不能完成
0707
不符合标准
0708
与需求不一致
0709
文字排版错误
0710
文档信息错误
0711
注释缺陷
08
性能问题
P-Performance
不满足系统可测量的属性值，如：
执行时间，事务处理速率等缺陷。
0801
事务响应时间过长
0802
系统资源占用过多：
CPU,ARM
09
配置问题
B-Build、package、merge
由于配置库、变更管理或版本控制引起的错误。
0901
配置管理问题
0902
编译打包缺陷
0903
变更缺陷
10
标准问题
N-Norms
不符合各种标准的要求，如编码标准、设计符号等缺陷
1001
不符合编码标准
1002
不符合软件标准
1003
不符合行业标准
11
环境问题
E-Environments
由于设计、编译和运行环境引起的问题。
1101
设计、编译环境
1102
运行环境
12
兼容问题
软件之间不能正确的交互和共享信息。
1201
操作平台不兼容
1202
浏览器不兼容
1203
分辨率不兼容
13
其他问题
O-Others
以上问题所不包含的问题
表格2-3缺陷类型列表
4.2.3.缺陷严重程度
缺陷严重程度:
指因缺陷引起的故障对软件产品的影响程度。
严重级别
对应缺陷严重等级
描述
1-致命（Fatal）
致命缺陷
系统任何一个主要功能完全丧失，系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定，用户数据受到破坏，或者危机人身安全；
例：
1）严重花屏
2）内存泄漏
3）系统崩溃/死机
4）模块无法启动或异常退出
5）功能设计与需求严重不符
6）严重的数值计算错误
7）其他导致无法测试的错误：
如HTTP500错误
2-严重（Critical）
严重缺陷
系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响，不能执行正常工作功能或实现重要功能。
例：
1）功能未实现
2）功能错误
3）系统刷新错误
4）影响功能及界面的错别字或拼写错误
5）安全性问题。
3-重要（Major）
较大缺陷
产生错误的结果，导致系统不稳定，运行时好时坏，严重影响系统要求或基本功能实现的问题。
例：
1）操作界面错误（包括数据窗口内列名定义、含义是否一致）；
2）提示信息错误（包括未给出信息、信息提示错误等）；
3）长时间操作无进度提示；
4）兼容问题。
4-一般（Minor）
一般缺陷
系统的次要功能没有完全实现，但不影响用户的正常使用，不会影响系统稳定性的：
1）提示信息不太准确或用户界面差、操作时间长等一些问题；
2）功能的实现有问题，如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现；
5-较小
（Slight）
轻微缺陷
使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题，重点指系统的UI问题：
1）滚动条无效；
2）可编辑区域和不可编辑区域不明显；
3）光标跳转设置不好，鼠标（光标）定位错误；
4）上下翻页，首位页定位错误；
5）界面不一致，或界面不正确；
6）日期或时间初始值错误（起止日期、时间没有限定）；
7）出现错别字，标点符号错误，拼写错误，以及不正确的大小写等；
6-有待改进
（Enhancement）
其他缺陷
系统中值得改良的问题：
1）容易给用户错误和歧义的提示；
2）界面需要改进的，某个控件没有对齐等；
3）对有疑虑的部分，提出修改建议。
表格2-4缺陷严重程度
4.2.4.缺陷优先级
序号
缺陷优先级
描述
01
立即解决（ResolveImmediately）
缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；
02
高优先级（highpriority）
缺陷严重，影响测试，需要优先考虑；
03
正常排队（NormalQueue）
缺陷需要正常排队等待修复；
04
低优先级（Lowpriority）
缺陷可以在开发人员有时间的时候被纠正。
表格2-5缺陷优先级
4.2.5.缺陷状态
缺陷状态：
是指缺陷通过一个跟踪修复过程的进展情况。
序号
缺陷状态
描述
01
新建New
测试人员提交新的错误到库。
02
激活或打开
（ActiveorOpen）
问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理。
03
拒绝（Rejected）
拒绝“提交的缺陷”：
不需要修复（WontFix）或不是缺陷（Invalid）或缺陷已经被其他的软件测试人员发现（Duplicate）。
04
已修正或已修复
（FixdorResolved）
已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证。
05
关闭（Closed）
测试人员验证后，确认缺陷不存在之后的状态。
06
重新打开（Reopen）
测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复；
07
推迟（Deferred）
这个软件缺陷在下一个版本解决。
表格2-6缺陷状态
1
4.3.如何提交缺陷报告（重要）
4.3.1.一个简单的缺陷报告示例
4.3.2.报告软件缺陷的基本原则：
在软件/测试过程中,对于发现的大多数软件缺陷,要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。
1.尽快报告软件缺陷
软件缺陷发现的越早，在进度中留下的修复时间就越多。
2.有效的描述软件缺陷
短小：
只解释事实和演示、描述软件缺陷必须的细节
单一：
每一个报告只针对一个软件缺陷
明显并通用：
用阅读者容易看懂的，简单易行的步骤所描述的软件缺陷，得到修复的机会较大。
可再现：
要想得到重视，软件缺陷报告必须展示其可再现性--按照预定步骤可以使软件达到缺陷再次出现的相同状态。
3.在报告软件缺陷时不要做评价
测试员和程序员容易形成对立关系。
软件缺陷报告应该针对产品，而不是具体的人，只陈述事实。
避免幸灾乐祸，自负，责怪。
得体和委婉是关键。
需要善于沟通与合作。
4.对软件缺陷报告跟踪到底
比没有找到重要软件缺陷更糟糕得是，发现了一个重要的软件缺陷，作了报告，然后把
他忘掉了或者跟丢了。
对项目负责，有责任心是每个测试工程师必须有的。
4.3.3.缺陷定位文件的重要性
提交缺陷报告时，附带缺陷定位可以使开发人员更快的定位问题，一般的定位文件有：
Ø缺陷图片
Ø操作视频
Ø运行日志
ØLOG文件等
4.3.4.缺陷报告的基本元素
一个完整的缺陷报告通常由下列几部分组成:
4.3.5.缺陷报告基本元素解释
4.4.软件缺陷的生命周期（重要）
5.敏捷开发（了解）
5.1.什么是敏捷开发
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷最大的特色是迭代式开发。
5.2.敏捷开发的优势
敏捷开发确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版产品的模式。
敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。
2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。
3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。
能最大化单位成本收益。
5.3.敏捷开发的特点
1.人员交流重于过程与工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划
5.4.与瀑布模型对比
敏捷开发：
●客人到餐馆来点菜（新项目）
●客人不确定想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
●根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
●后厨开始准备（项目启动）
●配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
●客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
●上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
●又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
●到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
●客人吃完，很满意（基本满足了全部的要求）
瀑布模型开发：
●客人到餐馆来点菜（新项目）
●客人不确定想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
●根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
●后厨开始准备（项目启动）
●根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
●半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
●再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
●客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
●这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
●于是，后厨只给客户加了盐，加了辣
●客人吃完，不是很满意，下次不来了（没有满足需求）
5.5.敏捷开发小结
总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。
在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。
6.课程总结
6.1.重点
1.缺陷生命周期
2.质量模型
6.2.难点
1.缺陷生命周期
2.质量模型
7.课后练习
8.每日一练
1.一条缺陷记录包含哪些信息?
2.请描述一下缺陷管理的流程?
升级会员 