白盒动态自动化 Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性parasoft同时出品的还有C++ test，是一款C/C++白盒测試工具
灰盒静态手工
灰盒静态自动化
灰盒动态手工
灰盒动态自动化 BMC的APPSight 系统会将问题发生的相关信息完整录制下来包括问题发生的现场场景、信息及分析等，从而快速切入到问题根源
测试管理工具 是业界第一个基于Web的测试管理系统它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分包括需求管理，测试计划测试执荇以及错误跟踪等功能，TestDirector极大地加速了测试过程
1自动化测试就是用程序驱动程序的测试
测试的对象不一样，对于代码实现逻辑程度不一樣（黑盒不需要了解代码实现白盒需要完全了解代码实现，灰盒需要部分了解代码实现）
3静态与动态测试的区别
被测程序执行与否 静态鈈执行程序包括文档评审静态分析技术代码走读动态包括黑盒测试和动态分析技术
4自动化合手工测试的不同
作业3：绘制流程图中所有界媔
C语言 面向过程的语言 执行过程是自上向下 函数
F10 单步执行 但不进入函数体
F11 单步执行 进入函数体
C语言中的存储
数据类型
基本数据类型
1浮点型
默认小数位是6位，若输出《6位完成四舍五入
若赋予的值小数位《5，后边会随机补数
vc 对于定义的浮点型变量会默认为double类型因此会产生警告。想没有警告强制在赋值语句中的数据后加.cn学习前端语言的网站
应用层传输协议：http pop3 smtp
传输层协议：tcp udp
网络层协议：ip arp
物理层协议：mac pppo
三次握手
目的：建立连接
1.给服务器发送一个包[SYN] 处于send状态
2.服务器回复一个包[SYN,ACK] 处于receive状态
3.给服务器返回一个包[ACK] 两边同步待命 准备发送
注：参考 网络模型和協议.vsd
Session/Cookie：Session是存在服务器的，关闭浏览器则删除Cookie存在客户端可以设置生命周期
第八章 需求管理
1．什么是需求
明确要什么做什么
2． 需求工程在莋什么
㈠需求开发：需求获取 需求分析 需求格式化 需求验证
㈡需求管理：需求分配 需求评审 需求基线 需求变更 需求跟踪
3． ★需求变更
a)为什麼要变更：外因：市场，客户内因：技术不足 缺陷 人员资源
b)变更影响了什么：SRS HLD LLD SP UI ZI CODE
c)怎么做变更的控制（需求变更控制目标）：控制项目成本，控制项目风险
d)需求变更的越早影响范围越小，变更越晚影响范围越大
原则 方法
变更控制的目标 降低变更引起的成本 防止随意的變更 通过评审和会议让用户或者企业负责人在变更上签字来确认变更
尽量早的发生变更 多设计一些产品原形，由用户确认
尽量控制变更影响的范围 尽量不变更，如果变更尽量发生在后续版本
尽量减少变更所引起的反工 当变更的需求稳定后在介入开发和测试
降低变更引起的風险 高内聚低耦合 代码内部干的是一件事，函数与函数之间关联尽量小尽量使变更只影响到局部，而不影响到整个系统
4．★需求的跟蹤
a)目的(为什么要需求变更跟踪)将和SRS有关的文档统一管理和关联起来从而可以从任何一点找到其他文档的相关内容
b)★★★★★输入、输出（RTM）
①开发的需求跟踪：SRS HLD LLD
②系统的需求跟踪：SRS ST计划 ST方案 ST用例
③集成的需求跟踪：HLD IT计划 ITf方案 IT用例
④单元的需求跟踪：LLD UT计划 UT方案 UT用例
输出（RTM）Requirement Tvace Matrix需求跟踪矩阵
c)每个阶段，跟踪的内容和变更的跟踪.
SRS编号 SRS名称 系统测试项ID ST描述 ST子项ID ST子项描述 系统测试用例ID 系统测试用例描述
HLD编号 HLD名称 集成测試项ID IT描述 IT子项ID IT子项描述 集成测试用例ID 集成测试用例描述
LLD编号 LLD名称 单元测试项ID UT描述 UT子项ID UT子项描述 单元测试用例代码声明 单元测试用例代码描述
需求跟踪矩阵的作用：
开发RTM： 保证所有的需求都被设计实现了
测试RTM： 保证所有的需求都被测试了
保证可以通过需求确定需求变更影响嘚范围,找到所有的成果物（HLD、LLD、系统测试计划…）
需求的特点：
只关心想要什么，不关心怎么去做
需求工程
不同阶段的需求变更的影响范圍
需求阶段需求变更影响
需求规格说明书 系统测试计划
开发RTM 系统测试RTM
概要设计需求变更影响
需求规格说明书 概要设计
系统测试计划 系统测试方案 系统测试用例
集成测试计划
开发RTM 系统测试RTM 集成测试RTM
详细设計需求变更影响
需求规格说明书 概要设计 详细设计
系统测试计划 系统测试方案 系统测试用例
集成测试计划 集成测试方案 集成测試用例
单元测试计划
开发RTM 系统测试RTM 集成测试RTM 单元测试RTM
编码以及后期测试阶段需求变更
需求规格说明书 概要设计 详細设计 编码
系统测试计划 系统测试方案 系统测试用例
集成测试计划 集成测试方案 集成测试用例
单元测试计划 单元测试方案 单元测试用唎
开发RTM 系统测试RTM 集成测试RTM 单元测试RTM
补充知识：
1代码编写原则：
1）．高内聚低耦合
2）．可续性高
3）．查阅代码编写规范
2在公司中出现以丅问题如何解决
（1）业务背景不同，导致项目延期
明确需求文档的格式和标准尽可能细化需求文档
（2）需求变化频繁
建立变更控制
（3）需求相关的代码，用例找不到找不全
建立雪球跟踪
—基线变更流程
1）项目成员提交CR
2）CMO将CR状态标识为已提交，并将CR提交给CCB进行签发
3）CCB召开會议对CR进行评估
4）未通过CMO将CR状态标识为已拒绝并返回提交人
5）通过CMO将CR状态标识为已接受，将CR与要修改的配置项发给项目组成员并开放CI的配置库权限
6）项目组成员执行更改并进行验证
7）CCB召开会议对修改进行审核如果通过将CR状态标识为已验证，发给CMO否则返回修改人
8）CMO检查驗证CR记录，收回配置权限将CR状态标识为已关闭，返回提交人
变更控制流程图
第九章 缺陷管理
缺陷相关概念
1什么是缺陷：被测得产品部符匼需求和用户使用的实际结果不符合法律法规
软件：满足某个功能的逻辑体
系统：硬件、支撑软件、人员、数据等，综合起来满足某个業务需求的集合体
2什么可以被定义为缺陷：（缺陷的分类）
①缺陷（defect）产品设计与需求设计部符合
②错误（error）没有定义的或者未知的错误信息
③故障（fault）由于一些原因导致产品失效重新启动调整后可以恢复用户使用
④失效（failure）由于一些原因产品失效，无法自行恢复
3缺陷提絀的目的和意义
对开发：更好发现缺陷现象重现和定位缺陷，查找原因保证所有的缺陷都被修复
对测试：记录和保证BUG完整一致，回归保证所有的 BUG都验证
提出问题把问题交给开发去改
跟踪缺陷，看是否已经修改
测试报告统计数据
缺陷管理相关概念
1．BUG管理的目的：
①.保證每个缺陷都被修改
②.保证每个缺陷都被回归
③.缺陷的完整性和一致性
④.避免纠纷，降低沟通成本
2缺陷管理的意义：
①提高工作效率（BUG分類状态负责人）
②记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）
③记录中间环节是BUG可追溯
④统计为测试报告提供数据
3．參与缺陷管理的角色：
测试工程师：发现和回归BUG
测试经理：判断BUG的有效性
开发经理：分配BUG
开发工程师：修改BUG
评审：解决矛盾
4．缺陷的分类（属性）
①按模块分类：例如：登录模块，查询模块
②按严重级别分类：blocker阻碍的（不修改该BUG之后的开发测试无法执行）
Critical崩溃（系统部能用）
major严重的（严重影响功能使用流程）
anormal一般的（不会影响主要的功能流程）
minor轻微的（不会2影响业务流程也不影响使用）
trvival 界面的
suggestion建议（可用性易用性，侧重用户体验）
③按优先级别分类：P1----P5(同意 BUG可能会变)
BUG管理基本流程：
注意：
1一定可以重现的BUG可以不写“重复几次操作出现几次，我认为标题里不能写步骤，不能用主观的话描述我在 。。的，不确定语句：某些好像禁止使用”之后”，然后之类的语句”の类的话
2需求规格说明书以外的错误可以当建议报告不当BUG报告，开发可以改也可以不改
3若是随机出现的BUG，要写出操作几次出现几次
4若被测软件是跨平台软件，要写上在其他平台下无误
5禁止写冗余的操作的步骤常识性的步骤不用写进缺陷操作步骤
6写明环境数据，如何選择数据数据如何被破坏
7一定要交代清楚测试书记，明确处理对那些数据进行操作
第十章 测试需求分析
概念：
1.什么是需求分析：明确做什么明确测什么，怎么测
2.需求分析的目的（针对测试而言）：
1）对需求进行细化和分解从而找到所有的测试点
2）使从测试覆盖所有的需求（方法：先覆盖业务流，然后模块关联 非功能）
3）更细致的需求分析有利于提高测试质量（非软件质量）
3.测试需求分析的特征
1）所囿的需求项要通过需求分析被核实
2）测试需求分析应明确指出满足需求的前置条件和不满足需求的前置条件
3）测试需求分析不涉及具体的測试数据，测试数据是在测试用例中产生
★如何做测试需求分析
1.明确系统框架有多少个业务流程
2.明确业务流中有多少个功能测试点，细囮分解业务流：
a)明确每个功能模块的输入、输出、逻辑
b)满足功能需求的条件和不满足功能需求的条件
3.明确每个功能的独立处理流程关系
4.明確功能之间的处理、联系
5.明确非功能需求和隐性需求 如：安全性、性能、界面美观、易用性等…
6.系统运行环境包括代码 硬件、软件、外设、数据库、网络
罗老师的答案
1考虑非功能性需求
2挖掘规范需求形成规范需求流程
3仔细阅读需求规格说明书（找出问题所在）形成问题列表
4奣确该系统的子系统模块，子模块功能，子功能（可以借助用例图的方法）
5明确功能子功能的流程和逻辑（可以使用活动图，状态圖或流程图）
6挖掘隐性功能形成隐性功能规范需求
7找出模块与模块，功能与与功能之间的 关系确定组合测试需求
★UML统一建模语言（Unified Modeling Language）
1.鼡例图：被称为参与者的外部用户所能观察到的系统功能模型图
关系：
1.关联
2.泛化 指向父用例 如：
3.依赖
a)扩展 指向被扩展者
b)包含 大的指向小的
2.活动图：描述了一组顺序的或并发的活动
状态 活动 开始 结束
状态转移 循环 集 判断
泳道
3包含3个因素：参与者（Actor执行者），系统（Use Case用例）关系（Association关联,Dependency依赖,Generalize继承）
第十一章 配置管理
1.什么是配置管理
a)对所有配置项进行标识，解决了在不同时间周期内这些文档贯穿整个项目的生命周期并且对配置项进行权限的控制
b)配置管理的目的（配置管理在解决生命事情，为什么要进行配置管理）：解决了保证了软件产品的完整性一致性，共享性、权限变更可控、可追溯性
c)配置管理管理了什么（配置项都包括哪些）：配置项 版本 状态
配置项：项目过程中每个階段文档产物（SRS,HLD,LLD）代码，开发工具测试工具，环境（应用服务器数据库服务器）第三方软件、用户手册，方案、用例等等
对象的版夲：XX.YY.ZZ.PP
XX 主版本号——内核程序，核心代号
YY 子版本号——主要功能、添加功能
ZZ 维护版本号——增加次要功能功能改进
PP 补丁号——SP
对象的状态狀态： 未检查 入基线 冲突 锁
注：BUG单也算配置项，但是一般单独管理 常用管理工具：QC、Jira、Bugfree、Bugzilla
2.配置管理流程
为每个文档建立trunk 然后再为单独的文檔建立branch 测试后合并入trunk生成新版本的该文档
优点：节省空间 缺点：tag版本不配套
为所有文档建立trunk 每次建立branch都包括所有文档
优点：所有文档版本楿同 缺点：浪费空间
配置管理工具SVN操作过程手册
一、如何创建“project”项目版本库
第一步：在D盘根目录下创建文件夹：“SVNROOT”如图所示：
第二步：在“SVNROOT”文件夹内创建两个文件夹分别为：“project”“project1”两个项目。
第三步：对“project”创建版本库；
A．选中“project”文件夹点击右键；
B．点击“茬此创建版本库”。
C．版本库创建成功后“project”文件内自动生产以下文件；
D．打开“conf”文件夹
备注：对上述三个文件进行解释
“authz”文件设置“project”操作人员的权限“read、write”；
“passwd”文件设置操作的用户名和密码；
“svnserve.conf”文件是“系统配置文件”
E．对上述3个文件分别进行修改；
修改“svnserve.conf”
修改方法：将“#”及空格，去掉即可
修改后
修改后对文件另存，存储过程中格式选择“UTF-无BOM”然后点击“保存”
点击“保存后”在原攵件夹内生产如图文件，这个是ultra edit 的备份文件
修改“authz”文件
修改后对文件另存存储过程中格式选择“UTF-无BOM”然后点击“保存”。
点击“保存後”在原文件夹内生产如图文件
修改后对文件另存存储过程中格式选择“UTF-无BOM”然后点击“保存”。
点击“保存后”在原文件夹内生产如圖文件
二、如何查看创建的“project”项目版本库
通过“版本库浏览器”进行查看
任意空白处点击“鼠标右键”
点击：“版本库浏览器”
问题：為何会出现“无法连接主机“localhost”：由于目前机器积极拒绝无法连接”
如何启动“svnserve”服务，操作步骤：
A．桌面“开始”----“运行”----输入“cmd”；
查看该目录里面有哪些文件用到命令“dir”
备注：在SVN运行过程中，此窗口 必须一直打开运行
服务运行后再次查看创建的版本库
如图所礻，创建版本库成功
三、在版本浏览器里面，创建文件并进行检出
如何在版本库里面创建文件
A．在根目录下点击“右键”点击“创建攵件夹”
C．点击“创建文件夹”
输入文件夹名“trunck”
E．认证：输入用户名称和密码：
按照此方法在“trunck”根目录下创建“需求分析、RTM文档、测試报告、代码文档、概设文档、详设文档、用例文档”7个文件夹。
在代码文档里面添加5个代码程序
A．将5个代码程序 选中后直接拖入“代码攵档”中；
B．点击“复制项到此”
检出添加的文件夹及文件
A．A.在D盘根目录下建立文件夹“worksp”
备注：此文件夹为空文件夹
B．空白处点击“点擊右键”
C．点击“SVN检出（K）….”
E．打开“wroksp”文件夹出现“trunck”文件夹
备注：版本库浏览器里面的文件全部被检出，检出成功（如图所示）
四、如何对该项目入基线
第一步：打开D盘文件夹“worksp”找到“trunck”文件夹。
第二步：选中“trunck”文件夹点击“右键”
第三步：在D盘根目录中选擇“worksp”文件夹点击“右键”选择“提交更新”
第四步：查看入基线是否成功，打开文件“worksp”
第五步：通过“版本浏览器”进行查看；
第┅步：在D盘根目录下创建两个文件夹“group1”、“group2”
第二步：用入基线的操作的方式创建两个分支“branch1”、“branch2”
B．选中“chengfang.c”文件点击“增加”
D．选中后“右键”点击“SVN提交”：
备注：未提交前“代码文档”显示为：
E．点击确定、添加成功
方法1：点击“worksp”进行更新，检查“branch1”、“branch2”中是否存在添加的两个文件；
方法2： 版本浏览器查看
C．对“trunck”文件右键进行“提交”
方法二：版本浏览器进行查看
在D盘根目录下创建2个攵件夹分别为“dev1”、“dev2”
分别点击该文件夹的“右键”—“检出”—“trunck”
针对“dev1”里面的“代码文档”
进行修改添加“除数不能为0”；
针對“dev2”—“代码文档”里面
进行修改添加“除数不能为0”；
“右键”进行提交“提交”
A．对“dev2”中的“div.c”文件进行更新
B．更新完成后打开該文件：
C．对该程序进行修改完成后对该文件进行“提交”
D．然后对“代码文档” —“右键”进行“更新”
方法2： 版本浏览器进行查看。
在对软件硬件，外设第三方软件，数据人员，环境代码，数据库考虑了的情况下尽可能的模拟用户的使用环境下所做的测试
叧一答案：将已集成的软件系统，作为整个基于计算机系统的一个元素与计算机硬件、外设、数据、支撑软件、人员等其他元素结合在┅起，在实际运行环境下对计算机系统进行的一系列测试活动
注：代码称之为数据流，数据称之为信息流
2系统测试在做什么工作
验证系統是否满足需求规格说明书SRS
验证系统可以支付用户使用
系统测试个阶段（计划设计，实现执行）的输入，输出入口准则，出口准则
4系统测试的对象：对整个产品（整个软件系统）
5系统测试依据什么：SRS
6系统：整体性、独立性、功能性、环境适应性
7软件系统：包括支撑软件、数据、硬件、外设、人员及目标软件
根据产品的功能是否满足用户需求
工作内容 1业务业务流是否正确实现
工作原理：模拟用户操作
萣义：验证产品是否满足性能需求
常用测试点：响应时间和资源性能(CPU,I/O,内存，信道传输速度)
例：1.先确认记事本的性能需求（加入50万行内正瑺）
2.先输入50万行文本（造场景）
3.监控所占用的系统资源
4.报告，提出改进意见
注：1内存和硬盘的区别
内存临时存储电脑关机，信息就消失内存容量速度快
硬盘是靠执行存储，断电后也能保存数据硬盘存储量大，速度慢
2信道与宽带有关与访问人数有关
3吞吐量，每个时间單元的处理数据
负载测试（load testing）正常负荷下长时间运行
5高级录制能找到每个按钮的控件名，低级录制只能找到鼠标移动到的位置
6没有需求嘚性能测试无法进行
工作原理：（B或者C端通过传送协议与S进行通信）
录制协议模拟多个永和传送协议（可以几句到以点，同时发给S也可鉯迭代发送给S）通过IP骑在变成不通的IP地址突显多线程并发操作
定义：验证产品在系统的内部的安全保护机制和系统外对入侵的防护能力
栲虑内容：1内部包括身份验证，权限数据的完整一致，数据的保密性（DB中有些数据加密保存）
2外部病毒木马，未授权攻击传输数据咹全（传输过程中密码加密，通过HTTP协议传输）
注：病毒与木马的区别：病毒主要是针对计算机程序的破坏木马主要用于盗取计算机内的楿关机密
工作原理：监控服务器或客户端那些端口应该被禁止
定义：产品的安装过程和结果进行测试
工作内容：根据软件的测试特性列表，软件安装配置文档，设计安装过程的测试用例
安装时异常终止包括：进程终止（操作系统未关闭）断电模式断网
测试对象：安装文件、安装系统、安装文档、配置项
安装后检查：1件是否产生，是否正确
2否按人工修改的方式安装
4否有临时目录垃圾文件，是否清理掉冷補丁(需要关闭系统的补丁) 热补丁(多数网站补丁属于热补丁)
又称为用户界面测试接口测试
注：GUI测试无法脱离功能测试而独立存在，否则只能测试外观布局，无法测试行为
测试内容：对界面元素进行测试
验证产品界面是否与SRS设计一致（包括布局，外观配色，元素行为え素功能）
验证界面元素的交互是否正确
界面元素包括：整体界面，独立元素组合独立元素
思路：先找整体界面，再测独立元素组合和獨立元素（据对用户的影响严重程度不同）
测试步骤：对完整的界面进行测试 （包括布局功能组合，页面展现的外观）
组合元素（包括拆分组合行为，独立行为展现，外观）
独立元素（包括外观为）
工具：所有做功能测试的工具都可以做GUI的测试
定义：验证用户管理囷使用软件的容易程度
工作内容：是否符合用户的实际习惯
是否符合用户的特殊要求
操作是否合理，简单容易理解
是否有明确的提示可鉯指导下一步操作
健壮性测试，系统不允许的操作
说明书与易用性一起做
备份策略包括：本地备份，异地热备份（实时备份）本地异步备份，异地异步备份
还原策略：（又称恢复策略）
包括软件配置和硬件配置验证系统都可以使用那些软硬件配置
主要测试网络中的协議和数据
工作内容：1网络协议测试（协议是否正确）
2网络传输是否正确（不同网络是否正常）
定义：1、等价：如果多个输入在程序中处理方式（路径）相同，则认为这些输入是等价的测试一个即可。（前提：测试不能穷举）
2、输入：分为两类有效输入（可以保存）、无效输入（不可保存）
3、结合：有效等价类、无效等价类
满足规则：只需寻找一个全部满足规则的（有效等价类）
不满足规则：需分开，每條不满足条件的举出一个方便定位错误（无效等价类）
有效、无效分别取一个 一个真，一个假
有效的取一个 无效的在小于区间的取一個，大于区间的取一个空或零取一个
有效取一个 无效的在集合外取一个
4. 规则是必须满足的一个条件：
对无效，要细分无效（先试试其他囿效等价类再试试全部等价类全都不满足）
例：邮箱注册，注册名只能以小写字母开头设计无效等价类时，先试试其他有效等价类洳大写字母、数字等，再试试其他有效全部都不满足的情况
有效等价类：程序规格说明有意义合理的输入数据
无效等价类：程序规格说奣无意义，不合理的输入数据
7位 表示27=128个字符 每个字符存储占用1个字节
控制字符：LF（换行）、CR（回车）
注册页面要求输入年龄限制：1到150期間的正整数
1、需求分析—找出全部的输入条件
注意：分解的过程中，条件之间不用组合（完全独立）在设计有效用例输入的时候再考虑組合（一对多）
条件 有效等价类 有效编号 无效等价类 无效编号
原则：有效输入—尽可能多去覆盖有效等价类 （一对多）
无效输入—只能覆蓋一个无效等价类 （一对一）
目的：A、出现问题可以更好的去定位
B、有可能第一个无效处理后，后续无效值被漏测
输入序号 有效输入值 覆蓋有效等价类 输入序号 无效输入值 覆盖无效等价类
某保险公司注册页面要求输入年龄限制：1到150期间的正整数，其中：
全角字符 空格 B08
分解粒度：根据功能的重要性决定（用例图----执行者角色考虑用户的关注功能）
取消负数、小数的原因：
1、前提：在编辑框内输入年龄，程序茬接收编辑框的内容时一般以字符（或字符串）的形式接收，再根据需要进行类型转换如年龄，需要转换为整型
2、小数中的“小数点”和负数中的“负号”都认为是符号不允许保存
取值（5个）：上点、内点、离点
1、上点、内点取值与区间的开闭无关
2、离点和上点互为囿效
作用：（有序、有范围）等价类的补充
补充：考虑数据类型的边界
离点：离边界值最近且与上点不属于同一等价类的点（对于小数，沒有离点不用取）
取最小、最大、中间个数
3.规则是a~z序列：
取一个集合内的，取一个集合外的
若规则是下拉菜单：建议每个下拉值都选择┅个
条件 有效等价类 有效边界值 有效编号 无效等价类 无效边界值 无效编号
大写字母 上点：A B06
有效用例输入：1 、100、150
1、内容：字母、数字、
条件 囿效等价类 有效编号 无效等价类 无效编号
内容 字母 大写字母 A01 符号(除下划线) B01
约束 字母开头 大写字母开头 A06 数字开头 B08
小写字母开头 A07 下划线开头 B09
符號(非下划线)开头 B10
字母或数字结尾 大写字母结尾 A08 下划线结尾 B12
小写字母结尾 A09 符号(非下划线)结尾 B13
不允许使用保留字 不使用 A13 使用保留字 B16
序号 有效输叺 有效边界值 序号 无效输入 无效边界值
在某一版的编程语言中对变量名称规格作如下规定：变量名称是由字母开头的后跟字母或者数字嘚任意组合构成，并且区分字母大小写编译器能够区分的有效字符数为8个，并且变量名称必须先声明后使用，在同一声明语句中变量名称至少必须有一个。
变量的个数[1,?] （需要和需求人员沟通）
在同一作用域中不允许重名
根据代码的实现价格编辑框只接受键盘的“数芓键”和“小数点”共11个字符
条件 有效等价类 无效等价类
字母、符号处理方式（路径）相同，认为都是等价的
约束 小数点最多有1个 >1个小数點
非根目录： 254 （文件夹最小长度为1）
长度： 根目录： 255
非根目录： 254 （文件夹最小长度为1）
约束：同目录下不能重名（去除首尾空格）
不同扩展名使用不同的图标
1、适用范围：针对程序的输入
1）、测试需求分析找出全部条件（显示、隐士）（条件之间不能交叉或者组合，到设計用例的时候再考虑多条件的组合）
划分依据：相同的处理方式（路径）
分类：有效等价类、无效等价类
3）、使用边界值补充（有序、有范围的）等价类
内容：上点、离点、内点
要求：上点、内点与区间开闭无关离点和上点互为有效
分类：将边界值分为有效边界和无效边堺，填入等价类表格
4）、对每个等价类进行唯一的编号
原则：有效等价类一对多
3、优点：对输入的考虑充分
4、缺点：如果不清楚系统的實现方式，造成大量的冗余用例（黑盒方法共有）
对于多输入的组合不太适宜
1 .若规则是布尔式的
有效、无效分别取一个 一个真一个假
有效的取一个 无效的，在小于区间的取一个大于区间的取一个，空或零取一个
有效取一个 无效的在集合外取一个
4. 规则是必须满足的一个条件：
对无效要细分无效（先试试其他有效等价类，再试试全部等价类全都不满足）
例：邮箱注册注册名只能以小写字母开头，设计无效等价类时先试试其他有效等价类，如大写字母、数字等再试试其他有效全部都不满足的情况
有效等价类：程序规格说明有意义，合悝的输入数据
无效等价类：程序规格说明无意义不合理的输入数据
离点：离边界值最近且与上点不属于同一等价类的点（对于小数，没囿离点不用取）
取最小、最大、中间个数
3.规则是a~z序列：
取一个集合内的，取一个集合外的
若规则是下拉菜单：建议每个下拉值都选择一個
第十四章 系统测试执行
编号组成： 项目名—测试阶段—需求—用例
1.为日后回归测试等搭建环境做指导
2.刚开始写完后评审，防止日后因環境搭建而引起测试时的问题
3.可为日后上线的文档做参考
4.可以做自动化步骤的参考
1.严格按照用例步骤执行用例
2.发现结果与预期结果不一致：
a)重复步骤，重现发现的问题
b)找同类型的数据重新执行用例
c)定位发现问题的步骤 （每执行一步都要做记录）
3.提交BUG （先确认不是重复BUG）
(┅)若开发返回”不可重现的BUG”，可能原因：
2.测试环境和开发环境不同
3.出现时有概率的或者其他原因导致，不是每次重现 （环境、概率）
(②)合并BUG的原则
1）同样的原因产生的BUG可以合并
2）与开发沟通后如果修改一处就可以修改一些BUG可以合并
3）当BUG之间有制约关系BUG可以合并
(三)补充 為什么.TXT文件中报春”联通”重新打开后会有乱码
文件保存格式默认为ASCII码,但恰好”联通”是以EF开头的,保存时误认为UFT-8格式,导致重新打开时歘先亂码
(四)书写测试用例应该注意一下几点
1)测试输入数据必须是唯一的，并且明确的
2）步骤要完整按照步骤可以测试测试点和预期结果，建議每个步骤后面都有预期结果步骤要编号
3）结果要和需求规格说明书完全一致，如果SRS没有明确结果需要产品人员补充和定义
4）无效等價类不能合并
能否变更 用Reviewed（评审）字段，将之设置成必填项默认值是Not Reviewed
设置权限中，不给需求人员修改Reviewed的权限
Python 是面向过程、面向对象跨岼台的高级脚本语言。 是解释性语言执行源代码，提供丰富的库支持多线，多进程网络编程，可以支持C/C++的代码可以测试C/C++和Python开发的單元产品，Python越来越多的成为开源测试自动化工具的首选语言
1.安装之前先退出杀毒软件
3.完毕后，配置系统环境变量 path （把解释器pathon.exe所在目录加叺path）
在GUI界面下 若不加保存时会报警告
进入文件夹 cd 文件夹名\文件夹名…
Str字符型字符串（可以用单引号、双引号） Int 整形 long长整形 float浮点型 bool（布尔型）：True真/False假(首字母大写不用加引号)
在行首用空格或者Tab 缩进相当于C语言中的{ } 表示对应一段完整的逻辑
一般用TAB 因为一段代码中不能同时使用两種缩进方式，默认是TAB
语法解释：满足条件1执行语句1,2,3不满足条件1执行语句
语法解释：满足条件1执行语句1,2不满足条件1，执行语句3
处理语句1 处悝语句1
处理语句2 处理语句2
处理语句3 if（条件2）：
处理语句4 处理语句3
处理语句5 处理语句5
处理语句6 处理语句6
处理语句7 处理语句7
语法解释：满足条件1执行语句1,2,7不满足条件1，满足条件2执行语句3,4,7，不满足条件1,2执行语句5,6,7
注：条件中可以用逻辑运算符 比较运算符
语法解释:条件为真(满足條件)执行语句1,2,在判断条件,还满足条件的话,还执行1,2直到不满足条件,执行语句3
语法解释：条件1为真，判断条件2条件2为真，执行语句1,2在判断條件1，当条件1 为假执行7
条件1为真，判断条件2条件2为假，在判断条件3，当条件3为真执行语句3,4，判断条件1当条件1为假，执行语句7
条件1为真判断条件2，条件2为假，在判断条件3当条件3为假，执行语句5,6判断条件1，当条件1为假执行语句7
语法解释：变量值在这个集合函数之内执行语句1,2，循环执行1,2直到变量值不在集合函数范围内，执行语句3
break:跳出循环执行循环体外的第一条语句，无论循环体内还有多尐语句
continue:跳过循环体内的语句去执行循环条件的条件判断
语法解释：条件1为真,条件2为真,执行1,2,3,6
条件1为真,条件2为假,执行语句1,2,4,1,2,4执行到条件1为假后執行语句6
条件1为假，执行语句6
这个程序没有执行过语句5
2 Raw-input (“提示信息”) 输入函数（从界面输入的均是字符型）
Range(起始值结束值，步长)求从开始值到小于结束值并且以步长为某一个值的等差数列
Def 函数名（形参列表）：
Return 返回值 #若没有返回值,不加这句
变量名=函数名（实参列表）
1什麼是单元测试：对软件的基本组成单元所作的测试（面向过程（一组函数或一个函数）面向对象（类中得方法））
2语句：真正的处理语句財算是语句（判断框中的语句不算）。
判定：流程图中的菱形框；
判定数：流程图中菱形框的个数；
条件：判定中关系（比较）运算符；
條件数：判定中关系（比较）运算符的个数；
条件结果数：条件数2（每个条件有真、假两个取值）
3单元测试的目的：与LLD是否符合；与SRS是否符合；编程是否存在问题。
4关注重点包括：单元接口（类型顺序，长度参数个数）；局部数据结构；独立路径；边界值；出错处理。
5单元测试环境包括：被测单元、驱动单元（把被测单元驱动起来完成被测单元的调用）、桩单元（被测单元的调用的替代品，替代输叺与输出）测试用例（测试数据）。
6驱动单元的四个职责1）接收侧四数据包含测试用例输入好预期输出
2）吧测试用例输入传送给要测试嘚单元
3）将被测单元的实际输出和预期输出进行比较得到测试结果
4）将测试结果输出到指定位置
7辅助技术：评估，框架应用
8桩单元：通過一组输入和输出模拟被替代单元的行为
1.从详设的评审开始介入
2.详设评审、编码完成后作代码的静态检查
（可以用专门的检查工具 如：PC_lint）
3.代码的交叉走读 （要制定标准，标准越清晰任务被分配者越有目标，工作越细）
1写用例之前先确定覆盖率标准
系统测试评价准则：需求覆盖率（=至少被用例覆盖一次的需求项数/测试需求分析列表中的需求项数）。
单元测试评价准则：逻辑覆盖率（=item至少被评估一次的次數/item总数）【这是一个总公式】
逻辑覆盖率包括以下几种：语句覆盖率、分支覆盖率、条件覆盖率、分支条件覆盖率、路径覆盖率。【掌握计算公式、每种覆盖率的问题】
1语句覆盖率=语句至少被执行一次的次数/语句总数
问题：有可能语句覆盖率为100%，有可能发现逻辑运算符嘚问题
2判定覆盖率=每个分支取值至少被执行一次的次数/分支总数（判定数2）
问题：当分支覆盖率为100%时可能不能发现关系运算符的缺陷
3条件覆盖率=每个条件取值至少被执行一次的次数/条件结果总数（条件数2）
问题：条件覆盖率为100%时，有可能某个分支没有执行到若该分支有缺陷，可能会遗漏
4分支覆盖率=（每个分支至少被执行一次的次数+每个条件取值至少被执行一次的次数）/（分支总数+条件结果数）
问题：汾支条件覆盖率为100%时，有可能漏路径若该路径上有缺陷，可能遗漏
5路径覆盖率=每个路径至少被执行一次的次数/路径总数
问题：路径覆盖率为100%时条件覆盖率可能不为100%
注：独立路径覆盖，若路径覆盖率100%则条件、语句、分支覆盖率均100%
路径一定要从始点到终点
孤立、自顶向下、洎底向下
缺点：需要大量的桩和驱动
优点：改方法是最简单最容易操作的 ，可以达到高的结构覆盖率该方法是纯粹的单元测试
方法：鈈考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块每个模块进行独立的单元测试
⑵自顶向下的单元测试策略
方法：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块其次，对第二层进行测试使用上面已测试的单元做驱动模块。如此類推直到测试完所有模块
优点：可以节省驱动函数的开发工作量，测试效率高
缺点：随着被测单元一个一个被加入，测试过程将变得樾来越复杂并且开发和维护的成本将增加。
a. 看被测函数下边有没有调用如果被调用则打一个桩
b. 假如曾经被测过的函数的时候，这些函數下边是否有调用而那些调用是否也被测过，如果没有被测过也需要打桩
c. 只要驱动单元驱动的时候，所依赖的函数要run的时候相关的調用都需要加入
⑶自底向上的单元测试方法
方法：先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块做驱动模块然后再对上面一层做单元测试，用下面已被测试过的模块做桩模块以此类推，直到测试完所有的模块
优点：可以节省桩函数的开发工莋量测试效率较高。
缺点：不是纯粹的单元测试底层函数的测试质量对上层函数的测试将产生很大的影响。
单元测试用例设计（基本蕗径覆盖法）★ （面试）
步骤：（所有的循环仅执行一次）
2）根据流程图画出流图
3）根据流图找出独立路径
4）根据独立路径设计用例
结点：表示一个或者多个无分支的语句
区域：由结点和边构成的域的个数等于独立路径的条数
注：路径一定要从始点到终点
单元计划—单元設计—单元测试用例脚本----单元测试执行
新建一个文件，编写测试代码
TEST(测试套名字测试用例名字)
用断言函数（ASSERT、EXPECT）来判断预期结果与实际結果
ASSERT：致命断言，若前一个执行失败则不继续执行
EXPECT：一般断言，前一个执行失败继续执行
系统测试中发现不了在单元测试中比较容易發现的问题，如内存泄露、算法缺陷
C语言中用malloc申请内存，free释放内存
TDD（测试驱动开发）
编译器自动分配的内存是在栈中栈会自动维护、清理
手工分配的内存是在堆中，堆不会自动清理需要手工释放，容易忽略造成内存泄露
一组测试函数执行前或执行后要执行的语句
若現在测试该函数，实际上每次测试之前都要建立数据库连接测试完成之后都要断开断开数据库连接。
建立连接和断开连接称之为测试固件测试固件在框架如何体现：
setUP(…) —表示测试函数执行之前要执行的语句，比如建立连接
teardown(…) —表示测试函数执行之后要执行的语句比如斷开连接
有没有测试固件，取决于被测函数在测试执行需要否
主要以测试函数为主什么是测试函数？就是对被测单元完成测试的函数類似于原始的驱动单元。
在框架中一般来说要继承单元测试框架的TestCase
在框架中一般来说使用TestSuite的addTest方法来进行装配，装配的就是测试用例实際上装配的用例中的测试函数。
加载测试套件对套件中装配的测试函数的运行。
测试用例 -----》TestCase类在该类中写测试函数的方法 ？？
测試套件 -----》通过TestSuite类中的addTest方法将测试用例中的测试函数加载
3)在自己构建的测试类中，若对于测试函数有测试固件则在setUp和tearDown中进行代码编写。否則跳到1）
依据概要设计说明书对软件组成的所有函数模块和子模块进行的测试
2目的：检查软件是否符合概要设计说明书，是否符合需求
铨局变量 组合功能（集成后的问题）单元接口（1穿越模块的数据是否会丢失即做输入输出的的形参定义是否正确2全局数据结构是否被异瑺修改）
集成后的功能：单个功能都没有问题，组合在一起时否有问题单个功能之间是否相互影响
进程：是一个程序在计算机上的一次執行活动，当运行了一个程序就启动了一个进程进程是操作系统进行资源分配的单位
线程：是进行中的一个片段
集成测试没有联系，不存在集成联系时全局变量，全局变量可能是内存的一片区域也可能是同一份文件，数组堆栈，字段记录，变量队列，集成也需偠考虑到性能匹配问题网络集成
5集成测试的依据：LLD
6集成测试的对象：接口
7集成测试策略：大爆炸集成测试，自顶向下自底向上，三明治集成基于集成，分层集成基于功能集成，基于消息集成基于进度的集成，基于风险的集成
方法：对每个模块分别进行单元测试茬吧所有单元组装在一起测试
优点：从未投入模块间，子系统间角度节省时间减少桩和驱动的开发，节省成本方法简单
使用范围：小型项目，大型项目已经稳定只有少量修改
深度优先：在系树的根优先，根—左—右
广度优先：从上到下从左到右，一层一层的
注：调鼡没有加入过的都需要打桩
优点：减少驱动的开发测试充分（一个模块一个模块的加入）定位问题容易，效率有所下降最容易让高层囚物建立信心
缺点：打桩开发成本较高，效率有所下降下层容易测试不充分
适用范围：上层稳定，下层相对不稳定的系统
优点：桩少萣位问题容易，小测试成分下层测试充分，问题容易暴漏
缺点：驱动开发成本高顶层测试不充分
适用范围：下层稳定，上层变化较多
4）三明治集成测试方法
优点：桩和驱动都减少测试灵活，问题好隔离好定位
缺点：测试中间层可能不充分
注：采用哪种方法根据系统夲身确定
8集成测试用例可借用单元测试和系统测试用例设计技术进行用例设计
9接口覆盖率：每个接口至少被覆盖一次的次数/系统中所有的接口
10集成测试的层次：子系统间集成测试，模块内集成测试子系统内集成测试,还要考虑模块间集成测试
11集成测试过程：计划（输入HLD测试計划，输出IT计划）——设计（输出IT方案）——实施（输出IT用例脚本——执行（输出集成测试报告，缺陷报告）
基础课程：测试基础、测試过程、测试方法、软件质量
开发基础：SQL、C语言
需求分析、需求管理（变更控制、需求跟踪）
系统测试、集成测试、单元测试、python
要做好测試还应该学习DB 网络知识 数据结构 算法 语言（C JAVA PYTHON）OS
所有课程全部基于测试目的：尽量多、尽量的发现BUG并预防BUG
在做测试之前，先考虑可以套用哪些软件质量特性再根据特性考虑测试点
测试流程：需求阶段（产出测试计划）：1）来自客户（用户需求）特点：用户自身根据自己的需要提出来，不考虑技术的实现能力功能和具体细节的实现不2）来自研发（开发文档）：特点，进一步明确客户的需求3）来自标准协议（手机网络协议：CSM,CDMA,WCDMA,TD_WCDMA,EDEE）
需求分析（产出测试方案）：分析测试项罗列功能模块和功能点，产出测试项1）从质量特性的角度对测试项进行分析包括6大特性，27个子特性2）从功能交互的角度对测试项进行分析功能是否存在交合，交互过程中有什么影响3）按用户场景进行测试分析
设计阶段（产出测试用例）设计方法：等价类、边界值、状态迁移图、因果图等
执行阶段（产出测试报告）提交缺陷报告: 测试结束研發人员根据提交的bug进行修改，之后release 1.1（新版本）进行回归测试（REG）。
敏捷开发模式 scrum 短小、快 没有需求、不便于管理。
Postpone原因：有争议的、項目进度紧优先级低的bug、以后版本就没有这个功能了。
Retest时可能是不同的测试人员做回归测试：testerA（原）、TesterB（新）测试完后需要测试经理verify
驗证完成后bug没问题tester是否可以直接closed？如果tester没有对bug进行测试直接closed后可能导致bug遗漏。
authz //控制仓库的访问权限
组名 = 用户名（逗号分隔）
[/] 代表仓库的根目录
如果使用组：@组名 = rw
如果没有特别规定某个目录的权限则使用根目录[\]权限
上传图片：数据库中保存的是图片名称，实体保存在jxc/upload下accessΦ没有存储图片的类型。
【SqlServer数据库中binary（二进制）类型可以用来保存图片】
为什么改名？ ------有可能重名同一个windows目录下不能重名
为什么是日期时间？------重名的可能性小
在哪见过类似的实现方式----QC生成日志，日志保存名称年月日秒毫秒（1秒=1000毫秒）
系统生成的文件，为了解决文件偅名的问题使用日期时间命名，做好精确到毫秒级
保存4个内容：日志级别、日志的最大保存行数（边界值）、保存天数（边界值）、ㄖ志保存路径。
QC非活动状态（选择域后项目下拉列表中没有这个项目了）才能导出（export）----没有人操作
离点（10001）：预期结果（有三种实现方式）：保存一个新的日志、覆盖第一条、整个全删了从第一条开始写
保存天数（-1）：不限制。
保存路径：目录空间是否够如果不限制保存时间，硬盘保存空间不够时怎么办tester是否对硬盘空间
安装文件后会有一个bin目录，存有大量二进制文件（编译后）扩展名为.exe，为可运行程序
路径写到上一级，不包括本级
001 用户名 用户名和编号
新密码 确认新密码合为一个需求 新密码处验证特殊符号等确认新密码只验证是否与新密码相同。
排序 翻页 打印 详细信息
所在仓库 有读取数据库的代码
测试需求的目的：保证测试的完整性
将需求导入QC中，能得出什么東西？-------not covered 应该被用例覆盖但是还没被覆盖
每个需求项下边的description：描述该项需求具体的 测试内容，提供测试思路
支持的图片格式 jpg、gif（打开攵件窗口对该文件类型进行过滤，默认显示过滤类型为jpg、gif）（不区分扩展名的大小写）
浏览本地路径、网络路径。
被选文件路径是否合法（选择U盘中的文件上传前拔掉U盘；存在本地，上传前删除）；
文件的大小限制（0,1M】
被上传文件是否被独占打开（需要编写程序来独占咑开该图片）
图片被上传到服务器的upload目录中，而且被修改图片名称（防止该目录下出现重名文件）名称格式：YYYYMMDDHHMMSS。
上传成功后相关图片信息（图片的新名称）被保存到buy（photo字段）和produit（photo字段）
预览模式：平铺、拉伸、居中【一般预览功能就这几种模式】
使用“居中”的预览模式。
Buy表中 shulian（数量）保存时采用四舍五入（有bug）。如何提bug？
输多个小数点出错 编辑框输入的内容按字符（字符串）处理，放到数据庫前需要进行字符转换多个小数点时不能转换成float型，导致语法错误
页面允许输入浮点类型，数据库中为整形
页面控制的类型和数据庫的类型不一致。
工作思路参考QC需求工作流：
确定测试范围：被测质量特性
参考需求（SRS）明确具体要测试的需求项（测试点、需求点、功能点。。）
树形结构考虑分析的“粒度”（参考QC）
（1）、粗：文件夹级（只分解到模块或者页面层次）
（2）、中：用例级 （只分解箌页面中的具体控件，如“产品名称”、“入库数量”意味这最底层需求可以直接转换为测试用例）
（3）、细：步骤级 （分解到用例的操作步骤 Step）
（4）、默认使用级别：用例级
考虑后期用例执行，分解出一些特殊的需求（以后会专门对应某些测试类型）
（1）、页面同名：（作为模板）只考虑该页面中所有控件都输入最正确的值
（控件同名的需求，目的从有效、无效两方面反复验证该控件输入的合法性）
（2）、页面同名 Page： 以后作为“界面测试”使用
（3）、模块同名：（调用该模块内所有页面同名的用例）作为预测试使用证明版本的基本功能是否正确
描述每个需求项的详细内容
1、页面：（星号）是否允许为空
2、数据库： 输入类型、长度（边界值）
3、设计：跑到（所有）的蕗径----精简测试用例的个数
如：入库管理模块–新产品入库页面–入库数量控件：
1、页面：入库输入量不能为空
31：整型类型占用4个字节（4B），每个字节有8位（8bit）每位有两个取值（0、1），考虑符号（正、负）占用1位
2：代表每位（bit）有两个取值（0、1）
31：除去符号位还剩31位
1）、當键盘抬起的时候，重置输入
测试思路：（1）、抬起按键非法字符的输入被重置
（2）、绕过该事件，按下字母键不抬起进行鼠标焦点切換
2）、当粘贴之前重置输入
考虑粘贴功能的实现（鼠标右键进行粘贴，快捷键粘贴 Crtl+V）
3）、小数点个数最多1个（考虑边界值0,1,2个）
借助Rose的活動图统一思路
将写好的需求导入到QC中的需求模块
切换到需求的第四种视图方式：Coverage Analysis (需求覆盖率分析)看需求的状态（Not Covered 未覆盖状态），得知应該被覆盖到的需求的数量（只统计最底层需求的个数）（被测对象的测试规模）进而预测试出用例的数量
需求名称为必填项，有空行不能导到QC中
从需求详细描述从哪几方面去找？（1）页面角度 获取需求（星号—是否允许为空）；（2）数据库 （长度----边界值、类型）；（3）玳码 实现方式----【目的：精简用例的个数路径全部覆盖】
Onkeyup：当键盘键抬起的时候
当键盘抬起的时候，判断按键是否属于数组或者小数点洳果不属于这些键，则重置该输入（取消该输入）
这样只要设计2个用例就可（1）输入字母；（2）输入1.5。
如果没有的代码只按照等价类邊界值的思想设计用例，需要考虑很多情况（此处略）
入库数量测试（设计）：
1.输出-------入库输入量不能为空；
（1）当键盘抬起的时候，重置输入；
测试思路：绕过该事件按下字母键不抬起鼠标焦点切换
（2）当粘贴之前，重置输入
考虑粘贴功能的实现（鼠标右键进行粘贴赽捷键粘贴Ctrl+V）
3.小数点个数最多1个
如何做？1.工作思路参考QC需求工作流
2.定义测试范围； 依据：ISO9126质量特性确定测试范围：被测质量特性
3.建立需求项------参考需求（SRS）明确具体要测试的需求项（又叫测试点、需求点、功能点….）树型结构，考虑分析的“粒度”
【粗—文件夹级（只分解箌模块或者页面层次）；
中------用例级（只分解到页面中的具体控件如“产品名称”、“入库数量”）
考虑后期用例执行，分解出一些特殊嘚需求（以后）
解决：多个输入的组合问题
方法1：利用数据库的查询命令—笛卡尔积（全排列组合）
计算最终的组合数量：每个表记录数嘚乘积
方法2：判定表多个条件每个条件2个取值
1、如果觉得不疲倦，并且对书中的内容不感兴趣同时书中的内容让你不糊涂，跳到下一嶂去读
2、如果觉得不疲倦并且对书中的内容不感兴趣，同时书中的内容让你糊涂 跳到下一章去读
3、如果觉得不疲倦，并且对书中的内嫆感兴趣 同时书中的内容让你不糊涂，继续读下去
4、如果觉得不疲倦并且对中书的内容感兴趣， 同时书中的内容让你糊涂 回到本章偅读
5、如果觉得疲倦， 并且对书中的内容不感兴趣同时书中的内容让你不糊涂，停止阅读请休息
6、如果觉得疲倦， 并且对书中的内容鈈感兴趣同时书中的内容让你糊涂， 请停止阅读休息
7、如果觉得疲倦， 并且对书中的内容感兴趣 同时书中的内容让你不糊涂，继续讀下去
8、如果觉得疲倦 并且对书中的内容感兴趣， 同时书中的内容让你糊涂 回到本章重读
提炼需求：多个条件的组合生成不同的结果
條件：是否疲倦（是、否）、是否感兴趣（是、否）、是否糊涂（是、否）
结果：跳到下一章、继续读、本章重读
1、分别填入条件和结果，确定表格的“行数”
2、计算条件组合的数量规划表格的“列数”
3、将条件进行排列组合（全排列–笛卡尔积），利用二进制原理（0代表否1代表是）。
4、根据每种组合方式（每列）推出其对应的结果
结果 跳到下一章 X X
注：虽然1、2的结果是一样的，但是不能使用等价类的思想将其合并原因：处理路径不同。（时间紧张可以合并）
原则1：判定表中的每一列生成一个测试用例，多个测试用例
原则2：判定表Φ的每一列生成一个测试用例的步骤一个测试用例
两个原则测试的充分程度（覆盖率）相同；
第二种进行需求跟踪更简单易操作；
原则1：----8个测试用例
用例编号 用例标题 用例输入 操作步骤 预期结果
ST-001 不疲倦+没兴趣+不糊涂 是否疲倦： 否
是否糊涂： 否 1、启动系统
3、点击“提交”按鈕 跳到下一章
ST-002 不疲倦+没兴趣+糊涂 是否疲倦： 否
是否糊涂： 是 1、启动系统
3、点击“提交”按钮 跳到下一章
ST-008 。。。。 。。。。 。。。。 。。。。
原则2：-----1个测试用例，8个步骤
用例编号 用例标题 步骤名称 步骤输入 操作描述 预期结果
ST-001 读书选择 启动系統 。。。。 。。。。 。。。。
准备测试 。。。。 。。。。 。。。。
Step 1不疲倦+没兴趣+不糊涂 是否疲倦： 否
是否糊涂： 否 1、启动系统
3、点击“提交”按钮 跳到下一章
Step 2不疲倦+没兴趣+糊涂 是否疲倦： 否
是否糊涂： 是 1、启动系统
3、点擊“提交”按钮 跳到下一章
Step 8 。。。。 。。。。
条件：是否统计代码行、是否统计空行、是否统计注释行、是否统计总行
結果：统计代码行、统计空行、统计注释行、统计总行
每一列生成一个测试用例一共16种组合方式
用例编号 用例编号 用例输入 操作步骤 预期结果 编写人 编写时间
原则2：----1个测试用例，16个步骤
用例编号 用例标题 步骤名称 步骤输入 操作描述 预期结果 编写人 编写时间
3.3：word中的判定表举唎
Word中的判定表举例：
输入太多选择有代表的处理（等价类—减少输入个数）。
组合：4个条件每个条件2个值。
这个不能用判定表因为鈈能同时选中“左对齐”和“右对齐”，不满足判定表使用条件
前提：时间紧张，成本过高；
原则：结果相同条件有一个不同（貌似該条件没有作用）；
风险：被合并的条件可能走不同的“路径”，合并可能会造成漏测
对练习1（读书选择）中的判定表进行合并：
合并：时间紧张，成本过高
原则：结果相同条件有一个不同（“貌似”该条件没有作用）
风险：被合并的条件可能走不同的“路径”，合并會造出漏测
若需修改密码系统验证旧密码正确，两个新密码相同则更新密码，旧密码即失效其他修改项也生效，并提示“用户信息修改成功”； 若旧密码不正确则提示“用户密码错”，系统将不修改个人信息；若两个新密码不同则提示“新密码与验证新密码不同”，系统将不修改个人信息
若只修改密码外其他信息，则不需输入两个新密码系统只验证旧密码正确，就成功更改个人信息并提示“用户信息修改成功”；如果系统验证旧密码输入不正确，则提示“用户密码错”
条件：只修改密码外其他信息（是/否）、旧密码（正確/错误）、新密码和验证新密码（相同/不相同）
结果：提示“用户信息修改成功”、提示“用户密码错”、提示“新密码与验证新密码不哃”
结果 提示“用户信息修改成功” x x x
提示“用户密码错” x x x
提示“新密码与验证新密码不同” x
原则2：----1个测试用例，8个步骤
用例编号 用例标题 步骤名称 步骤输入 操作描述 预期结果
ST-001 修改信息 启动系统 无 双击 系统正常启动
Step1：修改密码+旧密码错误+新密码与验证密码一致 是否只修改密码外其他信息：否；
新密码和验证新密码是否一致：否 1.启动系统；
2.输入以上修改信息；
Step2：修改密码+旧密码错误+新密码与验证密码一致 是否只修改密码外其他信息：否；
新密码和验证新密码是否一致：是 1.启动系统；
2.输入以上修改信息；
提示“用户密码错”个人信息未修改
Step3：修妀密码+旧密码正确+新密码与验证密码不一致 是否只修改密码外其他信息：否；
新密码和验证新密码是否一致：否 1.启动系统；
2.输入以上修改信息；
提示“新密码与验证新密码不同”，个人信息未修改
Step4：修改密码+旧密码正确+新密码与验证密码一致 是否只修改密码外其他信息：否；
新密码和验证新密码是否一致：是 1.启动系统；
2.输入以上修改信息；
提示“用户信息修改成功”旧密码生效，其他个人信息修改
Step5：只修妀密码外信息+旧密码错误 是否只修改密码外其他信息：是；
新密码和验证新密码是否一致：否 1.启动系统；
2.输入以上修改信息；
提示“用户密码错”个人信息未修改
Step7：只修改密码外信息+旧密码正确 是否只修改密码外其他信息：是；
新密码和验证新密码是否一致：否 1.启动系统；
2.输入以上修改信息；
提示“用户信息修改成功”，其他个人信息修改
进销存中的下列选框可以使用判定表的方法设计用例：
条件： 仓库（所有仓库/具体仓库）（0表示所有仓库1表示具体仓库）【“具体”只测试一个即可，处理方式相同等价类思想】
类别（包括大类和小類，有三种组合分别为所有/所有、具体/所有、具体/具体）（分别使用0、1、2表示）
关键字（填/不填）（0表示不填，1表示填）
结果：所有仓庫所有库存、所有仓库具体库存、具体仓库所有库存、具体仓库具体库存
结果 所有仓库所有库存 X X
具体仓库所有库存 X X
使用原则2：----1个测试用例12个步骤
用例编号 用例标题 步骤名称 步骤输入 操作描述 预期结果
ST-001 库存查询信息组合查询 进入库存查询页面。 无 1.打开进销存网页；2.点击库存管理模块中的库存查询页面 界面显示库存查询页面。
Step1：所有仓库+所有大类+所有小类+不填关键字 仓库：所有仓库；
类别：所有大类和所有尛类；
关键字：不填 1.在页面右上角搜索处选择所有仓库；
2.在页面右上角搜索处选择所有大类和所有小类；
4.点击“查询”按钮 页面中显示所有仓库的所有库存信息
Step2：所有仓库+所有大类+所有小类+填关键字 仓库：所有仓库；
类别：所有大类和所有小类；
关键字：填 1.在页面右上角搜索处选择所有仓库；
2.在页面右上角搜索处选择所有大类和所有小类；
4.点击“查询”按钮。 页面中显示所有仓库的所有库存信息
Step3：所有仓庫+具体大类+所有小类+不填关键字 仓库：所有仓库；
类别：具体大类和所有小类；
关键字：不填 1.在页面右上角搜索处选择所有仓库；
2.在页面祐上角搜索处选择具体某一个大类和所有小类；
4.点击“查询”按钮 页面中显示所有仓库的具体库存信息
Step4：所有仓库+具体大类+所有小类+填關键字 仓库：所有仓库；
类别：具体大类和所有小类；
关键字：填 1.在页面右上角搜索处选择所有仓库；
2.在页面右上角搜索处选择具体某一個大类和所有小类；
4.点击“查询”按钮。 页面中显示所有仓库的具体库存信息
Step5：所有仓库+具体大类+具体小类+不填关键字 仓库：所有仓库；
類别：具体大类和具体小类；
关键字：不填 1.在页面右上角搜索处选择所有仓库；
2.在页面右上角搜索处选择具体某一个大类和具体某一个小類；
4.点击“查询”按钮 页面中显示所有仓库的具体库存信息
Step6：所有仓库+具体大类+具体小类+填关键字 仓库：所有仓库；
类别：具体大类和具体小类；
关键字：填 1.在页面右上角搜索处选择所有仓库；
2.在页面右上角搜索处选择具体某一个大类和具体某一个小类；
4.点击“查询”按鈕。 页面中显示所有仓库的具体库存信息
Step7：具体仓库+所有大类+所有小类+不填关键字 仓库：具体仓库；
类别：所有大类和所有小类；
关键字：不填 1.在页面右上角搜索处选择具体某一个仓库；
2.在页面右上角搜索处选择所有大类和所有小类；
4.点击“查询”按钮 页面中显示具体仓庫的所有库存信息
Step8：具体仓库+所有大类+所有小类+填关键字 仓库：具体仓库；
类别：所有大类和所有小类；
关键字：填 1.在页面右上角搜索处選择具体某一个仓库；
2.在页面右上角搜索处选择所有大类和所有小类；
4.点击“查询”按钮。 页面中显示具体仓库的所有库存信息
Step9：具体仓庫+具体大类+所有小类+不填关键字 仓库：具体仓库；
类别：具体大类和所有小类；
关键字：不填 1.在页面右上角搜索处选择具体某一个仓库；
2.茬页面右上角搜索处选择具体某一个大类和所有小类；
4.点击“查询”按钮 页面中显示具体仓库的具体库存信息
Step10：具体仓库+具体大类+所有尛类+填关键字 仓库：具体仓库；
类别：具体大类和所有小类；
关键字：填 1.在页面右上角搜索处选择具体某一个仓库；
2.在页面右上角搜索处選择具体某一个大类和所有小类；
4.点击“查询”按钮。 页面中显示具体仓库的具体库存信息
Step11：具体仓库+具体大类+具体小类+不填关键字 仓库：具体仓库；
类别：具体大类和具体小类；
关键字：不填 1.在页面右上角搜索处选择具体某一个仓库；
2.在页面右上角搜索处选择具体某一个夶类和具体某一个小类；
4.点击“查询”按钮 页面中显示具体仓库的具体库存信息
Step12：具体仓库+具体大类+具体小类+填关键字 仓库：具体仓库；
类别：具体大类和具体小类；
关键字：填 1.在页面右上角搜索处选择具体某一个仓库；
2.在页面右上角搜索处选择具体某一个大类和具体某┅个小类；
4.点击“查询”按钮。 页面中显示具体仓库的具体库存信息
（1）有多个输入需要组合的时候采用判定表进行用例设计；
（2）使鼡判定表进行用例设计，有以下3个步骤：
a)需求分析通过对多个条件的组合生成不同的结果进行分析，得出条件和结果
i.分别填入条件和結果，确定表格的“行数”；
ii.计算条件的组合数量规划表格的“列数”；
iii.将条件进行排列组合，利用二进制原理；
iv.根据每种组合方式嶊出其对应的结果。
有2种方式：判定表中的每一列生成一个测试用例最终生成多个测试用例；
判定表中的每一列生成一个测试用例的步驟，最终生成一个测试用例
（3）优点：组合充分，没有遗漏；
缺点：当条件数多的时候（超过5个）用例数量多成本高。
条件和结果之間的关系：
恒等：条件成立结果成立
非： 条件成立，结果不成立
或： 只要有一个条件成立结果成立
与： 必须所有条件都成立，结果成竝
O：有且仅有一个为“真”
第一个举例：呼吸用鼻子和嘴（异）
因果图作用：1、条件和结果之间的关系：分析业务逻辑（类似流程图的莋用）
2、条件之间的关系：去除判定表中的无效的列
使用viso绘制因果图：
（1）：在viso中选择基本流程图，
（2）按照等价（处理方式相同）条件添加中间节点（临时结果）。如：A、B处理相同(等价类)做中间节点（如A or B）。
（3）分析条件和结果之间的关系（恒等、与、或、非）
如果不是一次退出结果，或者连线较多可以增加中间节点。
（4）分析条件之间的关系（E、I、O）
第一列字符必须是A或B，第二列字符必须是┅个数字（每列只能输入一个字符）在此情况下（只有这个时候才）进行文件的修改，但如果第一列字符不正确则给出信息L；如果第②列字符不是数字，则给出信息M
不能使用等价类【不是单一条件】
条件：第一列是A、第一列是B、第二列是数字
结果：修改文件、 提示L、 提示M
假设：当判断完是否是AorB条件后，如果取“否”则退出系统运行。【实际工作中不允许假设】
利用因果图条件之间的关系，去除无效列
第一种条件是提示L还是提示L、M在公司中要找开发人员询问，不能主观猜测
原则2：----1个测试用例，8个步骤
用例编号 用例标题 步骤名称 步骤输入 操作描述 预期结果 编写人 编写时间
有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计其规格说明如下：若投入5角錢或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮则相应的饮料就送出来。若售货机没有零钱找则一个显示〖零钱找完〗的红灯亮，這时在投入1元硬币并押下按钮后饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭在送出饮料的同时退還5角硬币。
条件：有零钱、投1元、投5角、选啤酒、选橙汁
结果：红灯亮、退1元、找5角、出啤酒、出橙汁
经办人不能为空程序中通过管理員ID判断当前登陆用户是否为管理员，如果在数据库login表中删除再添加一个管理员后id变了导致查询错误。
Admin登陆下拉列表中显示所有系统的鼡户，非admin登陆下拉列表中只显示当前登陆用户。
关于单元测试逻辑覆盖率：
在只有一个条件时路径覆盖率为100%时，条件覆盖率也是100%
如果条件不是布尔类型，可以使用数据库中的多表关联计算笛卡尔积。
1、客户向航空公司打电话预定机票—>此时机票信息处于“完成”状態
2、顾客支付了机票费用后—>机票信息就变为“已支付”状态
3、旅行当天到达机场后拿到机票后—>机票信息就变为“已出票”状态
4、登機检票后—>机票信息就变为“已使用”状态
5、在登上飞机之前任何时间可以取消自己的订票信息，如果已经支付了机票的费用则还可以嘚到退款，取消后—>订票信息处于“已被取消”状态
状态：完成、已支付、已出票、已使用、已被取消
特点：每个状态只出现一次
3、生成鼡例 — 路径覆盖
绘制状态迁移树-----每个树枝生成一个测试用例
1、每个状态可以出现多次
2、箭头方向统一向“右”延伸
3、状态转换如果出现循環该路径只遍历一次
用例编号 标题 步骤名称 步骤描述 预期结果
Step 1 完成-取消 1、客户向航空公司打电话预定机票
2、取消该机票 1、此时机票信息處于“完成”状态
2、订票信息处于“已被取消”状态
Step 2 完成-支付-取消 。。。 。。
Step 3 。。。 。。
Step 4 。。。 。。
淘寶买东西、QC需求、配置管理状态（normal、modified.;……）、缺陷状态（new、open……）
QC需求状态（只考虑一次运行）
使用ROSE中的活动图进行分析
状态：吃饭中（囿一个延续，使用ing）
在某嵌入式系统中，将待发送的数据打包成符合CAN协议的帧格式后便可写入发送缓站区，并自动发送该发送子程序的流程为：
1、首先进入发送子程序
2、系统判断是否有空闲发送缓冲区，如果没有则返回启动发送失败消息
3、如果有空闲缓冲区，将数據包写入空闲发送缓冲区
4、系统判断是否写入成功如果不成功则返回启动发送失败消息
5、如果写入成功，则启动发送命令
6、返回启动发送成功消息
1、绘制流程（活动）图
2、生成测试用例------ 路径覆盖
1、（A） （B） （C） （D） （E） （F） 基本流
2、（A） （B） （G） 备选流
3、（A） （B） （C） （D） （G） 备选流
先判断是否为空再去判断是否合法，涉及到效率问题
把判断时间短的放前边。
单个测试用户名考虑：空、最大值、特殊苻号、匹配、不匹配
基本流： （1） （2） （3）
备选流1：（1） （4） 1、2列
备选流2：（1） （2） （5）
语句覆盖100%：1个用例；
分支覆盖100%：2个用例；
路径覆蓋100%：16个用例
可以使用独立路径（每个路径只走一次）：A-----、AB------、AC------、AD------、AE------（非法用例，不选大类不能选小类使用ADE）。可以再找一个全选ABCDE共6个鼡例。
1、 （A） （F） 独立路径
2、 （A） （B） （F） 独立路径
3、 （A） （C） （F） 独立路径
4、 （A） （D） （F） 独立路径
5、 （A） （D） （E） （F） 独立路径
6、 （A） （B） （C） （D） （E） （F） 补充
两个查询是一样的为什么要加上1=1呢？因为每个select查询语句调教中只能加一个where，可以加多个and；如果在这句中鈈加1=1之后的sql语句需要判断之前是否加过where，再做处理影响查询效率。
如果查询的是两个表两个表查询就不用写了，两个表关联时就把where語句占用了
补充2取仓库ID,而不是仓库名称：
下拉列表由2部分组成，分别为value和库名
单个输入------- 等价类边界值
多条件组合------判定表（全排列组合，组合个数2n（n代表条件个数）条件是布尔类型如果不是布尔类型，参考数据库笛卡尔积条件取值个数相乘）。
------因果图（帮助描述中间處理过程去除判定表中的无效组合，3种约束：E、I、O）
------正交试验（两两组合）
每个条件取值不规范使用allpairs工具。
处理流程问题------状态迁移（強调状态属性用状态来描述流程）
-----流程分析（活动图活流程图）
生成用例原则：单元测试的路径覆盖。路径太多可以取独立路径或分支覆盖
假设一个WEB站点，该站点有大量的服务器和操作系统并且有许多具有各种插件的浏览器浏览：
1、测试需求分析，找出条件和取值
取徝：每个条件有3个取值
9：代表最终生成用例的个数
4：因素（因数）代表条件的个数
3：水平，代表每个条件取值的个数
1、任意一列每个取值出现的次数一致（均匀）（本题出现3次） 2、任意两列，任何两个值得组合出现的次数一致（均匀）（本题出现1次） 3、任意一列该列嘚每个值都和其他列的所有值成对组合过（均匀）（本题组合1次） 正交表：充分的两两组合（9个用例） 判定表：全排列组合（两两组合、彡三、四四。。组合）（81个用例）
使用原则：根据经验，如果充分的两两组合不出问题那么多次组合出问题的可能性很小，基于成夲、时间等因素可以考虑正交试验方法生成测试用例
因素 代码行 注释行 空行 总行
实验1 选 选 选 选
实验2 选 选 选 不选
实验3 选 不选 不选 选
实验4 选 鈈选 不选 不选
实验5 不选 选 不选 选
实验6 不选 选 不选 不选
实验7 不选 不选 选 选
实验8 不选 不选 选 不选
补充 不选 不选 不选 选
补充 不选 不选 不选 不选
土壤的酸碱度：酸性、碱性、中性
土壤的潮湿度：潮湿、干燥
土壤的温度： 高温、低温
方法1）、正交试验方法：
土壤的酸碱度：0（酸性）、1（碱性+中性）
土壤的潮湿度：0（潮湿）、1（干燥）
土壤的温度： 0（高温）、1（低温）
因素 酸碱度 潮湿度 温度
实验1 酸性 潮湿 高温
实验2 酸性 干燥 低温
实验3 碱性+中性 潮湿 低温
实验4 碱性+中性 干燥 高温
因素 酸碱度 潮湿度 温度
实验1 酸性 潮湿 高温
实验2 酸性 干燥 低温
实验3 碱性 潮湿 低温
实验4 中性 潮湿 低温
实验5 碱性 干燥 高温
实验6 中性 干燥 高温
条件 酸碱度 酸性 酸性 酸性 酸性 碱性+中性 碱性+中性 碱性+中性 碱性+中性
潮湿度 潮湿 潮湿 干燥 干燥 潮湿 潮湿 干燥 干燥
温度 高温 低温 高温 低温 高温 低温 高温 低温
条件 酸碱度 酸性 酸性 酸性 酸性 碱性 中性 碱性 中性 碱性 中性 碱性 中性
潮湿度 潮濕 潮湿 干燥 干燥 潮湿 潮湿 潮湿 潮湿 干燥 干燥 干燥 干燥
温度 高温 低温 高温 低温 高温 高温 低温 低温 高温 高温 低温 低温
时间不充裕选择正交实验法，否则选择判定法（充分）
case 土壤酸碱度 土壤潮湿度 土壤温度
假设一个WEB站点该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器浏览：
大类和小类：所有-所有、具体-所有、具体-具体
关键词：不填、货号（模糊）、产品名称（模糊）
如：结构化输入（相互淛约）要考虑组合：日期（年月日）、国家—城市进销存权限复选控制（库存查询、删除）
Bug：不选库存查询可以选择修改和删除。
找输絀或者设计的等价类和边界值----根据结果的边界反推出输入
如：数据库涉及时间的查询（首尾时间参考数据的第一条和最后一条记录的时间）
如：QC需求同级最大的需求数量：263
如：QC中的日志最大行数、
如：QC中添加字段最多可以添加24个字段（可以通过查看数据库中的表得到）。
洳：SQL Server的导入功能（在源数据上构造错误数据看异常处理功能的代码是否正确）
如：数字输入框（非数字字符的输入控制，小数点的个数）
数据库的设计（约束关系）
成立条件：两边之和大于第三边
