windows基础
软件定义
计算机=硬件加软件
软件=程序(program)+文档(document)
软件测试的对象：程序和文档都要测试
软件开发阶段划分
阶段一：需求分析阶段(由需求分析人员完成；产出物：《需求规格说明书》)
阶段二：设计阶段(由系统架构师/分析师完成；产出物：《概要设计说明书》和《详细设计说明书》)
阶段三：编码阶段(由开发人员完成/程序员完成；产出物：程序/代码)
不同的开发阶段引入的bug比例如何?
需求分析阶段引入的bug最多（大概占bug总数的55%左右）
其次是设计阶段（大概占缺陷总数的25%左右）
最少的是编码阶段（大概占缺陷总数的15%左右）
还有5%左右的缺陷是由系统兼容性或者配置原因造成的。
需求分析阶段引入的bug最多，其次是设计阶段，引入bug阶段最少的是编码阶段
因此：1）在测试中不能只测程序，文档也必须测
2）测试工作应尽早介入，并且贯穿整个开发周期始终(尽早测试原则，不断测试原则)
什么是软件缺陷
1.软件的缺陷–defect,bug
2.软件缺陷的定义：1）需求要求的功能没有实现
2）实现了需求没有的功能(画蛇添足)
3）软件出现了指明不应出现的错误
4）需求虽未明确指明，但是应该实现的功能没有实现
eg:法规； 说明：需求不是完美的，有可能有遗漏，但是测试人员应该专业，发现bug就要提交，即使需求中没有提及
5）软件不易使用，难以理解，运行缓慢等，站在用户角度上，一切不合理的（不好的）地方都可以看成缺陷。
3.软件的两个基本要素：
1）软件的功能要能实现(基础)
2）软件要有强大的异常处理能力(健壮性)
4.软件缺陷定义方式2：
由IEEE(美国电气和电子工程师协会)提出的软件缺陷定义
1）从软件外部看(黑盒测试)
2）从软件内部来看(白盒测试)
5.缺陷的同义词：
问题、毛病、异常、错误、功能实现有失效、违背
软件测试
1.测试-Test
2.什么是软件测试
简单来说，软件测试就是从现有软件中，尽可能的发现缺陷的过程
说明：1）软件不是完美的，测试人员的职责不是消灭缺陷，但是应该尽可能多的查找缺陷
2）软件测试强调排查缺陷的过程，只要是查找缺陷的过程就是测试，无论找到还是没有找到缺陷(软件公司鼓励测试人员多发现缺陷)
计算机的层次
1.计算机硬件（裸机）；操作系统； 应用软件
2.扩展
1）操作系统的作用：操作系统(Operating System – OS)作为中间系统平台，将计算机系统的硬件和软件统一进行管理
2）常用的OS有哪些?各自擅长的领域？
1）windows系统（微软）
优点：简单、易用，所以windows系统拥有大量的个人用户(pc ：个人电脑（personal computer）桌面之王)
缺点：安全性、稳定性较差；导致windows操作系统在企业的服务器操作系统中占有率较低。
2）Unix系统（贝尔实验室 1969年）
特点:稳定性，安全性高; 适合做服务器的操作系统
补充：收费、支持二次开发
3）Linux系统 （自由软件）
被称为类Unix系统
特点：安全性，稳定性高，免费，支持二次开发，开源。例如：bat等一流软件公司，都使用Linux作为服务器操作系统。(二次开发后，适应公司的需求）
提示:Linux 的常用命令，面试几率较高。
4）Mac（苹果公司）
1981年苹果公司推出世界上第一款可视化的操作系统。
特点:擅长图形、图像的处理
所以在图像设计领域用户量较大。
5）Dos系统（Ms_dos 微软公司产品）
disk OS–磁盘操作系统
1981年微软公司为IBM公司的第一款pc机研发的OS。
dos命令: ipconfig (查看ip地址）
3）裸机中有软件吗?
有软件，BIOS(basic input output system 基础输入输出系统)；
BIOS安装在计算机主板的“CMOS”芯片中
BIOS的作用：计算机通电后，控制权首先交给BIOS程序，由BIOS程序进行“上电自检”—开机后首先由BIOS程序检查计算机硬件设备的连接是否完好，如果连接没有问题，将控制权转交给OS；如果连接有问题，那么BIOS将启动蜂鸣器，发出警报音，并阻止OS启动。
补充:(1)如何进入BIOS程序
台式机：开机后按“Delete”键（删除）
笔记本电脑:开机后按“F2”或“F8”，如果都不是查百度。
（2）注意：不要盲目修改，如果有修改的需求可以搜索帮助文档，或请专业人员协助。
软件的分类
1.基本分类
1）系统软件：操作系统；系统的补丁程序；驱动程序
2）应用软件：（1）娱乐类：游戏、播放类、阅读类、社交类等
（2）办公类:office、WPS、OA(办公自动化）等
（3）图形、图像类：PS（photo shop）、美图类、3dmax，玛雅，CAD等
（4）管理类:财务管理、客户管理、进销存管理、招投标管理、民航管理等
（5）数据类：Oracle数据库（甲骨文）、MySQL数据库、SQLserver（微软）、DB2（ibm公司）、sybase（sybase公司）、Access（单机版）
2.按结构分类
1）单机软件：特征：不需要网络就可以应用的软件是单机软件，例如：word,压缩软件，单机小游戏等
2）分布式软件：特征：需要连接网络（广域网和局域网），才可以应用的软件是分布式软件
（1）C/S结构：client/server：客户端/服务器结构， 客户端要安装专门的客户端应用程序，才能享受相应服务器提供的服务。例如：QQ\滴滴打车等
（2）B/S结构：Browser/server：浏览器/服务器结构，客户端不需要安装专门的客户端应用程序，只需要有公共的浏览器，输入不同的网址，就可以享受不同服务器提供的服务。
注意：如果测试B/S结构的软件，那么必须进行浏览器的兼容性测试
主流的浏览器：IE浏览器（测试时要测试不同的版本）；Firefox浏览器（FF，火狐），开源浏览器； Chrome浏览器（谷歌）；safari浏览器（苹果）；Opera浏览器（欧朋）；360浏览器等
进制和进制转换
1、十进制（案例：找到进制的规律）
1）系数：0-9
2）进位规则：逢10进1
3）权：基数的次幂
基数：几进制基数就是几
十进制的权：就是10的次幂
规律：最右侧一位的权是10的0次幂（1），每向左移动1位，次幂数+1。
4）进制的表示
方式1：下角标 （几进制下角标就写几）
方式2:后缀 （十进制的后缀 D）
说明：十进制是默认进制，可以不用任何特殊表示。
2、二进制（计算机的机器语言）
1）系数：0,1
2）进位规则：逢2进1
111B–7D ;1111B–15D
3）二进制的权
二进制的权是：2的次幂
规律：最右侧一位的权是2的0次幂（1），每向左移动1位，次幂数+1
扩展：
二进制（任意进制）→十进制
方法：按权展开求和法
方法说明：每位的系数乘以该位的权，乘积相加求和。
4）二进制的表示
方式1：下角标2
方式2：后缀B
5）二进制的缺点
二进制数据位数过多，所以表示时非常繁琐。
3、十六进制
说明:为了解决二进制位数过多，表示繁琐的问题，计算机中引入了十六进制（重点）和八进制
1）系数：0-9,A=10,B=11,C=12,D=13,E=14,F=15 (A-F)
2)进位规则：逢16进1
3）十六进制的权：16的次幂
规律: 最右侧一位的权是16的0次幂（1），每向左移动1位，次幂数+1。
十六进制→十进制
方法：按权展开求和法
4）十六进制的表示
方式1：下角标16
方式2：后缀H
4、八进制
1）系数：0-7
2）进位规则：逢8进1
3）权:8的次幂
规律：最右侧一位权是8的0次幂，每向左移动一位，次幂数+1。
八进制→十进制
方法:按权展开求和法
4）八进制的表示
方式1：下角标8
方式2：后缀O
进制之间的转换
1、以十进制为中心的转换
1）任意进制→十进制： 方法:按权展开求和
2）十进制→任意进制： 方法：除基取余逆读法
方法说明：步骤1：十进制数除以基数（要转成几进制就除几）得到商和余数（整数）；
步骤2：继续用得到的商除以基数，直到商为0时为止
步骤3:最后倒序读取余数作为结果。
案例：十进制→二进制
2、以二进制为中心的转换
说明：每4位二进制可以表示1位十六进制 。
1）二进制→十六进制：方法:4合1
方法说明：步骤1：将二进制数，从后向前每4位分成1组
步骤2：计算每组对应的十六进制结果（按权展开求和 ）
步骤3:按顺序将结果读出即可
2）十六进制→二进制：方法:1分4
将每1位十六进制，拆分成4位二进制
3、二进制与八进制的相互转换
注意:每3位二进制数据，表示1位八进制数据。
二进制→八进制： 方法:3合1
八进制→二进制 ：方法:1分3
问题：如果八进制和十六进制要相互转换，怎么转？
答：可以在中间使用二进制（或十进制）作为桥梁进制。例如：八进制→二进制→十六进制
缺陷报告
软件项目的测试流程
- 熟悉，分析需求（阅读需求，分析需求，整理业务）
- 制定测试计划：一般由测试组长或测试经理完成测试计划的制订，测试人员阅读并执行该测试计划。
测试计划中一般有哪些组成部分？
1）引言：目的、背景、范围、定义、参考资料
2）测试内容：测试功能清单
3）测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具
4）测试环境：硬件环境、软件环境、特定测试环境要求
5）项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
6）实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件
7）风险管理 - 设计测试（分析，使用合理的测试方法，设计编写测试用例）
- 执行测试，记录测试结果
- 记录缺陷，跟踪和管理缺陷（缺陷报告）
- 测试总结（提交：测试报告/测试总结报告）
四大文档：测试计划（项目）
测试用例
缺陷报告
测试总结报告（项目）
缺陷报告
- 什么是缺陷报告?
测试人员发现缺陷，将缺陷记录在《缺陷报告》
通过缺陷报告将缺陷告知给开发方
通过缺陷报告实现对缺陷的跟踪和管理
缺陷报告是测试人员和开发人员的重要沟通方式 - 如何编写缺陷报告
1）说明：在企业里通常是使用缺陷管理工具来对缺陷进行管理，例如：QC（hp公司，英文版，收费）；禅道（中文版，免费），bugzilla，企业自己研发的缺陷管理工具等
注意：不同的企业使用的缺陷管理工具不同，缺陷报告的模板也不是一模一样，但是缺陷内容大同小异。
2）缺陷报告的主要组成：案例：除以0时，弹出错误提示，点击确认后，程序异常退出
（1）缺陷编号（Defect ID）：记录的是发现缺陷的顺序号。
说明：缺陷编号可以唯一标识每一条缺陷
缺陷编号在缺陷管理工具中通常是自动生成的
缺陷是以项目为单位统一编号的
（2）缺陷标题（summary）：要求简明扼要的将缺陷概括出来。要求易读、易懂
（3）缺陷发现者（detected by）：测试人员自己的账号。（张三： zhangS_qc）
（4）提交缺陷的日期（detected on date）：注意：缺陷应及时提交
a）缺陷确认后应及时提交，不应人为延误。
b）发现缺陷后应确认:该缺陷不是由于测试人员操作疏忽或配置原因造成的“假缺陷”，确认后再提交给开发方。（测试人员应尽量避免假缺陷的提交）
（5）缺陷指派给谁处理（assigned to）：说明：默认规则是，在谁开发的模块中发现bug，谁就应该负责解决该bug。首先：由测试人员指派给开发方的负责人（开发经理，项目经理等），由开发方负责人再去指派给对应负责的开发人员。即总结指派过程：测试人员→开发方负责人→对应的开发人员
（6）功能模块：（subject）：在哪个功能模块中发现的bug；缺陷的基本定位；有利于开发方负责人，确定由谁来负责解决该bug。
（7）缺陷所属版本（detected in release）：说明：版本不仅指最终发布（或上线）的软件版本，也包括在软件研发过程中，出现过的若干临时版本。
(a)什么是回归测试?： 在当前版本中，对上一个版本中测过的所有功能重新测试一遍。
（b）回归测试的必要性（作用）?：在当前版本被修复的缺陷，有可能带来新的问题；新增加的功能有可能会对原有功能产生影响，带来新的bug；–做回归测试为了验证软件的原有功能是否依然正常
（c）回归测试存在用例的重复执行，所以建议企业在满足条件时，可以使用自动化的方式进行回归测试，以提高测试效率。
（8）缺陷的状态（status）：表明缺陷处于怎样的处理情况
（a）缺陷有哪些状态？：新的缺陷–new ；激活的缺陷–open；已修复的缺陷–fixed；关闭的缺陷–closed；被拒绝的缺陷–rejected；重新激活的缺陷–reopen
（b）缺陷报告的跟踪处理过程（流程、步骤、生命周期等）? ：
步骤1：测试人员发现缺陷，填写缺陷报告（新的–new），提交给开发经理。
步骤2:开发经理验证缺陷，可能会出现以下两种情况:
情况1：验证缺陷通过（承认该bug），将该缺陷激活（open），并指派给相应的开发人员。
情况2：验证缺陷没通过（不承认该bug），开发经理会拒绝（rejected）该bug。
步骤3：开发人员将指派的缺陷进行修改，改后将缺陷状态设置为：已修复（fixed）
步骤4:测试人员对已修复的bug，进行返测：
情况1：返测通过，测试人员将该bug关闭（closed）；
情况2：返测未通过，测试人员将缺陷重新激活（reopen），指派回该开发人员继续修改，直到缺陷返测通过，关闭为止。
（ c ） 问答
A. 测试人员提交的bug如果被开发方拒绝，测试人员应如何处理？
答：首先：自己要进行自检、自查；
其次:根据bug被拒的原因，去与开发、产品经理等沟通、协调工作。(必要时可以请测试组长出面协调）
最后：开发方拒不承认，那么可以向测试组长汇报情况，由测试组长出面，代表测试方沟通、解决。
结论:如果最后认定是假缺陷，测试方负责将该假缺陷关闭。如果最后认定是bug，开发方拒绝错误，谁拒绝的谁负责将缺陷激活，重新纳入回正常的缺陷处理流程。
B. Q1：用状态的变化表示缺陷的基本跟踪处理过程。: new–>open–>fixed–>closed
C. Q2: 用状态的变化表示:带有返测失败的缺陷跟踪处理过程。（返测失败1次）:new–>open–>fixed–>reopen–>fixed–>closed
D.Q5：缺陷报告的跟踪管理过程？
E.Q6：表示带有缺陷被拒绝的缺陷跟踪处理过程 :
真bug：new–rejected–open–fixed–closed
假 bug：new–rejected–closed
（9）缺陷的严重程度（severity）：表明该缺陷有多糟糕，对程序影响有多坏。
注意：缺陷的严重程度应专业准确判断，不要人为改变评级
严重程度级别：1-致命的-urgent（[ 非常严重–very high]–多数缺陷管理工具中没有该级别）
2-严重的-high
3-中等的-medium
4-建议性的小问题-low
问题提出：缺陷的严重级别的定义过于笼统，工作中会引起争议
解决问题：企业会制订缺陷严重级别定义的详细文档，测试人员在判定严重级别时必须要参照
提示：不同企业，甚至同一公司不同项目组，严重级别的详细定义都可能不同，要注意区分参考
（10）缺陷的优先级（priority）： 希望（建议）缺陷在什么时候或什么版本解决。注意：开发人员可以根据实际情况修改优先级。
优先级别的定义：1-立即解决-urgent（ [在本版本解决-very high ]少数缺陷管理工具中有该级别）
2-下一个版本解决-high（最常用）
3-软件产品发布之前解决-medium
4-尽量在产品发布之前解决-low（有可能有的bug是软件发布了还没有解决的）
问题：不同公司，不同项目组，优先级的详细定义不同，应注意参考。
与优先级和严重程度有关问答：
Q1：优先级的定义受哪些因素影响？
1）缺陷的严重程度，一般越严重，优先级越高。
2）缺陷影响的范围–影响范围越大，优先级越高
3）开发人员的开发压力，开发压力越小，优先级越高。
4）解决缺陷的成本（时间），成本越小，优先级越高
Q2：严重程度和优先级是严格成正比关系吗？
严重程度和优先级不是严格成正比关系，例如：界面错字，严重程度低，但是优先级高。
Q3：严重程度和优先级定好后能修改吗?
严重程度一般定好后，不能修改；优先级定好后可以修改，而且开发方经常延后。
Q4:在发布的软件产品中，是否可能存在发现但没有解决的bug？
有可能存在此类bug。 此类bug通常需要开“bug讨论会”，评估解决该bug的成本，和如果不解决是否会给用户带来严重影响，或引起法律诉讼。在权衡利弊后才可以决定。对于此类bug，软件企业通常会通过升级版本或者打补丁的方式在后期给与解决。
（11）缺陷描述（description）: 将发现缺陷的过程（步骤、数据）记录下来，使开发人员能重现该bug。
要求：逻辑清晰，用语专业、准确，易懂，不要出现任何评价性的语言。(如实记录）
总结–让开发人员能看明白。
通常企业的缺陷描述会有如下格式：步骤:
预期结果:
实际结果： - 缺陷报告总结：
1、缺陷报告作用？
1）缺陷报告能够记录缺陷
2）可以对缺陷进行跟踪管理
3）可以实现对缺陷的分类、统计、总结。
2、如何识别缺陷？
1）测试用例–实际结果与预期结果不一致就是bug
2）需求–当与需求不符时就是bug
3）缺陷的定义（5条）
4）与开发、产品、客户等沟通讨论，以确定bug。
测试用例–等价类划分法和边界值法
测试用例介绍
- 什么是测试用例？
也叫测试案例（test case/test instance）
在测试执行之前由测试人员编写的，用来指导测试过程的重要文档，测试用例主要包含：用例编号（标题），测试目的，测试步骤，预期结果等。 - 设计、编写测试用例的方法？（黑盒/功能测试方法有哪些？）
等价划分法；边界值；因果图/判定表 ；正交排列法；测试大纲法；场景法（应用最广泛）
测试用例的编写能力，是考察测试人员的基本技能 - 编写测试用例可以参考什么？
1）需求相关资源（有可能没有，例如：一些升级或者更新的项目，原始资料丢失，导致需求文档缺失）
2）核心的技术文档（有时测试方可能拿不到，例如：是外包的测试公司）
3）被测系统：是非常重要的参考资源，在实际应用中，可能只通过需求只能设计30%左右的用例，所以企业通常是需求结合被测试的系统完成用例设计。
4）可以通过与开发，产品，用户等沟通，讨论。（还可以通过对比同类优秀产品，查找网络资源等方式）
等价类划分法
- 应用场合（测试什么）
在程序中，有数据输入的地方就可以使用等价类划分法。将大量数据划分成若干范围，再从每个范围中挑选少数代表数据进行测试（抽样测试，高效） - 测试思想
1）穷举测试思想：就是将所有可能的数据，全部测试一遍
分析：穷举测试是最全面的测试，但是要测试大量的数据，测试花费时间长，效率低下
综上：在实际应用时，当测试数据量较大时，不应该选择穷举测试。
2）理想测试思想：能用最少的测试数据，达到最好的测试质量。（好的性价比）
分析：优化的测试思想，测试效率极高，但是毕竟没有测试所有数据（没穷举），可能有遗漏缺陷的风险
解决方案：在所有用例测试完成后，如果还有测试时间，应尽量进行补充测试，以降低遗漏缺陷的风险（不放心，纠结，随机等）
3）等价类划分的测试思想：
将大量数据划分成若干范围，再从每个范围中挑选少量代表数据进行测试
说明：每个范围的测试结果应该是一致的（等价的） - 测试步骤（测试人员身份）
被测系统：两位整数加法器
需求：第一个数和第二个数都要求是-99–99之间的整数，不能为空。
思路：每个控件单独测试（适合初学者）
先测“第一个数”，第二个数填正确的配合
再测“第二个数”，第一个数填正确的配合
步骤1：分析需求，初步划分等价类
等价类划分为：有效等价类：对程序来说，正确的，合理的输入数据集合（正确）–验证功能是否正确实现
无效等价类：对程序来说，错误的，不合理的输入数据集合（错误的）–验证软件的异常处理能力
以需求为依据：有效：-99–99之间的整数； 无效：为空、非整数、>99的整数、<-99的整数
步骤2：细化等价类
依据：不再以需求作为依据，而是以数据存储的类型或格式作为依据
1）细分1：非整数（常用）
小数、字母、中文字符、特殊字符（符号、空格等）；
整数的无效等价类（非整数），细分后： 小数、字母、中文字符、特殊字符
2）-99–99之间的整数（有效）
说明：整数类型在存储时使用“补码”方法，正、负整数的补码算法不同，所以需要分别测试。
细分后： -99–（-1）–负数； 0–99–正数
3）说明：无效的数据，没有存储的要求，所以没有必要细分成正、负两部分。（但是如果不放心作为补充测试，测一下也可以）
步骤3：将分析结果写入《等价类表》
步骤4：编写测试用例
提示：每个等价类中要至少挑选一个代表数据进行测试（为了保证每个等价类都被覆盖到）
总结：案例1：两位数加法器的问题
问题1、测试有效数据时，出现了用例冗余（重复）的问题。
问题2：无效数据的组合情况没有测试
例如：两个文本框都错
一个文本框错多种情况
但是，不需要将所有无效的组合情况全部测试，只需要挑选容易出问题，或者不放心的情况重点组合测试即可。–强化测试 例如:两个文本框都为空的情况，一般必须强化要测。
问题3：如果补充测试，额外发现了bug，该怎么做？
如果在补充测试中发现了bug，测试人员应对发现的bug提交缺陷报告，并且补充测试用例
说明：测试用例是可维护的技术文档，在测试过程中通过不断维护、完善用例，使测试覆盖更好，遗漏缺陷更少。
边界值法
说明：开发人员在编程时，边界的数据是很容易产生错误的，所以测试人员应对边界数据进行测试，可以采用边界值法实现
- 应用场合：程序中有数据输入的地方，可以使用边界值法测试。边界值法通常与等价类划分法配合使用，以形成比较完善的测试方案。注意：边界值和等价类划分经常配合使用，但是个别情况下也有可能不配合使用。例如： 性别：有效：男、女；无效：男、女之外的字符
- 边界值如何划分
1）边界值点：有效等价类和无效等价类之间的分界点就是边界值点（最小值min、最大值max）
2）次边界值点（4个）：边界值相邻两边的点就是次边界点；
（有效 min+/无效 min-）最小次边界
（有效 max-/无效 max+）最大次边界
3）问答：Q1：如果测试时间紧张，优先测试哪些边界值？最优先测试边界值点，就是最大值和最小值。
Q2：是不是所有数据的边界在需求中都是开始就定义好的？不一定，有一些数据的边界是在研发后，逐渐确定的。
Q3：年龄：18-60岁，划分边界值。18 ，60；19， 59；17, 61
Q4：工资：3000-20000之间的小数，小数位数最多保留小数点后2位（精确度0.01），划分边界值。 min：3000.00； max：20000.00； min+：3000.01； max-：19999.99；min-：2999.99；max+:20000.01；额外重点测试小数位数（精确度）的边界：最大值：小数点后2位，次边界：小数点后1位，小数点后3位 - 重点提示：等价类划分和边界值法应该配合使用，两者的目的不一样，一个侧重与检查每个范围（等价类），一个侧重于检查边界（边界值）。所以配合起来最完善
等价类划分+边界值： 步骤1：确定测试方法
步骤2：根据需求，对控件进行测试方法分析（单独），填《数据分析表》
步骤3：设计测试方案（思路），编写测试用例
因果图/判定表法
1.应用场合：界面中有多个控件，不同控件之间存在组合和制约（限制）关系，不同控件组合会对应不同的输出结果，可以使用因果图/判断表法，理清输入组合对应的输出结果是否正确
说明：因果图/判定表法适合测试控件之间组合数量较少的情况（一般少于20种）如果组合数量较多时，可以采用更优化的正交排列法
2.因果图
1）因果图解析： 因：输入条件；果：输出结果；因果图：就是用画图的方式，表示因（输入条件）和果（输出结果）之间的关系
2）图形符号
（1）基本图形符号：说明：表示因果之间的关系（双方）
（a）恒等（1个输入条件）：如果a=1，那么b=1；如果a=0，那么b=0；说明：1代表真（true）；0代表假（false） 
（b）与（至少两个输入条件）：含义：全1为1，有0为0
（c）或（至少两个输入条件）：含义：全0为0，有1为1
（4）非（1个输入条件）： 含义：相反，如果a=1，那么b=0； 如果a=0，那么b=1
（2）制约（限制）图形符号
说明：表示要么因要么果要么果之间的制约关系（单方面）
（a）互斥（E-EXCLUDE）：可以不选，如果选只能选一个选项
（b）唯一（O-only）：含义：有且仅有一个选择。问题：互斥和唯一的区别；唯一是必须要选1个，而互斥是可以不选
（c）包含（I-include）：含义：至少选择1项（不能不选，但是可以多选）
（d）要求（R-require）：含义：如果a=1，要求必须是1；如果a=0，那么b的值无所谓
（e）屏蔽（M-masked）：含义：如果a=1，那么b必须是0；如果a=0，那么b可以是1或0
3.测试步骤
案例1：
步骤1：熟悉需求，找出所有的输入条件（因）：
投币：50元 、100元
充值金额：50元、100元
1）投币50元
2）投币100元
3）充值金额50元
4）充值金额100元
步骤2：找出所有的输出结果（果）
1）充值成功并退卡
2）找零
3）错误提示并退卡
将找出的因和果填入《判定表》中
步骤3：分析输入条件中存在哪些组合或限制关系。
组合： 限制：
有：1个按钮、2个按钮 的情况 
步骤4：分析每个输入条件组合对应的输出结果，画因果图，填判定表（熟练之后画因果图可以省略）
填表时：选： 1或者T（true真）； 没选：0或者F（false 假）或者不填
说明：1）因果图只是进行分析辅助的工具，分析判定表，最终使用判定表可以进行用例的编写，而如果不画因果图也可以实现分析，并填判定表，那么在实践中就可以省略画因果图，直接填判定表，进而编写用例（画因果图反而可能会浪费测试时间）
2）判定表的缺点：判定表擅长表示组合关系，但是输入条件之间的制约（限制）关系，判定表很难表示。解决方案：可以在判定表中加入备注信息，将限制关系写在备注中
步骤5：编写测试用例：判定表中每一列，可以表示一种组合情况，编写一条用例
4.方法总结：
1）因果图/判定表法适合测试控件之间的组合情况，但是该方法适合测试组合数量较少的。
2）判定表法特点：
（1）输入条件（因）的顺序是无关紧要的。
（2）输出结果（果）的顺序是无关紧要的。
（3）先测哪个组合，后测哪个组合也是无关紧要的。
（4）每个组合情况都是相互独立的。（无需依赖其他组合）
3）判定表的组成
练习：
案例：工资发放系统（一种测试方法难以完成功能测试，所以在实际工作中经常会有2-4种测试方法综合使用的需求）
1.测试步骤：
步骤1：分析需求，确定测试方法；等价类+边界值，判定表法
步骤2：进行测试方法分析，将分析结果填表—《数据分析表》，《判定表》
步骤3：确定测试方案（思路），编写测试用例。
方案：
首先：（三个文本框）的有效数据 + 判定表（8种） 要组合测试
接下来：要单独测试每个文本框的无效数据
其他数据随机挑选正确数据配合即可
最后：要根据时间进行适当补充测试
1）全部文本框都为空的情况
2）本月工资覆盖多个无效情况
3）随机挑选数据补测
正交排列法
1.方法说明：正交排列法是依赖于“正交表”（工具）进行测试的测试方法。正交表是数学统计学专业的科研成果。提示：测试人员不需要研究如何填写正交表。只需要能够挑选合适的正交表，和能够应用正交表于测试就可以了
2.应用场合：界面中有多个控件，每个控件有不同的取值，不同控件取值之间存在组合关系，但是组合数量较大（成百上千），不应测试所有组合（效率低，穷举），可以使用正交排列法挑选最优，最少的组合进行测试。正交排列法是一种效率高，优化的测试方法（抽样测试）
问题：判定表法和正交排列法的异同？
1）判定表法和正交排列法都适合测试控件之间的组合情况。
2）测试组合数量较少时，比较适合使用判定表法（一般少于20种）–测试全面
3）测试组合数量多时，比较适合使用正交排列法（一般多于20种，成百上千）–效率高（优化）
4）判定表法测试时既要考虑控件之间的组合也要考虑控件之间的控制关系；但是正交排列法只需要考虑控件之间的组合情况即可
3.解析正交表公式
L：line行
n：代表该正交表有几行，n值已经计算好，固定使用即可
m：代表正交表每列的最大值
k：代表正交表有几列
4.如何利用正交表进行测试
案例：字符属性设置
步骤1：熟悉需求，将参与组合的控件和控件取值填入Excel表格。
步骤2：挑选合适的正交表
技巧：挑选合适的正交表，其实就是确定m值和k值得过程。
m值：由每个控件的取值个数决定。
k值：由参与组合的控（k开头）件个数决定。
应用： m值（取值个数）=3
k值（控件个数）=4
所以：要挑选3的4次幂的正交表。
步骤3：应用正交表
通过映射（替换），将正交表改造成能测试的表格。
使用excel的“查找和替换”功能实现映射（快捷键：Ctrl + H）
（1）将控件名称与正交表的“因子”部分 （正交表列标题）进行映射（替换）。
（2）将控件的取值与正交表对应列的“状态”（每列中的数值1,2,3等）进行映射（替换）。
步骤4：编写测试用例
每一行代表1个组合情况，可以编写1条用例进行测试。
5.总结
1）正交表的缺点（局限）
（1）正交表的数量有限（9个）
（2）正交表要求取值个数相同，但是实际应用中，控件的取值个数不一定都相同
2）正交表说明：正交表理论上已经将大量组合中最优、最少的组合筛选出来，是一种非常优化的测试方法，但是毕竟没有测试所有组合，有可能有遗漏缺陷的风险，所以如果时间允许，应该适当进行补充测试，以降低风险。
3）正交表特征：平均（均匀）
（1）每一列的数值，出现的次数都是均等的
（2）任意两列，同一行会形成1个有序数对，每个有序数对出现的次数均等
4）如果没有合适的正交表要如何解决
（1）k值不合适：解决方案：挑选k值最接近的，并且大一点，用不到的列删除即可
（2）m值（控件的取值个数）不同：当不同控件的取值个数（m值）不同时，可以采取：方案1：少数服从多数， 分析： K=4, M=3 (m=3的有两个控件，最多，所以m=3） 所以：挑选 3的4次幂的正交表；方案2：最大值分析： k=4， m=4（m=4的是最大取值）， 所以：应该选择4的4次幂的正交表，但是没有，所以最终选择：L16（45）的正交表，用不到的1列可以删除。
建议使用最大值方案：
（a）少数服从多数需要改变表结构。
（b）最大值方案相对来说测试质量会更好（测的组合更多，覆盖更高）
（3）总结： （a）如果有多出的列可以删除。
（b）先替换能替换的
（c）多出的测试机会（空），应尽量均匀的分配给该列的取值。
（d）最后检查是否有完全相同的两行，如果有要适当处理（删、改）
（e）提示：选择正交表时最优先的是挑选正合适的正交表，如果没有正合适的，再应用方法解决。
补充：正交排列法常用于测试：属性设置（字符、打印等）功能或者软件的兼容性测试等。
测试大纲（提纲）法
1.应用场合：软件中有多个窗口，每个窗口中有若干操作，不同窗口操作间存在关系，为了理清窗口之间的关系，使用测试大纲法，该方法常用于测试：多窗口之间的跳转关系，软件的安装和删除程序，理清需求点之间的层级关系等
2.测试步骤
步骤1：分析需求，列大纲–列出窗口以及窗口中的操作点（功能点），注意：列窗口的时要注意窗口的层级关系（出现的顺序）
步骤2：根据大纲，理清窗口之间的关系，编写用例
1）思路：通常会选择简单的功能点进行测试（由易到难）；先测帮助 -->地图–>专卖店
2）如果在当前的窗口间测试路线中，所有的功能点在之前的用例中都测试过（没有未测功能点），那么该条路线可以省略不测。但是如果时间充足，最好还是测一下（可以不写用例）
3）测试“下拉列表框”或者“列表框”时，一般至少测试3项：第一项，中间某项和最后一项
3.编写测试用例
1）当测试“下拉列表”，“列表框”控件时，至少要测试3项：第一项，中间某项，最后一项
第一项 ：最小值（边界值法）
最后一项：最大值（边界值法）
中间某项：有效等价类（等价类划分法）
例如：测试月份
思路：最小值（1月）；最大值（12月）；闰月（2月）；大月（1月或12月）；小月 （例如：4月）；如果有“为空”的情况应单独测试。
2）如果测试过程一样，那么可以考虑重用（复用）用例，注意：虽然用例复用了（用例可以不重复写），但是用例的执行过程必须要按要求执行，并记录结果，不能也跟着重用了（不能省）
3） 测试大纲法的经典应用：测试snagit软件的安装程序
（1）安装程序测试的特征
（a）软件安装程序窗口比较多，但是窗口之间关系比较简单，主要就是“上一页”和“下一页”
（b）软件的安装程序测试，用例通常以列大纲的的方式写在word文档中即可，比较简洁
（c）软件安装程序的安装环境：系统（OS）的兼容性–品牌，版本，位数（64位或32位）
与其他应用软件的兼容性–杀毒软件，输入法等
安装路径：默认路径（一般指向系统路径）
自定义路径（正确，错误）
（d）如果计算机中已经安装了该软件，安装程序一般会给出哪些选项？ 覆盖、更新升级、取消、不允许
场景法
1.应用场合：
1）场景法是应用最为广泛的测试方法，常被用来测试软件的业务过程和业务逻辑
2）场景法基于“软件业务”的的方法
3）测试人员将自己当成是最终用户，尽可能多的模拟用户使用软件的各种情景，主要模拟两种情景
（1）模拟正确的业务实现过程–验证软件功能是否实现
（2）模拟错误的业务实现过程–验证软件的异常处理能力（健壮性）
2.场景法基于两个层面
1）基于“业务层面”（更为重要）：要求测试人员对被测系统的业务非常熟悉，最好能成为该行业“业务”的“专家”
2）基于“技术层面”：（1）基本流：也叫正确流或者有效流，模拟正确的业务实现过程
（2）备选流：也叫错误流或无效流，模拟错误的业务实现情景。
3.场景法应用的思路：测试人员拿到测试任务时，首先应该对功能的整体业务流程或业务逻辑进行测试（使用场景法），当确认整体业务没有问题后，再对细节展开测试（应用等价类，边界值，判定表等）–先测整体业务，再测细节
4.场景法的测试步骤
说明：场景法的要点和难点是业务的理解和分析，业务越复杂，难度越大。
案例1：ATM取款 （业务熟悉）
步骤1：熟悉需求，整理业务（流程、逻辑） ，列出基本流或备选流。
1）基本流（有效流）–取款成功的业务过程
验证卡→输入正确密码→选择“取款”功能，选择取款金额→出钞，给出提示信息，更改余额等
2）备选流（无效流）–取款失败的业务过程
（1）验证卡失败
（2）密码错误3次以下
（3）密码错误3次–锁卡并吞卡
（4）余额不足
（5）超出当次取款上限-5000元
（6）超出当日取款上限–20000元
（7）ATM机余额不足
步骤2：填《场景表》
案例2：五子棋游戏测试
步骤1：熟悉、分析需求，整理业务,填《场景表》
补充需求： 电脑如果是黑棋（电脑先），电脑不允许下出禁手，如果电脑作为黑棋下出禁手就是bug。
整理业务：玩家先（玩家黑棋）： 玩家胜；玩家负；和棋；黑棋遇到禁手位–；避开：继续行棋；没避开：判负
电脑先（电脑黑棋）：电脑胜；电脑负；和棋； 电脑（黑棋）：遇到禁手位必须避开，否则就是bug。
步骤2：根据场景（测试用例）执行测试，记录测试结果。（通过记录证迹（截图或视频）+说明）
注意事项：
1）截图时如果有提示信息遮挡有效数据，请移动它，不要遮挡任何有效信息。
2）尽量截取整个界面，不要只截局部，尽量提供全部相关信息。
案例3：美萍酒店管理系统
1）测试准备：被测系统：美萍酒店管理系统
（1）测试环境搭建
（2）准备测试数据
2）被测功能–删除房间类型
步骤1：熟悉、分析需求，整理业务，填《场景表》
需求：删除房间类型与房态和服务生有关。
影响房间类型删除的因素有两个：
房态【单独】：（1）如果房间类型中所有房间都没人住 ，房间类型可以删
（2）如果房间类型中有房间有人住（哪怕一间房），房间类型都不能删除
服务生【单独】：（1）如果分配有服务生的房间类型， 不能删除
（2）如果没有分配服务生，可以删除
综合考虑房态和服务生两个因素,整理业务：
能删：没人住+没服务生
不能删：有人住+没服务生
没人住+有服务生
有人住+有服务生
有人住：占用、长包房、预定
没人住：可供、停用、清理
步骤2：根据场景，设计、编写测试用例。
测试理论基础
1.软件的开发阶段划分
1）需求分析阶段：需求分析人员完成–《需求规格说明书》
2）概要设计阶段：一般由系统架构师/分析师完成–《概要设计说明书》
3）详细设计阶段：一般由系统架构师/分析师完成–《详细设计说明书》
4）编码阶段：由开发人员完成–产出物：程序
2.软件测试阶段划分（该阶段划分并没有包含需求和设计阶段的测试过程）：
1）单元测试：（1）单元测试是整个测试过程中的最小测试单元，通常一个窗口，功能模块，方法，函数，类等，都可以作为一个测试单元。
（2）单元测试主要参考详细设计文档
（3）单元测试理论上使用白盒测试方式
补充：公司实际进行单元测试时，由于白盒测试人员进行单元测试的成本过高，所以为了节省成本，通常选择让开发人员做单元测试（白盒测试）；但是开发人员做单元测试，测试质量得不到保证，所以企业通常采用以下两种方式解决：（a）交换互测（b）两轮测试：第一轮开发人员用白盒方式测，第二轮测试人员再用黑盒方式测试。
（4）驱动模块和桩模块
说明：在单元测试阶段，测试者经常要编写驱动模块和桩模块
驱动模块：模拟被测模块的上一级模块（调用被测模块的）
桩模块：模拟被测模块的下一级模块（被"被测模块"调用的）
总结：驱动模块→被测模块→桩模块
2）集成测试（组装测试）
（1）集成测试阶段也叫组装测试阶段。是将程序的各个模块，逐步组合在一起的测试过程
（2）集成测试是在单元测试的基础上进行的测试过程
（3）集成测试过程中，程序不是一蹴而就的，而是各个功能模块逐步合并在一起，在逐步组装过程中可能会形成若干临时版本
（4）集成测试阶段主要参考概要设计文档
（5）集成测试阶段主要以黑盒测试方式进行，但是一些重点，难点功能，和一些核心功能模块会辅助以白盒测试方式
（6）冒烟测试（也叫版本验证测试）：
当测试组接到一个新的测试版本时，通常会做”冒烟测试“–冒烟测试由较少的人（2-3人，经验丰富），花费较少的时间（0.5-2天），对所测版本的核心功能，进行快速测试，如果核心功能没有问题，那么全组展开全面测试；如果核心功能问题较大，版本不稳定，那么测试方拒绝该版本，退回开发组
（7）集成测试阶段，拿到一个新版本后的测试思路如下：
首先：冒烟测试–验证该版本是否可以接受测试
接下来：返测–验证已修改的bug是否已经修复成功。
回归测试–对上个版本测过的所有功能，再重新测试一遍。
最后：对新增加的功能进行测试。（有的特殊版本，是专门用来修复bug的，这样的版本就没有新功能需要测试。）
说明：以上为集成测试的基本工作思路，但是实际情况中，这些工作不一定都需要。
3）系统测试
（1）当软件组装完成后，对模拟真实环境下的完整系统进行的测试过程
（2）系统测试阶段的测试重点：（a）系统的兼容性测试（b）在模拟真实环境下，整个系统功能是否正确运行
（3）系统测试阶段：参考需求文档
（4）系统测试阶段使用黑盒测试方式进行测试
（5）确认测试：说明：在系统测试之前，通常会做一次“确认测试”
确认测试要负责确认两个内容：（a）确认整个系统是否已经可以进入全面的系统测试阶段（b）确认文档是否齐全，尤其是交付给用户的文档与认证的文档
注意：确认测试阶段由于测试时间相对较短，参与人员相对较少，从规模上无法与其他四个测试阶段相提并论，所以通常不把确认测试阶段与单元、集成、系统、验收等测试阶段并列。
4）验收测试
（1）在公司中，通常将验收测试简称为UAT（User Acceptance Testing）翻译为“用户接受度测试”
（2）验收测试阶段：是需要有用户参与，对软件进行检查的测试过程
（3）分为两个小的测试阶段：（a）Alpha测试阶段：在软件公司指定的环境中（软件公司对所发现的bug有很强的控制力），理论上是由用户对软件进行检查。补充：实际情况中，用户有可能无法亲自进行alpha测试，通常会由软件公司找测试人员替用户完成，也有的用户会自己请第三方测试机构替自己完成alpha测试。（b）Beta测试阶段：beta测试在最终用户的使用环境中进行（软件公司对bug的控制力将极大削弱，软件公司收集bug的难度和成本都将增大），由最终用户对软件进行检查。例如：公共类软件（OS，网络游戏，输入法，qq等）就是将被测软件免费发放给最终用户，通过收集用户使用软件过程中，产生的bug，来进行beta测试。
3.软件测试的模型
（1）软件的测试模型能够表示开发阶段和测试阶段（级别）之间的对应关系。例如：V模型（重点）、W模型、H模型等
（2）介绍v模型
（a）会画v模型
（b）v模型的优、缺点
优点：
l v模型能够清晰，明确的表示开发阶段和测试阶段（级别）。–阶段划分明确
l v模型能够清晰、明确的表示开发阶段和测试阶段（级别）的对应关系。
l 测试阶段既包括最底层的单元测试（代码级、专业级），也包括最顶层的验收测试（用户级、界面级）。–测试级别涵盖全面。
缺点：
l v模型中缺少了需求和设计阶段的测试内容。
l 不能体现出尽早测试和不断测试原则
l 容易造成误解测试工作只是开发工作的收尾
3）w模型
（1）w模型可以看成是双v模型，第一个v是完整的‘开发活动’，第二个v是完整的‘测试活动’。
（2）与v模型相比，w模型增加了需求和设计阶段的测试内容，更符合尽早测试和不断测试原则；体现出开发和测试是同步进行的，平行的两个过程。
4.软件测试的分类
1）按照测试技术划分：
（1）黑盒测试：也叫功能测试，就是不关注内部的程序结构，在已知输入和输出时，对功能实现情况的测试
（2）白盒测试：不关注程序的外部功能，而是主要关注程序的内部结构的测试方式
（3）灰盒测试：结合了黑盒测试和白盒测试的要素进行测试的方法，一般先用黑盒测试发现bug，再由白盒测试进一步的对bug进行调查（在集成测试阶段，比较常用灰盒测试）
补充：白盒测试：白盒测试的质量较高，但是白盒测试效率低，成本高；白盒测试人员必须要懂编程；白盒测试也是需要编写测试用例的。
2）按测试时是否需要运行软件进行分类：
（1）静态测试：不需要运行程序就可以进行的测试；例如： 文档测试； 界面测试（UI测试）；（静态）代码测试：就是检查代码是否符合一定的标准和规范。
（2）动态测试：需要运行程序才可以进行的测试 。例如：功能（黑盒）测试是动态测试； 特殊：白盒测试有可能动态，也有可能静态。
（3）问答：（静态）代码测试和白盒测试有什么区别？（a）白盒测试：测试代码的结构和实现逻辑；要求测试人员必须要懂编程；并且测试人员需要编写测试用例（b）代码测试：测试的是代码是否符合一定的标准和规范；代码测试不要求测试人员懂代码；代码测试不需要测试人员编写测试用例，只需要对照检查单进行测试即可
3）按测试结构分类
（1）功能测试：（a）所有的软件都需要先进行功能测试（b）功能测试分为手工测试和自动化测试
（2）性能测试：（a）分布式软件（B/S,C/S）需要做性能测试。（b）性能测试只能依赖工具进行自动化测试，不能手工实现性能测试
4）其他（名词、术语）
（1）返测
（2）回测（回归测试）
（3）兼容测试
（4）随机测试（猴子测试）
（5）软件项目的测试流程
（6）功能测试方法的测试策略
来源：CSDN
作者：Miss.wang
链接：https://blog.csdn.net/weixin_45877955/article/details/104573215