1. 如果你来到公司，直接给你一个项目，你要怎么做（测试流程）（描述下你们测试的过程）

• 首先会在产品经理那里拿到需求文档，熟悉需求文档，提取测试点以及记录自己不理解的地方
• 在产品经理召开的需求评审会上提出自己不理解的地方，大家讨论解决。
• 根据测试点和数据库设计（开发会邀请我们参加数据库设计）编写测试用例，编写完成后进行用例评审，通过后等待开发提测
• 根据开发提供的接口文档进行接口用例的设计，
• 后端开发完成后，首先进行接口测试，对bug进行提交和管理
• 前后端整合完成后，首先进行冒烟测试,对主功能进行测试，通过之后再执行全部的测试用例，对bug进行提交，等待开发修复，修复完后，进行回归测试
• 测试结束后，将所测试的内容进行整理，编写系统测试报告
• 验收

  2. web和app的区别

  答: 两者测试类型是相似的，都需要进行功能，性能，安全性测试，他们主要区别：
  第一：web端一般是B/S架构，基于浏览器，APP是C/S架构，是有客户端的。所以从架构来看，web测试只要更新了服务器端，浏览器端就会同步更新，而APP端，修改了服务端，意味着客户端所使用的的核心版本都需要回归一遍
  第二：客户端性能方面，web端可能只关注响应时间，app要关心流量、电量，cpu和内存占用等
  第三：兼容方面，web端是基于浏览器的，所以测试不同OS平台下不同浏览器的兼容，APP测试必须依赖于手机，还要看分辨率，屏幕尺寸，系统版本等
  第四：APP需要专项测试：安装/卸载，弱网，交叉事件测试等

3. 功能测试测试用例怎么设计，举例说明？（测试用了有那些方法，举例说明）

答：比如说之前测试的销售管理项目中，可以新增会员信息，针对会员姓名的话，需求是2-10个字符，这时就需要用到等价类和边界值来设计；
然后在健身管理系统中，可以使用多个条件对会员进行搜索，条件之间存在多种组合关系，这时就用到正交表，正交表一般通过工具来设计，然后再对结果进行适当增加和剔除；
然后涉及到业务流程的部分，需要用到场景法进行整个流程进行分析，例如健身管理系统，一个新的用户来到健身房，经历办卡，购买课程，然后预约课程，进行打卡等步骤，才算完成整个流)

4. 如何区分前后端的bug

答：如果只是测接口产出的bug 必定是后端
响应300， 清理缓存
响应400 服务端
500 客户端
如果做功能测试发现bug 通过接口定位bug归属
如果用户参数输入正确但是前端给后端传递错误的参数 说明前端问题 前端没有正确提取参数
如果用户输入参数正确且前端传递参数也正确但是接口返回结果错误 说明后端问题后端没有实现正确的业务逻辑
如果参数正确返回结果也正确但是页面没有实现对应的效果说明前端问题前端没有正确的渲染

5. 每次迭代会产生多少需求 每个需求要覆盖多少用例

答：4周一次迭代，简单功能200-300，复杂功能300-400
产生20个需求，每个需求5个用例—10条（具体看需求复杂程度）
扩展：人员比例4:1~7:1
时间比例产品1：开发2：测试1

6. 印象深刻的bug（文件上传性能测试图片过大）

答：在之前的销售管理系统项目中，其中有个上传文件的功能点，当中存在一个比较有意思的bug，整个功能需要两个数据，批次号和文件。输入的批次号在第一次使用时并没有问题，页面显示的内容也和文件中的内容一致，但是当删除这个批次后，接着换一个文件再次使用该批次号，页面显示的内容和第一次文件中的内容一模一样，通过抓包，后端响应的数据也是和第一次的数据一致，后来通过xshell工具查看tomcat下upload文件夹，sz下载下来，发现该批次号产生的文件是第一次上传的数据。但数据库中没有这个批次号，我就推测应该是后端没有对批次号校验，将已经删除的批次号产生的文件进行数据覆盖。然后我就将bug提交给开发，最终解决的方案就是开发在代码中加了判定，如果存在对数据进行了覆盖。

7. 总共发现了多少bug？（20%左右）

答：3个模块260条用例 50条bug 2个模块180条用例 34个bug

8. 回归测试主要测什么

答：发现bug的用例，与bug相关的用例，指标达成
先测试bug有没有修复，再看修复后的代码对主流程，核心功能有没有产生影响

