软件测试常见面试题一

1.测试流程

    需求评审

    编写测试计划与方案

    编写测试用例与评审

    执行测试与BUG跟踪

    编写测试报告

    上线后进行回归测试

    总结

2.如何编写测试用例

  了解需求，根据需求设计方法(等价类，边界值……)，测试用例要素 编号，标题，所属模块，前置条件，操作步骤，预期结果，实际结果

3.测试方法和策略

  功能测试，性能测试，界面测试，安全测试，兼容测试

4.测试计划和方案由组长和测试经理完成

5.定位问题

  抓包 web端F12开发者工具 移动端filder查看响应，看前端还是后端问题 Linux查看日志都可以 tail -f日志文件名

6.如何提交bug

  使用工具：禅道

  项目名称，所属模块，提交人员，指派人员，版本号，bug标题,重现步骤，预期结果，实际结果，截图

7.bug生命周期

   bug提交，开发确认，是bug解决，提交测试，测试验证，若修复关闭bug，未修复继续打开bug

New：新建的Bug，未经评审需决定是否指派给开发人员进行修改。虚线就表示经沟通，不是bug，所以直接关闭。

Open：确认是bug后，并且认为需要进行修改，指派给相应的开发人员。

Fixed：开发人员修改后标识为修改字体，需测试人员近回归测试验证。

Delay：确认为暂时不需要修改后续需要修改的bug

Closed：修改的bug经测试人员进行回归测试通过验证，关闭bug。虚线：其他的状态的bug已经不需要修改，例如：需求有变动，已经不再是bug，直接关闭。

Reopen：经验证后发现bug未修改或未修改完，则重新打开，让开发人员重新修改

8.如何确定是界面的BUG还是接口的BUG？

  通常可以利用抓包工具来进行分析，可以从三个方面进行分析：请求接口，传参，响应。

• 1.查看请求接口url是否正确， 如果请求的接口url错误，为前端的bug
• 2.查看传参是否正确，如果传参不正确，为前端的bug
• 3. 请求接口url和传参都正确，查看响应是否正确如果响应内容不正确，为后端bug

9.遇到无法复现的bug怎么办

• 1、首先出现难以复现的bug一定要截图提交bug
• 2、其次评估bug的重要程度以及对整个项目的影响，如果影响小，就记录下来，继续跟踪
• 3、如果对项目影响较大并且多次测试（20次左右），还是无法复现，提交给项目经理组织团队进行研究

10.bug优先级

• 1.mmediate（立刻，一类）

      问题马上要解决，否则系统根本无法达到预定需求

• 2.Urgent（紧要、优先，二类）

      问题修复很紧要，关系到主要功能模块

• 3.high(高度重视，二类或者三类）

      有时间就要马上解决，否则系统偏离需求要求较大或预定功能

• 4.Normal(正常，三类)

      进入个人计划解决，表示问题不影响需求实现，但是影响其它使用方面，

      比如：页面调用出错，调用了错误等。

11.bug等级

• 1.致命缺陷：非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 　
• 2. 严重缺陷：较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 　
• 3.一般缺陷：软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 　
• 4.轻微缺陷：软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；

12.缺陷报告包含哪些内容

     缺陷id.，缺陷状态，缺陷标题，缺陷的严重程度，缺陷的优先级，缺陷所属模块，缺陷详细描述

13.双V模型

    开发v：需求分析，概要设计，详细设计，编码，集成，实施，交付

    测试v：验收/系统测试设计，集成测试设计，单元测试设计，单元测试，集成测试，系统测试，验收测试

14.alpha测试

    α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。α测试即为非正式验收测试。

15.弱网测试

    弱网测试主要就是对带宽、丢包、延时等进行模拟弱网环境。属于健壮性测试的内容

   模拟场景(如用户在地铁里，巴士上，甚至是电梯，车库等场景使用APP，我们就需要针对这些场景的弱网环境下，验证出现丢包、延时软件的处理机制，避免因用户体验不友好造成用户的流失。)

16.如果提交一个BUG，开发认为这不是一个BUG，如何处理

•     首先，将问题提交到缺陷管理库里面进行备案。
•     然后，要获取判断的依据和标准：

           v. 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

           vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

           vii.根据用户的一般使用习惯，来确认是否是缺陷；

           viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

•     合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
•     等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定

17.怎么把软件缺陷描述清晰？

     1. BUG 的详细描述，重现步骤，实际结果，期望结果

     2. BUG标题，所属的模块，缺陷类型

     3. 如果BUG的复现涉及到具体的特定文件，还需要在附件中上传该文件

     4. 如果BUG不易理解，还可以附加截图

     5. 如果是兼容性缺陷，需要写明重现BUG的环境，包括操作系统，分辨率，浏览器版本

18.需求怎么编写成测试用例？

    1. 先把需求转换成测试点

    2. 针对每个测试点，选取测试用例的设计方法

    3. 利用测试用例的设计方法，设计不同的测试数据

    4. 由测试点或者具体的测试数据转化为测试用例

19.软件测试其他的测试角度

 

 

     测试类型：功能测试外，兼容性，界面，接口，性能相关业务：与被测功能相关联的业务

 

    其他特殊角度：逆向操作（删除会员后再添加，填写订单时返回，商品重新回到购物车），

                             异常处理（支付时网络中断，提交表单时，连续点击提交按钮），

                             极端情况（后台列表，0条数据，海量数据，列表分页的一  页或者超过10页的省略显示）

20.安全性测试

     权限

     敏感信息的加密，在数据库存储，数据传输的时候。比如密码信息

     跨站脚本攻击，XSS攻击全称跨站脚本攻击(Cross Site Scripting)，是为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS