CPT203-Software Engineering: Software Testing软件测试
目录
1.测试
1.1广义描述
1.2 基础定义
1.3 目的
1.4测试的各个阶段 Stages of testing
2.开发测试 Development testing
2.1基础
2.2单元测试 Unit testing
2.2.1示例：气象站 weather station
2.2.2其他示例：
2.2.3 自动化单元测试 Automated Unit Testing
2.2.4选择单元测试用例 Choosing A Test Case
2.2.4.1划分策略 Partition Strategy
2.2.4.2指导方针策略 Guideline Strategy
2.3 组件测试 Component testing
2.3.1组件中的接口测试 Testing Interface in the Component
2.3.2接口错误类型
2.3.3接口测试的一般指导方针 General Guidelines for Interface Testing
2.4系统测试 System testing
2.4.1系统测试与组件测试
2.4.2 基于用例的方法 Use case-based Approach
2.4.3系统测试政策 System Testing Policies
3.版本测试 Release testing
3.1版本测试与系统测试的不同点：
3.2 基于需求的方法 Requirements Based Approach
3.3场景方法 Scenario Approach
3.4 性能测试 Testing Performance
4.用户测试 user testing
4.1用户测试的类型 Types of user testing
4.2 Alpha测试
4.3 Beta测试
4.4 验收测试
4.4.1 完整步骤
1.测试
1.1广义描述
- 从广义上讲，测试是软件验证和确认（V & V）过程中的一部分，检查正在开发的软件是否符合其规格说明，并提供付费用户期望的功能。From a general perspective, testing is part of a broader process of software verification and validation (V & V), checking that software being developed meets its specification and delivers the functionality expected by the people paying for the software.
- 这些检查过程从需求可用时开始，并持续到开发过程的所有阶段。These checking processes start as soon as requirements become available and continue through all stages of the development process
- 两种技术：
·静态：与分析静态系统表示以发现问题有关的检查（例如，检查文档和代码分析）。Static: Inspections concerned with analysis of the static system representation to discover problems (e.g., check document and code analysis)
·动态：与练习和观察产品行为有关的测试。系统使用测试数据执行，并观察其操作行为 Dynamic: Testing concerned with exercising and observing product behaviour. The system is executed with test data and its operational behaviour is observed.
1.2 基础定义
- 从实际的、以执行为中心的角度来看，测试旨在展示程序是否按照预期工作，并在使用前发现程序缺陷。Testing, from a practical, execution-focused view, is intended to show that a program does what it is intended to do and to discover program defects before it is put into use.
·当您测试软件时，您使用人工数据执行程序。When you test software, you execute a program using artificial dat
·您检查测试运行的结果，寻找错误、异常或有关程序非功能性属性的信息。You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes.
1.3 目的
- 为了向开发者和客户证明软件满足其需求，进行验证：To demonstrate to the developer and the customer that the software meets its requirements, for validation
·对于定制软件，这意味着需求文档中的每个需求至少应该有一个测试。对于通用软件产品，这意味着应该对所有系统功能进行测试，以及这些功能的所有组合，这些功能将被包含在产品发布中。For custom software, this means that there should be at least one test for every requirement in the requirements document. For generic software products, it means that there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release.
- 为了发现软件行为不正确、不期望或不符合其规格说明的情况，寻找缺陷：To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification, for finding defects
·它涉及到挖掘不期望的系统行为，例如系统崩溃、与其他系统的不必要交互、计算错误和数据损坏。It is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.
1.4测试的各个阶段 Stages of testing
- 开发测试，在开发过程中对系统进行测试以发现错误和缺陷。Development testing, where the system is tested during development to discover bugs and defects.
·系统设计人员和程序员可能会参与其中System designers and programmers are likely to be involved
- 版本测试，在系统发布给用户之前，由一个独立的测试团队对完整版本的系统进行测试。Release testing, where a separate testing team test a complete version of the system before it is released to users.
·检查系统是否满足系统利益相关者的要求Check that the system meets the requirements of system stakeholders
- 用户测试，系统的用户或潜在用户在自己的环境中测试系统。User testing, where users or potential users of a system test the system in their own environment.
·“用户”可能是内部市场团队The ‘user’ may be an internal marketing group
- 验收测试，客户正式测试。Acceptance testing where the customer formally tests
2.开发测试 Development testing
2.1基础
- 从小型到大型，开发测试测试3个方面：From small level to large level, the development Testing tests 3 things:
·单元测试，测试单个程序单元或对象类。单元测试应该专注于测试对象或方法的功能。Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
·组件测试，将几个单独的单元集成以创建复合组件。组件测试应该专注于测试这些单元通过接口之间的交互。Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing the interaction between these units via interfaces.
·系统测试，将系统中的一些或全部组件集成并对整个系统进行测试。系统测试应该专注于测试组件之间的交互。System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions.
2.2单元测试 Unit testing
- 单元测试是隔离测试单个组件单元的过程。Unit testing is the process of testing individual component unit in isolation.
- 单元可以在不同级别上定义（例如，一个函数/方法），在本课程中，它被认为是具有多个属性和方法的对象类。Units can be defined at different levels (e.g., a function / method), while, in this class, it is considered to be object classes with several attributes and methods.
- 对一个类进行完整的测试覆盖涉及Complete test coverage of a class involves
·测试与对象相关的所有操作Testing all operations associated with an object
·设置和查询所有对象属性Setting and interrogating all object attributes
·在所有可能的状态下调用对象。Exercising the object in all possible states
2.2.1示例：气象站 weather station
- 它有一个单一属性，即其标识符。只需要一个测试来检查它是否已正确设置。It has a single attribute, which is its identifier. Only need a test that checks if it has been properly set up.
- 为与对象相关联的所有方法定义测试用例，如reportWeather、reportStatus等。Define test cases for all of the methods associated with the object such as reportWeather, reportStatus, etc.
- 理想情况下，您应该隔离测试方法，但在某些情况下，需要一些测试序列（例如，重启/关闭）。Ideally, you should test methods in isolation but, in some cases, some test sequences are necessary (e.g., restart/shutdown).
- 使用状态模型，识别要测试的状态转换流程和引起这些转换的事件序列。Using a state model, identify flow of state transitions to be tested and the event sequences to cause these transitions
- 例如：
·关闭 -> 运行 -> 关闭Shutdown -> Running-> Shutdown
·配置 -> 运行 -> 测试 -> 传输 -> 运行Configuring-> Running-> Testing -> Transmitting -> Running
·运行 -> 收集 -> 运行 -> 汇总 -> 传输 -> 运行Running-> Collecting-> Running-> Summarizing -> Transmitting -> Running
2.2.2其他示例：
测试用例 1：开始 > 检查 >座位不可用 > 终止
Start > Checking > SeatUnavailable > Terminate
测试用例 2：开始 > 检查 >注册 > 注册成功> 终止
Start > Checking > Registering > Registered >Terminate
测试用例 3：开始 > 检查 >注册 > 座位不可用 >终止
Start > Checking > Registering
2.2.3 自动化单元测试 Automated Unit Testing
- 尽可能地，单元测试应该是自动化的，这样可以在没有手动干预的情况下运行和检查测试。Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention.
- 在自动化单元测试中，您使用测试自动化框架（如JUnit）来编写和运行程序测试。In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests.
- 单元测试框架提供了通用的测试类，您可以扩展这些类来创建特定的测试用例。然后它们可以运行您实现的所有测试，并通过某种图形用户界面（GUI）报告测试的成功或失败。Unit testing frameworks provide generic test classes that you extend to create specific test cases. They can then run all of the tests that you have implemented and report, often through some GUI, on the success of otherwise of the tests.
- 组成：
·一个设置部分，您在其中使用测试用例初始化系统（例如，初始化被测试的对象）A setup part, where you initialize the system with the test case (e.g., initialize the object under test)
·一个调用部分，您在其中调用要测试的对象或方法。A call part, where you call the object or method to be tested.
·一个断言部分，您在其中将调用的结果与预期结果进行比较。如果断言评估为真，测试就成功了；如果为假，则测试失败了。An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.
2.2.4选择单元测试用例 Choosing A Test Case
- 测试是昂贵且耗时的，因此选择有效的单元测试用例非常重要。在这里，有效性意味着两件事：Testing is expensive and time consuming, so it is important that you choose effective unit test cases. Effectiveness, in this case, means two things:
·测试用例应该显示，在预期使用情况下，您正在测试的组件能够按照预期工作。The test cases should show that, when used as expected, the component that you are testing does what it is supposed to do.
·如果组件中存在缺陷，这些应该通过测试用例被揭示出来。If there are defects in the component, these should be revealed by test cases.
- 这导致了两种类型的单元测试用例：
• 第一种应该反映程序的正常操作，并应该显示组件按预期工作。The first of these should reflect normal operation of a program and should show that the component works as expected.
• 另一种测试用例应该基于测试经验，即常见问题出现的地方。它应该使用异常输入来检查这些输入是否被正确处理，并且不会使组件崩溃。The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that these are properly processed and do not crash the component.
2.2.4.1划分策略 Partition Strategy
- 策略1：划分测试，您识别具有共同特征的输入组，并应该以相同的方式处理。您应该从这些组中选择测试用例。Strategy 1: Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way. You should choose tests from within each of these groups.
- 这些组中的每一个都是等价划分或域，程序对每个组成员的行为方式是等价的。Each of these groups is an equivalence partition or domain where the program behaves in an equivalent way for each group member
- 示例：程序接受4到10个输入，这些输入是五位数的整数，范围从10,000到99,999。
·选择测试用例的一个好经验法则是在划分的边界上选择测试用例，以及在划分的中点附近的案例。A good rule of thumb for test case selection is to choose test cases on the boundaries of the partitions, plus cases close to the midpoint of the partition.
·您可以通过使用程序规范或用户文档以及经验来识别划分，预测可能检测到错误的输入值类别。You identify partitions by using the program specification or user documentation and from experience where you predict the classes of input value that are likely to detect errors.
2.2.4.2指导方针策略 Guideline Strategy
- 策略2：基于指导方针的测试，您使用测试指导方针来选择测试用例。这些指导方针反映了程序员在开发组件时经常犯的错误类型的以往经验。Strategy 2: Guideline-based testing, where you use testing guidelines to choose test cases. These guidelines reflect previous experience of the kinds of errors that programmers often make when developing component.
- 测试具有单一值的序列/数组/列表的软件。Test software with sequences/arrays/list which have only a single value.
·程序员自然认为序列由多个值组成，有时他们会在程序中嵌入这种假设。因此，如果遇到单值序列，程序可能无法正常工作。Programmers naturally think of sequences as made up of several values and sometimes they embed this assumption in their programs. Consequently, if presented with a single-value sequence, a program may not work properly
- 在不同的测试中使用不同大小的序列/数组/列表。Use sequences/arrays/list of different sizes in different tests.
·例如：[1]，[1,2]，[1,2,3] 等等。
- 派生测试，以便访问序列的第一个、中间和最后一个元素。Derive tests so that the first, middle and last elements of the sequence are accessed.
·例如：划分策略。
- 测试零长度的序列/数组/列表。Test with sequences/arrays/list of zero length
·例如：[]。
2.3 组件测试 Component testing
- 软件组件通常是由多个相互作用的单元组成的复合组件。Software components are often composite components that are made up of several interacting units.
- 组件的功能基于这些单元通过接口的交互。The functionality of the component is based on the these units interacting through interface.
- 因此，测试复合组件应该集中在证明组件接口的行为符合其规格说明上。Testing composite components should therefore focus on showing that the component interface behaves according to its specification.
·您可以假设组件内各个对象的单元测试已经完成。You can assume that unit tests on the individual objects within the component have been completed.
2.3.1组件中的接口测试 Testing Interface in the Component
- 单元A、B和C已经被集成，创建了一个更大的组件或子系统。Unit A, B, and C have been integrated to create a larger component or subsystem.
- 测试用例不是应用于单个单元，而是应用于通过组合这些组件创建的复合组件的接口。The test cases are not applied to the individual units but rather to the interface of the composite component created by combining these components.
- 注意：复合组件中的接口错误可能无法通过测试单个对象来检测，因为这些错误是由于组件中对象之间的交互导致的。Note: Interface errors in the composite component may not be detectable by testing the individual objects because these errors result from interactions between the objects in the component
2.3.2接口错误类型
- 接口误用 Interface misuse
·调用单元在调用另一个单元时，在其接口的使用上犯了错误。例如，参数顺序错误。A calling unit calls another unit and makes an error in its use of its interface. e.g. parameters in the wrong order.
- 接口误解 Interface misunderstanding
·调用单元对被调用单元的行为嵌入了错误的假设。A calling unit embeds assumptions about the behaviour of the called unit which are incorrect.
- 时序错误 Timing errors
·被调用单元和调用单元以不同的速度运行，访问了过时的信息。The called and the calling unit operate at different speeds and out- of-date information is accessed
2.3.3接口测试的一般指导方针 General Guidelines for Interface Testing
- 设计测试用例，使得调用过程的参数处于其范围的极端值。Design tests so that parameters to a called procedure are at the extreme ends of their ranges
- 总是用空指针测试指针参数。Always test pointer parameters with null pointers
·例如：`processCustomerData(some para)` -> `processCustomerData(NULL)`
- 设计测试用例，使组件失败。Design tests which cause the component to fail
·例如：`parseDate(String dateStr)` 格式为 "YYYY-MM-DD" ->
`parseDate("2024-31-02")` 或 `parseDate("02-2024-31")`
- 使用压力测试 Use Stress stress testing
·测试系统如何处理高流量和数据负载。Test how the system handles high traffic and data load
- 在多个组件通过共享内存交互的地方，设计测试用例，改变这些组件被激活的顺序。Where several components interact through shared memory, design tests that vary the order in which these components are activated
·在多线程应用程序中，如果T1、T2、T3线程访问和修改共享变量，编写测试执行T1、T3、T2或类似的操作。In a multi-threaded application where T1, T2, T3 threads access and modify shared variables, write tests performing T1, T3, T2 or so
2.4系统测试 System testing
- 在开发过程中进行系统测试涉及将组件集成以创建系统的一个版本，然后测试该集成系统。System testing during development involves integrating components to create a version of the system and then testing the integrated system.
- 系统测试的重点在于测试组件之间的交互。The focus in system testing is testing the interactions between components.
- 系统测试检查组件是否兼容，是否正确交互，并在正确的时间传递正确的数据。System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces.
2.4.1系统测试与组件测试
- 系统测试显然与组件测试重叠，但有两个重要区别System testing obviously overlaps with component testing but there are two important differences
·在系统测试期间，可重用的组件、独立开发的组件和现成的系统可能会与新开发的组件集成在一起。然后对整个系统进行测试。During system testing, reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested.
·不同团队成员或子团队开发的组件可能在这个阶段集成。系统测试是一个集体过程，而不是个人过程。Components developed by different team members or subteams may be integrated at this stage. System testing is a collective rather than an individual process.
>在一些公司中，系统测试可能涉及一个独立的测试团队，设计师和程序员不参与其中。In some companies, system testing may involve a separate testing team with no involvement from designers and programmers.
2.4.2 基于用例的方法 Use case-based Approach
- 为识别系统交互而开发的用例可以用作系统测试的基础。The use-cases developed to identify system interactions can be used as a basis for system testing.
- 每个用例通常涉及多个系统组件，因此测试用例会迫使这些交互发生。Each use case usually involves several system components so testing the use case forces these interactions to occur.
- 您可以使用序列图来识别将被测试的操作，并帮助设计执行测试用例。You can use the sequence diagrams to identify operations that will be tested and to help design the test cases to execute
2.4.3系统测试政策 System Testing Policies
- 彻底的系统测试是不可能的，因此可以制定测试政策，以定义所需的系统测试覆盖范围Exhaustive system testing is impossible so testing policies, which define the required system test coverage, may be developed.。
- 测试政策的示例：
·所有通过菜单访问的系统功能都应进行测试。
> 例如，在“文件”菜单下，有“打开”、“保存”、“退出”按钮，确保所有这些与用户交互的按钮都能正常工作。
·通过同一菜单访问的功能组合（例如文本格式化）必须进行测试。
> 例如，选择文本并同时应用多个格式选项，例如，加粗 + 斜体 = abc，以确保它们可以无问题地组合使用。
·在提供用户输入的情况下，所有功能必须使用正确和错误的输入进行测试。
> 例如，用户名 + 密码。
3.版本测试 Release testing
- 版本测试是对特定版本的系统进行测试的过程，该版本旨在供开发团队以外的用户使用。Release testing is the process of testing a particular release of a system that is intended for use outside of the development team.
- 版本测试过程的主要目标是说服系统的供应商，该系统足够好，可以投入使用。The primary goal of the release testing process is to convince the supplier of the system that it is good enough for use.
·因此，版本测试必须证明系统能够提供其规定的功能、性能和可靠性，并且在正常使用过程中不会出现故障。Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use.
3.1版本测试与系统测试的不同点：
- 应该由一个未曾参与系统开发的独立团队负责版本测试。A separate team that has not been involved in the system development, should be responsible for release testing.
- 开发团队进行的系统测试应该专注于发现系统中的缺陷。版本测试的目标是检查系统是否满足其要求，并且是否足够好，可以供外部使用。System testing by the development team should focus on discovering bugs in the system. The objective of release testing is to check that the system meets its requirements and is good enough for external use .
3.2 基于需求的方法 Requirements Based Approach
- 基于需求的方法涉及检查每个需求并为其开发一个或多个测试。Requirements-based approach involves examining each requirement and developing a test or tests for it.
- 示例：
MHC-PMS需求：
·如果已知患者对某种药物过敏，则开处方该药物将导致系统用户收到警告消息。
·如果开处方者选择忽略过敏警告，他们必须提供忽略此警告的原因。
设置测试：
·建立一个没有已知过敏史的患者记录。
·建立一个有已知过敏史的患者记录。
·建立一个对一种或多种药物过敏的患者记录。
·开处方两种患者过敏的药物。
·开处方一种会发出警告的药物，并覆盖该警告。
3.3场景方法 Scenario Approach
- 场景方法设计了典型的使用场景，并利用这些场景为系统开发测试用例。Scenario approach devises typical scenarios of use and use these to develop test cases for the system.
- 场景是一个描述系统可能被使用的一种方式的故事。A scenario is a story that describes one way in which the system might be used.
- 场景应该是现实的，真实的系统用户应该能够与之相关联。Scenarios should be realistic and real system users should be able to relate to them.
- 示例：
3.4 性能测试 Testing Performance
- 版本测试的一部分可能涉及测试系统的涌现属性，如性能和可靠性。Part of release testing may involve testing the emergent properties of a system, such as performance and reliability.
- 性能测试通常涉及规划一系列测试，其中负载稳步增加，直到系统性能变得不可接受。Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable.
- 进行性能测试：To conduct performance test
·操作配置文件：一组反映系统将处理的实际工作混合的测试An operational profile: a set of tests that reflect the actual mix of work that will be handled by the system
·构建：如果系统中90%的交易是A类型；5%是B类型；其余的是C、D和E类型If 90% of the transactions in a system are of type A; 5% of type B; and the remainder of types C, D, and E
→ 设计操作配置文件，使得绝大多数测试是A类型。design the operational profile so that the vast majority of tests are of type A
- 压力测试 Stress testing
·通过提出超出软件设计限制的需求来对系统施加压力。Stressing the system by making demands that are outside the design limits of the software.
·例如：测试一个设计为每秒处理高达300笔交易的交易处理系统。
→ 用少于300笔交易进行测试
→ 增加系统负载直到它失败
·重要性
> 它测试了系统的失败行为。It tests the failure behavior of the system.
> 它对系统施加压力，可能会导致在正常情况下不会被发现的缺陷暴露出来。It stresses the system and may cause defects to come to light that would not normally be discovered.
4.用户测试 user testing
- 用户或客户测试是测试过程中的一个阶段，用户或客户在此阶段提供输入和对系统测试的建议。User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.
- 即使已经进行了全面的系统测试和版本测试，用户测试也是必不可少的。User testing is essential, even when comprehensive system and release testing have been carried out.
·这是因为用户工作环境的影响对系统的可靠性、性能、可用性和健壮性有重大影响。这些影响无法在测试环境中复制。The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.
4.1用户测试的类型 Types of user testing
- Alpha测试 Alpha testing
·软件的用户与开发团队合作，在开发者的场所测试软件。Users of the software work with the development team to test the software at the developer’s site.
- Beta测试 Beta testing
·软件的一个版本提供给用户，让他们进行实验并向系统开发者提出他们发现的问题。A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
- 验收测试 Acceptance testing
·客户测试一个系统，以决定它是否准备好被系统开发者接受，并部署在客户环境中。主要用于定制系统。Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems
4.2 Alpha测试
- 在 alpha 测试中，用户和开发者共同测试正在开发的系统，因为用户能够识别出开发测试团队不容易察觉的问题和问题。In alpha testing, users and developers work together to test a system as it is being developed, becasue users can identify problems and issues that are not readily apparent to the development testing team
- 测试者可能愿意参与 alpha 测试过程，因为这让他们能够提前了解他们可以利用的新系统特性。Testers may be willing to get involved in the alpha testing process because this gives them early information about new system features that they can exploit.
- 好处：
·早期发现问题：真实用户及早识别出微妙和特定于上下文的问题，防止了发布后昂贵的修复。 Early Detection of Issues: Problems that are subtle and context-specific are identified early by real users, preventing costly fixes post-launch
·早期采用者参与：参与 alpha 测试的用户对产品感到拥有感和参与感，使他们有可能在市场上支持该产品。Early Adopter Engagement: Users involved in the alpha testing feel a sense of ownership and engagement with the product, making them likely support the product when it is on the market
4.3 Beta测试
- Beta测试是在软件系统的早期版本，有时是未完成的版本，提供给客户和用户进行评估时进行的。Beta测试对于发现软件与其使用环境中的特性之间的交互问题至关重要。它也是一种市场营销形式。Beta testing takes place when an early, sometimes unfinished, release of a software system is made available to customers and users for evaluation. Beta testing is essential to discover interaction problems between the software and features of the environment where it is used. Also a form of markerting.
- Beta测试者可能是一群被选中的客户，他们是系统的早期采用者。或者，软件可能被公开提供给任何感兴趣的人使用。Beta testers may be a selected group of customers who are early adopters of the system. Alternatively, the software may be made publicly available for use by anyone who is interested in it.
- 好处
·可用性反馈：它允许开发者看到真实用户如何与软件互动，这可以突出以前可能不明显的可用性问题。Usability Feedback: It allows the developers to see how real users interact with the software, which can highlight usability issues that may not have been apparent before.
·性能问题：它有助于识别性能瓶颈和应用程序可能无法很好地扩展的领域。Performance Issues: It helps identify performance bottlenecks and areas where the application may not scale well
·市场洞察：从Beta用户那里收集反馈有助于确保产品满足其目标市场的期望。Marketing Insight: Gathering feedback from beta users helps ensure the product meets the expectations of its target market
4.4 验收测试
- 验收测试是软件开发生命周期中的关键阶段，专注于评估系统是否满足业务或最终用户设定的约定要求和规格。Acceptance testing is a critical phase in the software development lifecycle, focusing on evaluating whether the system meets the agreed-upon requirements and specifications set by the business or the end-users
- 它验证软件系统是否满足所有业务和用户需求，检查是否符合与利益相关者约定的法规、标准和其他标准，并确保系统具备并准备好用于运营使用，并且令最终用户满意。It verifies that the software system meets all business and user requirements, checks compliance with regulations, standards, and other criteria agreed upon with the stakeholders, and ensures that the system is capable and ready for operational use and is satisfactory to the end-users.
4.4.1 完整步骤
- 步骤1. 定义验收标准：理想情况下，这应该在系统合同签订之前的过程早期进行。实际上，详细的要求可能不可用，而且在开发过程中可能会有重大的需求变更。Define acceptance criteria: Ideally, it should take place early in the process before the contract for the system is signed. In practice, detailed requirements may not be available and there may be significant requirements change during the development process
- 步骤2. 计划验收测试：它涉及决定验收测试的资源、时间和预算，并建立测试时间表。讨论内容包括（1）所需覆盖的需求范围；（2）系统特性测试的顺序；以及（3）测试过程中的风险以及如何减轻这些风险。Plan acceptance testing: It involves deciding on the resources, time, and budget for acceptance testing and establishing a testing schedule. Discussion about (1) the required coverage of the requirements; (2) the order in which system features are tested; and (3) risks to the testing process and how to mitigate them.
- 步骤3. 推导验收测试：一旦确定了验收标准，就需要设计测试来检查系统是否可接受。验收测试应该旨在测试系统的功能和非功能特性（例如，性能）。Derive acceptance tests: Once acceptance criteria have been established, tests have to be designed to check whether or not a system is acceptable. Acceptance tests should aim to test both the functional and non-functional characteristics (e.g., performance) of the system
- 步骤4. 执行验收测试：在系统上执行约定的验收测试。理想情况下，应在系统将被使用的实际环境中进行。实际上，可能需要设置一个用户测试环境来运行这些测试。Run acceptance tests: The agreed acceptance tests are executed on the system. Ideally, take place in the actual environment where the system will be used. Practically, a user testing environment may have to be set up to run these tests.
- 步骤5. 商议测试结果：定义的所有验收测试都通过且系统没有问题是非常不可能的。开发者和客户必须协商决定系统是否足够好以投入使用。他们还必须就开发者对已识别问题的反应达成一致。Negotiate test results: It is very unlikely that all of the defined acceptance tests will pass and that there will be no problems with the system. The developer and the customer have to negotiate to decide if the system is good enough to be put into use. They must also agree on the developer’s response to identified problems.
- 步骤6. 拒绝/接受系统：这个阶段涉及开发者和客户之间的会议，以决定是否应该接受系统。如果系统不够好，无法使用，那么就需要进一步开发来修复已识别的问题。一旦完成，重复验收测试阶段。Reject/accept system: This stage involves a meeting between the developers and the customer to decide on whether or not the system should be accepted. If the system is not good enough for use, then further development is required to fix the identified problems. Once complete, the acceptance testing phase is repeated.