测试基础

测试的目的

• 发现缺陷 （组件测试，集成测试，系统测试）
• 增加对质量的信心（验收测试）
• 为决策提供信息
• 预防缺陷（需求阶段，系统设计阶段）

黑盒测试技术

• 测试人员不需要了解被测对象的内部结构和具体设计，测试人员通过分析被测对象的测试依据（需求规格说明书）设计测试用例。
• 包含静态测试技术和动态测试技术。

常见的黑盒测试方法有哪些？

• 等价类
• 边界值
• 场景法
• 正交试验法
• 因果图
• 错误推断法
• 状态转移
• 判定表法

你是如何选择黑盒测试方法的？

通常情况下采用：等价类 + 边界值 + 错误推测法
特殊情况：

1. 对于业务流清晰的系统，可以利用场景法贯穿整个测试过程
2. 输入条件的原因和结果之间的因果关系比较模糊，或者因果关系非常
   庞大，可以利用正交试验法选择较少的组合达到最佳效果。

白盒测试技术

• 根据被测对象的结构系统化设计测试用例的一种方法。白盒测试可以应用于任何测试级别。在不同的测试级别，其分析的结构可能有所不同。应用在组件测试中，则分析软件组件的代码结构。应用在集成测试中，结构可能是组件间的调用结构。应用在系统测试和验收测试中。结构可能是业务过程，或菜单结构。
• 包含静态测试技术和动态测试技术。

白盒静态测试技术

• 静态测试是在不运行代码的情况下，通过一种质量准则或其他准则对测试项进行检查的测试。

• 静态测试技术包含代码检查、编码规则检查、静态分析。

白盒动态测试技术

• 动态测试是通过运行程序来发现错误或验证是否符合预期。
• 基于控制流设计用例（语句测试，分支测试，判定测试，分支条件测试，分支条件组合测试，修正条件判定测试）
• 基于数据流设计用例（不常用）

请介绍下 v 模型（瀑布模型）的不同的测试阶段

V 模型中有单元测试，组件测试，系统测试，验收测试的四个阶段。

单元测试的目的是为了验证软件最小设计模块是否按照组件详细设计说明的要求工作，发现需求和设计中存在的错误，以及编码过程中引入的错误。单元测试可以采用白盒测试，也可以采用黑盒测试。单元测试中，需要为测试组件开发驱动器和桩模块。驱动器模块用于模拟被测组件上级模块，它生成测试数据下放到被测模块。桩模块用于模拟被测组件工作过程中所调用的模块。

集成测试是在软件单元测试完成并修复了所发现的错误后，进行的测试。主要是对集成的组件之间的接口和组件与组件协同工作进行的测试。黑盒和白盒测试技术可以运用到集成测试当中。常见的集成策略有一次性集成和增量式集成。

系统测试是基于系统整体需求说明书的黑盒类，这是覆盖系统所有联合的部件。目的是确认整个系统是否满足需求说明中的功能与非功能需求。

验收测试：通常是由使用系统的用户来参与或主导。目的是通过测试评估系统是否可以发布。

谈谈你对回归测试的理解

• 如果软件修复了缺陷，那么就必须引入回归测试。回归测试首先要验证缺陷是否确实被正确修复了。然后测试因此次缺陷修复而可能影响那个功能是否依然正确。回归测试可以在所有的测试阶段上进行。同时适用于功能测试，非功能测试和结构测试。回归测试有两种策略，一种是基于影响分析的回归。一种是完全回归。

如何设计一个“好的”测试用例？

• 首先，你需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
• 其次，设计测试用例的方法有很多种，但综合运用等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。
• 再次，“好的”测试用例在设计时，需要从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要。
• 最后，如果想设计一个“好的”测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。

一个用例包含哪些内容？

• 用例编号
• 用例名称
• 前置条件
• 测试步骤
• 预期结果
• 实际结果
• 功能模块
• 需求编号
• 测试类型
• 测试阶段
• 优先级
• 设计人

提交的缺陷包含什么内容？

• 缺陷标题

首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。

其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面。

最后，缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里。

• 缺陷概述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题的本质描述清楚是关键。

• 缺陷影响

缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。

缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。

• 环境配置

环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。

需要注意的是，环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。

• 前置条件

前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。

• 缺陷重现步骤

缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。

这里需要注意的是，操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。

通常测试工程师在写缺陷重现步骤前，需要反复执行这些步骤 3 次以上：
一是，确保缺陷的可重现性；
二是，找到最短的重现路径，过滤掉那些非必要的步骤，避免产生不必要的干扰。