9. 第一个项目小组怎么分工？测试周期大概多久？

答：5：1，测试周期6个月左右
扩展：测试周期：从立项到上线

10. 编写了多少条测试用例，花了多久（一天写多少条用例，你的项目写了多少条记录）

答：我写的模块是60到70条用例，一上午的时间
扩展：一天执行200-300条用例，一天写150条

11. fiddler抓手机的包怎么抓

答：只能抓应用层http，https（AC）的
首先保证手机和电脑在一个网络上，接下来在fiddler上开启远程连接，并开启https，默认端口8888，然后在手机的wifi中设置代理，填写电脑端的ip和端口，再使用手机浏览器访问代理ip，下载证书并安装，就可以进行抓取了

12. bug的等级都有什么

答：致命：系统崩溃，数据丢失，数据损坏
严重：操作性错误，错误结果，遗漏功能
一般：小问题，错别字，ui布局，罕见故障
建议：不影响使用的瑕疵或更好的实现

13. 测试用例的属性有哪些？

不同公司定义的属性会有一些差别，大同小异
用例ID，用例名称，前置条件，操作步骤，期望结果，设计人员，重要等级，所属类别等
测试的类型+模块+功能+测试点

14. 怎么测的弱网 上行下行速率设的多少

答：可以使用fiddler抓包工具，在自定义规则里设置发送/接收1KB数据所需要的时间来控制网络传输的速率，设置300ms延迟。

15. 提的bug开发不认为是bug（这里需要注意：找产品prd文档核对，建议结果找产品确认）

答：通常开发说不是bug通常有两种情况：
1.需求里没有明确规定这个东西需要实现，这个时候可以找产品进行确认沟通要不要完善或者更改需求，确认好之后再决定要不要改（
2.bug的复现步骤很少有用户去这么操作，所以开发觉得不需要改，这个时候先去和开发解释为什么觉得这是个bug，说明这个bug带来的后果，如果还是不行，就和开发经理，测试经理进行确认沟通，最终确认是否修改
1、测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
（重要的是：有图有真相，带有清晰说明的截图比一大推描述来得直观，易懂。注意对问题区域以强调色（如红色）标识，并配以名字说明）
2、难以复现的Bug
不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
3、有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
（在时间允许的情况下，在项目测试接近收尾时开一个bug清除会议，对于剩余bug是否修复做明确处理）
4、功能性Bug
与需求不符、与原型设计不符。有时候开发对需求没有深入了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。（最好在提bug时，就把需求、设计截图带上，自然省去了大多争议，除非开发确实觉得设计有问题，需要重新进行讨论设计的）

16. 测试用例的编写流程（）

答：1.用例的要素
2.首先熟悉需求并分析项目流程，从而了解产品的业务和功能，提取测试点
3.根据测试点以及UI设计的原型图和数据库的设计，进行细化分析，使用一些用例设计方法，比如等价类，边界值，场景法等去设计测试用例，使用指定的模板进行编写
4.每个模块测试用例写完之后，我们可以从业务流程出发，去考虑是否覆盖了所有的业务场景
5.还需要考虑UI界面测试，兼容性测试，安全性测试等用例，最后提交评审

17. 发现一个偶现的bug怎么处理

答：偶发性bug也是需要提交的，描述清楚操作步骤，数据，提供响应佐证并保留运行时产生的日志，备注上可能产生的原因，必要时可以与开发人员，项目经理一起分析定位讨论，如果最终仍未解决，需要在测试报告中体现，并分析可能造成的影响，最终权衡该bug是否可遗留。如果被遗留，需要在后续版本中持续追踪该bug，直到被修复，或者三五个版本都无法进行复现，即可关闭

18. 当你提了bug，开发进行了修改，但是bug依旧存在这种情况你该怎么做

答：1.查看代码管理服务上是否有更新
2.测试环境的程序是否是最新的
3.强制清除缓存
4.反馈给开发，同时bug状态改为reopen

19. 测试环境是如何划分的

答：测试环境：测试人员执行测试用例用的环境。测试人员自己维护
生产环境：真实用户在用的环境。运维维护
开发环境：开发人员用的联调自测试环境。开发人员自己维护
预发布环境：在生产环境发布之前做预演的一个环境。数据库的数据跟生产环境数据一模一样。运维维护
验收环境：用户/公司的业务人员/产品经理来做验收测试来用的。测试人员维护/运维

