软件组成：
软件的分类
软件缺陷的由来
所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷
软件缺陷的定义
软件测试的由来
正向思维
反向思维
IEEE定义的测试
广义软件测试定义
确认（Validation）：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现
验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足
| 测试 | 调试 | |
|---|---|---|
| 主体 | 测试人员 | 开发 |
| 目标 | 找bug | 将错误修改正确 |
| 方法 | 等价类、边界值… | 程序和逻辑算法 |
| 思路 | 反向思维 | 正向思维 |
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
基于软件危机对于计算机发展的阻碍，1968年，在联邦德国召开的国际会议上，北大西洋公约组织的计算机科学家讨论软件危机问题。提出了软件工程这个名词，从此软件生产进入工程化时代。
软件工程包括两方面的内容：
引起软件危机的主要问题是软件质量问题；
软件工程主要解决的就是软件质量问题；
软件测试是软件质量管理体系中一个非常重要的手段
需求分析、概要设计、详细设计、编码、测试、验收
1、瀑布模型
最早提出的软件开发的过程模型
优点：
缺点：
2、快速原型模型
应用领域越来越多
原型：就是一个模型，可以模拟操作、简单运行
典型应用和工具：Axure 制作原型
3、增量模型
把软件分割成独立的模块，分批次的完成和交付
缺点：打破原有的软件结构和框架，可能会带来一定的风险
增量模型一般会和迭代模型一起运用
1）软件增加了新功能
2）优化了…功能
3）修复了某些未知/已知的bug
4、迭代模型
迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他元素，强调开发的深入；在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试流程。
优点：
5、螺旋模型
螺旋模型是一种演化软件开发过程模型，它兼顾了快速模型的迭代的特征以及瀑布模型的系统化与严格监控
获取测试需求–>编写测试计划–>制定测试方案–>开发与设计测试用例–>执行测试–>提交缺陷报告–>测试分析与评审–>提交测试总结–>准备下一版本测试
测试过程的质量将直接影响测试结果的准确性和有效性
揭示了开发过程与测试过程中各阶段的对应关系
优点：每个阶段比较清楚，测试过程由底层（代码）测试到高层（应用）测试过程
缺点：
由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
优点：
局限性：
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
H模型揭示了一个原理：软件测试是一个独立的流程！
软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，也可以反复进行。
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
1.按照开发阶段划分
2.按照代码运行划分
3.按照软件特性划分
4.按照测试技术划分
5.其他测试类型
6.按照测试运行主体划分
简单地说，测试用例就是：
设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果（为了特定的目的而设计的一组测试输入，执行条件和预期结果构成的文档）。
如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内
软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。
测试用例（Excel）应该包含以下内容：
标识符（用例编号）：由测试设计过程说明和测试程序说明引用的唯一标识符。一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体，还要指出引用的产品说明书或者测试用例所依据的其他设计文档。测试用例的测试目的，必须是确定的，可以不写目的产生的结果，测试目的决定了测试步骤和预期结果，一般情况下，用一句话表明目的（表明测试模块、测试对象、方式、事件）。例如：使用谷歌浏览器打开百度首页；在QQ登录界面输入正确的用户名密码能登录上。
依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例（已经存在的测试用例），用例依赖可以跨越模块（A设计员可能会依赖B设计员的测试用例）。例如：增加了一个数据的测试用例，将会被删除该数据的测试用例依赖
测试步骤：用最朴实的语言，写出软件的操作步骤，表明操作的对象和方式，数据，要尽量详细。例如：在用户名文本框输入：XXX；在省份下拉列表选择：北京 城市下拉列表选择：北京
测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致；没有数据，空着不写。例如输入要求不为空，不输入就不写（须在测试项中标注某一个内容为空）；如果要对空格进行测试，不要将空格放在数据的最前面或最后面（123 456）
预期结果：准确（对象的准确、内容的准确），原则上每一个操作都要有一个结果，在重要的步骤之后，设定预期结果，一般和测试目的密切相关。例如：页面跳转到XXX；程序弹出对话框，提示用户名或密码错误，请重新输入！
测试结果：要求在测试执行完成后添加，没有执行保持为空。测试结果只有两个：通过（Pass）/ 失败（Failed），和预期结果一致即为通过，不一致即为失败
测试人：测试的执行人，可以和设计者相同，也可以不同
备注：为了测试用例正常执行而做的特殊准备。例如：专门制造网络不畅情况下，软件错误提示
输入说明：该说明列举执行测试用例的所有内容或者条件
输出说明：描述进行测试用例预期的结果
环境要求：指执行测试用例必要的硬件、软件、测试工具、人员等
特殊要求：描述再执行测试必须的特殊要求
用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明
用例按照测试分类：
功能（Function）
界面（UI）
性能（Performance）
安全（Security）
接口（Interface）
用例设计和编写的作用
1、等价类划分法原理
把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。把每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。
2、等价类划分法设计步骤
确定等价类的原则：
3、应用场景
针对需要有大量数据测试输入，但是没法穷举测试的地方。如：有输入框、下拉列表、单选复选框等，需要同时提交，对于每种输入都需要大量测试输入验证。
典型代表：页面级的输入框类测试
4、等价类划分法
①划分等价类和列出等价类表
例：
②确定测试用例
如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据；如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1得数作为测试数据；分析规格说明，找出其他可能的边界条件
边界值只是一个特定的数据。例如，文本框需要输入6~18位字符
边界值有：6个字符；18个字符
次边界：边界附近的值，按照系统规定的单位或计算方式，一个数据的差异。
例如，字符就是个，一个字符，没有半个字符的说法；人民币金额，最小单位是0.01元（1分），ATM机取款和存款，最小单位就是100元，只能是100元的整数倍
思考：
1）6≤x≤18，测试中x的边界值要选取哪几个进行测试？（5，6，7，17，18，19）
2）6＜x＜18，测试中x的边界值要选取哪几个进行测试？（6，7，8，16，17，18）
3）文本框输入字符的个数要求是不大于150字，测试时如何选择边界值？（0≤x≤150，空，1，149，150，151）
上点、内点（中间取值）
离点优化：开内闭外
边界值的选择原则
1、什么是因果图
因果图法是一种适合于描述对于多种输入条件组合的测试方法。
根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法。
它适合于检查程序输入条件涉及的各种组合情况。
2、因果图的符号
第一步：根据功能说明书中规定的原因和结果之间的关系画出因果图（一般左边是原因，右边是结果）
第二步：根据功能说明在因果图中加上约束条件
其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束，它们的含义如下（假设原因成立用1表示，不成立用0表示）：
阅读和分析功能说明书，识别出”原因“和”结果“，并加以编号
1、分析原因和结果
2、根据需求分析画出原因和结果之间的关系（部分关系），并进行关系的连接
3、按照需求描述原因、结果之间的约束
因果图使用中的局限性：当原因和结果很多的时候，它们之间的关系连线就会很多，导致因果图的可读性变差。因此用作局部的小功能（原因和结果不是很多的时候）分析。
因果图优势：能够发现设计中存在的不足
4、列出所有的原因和结果的列表，设计初步的测试用例步骤
将因果图中的每一个分支用表格列出来，而列表中的每一列都是一条测试用例
C5、C6、C7：这是一种bug，不能做测试设计
经过分析发现：
1）只选择饮料，没有投币的时候，软件没有任何结果
2）只投币，没有选择饮料的时候，软件没有任何结果
3）不能把软件的缺陷设计成测试用例
1、什么是判定表法（判定表驱动法）
是分析和表达多逻辑条件下执行不同操作地情况的工具。
应用场合：主要适用于多条件的内容组合与结果分析
它由以下几个内容组成：
3、判定表使用实例
1）分析条件和动作
| 条件1 | 条件2 | 动作 |
|---|---|---|
| 金额>500 | 未过期 | 发出批准单、提货单 |
| 金额>500 | 过期 | 不发批准单 |
| 金额≤500 | 未过期 | 发出批准单、提货单 |
| 金额≤500 | 过期 | 发出批准单、提货单、通知单 |
2）写入条件桩、动作桩、条件项、动作项
判定表
3）对判定表进行简化和优化，对其中不合理或重复的进行取舍
无论金额高低，只要未过期，都会发批准单和提货单（在测试时间不充足的情况下，可以选二者中的一个情况进行测序；在测试时间充足的情况下，每一个都要测试），所以优化之后，条件项就减少为3个
4）将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果
4、适合使用判定表设计测试用例的条件
测试用例的设计方法：没有哪一种方式是单独使用
1）所有的软件，都是因为某种操作才会导致一定的结果。–考虑使用因果图
2）所有的软件都有文本框。–考虑必须一定使用等价类、边界值
1、场景法基本原理
现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
基本流：软件功能按照正确的事件流实现的一个正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流：除了基本流之外的各支流，包含多种不同的情况。
2、场景列表：
注意：
3、设计用例的步骤
场景法适用于解决业务流程清晰的系统或功能
案例：ATM机取款
基本流：插卡–输入密码–选择取款金额–等待出钞–取卡
备选流：
1、卡不是银行卡
2、卡不是银联的卡
3、密码输错一次
4、密码输错两次，第三次输入正确
5、密码输错三次，冻结账号或吞卡
6、选择存款服务
7、选择查询服务
8、选择转账服务
9、选择修改密码服务
10、选择取款金额100、200、…
11、选择其他金额
12、账户余额
13、ATM机没钱了
14、账户取款金额达到取款机的当日取款上线
15、账户取款金额达到账户当日取款交易上限
16、取款机掉线
17、取款机停电
18、…
场景设计
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流5
场景4：基本流 备选流4
场景5：基本流 备选流2 备选流4
设计测试用例（场景5）：
假定ATM只能识别银联卡
1、插卡（先用万事达卡）
2、换卡（银联卡），再进行插卡
3、输入密码（第一次输入错误）
4、再次输入密码（第二次输入错误）
5、第三次输入密码（输入正确）
6、选择服务–取款
7、选择取款金额–500
8、等待出钞
9、取卡
为用例的步骤设计数据
1、正交法原理介绍
正交实验法就是利用排列整齐的表-正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的试验次数找到较好的生产条件，以达到最好效果。
这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格-正交表来安排试验并进行数据分析的方法。
基本思想：
在一项试验中，把影响试验结果的量称为试验因素（因子），简称因素。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其他因素的每个水平参与试验的几率是完全相同的，能有效地比较实验结果并找出最优地实验条件。
在任意2列其横向组成的数字对中，每种数字对出现地次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中。
2、正交实验法实现步骤
（1）确定因素
这里的因素指对原件运行结果有影响的软件
确定因素的取值范围或集合，因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源；要从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或没有提及）
（2）确定每个因素的水平
根据因素的取值范围或集合，采用等价类划分、边界值分析以及其他软件测试技术，在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值
（3）选择正交表
根据确定的因素和水平，选择适合的正交表（只要特定的因素数和水平数的组合才有对应的正交表）；如果没有合适的正交表可用或需要的测试用例个数太多，要对因素和水平进行调整
3、实际案例
完全排列组合：3×3×3=27
正交表设计助手：latin、blend
L9_3_4：3水平4因素，9次实验
每一列，同一个数字出现的次数相等（3次）
任意2列中，同一个数字对出现的次数相等（1次）
1、功能图法原理
功能图法又叫做状态迁徙图。
来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时（软件的状态会根据某些内容、条件、操作的变化而变化），如何进行测试用例的设计就比较麻烦。
状态迁徙图的目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖
2、功能图法步骤
3、案例：以QQ登录界面为例，说明功能的变迁
1）列出所有可能的事件
IP1：输入账号
IP2：输入密码
IP3：点击登录按钮
IP4：点击关闭按钮
2）定义QQ登录界面为“空闲”状态
3）给空闲状态加操作：第一轮分析后产生了新的状态
针对新的状态进行分析（第二轮）
得到一个新的状态，继续进行分析
虽然得到了一个全新的界面（状态），但是和空闲状态发生了“隔断”，因此将其视为空闲状态的结束，可以结束分析过程。
4）将状态变化过程列表化，准备设计测试用例
设计用例时：
①A列：从QQ的登录界面，直接点击关闭按钮，QQ登录退出
②D列：从QQ的登录界面，先输入QQ号（状态变为QQ号已输入）；再输入密码（状态变为QQ号、密码已输入）；点击登录，状态变为QQ主界面
1、测试大纲法
一种着眼于需求的方法。为列出各种测试条件，将需求转化为大纲的形式（进行详细的需求分析，将其转化为思维导图–树形结构）。
无需用例设计，一般从根节点开始，到叶节点结束，这样的一条路径就是一条测试用例。
一般用于快速的测试和过程记录。用例一般进行后补
2、探索性测试法
基于测试人员经验和直觉的测试方法。
是计划内测试用例设计的补充。
探索性测试法执行前也需要设计测试用例
3、猴子测试（随意性测试）
一种没有书面测试用例（无意识的行为）、记录期望结果、检查列表、脚本或指令的测试。
缺点：
总结：所有测试用例方法的使用，都不是独立的，往往在一个软件的页面中，需要好几个测试用例方法融合在一起使用。正交试验法是一种及其特殊的用例设计方法，一般没地方用
案例：教育APP
1、启动页面
需求：
1）读取版本更新信息：匹配当前APP与线上需要更新的APP版本是否一致
2）读取用户信息：未登录用户，则不用获取；已登录用户，验证是否登录过期
用例设计方法–场景法
设计场景：
①APP的安装版本比最新版低。启动就需进行版本检测，并进行提示
②APP的安装版本与最新版一样。默认检测成功
③APP启动检测用户登录状态，如果登录过期或未登录，启动完成后直接跳转登录界面
④APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转首页界面
2、登录界面
需求：
1）手机号：只支持大陆手机
2）验证码：长度为6位数字
3）短信验证码文本内容：【正教】456712（正交验证码），30分钟内有效，为确保您账号安全，请勿将验证码告诉他人！
4）登录按钮点击后，系统可能的弹窗提示
用例设计方法–等价类划分法、边界值分析法、因果图法
等价类划分法：
①手机号的有效性（手机号包含各种不合法字符）
②验证码包含各种不符合需求的字符
边界值分析法：
①手机号超过/不足长度限制
②验证码超过/不足长度限制
③验证码有效期为30分钟，所以超过30分钟后使用验证码，就是边界值的使用
④弹窗提示1s消失，超过/不足的测试都是边界值的应用
因果图法：
①提交数据时，APP网络中断，有网络异常的提示
②提交数据时，服务端崩溃或者无法提高正常服务，有服务器报错提示或等待提示
③提交数据时，手机号不符合要求（不存在），有手机号错误的提示
④提交数据时，验证码输入不是收到的验证码、超时，有验证码错误提示
3、课程内容页面，需求如图所示：
用例设计方法：场景法、等价类划分法、边界值分析法
场景法：
①该课程今日有作业、有提问的内容展示。老师发布作业时，学生提问
②该课程今日有作业、无提问的内容展示。老师发布作业时，学生无提问
③该课程今日无作业、有提问的内容展示。老师没有发布作业时，学生提问
④该课程今日无作业、无提问的内容展示。老师没有发布作业时，学生无提问
等价类划分法、边界值分析法：
①日期的显示。有没有出现2017年2月有29的现象？
②日期的显示。有没有出现2017年2月1日和2017年1月31日重复或者相隔一天的现象？
判断依据：需求说明书
软件在使用过程中存在的任何问题（如：错误、异常、失败等），简称bug。
一般事项：
对于满足标准1、2的缺陷，一般都属于中高优先级的缺陷
对于满足标准5的缺陷，一般属于建议级别的缺陷（优先级较低）
特殊情况例外，例如需求中有明确的性能要求或者其他规范要求
缺陷类型时根据缺陷的自然属性划分的缺陷种类
注意：需求分析、设计阶段，稳定类型的缺陷多；集成测试阶段，一般接口类型的缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷
缺陷的故障对软件的影响。
很大程度上取决于缺陷对测试工作的影响程度。
例如：电商系统的用户注册功能无法使用（无法登录、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法使用）就必须立即修复；电商系统中关于用户购买流程帮助说明的网页链接点击404页面
注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷优先级高，甚至需要理解解决；软件的备选流、基本功能测试中的反向测试内容优先级较低，甚至有效可改可不改
面试：缺陷的严重程度和优先级有什么关系？
1）没有任何直接的关系
2）不要认为严重的缺陷，修复优先级就越高
3）若碰到优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退现象，严重程度很高，但优先级很低
①激活/打开（新建）。由测试人员进行标注
②确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、质量保证（QA）、产品经理确认，经确认后，有效的缺陷会指派给相关人员进行处理
③已修复/修正。在缺陷被修复后，一般由开发人员进行
④关闭/非激活。缺陷被修完成后，经测试人员验证后无问题
⑤重新打开。经测试人员验证后缺陷没有修复成功，需要重新打开进行再次处理和修复
⑥推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或其他相关管理人员进行确认
⑦保留。缺陷暂时修复不了。一般由开发人员设定，也需测试人员进行确认
⑧不能重现。开发按照缺陷复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷育有类似特征；由于操作系统差异、浏览器缓存等信息出现的问题。作为测试人员，提交bug之前要再三确认bug
⑨需要更多信息。作为测试人员，提交bug时要尽可能把所有相关文件一起提交（图片、视频）
⑩重复。测试中，一定要避免类似情况出现。尤其在软件的某一个功能频繁被多个模块调用的情况下
直接原因
测试总结时关注缺陷的根源
①发现缺陷：测试人员
②提交缺陷：测试人员
③确认缺陷：测试主管、质量保证（QA）、产品经理确认
④分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理，一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、UI、产品经理
⑤修复缺陷：主要由开发（代码）修复，也有可能是产品经理（需求）修复问题，也有可能是UI（界面）修复
⑥验证缺陷：测试人员验证缺陷是否修复成功
⑦关闭缺陷：只能是测试人员进行
面试提问：针对你工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）
客观依据：需求文档、设计文档、产品原型、测试用例
主观依据：同行业的类似成熟软件、和开发人员沟通、和有经验的测试人员沟通、同行业隐性需求
预期读者：开发人员、质量管理人员、市场人员、运维人员
1）缺陷编号。Bug_项目名称_模块名称_功能名称_0001
2）所属模块。一级模块/二级模块/三级模块
3）优先级。缺陷修复的紧急程度。P1＞P2＞P3＞P4
4）严重程度。S1＞S2＞S3＞S4
5）缺陷概述。用一句话描述缺陷的基本情况
6）缺陷描述。将缺陷的复现步骤、实际结果、预期结果列出
7）提交人。
8）备注。一般写产生改缺陷的特殊情况；bug截图
跟踪流程
测试的基本流程：
获取测试需求–>编写测试计划–>制定测试方案–>开发与设计测试用例–>执行测试–>提交缺陷报告–>测试分析与评审–>提交测试总结–>准备下一版本测试
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：
1）分析出系统的模块和组织结构
2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者角色要用
3）识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员要有相应的分析成果，一般用Xmind思维导图工具进行分析，或使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向和优先级
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，即每一个需求点都要被测试。因此，测试过程中，衡量需求的覆盖程度就非常重要，使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明。如果需求覆盖度＜100%，那一定说明了测试的覆盖度不够。
测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1）设计的测试用例总量 TC
2）执行的测试用例数量 EC
3）未执行的测试用例数量 WC
4）执行通过的测试用例总量 SC
5）执行失败的测试用例总量 FC
6）提交的缺陷的总量 BC
以上六个数据，要符合如下数量关系：
1）TC≥EC
2）TC=EC+WC
3）EC=SC+FC
4）BC≥FC 一条测试用例的预期结果数量是固定的（甚至是唯一的）。测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的
5）通过SC/EC 可以表现出系统的质量是否合格
6）通过EC/TC 可以表现出系统的需求是否得到满足
功能性：满足某种需求的一种属性或能力
性能效率：在规定条件下，相对应所用资源的数量，软件产品提供适当性能的能力
兼容性：在一定条件下兼容其它软硬件产品的能力
易用性：在指定条件下，产品被理解、学习、使用和吸引用户的能力
可靠性：产品在规定条下，在规定的时间内完成规定功能的能力
信息安全性：信息在传输或存储过程的安全程度
可维护性：在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力
可移植性：从一种环境迁移到另一种环境的能力
