标签：测试 迭代 等价 基础知识 测试用例 模块 软件

一、入门级

1、为什么测试

① 软件已经或不可缺

② 缺陷不可避免

③ 软件不正确执行会导致很多问题

2、测试基本里面和关键要素

2.1 认知误区

① 测试时测试人员的事

② 测试时耗时，昂贵的

③ 开发完成后才开始测试

④ 可以穷尽所有可能的测试

⑤ 内部测试可以发现所有问题

⑥ 测试只是为里发现缺陷

2.2 基本理念

① 基于风险的测试

② 尽早测试

③ 持续测试

④ 分层测试

⑤ 可信测试

⑥ 代表客户测试

2.3关键要素

① 端到端测试与验证流程

② 测试技术与工程方法

③ 测试工具与自动化

④ 测试组织与人员能力

3、软件测试的定义

3.1 定义

描述一种用来促进鉴定软件的正确性，完整性，安全性和质量的过程

3.2 公司观点

① 测试是一个好汉计划，准备和测量活动的过程。

② 目的是确认被测系统的特征，并指出需求和实现之间的差异

3.3 证实与证伪

① 证实

1>正向思维：为程序能够按照预期摄像那样运行而建立足够的信心

2>优点：以需求和设计为本，有利于界定测试工作的范畴和测试计划安排，针对性强，有利于质量评估工作

3>不足：观念以证实为主的情况下，不容易找到软件的错误，也容易忽略一些错误

② 证伪

1>逆向思维：测试是为了证明程序有错，而不是证明程序无错误

2>优点：容易找到较多的错误

3>不足：与需求和设计没有必然的关联，测试活动容易丢失重点，可能发现较多对客户使用没有影响或影响较小的bug

③ 一些观点

1>测试≠调试

2>证实不利于测试发现问题

3>证伪易让测试忽视对需求实现关注

4>单纯强调风险容易忽略质量底线

4、软件缺陷

4.1 定义

① 内部：是软件产品开发或维护过程中所存在的错误、毛病等各种问题

② 外部：是系统所需要实现的某种功能的失效或违背

4.2 主要类型/现象

① 功能、特性没有实现或部分实现

② 设计不合理，存在缺陷

③ 实际结果和预期结果不一致

④ 运行出错，包括运行中断、系统崩溃、界面混乱

⑤ 数据结果不正确、度量不够等

⑥ 用户不能接受的其他问题，如存取时间过长，界面不美观

5、软件测试的目的

5.1 目的

① 发现缺陷

② 质量评估

③ 预防缺陷

5.2 不同阶段的测试目标

① 单元测试、集成测试和系统测试：主要是尽可能的发现失效，从而识别和修正尽可能多的缺陷

② 验收测试：目标是确认系统是否按照预期工作，是建立满足里需求的信心

③ 回归测试：为了验证在开发过程中的软件变更是否引入新的缺陷

6、软件测试的原则（ISTQB）

6.1 测试可以显示缺陷（defect）的存在

① 显示缺陷存在，不能证明不存在缺陷

② 可以减少软件中存在缺陷的可能

6.2 穷尽测试是不可能的：应使用风险分析和优先级来聚焦测试投入

6.3 测试尽早介入：关注点应放在已经定义的测试目标（test objective）上

6.4 缺陷具有集群性：二八法则

6.5 杀虫剂悖论

① 测试用例要经常性的评审修改稿

② 不断增加新的不同角度的测试用例

6.6 测试活动依赖于测试内容，测试内容决定测试活动

6.7 “Absence-of-errors”谬论，系统发布取决于是否满足客户需求，而不是是否还有缺陷

7、软件测试的对象

① 软件测试≠程序测试

② 需求分析、概要设计、详细设计以及编码各阶段所得到的的交付件，包括设计文档，源代码，应用程序，随版本发布的资料，都是测试对象

8、软件质量属性

8.1 反应实体满足明确的和隐含的需求的能力的特征总和

8.2 软件质量是产品、组织和体系或过程的一组固有特性，反应他们满足顾客和其他相关方面要求的程度

8.3 人们通常把影响软件质量的特性称为软件质量属性

8.4 常见的质量属性模型

① ISO 25010质量模型