20. 两台设备同时登录，有一台会提示被挤下线，这个背后的原理是什么？

答：第一台设备登录后， 客户端和服务端都会存储一个token，这两个值是一致的，后面第二次登录，客户端和服务端又会存储一个token，这时第一台设备再发送请求，它所携带的token就和第一次不一致，就会被挤下线。

21. 怎么造数据

答：数据量比较小，可以通过页面点击操作进行添加，数据量较大，可以通过ui自动化和接口进行数据的添加，还可以通过数据库来构造

22. 你们的测试报告包含什么

答：实际测试内容，实际测试进度，实际参与人员，实际职责分配，测试环境，
数据统计：用例执行率，用例执行通过率，bug数量（按测试人员，按模块统计，按严重程度统计）
遗留问题统计及分析：主要是未修复的 bug可能带来的影响
未修复的bug 的处理方案
测试结果评估：通过/不通过

23. 产品已经上线，出现bug应该怎么处理

答：先将bug 向领导汇报
bug不严重：开发人员进行修复，测试人员进行测试，跟随下个版本发布
Bug严重：进行版本的回滚，回到上一个版本
然后要总结反思bug后期规避的方案，降低以后再次出现类似问题的概率。
回滚的注意事项:（迭代需要做的事情）
1.bug修复的测试
2.生产环境的数据修复后的验证
3.bug修改再次发布，生产环境的验证
4.新功能的

24. 浏览器中输入url后会发生什么

答：

25. 测过丢包吗

答：没测试过，我觉得可以通过cmd命令 ping ip 查看丢包（工具）

26. 如果第二天上线，这时候遇到个重大bug，作为测试怎么做

答：首先要让领导知道这个事情，同时要跟踪开发修复的进度，然后开发修复完成后要及时沟通，询问修复可能会影响那些模块，然后对bug和主功能进行回归测试，测试通过才可以关闭bug，测试不通过继续修复

27. 如果开发说不是bug，且需求文档没有说明，怎么做

答：先去确认一下需求文档中是不是没有说明，没有的话去找产品经理进行沟通，确认是否要当作bug来进行处理，目前这种处理方式行不行，如果产品经理觉得没问题，那么就关闭这个bug。如果产品经理这里需求需要变动，就需要和开发沟通修复。

28. 一个页面一直在加载，请分析可能由哪些原因导致的

答：1.前端需要加载的文件太大
2.调用的第三方js，第三方服务慢
3.接口响应慢（代码执行慢，响应信息太大）
4数据库响应慢
5网络慢（客户端网络，服务端网络）
6.后端服务比较忙或者响应慢

29. 开发提测晚了怎么办

答：提前一天先去确认能不能准时提交，再和测试主管和项目组的领导进行反馈，如果真的不能准时，就一起加班将时间补回来

30. 用例设计:一个输入框，可以搜索对应的数据，编写一个完整的case

答：

31. 怎么篡改手机软件数据；

答：使用fiddler进行抓包，使用自动响应的功能或者后置断点

32. adb 命令，monkey相关；

答：adb devices 查看设备是否连接
adb connect -s ip:端口 连接指定设备
adb install 安装包路径 安装软件
adb shell am start -W -n 主包名/主类名 启动某软件
adb pull 从手机端拉数据
monkey做稳定性测试用的

33. 用例的要点

1. 用例编号
2. 测试项
3. 用例的标题
4. 优先级
5. 预置条件
6. 测试输入
7. 操作步骤
8. 预期结果

   34.bug的管理流程

   

   35.软件开发的流程

   

   36.测试停止的标准

   1 软件已经过单元、集成、系统测试停止的标准。
   2 系统经过验收测试，并得出测试结论。
   3 项目暂停开发进行调整时，测试随之停止，备份暂停点。
   4 项目生命周期内出现重大估算或者进度偏差。测试停止，并备份数据。shuxi

   37.自动化测试的意义及价值

   1） 自动化测试提高效率，缩短测试工作时间
   2） 自动化测试和人工测试相比，每一次测试执行的操作时固定的，非常可靠
   3） 自动化测试能加大每一轮回归的力度，提高测试的覆盖率
   4） 自动化测试具备更好的重现软件缺陷的能力，具有很强的一致性和可重复性

   38.什么是冒烟测试，通过率是多少

   思路：

