UT /SIT/ UAT

UT /SIT/ UAT - 云+社区 - 腾讯云 https://cloud.tencent.com/developer/article/1541268

我们公司只有测试环境--准生产环境--生产环境。

UT是单元测试，Unit Test：

单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。；

单元测试是对软件中的基本组成单位进行测试，检验其函数的正确性(包括功能正常，输出正确)。

一般来说，单元测试用例的编写最早可以在设计评审完成后就启动，和编码可以同时进行。但如果在时间允许的情况下，单元测试用仞』的编写最好放在编码后进行，这样能更好地覆盖代码的各个分支。若是以设计文档为唯一的编写依据，那么对于代码走读时发现的缺陷将在用例评审中被再次发现，造成重复劳动，用例的维护期也将提前开始。

单元测试用例编写的目的是函数覆盖，覆盖的方法有：语句覆盖、分支覆盖、条件覆盖、条件组合覆盖和路径覆盖等。为了以最少的资源做最多的测试检查，首选路径覆盖的方法。路径覆盖是设计足够的测试用例，运行所测程序并覆盖程序中所有可能的路径。

SIT 集成测试

主要关注点在模块间的数量，逻辑，操作等。

集成测试是软件系统在集成过程中所进行的测试。其主要目的是检查软件单位之间的接口是否正确。其接口主要包括通信协议、调用关系、与文件或数据库等第三方中间件的交互。

集成测试用例的编写要紧扣与程序相关的各个接口，使每类接口的数据流或控制流均通过接口，从而实现接口测试的完全性。注意：对同一数据流要分别进行正确数据流与错误数据流的用例设计，对边界值的输入最好有单独的用例。集成测试还应关注接口的性能问题，根据系统的性能需求还要设计相关的接口性能测试用例。集成测试的执行主要是借助测试工具——桩程序来实现。桩程序的编写最好由他人来完成，以防止一个人对接口定义理解有偏差而使意外发生。

UAT是验收测试，User Acceptance Test：

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

主要的差别是测试执行者

ST一般是由研发部门的测试人员完成的

仍然是研发部门内部活动

UAT是由软件最终用户代表完成

一般应该是业务部门的人

理想的UAT应该是由业务人员自己按他们对业务的理解和原始需求去写测试用例并完成测试

但往往因为软件刚出炉业务人员还不会操作

所以UAT重用ST的测试用例是一个相对更可行的方案

从测试的角度讲

ST往往仍然是从技术的角度验证需求实现了

而UAT更注重从实际应用的角度看软件的可用性

无论是从测试理论还是研发流程上讲

ST都不能代替UAT

只不过现在很多时候UAT被省略了

而且也不是所有产品都能找到最终用户就做UAT

在企业级软件的测试过程中，经常会划分为三个阶段——单元测试，SIT和UAT，如果开发人员足够，通常还会在SIT之前引入代码审查机制（Code Review）来保证软件符合客户需求且流程正确。下面简单介绍一下SIT和UAT的基本情况。

SIT(System Integration Testing)系统集成测试，也叫做集成测试，是软件测试的一个术语，在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。

UAT(User Acceptance Testing)用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。

区别与联系：

SIT是集成测试

UAT是验收测试

从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。

从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试。它们两个之间的专注点是不一样的.UAT主要是从用户层面这些去考虑和着手测试,而SIT主要是系统的各个模块的集成测试.这在整个软件过程理论的基础知识中相当重要的.理论上讲SIT是由专业的测试人员去完成,UAT是由用户去做的.

如果按照规范来的话,做UAT测试的人一定是要对业务很精通的,并且是具有代表性的用户,关注的东西就是业务流程是否通畅是否符合业务的需要.以需求分析文档为重要参考,还有一些用户的操作习惯等等一系列的东西.

 

User Acceptance Testing | University IT https://uit.stanford.edu/pmo/UAT

Overview

User Acceptance Testing (UAT), which is performed on most UIT projects, sometimes called beta testing or end-user testing, is a phase of software development in which the software is tested in the "real world" by the intended audience or business representative. This type of testing is not intended to be menu-driven, but rather to be performed by business users to verify that the application will meet the needs of the end-user, with scenarios and data representative of actual usage in the field.

 

Details

• The Business Analyst should begin preparing a UAT Test Plan, with adequate time before the SIT phase is scheduled to end (SIT exit), to complete the plan, as well as allow for management review, updates, and approvals. This is usually a task in the overall project plan. Just like the SIT Test Plan, the UAT Test Plan has the following sections:
  1. Introduction
  2. Testing Scope
  3. Testing Approach
  4. Testing Deliverables
  5. High-Level Schedule
  6. Error Management & Reporting
  7. Environmental Requirements
  8. Roles & Responsibilities
  9. Risks & Assumptions
  10. UAT Exit Criteria

  Approvals of the UAT Plan should be obtained from the Project Manager, Project Sponsors, and the Business Owner or designee and recorded before proceeding with UAT testing.

• Test cases should be prepared by the Business Analyst, again allowing adequate time for review and approval by the Business Owner, and again ensuring that they are complete, approved, and uploaded to Zephyr before development exit. QA can assist the business with Zephyr and will usually agree to help with test results maintenance in Zephyr via spreadsheet updates from the Business Analyst. And again, this should be a task in the project plan.
• Business users have the option of re-running any or all SIT tests. Testing should be drive by business procedures, not by functionality. It should include end-to-end test cases and employ real-life data. The goal of UAT is to formally assess if the integrated solution satisfies the release acceptance criteria (see below).
• The Business Analyst should provide weekly updates on their page in the project Confluence (or via Box, Shared drives, etc.) that include: (1) completed test cases/scope from the reporting week; (2) overall test case execution progress and pass/fail percentages; (3) planned test cases/scope for the coming week; (4) any issues, concerns, or blockers. A high-level synopsis of UAT status should be included in the Executive Summary Report during the weeks that the project is in the UAT phase.
• As outlined in Business Requirements, for traceability, best practice is to ensure the business links all bugs logged in JIRA to both the corresponding Zephyr test case and the applicable business requirement JIRA issue. This practice can help mitigate disagreement among project team members about what is a bug and what is a change request.
• Be sure to follow the change control process (for more information, see Scope Management) closely during UAT. For many testers, this may be the first time they've seen or used the new application/system and they may have their own strong design opinions. The more changes that are requested and accepted during UAT, the more likely it is that regression bugs will crop up. Best practice is to always allow at least 1 - 2 weeks of regression testing at the end of UAT testing, before which time all baseline test cases should have been executed.
• The UAT release acceptance criteria, found in the UAT Exit Criteria Checklist template must be met (and approved by both the business and IT project sponsors) for the project to progress to the next stage of the Software Development Life Cycle, Implementation and Change Management.
• While exceptions for open P1 - P3 bugs are not permitted for UAT Exit, if the Project Sponsors agree, lower priority change requests and enhancements may be listed as exceptions on the UAT Exit Criteria document/page.
• For an example of UAT Exit Criteria from a previous project, see R12.