面试题记录-- 对于软件测试的理解，测试的核心，测试策略

记录面试遇到的题
个人理解，关于测试核心，怎么做好测试等等的问题，其实总结都是为了：预防！预防！预防！
👉预防缺陷，把缺陷扼杀在摇篮里，↗测试效率

• 接口测试
• 敏捷

测试

1. 你怎么看测试？软件测试是什么，分为哪几个阶段

   怎么看测试：测试= 已知测试需求（测试项）+ 探索式测试（基于头脑风暴的业务场景+测试数据）
   软件测试的目的：主要目的是保证质量，同时现在的软件测试也讲究质量和速度，（因为竞争大），在测试过程中，不管是测试左移，还是使用到的各种测试方案和策略，主要目的还是为了有效率的保证质量。

   👉缺陷预防 / 测试应该在哪个阶段介入

   1. 尽量将测试左移，在需求分析阶段就应该介入，把设计上的缺陷，或产品经理，开发，测试间理解不一致的问题都找出来，并达成一致，预防由于理解不一致导致的不必要的缺陷的发生
   2. 推动开发完成单元测试或（开发自测：即，执行我们的部分测试用例），从而保证提交给我们的测试版本是高质量的，这样会节省大量项目时间，整个研发团队共同为质量负责任

2. 作为一名软件测试工程师，应该要具备什么素质？

   
   沟通能力体现：能够有效评估和跟踪测试缺陷，与开发人员进行沟通，准确的定位并跟踪问题，推动问题及时解决。
   因为测试是无穷尽的，但是又要保证测试的质量和效率，所以测试人员也要有策略选择的设计用例。
   测试人员必须要深入理解业务。测试工程师，不仅是发现缺陷，更要从整个流程项目流程去考虑，尽量帮助项目开发和测试融为一体，把质量体系全部搭建出来，提高开发测试所有人的质量意识。

3. 测试的一个基本测试流程是什么？

   • 首先会召开需求分析会议，参加人员有产品（或者叫业务）、开发和测试，主要是探讨需求需要的一些功能点。
   • 完了之后，开发就排期进行开发，我们就根据主管写出来的计划、分配到的任务编写测试用例。
   • 写完之后会进行用例评审，需要修改的就修改整理形成最终的用例版本。
   • 之后开发人员将软件开发完成并部署到SIT测试环境后，我们会依据测试用例来执行测试。
   • 测试过程中，对于发现的BUG提交到缺陷管理工具禅道，并跟踪bug状态直至关闭，首轮测试完后还需要第二轮回归测试或者第三轮回归测试（回归几轮都是根据具体的可用测试时间来决定的，一般我们都是回归测试一轮就结束）
   • 最后测试完成后编写测试报告。
     
     

4. ⭐测试思维：测试的思维是全面，联系，分清主次，优先级

   思维，即你看到这个产品或者这个需求的第一反应，每个人随着经验的增长会对测试的理解不一样，思维也不一样，刚开始的思维可能只是根据需求去想法设法的设计用例找bug，这只是模块，慢慢的开始从业务逻辑上去找bug，比如模型场景等，再慢慢的从需求设计上去避免bug或者说预防bug，从如何“找”到如何“避免”.（→ 可以引申“缺陷预防”了）

5. 测试分析是怎么做的？
   完全理解新需求的意思，包括每一个字，因为每一个字也许就是一个需求。同时还会不断去想新需求，以及可能会影响到哪些老功能，然后可以把这些分析出来的点用思维导图整理起来，作为一个大致的草稿，方便之后整理测试点。

6. ⭐测试的核心是什么？

   👉彻底的理解需求（→ 也是测试分析的时候要做的）
   所谓理解 ≠ 开发认为的需求，开发做成了什么，然后去测给你的版本有什么缺陷，而是指对于需求的本质要理解到位。开发往往是从实现的角度来描述需求，而不是从用户的角度。测试人员就要站在用户的角度，虚拟出用户是如何使用这个软件的，他要用这个软件去解决他什么问题，是在什么场景下去解决的。只有理解了这个要点，才能说具备了合格的测试思维.【又引出一个问题：开发和测试的区别】带着这种测试思维，再参与到需求定义的评审，设计的评审，就会更有效地把问题消灭在初始阶段，从而提升测试的效率。

   👉测试策略 ← 问你测试的方法是什么⭐
   测试策略就是要能够想到测试的重点在哪里，难点在哪里，测试要具体执行到什么程度，等等。
   测试策略更多地是从如何预防角度去思考测试的价值，而不是事后的保证。预防，就要有点未卜先知的能力。比如
   ① 对 bug 能不能做到一个影响性分析，比如他可能会出现在哪个模块，掌握二八原则。以及业务有改动的时候能及时和开发做一个沟通，他改的代码可能会影响到哪些模块，都算一个未卜先知的能力。
   ② 就是写测试用例的时候要注意优先级，这是为了之后的回归测试，毕竟回归测试的时间有限，为了更高效率地执行测试用例，回归测试的时候就可以挑选优先级比较高的用例去执行。
   ③ 探索式测试也是一个测试策略，因为一个人的思维是有局限的，一个测试执行完测试用例后，由第二个测试花一个小时时间去进行探索式测试，就是不根据测试用例来测试，完全就是以用户的角度去测试，然后提交一份测程报告，这样子可以把测试工作做得更加全面。

7. ⭐怎样做好测试 / 拿到一个项目，你会怎么做测试？ [PS：以下问题都是附属问题，所以回答有很多交集]

   要做好测试，首先我觉得测试应该尽早介入，在需求分析阶段，要彻底的理解需求，把设计上的缺陷，或产品经理，开发，测试间理解不一致的问题都找出来，并达成一致。预防由于理解不一致导致的不必要的缺陷的发生。思路：【测试左移】→ 测试用例设计很重要 →执行测试（然后接下面对应的点）

   拿到项目后，先熟悉需求、原型图，了解被测功能和各个功能的业务逻辑；支持哪些平台，有哪些不同的应用场景，是否需要考虑到稳定性、性能等等。针对以上需要测试的内容进行大概的测试规划，提炼出测试点，然后逐个细化去设计测试用例。（👉接测试用例如何设计）
   整个过程中存在疑问的及时跟开发产品沟通确认。拿到被测软件后，按照用例执行测试，提交bug，并有效进行回归测试完成bug跟踪；测试完毕后（可以+探索性测试），及时汇报测试结果，输出测试报告。

   👉问测试点怎么写的？
   测试点就是根据产品需求打出来的一个草稿，在设计测试点的时候就要考虑到正例和反例，把他们标记出来，并且加上他们的优先级，比如一般来说反例的优先级都是三级。这样有利于后续做回归测试的时候有策略选择用例。

   👉测试点，如何转化成测试用例？ ==> 场景法构造测试用例
   测试用例设计工作应该有个准出标准，即：不可以陷入测试用例感觉写不完的漩涡。
   所以在整个测试用例设计过程中， 我们都在使用用户的场景去设计用例，也就是说，我们要考虑出所有的用户场景，当用户的场景都被想全了，就准出了

   哪些测试点可以设计为测试用例呢？
   如果这个测试点，符合真实用户的行为的时候，它就应该被写成测试用例 。但是这个测试点，单独使用，无法构成真实用户的行为，那么应该与其他测试点融合或加入现有的用户场景测试用例

   👉测试用例怎么设计 / 你怎么写测试用例 ？

   ① 首先是根据产品的需求提炼出测试点，然后根据测试点扩展写成测试用例，像等价类、边界值这种方法在设计测试用例的过程中我就会潜移默化的用到了。
   ② 另外写测试用例的时候，会考虑到正例和反例，事实上在写测试点的阶段我就会把正例和反例标记出来了，以及他们的优先级。（理论上来说反例的优先级都是三级，在回归测试的是理论上是可以不做反例的回归测试的→看情况说）我觉得这样其实对后续的工作是一个很大的减负。
   ③ 我觉得测试用例设计工作应该有个准出标准，避免陷入测试用例感觉写不完的漩涡。（比如一个注册页面，10几个空，排列组合，都写不完）。所以在整个测试用例设计过程中， 我们要考虑出所有的用户场景（也就是说，当用户的场景都被想全了，就准出了）

   （评价）我觉得一份优秀的测试用例其实非常考验测试人员的工作水平，因为他需要考虑到未来执行用例的一个时间成本、人力成本、还有回归测试的策略，所以我觉得设计测试用例是非常重要的。

8. 如何执行好测试用例

   首先一定要先理解产品的需求，需求文档要分析透；然后测试用例的执行率一定要是100%；尽早开始执行测试，这样缺陷发现的越早越好。另外在用例100%执行完之后，可以安排另外一个人执行1h左右的探索性测试。

9. 什么是探索性测试
   探索性测试的特性就是不执行用例，探索式测试是先执行再记录的，一般会用在两个地方：
   ① 项目验收前，进行交叉测试（就是测试人员A根据用例测完，测试人员B去测试，但不用用例，类似找茬），进行探索性测试的时候，是以一种“新”用户的状态去，尝试发现别人（之前测试人员）没有发现的问题，可以更全面。
   ②开发提供影响性分析报告后，对那些可能会影响到的模块做探索式测试

   探索性测试中双方对象是执行探索测试的人和被测系统，验收性探索式测试需要提交一份测程报告。

   测程报告内容有什么：
   执行人、执行用户场景、执行时主要用到的测试数据、执行的证据，一般的话截图就可
   以了，执行结论，有没有没有发现的 bug 或者可以优化的建议。

10. 关于上线的准出标准：所有需求被覆盖（测试用例），测试完毕；测试执行率100%；测试通过率>95% 且 这剩下的5%不可以有1级缺陷，只可以有3个2级缺陷，3级缺陷要在30个以下。

