软件测试的基本理论知识_软件测试基础知识整理
01软件研发流程
1．软件产品
软件产品是指向用户提供的计算机软件、信息系统或设备中嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。
2．软件工程
软件工程，英文名SoftwareEngineering，是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
“软件工程是开发、运行、维护和修复软件的系统方法。”这个定义相当概括，它主要强调软件工程是系统方法而不是某种神秘的个人技巧。
3．软件开发过程
软件产品从最初构思到公开发行的过程，称为软件开发过程。
开发过程有各种不同的方法，没有所谓最好的模式。
最常见的4种：
瀑布模式
螺旋模式
快速原型
4．软件生命周期
5．软件研发流程
6．软件测试流程
需求分析
测试计划
测试方案
测试用例
测试执行
测试报告
7．软件项目成员
- 项目经理
驱动整个项目的运转，负责制定计划，安排人力，管理进度，协调团队，进行重大决策。
- 架构师 / 系统工程师
技术专家，经验丰富，负责整个系统的体系架构的设计以及关键模块的设计。
- 程序员 / 开发人员
设计、编写软件，并修复软件中的缺陷。
- 测试工程师
负责找出软件产品存在的问题并报告。
- 资料工程师
负责编写软件产品附带的文件和联机帮助文档
- 配置管理员
负责管理程序员写的代码和资料工程师写的文档资料，并组合成一个软件包
- QA
质量监管人员
02软件测试基础
1．软件测试概念以及目的（掌握）
测试的目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试。
2．软件测试质量（了解）
软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”
明确的需求指：软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准；隐含的需求指：所有专业开发的软件都应具有的隐含特征的程度。
3．软件测试原则（掌握）
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，因此我们提出了这样的一组测试原则,如下所示。
1) 所有的软件测试都应追溯到用户需求。
2) 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
3) 完全测试是不可能的，测试需要终止。
4) 测试无法显示软件潜在的缺陷。
5) 充分注意测试中的群集现象。
6) 程序员应避免检查自己的程序。
7) 尽量避免测试的随意性
4．软件测试对象（掌握）
1) 根据软件的定义，软件包括程序、数据、文档，所以软件测试并不仅仅是程序测试。软件测试贯穿于整个软件生命周期中。
2) 由于在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应作为“软件测试”的对象。
5．软件测试分类（掌握）
1) 按照开发阶段划分软件测试：单元测试、集成测试、系统测试、验收测试
2) 按照测试实施组织划分软件测试：开发方测试、用户测试(Beta测试)、第三方测试
3) 按照测试技术划分：白盒测试、黑盒测试、灰盒测试。
软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。
6．软件测试风险（掌握）
软件测试中的软件风险分析是根据预测软件将出现的风险，制定软件测试计划并排列优先等级，风险分析是对软件中潜在的问题进行识别、估计和评价的过程。
风险也包括进度风险、质量风险、人员风险、变更风险、成本风险等
7．软件测试工程师（了解）
具备的技能：
1) 计算机相关知识，能够熟练使用常用的管理工具
2) 开发语言：C,Java,JavaScript,VBScript,Shell。
3) 数据库：SQLServer, Oracle,MySQL等数据库知识
4) 操作系统,如Windows 2003以及2008,UNIX,Linux,MAC,Solaris等
5) 网络基本知识，能够独立完成测试环境的搭建。
6) 软件基础知识：软件工程,软件生命周期,测试理论和测试方式有较深的理解。
7) 软件测试技术,方法,流程,测试文档编写,能独立设计和执行测试用例,提交完整的缺陷报告单, 编写测试报告。
8) 测试工具，能够熟练使用至少一种功能/性能自动化测试工具。
9) 质量管理知识，如CMM,CMMI以及ISO 9001等。
职责：
1) 配置测试环境
2) 执行软件测试
3) 报告软件缺陷
4) 更新缺陷报告内容
5) 验证修正的缺陷
6) 报告测试状态
7) 完成测试相关的其它任务
03软件测试类型
1. 软件测试分类
按阶段划分
1) 单元测试：是指对软件中的最小可测试单元进行检查和验证。
2) 集成测试：在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。
3) 系统测试：将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试.
4) 验收测试（а、ß测试）：
a.它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制
b.主要确认软件是否按合同要求进行工作，既是否满足软件需求规格说明书中的要求。
按是否运行程序划分
1) 静态测试：不运行被测试的软件，而只是静态的检查代码、界面或者文档
2) 动态测试：实际运行被测试的软件，输入相应的测试数据，检查世界的输出结果是否和预期结果相一致的过程。
按是否查看代码划分
黑盒测试：把软件看成一个黑盒子，不管内部逻辑和内部特性，只依据规格说明书检查程序的功能是否符合功能说明
白盒测试：又称为结构测试。着重于程序内部结构和算法，不关心功能和性能指标。
灰盒测试：介于白盒和黑盒测试之间，基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
其他划分
回归测试：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例。防止出现“以前应用没有的问题现在出问题了”。
冒烟测试（BVT测试（BuildVerification Test ））：冒烟测试的对象是每一个新编译需要正式测试的版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
随机测试（又名猴子测试）：测试数据是随机产生的，在测试用例之外。只能作为一个测试的补充。
敏捷测试（敏捷开发引发）：敏捷测试(Agiletesting)是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
TDD（测试驱动开发）
测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。
04质量
1．什么是质量
对于不同类型的产品，评价质量好坏的关注点不同
2．软件质量有何价值？
软件质量的价值，取决于其应用情景的重要程度，以及该应用情景对于该软件产品的依赖程度。
3．软件质量模型
内部质量：它是从内部观点出发的软件产品特性的总体。内部质量是针对内部质量需求被测量和评价的质量。
外部质量：外部质量是从外部观点出发的软件产品特性的总体。它是当软件执行时，更典型地是使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量。
使用质量：是从用户观点出发，来看待软件产品用于特定环境和条件下的质量。它测量用户在特定环境中达到其任务目标的程度，而不是测量软件自身的性质。
4．什么是质量保证
为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。
5. QC与QA的区别
QC和QA的主要区别：前者是保证产品质量符合规定,后者是建立体系并确保体系按要求运作,以提供内外部的信任
QC就是测试人员，职责是尽可能早地发现软件的缺陷，并确保缺陷得到修复（有些企业里，测试人员被称为SQA）
QA是流程的监督者，职责是创建和执行 改进软件开发过程，并防止软件缺陷发生 的标准和方法
6. ISO9000与CMMI的介绍
ISO：国际标准化组织
ISO9000：国家质量管理体系标准
7. CMMI是什么？
Capability Maturity Model Integration (能力成熟度模型综合)
该模型提供一套可供公众使用的准则；这些准则描述那些成功地实施了过程改进的组织的特性。
该模型用“软件能力成熟度”来衡量这种软件综合能力
面试：杯子怎么测？1
功能测试(Functiontest)
能否装水，
除了装水， 能否装其他液体。比如可乐，酒精
能装多少ML的水
杯子是否有刻度表
杯子能否泡茶，跑咖啡
杯子是否能放冰箱，做冰块
杯子的材质是什么（玻璃，塑料,黄金做的）
界面测试(UI Test)
外观好不好看。
什么颜色
杯子的形状是怎么样的。
杯子的重量是多少
杯子是否有异味
杯子的图案是否合理
性能测试(performancetest)
能否装100度的开水 (泡茶)
能否装0度冰水
装满水，放几天后，是否会漏水
杯子内壁上的涂料是否容易脱落。
杯子上的颜色是否容易褪色或者脱落
被我坦克压下，是否会碎 (这条是开玩笑的哈)
安全性测试(Securitytest)
制作杯子的材料，是否有毒
放微波炉里转的时候，是否会爆炸, 或者杯子是否会熔化。
从桌子上掉到水泥地上是否会摔碎。
杯子是否容易长细菌
杯子是否有缺口，会划坏嘴巴
杯子内壁上的材料，是否会溶解到水中
杯子破碎后，是否会对使用者造成伤害
可用性测试(UsabilityTest)
杯子是否容易烫手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施
面试：杯子怎么测？2
需求测试: 查看杯子使用说明书
界面测试: 查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24 小时检查泄漏时间和情况；盛上汽油（案例二）放24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试: 杯子加包装( 有填充物), 在多高的情况摔下不破损
震动测试: 杯子加包装( 有填充物), 六面震动, 检查产品是否能应对恶劣的铁路\ 公路\ 航空运输
测试数据：测试数据具体编写此处略。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：该期望输出需查阅国标、行标以及使用用户的需求
05测试需求分析
1．测试需求
什么是测试需求
测试需求主要解决“测什么”的问题 ，即指明被测对象中什么需要测试。
测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
测试需求的特征
制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；
测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件；
测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容；
为什么要测试需求
软件测试需求是开发测试用例的依据；
有助于保证测试的质量与进度；
测试需求是衡量测试覆盖率的重要指标；
2．测试需求分析过程
需求采集
需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求；
测试需求分析
测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求；
3．测试需求评审
完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。
06 测试计划
1．测试计划的定义
测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。
2．测试计划的作用
1）测试过程提供指导
测试目标
测试内容
测试方法
测试时间周期
2）改善测试任务与测试过程的关系
3）提高测试的组织、规划和管理能力
3．如何制定测试计划
- 认真做好测试资料的搜集整理工作；
- 明确测试的目标，增强测试计划的实用性；
- 坚持“5W”规则，明确内容与过程；
- 采用评审和更新机制，保证测试计划满足实际需求
4．测试计划的内容
1) 测试项目简介
2) 需要测试的特征
3) 不需要测试的特征
4) 测试的方法（测试人员、测试工具、测试流程）
5) 测试环境（软件、硬件、网络）
6) 测试环境是测试人员为进行软件测试而搭建的环境
7) 测试开始条件和结束条件
8) 测试者的任务、培训
9) 测试进度与跟踪
10) 测试风险与解决
11) 测试计划的审批与变更方式
5．测试风险与解决
07测试方案
1． 测试方案的目的
在方向上明确要测什么、怎么测，以及达到什么样质量标准。
2． 测试计划与方案的区别
3． 如何制定有效测试方案
1) 测试需求分析
2) 测试策略
3) 测试资源
4) 测试进度计划
5) 风险管理
6) 质量
4． 测试策略
制定测试策略：测试资源、测试进度计划、风险管理、质量
测试类型：
1) 功能测试
2) 界面测试
3) 安全测试
4) 本地/国际化测试
5) 数据库测试
6) 可靠性测试
7) 集成测试
8) 兼容性测试
9) 自动化测试
10) 性能测试
11) 回归测试
08 黑盒用例设计方法
1. 黑盒测试的概念
黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
2. 黑盒测试主要测试的错误类型有
①不正确或遗漏的功能；
②接口、界面错误；
③性能错误；
④数据结构或外部数据访问错误；
⑤初始化或终止条件错误等等。
3. 黑盒测试的实施过程
测试计划阶段
测试设计阶段
测试执行阶段
测试总结阶段
4. 黑盒用例设计技术（重点）
1）等价类划分方法（重点）
2）边界值分析方法（重点）
3）场景法 （重点）流程分析法，是业务流程
基本流（正常流）
备选流（异常流）
4）错误推测方法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
5）因果图方法
考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.
6）判定表驱动分析方法
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
7）规则及规则合并
规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系
8）正交试验设计方法
它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，是一种高效率、快速、经济的实验设计方法。
5. 等价类划分方法
可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.
有效等价类
满足输入条件
无效等价类
不满足输入条件
超范围数值
空值
特殊字符
空格 （trim 去除空格）
6. 边界值分析方法：是对等价类划分方法的补充
7. 测试方法选择的综合策略
1) 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效方法。
2) 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
3) 用错误推测法再追加一些测试用例。
4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5) 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度
09 测试用例设计
1. 测试用例的主要构成要素
测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作
2. 设计测试用例的原则
用语简洁清晰，但不能过于简单
用语无歧义，尽量少用过长的句子
用例的各个基本要素要齐备，不能缺失
用例的步骤应该足够详细，操作应该明确
容易被其它测试工程师读懂，并能顺利执行
3. 用例的粒度
1) 粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理
2) 用例的粒度大，则总的用例数就少，用例看起来也简洁
3) 用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计
4. 执行结果
1) 当用例还尚未被执行时，是New未执行状态
2) 当执行结果与预期结果相符时，是Pass通过状态
3) 当执行结果与预期结果不符时，是Fail失败状态
4) 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
5) 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。
5. 编写元素
用例编号、用例标题、用例级别、前提条件、操作步骤、预期结果、编写人、备注
11 测试执行
1.测试执行
1）什么是执行测试用例
根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。
2）测试执行过程注意事项
ü 搭建测试环境事项
ü 注意前提条件和特殊说明
ü 测试用例要全部执行
ü 不要忽视任何偶然现象
ü 加强测试过程记录
ü 详细预期与实际的不一致
ü 提交缺陷时与开发的关系处理
ü 提交一份优秀的问题报告单
ü 及时更新测试用例
2. 软件缺陷
缺陷又名为BUG（臭虫）
并非所有的缺陷都需要修复
a) 没有足够的时间
b) 不算真正的软件缺陷
c) 修复的风险太大
d) 不值得修复
3. 缺陷的流程
4. 缺陷生命周期—状态
5. 缺陷的等级
6. 测试报告
测试报告的主要内容
数据统计
遗留bug情况
测试风险
测试对象评估
测试结论
测试总结：回顾整个项目的测试过程，总结个人成长经验，取得了什么成绩、有哪些不足、有什么好的经验或者方法可以和大家分享呢？对工作进行一个理性的分析和思考。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/209991.html原文链接：https://javaforall.cn