测试面试题

1.测试流程     

   我们一般在项目进行立项会【产品经理  项目经理  开发人员 测试人员】的时候进行参与，讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写 测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审，开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug 开发进行修改，修改成功侯关闭bug，进行回归测试，在上线前进行测试总结。

《需求文档》/《规格说明使用书》

《测试计划》 一般由于测试组长或者是测试经理编写  （参与）

《测试用例》   根据模块划分/根据测试功能/性能/自动化进行划分

 用例评审会【测试人员 测试组长/项目经理 产品经理】：       a:组内评审   

                   【测试人员 测试组长/项目经理 产品经理 客户】： b:组外评审

冒烟测试：   对软件的主要功能进行测试

回归测试： 

测试总结：一般由于测试组长或者是测试经理编写  （参与）

日常工作：（其中几个 并不是所有的）

    1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。 2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试 3、负责测试用例的编写；编写测试报告和对测试结果分析， 4、与开      发人员、产品经理沟通和协作，推动整个项目的顺利进行； 5、负责软件开发团队项目进度管理工作，6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等      至少一种性能测试工具 8 . 熟练掌握java/python/shell 等编程语言的一种9.熟练使用python+selenium/appnium pytest  untest  innerHtml 10、持续性能监控

 

测试环境的搭建：

     windos       

     linux ：  tomcat  jdk   mysql  禅道  jenkins  。。。

 

2.测试分类   

 

测试分类： 按阶段划分   代码是否执行  程序运行划分  其他

 

### 阶段划分：

      单元测试：    单个功能的测试    （增删改查  分页 上传 下载 ）

      集成测试 ：   功能模块的测试      （多个功能功点进行总结在一起）

      系统测试：       多个模块合成测试     （整个软件的整体测试）

      验收测试 :       客户以及产品经理进行   （交付前的测试） 

### 程序是否执行:

       静态测试：     ui界面  业务逻辑

       动态测试：     链接数据之后 

###代码是否执行：

          黑  ： 纯功能测试   （手动测试。点点点

                    功能测试

                            安装/卸载测试

​                            界面测试

                            易用测试

​                            兼容性测试

                            逻辑功能测试

                            

                  性能测试

​                        稳定性测试    monkey命令

                        压力测试      

                        负载测试

​                         一般性能测试    系统资源使用率   

         白 ：  使用编程脚本进行测试  实现自动化
         灰：  介于黑和白之间

   其他测试：

               冒烟测试

              回归测试

              随机测试

              暴力测试 

 

 

3.测试原则：

           1.应当把“尽早和不断地测试”作为开发者的座右铭。              

            2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网 络 异常中断、电源断电等情况。 

           3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

           4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。 

          5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。 

          6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。 

          7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。 

 

 

编写测试用例的基本方法

1.等价类划分法

应用场景：多用于输入框

2.边界值法

3.因果图法

适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

4.场景法

5.错误推测法

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

6.正交表法

应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

 

 

 

测试用例包含

用例编号 用例描述  【用例所属模块】  执行条件  预期结果 测试输入   实际结果 

【测试人】  【测试版本】 【测试日期】 【备注】

 

 

 

用例评审

 

【测试人员 测试组长/项目经理 产品经理】：       a:组内评审   

【测试人员 测试组长/项目经理 产品经理 客户】： b:组外评审

 

 

用例评审标准

1. 测试用例的正确性 (测试用例不含有争议)

2. 测试用例是否冗余

3. 测试用例的覆盖率

4. 测试用例是否满足需求文档

   评审的内容有以下几个方面

   1. 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

   2. 优先极安排是否合理。

   3. 是否覆盖测试需求上的所有功能点。

   4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确_期待结果是否有明显的验证方法。

   5. 是否已经删除了冗余的用例。

   6. 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。

   7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。

   8. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤

 

 

 

 

 

4.测试发现bug而开发不认为是bug 你怎么办？

   1.找到需求文档或者是原型图进行匹对
   2.尝试多种测试环境和多种测试方式来确认是否为bug

   3.整理bug的复现的步骤和出现的频率

   4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug

   5.将客户经理  测试  测试经理和项目经理进行开确认会来判定是否为bug

   6.测试人员需要将bug整理并写入测试总结中

 

  5.开发流程

     <