测试理论2

测试理论基础（主要是黑盒功能测试）：

测试用例设计：
系统测试流程：
测试计划设计：
目标：根据实际情况有不同，根据项目来决定
总体概述：
项目背景
项目范围
测试计划：
测试资源的需求：硬件（硬件服务器、手机设备、平板设备、电话卡）、软件（操作系统、数据库、web服务器）、设备资源、人员需求；
组织形式、测试对象、需求跟踪、测试通过/失败标准、测试挂起/恢复条件、测试风险与防范、测试任务安排
应交付的测试工作产品
资源分配
测试需求分析：
分析需求来源：需求规格说明书、开发需求、继承性需求、行业竞争分析、经验库
需求分类：功能性需求、功能性需求、外部程序应用接口需求
根据软件质量特定划分需求：安全、可靠、可移植性、可维护

测试策略：解决怎么做
测试规程设计：测试需求变更控制流程、测试用例变更控制流程、测试环境搭建流程、缺陷管理流程
测试用例设计：
配置测试环境：
测试用例执行：
缺陷跟踪回归：
测试报告的输出：测试日报、测试总结

测试用例：
定义：测试用例是为特定的目的而设计的一组测试输入、执行条件和预期结果，体现测试方案、方法、决策，
要素：
用例编号：a-b-c-d a：产品名称或项目名称 b：用例属性：st、it、ut c：测试对象 d：编号
测试项：准确的描述所需要测试项及其特征
测试标题
用例属性：
重要级别：用例在执行时优先程度及重要程度：高(实现主体功能的用例) 中（主项流程经过备选流处理能够正确实现） 低（GUI 易用性表达 文字描述类）
预置条件：执行用例之前应该满足的条件
测试输入：执行步骤所涉及的数据
操作步骤：具体的动作
预期结果：必须具体阐述指定的环境和输入标准得到期望的测试结果
实际结果：用自己的语言描素测试完成的结果。尤其是与预期不同时要提出bug
附件：有没有都可以不是必要

