SVN和禅道

svn 版本控制器

svn update  ==》更新服务器和缓存区之间不相同的东西。
svn commit ==》提交缓存区中的操作
check out  dirctroy  ==》检出目录。并且将服务器现存的东西拉取到缓存区

git仓库的指令
1. git status
2. git diff
3. git add
4. git commit
5. git pull
6. git push

动态测试：将软件运行起来，进行测试。
静态测试：查看需求，查看文档（用例）。  对代码进行走查
走查：查看有没有逻辑错误或者语法错误，也可以查看文档，

正式评审：等用于组内评审，组内的人员召开的一次会议

度量：标准。要求某个系统或者软件的bug密度在5%~10%以内
例如：我开发人员实现了100个功能，只能出现5-10个bug，15个bug

评审员：所有参加会议的人员
记录员：所有人都是记录，例如一旦需求更改，所有人都需要知道，并且了解更改的地方


技术评审：对当前迭代的功能相关的代码进行审查

复杂性：复杂程度

圈复杂度（复杂性的标准）：程序中独立路径的数量。
可 以衡量一个组件模块的判定结构的复杂程度。

控制流程图:执行组件或系统的一系列顺序的路径，展示整个流程中的每个环节

数据流：指代数据从哪里来，到哪里去的过程
自己输入的数据，上传到多测师论坛后台的服务器中。会用数据库来存储你所注册的信息


圈复杂度计算公式：
1.
v=e-n+2
e代表边数
n代表节点数
10-7+2=5

2.
v=区域数
区域数：闭合的环的数量

3.v=p+1
p：判定节点数
判定节点：同时指向多个方向：代表从这个节点要可以选择分支


白盒测试：
条件覆盖：设计场景，看代码的逻辑
语句覆盖：检查代码的语法是否正确

黑盒测试：功能测试
1.等价类
2.边界值
3.判定表
4.因果图
5.正交表
6.场景法
7.状态迁移


有效等价类：对程序规格说明有意义 的、合理 的输入数据
无效等价类：对程序规格说明无意义 的、不合 理的输入数据

如果一个学生管理系统，需要输入学生的成绩，输入的值0~100能够正常录入学生成绩。  
有效等价类：0~100，
无效等价类：小于0  ，大于100，符号（@#￥%……&&*（），汉字

举例：
现有一个档案管理系统，容许用户通过输入年月对档案文 件进行 检索，系统对查询条件年月的输入
限定为1990年1 月～2049年12月，并规定：日期由6位数字字符组成，前 4位表示年，后2位表示月

有效等价类：199101，199201，199103  （所有的有效等价类，对于程序来说都是等价的）
尽可能覆盖最多的有效等价类就是一条用例
用例标题：
验证档案管理系统输入满足1990~2049之间年份，满足1~12月之间月份，6位长度的数字 ：199101。点击检索，
检索成功。显示检索内容。

无效等价类：每一个无效等价类都从不同方向违反了规定（一个无效等价类就等于一条用例）
5位，7位（长度）
年份（小于1990，大于2049）
月份（小于1，大于12）
类型（汉字，特殊字符，字母）
不输入

验证档案管理系统输入，满足1990~2049之间年份，满足1~12月之间月份，长度是5位的数字：19911，点击检索，
检索失败，提示输入的值有误。
1990《x《2049

199001  204912          198912   205001     199011   
1，12     0，13   ，6


验证档案管理系统输入，满足1990~2049之间年份，满足1~12月之间月份，长度是7位的数字：1991001，点击检索，
检索失败，提示输入的值有误

编写用例值得注意的地方：
1.用例标题一定要以验证开头
2.用例标题要和用例步骤相互呼应
3.用例标题要与预期结果相互呼应




等价类划分的设计用例思路：
1. 找输入条件
2. 为每个输入条件找有效、无效等价类
3. 为每个等价类编号
4. 用最少的用例覆盖最多的有效等价类
5. 每一个无效等价类都是一个用例
等价类的优缺点
优点：是考虑了单个输入域的各类情况， 避免了 盲目或随机选取输入数据的不完整
性和覆盖的不 稳定性。
缺点：方法虽然简单易用，但是没有对组 合情况 进行充分的考虑。
需要结合其他测 试用例设计的 方法进行补充。比如边界值

边界值：

0<x<100    ==》开区间

上点：边界上的点：2个 (0,100)
离点：离上点最近的点:2个(1,99)  ==》开区间往内取
内点：在范围内的点:2~98任意取一个

0《x《100   ==》闭区间
上点：0/100
离点：-1/101  ==》闭区间往外取
内点：1~99任意取一个

5《x<26   ==》半闭半开区间  
上点：5，26
离点：4，25
内点：6~24

5<x《26  ==》半开半闭区间
上点：5，26
离点：6，27
内点：7~25

边界值设计方法
优点：避免盲目随机的筛选测试数据
缺点：只能考虑单个的输入域，不能够对组合情况进行判定