1>功能性:功能完整性、正确性、适宜性

2>性能效率:时间行为、资源利用率、容量

3>兼容性:共存性、互操作性

4>可用性:适宜性的可识别能力、可学习、可操作性、防呆、界面、可访问性

5>可靠性:成熟度、可用性、容错、可恢复性

6>安全性:保密、完整性、不可否认性、可问责、真实性

7>可维护性:模块化、可重用性、可分析性、可修改性、可测性

8>可移植性:适应性、可安装性、可替换性

② McCall质量模型

③ NIST模型

8.5 包含的主要特性

① 安全性（Security）

② 可靠性（Reliability）

③ 性能及效率（Efficiency）

④ 可用性（Usability）

⑤ 可维护性（Maintainability）

⑥ 兼容性（Compatibility）

9、软件测试分类

9.1 是否运行程序

① 静态测试

1>评审：需求文档、规格说明书、源代码、测试用例、产品资料

2>静态分析：软件源代码、软件模型

② 动态测试

1>黑盒测试：根据功能和接口设计测试用例

2>白盒测试：根据内部实现和结构设计测试用例

③ 关系

9.2 按测试阶段分

①单元测试

1>定义：对软件测试中的最小可测试单元进行检查和验证

2>对象：软件基本组成单元，可以使函数、模块、类或组件

3>目标：单元模块内的逻辑结构和功能是否正确，发现程序设计或实现的逻辑错误

4>策略：开发人员对自己交付模块进行测试，尽早测试，降低缺陷修复代价

5>分类

1.驱动模块：接受测试数据

2.桩模块：被调用的模块，是被测对象得以运行

② 集成测试

1>定义：把若干个经过单元测试的组件/模块/单元组装到一起的测试

2>对象：测试模块之间的接口，如操作系统、文件系统、硬件或系统之间的接口

3>目标：通过对模块功能、接口设计进行分析，覆盖所有的功能项目，重点的接口、边界进行重点测试，确保被集成部分之间的接口正确无误

4>策略：根据系统结构、功能任务集、事务处理顺序来制定。减少在生命周期后期才发现缺陷而产生的风险，集成程度应该逐步增加

5>分类

1.非增量式集成：又称一次性集成，对完成的单元测试的所有模块在一起进行测试

2.增量式集成

自顶向下集成：使用桩模块模拟底层模块的接口，模块按照层级的降序进行叠加

自底向上集成：从最底层模块开始，使用缺东模块或测试工具模拟高层接口模块，按照层级的升序进行叠加

③ 系统测试

1>定义：将已经确认的软件、硬件、外设、网络等元素结合在一起，进行各种组装测试和确认测试

2>对象：完成的软件系统/产品，测试环境应该尽量和最终的目标或生产环境一致

3>目标：验证整个系统是否满足预定的功能和非功能需求，找出与需求规格不符或矛盾的地方

4>策略：基于不同方面的测试，如基于风险评估、需求规格说明，业务过程等。系统测试通常由独立测试团队进行。

5>分类

1.功能性测试

2.非功能性测试：可靠性、效率性、客服务性

6>一般不考虑程序实现的内部逻辑，以检验输入输出信息为主

④ 验收测试

1>定义：由用户、客户、系统的其他利益者，进行的确认是否可以接受一个系统柜的验证性测试

2>对象：系统、系统的某部分或特定的系统非功能特征

3>目标：对系统功能、系统莫部分或特定的系统非功能特征进行测试，来确定系统是否满足客户需求并能够进行商用，建立信息。发现缺陷不是验收测试的主要目标

4>策略

1.验收测试内容取决于应用风险，包括彻底的验收测试、简单的验收测试、互操作验收

2.由用户参与输出测试用例与测试

5>分类

1.用户验收测试

2.运营测试：如系统备份/恢复测试、灾难恢复测试、用户管理测试

3.合同和法规性验收测试

4.现场测试

在软件开发组织的现场进行

在用户现场进行，也称为工厂验收测试和现场验收测试

9.3 是否涉及源代码

① 黑盒测试

1>定义：不需要参考组件或系统内部结构，依据客户需求，检查程序的功能是否符合它的功能说明。又称为功能测试或数据驱动测试