对于缺陷重现步骤的描述应该尽量避免以下 3 个常见问题：
笼统的描述，缺乏可操作的具体步骤。
出现与缺陷重现不相关的步骤。
缺乏对测试数据的相关描述。

• 期望结果和实际结果

当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。

• 优先级（Priority）和严重程度（Severity）

严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。

缺陷的优先级和严重程度又有什么关系呢？

缺陷越严重，优先级就越高；
缺陷影响的范围越大，优先级也会越高；
有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。

• 变通方案（Workaround）

变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者他们一同决定。
牛批
变通方案的有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据。如果某个严重的缺陷没有任何可行的变通方案，那么不管修复缺陷代价有多大，优先级一定会是最高的，但是如果该缺陷存在比较简单的变通方案，那么优先级就不一定会是最高的了。

• 根原因分析（Root Cause Analysis）

根原因分析就是我们平时常说的 RCA，如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。

可以做好根原因分析的测试工程师，通常都具有开发背景，或者至少有较好的代码阅读以及代码调试的能力。

• 附件（Attachment）

件通常是为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等。

你们的测试流程是怎样的？

OBS

• 需求评审

1. 项目组组长串讲该月需求，大概说下设计想法，把一些开发任务进行分解。
2. 成员记录需求，联系需求方，组长确认，思考如何实现。
3. 开发成员对自己承担的需求进行反串讲，讲述自己的理解和实现思路。
4. 测试记录测试需求，对不明白的地方进行提问。

• 制定测试计划

1. 确定测试范围和风险，根据测试的风险级别确定测试的重点和优先级。
2. 确定测试目的
3. 确定测试方法
4. 确定测试资源
5. 计划测试进度
6. 确定测试入口和出口准则

• 测试分析和设计

1. 根据测试需求整理测试点
2. 申请相关环境的权限
3. 用例设计，用例内部评审，用例补充修改

• 测试实现和执行阶段

1. 搭建和维护测试环境，保证环境可用
2. 满足测试入口条件后（比如部署成功），执行测试用例，记录测试日志，避免重复执行，如果出现影响测试执行的事件要及时报风险，如果能自己处理则立即处理，如不能处理则上升。
3. 测试开始编写测试计划。
4. 测试运行梳理测试点，运用合适的方法设计和编写用例。
5. 团队内部对测试用例进行评审，提出意见，对用例进行维护和修改。
6. 测试搭建测试环境
7. 执行测试用例
8. 提交缺陷报告并跟踪
9. 回归测试
10. 补充和优化用例
11. 编写测试报告

数据库

1. 开发串讲他们要做的功能，我们做记录提问并搞清楚需求
2. 测试点输出，测试用例评审
3. 设计用例自动生成工具和用例执行工具
4. 生成测试用例，提交到代码库
5. 搭建流水线 （ ** ）
6. 每次合并请求时新建 docker，在 docker 中使用用例执行工具执行冒烟用例 （**）
7. 代码合并后，部署分布式环境，用例执行工具执行全量用例 （**）
8. 看护流水线，提交缺陷报告并根据跟踪
9. 回归测试
10. 补充和优化用例

你写过测试计划么，包含什么内容

写过一次

• 测试范围

  测试范围中需要明确“测什么”和“不测什么”。

• 测试策略

  测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题。测试策略会要求我们明确测试的重点，以及各项测试的先后顺序。

  测试策略还需要说明，采用什么样的测试类型和测试方法。

  第一，功能测试

  对于功能测试，应该根据测试需求分析的思维导图来设计测试用例。主线业务的功能测试由于经常需要执行回归测试，所以需要考虑实施自动化测试，并且根据项目技术栈和测试团队成员的习惯与能力来选择合适的自动化测试框架。这里需要注意的是，通常应该先实现主干业务流程的测试自动化。

  实际操作时，你通常需要先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术。对于需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。另外，你还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口。

  第二，兼容性测试

  对于兼容性测试来说，Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等

  兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定了，才会开始兼容性测试。当然也有特例，比如，对于前端引入了新的前端框架或者组件库，往往就会先在前期做兼容性评估，以确保不会引入后期无法解决的兼容性问题。

  兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。道理很简单，因为兼容性测试往往要覆盖最常用的业务场景，而这些最常用的业务场景通常也是首批实现自动化测试的目标。

  所以，我们的 GUI 自动化框架，就需要能够支持同一套测试脚本在不做修改的前提下，运行于不同的浏览器。

  第三，性能测试

  对于性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

  ...

