QA 与您

引言

与质量保证部门合作常常会是一种对立局面，但实际上，情况不应如此。开发人员、客户、市场营销、首席技术官、首席执行官、会计部门等等，都是交付功能性、美观、安全、可靠且易于使用的产品的利益相关者。本文只能触及这六个术语的表面

1. 函数式编程
2. 美观
3. 安全
4. 安全
5. 易于使用
6. 准确

的实际含义。根据所开发的产品，它们的权重也会有所不同。在处理REST请求的服务器中，安全性可能至关重要，而美观性则无关紧要，因为没有面向客户的用户界面。在医疗设备或飞机上的发动机切断开关中，安全性可能是优先考虑的。在移动游戏应用程序中，安全性可能无关紧要（除非您想确保用户在玩游戏时没有过马路或开车）。因此，根据应用程序的不同，您可能需要解决上述部分或全部问题，而质量保证流程应根据这些（以及我省略的）的测试方式提供适当的覆盖平衡。

最终，质量保证流程就像一个数学证明——它由正式的、可重复的流程组成，用于验证和确认应用程序。

阅读本文时...

一些小细节

• “开发人员”可以是
  • 独立开发人员
  • 顾问团队
  • 内部团队
  • 以上各项的组合
• “客户”可以是
  • 扮演客户角色的个人/团队
  • 客户可以是内部的（例如，会计部门）
  • 为之编写产品的实际客户（个人或企业）
  • 匿名——您可能正在为大众创建产品
• 质量保证人员应该是所有人
  • 开发人员
  • 市场营销
  • 首席技术官/首席执行官/首席运营官/等等
  • 客户（Beta测试人员等）
• COTS - 商业现成软件

什么是质量保证？

听起来可能有些循环，质量保证是测试应用程序以确保其满足最低要求的过程，其中要求建立了“质量”的基线。质量保证有不同种类，但至少，将其组织成四个类别会很有用

1. 函数式
2. 美观
3. 代码
4. 安全

功能性质量保证

功能性质量保证旨在验证应用程序是否满足最初促使产品开发的行为要求。在各种输入和操作下，应用程序是否以正确的方式行为，产生正确的输出和操作？功能性质量保证通常由以下方面指导

• 开发人员——这个人/团队拥有独特的“白盒”视角，因此可以提供有价值的输入，说明如何最大化代码路径测试，以确保程序的所有行为方面都得到测试。这不仅包括“正常”行为，还包括错误处理和错误恢复。
• 客户（或扮演客户角色的人）——客户想知道程序是否能满足他们的需求，以及程序所做的事情是否准确、安全、可靠、易于使用等。
• 质量保证团队——它是否满足要求？它是否处理问题（网络中断、硬件故障、错误输入等）？它是否适用于各种硬件/操作系统版本？硬件/操作系统/第三方配置矩阵是什么？这些是开发人员和客户可能都没有考虑到的测试，它们源于对其他系统的了解和一般经验。它通常可以由开发人员在开发过程中遇到的问题以及客户根据其特定领域知识所了解的问题来指导。

美观性质量保证

这是一个经常被忽略但很重要的步骤，其相关性因应用程序类型而异

• 客户——它使用起来直观吗？它是否与现有流程/工作流程配合良好？它容易学习吗？
• 市场营销——它看起来好吗？它比竞争对手更好看吗？它能自我推销吗？
• 用户界面的外观和感觉是否一致——字体、颜色、布局等。

没有人希望一个应用程序因为笨拙、增加了工作量或与现有业务流程不一致而让每个人都讨厌使用。市场营销希望确保产品达到或超过竞争对手目前拥有的产品，而当潜在客户访问您的网站并查看应用程序截图时，第一印象往往是成败的关键。

代码质量保证

这是另一个经常被忽略的步骤。在这里，开发团队和首席技术官应该参与其中

