请选择行业
请选择职位
请选择省份
请选择城市

面字节跳动Python软件测试用例编写面试(二)

时间: 2021-07-05 10:52   作者: 程序猿瑾哥哥   点击次数: 
 
  4、黑盒-判定表
  判定表:分析和表达多逻辑条件下执行不同操作的情况的工具 ;略过因果图的绘制,直接列出所有组合进行筛选;
  分析思路:判定表通常有四个部分组成:条件桩、动作桩、条件项、动作项;
  判定表的建立步骤:(根据软件规格说明)
  确定规则个数;列出所有条件桩和动作桩;填入条件项;填入动作项,得到初始判定表;简化合并相似规则;
  ==使用场景:控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。缺点是不能表达重复执行的动作,例如循环结构。
  5、黑盒-正交试验法
  正交实验法:利用因果图来设计测试用例时, 输入原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到;往往因果关系非常庞大,以至于测试用例数目巨大,为了有效地、合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
  分析思路:
  (1)提取功能说明,构造因子–状态表 ;
  (2)加权筛选,生成因素分析表 ;
  (3)利用正交表构造测试数据集 ;
  使用场景:必须考虑输入条件的各种组合(从大量的数据中挑取适量、有代表性的点,合理有效的测试)。
  6、黑盒-场景实验法
  场景实验法:软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流;生动的描绘出事件触发时的情景,有利于设计用例,同时测试用例也更容易的得到理解和执行。
  分析思路:
  每条路径都反映了基本流和备选流;基本流是最简单的路径;备选流自基本流开始,会有特定条件下加入并执行,可能有多种情况;
  使用场景(0代表基本流):0;0+1;0+1+2;0+3;0+3+1;0+3+1+2;0+4;0+3+4;…
  7、错误推断法
  错误推断法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法;更多的与用户的使用习惯及测试程序中的常见问题为主。
  分析思路:
  (1)列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据这些情况选择测试用例;
  (2)注意积累与分享;
  使用场景:任何测试、任何情景下都会用到的方法。
  有常用的测试用例集,可以参照。
  举例:数字输入验证,分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值;不合法的输入,系统给出必要的判断提示信息;
  8、黑盒-需求转换法
  需求转换法:根据需求,执行需求分析,并编写测试用例。
  分析思路:
  (1)将需求转换为思维导图;
  (2)仔细推敲每一个字的含义;
  (3)与用户的使用场景和目的结合;
  (4)严格设计每一个用例;
  (5)可以建立一种模型,进行需求转换;
  使用场景:任何测试、任何情景下都会用到的方法。
  注意:需求的变更带来的影响;需求理解偏差带来的影响;需求含糊不清带来的影响等;
  9、黑盒-设计文档
  设计文档:参照设计文档,可以理解软件系统内部设计流程及处理机制,对比写好的测试用例,可以在对应功能及模块处新增;
  分析思路:
  (1)仔细阅读设计文档;
  (2)与相关人员沟通实现机制;
  (3)结合测试用例编写方法,对比之前写好的用例;
  使用场景:任何测试、任何情景下都会用到的方法。
  注意:设计文档的编写正确性;设计文档的理解偏差;
  10、黑盒-探索式测试法
  探索式测试法:无限创意的测试点,永无止境的探索测试;我们要在测试的最前沿发挥洞察力、技术及应变措施,找出产品的缺陷;
  分析思路:
  局部探索式测试;全局探索式测试;混合探索式测试;
  使用场景:任何测试、任何情景下都会用到的方法。像漫游一样,自由地寻找软件中的缺陷,软件测试的未来必然有探索式测试。
  第二部分:白盒用例编写
  基本思路:
  第一步需要绘制流程图;
  第二步根据路径分析法确定测试用例;
  第三步使用等价类/边界值的方法确定测试用例的数据
  第四步根据实际情况补充(如默认流程、特殊流程等)
  基本策略:
  1、语句覆盖准则基本上没啥用,比较强的逻辑覆盖准则是判定覆盖或者条件覆盖;通常判定覆盖可以满足语句覆盖;语句覆盖<判定覆盖<条件覆盖;
  2、循环覆盖来说,完全的路径测试并不符合实际。

打印本页 | 加入收藏

上一篇:给要转行做软件测试的一些忠告     下一篇:大神经验:软件测试的自我发展规划

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: