产品的风险识别，提高产品成功的几率。
一、本质 站在用户的角度来检验一个软件是否满足客户的功能需求，并且能够及时准确的发现其中用户可能察觉不到的软件的缺陷。 二、立场 为了证明程序有错误！ 三、成本 及时的发现漏洞或者逻辑缺陷，能够避免产品在未来投入生产后可能产生异常所造成的公司成本资源的浪费。
一、定义 对某个软件系统运行过程进行检验其是否满足需求(或者说实际运行结果是否符合预期)
二、原则
1.方向 一切测试都要以用户需求为中心测试的用例是设计出来的，不是写出来的(按需设计) 2.执行 测试贯穿整个产品的声明周期提前测试+不断测试不要妄想穷举所有的可能测试用例 3.错误 二八原则：80%的错误,发生在20%的模块中对发现错误较多的程序段，应进行更深入的测试错误的优先级排序->先解决影响产品基础功能的问题一、软件证明阶段
1960年代—> 测试即debug程序二、软件检测阶段
1960-1978年代—>证明软件是正确的1979-1982年代—>测试思想初成(为了返现软件错误：破坏性测试)黑盒测试的概念诞生：把程序看做一个黑盒子，不考虑内部结构，只是在外部测试程序的功能是否能够按照规范说明准确无误的运行。三、软件预防阶段
1983年 测试行业的标准IEEE829的诞生—>标志着软件预防阶段的开始白盒测试的概念诞生：把程序看做一个白盒子，能够清楚的看减盒子内程序的逻辑和相关信息，观察程序运行内部是否按照规格设计说明书设定的运行，以及每个独立的模块结构是否正常有效。四、软件全面质量管控阶段
21世纪至今—>以用户为中心，降低产品风险，全流程把控产品的质量。灰盒测试概念诞生—>当今产品的开发速度过快的环境下衍生的一种测试模式，根据需求高效的来进行产品测试，即包含了黑盒的纯用户行为的测试 又可以根据测试需求查看具体某一个功能代码的内部逻辑。一、软件开发模型
1.瀑布型（20世纪70年代）
概念： 将开发流程划分6个阶段—>制定计划、产品需求、设计功能、编码、测试、运维 各个阶段严格按照线性执行, 逐级操作, 从上到下固定次序 优点： 6个阶段 划分明确, 清晰 只需要关注后续阶段迭代功能期间, 复用性高提供了一个开发模板 从分析->设计->开发测试->上线 缺点： 不灵活, 固化, 每个阶段产生大量文档(产品需求文档, 接口文档, 原型图, 设计报告, 测试报告, 测试设计, 运维报告, 上线文档)用户参与度比较低, 产品风险较高突出缺点是不适应用户需求的变化用户需要足够的耐心 适用场景： 需求非常明确, 变化极少的项目 客户要求相对较低, 参与度低2.快速开发模型
概念： 借助原型辅助工具根据用户的需求构建一个产品原型, 让用户参与使用, 反复进行：确认需求>需求敲定>运行查看>总结改进优点： 适应用户需求的变化, 用户参与度比较高, 满意度比较高, 节约成本缺点： 前提必须有 产品原型, 限制开发的思路开发技术和工具 不一定符合最新技术频繁修改 适用场景： 中小型的项目, 不适用大型项目对所开发的领域比较熟悉3.增量模型（常用）
概念： 按照需求 将项目拆分模块化,开发一个模块,测试一个模块, 用户参与体验模块, 及时响应用户的需求优点： 降低开发风险, 提高用户参与度模块顺序可以随时调整, 比较灵活 缺点：需求变化 尽可能控制变化少适用场景：迭代更新、新产品开发4.螺旋模型（20世纪90年代）
概念：以风险分析驱动开发, 将瀑布型和快速原型模型结合.优点： 设计灵活, 在整个阶段可以灵活调整变更风险更低 缺点： 风险评估的专家 要求特别高, 评估结果需要科学准确如果风险评估干扰了项目的营收, 整个风评可以不做 适用场景：大型项目二、 测试模型
1.V模型
概念: 先开发后测试 开发阶段: 需求分析—概要设计–详细设计–编码测试阶段:单元测试—集成测试–系统测试–验收测试 四个测试阶段：单元测试->白盒测试, 测试代码有没有问题,–django子应用-test.py ; 单模块测试集成测试->多模块测试, 至少两个模块①冒烟测试->主功能测试,②回归测试->测试人员发现了BUG–提交给开发–开发修改完毕–测试再次测试–回归测试③系统测试->是检测系统的功能、质量、性能能否满足系统的要求验收测试->确定上线之前 的测试 优点： 阶段清晰明了既包含单元测试又包含系统测试 缺点：测试介入太晚2.VV模型 （常用配合增量模型的开发模式）
概念：边开发边测试, 测试和开发是相互独立的, 弥补了V模型的缺点可以让测试尽早介入开发过程中，跟上项目进度优点：测试伴随整个项目的开发周期、测试和开发是并行独立进行缺点：面向中大型企业 对技术要求较高 3.H模型 概念：测试独立于开发, 根据测试的就绪点进行测试, 灵活性较高, 随时开发随时测试优点：测试伴随整个项目的开发周期、测试于开发是并行独立进行缺点：H模型的中间就绪点难找，管理难度大，对测试人员技术经验要求较高三、 测试的基本流程
1、需求分析阶段 开需求分析会出需求分析报告 2、 测试计划阶段 预估测试时间预估测试的人力测试环境搭建测试数据准备测试服务器 3、 测试设计阶段 设计测试用例评审测试用例 4、执行测试阶段 点界面代码测试自动化测试 5、测试评估阶段 根据 测试用例, 测试报告, 缺陷报告–对产品进行上线评估一、测试用例概念 测试用例(test-case)，就是一个用来实现测试具体的软件某个功能是否可以满足用户需求的一个demo，包含输入、执行条件以及预期结果。 二、特性
提升效率，可以复用
有效性，不同人测试同一结果
容易组织分类
可以作为评估依据
方便管理
三、原则
保证测试用例的明确性(一个借口一个用例，条件明了)确保测试用例具有代表性(减少类似功能测试用例的重复)确保测试用例的简洁性(可读性高、过程目的明确)一、测试用例组成的八要素
1.测试用用例的编号（唯一）2.测试标题（唯一） 3.测试模块（所属接口）4.预置条件（硬件、版本、系统）5.测试输入（程序需要传递的数据）6.测试步骤（足够明了）7.预期输出结果（返回值、响应等）8.重要程度 高中低二、测试用例的几种设计方法
1.等价类划分法(包括边界值分析法) 定义：从大量数据里划分范围（每个范围内的数据测试效果是等价的所以每个范围是一个等价类），然后从每个范围中挑选代表数据，这些代表数据能反应这个范围内数据的测试结果。分类： 有效等价类： 满足程序的规格说明检验程序是否实现了规格说明中所规定的功能和性能 无效等价类： 超出程序规格说明外的数据，不合理、无意义的数据可校验程序对于无效数据的处理能力,检测程序的健壮性、容错能力 适用场景：大量数据中挑选出具有代表性的样本数据 2.判定表法 定义： 将复杂的需要测试的代码逻辑可能的各种情况全部列出来，避免测试项遗漏组成元素 条件桩：列出了问题的所有条件，通常认为列出条件无关紧要。动作桩：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。条件项：列出针对它左列条件的取值。在所有可能情况下的真假值。动作项：列出在条件项的各种取值情况下应该采取的动作。 使用原则： 规则：任何一个条件组合的特定取值以及相应的执行操作为规则。条件项和动作项自由组合构成全部可能条件。化简：规则合并有两条或者多条具有相同动作并且其条件项之间存在着极为相似的关系，即可化简为一个操作。 适用场景： 某些业务逻辑实现依赖于多个条件组合，针对不同的组合值分别针对执行不同的测试条件。 3.正交验证法 定义： 也叫正交实验法或者正交排列法，就是使用最小的测试过程集合获得最大的测试覆盖率。在一项实验中，把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。 组成：公式->Ln(m^k) n代表行数：n=k*(m-1)+1k代表列数：即条件的个数(因子的个数)m代表因子选项：即因子中的包含的所有值 试用场景： 需求中条件的组合数量量比较大的时候需求两个两个因子相互组合的时候 正交法的局限性： 对于控件个数，如果没有，就选择一个接近的对于控制的取值，应该少数服从多数，有更多空间的取值一样 4.其他不常用方法 错误推测法场景法因果图法三、写测试用例（Important）
等价类划分法的测试用例 要求：测试某网站账号的合法符合规范(8-12位、只能由数字组成) 测试用例： 用例编号等价类划分输入预期结果测试结果重要级别Test-账号01有效等价类(有效边界值)12345678正确正确高Test-账号02无效等价类(无效边界值)1234567正确正确高……………… 判定表法的测试用例 要求：对于显卡功率大于250W的主机、维护记录不全或运行5年以上的主机，应优先维修。 测试用例： 条件+动作 条件桩显卡功率大于250W?维护记录不全？运行超过5年 ？动作桩优先维修 初始判定表(所有可能) 条件桩条件项12345678显卡功率大于250W?YYYYNNNN维护记录不全？YYNNYYNN运行超过5年 ？YNYNYNYN动作桩优先维修?XXXXX…其他处理XXX 化简后的判定表在三个条件中有2个不满足时，剩下的一个完全没有参考价值，可以进行简化。
只有功率大于250W、维修记录全的、运行5年以上的才优先处理。
其他处理的情况是： 满足动力大于250W、维修记录完全、没有运行5年以上中只要满足两项。
条件桩条件项12345显卡功率大于250W?YYNNN维护记录不全？YN--N运行超过5年 ？-YYNN动作桩优先维修?XXX…其他处理XX 正交法法的测试用例 要求：测试某网站账号的合法符合规范(8-12位、只能由数字组成)测试用例：实现“字符属性设置”的测试用例编写
列举因子表 字体字符样式字体颜色字号仿宋粗体红色20号楷体斜体绿色30号华为楷体下划线蓝色40号 正交表确定：L9(3^4)所有的可能取值 实验号字体字符样式字体颜色字号1仿宋粗体红色20号2仿宋斜体绿色30号3仿宋下划线蓝色40号4楷体粗体绿色40号5楷体斜体蓝色20号6楷体下划线红色30号7华文楷体粗体蓝色30号8华文楷体斜体红色40号9华文楷体下划线绿色20号 测试用例编写(上图每一行都是一条测试用例！) 用例编号输入预期结果实际结果是否为BUGUT-设置字符子项测-01字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:20仿宋、 粗体、 红色、20号仿宋、 粗体、 红色、20号否UT-设置字符子项测-02字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:30仿宋、 粗体、 红色、20号仿宋、 粗体、 红色、25号是……………一、什么是缺陷 缺陷就是软件系统中不符合用户需求或者达不到用户满意的的问题。 二、缺陷来源 软件系统运行过程中发现的某种破坏系统正常运行能力的问题，而导致不满足用户的需求。 三、缺陷表现形式
从严重程度上划分： 失效(高)： 软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。故障(中)： 软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为缺陷(低)： 存在于软件中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug； 从外在表现上划分 1.设计性 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾数据不正确，或者精度不够，不完整或者格式不统一 2.功能性 功能、特性没有实现或者部分实现没有达到需求规格说明书所规定的性能指标运行出错，包括运行中断，系统崩溃，界面混乱等用户不能接受的其他问题，比如等待时间过长，界面不美观 3.其他 硬件或者系统软件上存在的其他问题一.组成
缺陷名称
缺陷状态
缺陷的严重程度(高->低) * 1.Fatal：致命缺陷 * 2.Critical：严重缺陷 * 3.Major：一般缺陷 * 4.Minor：小缺陷 * 5.Enhancemental：建议的问题
缺陷解决的优先级(高->低) * 1.P1：立即解决 * 2.P2：高级优先 * 3.P3：正常级别 * 4.P4：低级优先
二.缺陷的分类–>BUG的类型 三.缺陷报告！
一、认识禅道
1.禅道做什么用？ 一款集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体的项目管理软件。2.为什么用“禅道”这个名字？ 这个名字是受《编程之道》和《编程之禅》这两本书的启发。英文里面的禅为Zen，道为Tao，所以软件的英文名字为zentao。二、安装禅道
各种环境环境安装: 来自禅道官网教程. 三、使用禅道
大家可以按照官网的教程进行练习： 来自禅道官网教程.
