软件测试与质量复习
- 软件缺陷定义：
软件缺陷就是软件产品中存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。
软件缺陷表现形式
- 设计不合理，不是用户所期望的风格、格式
- 部分实现了软件某项功能
- 系统崩溃、界面混乱
- 数据结果不正确、精度不够
- 存取时间过长、界面不美观
软件缺陷案例（UML路径错误、int类型的数据溢出、J2ME存在的漏洞、平台设计不合理）
软件测试与质量的关系：息息相关，分不开，测试是手段，质量是目的，软件测试作为一种辅助而且必需的手段，客观反映某个时间段内的软件质量。
软件测试作为软件质量的重要保证。通过分析和测试软件来发现和纠正错误，可以保证软件质量。软件质量控制所采取的主要技术就是软件测试，通过软件测试，来验证产品是否符合技术文档预期的功能、特性和性能等要求，并识别产品缺陷。
软件测试与软件开发过程的关系：
密不可分。软件测试在开发阶段具有以下作用：
- 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控
- 需求分析阶段: 确定测试需求分析、系统测试计划的制订，评审后成为管理项目。
- 详细设计和概要设计阶段:确保集成测试计划和单元测试计划完成。
- 编码阶段：由开发人员完成自己负责部分的测试代码，当编写工作项目较大时，由专人进行编码阶段的测试任务。
- 测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。
测试和开发贯穿软件过程的整个生命周期，二者相辅相成、相互依赖。
同时开始，同时结束，保持同步关系，并行的。
测试过程是对开发过程中阶段性成果和最终产品进行验证的过程，所以2者相互依赖。前期，测试过程更多地依赖开发过程，后期，开发过程更多地依赖测试过程。
软件测试定义
使用人工或自动手段来运行或测试某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试目的
以最少的时间和人力找出软件中潜在的各种错误和缺陷，证明软件功能和性能与需求说明相符。
- 找出错误、分析错误发生原因和错误发生趋势，帮助管理者发现缺陷，及时改进。
- 测试分析帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。
- 完整的测试是评定软件质量的一种方法，没有发现错误的测试是有价值的。
软件测试原则
- 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
- 测试用例应由测试输入数据和与之对应的预期输出结果两部分组成。
- 程序员应避免检查自己的程序
- 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件
- 充分注意测试中的群集现象
- 严格执行测试计划，排除测试的随意性
- 应当对每一个测试结果做全面检查
- 妥善保存测试计划、测试用例、出错统计和最终分析报告，为软件维护提供方便
3、 软件测试的基本思路
- 增加功能的测试思路，必填项校验、文本输入框校验
- 修改功能的测试思路，考虑什么类型的数据允许修改
- 删除功能
单条删除：删除权限，删除的恢复和撤销、数据库变化、由于业务影响不能删除
多条删除：系统异常是否删成功，有条件的选择多条删除（构造符合条件的删除和不符合条件的删除，检查消耗时间
- 查询功能
- 导入导出功能（文件类型格式、大小、文件数据格式、导入导出的结果是否正常）
- 计算功能（弄清计算逻辑，把所有可能的情况都测了）
- 业务流程，走完整流程
为什么需要测试用例，
- 设计测试用例是为了更有效、更快地发现软件缺陷
- 测试用例具有很高的有效性和可重复性，依据测试用例进行测试可以节约测试时间，提升测试效率
- 测试用例具有良好的组织性和可跟踪性，有利于测试的管理
什么是测试用例，
测试用例就是为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定需求。
单元测试（unit testing）：是指对软件中的最小可测试单元进行检查和验证。程序的多个模块可以并行地进行单元测试。
解决任务：边界条件、局部数据结构、模块接口、出错处理、路径测试
单元测试的依据
（1）源程序本身，代码 + 注释。 （2）《详细设计》文档。
单元测试的通过标准
- 程序通过所有的单元测试的用例。
- 语句的覆盖率达到100%。
- 分支的覆盖率达到85%。
单元测试的一般步骤（白盒测试）
- 编译运行程序，查看能否正确运行
- 静态测试（查看编码规范）
- 动态测试（运行程序）
➢单元的质量是整个软件质量的基础，所以充分的单元测试是非常必要的。
➢ 通过单元测试可以更早地发现缺陷，缩短开发周期、降低软件成本。多数缺陷在单元测试中很容易被发现，但如果没有进行单元测试，那么这些缺陷在后期测试时就会隐藏得很深而难以发现，最终导致测试周期延长、开发成本急剧增加。
集成测试（integration testing）：是指将已通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。
三明治集成-混合策略：改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得更彻底。
集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。重点检测各个模块的接口部分，如函数之间的参数传递是否正确、全局变量的使用等。
实际：单元测试和集成测试同步进行，在单元测试中先测试几个函数的功能，然后再集成测试一下这几个函数的接口（即参数传递）。
集成测试的依据 （1）单元测试模块。 （2）《概要设计》文档
➢ 确认测试用于验证软件的有效性，验证被测软件是否满足需求规格说明书中 列出的需求，即验证软件的功能及其他特性是否与用户要求一致。
➢ 软件的功能要求在软件需求规格说明书中已经明确规定，即需求规格说明书 包含的用户需求信息就是软件确认测试的基础。
系统测试是验证软件产品是否符合这些质量特性要求的测试。系统测试包括性能测试、安全测试和兼容性测试、易用性测试等。
验收测试（acceptance testing）：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保证人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。重要性：涉及到用户能否最终验收签字并付款。
6、 软件测试分类
执行主体分类：开发方测试（alpha、验收测试）、用户（β）、第三方测试（独立测试）
静态测试（static testing）：不实际运行被测软件，只是人工静态分析和检查程序代码界面和文档中可能存在的错误的过程。
7、 软件测试模型：V 模型、W 模型
8、
Alpha测试：由用户、测试人员、开发人员共同参与的内部测试，检验是否满足需求
Beta测试：内测后的公测，即完全交给最终用户测试
回归测试：一种验证已变更的系统的完整性与正确性的测试技术，是指重新执行已经做过的测试的某个子集。
冒烟测试（Smoke Testing）是指：针对每个版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单的验证性测试，验证产品或系统的“基本功能”流程是否正常。
随机测试是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误
1、 黑盒测试：什么是黑盒测试
也称功能测试，是通过测试来检测每个功能是否都能正常使用。在测试中把程序看成是一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，对程序接口进行测试，它只检查程序功能是否按照规格说明书的规定正常使用，程序是否能适当地接受输入数据而产生正确的输出信息。
2、
等价类划分法的定义：等价类划分法是把所有可能的输入数据，即程序的输入数据集合划分成若干个子集（即等价类），然后从每一个等价类中选取少量具有代表性的数据作为测试用例。
- “有效等价类”：完全满足产品规则说明的输入数据，即有效的、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规则说明所规定的功能性要求。
- “无效等价类”：和有效等价类相反，即不满足程序输入要求或者无效的输入数据构成的集合。
等价类划分原则：
- 如果规定了输入值的范围，可定义一个有效等价类和2个无效等价类
- 如果规定输入的规则，可以划分出1个有效等价类和若干个无效等价类（从不同角度违反规则）
- 如果规定了输入数据的一组值（数值），且程序对不同输入值做出不同处理，则每个允许的输入值是一个有效等价类，并由一个无效等价类（所有不允许的输入值的集合）
- 如果规定了输入数据是整型，则可以划分出正整数、负整数和0这3个有效等价类。
- 当处理表格时，有效类可以划分为空表、含一项的表、含多项的表等。
使用等价类划分法的过程
（1）形成等价类表，每一等价类规定一个唯一的编号。
（2）设计一测试用例，使它能够尽量覆盖尚未覆盖的有效等价类。重复这个步骤，直到所有的有效等价类均被测试用例所覆盖。
（3）设计一新测试用例，使它仅覆盖一个尚未覆盖的无效等价类。重复这一步骤，直到所有的无效等价类均被测试用例所覆盖。
3、
边界值分析法定义：就是对输入或输出的边界值进行测试的一种黑盒测试方法
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
使用边界值分析法的过程
如果是范围，选择刚到达范围的边界值以及刚刚超越边界的值作为测试数据。
决策表法的定义：决策表法是分析和表达多逻辑条件下执行不同操作的技术
决策表的概念：决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。
制定决策表一般经过以下4个步骤：
• 列出所有的条件桩和动作桩。
• 填入条件项。
• 填入动作项，制定初始判定表。
• 简化、合并相似规则或者动作
规则的简化和合并
– 如果两条或多条规则的动作项相同，条件项只有一项不同，则可以将该项合并，合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。
使用决策表法的过程
因果图法的定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图中输入条件与输出结果之间的关系（4 种）
因果图中输入或输出的约束关系（5 种）
使用因果图法的过程
三、白盒测试
1、
白盒测试方法：对软件的过程性细节做细致的检查，把测试对象看成是一个打开的盒子，允许测试人员利用程序内部逻辑结构及有关信息，设计或选择测试用例，针对程序语句、路径、变量状态等来进行测试。
静态白盒测试是一种不执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。侧重于纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。
人工静态测试（代码检查法、静态结构分析法）
2、
逻辑覆盖法定义：通过对程序逻辑结构的遍历实现对程序的覆盖，它是一系列测试过程的总称。
• 逻辑覆盖法以不同的覆盖项作为测试标准。
• 覆盖项是指作为测试基础的一个入口或属性，比如语句、判定（分支）、条件等。
5 种不同的逻辑覆盖标准（语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、条件组合覆盖），
语句覆盖法（SC）的基本思想是：设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次
判定覆盖法（DC）的基本思想是：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。
条件覆盖（CC）的基本思想是：设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。
条件-判定覆盖（CDC）：是条件和判定覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
条件组合覆盖(MCC)的基本思想是：设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。
它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两
种结果，而是要求让这些结果的所有可能组合都至少出现一次
使用逻辑覆盖法的过程
3、
基本路径/线性无关路径：包括一组以前没有处理的语句或条件的一条路径（与其他基本路径至少有一条边不能相同）
基本路径测试方法:在不能做到所有路径覆盖的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是基本路径测试法
基本路径测试开始前的准备工作：分析源程序、绘制程序控制流程图
使用基本路径法的步骤和过程
- 导出程序的控制流图
- 计算控制流图 G 的圈复杂度 V(G)
- 导出独立路径（用代码行号表示）
- 设计测试用例，确保基本路径集中的每条路径都被执行
控制流图（程序流程图转化为控制流图，复合条件下生成控制流图）
图矩阵（控制流图转化为控制流图矩阵）
圈复杂度的计算（4 种方法）
圈复杂度为程序逻辑复杂性提供定量的测度，该度量用于计算程序的基本独立路径数目，确保所有语句至少执行一次的测试数量的上界。
V(G)=4（区域数）或：V(G)= 3（判断节点数）+ 1 = 4；
V(G)=10（边的个数）-8（节点个数）+2=4；
四、性能测试
1、
性能测试：测试在一定条件下系统行为表现是否符合需求规格的性能指标，例如计算精度、响应时限、恢复时限、传输错误率等性能指标。
2、
响应时间：对请求做出响应所需要的时间。（网络传输和应用延迟）
并发用户数（1同一时刻做同一件事情、2发出请求或者操作可同可不同）
➢ 第一：并发强调所有的用户必须在同一时刻对服务器进行施压。
➢ 第二：强调要与服务器进行数据交互。同类/不同类操作
吞吐量：指在一次性能测试过程中，网络上传输数据量的总和。
➢ 1、一般来说，在系统的设计范围之内，吞吐量随系统的并发用户数的增加呈现增加趋势；
➢ 2、当超出这个范围时有两种情况，一种是系统只能处理这么多，超过这个数系统不接收了，最后随着并发用户数的增多吞吐量是一个水平的直线；还有一种情况是不管来多少系统都接收最后导致系统吞吐量下降甚至系统崩溃。
➢ 性能计数器：描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间等，在性能测试中发挥着“监控和分析”的作用
- 资源利用率：CPU占用率、内存占用率、磁盘使用率、网络等。
- 资源利用率表现当前服务器资源使用的情况，它是分析服务器出现瓶颈和对服务器进行调优的主要依据，在配置调优测试的过程中，通过比较配置调优前后系统资源的使用率来判断调优的效果.
➢ 思考时间(Think Time)：也称为“休眠时间”，是指用户在进行操作时，每个请求之间的时间
间隔。
➢ 点击率(Hit Per Second)：是指每秒钟用户向Web服务器提交的HTTP请求数。
➢ 用户每点击一次，服务器端就要对用户提交的请求进行一次处理；
➢ 对于Web 系统来说，点击率是服务器处理的最小单位，点击率的值越大，说明服务器端所能承受的压力越大。
➢ 通常情况下，Web 服务器都具有防刷新的机制，因为客户每刷新一次系统就要响应一次点击，如果不对服务器进行防刷新处理，当用户不停地单击刷新按钮，此时服务器将承受着巨大的压力。
3、 常见的性能测试：基准测试，并发测试，联机测试，综合场景测试，负载测试，压力测
试，每种性能测试的目标和执行方式
基准测试（Benchmark Testing）单用户测试
基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试，目的在于量化响应时间、吞吐率的指标，便于后续比对。
方法是做多组不同场景的测试，观察结果，抽取出几个关键数据做好记彔，用于以后进行性能对比和评价。
并发测试（Concurrency Testing）
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
特点：
（1）主要目的是发现系统中可能隐藏的并发访问时的问题。
（2主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。
（3） 可在在开发的各个阶段使用，需要相关的测试工具的配合和支持。
负载测试（正常下承受多大负载）：可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试，他的主要目的验证业务或者系统在给定负载条件下的处理能力。此外，还要关注响应时间、每秒通过事务数和其他相关指标。（一次加载、递增加载、高低突变加载、随机加载方式）
负载测试是为了发现系统问题（内存泄漏、性能瓶颈）。而性能测试是为了获取性能指标。
压力测试（施加多大压力使得系统崩溃）：可以理解为没有预期的性能指标，不断加压，看系统什么时候崩溃，以此来确定系统的瓶颈不能接受的性能拐点，以获取系统的最佳并发数，最大并发数（高负载稳定性测试+极限负载破坏性压力测试）（步骤1：简单多任务测试；2：修正后增加压力直到崩溃）
压力测试也可以看作负载测试的一种，即高负载下的负载测试。负载测试与压力测试的概念并非完全独立，在实际应用中一般二者都是相互结合，相互补充的。
版权归原作者 hahahahanhanhan 所有， 如有侵权，请联系我们删除。