• 测试资源

  测试资源通常包括测试人员和测试环境，这两类资源都是有限的。测试计划的目的就是，保证在有限资源下的产出最大化。所以，测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。

  测试人员是最重要的，直接关系到整个测试项目的成败和效率。测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。

  相对于测试人员，测试环境就比较好理解了。不同的项目，可能会使用共享的测试环境，也可能使用专用的测试环境，甚至还会直接使用生产环境。

• 测试进度

  在明确了测试范围、测试策略和测试资源之后，你就要考虑具体的测试进度了。测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。

• 测试风险预估

  俗话说，计划赶不上变化，对于测试也是一样的道理，很少有整个测试过程是完全按照原本测试计划执行的。通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因。

  对于需求变更，比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化。

  另外，随着测试的开展，你可能会发现前期对于测试工作量的预估不够准确，也可能发现需要增加更多的测试类型，也可能发现因为要修改测试架构的严重缺陷而导致很多的测试需要全回归，还有可能出现开发递交测试版本延期，或者人员变动等各种情况。

  所以，在制定测试计划时，你就要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。 那么，在真的遇到类似问题时，你才可以做到心中不慌，有条不紊地应对这些挑战。

如何设计登录模块的测试用例？

• 功能

  输入已注册的用户名和正确的密码，验证是否登录成功；
  输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
  输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
  用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
  用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
  如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
  如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
  用户名和密码是否大小写敏感；
  页面上的密码框是否加密显示；
  后台系统创建的用户第一次登录成功时，是否提示修改密码；
  忘记用户名和忘记密码的功能是否可用；
  前端页面是否根据设计要求限制用户名和密码长度；
  如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
  刷新页面是否会刷新验证码；
  如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
  用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
  不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
  页面默认焦点是否定位在用户名的输入框中；
  快捷键 Tab 和 Enter 等，是否可以正常使用

• 安全

  用户密码后台存储是否加密；
  用户密码在网络传输过程中是否加密；
  密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
  不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
  密码输入框是否不支持复制和粘贴；
  密码输入框内输入的密码是否都可以在页面源码模式下被查看；
  用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
  用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
  连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
  同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
  同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性

• 性能

  单用户登录的响应时间是否小于 3 秒；
  单用户登录时，后台请求数量是否过多；
  高并发场景下用户登录的响应时间是否小于 5 秒；
  高并发场景下服务端的监控指标是否符合预期；
  高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
  长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

• 兼容性

  不同浏览器下，验证登录页面的显示以及功能正确性；
  相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
  不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
  不同分辨率的界面下，验证登录页面的显示以及功能正确性。

如何处理好和开发的关系

1. 要有耐心和细心
2. 尊重对方
3. 提高自己的业务能力和技术能力
4. 要有原则
5. 积极主动

一个好的测试工程师需要什么样的素养？

1. 责任感
2. 沟通能力
3. 耐心
4. 快速学习能力
5. 自信心
6. 批判主义思维
7. 逆向思维
8. 自动化技术能力
9. 好奇心
10. 洞察力

bug 的生命周期是怎样的？

• New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
• Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team
• Open: The developer starts analyzing and works on the defect fix
• Fixed: When a developer makes a necessary code change and verifies the change, he or she can make bug status as “Fixed.”
• Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the testers end, the status assigned is “pending retest.”
• Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to “Re-test.”
• Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”
• Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
• Closed: If the bug is no longer exists then tester assigns the status “Closed.”
• Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
• Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to “rejected.”
• Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
• Not a bug:If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.

如果开发说这不是 bug 怎么办？

1. 首先确认是不是因为自己对 BUG 的描述不清晰，导致开发人员难以理解；
2. 其次确认开发环境与测试环境是否一致；
3. 确认是否是偶现的难以复现的 BUG；
4. 若开发人员说 BUG 就是设计如此，则要与产品经理确认需求是否发生变化，若需求有变化，则将 BUG 关闭，并及时更新测试用例；
5. 若意见还不一致，就和开发人员、产品经理一起开会讨论 BUG 是否需要修改，若不修改，则将 BUG 关闭，最好保留相关沟通记录，便于后续追溯。

临近发布时间节点，但还有已知缺陷没有解决，同时版本又重要又紧急，如何应对？

以下是思考方向

出现概率

• 是否必现？
• 偶现概率？
• 偶现概率偏低是否可以考虑延期修复

影响范围

• 主流程 or 异常场景？
• 主要功能 or 次要功能？
• 若是主流程，是否影响正常功能使用？
• 若是主要功能，是否影响其他功能模块的使用？
• 若是异常场景，操作步骤是否繁琐
• 该功能/场景使用频率如何？
• 出现若是界面效果不如意能否接受？

