업무, 개발, 테스트는 서로 다른 개인처럼 보이지만 실제로는 그들의 일이 밀접하게 연결되어 있다. 테스터들은 종종 개발 단계에서 비즈니스 요구 사항 설명서를 받고 테스트 사용 사례를 쓰기 시작하는데, 이는 의심할 여지 없이 테스트 효율을 떨어뜨릴 것이다. 요구 사항 검토는 고객의 요구 사항을 빠르고 포괄적으로 이해하는 데 도움이 되며, 이를 통해 후속 테스터가 비즈니스 요구 사항을 이해하는 데 걸리는 시간을 절약할 수 있으며, 회의에서 테스트의 초점과 문제점을 명확하게 파악하여 토론을 통해 솔루션을 찾을 수 있습니다.
비즈니스 흐름도를 사용하여 테스트 케이스를 작성하십시오.
일부 복잡한 요구 사항의 경우 분기 경로가 많기 때문에 테스트 시 개별 상황을 쉽게 무시할 수 있습니다. 이때 비즈니스 요구 사항에 따라 비즈니스 순서도를 그리거나 개발자가 코딩할 때 관련 비즈니스 순서도를 참조하는지 물어보십시오. 비즈니스 흐름도는 각 분기 경로의 상황을 직관적이고 명확하게 표시하여 테스트 사례가 불완전하지 않도록 합니다.
예를 들어, 공공 계좌 동결 관련 거래의 최적화를 테스트할 때 몇 줄의 비즈니스 요구에 따라 매우 복잡한 비즈니스 흐름도를 그렸습니다. 다음 그림은 부분 동결 및 강제 공제의 비즈니스 논리를 중점적으로 설명하는 간단한 버전으로, 관련 공식과 숫자는 문자로 대체됩니다. 이런 수요에 대해 그림이나 표를 그리지 않으면 포괄적이고 정확한 테스트 케이스를 설계하기가 어렵다. 그러나 비즈니스 담당자, 개발자와 논의하고 자세한 비즈니스 순서도를 파악한 후에는 테스트 케이스 작성에 누락이 없을 것입니다. 따라서 여러 지점의 업무 수요에 대해서는 그림을 잘 그리고 도표로 생각을 명확하게 검증해야 한다.
기업 협회 시스템 분석
테스트 분야에서는 관련 시스템에 대한 분석이 부족한 것이 변화의 중요한 원인 중 하나이다. 서비스 공급자 시스템의 인터페이스가 변경되면 해당 인터페이스를 호출하는 관련 소비자 시스템의 기능을 적절히 조정하거나 총 회귀를 수행해야 합니다. 크로스 시스템 호출은 종종 여러 개발자를 포함 하기 때문에, 모두가 서로의 시스템을 충분히 이해 하지 않습니다, 그래서 상관 관계 분석은 특히 엄격 해야 합니다.
4. 완벽한 비즈니스 시나리오
업무 프로세스는 계좌 개설-활성화-판매, 동결-동결 계속-해동, 계약 서명-유지 관리-종결을 포함한 폐쇄 루프를 형성하는 경우가 많기 때문에 업무 시나리오는 최대한 완전해야 합니다. 예를 들어 간접비 계정의 논리는 설계 시 다를 수 있습니다. 계좌를 개설할 때 새로 개설한 계좌와 계좌를 이체한 고객번호가 일치하는지 판단하지 않고, 지불을 요구할 때 고객번호가 일치하기 때문에 계좌를 개설할 수 있지만 계좌를 판매할 수 없는 등의 조작 위험이 있다. 따라서 사례 설계에서는 전환 지점이 계좌 개설 또는 계약이지만 가능한 한 완전한 비즈니스 프로세스를 테스트해야 합니다.
5. 날짜
날짜는 테스트에서 매우 중요한 요소입니다. 당일에 할 수 있는 거래, 회계 날짜를 전환하거나 거래 날짜를 수정하는 것은 모두 실패할 것이다. 예를 들어 다단계 장부 잔액 조정을 테스트할 때 최초 거래 일자가 현재 회계 일자인 경우 거래 정보가 정확하며, 최초 거래 일자가 현재 회계 일자보다 이전인 경우 수취인의 다단계 장부 번호는 서로 다른 프로그램 분기에 해당하므로 오류를 표시합니다. 따라서 사례를 설계할 때는 시간 요소가 거래에 미치는 영향을 충분히 고려하여 다양한 날짜 값을 설계해야 하는지 여부를 분석해야 합니다.
데이터를 캐시하다
테러 관련 정보와 같은 테스트 데이터에 대한 엄격한 요구 사항이 있을 경우 캐시된 데이터의 영향에 주의해야 합니다. 예를 들어, 먼저 유효한 데이터 세트를 입력하고 제출하면 거래가 중간에 종료됩니다. 이때 거래 정보는 비워지지 않고 유효하지 않은 테스트 데이터로 수정되어 성공합니다. 이는 비즈니스 요구 사항에 반하는 것입니다. 따라서 입력에 제한이 있을 경우 캐시된 데이터가 제때에 비워지거나 업데이트되도록 해야 합니다.
7. 테스트 데이터 유형
테스트 데이터의 유형은 풍부해야 합니다. 예를 들어, 환산에 만료된 임시 계정이 포함된 경우 만료되지 않은 임시 계정, 만료된 기본 계정, 만료된 일반 계정, 만료된 특수 사용자, 등록 자본 검증 계정 및 만료된 외환 계정을 검증해야 합니다. 일반적으로 결함은 변환점 자체가 아닌 관련 요소에서 발생합니다. 개발자는 인코딩 시 변환점에 대해서만 단위 테스트를 수행하고 연관 요소는 쉽게 간과되기 때문입니다.
8. 증빙 영수증
전표는 반드시 명확하고 직관적이어야 하며, 거래가 성공한 후에는 전표 표시를 확인해야 한다. 중요한 것은 거래 정보가 큰 경우 줄임표 대체 거래 정보가 금액, 계정 등과 같은 중요한 정보인지 확인하는 것입니다. 도장이 중요한 정보를 차단하는지 여부, 고객이 서명할 수 있는 충분한 공간이 있는지 여부 등을 알 수 있습니다.