软件部署前的软件验收测试正式与非正式测试的要点和要求？

一、 正式验收测试

正式验收测试主要目的是为软件是否达到合同/需求规格说明书中的约定标准提供客观证据，用来决定是否接受并部署该软件。

主要要点和要求如下：

测试依据：

要点：测试活动必须完全基于经过双方确认的、具有法律或契约效力的文档。这通常包括《需求规格说明书》、《合同条款》以及可能有的《服务等级协议》（SLA）。测试用例的设计旨在验证软件行为和这些文档的条款完全一致。

要求：必须建立完整的需求跟踪矩阵，确保每一个需求都有对应的测试用例进行验证，并且测试结果（通过/失败）可以被清晰追溯。

测试环境和流程：

要点：测试必须在高度模拟生产环境的独立测试环境中进行。测试过程需要被详细记录，包括测试用例的执行步骤、测试数据、实际结果和预期结果的偏差等。

要求：环境配置必须文档化并受控。测试过程需要由独立的测试团队（或买方代表）执行，开发团队在此期间通常不直接介入，以确保评估的客观性。

预先定义的准则：

要点：在测试开始前，就必须明确定义何为“通过”。这包括：所有关键测试用例必须通过；非关键用例的通过率需达到约定比例（如95%以上）；所有已发现的严重及以上缺陷必须全部解决并验证关闭。

要求：这些准则是不可妥协的硬性条件。若测试结果未达到通过准则，软件原则上不能被接受，部署活动应被暂停。

产生的验收报告：

要点：测试的Zui终产出是一份正式的验收测试报告。该报告会详细陈述测试范围、执行情况、缺陷统计、Zui终结论（建议接受/有条件接受/拒绝）。

要求：这份报告是项目验收和尾款支付的关键依据，具备法律和商业上的重要性。

二、 非正式验收测试

非正式验收测试则更加灵活和务实，通常在正式测试之前或和之并行进行。主要目的是在实际业务场景中，由真实用户来发现那些在结构化测试中难以暴露的可用性、工作流和实际业务契合度问题。

主要要点和要求如下：

侧重于用户体验和业务流：

要点：测试者（通常是Zui终用户或领域专家）并不严格遵循预先编写的测试用例，而是模拟真实的日常工作流程来使用系统。重点在于发现软件是否“好用”，而不仅仅是“能用”。

要求：需要鼓励测试者跳出固定脚本，进行探索性测试。他们应关注界面直观性、操作效率、业务流程的顺畅度以及是否符合个人工作习惯。

灵活和探索性：

要点：测试过程允许并鼓励临场发挥和随机探索。测试者可以尝试各种边缘操作或不按常规路径使用功能，这极易发现一些深层次的、涉及多个功能交互的集成性缺陷或设计漏洞。

要求：虽然过程灵活，但仍需有基本的记录机制，例如提供便捷的缺陷反馈渠道，确保发现的问题能够被有效记录和追踪。

反馈和迭代：

要点：非正式测试的主要价值在于快速收集用户反馈。它不像正式测试那样需要一个“Zui终判决”，而是作为一个持续的信息来源，为开发团队在软件Zui终交付前提供宝贵的优化机会。

要求：开发团队需要对反馈做出积极响应，快速修复那些被普遍认为影响使用的缺陷或体验问题。这个过程本质上是上线前的Zui后一次“用户淬炼”。

在实际项目中，这两种测试模式共同构成了部署前的坚实质量防线：

非正式验收测试好比一次内部预演或彩排，它在相对宽松的氛围中收集意见、打磨产品，主要解决“做对了，但不好用”的问题。

正式验收测试则是Zui终的公开演出和评分，它在严肃、严格的环境下依据既定标准进行裁决，主要解决“是否按约定做对了”的问题。

一个成熟的软件交付流程，通常会先开展一轮或多轮非正式验收测试，待主要用户体验问题和阻塞性缺陷修复后，再启动不可妥协的正式验收测试。这套组合拳能Zui大限度地确保交付的软件既符合契约标准，又能满足真实业务场景的实际需要。