가이드라인:
|
시나리오 1 | 기본 플로우 | |||
---|---|---|---|---|
시나리오 2 | 기본 플로우 | 대체 플로우 1 | ||
시나리오 3 | 기본 플로우 | 대체 플로우 1 | 대체 플로우 2 | |
시나리오 4 | 기본 플로우 | 대체 플로우 3 | ||
시나리오 5 | 기본 플로우 | 대체 플로우 3 | 대체 플로우 1 | |
시나리오 6 | 기본 플로우 | 대체 플로우 3 | 대체 플로우 1 | 대체 플로우 2 |
시나리오 7 | 기본 플로우 | 대체 플로우 4 | ||
시나리오 8 | 기본 플로우 | 대체 플로우 3 | 대체 플로우 4 |
주: 단순성을 위해 시나리오 5, 6 및 8에서만 대체 플로우 3으로 표시되는 루프의 단일 실행을 나타냅니다.
각 시나리오의 테스트 케이스 도출은 특정 유스 케이스 시나리오를 실행할 수 있는 특정 조건을 식별하여 수행됩니다.
예를 들어, 위의 다이어그램에서 나타내는 유스 케이스가 대체 플로우 3에 대한 다음 사항을 설명한다고 가정하십시오.
"위의 2단계 "인출 금액 입력"에서 입력한 금액이 현재 예금 잔고보다 큰 경우 이러한 이벤트 플로우가 발생합니다. 시스템에서 경고 메시지를 표시한 다음 은행 고객이 인출 금액을 새로 입력할 수 있는 위의 2단계 "인출 금액 입력"의 기본 플로우와 재결합합니다."
이러한 정보를 사용하여 대체 플로우 3 실행에 필요한 테스트 케이스를 식별할 수 있습니다.
테스트 케이스 ID | 시나리오 | 조건 | 예상 결과 |
---|---|---|---|
TC x | 시나리오 4 | 2단계 - 인출 금액 > 예금 잔고 | 2단계의 기본 플로우와 재결합 |
TC y | 시나리오 4 | 2단계 - 인출 금액 < 예금 잔고 | 대체 플로우 3을 실행하지 않고 기본 플로우 실행 |
TC z | 시나리오 4 | 2단계 - 인출 금액 = 예금 잔고 | 대체 플로우 3을 실행하지 않고 기본 플로우 실행 |
주: 위에서 나타내는 테스트 케이스는 제공된 정보가 전혀 없기 때문에 매우 간단합니다. 이처럼 간단한 테스트 케이스는 거의 없습니다.
유스 케이스에서 테스트 케이스를 실행하는 실제적인 예는 다음과 같습니다.
예:
ATM 시스템의 액터 및 유스 케이스
다음 표에는 위에 있는 다이어그램의 현금 인출 유스 케이스에 대한 기본 플로우 및 일부 대체 플로우가 포함되어 있습니다.
기본 플로우 | 이 유스 케이스는 준비 상태의 ATM으로 시작합니다.
유스 케이스는 준비 상태의 ATM으로 종료됩니다. |
---|---|
대체 플로우 1 - 유효하지 않은 카드 | 기본 플로우 2단계 - 은행 카드 확인. 유효하지 않은 카드인 경우 해당 메시지와 함께 카드를 배출합니다. |
대체 플로우 2 - ATM 현금 부족 | 기본 플로우 5단계 - ATM 옵션. ATM에 현금이 부족한 경우 "현금 인출" 옵션을 사용할 수 없습니다. |
대체 플로우 3 - ATM 결제 자금 부족 | 기본 플로우 6단계 - 총계 입력. ATM의 결제 자금 잔고가 요청된 금액을 지급하기에 부족한 경우 해당 메시지를 표시하고 6단계 - 총계 입력의 기본 플로우와 재결합합니다. |
대체 플로우 4 - 올바르지 않은 PIN | 기본 플로우 4단계 - 계정 및 PIN 확인. 올바른 PIN을
입력할 수 있도록 고객에게 3회 시도를 허용합니다. 잘못된 PIN이 입력되면 ATM은 해당 메시지를 표시하고, 시도 횟수가 남아 있을 경우에는 이 플로우가 3단계 - PIN 입력의 기본 플로우와 재결합합니다. 최종 시도에서 입력한 PIN이 올바르지 않으면 ATM이 준비 상태로 리턴되어 현재 유스 케이스가 종료됩니다. |
대체 플로우 5 - 계정 없음 | 기본 플로우 4단계 - 계정 및 PIN 확인. 뱅킹 시스템이 찾을 수 없는 계정이거나 인출을 허용하는 계정이 아님을 나타내는 코드를 리턴하는 경우 ATM은 해당 메시지를 표시하고 9단계 - 카드 리턴의 기본 플로우와 재결합합니다. |
대체 플로우 6 - 예금 잔고 부족 | 기본 플로우 7단계 - 권한 부여. 뱅킹 시스템은 예금 잔고가 기본 플로우 6단계 - 총계 입력에서 입력한 금액보다 적다고 나타내는 코드를 리턴합니다. ATM은 해당 메시지를 표시하고 6단계 - 총계 입력의 기본 플로우와 재결합합니다. |
대체 플로우 7 - 일별 최대 인출 금액 도달 | 기본 플로우 6단계 - 권한 부여. 뱅킹 시스템은 현재 인출 요청을 포함하여 24시간 허용되는 최대 금액을 초과함을 나타내는 코드를 리턴합니다. ATM은 해당 메시지를 표시하고 6단계 - 총계 입력의 기본 플로우와 재결합합니다. |
대체 플로우 x - 로그 오류 | 기본 플로우 10단계 - 영수증. 로그를 갱신할 수 없는 경우 ATM은 모든 기능을 일시 중단하는 "보안 모드"로 들어갑니다. 적절한 알람을 뱅킹 시스템에 전송하여 ATM이 일시 중단 상태에 있음을 알려줍니다. |
대체 플로우 y - 종료 | 고객은 언제든지 트랜잭션 종료를 결정할 수 있습니다. 트랜잭션이 중지되고 카드가 배출됩니다. |
대체 플로우 z - "차단" | ATM에는 전원 장치, 다양한 도어와 게이트에 영향을 주는 가압기, 보안 감지기와 같이 여러 기능을 모니터하는 다양한 센서가 포함되어 있습니다. 센서가 활성화될 때마다 알람 신호는 경찰서로 송신되며, ATM은 적절한 재시작/재초기화 조치를 취할 때까지 모든 기능을 일시 중단하는 "보안 모드"로 들어갑니다. |
반복 계획에 따라 첫 번째 반복에서 현금 인출 유스 케이스가 제대로 구현되었는지
확인해야 합니다. 전체 유스 케이스가 구현되지 않고, 다음 플로우만 구현되었습니다.
- 기본 플로우 - 미리 설정된 금액($10, $20, $50, $100) 인출
- 대체 플로우 2- ATM 현금 부족
- 대체 플로우 3 - ATM 결제 자금 부족
- 대체 플로우 4 - 올바르지 않은 PIN
- 대체 플로우 5 - 계정 없음/올바르지 않은 계정 유형
- 대체 플로우 6 - 예금 잔고 부족
현재 유스 케이스에서 도출할 수 있는 시나리오는 다음과 같습니다.
시나리오 1 - 성공적인 현금 인출 | 기본 플로우 | |
---|---|---|
시나리오 2- ATM 현금 부족 | 기본 플로우 | 대체 플로우 2 |
시나리오 3 - ATM 결제 자금 부족 | 기본 플로우 | 대체 플로우 3 |
시나리오 4 - 올바르지 않은 PIN(잔여 시도 횟수 있음) | 기본 플로우 | 대체 플로우 4 |
시나리오 5 - 올바르지 않은 PIN(잔여 시도 횟수 없음) | 기본 플로우 | 대체 플로우 4 |
시나리오 6 - 계정 없음/올바르지 않은 계정 유형 | 기본 플로우 | 대체 플로우 5 |
시나리오 7 - 예금 잔고 부족 | 기본 플로우 | 대체 플로우 6 |
주: 단순성을 위해 위의 표에는 대체 플로우 3, 6의 루프(시나리오 3, 7) 및 루프 조합이 포함되지 않습니다.
이러한 7개 시나리오 각각의 경우 테스트 케이스가 식별되어야 합니다. 테스트 케이스는 매트릭스 또는 의사결정표를 사용하여 식별 및 관리할 수 있습니다. 공통 형식은 다음과 같습니다. 여기서 각 행은 개별 테스트 케이스를 나타내고 열은 테스트 케이스 정보를 식별합니다. 이 예제의 각 테스트 케이스에는 테스트 케이스 ID, 조건(또는 설명), 테스트 케이스에 참여하는 모든 데이터 요소(데이터베이스에 이미 있거나 입력되어 있음) 및 예상 결과 등이 있습니다.
매트릭스 전개를 시작하려면 유스 케이스 시나리오를 실행해야 할 데이터 요소를 식별하십시오. 그런 다음 각 시나리오에 대해 적어도 해당 시나리오의 실행에 적합한 조건을 포함하는 테스트 케이스를 식별하십시오. 예를 들어, 다음 매트릭스에서 V(유효)는 실행할 기본 플로우에 대해 해당 조건이 유효해야 한다는 것을 표시하는 데 사용되며, I(무효)는 원하는 대체 플로우를 호출할 조건을 표시하는 데 사용됩니다. 다음 표에서 "n/a"는 테스트 케이스에 해당 조건을 적용할 수 없음을 표시합니다.
TC ID# | 시나리오/조건 | PIN
|
계정 번호
|
입력 금액
(또는 선택)
|
계정 금액
|
ATM 금액
|
예상 결과 |
---|---|---|---|---|---|---|---|
CW1 | 시나리오 1 - 성공적인 현금 인출 | V | V | V | V | V | 현금 인출 성공 |
CW2 | 시나리오 2 - ATM 현금 부족 | V | V | V | V | I | 현금 인출 옵션 사용 불가능, 유스 케이스 종료 |
CW3 | 시나리오 3 - ATM 결제 자금 부족 | V | V | V | V | I | 경고 메시지 표시, 기본 플로우 6단계 - 총계 입력으로 리턴 |
CW4 | 시나리오 4 - 올바르지 않은 PIN(> 1회 시도 횟수 있음) | I
|
V | n/a | V | V | 경고 메시지 표시, 기본 플로우 4단계로 리턴, PIN 입력 |
CW5 | 시나리오 4 - 올바르지 않은 PIN(= 1회 시도 횟수 있음) | I
|
V | n/a | V | V | 경고 메시지 표시, 기본 플로우 4단계로 리턴, PIN 입력 |
CW6 | 시나리오 4 - 올바르지 않은 PIN(= 0회 시도 횟수 있음) | I
|
V | n/a | V | V | 경고 메시지 표시, 카드 보류, 유스 케이스 종료 |
위의 매트릭스에서는 6개 테스트 케이스가 4개의 시나리오를 실행합니다. 기본 플로우의 경우 위의 테스트 케이스 CW1(포지티브 테스트 케이스로 알려져 있음)은 유스 케이스를 통한 기본 플로우 경로를 이탈 없이 실행합니다. 조건이 올바른 경우에만 기본 플로우를 수행할 수 있도록 전체적인 기본 플로우 테스트에는 네거티브 테스트 케이스가 포함되어야 합니다. 테스트 케이스 CW2 - 6은 이러한 네거티브 테스트 케이스를 나타냅니다(음영 표시 셀은 대체 플로우 실행에 필요한 조건을 나타냄). CW2 - 6은 기본 플로우의 경우에는 네거티브 테스트 케이스이지만, 대체 플로우 2 - 4의 경우에는 포지티브 테스트 케이스가 됩니다. 이러한 대체 플로우 각각에는 하나 이상의 네거티브 테스트 케이스가 있습니다(CW1 - 기본 플로우).
시나리오 4는 충분하지는 않지만 시나리오별로 포지티브 및 네거티브 테스트 케이스가 하나씩 있는 예입니다. 시나리오 4 - 잘못된 PIN을 완전히 테스트하려면 3개 이상의 포지티브 테스트 케이스(시나리오 4 호출용)가 필요합니다.
위의 매트릭스에서는 조건에 대한 실제 값(데이터)을 입력하지 않았습니다. 이러한 방식으로 테스트 케이스 매트릭스를 작성하면 테스트할 조건을 쉽게 확인할 수 있습니다. 또한 V와 I(또는 여기서의 음영 표시 셀)만 조사해야 하므로, 충분한 테스트 케이스가 식별되었는지를 매우 쉽게 판별할 수 있습니다. 위의 표를 조사해 보면 음영 표시 셀이 없는 여러 조건이 있기 때문에 테스트 케이스(예: 시나리오 6 - 계정 없음/올바르지 않은 계정 유형 및 시나리오 7 - 예금 잔고 부족)가 누락되어 있습니다.
충분한 테스트 케이스를 식별한 경우에는 이러한 테스트 케이스를 검토하고 유효성을 확인하여 정확성과 적합성을 보증하고 중복, 동등 테스트 케이스 또는 기타 불필요한 테스트 케이스를 제거해야 합니다. 자세한 사항은 개념: 테스트-아이디어 목록을 참조하십시오. 또한 추가 사항은 테스트 케이스의 테스트 데이터 정의 섹션을 참조하십시오.
TC ID# | 시나리오/조건 | PIN
|
계정 번호
|
입력 금액
(또는 선택)
|
계정 금액
|
ATM 금액
|
예상 결과 |
---|---|---|---|---|---|---|---|
CW1 | 시나리오 1 - 성공적인 현금 인출 | 4987 | 809 - 498 | 50.00 | 500.00 | 2,000 | 현금 인출 성공, 450.00으로 예금 잔고 갱신 |
CW2 | 시나리오 2 - ATM 현금 부족 | 4987 | 809 - 498 | 100.00 | 500.00 | 0.00 | 현금 인출 옵션 사용 불가능, 유스 케이스 종료 |
CW3 | 시나리오 3 - ATM 결제 자금 부족 | 4987 | 809 - 498 | 100.00 | 500.00 | 70.00 | 경고 메시지 표시, 기본 플로우 6단계 - 총계 입력으로 리턴 |
CW4 | 시나리오 4 - 올바르지 않은 PIN(> 1회 시도 횟수 있음) | 4978
|
809 - 498 | n/a | 500.00 | 2,000 | 경고 메시지 표시, 기본 플로우 4단계로 리턴, PIN 입력 |
CW5 | 시나리오 4 - 올바르지 않은 PIN(= 1회 시도 횟수 있음) | 4978
|
809 - 498 | n/a | 500.00 | 2,000 | 경고 메시지 표시, 기본 플로우 4단계로 리턴, PIN 입력 |
CW6 | 시나리오 4 - 올바르지 않은 PIN(= 0회 시도 횟수 있음) | 4978
|
809 - 498 | n/a | 500.00 | 2,000 | 경고 메시지 표시, 카드 보류, 유스 케이스 종료 |
위의 테스트 케이스에는 현재 반복의 현금 인출 유스 케이스를 확인하는 데 필요한 일부 테스트 케이스만 있습니다. 필요한 기타 테스트 케이스는 다음과 같습니다.
이후의 반복에서 다른 플로우를 구현할 경우에 필요한 테스트 케이스는 다음과 같습니다.
기능 테스트 케이스를 식별할 경우 다음 사항을 확인하십시오.
추가 가이드는 테스트 케이스의 테스트 데이터 정의 섹션을 참조하십시오.
테스트 대상에 대한 모든 요구사항이 반드시 기능 요구사항 결과물(예: 유스 케이스 스펙)에 반영되는 것은 아닙니다. 비기능 요구사항(예: 성능, 보안 및 액세스, 형상 요구사항)에서는 테스트 대상의 추가 작동 또는 특성을 지정하며, 종종 기능 요구사항과는 별도로 설명됩니다. 추가 스펙은 이러한 추가 요구사항의 테스트 케이스를 도출하는 기본 소스 중 하나입니다.
이러한 추가 테스트 케이스를 도출하기 위한 가이드라인은 다음과 같습니다.
성능 테스트 케이스의 기본 입력은 비기능 요구사항을 포함하는 추가 스펙입니다. 결과물: 추가 스펙을 참조하십시오. 성능 테스트의 테스트 케이스를 도출할 경우 다음 가이드라인을 사용하십시오.
기능 테스트의 테스트 케이스와 마찬가지로 대개 사용법 시나리오 또는 요구사항별 테스트 케이스가 하나 이상 있습니다. 여러 개의 테스트 케이스를 정의하는 것은 일반적입니다. 예를 들면, 한 테스트 케이스는 성능 임계값 이하(평균 트랜잭션 처리율)이고 다른 테스트 케이스는 임계값(상위 트랜잭션 처리율)에 있으며 세 번째 테스트 케이스는 임계값 이상(최대 트랜잭션 처리율)입니다.
위의 성능 기준 이외에도 다음을 포함한 응답 시간에 영향을 주는 지정 조건을 식별하도록 하십시오.
일반적으로 기능 테스트에 사용된 것과 유사한 테이블 매트릭스에서 성능 테스트의 테스트 케이스를 캡처합니다.
추가 사항은 테스트 케이스의 테스트 데이터 정의 섹션을 참조하십시오.
여러 개의 성능 테스트 유형에 대한 몇 가지 예는 다음과 같습니다.
로드 테스트의 경우:
TC ID# | 워크로드 | 조건 | 예상 결과 |
---|---|---|---|
PCW1 |
1 (하나의 ATM) |
인출 트랜잭션 완료 |
< 20초마다 트랜잭션 완료(비액터 종속 타이밍) 발생 |
PCW2 |
2 (1,000개의 동시 ATM) |
인출 트랜잭션 완료 |
< 30초마다 트랜잭션 완료(비액터 종속 타이밍) 발생 |
PCW3 |
3 (10,000개의 동시 ATM) |
인출 트랜잭션 완료 |
< 50초마다 트랜잭션 완료(비액터 종속 타이밍) 발생 |
스트레스 테스트의 경우:
TC ID# | 워크로드 | 조건 | 예상 결과 |
---|---|---|---|
SCW1 |
2 (1,000개의 동시 ATM) |
데이터베이스 잠금 - 동일 계정을 요청하는 두 개의 ATM |
ATM 요청 대기열 처리 |
SCW2 |
2 (1,000개의 동시 ATM) |
뱅킹 시스템 통신 사용 불가능 |
트랜잭션 대기열 처리 또는 시간 종료 |
SCW3 |
2 (1,000개의 동시 ATM) |
트랜잭션에서 뱅킹 시스템 통신 종료 |
경고 메시지 표시 |
액터와 유스 케이스는 특정 액터에 값을 산출하기 위해 시스템에서 수행하는 조치와 시스템의 외부 사용자 사이의 상호 작용을 설명합니다. 복잡한 시스템에는 많은 액터가 포함되어 있으며, 유스 케이스를 실행하도록 지정된 해당 액터만이 이를 수행할 수 있도록 테스트 케이스를 전개해야 합니다. 특히 이러한 사실은 액터 유형에 기반한 이벤트의 유스 케이스 플로우에 차이가 있는 경우에 적용됩니다.
예를 들어, ATM 유스 케이스에서 경쟁 은행의 은행 카드 및 계정을 사용하거나 비가맹 은행 카드를 사용하려고 하는 "은행 고객"과 대비하여 ATM을 소유한 은행의 카드와 계정인 경우 "은행 고객" 액터에 대해 서로 다른 유스 케이스 이벤트 플로우를 실행할 수 있습니다.
기능 테스트 케이스에 대해 위에 나열된 것과 같은 가이드라인을 수행하십시오.
추가 가이드는 테스트 케이스의 테스트 데이터 정의 섹션을 참조하십시오.
보안 및 액세스의 테스트 케이스 예제:
TC ID# | 조건 | 카드
(V: 유효 카드 표시) |
카드 판독기
(V: 제대로 작동 중인 판독기 표시) |
은행 네트워크 | 예상 결과 |
---|---|---|---|---|---|
ACW1 | 은행 네트워크 내부 | V | V | V | 모든 유스 케이스 사용 가능 |
ACW2 | 은행 네트워크 외부 | V | V | I | 현금 인출 유스 케이스 전용 |
ACW3 | 카드 판독 불가능 | I | V | V | 경고 메시지, 카드 배출 |
ACW4 | 도난당한 카드로 보고 | I | V | V | 경고 메시지, 카드 보유 |
ACW5 | 만기된 카드 | I | V | V | 경고 메시지, 카드 보유 |
일반적인 분산 시스템에서는 지원될 하드웨어와 소프트웨어의 여러 조합이 허용될 수 있습니다. 테스트 대상이 여러 형상(예: 다양한 운영 체제, 브라우저 또는 CPU 속도)에서 작동하거나 적절히 수행되는지 확인할 수 있도록 테스트를 수행해야 합니다. 또한 테스트에서는 컴포넌트의 조합도 다루어 여러 컴포넌트 사이의 상호 작용에서 발생하는 결함을 제거해야 합니다. 예를 들어, 한 어플리케이션에서 설치한 DLL 버전이 다른 어플리케이션에서 예상하는 동일한 DLL 버전과 충돌하지 않도록 해야 합니다.
형상 테스트의 테스트 케이스를 도출하려면 다음 가이드라인을 사용하십시오.
설치 테스트에서는 테스트 대상이 모든 사용 가능한 설치 시나리오에서 설치될 수 있는지를 확인해야 합니다. 설치 시나리오에는 최초의 테스트 대상 설치나 새 버전 설치 또는 테스트 대상 빌드(이전 버전을 포함하는 시스템) 등이 포함될 수 있습니다. 또한 설치 테스트에서는 부족한 디스크 공간과 같은 비정상 조건이 발생할 경우 테스트 대상이 만족할 수 있게 수행되는지 확인해야 합니다.
테스트 케이스에서는 다음 사항을 포함한 소프트웨어의 설치 시나리오를 설명해야 합니다.
클라이언트-서버 소프트웨어의 설치 프로그램에는 특수화된 테스트 케이스 세트가 있습니다. 호스트 기반 시스템과는 달리, 설치 프로그램은 일반적으로 서버와 클라이언트 사이에서 구분됩니다. 따라서 설치 테스트에서 클라이언트, 미들 티어 및 서버를 포함하는 테스트 대상의 모든 컴포넌트에 대한 설치를 수행해야 합니다.
유스 케이스 모델, 설계 모델 및 추가 스펙 결과물에서 테스트 케이스를 도출하는 데 필요한 모든 입력을 찾는 것이 좋습니다. 그러나 이때 찾아낸 사항을 보완할 필요가 있습니다.
다음과 같은 예가 있습니다.
대부분의 경우 이전에 식별된 테스트 케이스에서 도출한 테스트 케이스의 변량 또는 총계를 작성하여 해당 테스트 케이스를 찾을 수 있습니다.
제품 승인 테스트는 소프트웨어 전개 이전의 최종 테스트 조치입니다. 승인 테스트의 목표는 일반 사용자가 소프트웨어에 빌드된 해당 기능과 타스크를 수행할 수 있도록 소프트웨어가 준비 및 사용될 수 있는지를 확인하는 것입니다. 제품 승인 테스트에는 종종 소프트웨어의 실행에 대비하여 그 이상이 포함되며, 고객에게 전달되는 모든 제품 결과물(예: 훈련, 문서 및 패키지)도 포함됩니다.
소프트웨어 결과물의 테스트 케이스 도출이 위 섹션에서 설명한 방식으로 수행됩니다. 제품 승인 테스트의 범위와 형식에 기초하는 테스트 케이스는 위에서 식별된 테스트 케이스(정식) 또는 서브세트(약식)와 동일하거나 유사합니다. 테스트 케이스의 깊이와는 별도로, 제품 테스트를 구현 및 실행하기 전에 테스트 케이스와 제품 승인 기준에 대해 계약해야 합니다.
비소프트웨어 결과물 평가는 평가할 결과물에 따라 매우 다릅니다. 평가 대상 및 방법에 관한 정보는 각 특정 비소프트웨어 결과물의 가이드라인 및 체크리스트를 참조하십시오.
회귀 테스트는 동일한 테스트 대상의 버전 또는 두 개의 빌드를 비교하여 그 차이를 잠재적 결함으로 식별합니다. 따라서 새 버전이 이전 버전처럼 작동한다고 가정하고, 변경 결과로 해당 결함을 채택하지 않도록 합니다.
하나의 반복에 있는 모든 테스트 케이스는 이후 반복에서 테스트 케이스로 사용되는 것이 좋습니다. 다음 가이드라인은 유지보수를 최소화하는 동안 회귀 테스트 값을 최대화하고 재사용하는 테스트 케이스의 식별, 설계 및 구현에 사용되어야 합니다.
테스트 케이스를 검토하여 일반적인 계약/승인에 도달한 경우에는 실제 데이터 값을 자세히 식별하고(예: 테스트 데이터 구현 매트릭스) 테스트 데이터 결과물을 작성할 수 있습니다.
Rational Unified Process
|