2023年软件测试技术经典教程笔记修汇总.docx

第一章 基础知识
1.1、软件
1)、软件=程序+文档
2)、分类
功能：系统+应用
架构：单机+C/S+B/S
用户：产品+项目
规模：小型+中型+大型
1.2、Bug
1)、类型一(广义上，软件生命周期，与用户需求不符的问题)：
完全没有实现的功能
基本实现功能，但有功能上或性能上的问题
实现了用户不需要的功能
2)、类型二(测试执行阶段的问题)
Defect---------Requirements&Design
Error-----------Development
Bug------------Testing
Failure---------Post production
1.3、测试
1)、概念：
测试是为了检查实际的软件是否符合用户需求，所以不能为了发现错误而发现错误。使用人工或自动手段，来运营或测试某个系统的过程。
2)、测试环境：硬件+软件+网络
规定：真实(项目、产品)+干净+无毒+独立(测试与开发)
1.4、测试用例
测试用例=输入+输出+测试环境
便于团队交流，便于反复测试，便于跟踪记录，比纳与用户自测
开发生命周期
需求分析 → 概要设计 → 具体设计 → 编码 → 维护
测试生命周期
测试计划 → 测试设计 → 测试执行 → 测试评估
需求分析和测试计划完毕后，根据《系统需求规格说明书》和软件原型(DEMO)写测试用例
1.5 其他
1)、测试人员素质规定：细心、耐心、信心、服务意识、团队合作意识、沟通能力
2)、如何成为优秀的测试工程师：1、不断学习充电 2、阅读原版书籍 3、阅读缺陷管理系统中的缺陷报告 4、阅读高手写的测试用例 5、学习产品相关的业务知识
1.6 软件测试的基本规则
1) Zero Bug 与 Good Enough
Good Enough原则：不充足测试是不负责任，过度的测试是一种资源浪费。
参考：*遗留bug不超过10个，严重的不超过5个
*测试用例执行率为100%，通过率为95%
*单元测试，关键模块语句覆盖率达成100%，分支覆盖率达成85%
2) 不要视图穷举法
3) 开发人员不能既是运动员又是裁判员
4) 软件测试要尽早执行
5) 软件测试应当追溯需求

