软件测试笔记本卡不卡，软件测试笔记本推荐
软件测试概述程序文档数据=软件狭义软件测试定义(执行程序或系统以发现软件缺陷的过程广义软件测试定义)手动或自动执行或测量某个系统的过程， 目的是验证它是否满足规定的需要，或者为了明确期待的结果和实际结果的差异，为什么要进行软件测试。
软件缺陷功能错误发现超出需求的部分(画蛇添足)性能不满足要求软件质量高)是否符合用户习惯、符合用户需求的测试任务
决定修改后进行回归测试，对修改的部分再次进行测试，避免引入新的错误测试用例定义和组成部分
测试用例是为特定目的而设计的一组测试输入、执行条件和预期结果。
测试用例是要运行的最小实体。
简而言之，测试用例就是设计这样的场景：软件程序必须在这种情况下正常运行，并且程序必须达到设计的执行结果。
用例ID用例名称测试目的测试环境前提条件测试步骤预期结果包括其他信息的优秀高质量测试用例是能够发现以前没有发现的错误，成功的测试是能够发现以前没有发现的错误的测试
两个方向
寻找错误，逆向思考。
证明工作正常，能正向思考。
目前方法的出发点是“寻找错误”。 因为我们不能证明软件是正确的。
用户需求
什么时候停止测试
继续测试不会发生新的失效，无论是继续测试还是发现新的缺陷，满足要求的回报都很少，无法考虑新的测试用例。 (如果符合测试规则和准则，则可以选择)测试过程模型的缺陷具有扩大的特征，随着阶段的推进，发现错误的成本会指数上升，因此开发过程不仅仅是代码级别的测试
瀑布模型：需求分析-设计(概要、细节) -编程-测试)单元、集成、系统) -维护v模型)瀑布-变更) :在软件开发的有生之年，开发活动和测试活动几乎都是详细设计阶段结束后出现单元测试的测试用例等w模型) ) v模型在制作更细分化、精细化的软件的同时进行测试)在需求分析上进行需求测试，在概要设计上进行功能测试，在详细设计上进行设计测试，在编码上进行单元测试，在集成上进行集成验收测试增加了系统测试h模型)没有实际意义，可以独立测试软件的原则只是所有测试都应该根据用户的需求提前、持续地进行软件测试(缺陷具有不断扩大的特点， 测试成本随着阶段的发展而上升(8-2原则测试中发现的错误的80%很可能是因为在程序中20%的早期测试中发现了80%，在系统测试中发现了剩下的80% )全部的16 ) 80%的工程可能用于20%的需求，也就是关键需求……软件缺陷的寄生虫性：发现的缺陷越多，说明软件留下的缺陷越多，避免自己测试自己程序的回归测试
测试不是开发后期的一个阶段的测试，实际上有点简单，但是像技术这样要求高的测试往往不能覆盖所有的输入。 “有时间，就有时间，就没有时间测量”软件测试不仅仅是测试人员的事，也是开发人员的事。 与调试和测试不同，测试不仅仅是运行软件并查看结果。 L10N :本地化测试I18N :国际化测试
黑箱测试等价类的划分及边界值分析如何划分有效与无效等价类(若干一般原则)
如果某个变量在一个范围内，给出其有效等价类的两个无效等价类某个变量在某个集合范围内，则可在集合内取有效等价类，在集合外取无效等价类。 如果某个变量的条件是“必须怎么样”、“必须怎么样”，则满足“必须怎么样”的条件，再取多个不满足的条件，从多个角度违反该条件，则一个变量是布尔型
有效等价类：尽可能多地覆盖有效等价类和无效等价类。 每找到一组数据至少覆盖一组无效等价类。 如果功能模块有多个输入，如何将多个自变量合并在一起寻找有效的等价类、无效的等价类、测试数据。 四种方法：以具有自变量X1，X2的函数f为例，X1可取值的范围为[a，b]、[b，c]、[ X2可取值的范围为[e，f]、[f，g]。
只有有标记的块内为一般等价类测试(不处理无效数据的测试)，所有的块为顽强等价类测试(处理无效数据的测试)
弱一般等价类
有假设前提：为单缺陷。 也就是说，假设系统中出现的缺陷很少是由2个以上的输入变量共同出现的缺陷引起的。
要使选定的测试用例覆盖所有有效等价类，必须针对X1 (横轴( ( a，b )、( b，c )、( c，d ) )。 必须复盖X2 (纵轴) ( e，f )、( f，g )。
在保证了这两点的情况下，可以任意取强的一般等价类
基于多缺陷假设选择的测试用例复盖所有有效等价类的直积。 (集合a(a1，a2，a3 )集合b ) b1，b2 )他们的笛卡儿积为a1，b1 )，( a1，b2 )，( a2，b1 )，( X2 )纵轴( ( e，f )，) f，g
有假设前提：为单缺陷。 也就是说，假设系统中出现的缺陷很少是由2个以上的输入变量共同出现的缺陷引起的。
考虑无效值，对于有效输入，测试用例设计与弱一般等价类相同； 对于无效的输入，测试用例必须保证具有一个无效值。 例如，如果某个变量的有效类的可取范围为x、y、z，则无效类为x-和z，总的可取范围为x-、x、y、z、z。 (保证剩下的值都有效。
因此，如下图所示，在确保弱一般等价类的可能点之后，必须分别确保X1，X2之一属于无效输入的两个多余可能范围，以及另一个属于有效输入的原始可能范围(例如，x1=无效X2 )
强健等价类
基于多缺陷，假设所有可能值的范围取笛卡儿积。 例如，如果某个变量的有效类的可取值的范围为x、y、z，则无效类为x-和z，并得出的值的范围之和为x-、x、y、z、z。 另外，取其他变量的取值范围和笛卡儿积。 (查找测试数据时
对于单缺陷，只有一个输入变量属于无效等价类，所有其他输入变量属于有效等价类。
包括：单一缺陷有效值单一缺陷无效值多缺陷时，即由多个输入变量同时出错引起。
包括：边界值分析是有效值和无效值与等价类划分密切相关。
划分等价类，然后结合边界值生成测试用例。
边界值分析也有单一缺陷的假设。
有四种设计测试用例的方法。
一般边界值分析的有效范围：最小、稍大于最小、正常值、稍大于最大、最大值无效范围：小于最小、大于最大共7个，通过进一步划分单一缺陷和多缺陷，设计用例个数呈指数上升
16位整数32767~-32768报表第一行和最后一行的屏幕光标左上角和右下角数组中第一个和最后一个循环的0，1，倒数1，倒数第二个决策表适用于该问题。 条件在多个组合中执行不同的操作。 有很多if、else if和else。 环路结构最严格，也不能说是最合乎逻辑的
规则：通过条件的任意组合，判定表中的一列(贯穿条件项和行动项)。
判定表上有几列表示有几个规则。
规则的简化：某个规则是相互包含的，可以简化
因果图确定所有原因并确定结果。 另外，可能还有中间结果的产生。 绘制因果图时请注意。
从输入中考虑I。 如果出现虚线，与ab相连，则表示ab中至少有一个必须使e成立。 如果出现虚线，与ab相连，则表示ab不能同时成立。 如果a在指向b的虚线三角箭头上，那么a出现的时候b也必须出现，一个也不会出现。 根据输出考虑m，如果a位于指向b的虚线三角箭头上，则当a为1时b必须为0。 当a为0时，b值是不定的(在恒等(:或非(:或：且ci :原因ei )结果中生成因果关系图后，根据图得到决策表，得到对应的测试数据)，将原因节点的中间节点作为条件桩，将结果节点作为动作桩
白盒测试逻辑改写-判定改写-判定/条件改写-条件组合改写-路径改写(按每个_条件改写/12句改写)判定分支至少执行一次条件改写)各判定条件取得各种可能的值判定/条件改写
有条件覆盖>； 判定盖>； 语句覆盖(即达到条件覆盖时，达到判定覆盖和语句覆盖)达到判定覆盖时，达到语句覆盖。 以下同样理解。
有条件覆盖>； 有条件的掩饰。
条件盖不一定包括判定盖、语句盖。
判断覆盖不一定包含条件覆盖。
路径复盖、判定复盖>； 语句覆盖。
基本路径测试基于程序环路复杂度测试方法，制定控制流程图，计算环路复杂度，找到独立路径并压缩到基本路径集合中，针对每个集合中的路径设计用例。
将复合逻辑表达式划分为一个表达式循环的复杂性用于计算程序的基本独立路径数。 每个新的独立路径都必须包含从入口到出口互不相同的新的有向边
当环路复杂的v(g ) e-n2p【边缘-节点2*连接区域数量，连接区域p通常为1】=P 1【判定节点数量1】通常，一个单元模块的最大复杂度v ) g ) 10将复盖的通路数量压缩到一定限度内时，例如
基于数据流的测试是根据真正的数据定义到数据的使用来测试的，必须找到定义的节点(包括赋值和比较)和使用的节点
定义节点DEF。 输入语句、赋值语句、循环语句、过程调用； 变量值发生变化的语句使用节点USE。 输出语句、赋值语句、条件语句、循环控制语句和过程调用必须找到所有此功能代码的定义位置和执行位置，并找到路径。
定义使用路径(从在第一个节点上定义某个变量开始，直到在最终节点上使用该变量为止)；定义清除路径(某个变量从定义节点到使用节点并未次级定义此变量)
循环测试假设程序是结构化的。
简单的周期测试
0次走刀循环1次走刀循环2次走刀循环m次走刀循环( m=循环最大次数) m-1、m、m 1次走刀循环试验的工艺单元测试单元试验内容： 5分(简答题) )。
模块接口测试局部数据结构测试独立路径测试错误处理测试边界测试单元测试的模块
被测试模块(被测试程序的模块驱动模块)测试模块的上级模块，被测试模块的主控程序存根)模拟被测试模块运行中调用的模块单元测试
为要测试的代码或要测试的功能点创建测试类，并在类中创建一个测试方法。
通过实例化对象调用被测方法，用断言进行实际值期望值的比较。
单元测试的方法
以白盒测试法为主，静态检查代码是否符合规范，然后动态运行代码并检查结果。
不仅要验证结果是否正确，还要检查程序的容错性、边界值处理等问题。
集成测试一次性集成big-bang :将通过单元测试的所有模块按设计要求一次性全部组装，然后进行整体测试。
时间变短了，但我急于成功。
自上而下逐步集成：从主程序模块开始，在按深度或广度优先策略组装的同时测试自下而上。 从最底层模块组装并集成测试汉堡。 两者相结合，采用树状逐层划线，顶层自上而下，底层自下而上相邻集成。 上下三层成对合并。 基于初始配对后相邻MM路径的集成： MM路径描述的不是可行路径，而是单元之间的控制转移。
最终得到调用图，去基本路径测试，寻找复杂度，寻找路径，得到测试用例的途径
系统测试黑匣子为主
系统测试对象(9)易用性、国际化本地化、性能、功能、界面、兼容性、安全性、文档、安装
具体地说，Web系统测试是测试Web系统测试的功能测试中包含什么样的内容、cookie的内容属于Web系统测试的哪个项目的测试(功能测试)
功能测试
页面测试页面链接测试表单测试cookie、Session测试设计语言测试数据库测试性能测试(负载/压力) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )。
连接速度测试工具LoadRunner负载测试压力测试网页性能Firefox插件： Yslow、Findbug、pagespeeddynatraceweb页面性能可靠性测试：不间断测试，出现多少错误
用户界面测试/易用性测试
导航测试图形测试内容测试总体界面测试安全性测试兼容性测试界面测试
在服务器接口外部接口的错误处理中，主要介绍了性能测试的含义和方法。 例如，包括压力测试方法、负载测试方法等
性能测试通过使用自动化的测试工具模拟各种正常、峰值和异常的负载条件来测试系统的性能指标。
时间性能)软件的一个具体事务的响应时间空间性能)软件运行时消耗的系统资源是我背一袋米(乐我背一袋米)，在操场上跑来跑去，看多累倒下，多累倒下
如果在某个时刻同时访问Web系统/某个页面的用户数超过了这个数，系统会发生什么现象？ 在线数据处理负载/压力测试关注什么？
验证系统能否同时响应大量用户，用户传输大量数据时能否响应，系统能否长时间运行。
瞬间接入高峰，为每个用户传输大量数据，长时间使用LoadRunner性能测试工具原理。 录制、播放用户的实际操作场景，监视、分析执行结果。
自动化录制播放脚本是常用的自动化测试的主要方法，有哪些类型、哪些工具
功能测试工具： QTP性能测试工具：设计LoadRunner编写脚本、记录脚本，使用用户定义的参数场景生成虚拟用户的机制。 使用控制器控制模拟多少用户。
使用监听器测试结果原文作者： sgyzetrov原文来源： CSDN原文链接： https://blog.csdn.net/s _ gy _ zetrov/article/details/80879773版权归原作者所有