规避措施

• 技术上有没有规避措施？
• 交互上能否提醒用户执行某些操作来规避出现缺陷？
• 出现问题后能否友好提示？

项目层面

• 发布时间是否能延期？
• 发布的版本是对内还是对外发布？
• 开发能否迅速解决问题？
• 解决问题成本如何？
• 产品团队能否接受带问题发布？
• 带问题功能能否接受暂不发布，只发布正常新功能

结论

• 若是必现，主流程/主要功能，使用频率较高，无法有效规避出现该问题的出现，解决成本较高，产品团队也不接受带问题发布的话，必须解决了再发布，即使项目再紧急，没有质量的发布也是得不到用户的认可的
• 当然在实际情况中，还是要根据不同的情况进行判断的
• 也有可能存在产品团队直接做决定，我们作为测试只能提醒风险点和建议，无法直接参与决策

你觉得软件测试人员在项目过程中除了测试工作以外，还应该肩负哪些责任？

• 项目层面：需要及时发现项目测试流程的不足点，及时沟通并改善不足的地方，推进项目组的测试规范
• 个人层面：提升个人测试能力，包括学习测试工具、测试框架等，提升测试效率，进行更多拓展测试，发现更多边界问题
• 团队层面：分享个人测试技能或项目经验，帮助团队其他成员提升测试技能，避免踩上不必要的坑。

怎样保证你写的用例能覆盖所有的需求。

• 需求评审、交互评审前均需要认真阅读文档，提前准备疑问，在评审会上解决疑问
• 先写测试点，进行一轮评审，补充测试点
• 将测试点转换为测试用例，再进行一轮评审，补充测试用例
• 版本发布后，复盘找到通过扩展测试发现的缺陷，若测试用例又没有的，及时补充测试用例
• 客户反馈 Bug 或内部发现 Bug，确认是否因为测试用例没写导致的漏测，若是则及时补充测试用例

测试过程中，发生过哪些特殊情况？

• 测试工作量评估不准确
• 需要增加额外的测试类型
• 修复某些严重缺陷，导致需要全量回归
• 送测延期
• 人员变动

有发生过漏测吗？

1. 有，在 obs monitor 项目中有一次需要开发一个模块采集某个微服务的数据，通过写脚本比对模块采集的数据没问题，准许上线。在线上出故障了，系统部署节点崩溃了，由于采集的数据过多直接撑爆了内存，使得虚拟机重启。这次就是忽略了系统会采集海量数据，没有涉及这个场景。
2. 云服务页面没有做国际化。

如何避免漏测？

• 提高需求评审质量

1. 需求评审过程必须建立规范的评审流程
2. 需求评审至少有需求、开发和测试人员参加
3. 需求评审必须安排业务熟悉和测试经验丰富的测试人员参加

• 测试用例的及时更新维护

1. 每当发起了需求变更必须及时更新测试用例库和做好过程   记录及用例评审
2. 在测试过程中启发的测试用例必须及时更新或录入到测试用例库
3. 漏测情况出现时，必须分析漏测原因和补充对应的测试用例
4. 反馈的运维缺陷问题（软件部分）必须分析原因，并补充的测试用例库

• 测试用例质量的提高（颗粒度、需求覆盖度、冗余度等）

1. 测试用例的设计编写必须由有测试经验和业务基础的测试人员设计编写
2. 着重正常流程测试用例，尤其常用和典型的用户场景和操作的分析
3. 建立规范的测试用例评审制度（组长评审、同行评审或组、组之间的交叉评审或发起需求和开发进行评审）
4. 建立通用测试用例库和测试用例框架，建立优质测试用例
5. 提前并多方面准备充分的测试数据以覆盖到所有测试用例

• 测试人员测试思维和测试意识的提高

1. 组织部门内部的业务知识培训
2. 组织部门内部的   技术技能培训
3. 组织部门内部的测试交流活动

• 测试环境要尽量贴近生产环境

1. 保证测试环境   数据库与生产环境的版本和配置一致
2. 保证测试环境服务中间件与生产环境的版本和配置一致
3. 可以的话，保证测试环境主机配置与生产环境主机配置一致
4. 可以的话，保证或模拟测试环境的网络环境与生产环境的一致
5. 要注意环境的兼容性测试问题，如系统、版本、分辨率等

• 测试执行过程的规范性、严谨性和策略性

