目录
1.软件测试基本概念
软件测试流程:
1.获取测试需求
2.编写测试计划
3.指定测试方案
4.开发和设计测试用例
5.执行测试（与开发交集）
6.提交缺陷报告
7.测试分析与评审
8.提交测试总结
软件测试过程模型:
V模型(揭示了开发过程和测试过程各阶段对应关系)
缺点: 忽略测试对需求分析、系统设计的验证 没有体现"尽早地和不断地进行软件测试"的原则
W模型(两个V模型，分别代表测试与开发过程)
缺点: 需求、设计、编码等过程被视作串行，无法灵活迭代
H模型（软件测试是一个独立的流程）
X模型（改进V模型，定位探索性测试）
软件测试理念:
尽早测试、全面测试、全过程测试、独立的、迭代的测试
软件测试分类:
单元测试（模块测试）涉及到代码和程序
集成测试（接口测试）
确认测试（冒烟测试）
系统测试（全面、全方位的）
验收测试（供求双方 α测试、β测试）
按测试技术:黑盒测试、白盒测试和灰盒测试
按代码运行:静态测试和动态测试
软件测试的原则:
用户需求、质量第一 、不可穷举
测试用例
设计一个情况，软件程序在这种情况下，必须够正常运行并达到程序所设计的预期结果
用例设计模板
1.标识符: TestCase_项目名称_模块名称_功能名称_0001
2.测试项。测试用例的测试目的，表明测试模块、测试对象、方式、事件
3.依赖用例。一般功能流程上，下游功能测试依赖于上游功能测试用例
4.测试步骤。用最朴实的语言写出软件的操作步骤。
5.测试数据。单独整合测试数据。
6.预期结果。内容、对象准确。重要步骤之后,设定预期结果。
7.测试结果。测试执行完成之后添加。 通过/失败 Pass/Fail
8.测试人。测试的执行人，和设计者相同，也可以不同
9.备注。为了测试用例正常执行而做的特殊准备。
作用 ：
1 有效性 2 可复用性 3 易组织性 4 可评估性 5 可管理性
注:测试用例需要经常更新，避免杀虫剂效应。
2.黑盒测试用例设计方法
等价类划分法
划分原则
一个文本框规定，输入字符个数为6~18位
1个有效：范围内有效 2个无效:小于6个 大于18个
划出等价类和列出等价类表
用例问题:
1.按照测试分类 （功能、UI、性能、安全、接口）
2.测试项
3.身份证号业务知识
4.测试项一般只写一个测试目的
5.依赖用例
边界值分析法
输入条件:值的范围 输入数据:范围边界值、刚刚超过边界范围的值
输入条件:值的个数 输入数据:最大个数、最小个数、比最小个数少1、比最大个数多1
分析规格说明，找出其他可能的边界条件
三角形判断，数据和顺序有没有关系？输入顺序不影响结果。
因果图法
适合于描述对于多种输入条件组合的测试方法
根据输入条件的组合、约束关系和输出条件的因果关系
原因与结果的关系: 恒等、非、或、与
约束条件:
原因约束:互斥、包含、唯一、要求（原因A成立，要求B一定成立）
结果约束:屏蔽（Mask）（结果之间A结果出现，B结果一定不出现）
优势:能够发现设计中存在的不足
局限性:原因和结果很多的时候，关系连线就会很多，导致因果图的可读性变差，一般用于局部小功能分析
判定表法
判定表驱动法: 条件桩、动作桩、条件项、动作项
应用场合: 适用于多条件内容组合与结果分析
使用的条件: 所有条件桩在表中的位置和顺序互相不影响，所有动作桩的顺序不会因为条件顺序的变化而产生不同
1.所有的软件，都是因为某种操作才会导致一定的结果 --因果图
2.所有的软件都有文本框 考虑必须一定使用等价类、边界值
场景法
事件触发控制流程。测试时，生动描述事件触发时的情景，有利于设计测试用例，
同时使测试用例更容易理解和执行。
基本流（软件功能正确实现的流程）、备选流 （基本功能流程之外的过程）
场景法适用于解决业务 流程清晰的系统或功能
正交实验法
利用排列整齐的表-正交表 ，用少数实验次数找到较好生产条件，达到最好的效果
核心概念：
1.影响实验结果的--实验因素（因子）、因素
2.每一个因素的不同取值（状况）--水平
例如，字的显示效果--字体、字号、颜色，称为因素
选择正交表--
1.n实验次数，m水平数，k因素的数量，这三个数字之间没有任何数学关系
2.仅适用于每一个因素的水平数都相同的正交表
功能图法
状态迁移图：遇到有事务流或者由于某种条件成立导致状态改变的软件时
使用条件:软件的状态会根据某些内容、条件、操作的变化而变化。
目标:尽可能覆盖软件状态、状态-条件组合的覆盖以及状态迁移路径的覆盖
步骤:
1.识别和列举所有的输入操作
2.定义空闲(初始)状态
3.为空闲状态加操作（只加一次）
4.为第3步所产生的新状态加操作（只加1次，并且曾经加过的操作不再重复添加）
5.循环为所有的新增状态加操作，直到没有新状态产生为止
6.组合任意状态，以列表的形式展现，设计和编写测试用例
测试大纲法
着眼于需求，无需测试用例，用于快速的测试和过程记录
探索性测试
基于经验和直觉
是计划内测试用例设计的补充
执行前需要设计测试用例
猴子测试（随意测试）
没有测试用例
缺点:测试不真实、不能达到一定覆盖率、许多测试冗余、同样随机数才能重建测试
3.其它
用例设计方法综合选择
·首先进行等价类划分
·在任何情况下都必须使用边界值分析方法
·如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
·对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
·状态迁徙图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
·对于业务流程清晰的系统，可以利用场景法贯穿整个测试案例过程，
·可以用错误推测法追加一些测试用例
·对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例
用例设计方法分类
1.等价类分析法
2.边界值分析法
3.因果图法
4.判定表法
5.场景法
6.正交实验法
7.状态迁徙图法（功能图法）
8.其他用例设计方法
记住方法的名称很简单，但是如何使用却是一个大问题:如何使用。用例设计方法的使用不是孤立存在的，而是存在于项目中！尤其是一个项目中。
教育APP为例设计各种用例设计方法
1.启动页
①读取版本更新信息。匹配当前APP与线上需要更新的APP版本是否一致。
②读取用户信息。未登录用户，则不用获取；已登录用户，验证是否登录过期。
用例设计方法：采用场景法进行设计。
设计场景：
①APP的安装版本比最新版要低。启动就需要进行版本检测，并进行提示。
②APP安装版本与最新版一样。默认检测过程成功。
③APP启动检测用户登录状态，如果登录过期或者未登录，启动完成后直接跳转登陆界面。
④APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转首页界面。
2.在登录界面，看需求
用例设计方法：采用等价类划分法和边界值分析法。
等价类划分法：
①手机号的有效性。（手机号包含各种不合法字符）；
②验证码包含各种不符合需求的字符
边界值分析法：
①手机号超过/不足长度限制；
②验证码超过不足长度限制；
③验证码有效期为30分钟；所以超过30分钟后使用验证码，就是边界值的使用。
④弹商提示1s消失；超过或者不足的测试都是边界值的应用。
3.课程内容页。需求如图所示
用例设计方法：场景法、等价类划分、边界值分析法。
场景法：
①该课程今日有作业、有提问的内容展示。老师发布作业的时候，学生提问。
②该课程今日有作业、无提问的内容展示。老师发布作业的时候，学生没有提问。
③该课程今日无作业、有提问的内容展示。老师没有发布作业的时候，学生提问。
④该课程今日无作业、无提问的内容展示。老师没有发布作业的时候，学生也不提问。
等价类划分法、边界值分析法：
①日期的显示。有没有出现2017年2月有29天的现象？
②日期的显示。会不会出现2017年2月1日和2017年1月31日重复或者相隔一天现象？
总结:所有测试用例的设计方法，没有独立使用的。都是融合在一起使用的，往往在一个软件界面中，都可以使用好几种测试用例的设计方法。
缺陷:
软件未实现产品说明书要求的功能
软件出现产品说明书指明不应该出现的功能
软件实现产品说明书未提到的功能
软件难以理解、不易运行、运行缓慢或者最终用户认为不好
缺陷类型、严重程度、优先级、状态、起源、来源、根源
缺陷类型: 功能、用户界面、文档、软件包、性能、系统/模块接口
注意：需求分析、设计阶段，文档类型的缺陷多；
集成测试阶段，一般接口类型的缺陷多一些；
系统测试阶段，功能、界面类型的缺陷多一些；
验收测试阶段，更多的关注性能缺陷；
实施过程，可能会遇到一些软件包的缺陷；
缺陷严重程度: 致命、严重、一般、较小 S1>S2>S3>S4
学习过程中，以PPT上所描述的严重等级进行缺陷严重程度划分
缺陷修复优先级: P1(立即解决)>P2(高优先级)>P3(正常排队)>P4(低优先级)
很大程度取决于缺陷对测试工作的影响程度。
优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能缺陷，优先级高，甚至需要理解解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。
面试提问：缺陷的严重程度和优先级有什么关系？
1）没有任何直接的关系。
2）不要认为严重的缺陷，修复优先级就高；
3）如果碰到，优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退的现象。严重程度很高；但是优先级就很低。企业logo错误，不影响任何功能；但是必须优先修复。
面试提问：提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级？
1）不能搞“狼来了”。
2）也不能私人关系“帮”好朋友减少不良影响。
缺陷的状态
缺陷通过一个跟踪修复过程的进展情况。表明缺陷的处理进度。
发现缺陷是缺陷处理的前提，但是还还没有进入缺陷的处理流程。
1.激活/打开（新建）。由测试人员进行标注。
2.确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证（QA）、由产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。
3.已修复/修正。在缺陷被修复后，一般由开发人员进行。
4.关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。
5.重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。
6.推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。
7.保留。缺陷暂时修复不了。一般也是由开发人员去设定。也需要测试人员进行确认。
8.不能重现。开发按照却显得复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三的确认bug。
9.需要更多信息。作为测试人员，撰交bug的时候，要尽可能的把所有相关的文件一起提交。（图片、视频）
10.重复。测试中，一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块（由不同的测试人员测试）调用的情况下
11.不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态不是bug。
12.需求修改需求说明书。缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成。
缺陷的起源、来源、根源。一般关注较多的是缺陷的来源（直接原因）；在测试总结的时候，关注缺陷的根源。
缺陷的来源
缺陷来源指缺陷的起因
缺陷的生命周期
1.发现缺陷。由测试人员。开发也能知道自己哪里写错了，但是不会广而告之。
2.提交缺陷。由测试人员。开发更不可能提交bug。
3.确认缺陷。一般由测试主管、或者质量保证QA、由产品经理确认。
4.分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。
5.修复缺陷。主要由开发修复，也有可能是产品经理修复问题。
6.验证缺陷。测试去验证缺陷有没有修复成功。
7.关闭缺陷。只能是测试人员进行。否则出了问题，测试认识一律不背锅。
缺陷的识别
依据:需求文档、设计文档、产品原型、测试用例，都是客观的依据
同行业的类似成熟软件。
测试人员在识别缺陷的时候，要很灵活的对待
缺陷报告
1、缺陷编号。Bug_ 项目名称_模块名称_0001。
2、所属模块。一级模块/二级模块/三级模块。
3、优先级。缺陷修复紧急程度.P1>P2>P3>P4。
4、严重程度。S1>S2>S3>S4。
5、缺陷概述。用一句话描述缺陷的基本情况。
6、缺陷的描述。将缺陷的复现步骤、预期结果和实际结果列出来。
7、提交人。是谁就写谁的名字。
8、备注。一般写该缺陷的特殊情况。将bug的截图作为备注信息。
缺陷报告预期读者
开发人员、质量管理人员、市场人员、运维人员
缺陷报告编写目的
1.展现缺陷的详细信息
2.展现缺陷的影响程度和方式
缺陷报告编写准则
准确、清晰、简洁、完整、一致
缺陷描述的规则:
1.可以再现
2.不做评价
缺陷跟踪系统
Bugzilla、Bugfree、禅道、QC
204
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
