测试案例梳理

测试的关键问题是()
    如何选择测试用例、
    

项目立项后，对项目进行需求分析后，开始着手编写测试用例；

先通过xmind直接整理测试点
再通过Excel直接编写

测试案例的管理软件：
    禅道
    jira
    bugfree
    github    
    redmine
    QC

测试用例重要的作用：
    技术上将需求转化为具体可验证的指标
    以文档的形式记录软件可能存在的问题
    防止测试过程的活动出现遗漏，提高工作效率
    测试工作量的展示

如何编写测试用例：
    常规思考，设身处地的从用户角度出发
    测试理论方法的支撑
    产品的熟悉和经验的积累

软件质量模型特性说明：
    功能性：功能有没有，好不好用     
    性能效率：对应系统的资源耗费程度及响应时间     
    易用性：容易理解、学习、使用      
    兼容性：能够兼容不同的软硬件平台
        不同浏览器显示与操作
        相同浏览器不同版本
        不同移动设备不同浏览器
        不同分辨率
        
    可靠性：不易出问题，万一出问题容易恢复    
    安全性：对于用户的安全保障（外在的人生安全、内在的信息安全等） 
        密码存储加密
        密码传输加密
         密码有效期
        直接输入已经登录的URL
        密码复制粘贴
        密码信息源码查看
        输入“sql"注入
        多次登录失败提示
        同一用户同一终端多浏览器登录
                
    可移植性：能否在不同环境条件下无故障运行    
    可维护性：对于后期的修复维护是否方便快捷

软件测试用例主要由
    测试输入数据和
    测试的预期结果
 

测试用例的组成元素：
    用例编号
    用例标题
        字数不能太多
        概括性-看到标题就能清楚这条用例测试点是什么
        不能歧义性
    功能模块名称
    前置条件
    输入数据
    操作步骤
    预期结果
    优先级
    执行结果
    编写人
    执行人
    
    
白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试。
    白盒测试是基于代码的测试，通过程序代码或者通过开发工具找出软件的缺陷。
    白盒测试总体上分为两大类为
        动态分析：代码运行结束后。模块功能检查和系统压力测试，必须执行代码后才能分析。
        静态分析：代码运行之前。数据流分析和代码覆盖率，不需要执行代码就可分析。
        静态测试包括
            代码检查、
            静态结构分析、
            代码质量度量等。
            它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
                人工测试技术主要包含三种静态测试技术，分别是走查、审查和正式评审。
                编码规则检查
                程序结构分析
                程序复杂度分析
    白盒测试的主要方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。
        白盒测试法的覆盖标准有
            逻辑覆盖、   (六种覆盖标准发现错误的能力呈由弱到强的变化：语句覆盖＜判定覆盖＜条件覆盖＜语句/判定覆盖＜条件组合覆盖＜路径覆盖)
                语句覆盖
                判定覆盖
                条件覆盖
                判定/条件覆盖
                条件组合覆盖
                路径覆盖
            循环覆盖、
            基本路径测试。
                基本路径V（G）
                1、V（G）=P+1 （P是判定节点）
                2、V（G）=D （D是区域数）
                3、V（G）=E-N+2（E是边的条数，N是节点数）
        
        1.语句覆盖---每条语句至少执行一次。
            例子1：使用语句覆盖对下列代码进行测试用例设计时，需要设计 2 个测试用例
                public  static void Test(int a, int b, int c)
                    {
                        if ((a > 1) && (c == 0))
                            b = b / a;
                        if ((a == 1) && (b > 1))
                            b = b + 1;
                    }
                    
            例子2：只要看见switch就要注意每个case后有没有break，请注意，语句覆盖，case2没有break，因此case2和case3可以同时在value=2时得到覆盖   

        2.判定覆盖---每个判定的每个分支至少执行一次。
            用判定覆盖设计的测试数据：(2)
                 a＝5 （判定表达式的值为“真”）
                 a＝0 （判定表达式的值为“假”）
                 这里不需要管b的取值，就已经满足判定覆盖的条件了。
            以下程序至少需要（ ）个测试用例，才可以满足判断覆盖
                if（x && y）{....}
                    else{....}    
                    
        3.条件覆盖---每个判定的每个条件应取到各种可能的值。
            例子1：用条件覆盖设计的测试数据：(4)
                语句if（a>5 && b<0）满足条件组合覆盖需要设计测试用例的个数为
                    a＝5 （条件a>1的值为“真”）
                    a＝0（条件a>1的值为“假”）
                    b＝5 （条件b>1的值为“真”）
                    b＝0 （条件b>1的值为“假”）
                    这里不考虑 a>1 or b>1 这个表达式的取值的情况，但必须把a>1 和 b>1 这两个条件的取值考虑全。   
       

            
        4.判定/条件覆盖---同时满足判定覆盖条件覆盖。
             例子1：针对程序段：IF（A||B||C）THEN  W=W/X，对于(A,B,C)的取值，（ ）测试用例能够满足MCDC（修正条件逻辑判定）的要求。
                 （A||B||C）一共有2^3=8,8种2组合，但是因为是或，or 或语句只要判断前面的，
                  若第一项为T，后面无论是啥，都为真，（T X X）  =（T T F）=（T T T）=（T F F）=（T F T）等效    4种
                  若第一项为F，则判断第二项，第二项为T，则后面无需判断，（F T X）   =（F T F）=（F T T）等效    2种
                  第二项为F，则判断第三项，第三项为T      （F F T）     1种
                  第二项为F，则判断第三项，第三项为F      （F F F）     1种
                  (T,F,F) (F,T,F) (F,F,T) (F,F,F)
    

        5.条件组合覆盖---每个判定中各条件的每一种组合至少出现一次。
            为下列代码设计测试用例，要求满足条件组合覆盖，需要设计测试用例的个数为（4个）
                BEGIN