• 冒烟测试就是验证开发人员提交的被测程序基本功能是否可以运行，
• 是否有必要展开正式测试
• 一般要求开发人员提测之前是要完成开发内部自测的，冒烟测试也可以看做是对开发团队自测质量的检查。
• 冒烟测试用例一般选取覆盖主干功能的正面数据对应的测试用例进行抽样

• 可以制定冒烟测试通过的概率，如80,85,90%等，不同团队标准不一样，但指标仅做参考，冒烟测试是否通过，具体问题具体分析

  19.你怎么理解手工测试和自动化测试

• 手工测试一般用于测试新的功能模块，能够对程序出现的各类异常灵活地做相应处理，但执行速度较慢；不能长时间持续操作，复现性比较差；

• 自动化测试一般用于进行回归验证，比较机械，执行的效率高，可以长时间持续操作，可以反复多次进行；容易复现；
• 自动化测试还可以做兼容性测试
• 手工测试一般更多的应用于新功能的测试；

• 自动化测试更多的应用于回归测试，兼容性测试，对比测试

  20.缺陷的严重等级和优先等级如何区分

• 严重等级指某个功能未实现正确对系统造成的影响程度；

• 优先等级指某个功能未实现正确要求开发人员进行修改处理的紧急程度；

• 属于两个不同的衡量纬度

  • 例：
  • 【登录时验证码错误但是仍然可以登录】这个问题就是严重等级高但优先等级不见得很高，因为不影响我后续测试；
  • 【但如果验证码正确但仍然不可以登录】就是一个严重等级高，优先等级也高的问题

    21，什么是回归测试

    :::info

• 简单说就是之前正常的功能是否因开发人员对代码的改动而受影响所做的验证测试

• 回归测试可以根据项目的时间投入决定是100%回归还是抽样回归，各有利弊

  • 1. 当前迭代周期内部的回归（手动+半自动化）
  • 1. 之前已经迭代完成的功能的回归（建议自动化方式进行） :::

       22, 测试环境部署的流程

       :::info 测试环境，指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称，简而言之，测试环境=硬件+软件+网络+数据准备+测试工具

• 硬件：指测试必需的服务器、客户端、网络连接等辅助设备。

• 软件：指测试软件运行时的操作系统、数据库及其他应用软件。
• 网络：指被测软件运行时的网络系统、网络结构以及其他网络设备构成的环境等。
• 数据准备：一般指测试数据的准备。测试数据会在测试用例设计的阶段设计好，然后软件运行的时候，作为软件输入去验证软件功能。如果是少量、正常的测试数据，可以直接通过手动方式模拟出来，如果是大量的用户数据的模拟，可以借助测试工具来构建。
• 测试工具：工具是辅助测试的好帮手，针对将要做的测试类型，可选择合适的工具让我们的测试事半功倍。比如接口测试，可以选择Jmeter或者postman；抓包工具，可以选择fiddler，wireshark等。

一般测试人员部署测试环境的步骤：

• 安装软件，如tomcat、jdk、mysql等；
• 上传项目包，如war包，放到tomcat的webapps目录下，解压war包的命令：unzip xxx.war；
• 修改配置，根据文档中说明修改tomcat、数据库等配置信息，项目的配置文件一般在项目名/WEB-INF/classes/这个目录下；
• 启动数据库，一般开发会给出初始化sql脚本；

• 重启tomcat服务。

  • 查询相应的进程：ps -ef | grep tomcat7
  • 杀掉进程：kill 进程编号
  • 重启tomcat：执行tomcat/bin下的./shutdown.sh停止，再输入./startup.sh重新启动 :::

    23. 测试计划中指定哪些内容

    :::info

    项目计划：项目经理
    #开发计划：开发经理
    测试计划：测试经理leader
    概括列举：
    项目背景，
    测试内容[功能，性能，安全，兼容….]，测试人员，职责分配，测试进度安排，测试方法[系统测试 接口测试、人工测试 自动化测试….]测试环境，测试风险及应对措施…..
    测试风险：

• 缺陷过多导致测试不能结束

• 难以修复的缺陷造成测试用例阻碍
• 数据库的误删 :::

  24. 测试方案的内容

  :::info 概括列举：
  实际测试内容，实际测试进度，实际参与人员，实际职责分配，实际测试软硬件环境，测试数据统计，遗留问题统计及分析，测试结果评估

甲方：文档简化
乙方：文档相对比较规范，一般企业会有固定的模板 :::

25. 描述下你们测试的过程

:::info

