7.测试用例设计方法 + Bug

一、正交实验法

1.使用场景
        因果关系比较庞大的情况下，不太适合用因果图判定表，在这种情况下，一般会采用正交实验法。
2.例子：
字符属性设置（4个条件） 
        字体很多
        字符样式很多        

        字体颜色很多
        字号也很多

       

组合很多

3.正交表，特制的表，一般记为

字符属性设置例子，表为，一共有4个条件，一个条件3个值，总共测9次

二、笔试面试题

1.用例需要评审吗？紧急情况用例也需要评审么？
        也需要，可以不组织会议，用例发送邮件给到相关人员确认。

2.如果被测项目很紧急，来不及写用例，怎么办？
        可以用xmind列出测试点，一一进行测试，测完之后时间不紧急的时候补用例，用于后面回归测试。

3.遇到隐形需求如何写用例？

        需求不明确的时候要先去熟悉功能，参考成熟的产品，站在用户的角度来挖掘需求。

4.用例有没有优先级？如果一定要有优先级，依据什么来确定？
        有优先级，高中低，以及核心功能来确定，用户是否使用的场景来确定。

5.编写测试用例会用到什么方法？

        拿到项目，先熟悉业务流程，用场景法来设计
        针对输入功能，一般用等价类边界值来设计
        多个条件不同组合不同结果，用因果图判定表来设计

        

三、Bug管理流程及禅道使用

1.什么是Bug？
        软件程序的漏洞，软件可改进的细节，与需求文档存在差异的功能。
 

2.bug类型

        代码（功能）错误：功能错误、性能、安全错误

        界面优化：界面易用性测试

        设计缺陷：建议优化的bug

3.bug等级
        bug等级越高，bug修改的优先级越高
        1）致命错误（blocker）（核心功能，数据问题，安全问题）

                1>常规操作引起的吸引崩溃，死机，死循环，闪退

                2>造成数据泄露的安全性问题，那比如恶意攻击造成的账户私密信息泄露

                3>设计金钱计算（不扣款，延时不算）
                4>阻断性测试，所有测试工作进行不下去（冒烟测试）

        2）严重错误：critical

                1>重要功能不能实现

                2>错误的波及面广，影响到其他的重要功能正常实现
                3>非常规操作，导致的程序死机，死循环，闪退。

                4>外观（界面）难以接受的缺陷

                5>密码明文显示：（界面+数据库）
                6>偶现的致命性错误

        3)一般错误（major）

             不影响产品的运行，不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

                1>次要功能不能正常实现

                2>操作界面错误（包括数据窗口内列明定义，含义不一致）
                3>查询错误，数据错误显示
                4>简单的输入限制为放在前端进行控制

                5>删除操作未给提示

                6>偶先的严重性bug

        4）细微错误（minor）
                界面方面的错误，描述错误，错别字

        5）改进建议