八大要素：
测试用例编号：字符和数字组合成的字符串，用例编号应具有唯一性、易识别
A-B-C-D a：产品名称或项目名称 b：用例属性：st、it、ut c：测试对象 d：编号
单元测试：产品编号-UT-单元测试项名-单元测试子项名-XXX
系统测试：产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试：产品编号-IT-集成测试项名-集成测试子项名-XXX
测试项：当前测试用例所在测试大类、被测试需求、被测模块、被测单元等。
系统测试用例测试项目：软件需求项
集成测试用例测试项目：集成后的模块名或接口名
单元测试用例测试项目：被测函数名
测试标题：简单描述，需要用概括的语言描述用例的出发点和关注点，原则上每个用例的标题不能重复
重要级别：对基本和普通测试项的区分;高级别:保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
中级别:重要程度介于高和低之间的测试用例
低级别：实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
预置条件：执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到 预期结果
输入：用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入、文件、数据库记录等
操作步骤：执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
预期输出：当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等
测试用例写作检查规则：
1.测试用例标识是否按照测试方案的规则来编写
2.是否每个测试用例的预置条件都被描述清楚？
3.每个测试用例的“输入”中是否列出了所有测试的输入数据？
4.测试用例的“预期结果”是否完整而清晰？
5.是否明确说明了每个测试用例或测试用例集的重要级别？
6.是否明确说明了测试用例的执行顺序
测试用例额外的要素：
用例设计者:能准确的找到测试用例设计人员，对用例修改时能方便找准人员
用例设计日期:方便检查用例设计的进度
用例版本号:方便用例设计人员对用例的跟踪
对应的开发人员:出现BUG后能及时找到相应的人员进行修复
测试用例设计方法：
等价类划分：
等价：具有相同属性或方法事物的集合，这个集合中某个个体所表现的特征与其他个体完全一致
对于某个被测对象的测试输入而言，某个个体能够接受或拒绝，所在集合中的任意个体都应该是被接受或拒绝
等价类划分：有效等价类 无效等价类
等价类划分规则：
1. 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2. 在输入条件规定了输入值的集合或必须如何的情况下，可确定一个有效等价类和一个无效等价类。
3. 在输入条件规定了真假值的情况下，可确定一个有效等价类和无效等价类
4. 在输入条件规定了一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
进行用例设计：根据需求，确定等价类（根据需求，可细化等价类），列出等价类表；输入条件 有效等价类 无效等价类
根据已列出的等价类表确定测试用例:（1）首先为等价类表中的每一个等价类分别规定一个唯一的编号。（2）设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类。重复这个步骤，直到所有的有效等价类均被覆盖。
（3）设计一个新的测试用例，使它仅覆盖一个尚未覆盖的无效等价类。重复这一步骤，直到所有的无效等价类均被覆盖。
等价类方法的优缺点：针对软件单输入域进行的有效测试;考虑到测试数据的覆盖度和代表性;以较少的测试用例达到了较好的测试效果;没有对多输入域组合情况的进行测试
边界值分析：经验：故障往往出现在定义域或值域的边界上，而不是在其内部。
边界条件：输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态
边界值三点: 上点:边界上的点 内点:边界有效范围内的任意一点 离点:离上点最近的点,根据上点的精度确定 如何确定离点:如果边界是闭区间，则离点在外,如果边界是开区间，则离点在内
边界值应用场景:
1. 如果需求规定了取值范围或取值个数时，可利用该范围的边界内及边界附近的数据进行测试 [6,18] 6、18、5、19、10
2. 如果需求规定了取值个数，则少于个数1个，多于个数1个的值进行测试 购买3件商品打八折 3件商品、2件商品、4件商品
3 . 如果需求规定了一个有序集合的时候，可使用该集合的第一个和最后一个值进行测试 下列列表有4个城市名可选择 第一个城市、最后一个城市
4. 如果程序使用一个内部数据结构的话，则应该从该数据结构的边界进行考虑
边界值方法总结：是一种和等价类划分相关的技术、其本质就是在边界及其附近选取测试用例、它具有很强的发现程序错误的能力、错误隐藏在角落，问题聚焦在边界上
判定表：
其实就是一个二维表，分析和表达若干输入条件下，被测对象针对这些输入做出的响应的一种工具，在遇到复杂业务逻辑时，可利用该表理清业务逻辑关系。
重要概念：
条件：条件桩：需求规格说明定义的被测对象的所有输入
条件项：针对条件桩所有可能的输入数据的真假值
动作：动作桩：针对条件被测对象可能采取的操作
动作项：针对动作桩，被测对象响应的可能取值
规则：条件项和动作项组合在一起，形成的业务逻辑处理规则
步骤：1.分析原因和结果
2.找出因果逻辑关系、约束关系，画出因果图
3.设计及优化判定表
4.根据判定表中输出结果的表现，进行判定简化。去除无效项，合并相似规则或者相同的动作
5.设计测试用例
基于判定表的测试是最为严格、最具有逻辑性的测试方法。条件过多，不适合转换成判定表可以用正交分析；
因果图：
因果图和判定表示衍生产生的，考虑到测试中输入条件的各种组合，可能有天文数字的条件，所以用到因果图，出来比较像鱼骨图
是从需求中找到因（输入条件）和果（输出结果）之间的制约关系以及组合关系，绘制出的图
因果图常用的符号： CI：原因 EI：结果 恒等：原因结果同时 出现 非~：原因出现，结果不出现；原因不出现，结果出现； 或V：原因1个出现，结果就出现；原因都不出现，结果就不出现；
且^:原因都出现，结果才出现
约束条件：（图就不上了百度吧 毕竟我也是刚接触测试）
从输入考虑：
E（互斥、异或）： 表示ab俩原因都不会同时成立，最多一个能成立
I（包含）：abc三个原因中至少有一个必须成立
O（唯一）：ab中必须有一个，且仅有一个成立
R（要求）：当a出现时，b必须也出现，不可能a出现b不出现
从输出考虑（强制或屏蔽）
a是1时，b必须是0
a是0时，b必须是1
因果图步骤：1.提取因果，赋予标识符 2.提取因果关系，表示因果图 3.表明约束条件 4.转换判定表 5.设计测试用例
正交分析:
场景法: