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

发布于:2024-09-17 ⋅ 阅读:(187) ⋅ 点赞:(0)

一、正交实验法

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

        字体颜色很多
        字号也很多

       

组合很多

3.正交表,特制的表,一般记为L_{n\left (m ^{k} \right )}

字符属性设置例子,表为L_{9\left (3 ^{4} \right )},一共有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)改进建议


网站公告

今日签到

点亮在社区的每一天
去签到