什么是试点测试？定义、含义、示例
编辑团队
什么是试点测试？
测试 试点测试是一种软件测试，它在实时运行条件下验证系统的某个组件或整个系统。试点测试的目的是在项目正式发布前，评估其可行性、时间、成本、风险和性能。
此测试正是在 UAT 和生产之间进行的。
在试点测试中，一部分最终用户会在系统全面部署之前试用待测系统并提供反馈。换句话说，这相当于为后续的可用性测试进行一次预演，有助于及早发现系统中的缺陷。
下图显示了这种安排：完成的版本发布给一个有限的试点小组并在那里进行监控，而更广泛的用户群则继续使用现有系统，直到结果出来。
试点测试涉及在客户站点（或用户模拟环境）安装系统，以测试持续和定期使用情况。
最常见的方法是让系统持续运行，以便找出其薄弱环节。然后，这些薄弱环节会通过正常的流程以错误报告的形式发送给开发团队。 缺陷管理流程这些缺陷将在系统的下一个版本中修复。
在此过程中，有时验收测试也作为 兼容性测试。当开发一个系统来替换旧系统时，就会发生这种情况。
In 软件工程试点测试还可以回答一个商业问题，即产品或服务是否有潜在市场。
为什么试点测试很重要
试点是低成本学习的最后机会。之后的一切都将是生产事故。具体来说，试点测试可以实现以下目标：
- 调试软件以及用于测试和支持该软件的程序。
- 确认该产品是否真正具备全面实施的条件。
- 有助于更好地制定推广的时间、预算和资源分配决策。
- 衡量目标人群对产品或项目的反应。
- 衡量项目成功与否的标准是既定的，而不是主观臆断。
- 让团队提前演练一下在可用性测试期间将要进行的活动。
如何进行试点测试
试点测试的级别取决于迁移项目的规模和范围。实际试点测试在专用区域或实验室中进行，用户在模拟软件功能时会运行大量程序、交易和报告。
可以根据项目的具体情况进行试点测试：
- 对于一般商业企业而言，可以在数据中心的一组服务器上对一组用户进行试点测试。
- 对于网站开发企业来说，可以通过在互联网上的测试服务器或文件夹中托管网站文件来进行试点测试。
- 对于商业软件供应商，可以与一组特殊的早期采用者进行试点测试。
无论在何种情况下，试点测试都遵循由五个步骤组成的书面测试计划。
第一步：制定试点计划
第二步：准备试点测试
步骤 3：部署并测试试点测试
第四步：评估试点测试
步骤 5：准备生产部署
在进行试点测试之前，需要考虑以下事项：
- 为参与者提供充分的培训。
- 服务器部署和试点系统准备的推广计划。
- 安装过程文档。
- 每个软件应用程序的测试脚本。它由待执行的功能清单组成。
- 通过电子邮件或网站，不断向设计和测试团队提供用户反馈。
- 设置试点的评估标准，例如不满意的用户数量、支持电话和请求的数量等信息。
- 组建一个由社区合作伙伴或利益相关者组成的工作组，他们已对您的项目进行投资，并将定期开会讨论您的进展情况。
- 制定评估计划和评估工具，以收集有关试点组的知识、态度和行为变化的必要信息。
在试点测试期间，团队收集并评估测试数据。基于这些数据，团队将选择以下策略之一。
- 蹒跚前行 – 向试点组部署新的候选版本。
- 回滚 – 执行回滚计划，将试点组恢复到之前的配置状态。
- 暂停 暂停试点测试。
- 修补并继续 – 部署补丁以修复现有解决方案。
- 部署 – 继续部署该解决方案。
回滚选项是试运行的意义所在，因此恢复路径也必须以同样的方式进行演练。 恢复测试 它演练失败处理方法，而不是将其写下来并想当然地认为它会奏效。
试点测试的准入和退出标准
在没有事先商定标准的情况下进行的试点项目，一旦收到反馈，就会演变成关于意见的争论。因此，在第一位用户登录之前，两套标准都必须经过审核并签字确认。
准入条件——试点项目可在以下情况下启动：
- 用户验收测试已完成，没有未解决的缺陷严重到会阻碍日常工作。
- 试点环境在配置、数据量和集成方面都与生产环境一致。
- 试点小组已经选拔完毕，接受了培训，并被告知了演习的目的和持续时间。
- 试点期间已制定经过测试的回滚计划并配备了支持联系人。
退出标准——试点项目通常在获得约定的测量数据后结束：
- 按严重程度统计缺陷数量，并设定阈值，超过该阈值则推迟发布。
- 系统支持的业务流程的任务完成率和错误率。
- 性能与被替换系统的基准性能进行比较。
- 支持负载，例如每位用户每周提出的电话或工单数量。
- 用户满意度是通过结构化调查而非非正式评论收集的。
这些测量结果会直接影响最终的“通过”或“不通过”的决定，而同样的数据通常也会影响更广泛的决策。 基于风险的测试 评估该版本在正式发布前需要多少额外的覆盖范围。
试点测试与 Beta 测试
这两种活动经常被混淆，因为它们都会将未完成的软件展示给用户。区别在于控制：试点是在特定群体内进行的有控制的试验，而 Beta 版则是公开发布，旨在收集大量用户反馈。
| 方面 | 中试 | Beta测试 |
|---|---|---|
| 目的 | 在已知地点选定的代表性群体 | 任何选择加入的公众成员 |
| 环境 | 由团队控制的类似生产环境 | 用户自己的设备和网络 |
| 定时 | 用户验收测试之后，正式发布之前 | 试播集之后，距离正式上映就更近了。 |
| 目的 | 证明可行性、成本、风险和部署准备情况 | 收集广泛反馈，揭露罕见的环境问题 |
| 多维数据监测 | 正式的准入和退出标准以及商定的指标 | 已报告的问题和使用情况遥测 |
| 回滚 | 为试点小组制定和排练计划 | 用户自行卸载或恢复原状 |
试点测试与此同样截然不同。 用户验收测试它会询问系统是否满足约定的要求，并且来自 alpha测试这在任何客户看到构建结果之前，都是在公司内部进行的。
试点测试的优势和劣势
权衡取舍很简单：飞行员购买证据，而获得这些证据则需要付出时间安排和协调方面的努力。
| 优势 | 缺点 |
|---|---|
| 能够揭示实验室无法在实际使用模式下复现的缺陷。 | 在用户验收测试 (UAT) 和正式发布之间增加一个阶段 |
| 验证安装步骤、培训材料和支持流程 | 需要类似生产环境和专门的支持服务 |
| 为是否继续推进的决定提供可衡量的证据 | 结果仅能代表所选试点组的情况。 |
| 将故障的影响范围限制在一个用户组内，而不是所有用户。 | 短期试点项目可能会错过月底、高峰期和季节性行为。 |
| 在全面推广之前，建立利益相关者的信心 | 参与者可能不愿报告自己实际工作中遇到的问题。 |
两篇文章都主张将试点项目视为计划内的一个阶段。 软件测试生命周期 它有自己的计划和所有者，而不是作为附加在末尾的非正式浸泡期。 系统测试.
试点测试的良好实践
- 安排试点测试在可用性测试前两天。
- 在所有用户、客户和项目团队就成功结果的标准达成一致之前，不要启动试点测试。
- 要求用户在他们的材料副本上标记任何问题，描述他们的顾虑，并提出改进建议（如果有的话）。
- 告知用户试点项目的目的、持续时间和进展情况。
- 选择能够反映真实用户群体的参与者，包括那些不太自信的用户，因为一群热情洋溢的用户会得出令人欣喜的结果。
- 保留一份问题、反馈和决定的日志，以便离职审查能够基于一份记录进行。
另外两种做法来自环境本身。要尽可能仔细地覆盖试点组的设备、浏览器和操作系统的分布情况。 配置测试 将会，并确认诸如备份、监控和批处理作业等日常操作运行正常，这正是本文所涵盖的内容。 运行验收测试.
试点测试示例
以下是试点测试的一些常见示例：
- Microsoft 跑了 Windows 内幕方案发布预发布版 Windows 在正式发布之前，先将构建版本推送给志愿者渠道。
- Google 跑了 Android Beta程序它将支持的 Pixel 设备注册到预发布版试用中 Android 在公开发布之前进行构建。
- 惠普为其产品和服务开展在线试点项目。
每个示例都遵循相同的模式：由有限的、自愿参与的用户群体运行真实产品，遥测数据和反馈信息流回供应商，然后根据这些数据进行更广泛的发布。该技术在其他可用方法中的定位已在文中阐述。 软件测试类型.