1. 测试过程严格按照测试用例执行
2. 适时进行结对测试和交叉测试
3. 适时加入探索性测试或随机测试
4. 测试前，测试人员必须熟悉业务需求，亦要熟悉软件逻辑
5. 测试过程中要不断补充遗漏的测试用例
6. 测试过程尽量贴近用户实际环境去测
7. 如有不影响实际使用的生产环境提供测试，最好在生产的环境和接口上进行测试

• 测试策略的制定与及时调整

1. 测试前根据风险定好测试策略，做好测试安排
2. 测试过程时刻关注项目进度，随时做好测试调整的准备
3. 如有充足的测试时间，最后一轮应该进行全面的回归测试
4. 如有充足的测试时间，可以进行生产环境的 beta 测试
5. 回归测试必须重点关注开发的修改范围，以免遗漏新引入的缺陷

• 漏测的原因分析及分享和漏测财富库的建立

1. 每当出现漏测现象，必须分析原因并组内通报，吸取教训
2. 每当出现漏测，必须将漏测的缺陷及原因分析录入财富库

你在工作如果遇到难题如何解决？

向内求助

1. 首先看自己项目的 wiki 有没有相关问题的解答
2. 在公司内部网站上查查有没有相关的案例分享
3. 如果时间允许，看看公司内部有没有专家可以提供咨询的

向外求助

1. 使用相关的垂直搜索网站精准搜索问题，查看现成解决方案
2. 在技术群发问
3. 有偿请教认识技术大佬

如果在有限的时间的内没有能解决，及时向领导汇报风险，借助领导的力量。

假设有一个很有挑战性的任务给到你，你之前没有接触过的，你会怎么处理？

• 首先，要挖掘这个任务的背景、需求、优先级、完成目标，详细了解这个任务的来龙去脉【挖掘需求】
• 然后要了解任务的一个整体架构，比如不同端用到的技术都有哪些，如果看不懂就要跟开发或者负责人沟通清楚【了解架构】
• 将任务根据类型或者步骤分成多个小任务，给每个小任务制定详细的测试方案、技术方案【任务分解】
• 根据方案查漏补缺自己的知识点和技术，不懂的就积极问【查漏补缺】
• 执行任务过程遇到问题记录下来，自行找解决方案或者找开发、大牛解答【沟通疑问】
• 最终输出任务结果的时候，输出每个小任务的关键结果数据以及结论【总结结果】

工作中经常有人找你打断你手头上的工作的话你会怎么处理？

可能要抽时间梳理一个问题解决地图。把经常问到的问题，分类写出解决方案或沟通地图，链接放在通讯工具签名处。如果有相同的问题来找，直接让人看链接。

如果是特殊的事情，看对方是否有托付心态，如果对方想我你帮忙解决，就果断拒绝。如果是想知道解决的方法，知道可以给他说方法。

对于以下的情况，基本都会做：

• 这个“帮忙”是领导交代过的，不要拒绝，但可以协商帮到什么程度

• 在自己责任范围内的事情不要拒绝，积极主动地接手过来

• 培养人的事情不要拒绝，也不要告诉他答案，可以给他解决问题的思路，引导他成长

拒绝的说话技巧：

• 先说事实：“今天有五件事没做完”、“老板今天下午就要”，这些都是事实，当你说出这些事实的时候，对方就知道你为什么要拒绝他，不会产生误解。

• 再谈感受：“我现在着急得很”，当你说出内心感受的时候，对方很容易感同身受、产生共鸣，就不好意思了。

• 最后给建议：“能不能先问问别人……”有了前两层的铺垫，这时候你再说出自己的建议时，对方就容易接受多了。提醒，千万不要开口就说这句，会适得其反，因为对方不理解你为何拒绝他，这时这句就会显得是在搪塞他。

现在在进行一个版本的测试，临时插入了一个需求，你会怎么处理这种情况？

首先需要从几个维度进行分析判断

• 谁给的需求？了解需求的背景
  测试经理、产品经理、销售、客户
• 需求跟版本的关联性？
  跟版本没有关联、 这个需求是新版本的一个需求只不过延期送测
• 需求的重要性、紧急程度？
  重要且紧急、重要但不紧急、不重要但紧急、不重要且不紧急
• 需求是项目上的，还是其他项目？
  如果是其他项目的就要判断到底属不属于我们测试，以及要沟通清楚为什么给到我们这边测试。

综合来看

• 只有重要且紧急的需求，且是由重要负责人提出。且是属于本项目的、跟本次送测有部分关联的需求才会允许临时改变测试计划.

• 如果是其他情况的话，我们是不允许中途测试其他需求的，一般就会在测完这个版本后，再安排下一个版本的测试