10 Essential QA Interview Questions *

软件质量保证(SQA)代表了关注软件开发整个过程的所有活动和过程. 它的目标是在最终产品发布之前最小化导致缺陷和失败的风险. It is done by designing, implementing, 维护帮助开发人员和软件测试人员以最有效的方式完成工作的过程.

与SQA不同，软件质量控制(SQC)是完全面向产品的. SQC的目标是在最终产品上执行测试活动，以验证所开发的产品符合客户的需求和期望.

在QA中，为所有场景测试所有可能的测试用例是不可行的. 在有效输入为两位数正整数的情况下, 已经有90个有效的测试用例, 而且还有更多的无效测试用例. In such situations, 我们需要一种更好的方法来选择测试用例, 同时确保涵盖所有场景.

等效分区测试是一种软件测试技术，它对输入的测试数据进行分区, 对于来自整个分区的单个输入, 被测试的系统也会这样做. 对于这个例子，我们可以创建四个分区:

• 任何两位数正整数:大于9小于100的数字(有效输入)
• 任何单位数整数:大于-10小于10的数字(正数或负数)(无效输入)
• 任何负两位数整数:小于-9的数字(无效输入)
• 任何三位数整数:大于99的数字(无效输入)

边界值分析测试是一种软件测试技术，它使用分区之间的极值或边界作为测试用例的输入.

从这四个分区和分区之间的边界, 我们可以设计以下测试用例:

• Test cases for equivalence partitioning are: 42 (valid); -15, 2, and 107 (invalid)
• Test cases for boundary value analysis are: 10 and 99 (valid); -10, -9, 9, and 100 (invalid)

测试的基本部分是结果的验证. In test automation, throughout each test case, 我们进行验证检查，以确保我们得到正确的结果.