原始需求
需求分析
对的的规格说明
错误的规格说明
设计
对的的设计
错误的设计
对错误说明的设计
编码
对的编码
错误的编码
对错误设计编码
对错误说明设计的编码
测试
对的功能
可改正的错误
不可改正的错误
潜伏的错误
不完善的软件产品
6) 缺陷的二八定理
一般情况下，软件80%的缺陷集中在20%的模块中。
7) 缺陷具有免疫性
缺陷具有免疫性，需要根据新版本修改维护测试用例，此外，有一个值得注意的经验：没修复3-4个bug，也许会产生一个新bug。
第二章 测试分类
2.1、是否运营程序
Static Testing------------代码规范、界面、文档
Dynamic Testing--------运营程序
2.2、根据阶段分类
Unit Testing(单元测试)----------10%
最小模块，依据源程序和《具体设计》
白盒测试人员||开发人员
编译代码→静态测试→动态测试
桩模块(Stub)、驱动模块(Driver)
Integration Testing(集成测试)----------20%
模块间的接口，依据单元测试的模块和《概要设计》
白盒测试人员||开发人员
一般单元和集成同步进行
System Testing(系统测试)----------40%
整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》
黑盒测试工程师
Acceptance Testing(验收测试)----------20%
整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》和验收标准
用户，可配合黑盒测试工程师
α测试：内侧
β测试：公测
2.3、是否查看代码
1)、White-Box Testing-----源代码的测试
2)、Black-Box Testing-----功能测试、性能测试
Function Testing(功能测试)
Logic Function Testing(逻辑功能测试)
UI Testing(界面测试)：窗口、下拉式菜单和鼠标操作
Usability Tseting(易用性测试)
Installation Testing(安装测试)
Compatibility Testing(兼容性测试)
其他：恢复测试、裸机测试、确认测试、接口测试、数据库测试、安全测试、配置测试
Performance Testing(性能测试)
时间性能：重要指一个事务的具体响应时间(Respind Time)。
空间性能：重要指软件运营时所消耗的系统资源(CPU、内存、硬盘)。
分类：一般性能测试、稳定性测试、负载测试、压力测试
a、一般性能测试：让被测系统在正常的软硬件环境下运营，不向其施加任何压力
b、稳定性测试(也叫Reliability Testing 可靠性测试)：指连续运营被测系统，检查系统运营时的稳定限度。通常用MTBF(Mean Time Between Failure)
c、负载测试(Load Testing)：让被测系统在其能忍受的压力极限范围内连续运营，检测系统的稳定性。
d、压力测试(Stress Testing)：连续不断的给被测系统增长压力，知道被测系统压垮为止，用来测试系统能承受最大压力。
2.4、回归测试、冒烟测试、随机测试
Regression Testing(回归测试)：软件新版本测试时，重新执行上一个版本测试用例。可以在任何阶段进行（单元测试、集成测试、系统测试、验收测试等），既有黑盒测试的回归，也有白盒测试的回归。
Smoke Testing(冒烟测试)：对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具有可测性。
Random Testing(随机测试)：指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边沿性的错误。
第三章 测试技术
黑盒测试技术
3.1、等价类技术(Equivalence Class Testing)
等价类：某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
有效等价类：符合《需求规则说明书》，合理地输入数据集合
无效等价类：不符合《需求规则说明书》，无意义的输入数据集合
等价类划分环节：
1)先考虑输入数据的类型(合法和非法)
2)再考虑数据范围
3)画出示意图，区分等价类
4)为每个等价类编号
5)从等价类中选择测试数据构造用例
3.2、边界值技术(Boundary Value Testing)
3.3、因果图法(Cause-Effect Graphs)
因果图法环节
1)找出所有的输入条件和输出，并编号
2)分析输入条件之间的关系，是互斥还是可以同时满足
3)画出输入条件的排列组合情况
4)编写测试用例
因果图试用于输入条件过多
3.4、流程图法(Workflow Method)
流程图法环节
1)具体了解需求
2)根据需求说明或界面原型，找出业务流程的各个页面及各页面之间的流转关系
3)画出业务流图
4)写用例，覆盖所有途径分支
流程图法是针对整个系统，而非某个页面或模块
尚有其他如：鉴定表、错误推测、场景法等，例：ATM机取钱-场景法(不全)
场景
密码
帐号
输入金额
账面金额
ATM钞票
预想结果
场景1：成功提款
1
1
1
1
1
提款
场景2：ATM内无钞票
1
1
1
1
0
不可提款
场景3：ATM内钞票局限性
1
1
1
1
0
提醒，返回开始
场景4：密码错误，可再次输入
0
1
null
1
1
警告，返回开始
场景5：密码错误，不可再次输入
0
1
null
1
1
警告，卡预保存
白盒测试技术
3.5 白盒测试检查点
*对程序模块的所有独立的执行途径至少测试一次
*对所有的逻辑鉴定，取’真’与’假’都至少测试一次
*在循环的边界和运营界线内执行循环体
*测试内部数据结构的有效性等
环节：1)根据分析画出流程图
2)计算圈复杂度 = 鉴定节点数 + 1
3)写出独立途径
4)根据独立途径设计测试用例
第四章 缺陷管理
4.1、Bug的分类
1)严重限度(Severity)：系统崩溃、严重、一般、次要、建议
2)优先级(Priority)：高(High)、中(Middle)、低(Low)
严重限度高，优先级不一定高，严重限度低，优先级不一定低
3)按测试种类：逻辑功能类(Fcuntion)、性能类(Performance)、界面类(UI)、易用性类(Usability)、兼容性类(Compatibility)
4)按功能模块
5)按生命周期：新建(New)、确认(Confirmed)、解决(Fixed)、关闭(Closed)、重新打开(Reopen)
4.2 缺陷报告
注意点：
1)保证重现Bug
2)用最少且必要环节描述Bug
3)简洁、准确、完整
4)一个Bug一个报告
4.3 缺陷管理工具
TrackRecord、Clearquest、Bugzilla(免费)、Mantis(免费)、JIRA(免费)
Bugzilla：Terry Weissman研制，perl编写，后台数据库是MySQL，最初是用来在Netscape内部跟踪Bug的，可以在多种平台运营
第五章 常用测试工具
分类：黑盒测试工具、白盒测试工具、测试管理工具
MI公司产品：
1、LoadRunner：性能测试工具
2、WinRunner：功能测试工具(QTP：MI的QTP代替占有市场)
3、TestDirector：测试管理工具(QC：HP收购MI公司后退出的一款TD升级产品)
性能学习LoadRunner，功能学些QTP，管理学习TD
IBM Rational公司的产品：
Rational Testmanager(测试管理工具)
Rational ClearQuest(缺陷管理工具)
Rational Robot(功能/性能工具)
Rational Purify(白盒测试工具)
Compuware公司产品
QACenter(测试管理)
TrackRecord(缺陷管理)
QARun(功能)
QAload(性能)
DevPartner(白盒测试)
Telelogic公司产品
Telelogic Doors(需求管理)、Logiscope(白盒测试工具)
其他公司产品
微软-WAS(性能测试)
Radview公司-WebLoad(性能测试)，TestView Manager(测试管理)
Parasoft公司-JTest(白盒测试)，C++ Test(白盒测试)
此外，很多缺陷管理工具是开源的，如：Bugzilla、Mantis、Jira
第六章 测试管理
6.1、测试与质量
软件质量：软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准，以及所
有专业开发的软件都应具有的隐含特性的限度(需求一致、符合准则、隐含特性)
SQA(Software Quality Assurance)：软件质量保证，为保证软件开发过程和结果符合预期
规定而建立的一系列规程，以及一照规程和计划采用的一系列活动及其结果评价。
SQA需要做的工作：
*建立软件质量保证活动的实体
*制定软件质量保证计划
*坚持各阶段的评审、审计、跟踪
*监控软件产品的质量
*采集软件质量保证活动的数据
*度量软件质量保证活动
SQA需要达成目的：
*通过监控软件开发过程来保证产品质量
*保证开发出来的软件和软件开发过程符合相应标准与规程(ISO90000 或 CMM)
*保证软件产品、软件过程中存在的不符合问题得到解决，必要时将问题反映给高级
管理者
*保证项目组指定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。
SQA工作人员：QA，QC工作人员：重要是TESTER
QA与QC：QA-防止问题(Prevention)，贯穿于整个软件生命周期中，防止错误的成因，重点是对软件开发过程进行监督、管 理、控制
QC-发现问题(Detection)，重要是测试人员，关注于最后的产品的质量活动，重点是对开发出的产品进行检查
6.2、常用模型
CMM：能力成熟度模型
1)初始级(Initial)：软件过程的特性是无序的，有时甚至是混乱的。 几乎没有过程定义，成功完全取决于个人的能力。
2)可反复级(Repeatable)：建立了基本的项目管理过程，可以追踪费用、进度和功能。有适当的必要的过程规范，使得可以重现以前类似项目的成功。
3)已定义级(Defined)：用于管理和工程活动的软件过程己经文档化、标准化，并与整个组织的软件过程相集成。所有项目都使用文档化的、 组织认可的过程来开发和维护软件。
4)已管理级(Managed)：软件过程和产品质量的具体度量数据被收集，通过这些度量数据，软件过程和产品可以被定暈地理解和控制。
5)优化级(Optimizing)：通过定量的反馈，进行不断的过程改善，这些反馈来自于过程或通过测试新的想法和技术而得到。
CMM ISO
•质量模型 质量标准
•评估 审查
•给你改善建议 结果有通过和不通过