• 结合自己的实际经验，描述需求的阅读分析，用例设计，测试执行，测试总结等过程

• 要求描述每个阶段的活动要有侧重点，要结合自身，描述具有画面感，接地气，描述自己在每个阶段具体怎么做，和相关人员如何协作 :::

  26.用例设计的方法

  :::info 等价类，边界值，判定表，正交试验，流程分析，状态转换，错误猜测,
  输出域的分析法等
  数据流分析法，用户交互（一个账户两地操作，同时请求），功能交互（订单管理生成异常单）
  注：因果图不需要，被问及就说用的比较少，因为因果图还是要转化成判定表进行后续操作的
  要求：每种用例设计方法自己要能举出实际的案例或者具体应用场景
  如：

• 等价类—-建议拿后端业务举例，不要拿界面的输入框举例，翻页功能中10页划分

• 正交分析—-多复合条件查询，可以视为每个条件参与不参与两种情况，按照多因子2状态分析；
• 流程分析—-一般涉及创单到后续的
• 状态分析—-一般一个资源在不同的条件及触发动作下会具有不同状态，比如

:::

27. 回归测试

:::info 简单说就是之前正常的功能是否因开发人员对代码的改动而受影响所做的验证测试
回归测试可以根据项目的时间投入决定是100%回归还是抽样回归，各有利弊

1. 当前迭代周期内部的回归（手动+半自动化）
2. 之前已经迭代完成的功能的回归（建议自动化方式进行） :::

   28. 如何理解手工测试和自动化测试

   :::info 手工测试一般用于测试新的功能模块，能够对程序出现的各类异常灵活地做相应处理，但执行速度较慢；不能长时间持续操作，复现性比较差；
   自动化测试一般用于进行回归验证，比较机械，执行的效率高，可以长时间持续操作，可以反复多次进行；容易复现；
   自动化测试还可以做兼容性测试
   手工测试一般更多的应用于新功能的测试；
   自动化测试更多的应用于回归测试，兼容性测试，对比测试 :::

   29. 项目测试涉及的人员的人员

   :::info 敏捷开发模式：计划会，站立会（早会），复盘会
   看板：自己的任务 不同条形框的任务转移
   2前端 5开发 2 测试 :::

   30. 测试结束的标准

   :::info

• 全部测试用例都执行完成
• 未修改的bug都被确认或置为应有状态，暂缓修改的问题都有详尽的解释
• 测试报告编写完成
• 测试收尾工作结束
• 项目处于试运行或上线阶段
• 在测试计划中定义结束标准：
  • 系统在一定性能下能平稳运行72小时，本版本中没有发现bug，普通bug的数量在3个一下，bug的修复率在90%以上
  • 实际测试的到上述要求，然后由开发经理，测试经理，项目经理共同签字，认同测试结束，版本即可发布

思路：

1. 一般情况下，系统测试结束有相应的参考标准
   如用例的执行率必须达到100%，缺陷的修复率要达到90%左右, P1致命100%修复 P2严重100%修复 P3 90%修复 一般P4建议
2. 发现的问题会按照优先等级和重要等级督促开发进行修改，不严重的问题都会留在后面处理（第一时间联系开发进行修复，对新的bug进行修复）

3. 等测试几个版本后，如果没有新的影响功能实现的问题出现；而且之前发现的bug也都已经修复到一定的比例，剩余的问题如果不影响系统的交付，可以经项目组相关人员确认后，做遗留处理 :::

   31. 怎么定位一个问题

   :::info 思路，不局限于以下方式：
   出现问题后进行初步的排查：自己的操作又没有问题——使用抓包，看接口的信息，类似于判断前后端的问题——查看数据库的信息——借助日志（微服务中的war包的tomcat）

4. 会参考错误的现象及提示的信息(例：http code )

5. 会借助一些工具进行错误信息的捕获，如fiddler等工具查看接口数据的请求和响应
6. 会借助数据库表中的数据进行观察判断
7. 会借助日志信息进行分析定位

8. 根据相关信息，制造数据，进行对比验证
   ….. :::

   32. 你发现的缺陷开发人员拒绝修改，怎么办

   :::info

9. 了解开发人员拒绝的原因，
   如果是自己测试错误造成的问题，可以撤销；
   如果不是自身问题，的确是程序问题，开发不承认，需要和开发沟通，阐述自己的观点，说服开发
   如果开发承认是自己代码问题，但由于技术问题或者修改成本问题仍然拒绝修改，反馈技术经理或者产品经理进行仲裁确认 :::

   33. 开发提测时间延后，交付时间不变，你们怎么办

   :::info 思路：不局限于以下方式