边界值分析原则
1. 如果输入（输出）条件规定了取值范围，则应该 以该范 围的边界内及边界附近的值作为测试用例
2. 如果输入（输出）条件规定了值的个数，则用最 大个数， 最小个数，比最小个数少一，比最大个
数多一的数作为 测试数据
3. 如果程序规格说明中提到的输入或输出是一个有 序集合， 应该注意选取有序集合的第一个和最后
一个元素作为测 试数据

有序集合：
list=[3，1，18，9，4，7，12]
list1=[1,3,4,7,9,12,18]
list2=[18,12,9,7,4,2,1]

判定表：罗列出了所有的可能性

结构：由4个部分组成
1）条件桩（condition stub）:列出问题的 所有条件（通常条件次序无关紧要）。
2）条件项（condition entry）：列出针对 它条件的取值（所有情况下的真假值）
3）动作桩（action stub）：列出问题规定 可采取的动作（顺序无约束）。
4）动作项（action entry）：列出条件各 种情况的应采取的 动作

组合的情况数目：条件项的条件桩次方

原因是输入，结果是输出
因果图可以转换为判定表

原因与结果之间的关系：
c代表原因，e代表结果
恒等：==   equal
1.原因出现，结果必然出现
2.结果出现，原因必然出现

非：!= not  ≠   ~
1.当原因出现，结果一定不会出现
2.当结果出现，原因一定不会出现

或：or  /   v  
1.其中一个原因出现，结果就会出现
2.结果出现，至少需要有一个原因出现


与：^   and  和  且 &
1.如果结果出现，必须要多个原因同时出现
2.如果多个原因同时出现，才会出现结果

因果图中的约束：
异：E  ==》有一个非必选的性别选择框，要么男，要么女，要么不选。
或：I   ==》必填的选修课，至少选择一个，也可以都选择
唯一：O ==》必选的性别选择框，我要么男，要么女。
要求：R  ==》有一个地址栏，如果我下下级地址栏中输入成都，那么地址栏的上一级必须是四川省

强制(原因与原因之间，结果与结果之间)：
1.如果a出现，强制要求b不能出现  ==》如果登录成功出现，登陆失败强制不会出现
2.如果a出现，强制要求b必须出现  ==》支付成功出现，必须出现支付凭证。(扣款，到账)

在工作中怎么样使用因果图？
因为因果图最终是为了生成判定表，由于因果图的关系网络比较复杂，所以我们一般会 将
因果图中的原因放入判定表的条件桩，将结果放入判定表的动作桩，从而完成初始判定表，
在筛选出合理的动作，作为我们的测试用例。


正交表：
最开始通过公式计算出，完成实验的最低次数，将水平因子均匀分布到正交表中。
Ln =k*（m-1）+1  ==》最低完成实验的次数
因素数（k）：条件的个数
水平数（m）：每个条件取值的个数

场景法：
离职流程：
1.提交离职申请    ==》申请离职 ==》设计申请离职状态出现的场景
2.审批通过离职申请  ==》审批通过
3.办理离职手续  ==》办理手续
4.交接工作  ==》交接工作中
5.开离职证明   ==》正在开具离职证明
6.离职完成  ==》此人已离职


购物流程：
1.选择商品，加入购物车  ==》制单中    ==》
2.结算商品    ==》下单
3.商家打包商品  ==》打包中
4.商家两联系物流  ==》物流揽件
5.物流配送  ==》运输中
6.顾客接受  ==》订单签收

登录场景：登录成功，登录失败
登录成功：
正确的账号，正确的密码，正确的验证码
登录失败：
正确的账号，错误的密码，正确的验证码
正确的账号，正确的密码，错误的验证码
正确的账号，错误的密码，错误的验证码
不输入

状态迁移：例如，订单状态的变更，为什么会导致订单的状态进行变更（因为商家，或者顾客的操作，需要去模拟操作，查看状态是否变更）


bug管理工具：
禅道，jira，BUGzilla，QC

神冰，lucp


bug的流程：
1.发现bug
2.提交bug
3.开发确认bug
4.修复bug
5.验证bug ==》a.bug被修复 b.再次提交bug
6.关闭bug

提单：测试人员发现bug  ，然后在用例管理平台中提出


如果你提的bug开发不认可怎么办？

1.再次去研究需求，在自己的理解范围内，如果认为依然是bug
2.找开发阐述它是bug的原因
a.开发认同你的观点
b.开发依然不认同你提出的bug
3.让开发说出它不是bug的理由
a.如果认同开发的观点，则关闭bug
b.如果不认同开发的观点
4.上报测试经理，让测试经理去跟开发或者开发经理沟通


bug的严重级别：
致命bug：如果这个bug存在，那么会导致服务器宕机 （濒临崩溃，卡死）
严重bug：影响主体功能通畅的bug
一般bug：影响细小（分支）功能的bug
建议性bug：界面，排版，错位，静态展示的错误

一条bug包含的内容：
bug标题，bug描述，重现步骤，bug级别，所属版本，所属模块，指派给谁

偶现性bug：我按照重现步骤去操作，bug有可能会出现。(有可能10次出现1次)
遇到偶现性bug，应该及时截图，已经添加说明，并且注意重现步骤中比较关键的点

必现性bug：我按照重现步骤去操作，bug一定会出现（操作10次，出现10次）