KPA(Key Process Area)：除第一级外，CMM的每一级是按完全相同的结构组成的。每一级包含了实现这一级目的的若干关键过程域，指出了公司需要集中力量改善的软件过程。 CMM2:可反复阶段
　　需求管理：requrement management
　　软件项目计划：software project planning
　　软件项目跟踪和监督：software project tracking oversight
　　软件子协议管理：software subcontract management
　　软件质量保证：software quality assurance
　　软件配置管理：software configuratione management
CMM3:已定义阶段
　　组织过程焦点：organization process focus
　　组织过程定义：organization process definition
　　培训大纲：training program
　　集成软件管理：intergrated software management
　　软件产品工程：software product engineering
　　组间协调：intergroup coordination
　　同行评审：peer review
CMM4:已管理阶段
　　定量管理过程：quantitative process management
　　软件质量管理：software quality management
CMM5:优化阶段
　　缺陷防止：defect prevention
　　技术改革管理：technology change management
过程更改管理：process change management
成熟度
初始级 可反复级 已定义级 已管理级 优化级
风险

常见的质量模型：
*ISO90000族标准：国际标准(ISO/TC176)，适合所有行业，其中9000-3针对软件开发
*CMM标准：行业标准(卡耐基-梅隆大学)，针对软件开发行业，分5等级，推出CMMI
*TICKIT标准：行业标准(英国软件行业协会)，针对软件开发行业，不太流行
*ISO15504标准：国际标准(试图结合1、2与软件工程概念)，合用所有行业，有待实践
其他模型：
TMM：软件测试成熟度模型
*初始级
*阶段定义级
*集成级
*管理和度量级
*优化、防止缺陷和质量控制级
McCall模型：【产品运营】对的性、健壮性、效率、完整性、可用性、风险
【产品修改】可理解性、可维护性、灵活性、可测试性
【产品转移】可移植性、可再用性、互运营性
6.3、软件的生命周期
软件：可行性研究、需求分析→设计、编码、测试→软件发布维护→淘汰
软件开发：需求分析→概要设计→具体设计→编码→维护
软件测试：测试计划→测试设计 测试执行→测试评估
软件生命周期模型：
1、Waterfall Model(瀑布模型)：计划-需求-设计-编码-测试-维护
开发的各个阶段比较清楚 依赖早起需求调查，不适应需求变化
强调初期计划及需求调查 单一流程，不可逆
适合需求稳定的产品开发 风险往往迟至后期才发现，失去及早纠正机会
2、Spiral Model(螺旋模型)：反复执行多个’瀑布模型’
适合需求经常变化的软件项目，但开发过程复杂，控制不好，容易混乱
3、V模型
用户需求 验收测试

