1、软件测试的定义:
IEEE给出的定义——
软件测试是使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。
《软件测试技术基础》——
软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。
2、软件测试的目的
软件质量:
1.发现系统的错误
2. 验证系统是否满足需求
3. 为产品放行提供依据
4. 改进开发流程
对于企业来说：
回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
测试的重要目的之一：发现软件中的缺陷
3、软件测试对象
阶段性文档(1 2 3):
1需求规格说明书 2概要设计规格说明书 3详细设计规格说明书
4源程序 5系统
最终产品文档(6 7):6用户手册 7帮助文档
4、软件质量保证人员与软件测试人员
同：两个岗位旨在提高软件的质量
异：软件测试人员SQC
1关心过程的产物2剖析开发出的软件
质量保证人员SQA
1全面质量管理 2过程改进
5、软件测试的原则
1.所有的软件测试都应追溯到用户需求
2.尽早地、不断地进行测试
3.严格执行测试计划
4.注重测试用例的设计
5.程序员应该避免测试自己的程序
6.增量测试，由小到大
7.注意集群现象(二八定理)
8.完全测试是不可能的
9.测试维护
集群现象（二八定理）Pareto原则：测试发现的错误中80%很可能起源于20%的模块中。
6、测试用例
IEEE标准610（1990）的定义：
测试用例是一组测试输入、执行条件和预期结果的集合。其目的是要满足一个特定的目标，比如执行一条特的程序路径或检验是否符合一个特定的需求。
一组测试用例包含：1、用例的编号 2、测试标题 3、用例级别 4、预置条件
5、操作步骤 6、预期结果
7、软件测试环境
软件测试环境= 软件+ 硬件+ 网络+ 历史数据
8、软件缺陷
软件从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都可能产生和发现缺陷。
需求阶段最多，运行维护时花费代价最高。
9、软件测试分类
1）、按测试技术上分类（是否查看代码）
黑盒测试：在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规 定正常用。也被称为功能测试或数据驱动测试。
白盒测试（测试代码）：要完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。也被称为结构测试或逻辑驱动测试。
灰盒测试：介于黑盒测试与白盒测试之间的测试，即要像黑盒测试那样关注输出对于输入的正确性；同时也关注内容表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志判断内部的运行状态。避免过度测试，精简冗余用例。
2）、按测试方式上分类（是否运行程序）
静态测试：是指不运行程序，对程序和文档进行分析与检查；静态测试技术又称为静态分析技术。
动态测试：通过运行程序进行检查、分析程序的执行状态和程序逻辑的外部表现
3）、按测试阶段分类
单元测试：单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作。包括对每一行代码进行基本测试。（白盒）
目的：主要是测试模块在语法、格式和逻辑上的错误。
集成测试：集成测试也称为组装测试，集成测试按设计要求把通过单元测试的各个模块组装在一起之后所进行的测试。(黑灰盒)
目的：检查模块间的接口关系，以便发现与接口有关的各种错误
系统测试：系统测试是将已经集成好的软件系统置于实际运行环境中所进行的测试。（黑盒为主）
目的：根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。
验收测试：为了检验接受测试的系统是否满足需求。用户也参与进来，（黑盒）
目的：验证软件功能的正确性和需求的符合性。
4）、按测试实施组织分类
开发方测试：开发方测试也称内部测试，主要指在软件开发完成后，开发方要对提交的软件进行全面的自我检查与验证，验证软件的实现是否满足软件需求说明的要求。
用户方测试：用户方测试是在用户的应用环境下，由用户通过运行和使用软件，验证软件实现是否符合自己期望的要求。由用户找出软件的应用中发现的问题与缺陷，并对使用质量进行评价。
第三方测试：第三方测试又称为独立测试，由在技术、管理和财务上和开发方和用户方相对独立的组织进行的测试。软件质量工程强调开展独立的验证和确认工作。一般找一个别的公司。
5）、按软件的质量特性分类
功能测试、性能测试、压力测试、用户界面测试、安全测试、可靠性测试、安装测试、兼容性测试、
10、软件测试什么时候开始
尽早开始，贯穿整个生命周期。
软件生命周期被划分成了若干个阶段：
可行性分析与项目计划、需求分析、系统设计、编码、调试、测试（执行）、维护升级到废弃等阶段。
11、测试数据文档
需求文档、缺陷报告、测试用例、测试计划方案
简单选择判断：
完全的测试是不可能的
原因：软件太复杂，资源不容许，“杀虫剂现象”等等。
措施：
需要根据实际情况来决定资源的分配，对测试程度和
范围进行有效的控制，只有这样才能投入最少的成本
获得最大的回报。
不能修复所有的软件故障
原因：没有足够的资源进行修复 修复的风险较大 不值得修复
结论：关键是要进行正确的判断、合理的取舍根据成本和风险分析决定哪些必须修复，哪些可以不修复
经验1：没有经过自己验证的问题，不要轻信
经验2：测试人员要始终站在用户的角度去看问题
经验3：必须基于“质量第一”的思想去开展工作
经验4：修复缺陷后，一定要进行回归测试
软件质量
软件的一些质量特性的组合，反映了软件满足用户需求的程度。[规定或隐含的需求]
瀑布模型
开发阶段包括计划、需求分析、设计、编码、测试和运行维护。
2章 黑盒测试（3个简答，黑盒测试设计）
1.黑白盒测试的定义及区别 （简答）
黑盒测试（Black-box Testing）又称为功能测试。
黑盒测试就是把测试对象看做一个不能打开的黑盒子，在完全不考虑程序的内部结构和处理过程的情况下，只依据程序的需求规格说明书， 检查程序的功能是否符合他的功能说明。
Ps: 关注程序外部结构，不考虑内部逻辑结构，不知道程序如何工作。
注重软件的功能性需求，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的，又称为数据驱动测试。
黑盒测试是在程序外部接口进行的测试。
白盒测试也称结构测试或逻辑驱动测试，通过了解软件系统的内部工作过程，设计测试用例来检测程序内部动作是否按照规格说明书规定的正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作。
白盒测试旨在使测试充分地覆盖软件系统的内部结构，并以软件结构中的某些元素是否都已得到测试为准则来判断测试的充分性。
2.黑盒测试发现的主要错误类型（简答）
1）功能错误或遗漏； 2）界面错误； 3）外部数据库访问错误；
4）性能错误； 5）初始化和终止错误。
黑白盒的测试方法 （简答）
黑盒测试方法：①等价类划分法 ②边界值分析法 ③判定表法 ④因果图法 ⑤场景法
白盒测试方法：①逻辑覆盖法（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖）、②基本路径测试
等价类定义：等价类是指某个输入域的子集合。
在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
测试某等价类的代表值就等价于对这一类其 它值的测试。
等价类划分法步骤
（1）划分等价类（有时需要细化） （2）建立等价类表，等价类进行编号
（3）通过等价类导出测试用例
从划分出的等价类中按以下原则设计测试用例:（选择）
（1）编号唯一 （2）尽可能多地覆盖尚未覆盖的有效等价类
（3）仅覆盖一个尚未覆盖的无效等价类 （4）覆盖所有的有效和无效等价类
等价类例题 （设计题）
对于函数F（X,Y）,其输入变Y的取值边界定义如下： X ∈ [a，b）∪ [b，c） ∪ [c，d] ； Y ∈[e，f）∪ [f，g] 可得到X,Y的等价类如下表
试用前述几种等价类测试用例设计法设计测试用例
边界值分析法定义
对输入或输出的边界值进行测试的一种黑盒测试方法。
是作为对等价类划分法的补充，这种情况下， 其测试用例来自等价类的边界。
边界点分为上点（边界上的点）、内点（域范围内的任意一个点）和离点（离上点最近的一个）
边界条件设计测试用例步骤
（1）确定边界情况（2）选取测试数据（3）导出测试用例
边界值分析法例题
程序的规格说明中规定：“重量在10公斤至50公斤范 围内的邮件，其邮费计算公式为……”。
（1）测试数据应取10及50，还应取9.99，10.01, 49.99及 50.01等。
(2)
判定表定义
判定表（也称决策表）是一个用来表示条件和行动的二维表，是分析和表达多逻辑条件 下执行不同操作的情况的工具。
Ps: 等价类划分法和边界值分析方法比较适合输入变量或输入条件相互独立的情况，但是当输入变量或输入条件相互依赖、相互制约的时候，采用等价类划分法和边界值分析方法是难以描述的，测试效果也很难保障。
在所有的黑盒测试方法中，基于判定表的测试是最为严格、最具有逻辑性的测试方法
判定表的建立步骤
（1）列出所有的条件桩和动作桩 （2）确定规则的个数
（3）填入条件项 （4）填入动作项 （5）简化判定表
规则公式
①有限条件桩：2的n次方（n条件桩个数 ②扩展条目：每组取值个数相乘
判定表例题（设计题）
我们可以通过分析三角问题的处理过程（即“业务逻辑”）得到：
当判断出a=b=c时，程序输出“等边三角形”。
当判断出a=b或b=c或a=c时，程序输出“等腰三角形”。
当a!=b且b != c且c !=a时，程序输出“一般三角形”
（1）列出所有的条件桩和动作桩：C1:a,b,c构成 三角形? C2:a=b? C3:a=c? C4:b=c?
A1:非三角形 A2:一般三角形 A3:等腰三角形 A4:等边三角形 A5:不可能
（2）确定规则的个数 2ˆ4=16
（3）填入条件项，填入动作项
（5）简化判定表 （6）设计测试用例
①对每一条规则设计一个测试用例
②去掉不存在的情况
因果图法定义
因果图法（Cause-Effect Graphics） 是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。
因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
原因：输入条件 结果：输出
因果图法例题+步骤
某软件的一个模块的需求规格说明书中描述：
（1）年薪制员工：严重过失，扣年终风险金的4%； 过失，扣年终风险金的2%。
（2）非年薪制员工：严重过失，扣当月薪资的8%； 过失，扣当月薪资的4%。
请绘制出因果图和判定表，并给出相应的测试用例
（1）分析原因和结果 （2）画出因果图
（3）施加相应的约束 （4）将因果图转化成决策表（判定表）
（5）设计测试用例
因果图的约束符号
1）输入条件的4种约束
①E约束（异/互斥Exclusive）：几个原因不会同时成立，可能他们都不成立，但最多有一个成立
② I约束（或/包含In）：表示几个原因中至少有一个必须成立，当然也 可能都成立。
③O约束（唯一Only）：表示几个原因中必须有且仅有一个成立
④R约束（要求Request）：表示当a出现时，b必须也出现。
2）输出条件的约束类型
①M 约束（屏蔽Mandate）：表示当a是1时，b必须是0； 而当a为0时，b的值不一定
场景法定义
场景法就是通过用例场景描述用例执行的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。
18.场景法例题+步骤
需求规格说明： 用户在一个在线购物网站购物，需要成功登录 到系统，选购后在线购买，在线上支付。支付成 功后生成订单，完成整个购物过程。
（1）画出路径流程图
（2）描述出基本流和备选流
（3）确定用例场景
（4）生成测试用例
V（Valid有效的）表明这个条件必须有效才可执行基本流；
I（Invalid 无效的）表明这种条件下将激活所需备选流；
“N/A”（不适用）表明这个条件不适用于测试用例。
（5）设计测试数据
（6）测试用例的补充