2>分类

1.功能测试

2.性能测试

3.可靠性测试

4.安全性测试

5.客服务性测试

6.兼容性测试

3>测试设计方法

1.等价类划分：把全部输入数据合理划分若干等价类，在每一个等价类值中取一个数据作为测试的输入条件

2.边界值分析：对输入或输出的边界值测试的一种方法

3.判定表：采用表格的形式，列出所有条件和所有结果的组合，做到无遗漏覆盖的测试方法

4.因果图：对多个输入之间的组合以及输入、输出之间的因果关系进行分析的方法

5.正交分析：从大量的试验点中选取适量有代表性的店，应用统计学理论中推导出的正交表，作为输入条件

6.功能图：根据被测功能的状态迁移图以及逻辑功能图的覆盖进行测试用例设计的方法

② 白盒测试

1>定义：根据被测对象的内部结构，设计测试用例的一种测试方法，又称为结构测试

2>对象：被测程序、组件

3>目标：按照被测对象内部的机构进行测试，确认是否达到预定要求

4>策略：主要应用于程序内部测试

5>分类

1.语句覆盖

2.判定覆盖

3.条件覆盖

4.判定条件覆盖

5.条件组合覆盖

6.路径覆盖

9.4 按测试针对的质量目标划分

① 功能测试

② 可适用性测试

③ 性能测试

④ 可靠性测试

9.5 其他分类方法

① 资料测试

1>定义：对产品资料的有效性、使用率和用户主管满意度进行测试

2>对象：产品配套、最终交付给客户的文档

3>目标：使用户能够按照产品手册的描述进行操作，以便能完成用户要求实现的某种功能

4>策略：不同文档使用不同策略，比如产品描述文档一般采用文档走读和其他辅助方法；安装文档采用文档走读、验证和其他辅助方法

② 自动化测试

1>定义：通过软件来模拟人的测试行为，替代人的测试执行工作

2>对象：函数、模块、整个系统等，可以用于单元测试、集成测试和验收测试等活动

3>目标

1.提高测试效率，讲需要重复的测试工作交给机器和软件执行

2.提高测试质量，完成手工很难完成或不可能完成的测试工作，并保证多次测试的一致性

4>策略：针对需要被反复只小姑娘的用例，并且产品或特性变更少，自动化价值大

③ 回归测试

1>定义：指修改里旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

2>对象：系统先前测试过并修改的部分，并根据分析确定其它可能受影响的部分

3>目标：确保在修改之后系统的各个方面依然保持原有的功能

4>目标

1.回归测试的规模可以根据已正常运行的软件中发现新的缺陷的风险大小来决定

2.回归测试一般可以通过自动化工具大大提高效率

5>范围：可以在所有的测试级别上进行，同时适用于功能测试、非功能测试和结构测试

6>内容

1.重要的功能（主要业务、VIP使用的功能、没有办法替代的功能）

2.执行最频繁的路径

3.本次升级有可能影响的功能

二、工作级

1、发展历程

华为研发模式：瀑布->敏捷（项目级/版本级/产品级）->DevOps

2、测试活动对应测试角色

3、常用测试设计方法

4、瀑布模型测试

4.1 严格吧软件项目的开发分割成各个阶段：需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试

5、DevOps模式

5.1 Development+Operations的组合

5.2 “大系统小做”，服务/微服务架构是快速创新的技术基础

5.3 小批量/小粒度频繁的发布和部署，平滑集中部署的风险

5.4 运营驱动开发，小步快跑，唯快不破，在运营中持续开发，用开发构筑运营的竞争力

5.5 自营+合营的运作模式，变“卖产品”为“卖服务”

5.6 打破研发和运营团队之间的界限

5.7 该模式下，交付以微服务为主，微服务独立发布

5.8 微服务测试活动解耦，实现服务独立的测试和质量评估能力。增强在线测试能力，对线上业务持续测试和监控

5.9 构建端到端的服务化测试流水线，支持微服务独立开发、验证与上线

6、敏捷测试

6.1 基本概念

① 是一种强调轻量的过程方法论，强调拥抱变化而不是与之对抗

② 为了可以快速的响应变化，通过与客户的亲密合作来取代合同的约定