I               NPUT(A,B)
                IF(A>5)AND(B<O)
                THEN
                X=A+B
                ELSE
                X=A-B
                END
                    都符合，都不符合，一个符合一个不符合（有两种情况）。
        6.路径覆盖---使程序中每一条可能的路径至少执行一次。
            

黑盒测试
    测试用例设计方法：
        等价类划分法：
            分类：
                有效等价类
                无效等价类（一条测试用例只能包含一个无效等价类）
            等价类划分的原则：
                按区间划分
                    按数据集合划分
                    按数据布尔值划分
                    按数值划分
                    按限制条件或规则划分
                    按细分等价划分
            举例：（手机号码输入验证）
                  输入数据类型                        划分等价类规则
                手机个数（11位）              1个有效等级类（11个数字）           无效等价类（大于或者小于11个数字）
                集合（手机号都是数字组成）                 （正确的数字集合）               （非数字：包括字母，汉字，特殊字符）
                符合某些规则的输入（手机号首位为1）        （首位为1）                      （首位不为1）
                取值范围
                布尔值
         
        边界值分析法：   
            边界值分析的值：（例如：输入框的输入数据范围为3-6（包含3和6），则内点是4，5；上点是3，6；离点是2，7。）  
                内点：域内的任意点都是内点
                上点：指边界上的点，无论此时域是开区间还是闭区间，上点就是域的上限与下限值
                离点：指的就是离上点最近的点，这里就跟闭区间还是开区间就有关系了，如果是开区间，那么离点就在域内，如果闭区间，那么离点就在域外（开内闭外）    
        
        
        判定表法：
            判定表法设计用例——规则数：2的n次方（n是条件数）
            条件数：4 —> 规则：16
            条件数：5 —> 规则：32
            条件数：6 —> 规则：64
            条件数：7 —> 规则：128

………
                举例：支付宝个人账户注册——验证用户名需求：
                    条件桩      
                        第一项输入手机号码
                        第一项属于电子邮箱
                        第二项输入正确的验证码
                    动作桩
                        报错l
                        填写账户信息
                        报错m
        
        因果图:
            考虑所有输入/输出条件的相互制约关系以及组合关系
            考虑输入条件之间的依赖关系
            再根据分析的关系来转化为判定表的规则
        
        
        状态迁移:
            例子：飞机售票系统
                路径1：预订—已取消
                路径2：预订—已支付—已取消
                路径3：预订—已支付—已出票—已取消
                路径4：预订—已支付—已出票—已使用
            
        
        场景法:
            软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
            重要概念：
                基本流
                备选流
                异常流
        
        
        
        正交试验：
            条件：因子 取值：水平。
        
        
        
        
        决策表
        错误推测法    

bug的管理：
    bug生命周期：
    一般：
        新建->指派->已解决->待验->关闭。
        重新打开（激活）->指派->已解决->待验，循环这个过程。中间还包括其他状态：拒绝、延期等        
        bug的跟踪：
            已经指派的bug
            已解决的bug
            重复bug
            不是缺陷
            无法重现
            不予解决
            无法重现
            不予解决
            设计如此
            延期修改