11. 测试大神余老师的精益测试解释

    追求精益测试，朝着质量领域里的质效合一的目标去发展：以用户、业务的角度去，场景流的方式去设计测试用例。因为测试是无穷尽的，但是又要保证测试的质量和效率，所以测试人员也要有策略选择的设计用例。
    e.g. 回归测试的时候，（1）让开发提供一些缺陷影响分析，（就是改代码改动了哪些模块），再根据这个模块历史以来缺陷的一个发布量，来判断怎么去挑选回归测试的测试案例。
    （2）然后在设计阶段，重视测试用例的优先级，设计测试用例的时候跟一般方法不一样，我们更加追求精益测试的精神，出发点是以用户的场景，以一个完整的事务去考虑测试用例，而不是以单独的一个表单去考虑测试用例。

12. app和web端测试的区别

    Web端测试和移动端测试类型基本相似，web端一般都是b/s架构，，app是c/s架构：
    (1) 从系统架构来看的话：web测试只要更新了服务器端，客户端就会同步更新；而如果是app端下修改了服务端，意味着客户端用户所有使用的核心版本都需要进行回归测试一遍。
    (2) 客户端性能方面：Web端可能只会关注响应时间；App则还要关心流量、电量、cpu、等；
    (3) 兼容方面：Web是基于浏览器的，所以更倾向于浏览器（IE、Chrome、firefox）和电脑硬件，电脑系统方向的兼容；App测试则必须依赖于手机或者pad，不仅要看分辨率、频目尺寸、重要看设备系统。

    从发布的版本，安装，操作，从兼容性角度，从性能角度，安全分析
    更多看这篇

测试场景题

1. 你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决？

   首先只要是 bug 就一定要记录到缺陷管理库，如果开发驳回，先请教他驳回的原因，然后再仔细研读需求文档，用需求文档里的内容去跟开发沟通，如果还是达不成一致的话，就只能请产品经理介入了。
   和开发沟通的时候，毕竟开发也很忙，所以我会先自己先多研究几遍需求，然后跟开发约一个固定的时间来研究讨论这个问题，确认这个是不是bug。如果我发现的是一个严重的bug，那我还是要及时跟开发确认（就不是等约定时间），如果还是存在争议，向上级反应，并由上级做出决定。

   判断的依据和标准：bug的严重等级，需求说明书，产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，
   （1）如果没有文档依据，根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
   （2）根据用户的一般使用习惯，来确认是否是缺陷；
   （3）与设计人员，开发人员和客户代表等相关人员探讨，确认是否是缺陷；

2. 对于复现率不高的bug怎么处理？

   首先只要是出现的bug都必须记录到缺陷管理平台。
   bug出现的信息尽量描述清楚：包括操作系统、浏览器版本，app写明机型型号；附带问题截图及日志截图，且标题注明偶现。
   提交后对于bug的跟踪。每一轮回归测试，都会尽可能去重现这个bug；多轮回归测试中仍然不能重现，会依据这个bug的严重程度决定是否继续跟踪。bug严重程度高，在上线前需要开发一起协助复现，如果还是复现不了，记录到bug平台后续版本再跟进。

3. 上线之后客户发现bug，如果你复现不了他们所反馈的问题你会怎么办？

   根据用户反馈来模拟其操作步骤，尽量复现bug；如果测试环境中复现不出用户所提出的问题，可在最终用户运行环境中来模拟操作，定位其问题并提交bug加以修复，如果小问题的话可以跟版本迭代走，如果是严重的bug且短时间内无法定位或修复，可与产品商议暂时保留数据，锁定并减少受影响范围，并暂时下架该商品。

4. 印象最深刻的一个 bug（面试高频问题）

   （印象最深的 bug 不一定是一个严重的 bug，对于测试来说，每一个 bug 都是很重要的。可以举例子：有个bug前期没有测试出来，即将上线前发现了，这个bug是源于前期需求分析设计的时候没有分析好，因为这个东西让我们整个团队进行了一个紧急的加班，但其实如果当时我把测试设计做得好，大家都仔细一点，配合更好一点，根本就不会出现这样的问题。）
   重点在于：这些 bug 的经历让我深深的觉得测试质量的重要性，

5. 工作时的测试流程是什么？
   每个测试人员都有自己的一套测试流程。通过我这？年来的经验总结，改进之后（自己总结，吸取同行的方法）的流程：
   需求评审（有开发人员，产品经理，测试人员，项目经理）
   －>需求确定(出一份确定的需求文档)
   －>开发设计文档（开发人员在开始写代码前就能输出设计文档）
   －>想好测试策略，写出测试用例
   －>发给开发人员和测试经理看看（非正式的评审用例）
   －>接到测试版本
   －>执行测试用例（中间可能会补充用例）
   －>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）
   －>开发人员修改（可以在测试过程中快速的修改）
   －>回归测试（可能又会发现新问题，再按流程开始跑）。

返回主目录