10. 向项目经理说明情况

11. 如果是整个系统提测延后，可以考虑是否有部分接口可以正常提测，优先测试
12. 考虑是否需要提前借调人员，开发一旦提测，是否要投入更多测试人力

13. 考虑加班进行赶工 :::

    34. 这个项目周期并不长，为什么要做自动化测试

    :::info 针对外包项目，就是客户要求
    自动化测试脚本是我们要给客户交付的测试成果物的一部分 :::

    35. 你们这个项目的测试用例设计了多少

    :::info 说大致数量即可

14. 如果对方说你的用例太多，可以说你们自己的用例除了测试流程的，其他的用例操作步骤相对不会很多，大概在5个操作步骤左右

15. 如果对方说你的用例太少，可以解释每个用例中操作步骤会比较多，涉及的测试点有好几个 :::

    36 .你们这个项目的缺陷发现了多少

    :::info 说大致数量即可，不要很精确 :::

    37.列举下你在这个项目中印象深刻的缺陷b

    :::info 思路：
    建议说一些接口相关的缺陷，不要只说界面上的错误

16. 数据库设计脚本上的缺陷，如主表的键值长度限制是varchar10，但从表中对应的外键长度限制是varchar8,这是一个设计的缺陷，隐藏在系统中，如果我们使用的实际数据小于varchar8,没有问题，但随着业务发展，一旦超过varchar8，就会报异常。

17. 接口返回会员的喜好关键字时，对应的json报文中，如果有喜好数据，value是一个数组【喜好1，喜好2….】,但如果没有喜好时，应该返回一个空数组【】，自己在测试时，没有喜好的时候，接口返回空字符串，自己以为正确；结果后来发现前端解析出了问题，被leader批评，印象深刻，接口测试一定要严谨
18. 接口测试时，返回的xxx时间值正确，但是格式错误，接口测试时认为值正确，大意放过了，结果前端解析出现问题，后续排查，发现自己没有关注接口的时间格式，这个错误自己第一次踩了坑后，印象深刻，后续测试接口会特意关注报文中数据的格式
19. 刚开始做测试的时候，发现一个缺陷，页面查询数据错误，把问题提交给了前端开发，由于前端开发比较忙，问题过了一天多才进行处理，开发排查后说是后端开发人员的bug，由于自己没有排查仔细，导致浪费了测试时间
20. 通过后台管理平台将一个商品设置下架操作，但是在销售查询页面，仍然能够查到该商品，可供销售，但有的时候，下架商品，就查询不到，很奇怪；最后花了很长时间，和开发确认后得知实际是因为开发人员的程序有缓存，当执行下架操作的时候，程序没有主动刷新缓存内容；所以能查到；有时删除，刚好查不到，是因为缓存本身有固定的更新时间，如果刚好赶上这个更新时间，就会发现程序是正确的，实际上是巧合而已，程序需要添加主动更新缓存机制。
    …… :::

    38. 你们的测试环境有几台，谁负责部署维护

    :::info

• 功能测试环境
• 自动化测试环境
• 生产环境 集群
  • 负载均衡
• 预发布环境（从集群中拉取）

• 然后推送到生产环境中 :::

  39. bug的严重度的分类

  :::info

• 严重：系统奔溃、数据丢失、数据损坏

• 较严重：操作性错误、错误结果、遗漏功能
• 一般：小问题、错别字、UI布局、罕见故障

• 建议：不影响使用的瑕疵或更好的实现 :::

  40. 什么是测试策略？什么是测试范围

  :::info 策略主要是指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、易用性测试等）用于说明测试方法以及如何使用测试方法
  测试范围有时等价于测试策略，有时候可以表示要进行测试的某个软件部位 :::

  41. 怎么根据线下环境评估线上环境的性能

  :::info

• 首先线下必须要有专门的性能测试环境

• 线下环境单台机器配置和线上不能相差很大，可以通过单台的机器性能推算出多态机器性能
• 如果线下机器配置很差，只能测试出程序有无性能问题，这样线下测试出来的数据对线上没有太大参考意义
• 如果想获得比较准确的线上性能情况，建议最好做线上的性能测试 :::

  42. 以实际工作为例，详细说一下用例设计的完整过程

  :::info

:::