• 代码是否文档完善？
• 代码是否可维护？
• 应用程序是否易于扩展？
• 是否存在暴露的后门？
• 所有敏感数据是否都得到了适当的保护/加密？

人员来来往往，应用程序必须随着新技术的出现和竞争对手升级其产品而不断增强。同样，这可能与您正在开发的产品高度相关，也可能几乎不相关。

安全质量保证

客户和公司需要知道

• 数据是否安全？
• 应用程序是否受到恶意攻击的保护？
• 是否实施了必要的角色？
• 角色是否阻止具有特定权限的人员不应该访问的功能？
• 角色是否启用具有特定权限的人员应该访问的功能？

这些问题（以及更多）通常不属于应用程序的功能质量保证范围，值得单独考虑。

如何进行质量保证

质量保证关乎输入和输出以及发生的行为，无论是模拟拒绝服务攻击还是验证用户点击取消按钮时UI是否返回主屏幕。

从文档开始

质量保证从一份或（希望）多份文档开始

• 客户和市场营销的需求文档（通常，市场营销会推动额外的功能）
• 开发人员的架构/设计文档
• 在开发过程中生成的任何内部文档，有助于指导质量保证流程
• 之前质量保证周期的文档
• 已知错误（总会有已知错误）
• 已知缺失功能（总会有已知缺失功能）
• 应用程序“弧”——应用程序的整体生命周期
  • 设计
  • 开发
  • 维护
  • 未来计划的增强
  • 生命周期结束
• 其他现有文档

根据这些或部分文档，可以创建一个正式的验收测试计划 (ATP)。

共同努力

创建ATP并非易事。它涉及团队合作（如果合适，包括客户），其中不同的利益相关者对最终的通过/失败标准有不同的要求。

作为一个团队，应该制定具体和正式的测试方法。这可能很复杂，尤其是在试图确定代码质量，或创建必要的测试夹具来模拟安全问题、硬件故障等时。要求可能是相互独立的——用户希望一键生成整个卫星的线束清单，但应用程序需要细致、准确和经过验证的组件、信号和连接器信息。

这是一个迭代过程

讽刺的是，质量保证过程本身也需要进行质量保证。一旦投入使用，是否出现了质量保证过程遗漏的问题？为什么？如何改进质量保证过程？尝试提前预测，但要认识到并非所有事情都能提前预测。

创建更多文档，编写更多代码

在质量保证流程正式开始之前，必须到位各种要素。

验收测试计划

ATP 是人人遵循和同意的圣经，是规则手册。每个人都为 ATP 做出贡献

• 开发人员通过其白盒知识贡献，以最大化代码覆盖测试
• 客户通过其领域知识贡献
• 质量保证人员可以贡献他们的“我们将如何破坏它”计划
  • 错误输入
  • 意外但允许的 UI 事件（黑盒测试）
  • 硬件故障
  • 网络故障
  • 依赖项故障（服务器、服务等）
• 市场营销可以贡献外观和感觉要求、易用性、帮助文档等。
• 可能存在多个ATP
  • 用于内部状态测试的白盒ATP
  • 用于功能/美观测试的黑盒ATP
  • 用于可扩展性/可维护性的代码ATP
  • 用于需求测试的客户ATP

保持简单但全面。不要被细节压倒，但要根据可用的时间、金钱和人员配备决定合适的质量保证水平。

测试夹具

质量保证的痛点是“我到底怎么测试这个？”在这里

• 开发人员和质量保证协调测试夹具
  • 测试服务器
  • 用于测试的端点
  • 实时与模拟（模拟）接口

附加文档

还有哪些其他文档可以帮助指导和创建ATP？

• 安装文档
• 用户文档
• 帮助文档

白盒测试

质量保证通常需要以客户不关心或不需要知道的方式深入了解应用程序。

• 探测/测试点
  • 关于如何独立验证的附加应用程序/说明
    • 内部状态（在工作流可以处于任意数量状态的有状态系统中很有用）
    • 中间输出（通常是关于工作流状态的公开信息）
