Loading... # 软件测试题目 ## 作业一 1. 软件测试对象包括 - 需求规格说明书 - 概要设计规格说明书 - 详细设计规格说明书 - 源程序 - 系统 - 用户手册 - 帮助文档 2. 软件测试的目的 - 发现系统的错误 - 验证系统是否满足需求 - 为产品放行提供依据 - 改进开发流程 3. 在软件生命周期的哪一个阶段,软件缺陷修复费用最低 需求分析(编制产品说明书) 软件生命周期:可行性分析与项目计划、需求分析、系统设计、编码、调试、测试(执行)、维护升级到废弃等阶段。 4. 为了提高测试的效率,应该 A、随机地选取测试数据; B、取一切可能的输入数据作为测试数据; C、在完成编码以后制定软件的测试计划; ==D、选择发现错误可能性大的数据作为测试数== 5. 软件测试员究竟做些什么 A、软件测试员的目的是发现软件缺陷 B、软件测试员的目的是发现软件缺陷,可能早—些 ==C、软件测试员的目的是发现软件缺陷,尽可能早一些,并确保其得以修复== D、软件测试员的目的是发现软件缺陷,尽可能早一些,并手动修复它 6. 划分软件测试属于白盒测试还是黑盒测试的依据是 A、是否执行程序代码 B、是否能看到软件设计文档 ==C、是否能看到被测源程序== D、运行结果是否确定 > 1. 黑盒测试 > > 在程序接口进行测试,它只是检查程序功能是否按照规格说明书的规定正常使用。 > 也被称为功能测试或数据驱动测试。 > 2. 白盒测试 > > 要完全了解程序结构和处理过程,它按照程序内部逻辑测试程序,检验程序中每条通路是否按预定要求正确工作。 > 也被称为结构测试或逻辑驱动测试。 > 7. 按测试级别划分,包括下面 ==A、单元测试== ==B、系统测试== C、静态测试 ==D、集成测试== > ### 1.2.3 按测试阶段分类 > > 1. 单元测试(能发现80%的问题) > > 单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作。(如自行车组装,先进行单元测试) > > 目的: 主要是测试模块在语法、格式和逻辑上的错误。 > 2. 集成测试 > > 集成测试也称为组装测试,集成测试按设计要求把通过单元测试的各个模块组装在一起之后所进行的测试。(一般分为函数间集成,模块间集成,子系统间集成) > > 目的: 检查模块间的接口关系,以便发现与接口有关的各种错误 > 3. 系统测试 **(重点关注)** > > 系统测试是将已经集成好的软件系统置于实际运行环境中所进行的测试。(一般指用户真实运行环境模拟测试) > > 目的: 根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。 > 4. 验收测试 > > 是软件开发结束后,用户对软件产品投入实际应用前进行的最后--次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求,以及用户能否接受的问题。 (旨在提高用户对软件质量的信心) > > 目的: 验证软件功能的正确性和需求的符合性。 > 8. 软件测试最小单元是单元测试 √ 9. 下面属于集成测试的是 A、测试模块在语法、格式和逻辑上的错误 ==B、检查模块间的接口关系,以便发现与接口有关的各种错误== C、根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求 D、验证软件功能的正确性和需求的符合性 10. 对软件**是否能达到用户所期望**的要求的测试称为( ) A、集成测试 B、压力测试 C、单元测试 ==D、验收测试== ## 作业二 > ### 2.2.3 等价类测试的类型 > > 根据测试用例的完整性划分 > > 1. 弱等价类测试 > - 弱一般等价类测试 > - 定义:单缺陷假设,不讨论异常区域 > - 测试用例策略: > 1. 对于有效输入,取每个有效等价类的一个值 > 2. 对于无效数据,不考虑(不取无效等价类) > - 弱健壮等价类测试 (传统的等价类测试) > - 定义:单缺陷假设,要考虑异常区域 > - 测试用例策略: > 1. 对于有效输入,取每个有效等价类的一个值 > 2. 对于无效输入,测试用例将拥有一个无效值,并保持其余的值是有效的。 > 2. 强等价类测试 > - 强一般等价类测试 > - 定义:多缺陷假设,不考虑异常区域 (即有效等价类的笛卡尔乘积) > - 测试用例策略: > 1. 对于有效输入,考虑有效等价类之间的组合 > 2. 对于无效输入,不考虑 > - 强健壮等价类测试 > - 定义:多缺陷假设,要考虑异常区域 (即一个全笛卡尔乘积) > - 测试用例策略: > 1. 测试用例从所有等价类(包括有效和无效等价类)笛卡儿乘积中选取(组合) > > 名词解释: > > - 弱 > > 是指从各个等价类中选取值时只考虑等价类自身,查出的缺陷属于“单缺陷”,即单一因素造成的缺陷。 > > 即单缺陷假设,**不考虑**取值**组合** > - 强 > > 是指考虑了等价类之间的相互影响,查出的缺陷属于多种因素造成的“多缺陷”。 > > 即多缺陷假设,**考虑**取值**组合**的情况 > - 一般 > > 不考虑**无效值**(异常区域) > - 健壮 > > 考虑**无效值**(异常区域) > > ![等价类测试的类型](http://storage.live.com/items/FECD80CE4F909A96!44948:/image-20230418224002463.png?authkey=AKpqV245EC2xOuk) 1. 弱等价类测试中的“弱”是指从各个等价类中选取值时只考虑等价类自身,查出的缺陷属于“单缺陷”,即单一因素造成的缺陷 √ 2. 下面描述正确的是 ==A、弱一般等价类:单缺陷假设,不讨论异常区域== ==B、强一般等价类:多缺陷假设,不考虑异常区域== ==C、弱健壮等价类:单缺陷假设,要考虑异常区域== ==D、强健壮等价类:多缺陷假设,要考虑异常区域;即一个全笛卡尔乘积== 3. 对于弱一般等价类测试只需要取每个有效等价类的一个值,不需要考虑无效等价类 √ 4. 下面关于等价类法和边界分析法描述不正确的是?() A、边界值分析法是针对输入或输出等价类的边界进行分析 B、边界值分析假定错误更多地存在于划分的边界上 C、边界分析法在等价类的边界上以及两侧的情况设计测试用例 ==D、边界分析法在从某个等价类中任选一个作为测试数据== > ### 2.3.3 边界值分析法与等价类划分法的区别 > > ![image-20230419151010680](http://storage.live.com/items/FECD80CE4F909A96!44959:/image-20230419151010680.png?authkey=AKpqV245EC2xOuk) > 5. 某软件功能,要求输入为非0的正整数,下面哪项属于有效等类。 A、-1 ==B、1== C、1.2 D、Hello word 6. 下面对有效等价类和无效等价类描述正确的是() ==A、有效等价类输入有效,合理的值== ==B、无效等价类输入无效的值== C、有效等价类关注异常处理 D、无效等价类关注功能 7. 划分等价类的原则包括 ==A、按双边区间划分== ==B、按单边区间划分== ==C、按取值划分== D、按处理逻辑划分 > ### 2.2.2 等价类划分方法 > > 1. 按双边区间划分 > > 如果输入条件规定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。 > 2. 按取值划分 > > 如果规定了输入数据的一组值(假定$n$个),且程序要对每一个输入值分别进行处理的情况下,可确定$n$个有效等价类(每个值确定一个有效等价类)和一个无效等价类(所有不允许的输入值的集合)。 > 3. 按单边区间划分 > > 如果输入条件规定了输入值的集合,这时可确立一个有效等价类和一个无效等价类。 > 4. 按限制条件/规划划分 > > 如果规定了输入数据必须遵守的规则或限制条件,可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则) > 8. 黑盒测试关注程序外部结构,不考虑内部逻辑结构,不知道程序如何工作 √ 9. 边界值分析法是对等价类划分测试法的补充 √ 10. 通常功能测试指的黑盒测试 √ ## 作业三 > ### 2.3.2 名词解释 > > - 边界:指相对于输入等价类和输出等价类而言,稍高于、稍低于其边界值的一些特定情况。 > - 边界点:分为上点,内点,离点 > > ![image-20230419150415727](http://storage.live.com/items/FECD80CE4F909A96!44958:/image-20230419150415727.png?authkey=AKpqV245EC2xOuk) > > 注:不管是闭区间还是开区间,上点都是其边界点,只是上点是否在域内有所区别 > > ### 2.3.5 边界条件测试用例设计法 > > 1. 一般边界条件测试用例设计法 > > - 方法 > 1. 每次保留程序中一个变量,让其余的变量取正常值,被保留的变量依次取min、min+、 nom、max和max。 > 2. 对程序中的每个变量重复(1) > - 特点 > 1. 一般边界值测试分析采用了可靠性理论的单缺陷假设。 > 2. 优点:简便易行;生成测试数据的成本很低; > 3. 局限性:测试用例不充分;不能发现测试变量之间的依赖关系; > 4. 对于一个$n$变量函数,该方法生成的测试用例数为$4n+1$ > - 结论:只能作为初步测试用例使用 > 2. 健壮性边界条件测试用例设计法 > > - 方法 > > 1. 每次保留程序中一个变量,让其余的变量取正常值,被保留的变量依次取min-、min、 min+、 nom、max- 、max和max+。 > 2. 对程序中的每个变量重复(1) > - 特点 > > 对于一个$n$变量函数,该方法生成的测试用例数为$6n+1$ > 3. 最坏边界条件测试用例设计法 > > - 方法 > > 1. 所有变量均可取min、min+、 nom、max- 和max这五个边界值中的任何一个, > 2. 测试用例为五个集合的笛卡儿乘积。 > - 特点 > > 对于一个$n$变量函数,该方法生成的测试用例数为$5^n$ > - 与基本边界条件的区别 > > 1. 基本边界值分析测试用例是最坏情况测试用例的真子集; > 2. 最坏情况测试显然更彻底; > 3. 最坏情况测试工作量大得多,变量函数的最坏情况测试会产生$5^n$个测试用例,边界值分析只产生$4n+1$个测试用例。 > 4. 健壮最坏边界条件测试用例设计法 > > - 方法 > > 1. 所有变量均可取min-1、min、 min+、nom、max- 、max和max+1这七个边界值中的任何一个。 > 2. 测试用例为七个集合的笛卡儿乘积。 > - 特点 > > 对于一个$n$变量函数,该方法生成的测试用例数为$7^n$ 1. 上点就是边界上的点,不管它是开区间还是闭区间 √ 2. 对于用户名长度(6,18),精度为1,下面上点,内点,离点正确的是 ==A、上点6,18== ==B、内点10== ==C、内点15== ==D、离点7,17== 3. 对于用户名长度[6,18],关于上点,内点,离点正确的是 ==A、上点6,18== ==B、内点10== ==C、内点15== ==D、离点5,19== 4. 一般边界值测试分析采用了可靠性理论的单缺陷假设 5. 最坏边界条件测试用例设计法是所有变量均可取min、min+、nom、max-和max这五个边界值中的任何一个 ## 作业四 > ## 2.4 判定表法 > > ### 2.4.1 定义 > > 1. **判定表**(也称决策表)是一个用来表示条件和行动的二维表,是分析和表达多逻辑条件下执行不同操作的情况的工具。 > 2. **判定表驱动法**(或决策表法)是根据需求描述建立判定表(决策表)后,导出测试用例的方法。 > 3. 在所有的黑盒测试方法中,基于判定表的测试是最为严格、最具有逻辑性的测试方法 > > ### 2.4.2 名词解释 > > - 将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。 > - 在判定表中贯穿条件项和动作项的一列就是一条规则。 > - 条件桩:需求规格说明书定义的被测试对象的所有输入。 > - 条件项:针对条件桩所有可能的输入数据的真假值。 > - 动作桩:针对条件被测对象可能采取的所有操作 > - 动作项:针对动作桩,被测对象响应的可能取值。 1. 当输入变量或者输出条件之间存在相互依赖或者制约的情况时,采用等价类划分法和边界值分析法是难以描述的 2. 在所有的黑盒测试方法中,基于判定表的测试是最为严格、最具有逻辑性的测试方法 3. 下面描述正确的是 ==A、条件桩—需求规格说明书定义的被测试对象的所有输入== ==B、条件项—针对条件桩所有可能的输入数据的真假值== ==C、动作桩—针对条件被测对象可能采取的所有操作== ==D、动作项—针对动作桩,被测对象响应的可能取值== 4. 对于有限条目,条件桩为3,则规则有(假设不进行规则合并) ==A、8== B、27 C、3 D、9 5. 对于下面描述正确的是 ![img](https://staticfile.eec-cn.com/richtext%2Fimage%2F20201018%2F71ADE748626848C98F59DBB372158C3C.png) ==A、c1,c2,c3是条件桩== ==B、A1,A2是动作桩== ==C、上述表有8条规则== ==D、上述的Y和N对应的单元是条件项== 6. 回答正确的是(不进行规则合并) ![img](https://staticfile.eec-cn.com/richtext%2Fimage%2F20201018%2FED1C791314FD4D14A1FFCF12A91A83FC.png) ==A、有4个测试用例== B、有2个测试用例 C、有3个测试用例 D、有3*2个测试用例 7. 若两条或多条规则的动作项相同,条件项只有一项不同,则可将该项合并,合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件 8. 对于下面业务采用判断表进行测试: 如果金额大于500元,又未过期,则发出批准单和提货单;如果金额大于500元,但过期了,则不发批准单;如果金额小于等于500元,则不论是否过期都发出批准单和提资单;在过期的情况还需要发出通知单 下面描述正确的是 ==A、条件桩:大于500,过期== ==B、动作桩:批准单,提货单,通知单== ==C、规则有为4个== D、规则为2*3个 9. ✔ 扩展条目判定表的条件可以有多个值,有n个条件的判定表的规则的个数为n个条件所有值的笛卡尔积 10. ❌ 扩展条目判定表规则是规则的个数为n个条件所有值的笛卡尔积,所以它一定比有限条目判定表规则数多 > ### 2.4.4 两种判定表 > > 1. 有限条目判定表 > - 特点:所有条件都是二值条件(真/假) > 2. 扩展条目判定表 > - 特点:条件可以有多个值 > ## 作业五 > ## 2.5 因果图法 > > ### 2.5.1 定义 > > - 因果图法(Cause-Effect Graphics) > > 是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法。 > - 因果图提供了一个把需求转化为判定表的系统化方法 > - 因果图法最终生成的就是判定表,它适合于**检查**程序输入条件的各种组合情况。(因果图是判定表前置条件,类似等价与边界关系) > - 原因:输入条件 > > 结果:输出 1. ✔ 当输入条件过多时,使用判定表会产生大量测试用例,使用因果法更合适 2. ❌ 判定表法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的 > 因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法。 > 3. 判断表的简化方式包括 A、条件项合并 B、动作项合并 ==C、规则合并== ==D、规则包含== > ### 2.4.5 判定表的简化 > > - 实际使用决策表时,常常先将它简化,简化是以合并相似规则为目标的。 > - 判定表的简化主要包含:**规则合并**与**规则包含** > > 1. 规则合并 > > 若两条或多条规则的动作项相同,条件项只有一项不同,则可将该项合并,合并后的条件项用符号`-`表示,说明执行的动作与该条件的取值无关,称为无关条件。 > 2. 规则包含 > > 无关条件项在逻辑上又可包含其他的条件项取值,具有相同动作的规则还可进一步合并。 > 4. 下面属于因果图的约束的有 ==A、互斥== B、依赖 ==C、包含== ==D、唯一== > > | 约束类型 | | 英文解释 | 约束说明 | > | ---------------------------- | ------ | ----------------- | -------------------------------------------------------- | > | <font color="red">E</font> | 互斥 | Exclusive排外的 | 原因a和b中至多有一个可能为1,即a和b不能同时为1。 | > | <font color="red">I</font> | 包含 | Include包含 | 原因a、b和c中至少有一个必须是1,即a、b和c不能同时为0。 | > | <font color="red">O</font> | 唯一 | Only唯一 | 原因a和b必须有一个,且仅有1个为1。 | > | <font color="red">R</font> | 要求 | Request要求 | 原因a是1时,b必须是1,即不可能a是1时b是0。 | > | M | 屏蔽 | Mandate授权 | 结果a是1,则结果b强制为0。 | > 5. ✔ 使用判定表方法可以充分弥补等价类边界值的不足,但是当输入条件过多时,使用判定表会产生大量测试用例 6. ❌ 因果图法可以表达重复执行的动作,例如循环结构 > ### 2.5.5 特点 [重要] > > - 优点 > > 能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。 > 可以指出需求规格说明书的不完整性和不明确之处。 > - 缺点 > > 不能表达重复执行的动作,例如**循环结构** > - 因果图与判定表的选择 > > - 条件和动作关系不明确:先使用因果图 > - 如果需求是以判定表形式给出的、项目在设计阶段就采用了判定表:直接用判定表:设计测试用例 > 7. ❌ 条件和动作关系不明确,先使用判定表法 > 先使用因果图法 > 8. 因果图是判定表前置条件,类似等价与边界关系 9. 因果图法能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏 10. 在场景法中,根据需求规格说明书中包含的时间流信息构造场景并设计相应的测试用例,使每个场景至少发生一次。 ## 作业六 1. ❌ 路径测试法对于复杂性大的程序要做到所有路径覆盖。 > 基本路径测试方法 > > 在不能做到所有路径覆盖的前提下,如果某一程序的每一个独立路径都被测试过,那么可以认为程序中的每个语句都已经检验过了,即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法。 > 2. ❌ 判定节点就是没有判定条件的节点 > 判定节点和区域 > > 包含条件的节点被称为**判定节点**,由判定根节点发出的边必须终止于某一个节点由边和节点所限定的范围被称为**区域** > 3. 下面对判定/条件覆盖测试法说法正确的是? A、判定/条件覆盖测试的测试强度比条件覆盖低 B、判定/条件覆盖只考虑判定出现“真”,“假”。 C、判定/条件覆盖只考虑条件出现“真”,“假”。 ==D、判定/条件覆盖既考虑判定需要出现“真”,“假”,也考虑条件出现“真”,假== 4. 控制流图包括哪些图形符号 A、判定 ==B、节点== C、条件 ==D、控制流线== > 控制流图中包括两种图形符号:**节点**和**控制流线** > > - **节点**由带标号的圆圈表示,可代表一个或多个语句、一个处理框序列和一个条件判定框。 > - **控制流线**由带箭头的弧或线表示,可称为边。它代表程序中的控制流。 > 5. 下面对程序的基本路径集描述正确的是 ==A、确定程序的基本路径集需要选择一条基路径== ==B、沿基路径后退,碰到判定节点翻转== ==C、基本路径集通常并不唯一== ==D、遵循先易后难的原则,对于循环,一般先让路径跳过循环,然后考虑进入循环== > 独立路径以及确定方法 > > - 独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。 > - 采用流图的术语,即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。 > - **程序基本路径集**是指由若干条独立路径组成的集合,其数量**由环形复杂度确定**。 > - McCabe开发了一种算法,用于确定程序的基本路径集合,方法如下: > > 1. 选择一个基线路径。 > 2. 沿基线路径后退,碰到**判定节点后翻转**,将翻转后的路径作为基线路径,重复本步骤,直到所有的节点都被翻转。 > > 注意:为遵循先易后难的原则, 对于循环,一般先让路径跳过循环,然后考虑进入循环。基本路径集通常并**不唯一**。 > - 一个样例 > > ![image-20230425230321085](http://storage.live.com/items/FECD80CE4F909A96!45008:/image-20230425230321085.png?authkey=AKpqV245EC2xOuk) > 6. 下面属于逻辑覆盖法的是 ==A、语句覆盖== ==B、条件覆盖== C、基础路径测试 ==D、判定条件覆盖== > ### 3.3.2 覆盖测试法 > > 依据覆盖源程序语句的详细程度不同和覆盖目标的不同,逻辑覆盖主要可分为: > > 1. 语句覆盖 > 2. 判定覆盖 > 3. 条件覆盖 > 4. 判定/条件覆盖 > 5. 条件组合覆盖 > 7. ✔ 程序基本路径集是指由若干条独立路径组成的集合,其数量由环形复杂度确定 8. ❌ 给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中**所有结点**的数量。 > 环形复杂度 > > - 环形复杂度又称为圈复杂度,以图论为基础,为我们提供了非常有用的软件度量。 > - 两种计算方法: > > 1. 其中,E是控制流图中边的数量, N是控制流图中的节点数量。 > > $$ > V(G)= E-N+2 > > $$ > 2. 其中, P是控制流图G中判定节点的数量。 > > $$ > V(G)= P+1 > > $$ > 9. ✔ 语句覆盖的基本思想是通过选择足够的测试用例,使得运行这些测试用例时,被测程序的每个语句至少被执行一次。 10. 基本路径测试法测试步骤包括以下哪些内容? 1. 画出程序的控制流图 2. 计算流图G的环路复杂性V(G) 3. 确定只包含独立路径的基本路径集 4. 根据上面的独立路径,设计测试用例,使程序分别沿上面的独立路径执行。 ## 作业七 1. 测试流程的阶段包括哪些 1. 测试计划阶段 2. 测试设计阶段 3. 测试实现阶段 4. 测试执行阶段 2. ✔ 制定测试计划确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险 > - 测试计划描述所有要完成的测试工作 > > - 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。 > - 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。 > - 目的 > 明确测试内容、测试任务安排、测试进度、测试资源、风险控制保持测试过程的顺畅, 有效控制和跟踪测试进度,应对测试过程中的各种变更。 > 3. ✔ 测试环境是指被测试软件所运行的软件环境和硬件环境 > 一般来说,软件产品提交测试后,开发人员应该提交一份产品安装指导书,在指导书中详细指明软件产品运行的软硬件环境。 > 4. 制定测试计划包括哪些 ==A、测试任务安排== ==B、测试进度== ==C、测试资源== ==D、风险控制== 5. 测试方案包括哪些 ==A、测试特性== ==B、测试方法== ==C、环境规划== ==D、工具的选择== > - 测试方案描述需要 **[重点]** > > 1. 测试的特性 > 2. 测试的方法 > 3. 测试环境的规划 > 4. 测试工具的设计和选择 > 5. 测试用例的设计方法 > 6. 测试代码的设计方案。 > - 目的 > > 从技术上对要测试的系统进行分析和测试设计,来保证测试的覆盖度。 > 6. 测试用例包括哪些 ==A、用例编号== ==B、预置条件== ==C、用例标题== ==D、操作步骤== > - 测试用例需要 **[重点]** > 1. 用例编号 > 2. 用例标题 > 3. 用例级别 > 4. 预置条件 > 5. 操作步骤 > 6. 预期结果 > - 目的 > 以最少的测试用例,实现最大的测试覆盖保证软件功能的正确性,从而提升软件质量。 > 7. ✔ 按照测试用例对软件功能进行测试。对于发现的缺陷必须记录,并且跟踪缺陷的状态,直至缺陷的验证关闭 > ### 4.1.8 执行测试用例 > > - 目的验证软件功能和性能与需求的实际匹配程度。 > - 角色与职责 > - 测试人员: > 按照测试用例对软件功能进行测试。对于发现的缺陷必须记录,并且跟踪缺陷的状态,直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例,保证测试用例与实际测试的一致性。 > - 开发人员: 对于测试人员提交的缺陷进行确认、修复。 > - 项目经理: 对测试人员与实际开发人员意见不一的问题进行裁决。 > 8. 严重性(Severity)是软件缺陷对软件质量的破坏程度 > ### 4.4.2 软件缺陷的主要属性 > > 主要属性有三个:1. 缺陷的严重性 2. 缺陷的优先级 3. 缺陷的状态 > > - 一旦发现软件缺陷,就要设法找到引起这个缺陷的**原因**,分析对产品质量的**影**响,然后确定软件缺陷的**严重性**和处理这个缺陷的**优先级**。 > - 各种缺陷所造成的后果是不一样的,有的仅仅是不方便,有的可能是灾难性的。一般问题越严重,其处理优先级就越高 > > 1. 严重性(Severity )是软件缺陷对软件质量的破坏程度 > > > | 标识 | 严重级别 | 严重程度 | > | ------ | ----------------------- | ------------------------------------------------------------------------------------ | > | 1 | 致命的(Fatal) | 主要功能完全丧失,造成系统崩溃、死机,或造成数据丢失等。 | > | 2 | 严重的(Critical) | 主要功能部分丧失,次要功能全部丧失,功能模块或特性没有实现,或致命的错误声明。 | > | 3 | 一般的(Major) | 不太严重的错误,如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。 | > | 4 | 微小的(Minor) | 一些小问题如有个别错别字、文字排版不整齐等,对功能几乎没有影响,软件产品仍可使用。 | > | 5 | 建议的(Enhancemental) | 由问题提出人对测试对象的改进意见或测试人员提的建议、质疑。 | > 9. ✔ 缺陷报告可以反映项目/产品当前的质量状态,便于项目整体进度和质量控制 10. ✔ 测试报告是针对所测软件本身,是给所测软件一个客观真实的评价 ## 作业八 1. ✔ 所有的软件测试都应追溯到用户需求 2. ✔ 一旦发现软件缺陷,就要设法找到引起这个缺陷的原因,分析对产品质量的影响,然后确定软件缺陷的严重性和处理这个缺陷的优先级 3. ❌ 设计测试用例需要做到一步到位,不需要完善 > ### 4.3.3 测试用例设计的基本原则 > > 基本原则: > > 1. 用成熟测试用例设计方法来指导设计 > 2. 测试用例的正确性 > 3. 测试用例的代表性 > 4. 测试结果的可判定性 > 5. 测试结果的可再现性 > 6. 足够详细、准确和清晰的步骤 > > 容易犯的错误: > > 1. 把测试用例设计等同于测试输入数据的设计 > 2. 强调测试用例设计得越详细越好 > 3. 追求测试用例设计“一步到位” > 4. 将多个测试用例混在一个用例中 > 5. 让没有测试经验的人员设计测试用例 > 4. ❌ 自动化测试可以完成取代手工测试 5. 下面对黑盒测试场景分析法的流描述正确的是 A、基本流不是一个场景 B、一个场景只能有基本流 ==C、一个场景可以是基本流和备选流的组合== D、一个场景只能有备选流 6. 下面哪种场景适合自动化测试情况 A、项目周期很短的项目 B、业务规则复杂的对象 ==C、需要频繁运行测试== D、软件不稳定 7. 软件测试的目的包括哪些 1. 发现系统的错误 2. 验证系统是否满足需求 3. 为产品放行提供依据 4. 改进开发流程 8. 在系统测试中,下面哪些属软件缺陷 - 软件未达到产品说明中已标明的功能 - 软件出现了产品说明书中指明不会出现的错误 - 软件功能超出了产品说明书指明的范围 - 软件测试员认为软件难以理解,不易使用,运行速度慢,或者最终用户认为该软件使用效果不好 9. Selenium支持的浏览器包括哪些 - Chrome - Edge - Firefox - Safari 10. ✔ 在使用selenium进行自动化测试的时候,如果使用的驱动和当前浏览器版本不匹配,则会影响selenium正常使用 最后修改:2023 年 06 月 12 日 © 允许规范转载 打赏 赞赏作者 支付宝微信 赞 如果觉得我的文章对你有用,请随意赞赏