软件质量保障 | 测试质量保障、自动化工具/框架、平台开发、算法测试、BAT/TMD大厂测试岗面试题/面经分享、测试团队建设与管理、测试新技术的分享。 偶尔也聊聊个人工作的收获与经验。可以帮忙内推字节、阿里、百度等大厂。
业内对软件故障频发问题进行大量研究表明：主要原因是在软件开发过程中质量保证不佳。执行严格的质量保障测试主要目的是防范发布质量差的产品，因为漏掉的小缺陷可能会导致公司经济上巨额的财务损失。一个很好的例子是Flud，它是iPad，iPhone，Android和Windows Phone的社交新闻阅读器应用程序，被称为“第一个真正的社交新闻阅读器”。但是由于软件质量不佳，频频出现启动失败问题。Flud团队的重视开发忽略测试，当产品最终发布时，它不可避免会出现缺陷。即使一切都已解决，但不良的声誉和糟糕的用户体验仍然阻碍了它的成功。因此，Flud公司倒闭了。
保障高质量软件的方法是实施有效的QA管理，该管理为构建无缺陷产品提供工具和方法。本文将讨论如何改善软件测试过程并提高软件产品质量的最佳实践。
敏捷软件开发周期
1.制定测试计划和测试流程
测试流程应精心制定、定义和记录。好的文档是在软件团队内部建立有效沟通的工具。因此，有效的计划需要为项目创建质量和测试计划。让我们看一下支持质量保障流程中产出的主要文档类型。
测试政策
测试政策是在组织级别创建的最高级别的文档。它定义了公司采用的测试原则和公司的测试目标。它还说明了如何进行测试以及公司如何衡量测试的有效性。
没有创建测试政策的标准方法，但通常包括以下内容：
- 从公司层面定义什么是测试
- 组织的测试目标
- 项目中软件测试的通用准则
- 测试条款的定义，以阐明其在其他文档中的进一步用法
- 列出支持测试过程的工具
- 评估测试效率的方法和指标
- 改进测试过程的方法
质量管理计划
质量管理计划是定义可接受的产品质量水平并描述项目将如何达到此水平的文档。这不是强制性文件，但是它将帮助你安排所需的所有任务，以确保项目满足客户的需求和期望。该计划的主要目标是支持项目经理，并通过定义要实现的角色、职责和质量标准来帮助组织流程。因此，它应包括软件的质量要求并描述应如何评估它们。
质量管理计划的关键组成部分：
- 质量目标
- 关键项目可交付成果和过程将进行审查，以确保达到令人满意的质量水平
- 质量标准
- 质量控制和保证活动
- 质量角色和责任
- 质量工具
- 报告质量控制和保证问题的计划
测试策略
测试策略是从业务需求规范文档衍生而来的更具体的产品级文档。通常，项目经理或业务分析师会创建测试策略，以定义用于实现测试目标的软件测试方法。测试策略由项目的业务需求驱动，这就是为什么它与项目经理的职责保持一致的原因。
测试策略的主要组成部分是：
- 测试范围
- 测试目标
- 预算限制
- 沟通和状态报告
- 行业标准
- 测试度量和指标
- 缺陷报告和跟踪
- 配置管理
- 截止期限
- 测试执行时间表
- 风险识别
在一个小型项目中，测试策略是测试计划的一部分。但是，对于较大的项目，项目经理必须将测试策略创建为一个单独文档，然后可以从该文档中进一步制定每个测试计划。
一个好的测试策略文档可以回答以下问题：
- 产品是什么？
- 测试内容是什么？
- 如何测试它们？
- 什么时候开始测试？
- 准入/准出准则是什么？
测试计划
测试计划是描述要测试什么，何时测试，如何测试以及由谁进行测试的文档。它还描述了测试范围和活动。测试计划包括要运行的测试目标，并有助于控制风险。由经验丰富的人员（例如质量检查负责人或经理）编写测试计划是一个好习惯。
一个好的测试计划应包括所有必要测试活动的时间表，以控制团队的测试时间。它还应该定义每个团队成员的角色，以便每个人都清楚需要什么。没有通用的方法来创建测试计划，因为它取决于公司的项目流程、标准和测试管理工具。根据IEEE 829标准，测试计划文档应包含以下信息：
- 测试计划标识符
- 介绍
- 参考资料（相关文件清单）
- 测试项目（产品及其版本）
- 软件风险问题
- 要测试的功能
- 未经测试的功能
- 方法（策略）
- 项目准入准出准则
- Suspension标准
- 可交付成果（测试计划文档，测试案例，工具，错误日志，问题报告等）
- 测试环境（硬件，软件，工具）
- 测试排期
- 人员配备和培训需求
- 职责范围
- 风险性
- 批准书
以下是一些使测试计划更有效的关键准则：
- 使你的测试计划简短。避免重复或无关紧要。它应该只包含相关信息。
- 请明确包括所有详细信息，例如程序的版本和版本，以使文档可搜索。
- 需要不断更新测试计划。这是一个实时文档，必须经常按需更新。
- 与利益相关者共享测试计划。它将为他们提供有关你的测试过程的信息。
测试用例
准备有效的测试用例是软件测试改进不可或缺的一部分。根据ISTQB（国际软件测试资格委员会）给出的定义，“测试用例是一组输入值，执行先决条件，预期结果和执行后置条件，针对特定目标或测试条件，例如执行特定程序路径或验证是否符合特定要求。”它是测试人员使用的关键手段之一。标准测试用例包括以下信息：
- 测试用例ID
- 测试用例描述
- 先决条件
- 测试步骤
- 测试数据
- 预期结果
- 实际结果
- 级别
- 由...制作
- 创建日期
- 执行者
- 执行日期
下面是ISTQB认证的测试用例示例：
使用以下实践来编写有效的测试用例：
- 确定可测试的需求。在开始测试过程之前，确定测试的范围和目的。
- 客户要求。编写测试用例的专家必须对功能和用户要求有很好的了解。每个测试用例都应牢记客户的要求编写。
准时写。编写测试用例的最佳时间是早期的需求分析和设计阶段。这样，质量专家可以了解所有需求是否都可以测试。
- 简单而易懂。测试用例应该简单易懂。每个测试用例应仅包括必要且相关的步骤。无论使用多少次和由谁使用，一个测试用例必须具有单个预期结果，而不是多个预期结果。
- 独特的测试用例。每个测试用例必须具有唯一的名称。这将有助于在以后的阶段对测试用例进行分类，跟踪和检查。
- 测试用例应该是可维护的。如果需求发生变化，测试人员必须能够调整测试用例。
2.采用面向测试的软件开发管理
实施面向测试的管理方法是提高软件质量的好方法。实现此目标的方法之一是使用极限编程（XP），这是一种软件开发方法，旨在产生具有适应不断变化的需求的能力的更高质量的软件。本文重点介绍与测试密切相关的两种XP惯例：
- 测试驱动的开发
- 结对编程
测试驱动的开发
测试驱动开发（TDD）是一种软件开发过程，在该过程中，在任何代码实现之前都要编写测试。TDD在重复非常短的开发周期的基础上采用了“测试先行”的方法。据此，每个新功能都从编写测试开始。开发人员在编写足够的生产代码来完成该测试之前，会先编写一个自动测试用例。该测试用例最初将失败。下一步将是编写侧重于功能的代码以使该测试通过。完成这些步骤后，开发人员将重构代码以通过所有测试。
以下是TDD的好处：
- 高质量。基于TDD的产品的质量通常比其他方法要高得多。
- 优化开发成本。从设计周期开始就进行测试，因此可以将后期调试的成本降到最低。
- 简化代码。工程师在使代码要求与特定测试保持一致方面投入了更多的精力。
- 对生产力的积极影响。TDD方法可提供有关引入错误和修复错误的快速反馈。一旦测试失败，开发人员会发现一个错误，然后对其进行修复以使其通过测试。
- 可执行文件。用例是作为测试编写的，其他开发人员可以将测试视为代码应如何工作的示例。
结对编程
结对编程也是一种极限编程技术。这种开发方法需要两名工程师在一台计算机上协同工作。其中一个（驱动程序）编写代码，而另一个（导航程序）监视代码并在整个过程中提出建议。这些角色可以随时交换。在一台计算机上工作的两个开发人员将生产质量明显更高的软件。从长远来看，提高的代码质量可以减少项目的调试和重构成本。
结对编程的好处：
- 高质量的代码。由于在代码编写之前或期间发现问题，因此将更少的错误和错误引入代码中。
- 配对编程减少了错误数量。
- 团队成员之间更好的知识共享。你将有更多的人知道产品的工作原理。在这种情况下，如果这对夫妇中的某人离开了公司，那么将剩下一些对代码有经验的人。
- 清除冗余代码。你将收到更短，更清晰的代码。这种做法也可以应用于测试过程。配对测试技术在一次头脑风暴会议中结合了两个测试人员的知识和经验，可以提高生产率。
3.测试左移
我们已经在极限编程内描述了测试驱动的编程实践。测试左移则是参考极限编程衍生一个很好的测试实践，该实践建议从项目开始过程，而不是传统方法的测试活动开始后才介入测试工作。
- 尽早计划测试策略。考虑从开发过程的早期阶段计划测试计划，以尽快检测并修复错误和故障。
- 审查要求。左移概念不一定会将所有测试活动都移到周期的开始。这也要求需要提前邀请测试人员与客户和其他利益相关者进行沟通，以审查和分析需求。
- 频繁测试。在整个开发阶段更频繁地执行较小的测试，并创建连续的反馈流，可以立即验证和改进系统。
- 自动化测试。只要有可能就实施自动化测试并最大程度地扩大测试范围也将加快并改善测试过程。
- 预防而不是应对。左移可以着重于问题的预防而不是解决。例如，测试人员可以与开发人员结成对子并为编码过程做出贡献，或者在构建之前进行测试。测试人员可以参加讨论会，提出问题并提供快速反馈以影响开发决策。
- 团队合作。这种敏捷方法在跨职能团队中最为有效，在跨职能团队中，成员紧密协作并拥有广泛的技能，因为测试人员参与开发过程和开发人员-在测试活动中，创建具有可测试性的产品。
话虽这么说，重要的是要记住，右移策略也存在，并且意味着对完整产品的生产后测试。它涉及从真正的最终用户那里获得反馈，并根据这些评论提高质量。
4.进行正式的技术评审
正式技术评审（FTR）是软件工程师执行的一项活动，旨在在早期阶段揭示功能和逻辑错误。FTR是一个小组会议，在该小组会议上，具有特定角色的与会者确保开发的软件符合预定义的标准和要求。
进行FTR的最佳时间是在你拥有成熟的产品时。但这取决于评审的类型。典型的FTR需要由具有特定角色的工程师团队担任发言人、审稿人。在每次会议结束时，应准备一份评审报告以回答以下问题：
- 评论了什么？
- 谁审查了？
- 发现哪些问题？
进行正式的技术评审有助于防止错误，并提前降低逻辑和实现错误的风险。它还可以帮助生产团队观察整个产品的功能，从而使开发更易于管理。
5.确保质量保证团队的舒适工作环境
工作环境直接影响员工的生产力和工作态度。这里有一些方法可以创造舒适的工作条件，并使你的团队保持快乐，投入和高效。
定义质量保障角色
测试包含由不同专家执行的各种活动。为了组织平稳运行的测试过程，在测试计划的计划阶段指定角色。质量保障中有六个常见角色：
- 软件测试工程师
- 测试分析师
- 测试自动化工程师
- 测试中的软件开发工程师
- 测试架构师
- 测试经理
每个角色都有自己的一套技能，职责和操作工具。要与你的质量检查团队进行适当的互动并了解每个职位的细节，请详细了解质量检查角色及其功能。
尊重测试人员
如果要实现高级质量目标，则需要在质量团队和开发人员之间建立相互尊重的信任关系。此外，最好搜索具有编码技能的人。显然，工程师会更尊重这样的测试人员。他们还将能够编写自己的一些测试工具。
质量团队负责人必须在团队会议上认识到团队的进步和成员的个人成就。
为你的质量团队提供培训
为你的质量团队提供必要的培训，以扩展他们的知识。你可以组织内部和/或外部培训课程以及团队建设练习，以改善整个团队的工作。质量小组负责人应组织头脑风暴会议，以激发团队集体创造力。这将有助于发明解决现有问题的新技术。
鼓励沟通
提高你的测试人员和开发人员以沟通效率。面对面的交流将有助于避免误解，并针对测试过程中遇到的问题分享有效的解决方案。你还需要一个优秀的团队负责人，他能够与测试人员有效地分享反馈和想法。质量经理应鼓励团队成员谈论可能影响生产力和效率的团队存在的问题和其他问题。在每个sprint或迭代结束时，由整个开发团队举行的回顾性会议是讨论成就，问题和下一步工作计划的方法之一。
让测试人员有机会在小组会议之外私下谈论事情也很重要。质量主管应保持灵活态度，并对新策略持开放态度，以最好地为团队服务。
6.用户验收测试
在产品开发中，我们具有用户角色来确定你的产品的理想客户或典型用户。用户角色是一种虚构的角色，具有产品目标受众的行为模式和目标。质量检查团队使用角色来确定在哪里以及如何查找错误。但是，遵循角色指导不能预测行为模式的整个范围。为确保你的应用程序满足用户需求，请考虑让最终用户参与测试。
传统上，最终用户测试或用户接受测试是在软件开发的最后阶段进行的。吸引最终用户测试你的应用程序可以帮助发现通常可能找不到的错误。它还证明你的软件已经可以投入生产，并且可以在开发阶段/之后向开发人员提供用户反馈。
用户验收测试类型
用户验收测试（UAT）可以通过多种方式进行。一般有5种UAT类型：
- Alpha和Beta测试是在预发布阶段进行的。Alpha测试由内部利益相关者在开发的早期阶段进行。业务和最终用户通常参与在开发环境中执行的alpha测试。内部团队的反馈意见可用于进一步提高产品质量并修复错误。Beta测试是在客户的环境中执行的，以确定应用是否适合用户使用。
- 合同验收测试是一种UAT，用于检查开发的软件是否符合合同要求。
- 法规测试可确保软件符合法律法规。
- 已完成操作验收或生产准备测试，以检查应用程序是否已准备好进行生产和使用。它验证是否安排了正确的工作流程（用户培训，备份计划，安全检查等）。
- 黑盒测试在不查看内部代码的情况下检查软件功能。这意味着测试人员仅知道应用程序应该做什么，而不知道如何做。这种类型的测试使测试团队可以获得与最终用户测试可比的最相关的结果。
测试用户文档
开发的任何类型的软件都有其用户文档（UD）。UD是有关如何使用应用程序或服务的指南或手册。因此，请确保还测试你的用户文档。你的软件手册也可以由一组最终用户测试人员进行测试。内部测试人员和技术作家负责结构和导航，而外部团队则帮助确定它是否实际可用。
在应用程序中加入用户入门也是一种很好的做法。用户入职包括一组方法，可帮助用户适应界面，导航以及总体上指导应用程序。例如，检查Canva–非设计师的设计师工具。Canva展示了用户使用视频，“做，展示，说”的方法以及整体用户友好性的一个很好的例子。如果你没有用户文档，而只选择入门指南，请确保与用户互动，以检查入门的帮助和有效性。
7.优化自动化测试
如果你确实想提高软件质量，那么绝对值得考虑使用自动化测试或使用自动化工具来运行测试。根据Capgemini，Sogeti和Micro Focus的《2020-2021年世界质量报告》，三个主要趋势中的两个是不断提高的测试自动化和敏捷方法的广泛采用。测试自动化可以节省时间，减少人为错误，提高测试覆盖率和测试能力，进行批处理测试和并行执行。以下是应用自动测试来增强流程的主要情况：
- 跨设备和跨浏览器测试
- 回归和冒烟测试
- 负载测试
- 性能测试
有各种各样的自动化测试工具。它们可以是开源的，也可以是商业的。Selenium，Katalon Studio，统一功能测试，Test Complete，Watir是最受欢迎的工具，值得首先检查。
尽管可以在传统的敏捷工作流中采用自动化测试，但它也是DevOps方法和持续集成实践的一部分。
持续集成和持续交付
持续集成（CI）是一种开发实践，要求工程师一天几次将更改集成到产品中。每个代码段都会在每次代码更改时运行“集成测试”，以快速检测错误和错误，并更轻松地定位它们。一个好的做法是将CI与自动化测试结合起来，以使你的代码可靠。Bamboo，Hudson和Cruise Control是开源工具，可用于在你的环境中引入持续集成。
持续交付（CD）被认为是敏捷原则的进化发展。这种方法意味着你可以以可持续的方式将更改快速发布给客户。CD允许在新代码就绪时承诺新代码，而无需进行短暂的发行迭代。通常，你会自动部署通过测试的每个更改。这是通过高水平的测试和部署自动化来实现的。
CI和CD实践需要连续测试，这将测试自动化提高到一个新的水平。他们在一个系统中组织了单独的自动化测试，使其成为CI / CD管道的一部分。
8.进行探索性和临时测试
尽管测试自动化具有所有明显的好处，但它仍然具有一定的局限性。当必须从用户的角度审查产品时，自动化不是最好的选择，而应让给其他测试方法。
探索性测试和即席测试的主要思想是人类的创造力。两者都几乎不需要文档，受限制或没有计划，而且两者都是随机的，会发现异常的缺陷或其他结构化测试范围未涵盖的缺陷。
因此，探索性测试是调查没有预定测试用例的产品以检查该产品实际工作方式的过程。要发现错误，需要测试人员的经验，直觉和想象力。探索性测试是即时进行的，测试将立即设计并执行。然后观察结果并将其用于修复可能的错误并设计下一个测试。
这是测试可用性的最佳方法之一，因为它涉及尝试各种现实情况和用户行为。使用此技术，可以快速评估系统，获得即时反馈并发现需要进一步测试的领域。
探索性测试的主要挑战在于，由于没有计划的脚本或严格的结构，因此难以记录其执行，复制失败和报告缺陷。
该专案测试是基于错误的猜测技术测试的最自然和最正规的方法。它通常在所有其他测试之后进行，其主要优点是速度快，因为它不需要任何准备并且没有要遵循的结构化程序。它通常与所谓的“猴子测试”相关联，当对某些随机数据执行随机测试以破坏系统时，该测试便会发生。
这种混乱的检查可以帮助检测很难通过正式测试发现并且很难重现的缺陷。但是，临时测试的结果是不可预测的，而且是随机的。
上面的两种方法有很多共同点，并且经常被混淆。但是，也有一些差异：
- 临时测试会预先研究软件；在进行探索性测试时，测试人员会在测试产品时了解该产品。
- 与完全随机的即席方法不同，探索性测试过程具有一些预定义的限制和范围，并赋予了它一定的结构。
- 临时测试通常在正式测试之后的开发过程结束时执行；而在sprint期间的任何时候都可以进行探索性测试。
最好的策略是用探索性和临时性测试来补充自动化测试。这样，你可以增加测试范围，改善用户体验并提出其他测试思路。
9.采用代码质量度量工具
如果你仍然想知道如何改善软件测试，请确保可测量，记录，审查和跟踪质量目标。没有测量代码质量的唯一正确方法。最好的建议是选择对你的工作流程简单有效的指标。
CISQ软件质量模型定义了软件质量的四个重要方面：可靠性、性能效率、安全性、可维护性和交付速度。此外，该模型可以扩展为包括可测试性和产品可用性的评估。
让我们看一下软件质量的五个主要方面，并探讨如何衡量它们：
- 可靠性。该指示器定义系统可以运行多长时间而不会出现故障。检查可靠性的目的是减少应用程序停机时间。
你可以通过测量可靠性，计算在生产中发现的bug的数量，或可靠性测试，具体而言，负载测试，支票如何在高负荷下的软件功能。也可以是回归测试，它可以 在软件进行更改时验证新缺陷的数量。
- 性能效率是指系统在给定时间间隔内执行任何操作的响应能力。可以使用以下指标来衡量性能效率：
- 压力测试可让你了解系统容量的上限。
- 保持测试会检查系统可以处理多长时间的负载以及何时性能开始下降。
- 应用程序性能监视是从特殊软件提供的用户角度出发的详细性能指标。
- 安全是系统保护信息免受软件破坏风险并防止信息丢失的能力。你可以通过扫描软件应用程序来计算漏洞数量。发现的漏洞数量是对安全性的肯定或否定度量。
- 安全更新的部署是实际安装了补丁或安全更新的用户所占的百分比。
- 解决时间是修复漏洞所需的时间。
- 可维护性是系统修改软件，将其用于其他目的，将其从一个开发团队转移到另一个开发团队或轻松满足新的业务需求的能力。一个非常简单的代码可维护性度量是检查功能或整个应用程序中的代码行数。具有更多代码行的软件更难维护。你还可以使用软件复杂性指标来衡量软件的复杂程度。更复杂的代码难以维护。
- 交付速度。衡量软件交付速度也很重要。软件版本的数量是如何频繁地传递给用户的主要指标。
10.有效地缺陷报告
良好的缺陷报告将通过清楚地识别问题并以这种方式引导工程师解决问题，从而帮助提高软件测试的效率。它必须是质量专家和开发人员之间沟通的基石和有效形式。报告写得不好会导致严重的误解。以下是有效的缺陷报告的指导原则：
- 如果可能，提供解决方案。该文档不仅必须包括缺陷场景，还必须为它们提供解决方案，即描述功能所需的行为。
- 在报告之前重现缺陷。报告缺陷时，你要确保它是可重现的。包括有关如何重现错误的清晰分步说明。确保指定上下文，并避免任何可以不同解释的信息。如果定期复制错误，仍然值得报告。
- 明晰。缺陷报告必须足够清晰，以帮助开发人员理解故障，包括有关QA所见内容的信息，以及他们希望看到的内容的声明。它应该详细说明出了什么问题。清晰性还意味着每个任务只能解决一个问题。
- 屏幕截图。包括突出显示缺陷的故障示例的屏幕截图。这简化了解决此问题的工程师的工作。
- 考虑添加缺陷摘要。准确的缺陷摘要有助于更快地确定缺陷的性质，从而减少修复时间。在缺陷清单中搜索缺陷时，它也很有用，因为缺陷ID很难记住。
最新的自动化测试工具与缺陷跟踪系统进行了内置集成。他们可以自动报告缺陷并跟踪其状态。也有单独的缺陷报告工具，例如JIRA或Mantis。
11.充分利用测试管理工具
测试管理工具是可帮助质量小组构建和管理测试过程的软件产品。此类平台可以与你的测试自动化框架、CI / CD工具、缺陷跟踪工具和其他软件解决方案集成。它们能提供以下能力：
- 计划测试活动
- 捕获要求
- 存储测试信息和结果
- 设计测试用例
- 管理测试用例环境
- 创建测试执行报告
- 通过跟踪KPI提供可见性
- 实现团队成员之间以及不同团队之间的数据共享
选择时，你必须在一个开源平台和商业平台（快速、易于使用，功能丰富且价格昂贵）之间做出选择。通常，对于小型公司来说，开源工具是一个不错的选择。
市场上有各种各样的测试管理工具可以满足不同的需求和预算。以下是一些流行的平台的简要概述。
- Zephyr是支持敏捷和DevOps框架的测试管理解决方案的全球领先提供商。它提供了多个版本：Zephyr for Jira-一种在Atlassian Jira软件内部运行的灵活的单项目工具；Zephyr Scale–也位于Jira内部的可扩展跨项目平台。
- SpiraTest是功能强大的质量检查套件，可帮助你计划和管理缺陷与需求。它提供了完整的可追溯性，各种测试类型支持以及多个报告选项。
- TestRail是一个全面的解决方案，提供了许多集成选项，包括问题和错误跟踪器以及测试自动化工具。它还具有强大的报告功能和可自定义的仪表板，可有效跟踪测试结果和重要指标并获得可行的见解。
- Kualitee是一种灵活的产品，可以进行有效的缺陷管理，测试用例管理和报告。它与各种测试系统集成，并具有移动版本。
- Testpad是一种简单，轻巧的工具，专业测试人员和其他专家（例如客户，经理等）都易于使用。它使你可以创建基于清单的测试计划，轻松添加新测试，并适应各种测试样式（ BDD，TCM，探索性等）。
