测试面试题

测试中什么时候使用 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报告，提的报告)

 

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

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

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