测试面试题

测试中什么时候使用 Linux

  搭建测试环境 (JDK MYSQL TOMACT NGINX)  使用 liux 对服务器简单的维护

  使用Linux 查看日志 定位bug 

测试中什么时候使用Mysql

  参数 获取 session token 多表联查(3张表的联查)

 

软件测试的原则

1 尽早原则: 不断测试 作为我们测试的座右铭
2 考虑意外情况和极端情况发生: 例如 边界值 网络异常中断,断电等
3 群集现象:开发人员不良习惯造成的 
4 测出问题能够复现问题: 测试过程中要有bug 要知道怎么能触发它 不是偶然的
5 回归测试的关联性:开发修改代码后 再测其他用例 看看是否因为更改而新生的bug
6 善于总结相关文档: 要养成写bug日志的习惯  
 

面试题: 对任意物品的测试 

回答思路: 1 功能上  体积 形状 用途 材质
          2 外观    颜色  图案
          3 性能
          4 易用性
          5 安全性

面试题: 测试中出现bug 开发不认为是bug的时候怎么办 

回答思路:  找自己的问题 
            别人的问题
            存在纠纷的时候 找领导
    1 首先我会从自己经过多次测试发现bug的出现次数和频率,记录复现bug的方式,然后送给开发人员
    2 再根据需求文档来确认是否为bug
    3 如果开发不认为是bug 将复现bug的记录和需求文档找产品经理进行商议确认是否为bug
    4 如果项目经理和产品经理都不认为是bug 我会讲bug记录在厕所文档中 方便下次评审会上将问题再次抛出
 

判断三角形

测试评审的标准 (必背)

1 测试用例的正确性测试用例不含有争议
2 测试用例是否冗余
3 测试用例的覆盖率
4 测试用例是否满足需求文档

    评审内容 
    评审的内容有以下几个方面� 
    1)用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。 
    2)优先极安排是否合理。 
    3)是否覆盖测试需求上的所有功能点。 
    4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确�期待结果是否有明显的验证方法。
    5)是否已经删除了冗余的用例。 
    6)是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在"保护"20%的功能实现。 
    7)是否从用户层面来设计用户使用场景和使用流程的测试用例。 
    8)是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤
 

BUG生命周期 (重点***)

新建, 确认, 重新严重, 关闭, 重新打开

一个 Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试:测试人员对Bug进行回归测试,如果确实已经解决,就将Bug的状态修改为关闭。否则的话则发给进行回归测试,如果确实已经解决,就将Bug的状态修改为关闭。否则的话则发给开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

缺陷报告(bug报告,提的报告)

1

测试用例设计方法?以及模板内容

测试用例设计方法有: 等价类划分法  边界值分析法 因果图法 场景法 决策表 正交实验法

 测试用例模板内容: 序号 用例编号 用例类型 所属模块 前置条件 操作步骤 预期结果 实际结果 

原文地址:https://www.cnblogs.com/sunzzc/p/13025038.html