• 日志记录
  • 开发人员为质量保证提供工具以监控白盒日志记录——内部发生的事情
  • 开发人员为质量保证提供工具以监控黑盒日志记录
    • 这是“现场”日志记录——仅非敏感数据，限制更多，记录到安全服务器
    • 通常可能是客户要求
    • 通常有助于弄清楚现场发生了什么。
• 错误/异常报告
  • 您为质量保证提供哪些设施来监控代码异常？
    • 信息性消息框？
    • 电子邮件通知？
    • 特定异常日志通道？

输入/工作流/输出

一套正式的输入参数、工作流和预期输出是质量保证流程的基石。

• 一组要测试的初始输入状态/值
• 每组初始输入状态/值的预期输出状态/值
• 报告——是否创建了正确的报告，它们是否准确？

自动化工具

上述工作流可以自动化吗？需要开发或获取哪些工具（内部和COTS）来辅助测试自动化？

• 开发人员和质量保证共同开发内部测试自动化工具
  • 测试数据设置/拆卸
  • “跳转到”应用程序中的特定点，以测试特定行为，而无需经过一堆预先步骤
• 质量保证确定哪些COTS工具可以帮助测试自动化

报告

如何

• 质量保证报告问题？
• 开发人员报告问题已修复？
• 项目经理确定问题的优先级？
• 质量保证重新测试并签署问题？

这涉及

• 质量保证有一个正式的缺陷报告流程，包括
  • 用于跟踪缺陷修复的COTS工具
  • 重现问题的确切步骤
• 开发人员附上任何程序生成的日志，这些日志
  • 显示系统正在做什么
  • 验证质量保证采取的步骤是否确实是正确的步骤
• 开发人员/质量保证文档
  • 有助于重现问题的额外测试步骤
  • 在当前ATP中可能被遗漏的相同或类似问题可能发生的额外测试步骤
• 客户可能有一个不太正式的报告流程，需要将其输入到正式流程中
• 项目经理有能力确定问题的优先级，将问题移至“下个版本”，并跟踪解决问题所采取的步骤和所需的时间。

签署

签署涉及所有利益相关者

• 开发版
• 客户
• 市场营销
• 首席技术官/项目经理
• 其他

基本质量保证工作流程

以下工作流程

• 不一定是顺序的——它们可以并行发生，这取决于与客户等的关系和参与程度。
• 不需要在应用程序完全准备好时才发生。应用程序的特定区域可以在任何时候进行测试，尤其是在里程碑与可交付成果相关联时。

基本步骤是

1. 开发人员进行自己的测试
   1. 在此过程中，开发人员可以开始创建“白盒”ATP。
2. 内部审查
   1. 在将应用程序移交给质量保证之前，开发人员/团队进行内部测试。
   2. 这也是进行代码质量保证的好地方。
   3. 可以在这里提供对质量保证的任何额外指导。
   4. 任何额外的辅助工具（如上所述，测试夹具、模拟器等）可以在这里确定，如果不是更早的话。
3. 质量保证测试
   1. 质量保证测试应用程序。
   2. 发现并修复问题或将其移至“下个版本”
   3. 过程迭代
4. 客户/现场测试
   1. 客户测试应用程序。
   2. 发现并修复问题，或接受变通方法，或同意将问题移至“下个版本”。
   3. 过程迭代。

有限的现场测试通常是向所有人发布应用程序之前的一个有用步骤。那些愿意成为新产品小白鼠，在出现严重问题时有备用系统，并且能够清晰沟通问题并提供有用反馈的特定客户——嗯，这些客户就像黄金一样。

结论

虽然本文只是触及了正式质量保证流程的表面，但它旨在作为高级规划和质量保证流程的介绍，特别是对于没有“生产”应用程序工作经验的团队，或者寻求改进目前非常非正式流程的团队。希望这能给您一两个想法！