③ 绝大多数的敏捷方法论采用迭代/增量开发的过程模型

6.2 开发原则

① 尽早的、持续的交付有价值的软件

② 欢迎改变需求，利用变化

③ 交付的时间间隔越短越好

④ 小批量是快速交付的关键

6.3 测试流程

6.4 测试计划

① 产品整理的测试计划：包含产品场景测试分析、迭代SDV测试、SIT测试

② 迭代Task测试计划：详细说明每个Task（小粒度需求）的用例数、日期、验收用例等，在每轮迭代的开始完成

6.5 测试设计

① 设计流程

1.开发、测试全过程结合：OR/DR/场景分析出测试场景用例

2.基于迭代需求分析进行迭代测试设计，对于非关键特性可免测试设计文档，直接输出测试用例

3.定义详细的测试用例写作规范和模板，引导用例设计的充分性，输出“好”用例

② 设计特点

1.分布设计

2.测试设计扁平化

3.迭代闭环测试设计

4.开发测试紧密融合

③ 设计方法

1>等价类

1.等价类覆盖：有效等价类/无效等价类

2.等价类划分原则

输入条件是一个布尔值，可以获得一个有效等价类和一个无效等价类

输入条件规定“必须如何”的情况下，获得一个有效等价类和一个无效等价类

规定了输入数据必须遵守的规则，可以获得一个有效等价类和若干无效等价类

输入条件规定里取值范围，可获得一个有效等价类和两个个无效等价类

规定了输入数据的一组n个值且分别处理，可获得n个有效等价类和一个无效等价类

3.等价类划分总结

优点

思路简洁，操作简单

最终测试用例规模小，可以充分覆盖特性测试规格

缺点

没有考虑输入之间的组合情况

完全基于特性测试规格不考虑内部实现，容易造成用例遗漏

对输入的边界考虑不充分，需要和边界分析法一起使用

2>边界值

1.边界上的值，正好在边界值上方的值，正好在边界值下方的值

2.选取原则

确定输入范围

生成测试用例（三点法）

字符：起始-1/结束+1

数值：最小值-1/最大值+1

空间：小于空余空间一点/大于满空间一点

阈值：小于阈值一点/大于阈值一点

正好等于，刚好大于，刚刚小于

测试项整合

3.适用范围

条件规定了一个值的范围

条件规定了值得个数

条件规定了值得先后顺序

4.三点法

上点：边界上的店，如果是闭区间上点在域范围内，开区间在域范围外

离点：离上点最近的一个点，闭区间在域范围外，开区间在域范围内

内点：域内的任意点

6.6 测试用例实现

① 流程：“测试用例实现”输入包含：测试方案、测试用例清单、产品开发文档、测试工具

② IBO测试模型：测试目的、预置条件、输入、输出、内部信息、预期结果

③ 通用模板：用例标题、预置条件、测试步骤、预期结果

④ 好的测试用例:可执行性、重用性、可重复性、规范性：易懂、易确认、风格一致、用词一致、精确、简洁

6.7 敏捷测试自动化

① 目的：完成迭代的循环测试，保证新的交付不会造成产品版本的质量下降，问题可以及时快速反馈，并保证版本质量的持续提高

② 要求

1>版本发布多节奏快，全流程自动化

2>自动化需要覆盖基本功能和典型场景

3>自动化需要端到端投入，按照要求快速分析及落地

6.8 敏捷迭代测试验收

① 活动描述

1>Task澄清：本Task主要做什么，实现哪些功能

2>梳理测试重点

② 输入：Task和计划

③ 输出：Task签收情况

6.9 迭代测试执行与回顾

① 活动描述

1>每天测试版本是否采用前一天最新发布版本

2>测试用例执行，及时提单

3>测试过程中未澄清疑问及时沟通并优化用例

4>缺陷跟踪

② 输入

1>迭代测试用例

2>迭代经验和温恩替

③ 输出

1>问题单，测试报告

2>迭代回顾会议纪要

搜索

复制

<iframe></iframe>

标签：测试,迭代,等价,基础知识,测试用例,模块,软件
来源： https://www.cnblogs.com/xuanling/p/16440666.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。