为了执行这些检查，例如使用Selenium [http://www].toptal.框架，我们使用 Assert* and Verify* classes of commands.

assert和verify命令组都检查给定的条件是否为真. 不同之处在于如果条件为假且检查失败会发生什么. When an assert command fails, 它后面的代码将不会被执行，测试将立即中断. 另一方面，当验证命令失败时，代码将继续执行.

当后面的代码依赖于assert命令的成功时，我们使用assert命令. E.g. 只有当我们以admin用户身份登录时，我们才希望在页面上执行操作. In that case, 我们将断言当前登录的用户等于admin用户, 测试代码只有在满足条件时才会执行——否则就没有意义了, 因为我们知道我们在错误的环境中进行测试.

当它们后面的代码不管是否满足条件都可以执行时，我们使用验证命令. E.g. 检查网页标题:我们只想确保页面标题是预期的，我们将记录验证命令的结果. 一个错误的标题本身不应该影响其他正在测试的内容.

验证和确认是质量保证中的两个基本术语，经常被错误地互换. 当谈到准确地制定正确的解决方案时，我们可以问自己两个问题:

1. Are we building the system properly? (verification)
2. Are we building the proper system? (validation)

首先，我们将确保我们正在建设的系统是工作的，它有所有必要的部分，根据指定的要求. This process is called verification. After that, 在软件开发过程的最后阶段, 我们将集中精力确保该系统满足最终用户的需要和期望, in a process that we call validation.

验证和确认在QA过程中都是至关重要的，因为它们都允许以不同的方式识别缺陷. 验证识别规范文档中的缺陷, 当验证发现软件实现中的缺陷时.

问题的严重性和优先级对于正确的问题管理非常重要. Severity表示问题的严重性, 优先级是指解决问题的紧急程度.

严重性是一个精确定义的特征，因为它是基于问题对最终用户的影响. 如果最终用户能够正常地与应用程序交互，并且应用程序的正常使用不会受到阻碍, then the severity is low. 但是，如果最终用户在使用应用程序时遇到应用程序崩溃或类似问题, the severity increases to high.

On the other hand, the value for priority 是否由负责人按照规定的要求进行个人判断来定义. 通常，随着最终用户更容易接触到问题，优先级也会增加.

严重程度高但优先级低的问题包括以下场景:

• 当在用户很少与之交互的遗留页面上单击一个模糊的按钮时，应用程序会崩溃
• 未发表的帖子(草案版本)在管理可以访问没有一个有效的登录，如果准确的地址是手动输入(e.g. http://www.private.域/ admin /小组/文章/汇票/ 19380108 /编辑)
• 点击提交按钮50次会导致应用程序崩溃

低严重性但高优先级的问题包括以下类型的场景:

• 登陆页上的公司标识不正确
• 登陆页的标题有错别字
• 错误的产品照片正在显示

测试自动化有很多优点，测试用例应该在可能和适当的时候自动化. However, 在某些情况下，测试自动化是不可取的，手动测试是更好的选择:

• 当验证取决于执行测试的人(UI/UX，可用性，外观和感觉)
• 当一个特性在不断变化和自动化测试用例的情况下被开发时，将意味着资源的浪费
• 当测试用例具有极端复杂性时，自动化它们将是对资源的浪费
• 当测试人员需要执行手动会话以获得对系统更深入的了解时

RTM是显示测试用例(由QA工程师编写)和业务/技术需求(由客户或开发团队指定)之间关系的文档.) RTM的主要思想是确保所有的需求都被测试用例覆盖, 从而确保没有任何功能未被测试.

Using an RTM, 我们可以确认业务和技术需求的100%测试覆盖率, 以及对缺陷和执行状态有一个清晰的概述. 毫无疑问，它突出了文档中任何缺失的需求和/或差异.

rtm允许更深入地了解QA工作，以及通过测试用例和重新工作它们对QA工程师的影响.

例如，假设我们有以下需求:

• R.01: A user can log in to the system
• R.02: A user can open the profile page
• R.03:用户可以向其他用户发送消息
• R.04:用户可以有头像
• R.05: A user can edit sent messages

然后我们可以设计以下测试用例:

• T.01:验证用户是否能够登录
• T.02:验证用户是否能够打开头像页面并编辑头像
• T.03:验证用户是否可以发送和编辑消息

这将给出如下RTM，显示需求和测试用例之间的关系:

Theoretically, for some products and cases, 测试活动可能占用大量的资源, 也可能是不可能的或不切实际的. 为了拥有一个合适的QA流程——一个我们能够确定产品已经准备好供用户使用的流程——我们需要能够判断我们何时完成了测试.

这就是我们应用退出标准文档的地方, 哪些列出了在产品发布之前必须满足的条件. 退出标准是在测试计划阶段定义的，它允许QA经理和测试工程师构建符合预设条件的有效且高效的QA过程, 从而确保正在构建的系统满足需求并按时交付.

退出标准可以包括:测试用例覆盖率, 按优先级和/或严重程度划分的剩余问题, feature coverage, deadlines, business requirements, etc.

例如，一个简短的退出条件列表可以是:

• All test cases have been executed
• 95 percent of tests are passing
• 不存在高优先级和高严重性的问题
• 对用户描述的任何更改都被记录下来

从这个例子中，我们可以看到，退出标准需要严格，但也要合理. 期望所有测试都100%通过可能是不现实的, 但我们必须确保不会出现导致系统故障或用户无法以预期方式使用系统的严重故障.

首先，我们从绘制代码的流程图开始:

以获得测试用例的数量, 100 percent statement coverage, 我们必须找到所有节点所在路径的最少个数. 如果我们沿着路径1-A-2-C-3-E-4-F-G-5-I-6-J，我们将覆盖所有节点(1-2-3-4-5-6), 因此，用一个测试用例满足代码中的所有语句. However, 因为两个语句(节点2和节点5)是冲突的, 一个单独的测试用例不能用于有问题的代码. 我们将需要两个测试用例来完全覆盖所有语句:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-B-G-5-I-6-J

获得100%的测试用例的数量 branch 覆盖意味着找到覆盖所有路径的最小数量 edges，基本上涵盖了所有可能的真假陈述. 通过使用来自完整语句覆盖的相同两条路径，我们可以实现几乎完整的分支覆盖. 这两条路径唯一没有覆盖的分支是“D”分支, 为此，我们需要一个额外的路径到前面提到的两个. 所以我们的三个测试将涵盖这些路径:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-B-G-5-I-6-J
• 1-A-2-C-3-D-G-5-H

路径覆盖确保在整个代码中覆盖所有可能的路径. Keeping the statement limitations in mind (X > 0 and X < 0), 以下是所有可以遵循的路径:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-C-3-D-G-5-H
• 1-A-2-B-G-5-I-6-J
• 1-A-2-B-G-5-H (when X = 0)

状态转换测试是一种黑盒测试技术，其中输入条件的变化会导致被测应用程序的状态变化. 从一个状态开始的0开关转换的数量等于从该状态开始的长度为1的转换的数量. 从图中，我们可以看到从 Reopened are:

Reopened -> In Progress
Reopened -> Resolved
Reopened -> Testing
Reopened -> Closed

这样我们总共有4个0开关转换.

从一个状态开始的1个开关覆盖等于从原始状态开始的长度为2的所有转换. 从0开关转换的信息和图表, 我们可以列出可能的1-switch转换:

Reopened -> In Progress -> Closed
Reopened -> In Progress -> Resolved
Reopened -> Resolved -> In Progress
Reopened -> Resolved -> Reopened
Reopened -> Resolved -> Testing
Reopened -> Testing -> Resolved
Reopened -> Testing -> Reopened
Reopened -> Testing -> Verified
Reopened -> Closed -> Reopened
Reopened -> Closed -> In Progress

我们列出了10种可能的1-switch转换 Reopened 状态，但由于规范的限制，如果票证处于状态 Reopened has been Closed 它只能恢复到相同的状态 Reopened，我们可以将最后的1-switch转换标记为 invalid. 这就引出了9个1-switch转换的最终计数.