规格定义 系统测试

概要设计 集成测试

具体设计 单元测试

编码
具体表达了测试的各个阶段及参考依据，但没有说明在项目前期测试需要做哪些工作，且流程也是单项，不可逆
4、W模型
需求分析 需求测试 系统安装 验收测试

概要设计 概要设计 系统构建 系统测试
测试

具体设计 具体设计 模块集成 集成测试
测试

编码实现 单元测试
强调测试随着整个软件开发生命周期，对象也不仅是程序，有助于尽早发现问题，但是需求设计编码等活动也被视为串行，测试和开发也保持一种线性的前后关系。
W模型、H模型、X模型
通常可以在W模型的框架下，运用H模型的思想进行独立的测试，当有变更发生时，按X模型和前置模型的思想进行解决。(百度另几种模型)
6.4 软件测试计划
撰写测试计划时，应注意一下四点：
*增强测试计划实用性注意体现项目的测试特点
*坚持”5W1H”规则，明确内容与过程
5W1H：”WHAT”,”WHY”,”WHEN”,”WHERE”,”WHO”,”HOW”
what：明确测试范围和内容
why：测试目的
when：拟定测试开始和结束日期
where：给出测试文档和软件的存放位置
who：测试人员的分派
how：指出测试的方法和工具
*采用评审和更新机制，保证测试计划满足实际需求
*分别创建测试计划与测试策略
其他
RUP： rational unified process 统一软件开发过程
它定义了在整个软件开发过程中：在什么时候，应当有谁，进行什么样的开发活动，产生什么样的结果，来保证准时提交筒质量的产品。
RUP总体结构
每个角色完毕指定的活动
每个活动产出合格的产品
每个产品拥有相关的指南，模板等
RUP重要特点
迭代化软件开发
以架构为核心的软件开发
用例驱动的软件开发
风险驱动的软件开发
最佳经验
迭代化开发
需求管理
基于构件的软件架构
可视化建模
连续的质量验证
配置管理
RUP适合任何项目
RUP在实行之前必须进行裁剪
RUP是个丰富的知识库，需要你不断的去查阅，选择
实践RUP是个连续的过程
国际化与本地化
Globalization testing
注意的是它与翻译是没什么太大关系的。
国际化测试关注产品是否达成了不同的时区、时间日期、货币格式和不同的文化习 惯等，当然尚有政治规定方面的规定。
Localization testing
对一个软件进行本地化测试就需要关注文本显示的空间，由于不同语言的 长度不同样，所以在设计界面的时候就要小心了！
验证软件被翻译完毕后，是否有什么错误，是否可以正常工作。