paint-brush
소프트웨어 QA: 조합 테스트 설계 문제 해결~에 의해@shad0wpuppet
26,169 판독값
26,169 판독값

소프트웨어 QA: 조합 테스트 설계 문제 해결

~에 의해 Konstantin Sakhchinskiy5m2024/01/22
Read on Terminal Reader
Read this story w/o Javascript

너무 오래; 읽다

소프트웨어 테스트, 특히 k-way 및 쌍별 테스트와 같은 조합 테스트 설계의 과제. 잘못된 입력, 강력한 테스트 방법, 변수 조합과 같은 문제에 대해 논의합니다. 사례 연구를 사용하여 감지되지 않은 결함의 확산을 강조하고 기본 설정과 복잡한 변수 상호 작용을 고려하여 미묘한 테스트 접근 방식의 필요성을 강조합니다. 핵심 내용은 강력한 소프트웨어에 대한 포괄적인 테스트 전략의 중요성입니다.
featured image - 소프트웨어 QA: 조합 테스트 설계 문제 해결
Konstantin Sakhchinskiy HackerNoon profile picture


소프트웨어 테스팅 에서 테스트 사례 설계는 앱의 신뢰성과 견고성을 보장하는 데 필수적입니다. k-way 테스트 및 쌍별 테스트와 같은 조합 테스트 설계 기술은 서로 다른 입력 변수 간의 상호 작용을 테스트하는 것을 목표로 합니다. 그러나 문제와 함정으로 인해 심각한 오류를 찾아내는 효율성이 저하될 수 있다는 것이 분명해졌습니다.


이 짧은 기사는 조합 테스트 설계 중에 발생할 수 있는 특정 문제에 초점을 맞추고 신중한 고려가 필요한 미묘한 차이를 탐구합니다. 잘못된 입력 값의 사례, 강력한 오라클의 중요성, 자주 간과되는 변수 조합의 중요성, 변수가 상호 작용하는 방식에 대한 중요한 이해를 살펴보겠습니다.


입력 값의 식별이 잘못 되었습니다 .

k-way 테스트 세트는 k 변수 값의 가능한 모든 조합으로 구성됩니다. 예를 들어, Allpairs 알고리즘을 적용하면 변수 값 쌍의 가능한 모든 조합을 포함하는 양방향 테스트 세트가 생성됩니다. 결과적으로, k-way 결함은 k 변수 값의 상호 작용으로 인해 발생하는 오류를 의미합니다. SYS1과 SYS2라는 두 시스템을 조사한 결과 프로덕션 릴리스 이후에 오류가 발견되었습니다. 두 시스템 모두 k 값이 2, 3, 4 및 5+인 k-way 테스트를 거쳤습니다.


표는 두 시스템에 대한 k-way 테스트 결과를 표시합니다.

결함 유형

SYS1

SYS2

양방향

30

29

3방향

4

12

4방향

7

1

> 4방향

7

찾을 수 없음

34

43


각 k-way 세트에 대해 순차적인 점검이 수행되었습니다. 그림 2.1을 보면 2개 이하의 입력 변수의 상호 작용으로 인해 발생하는 오류가 29 in SYS1 , 30 in SYS2 알 수 있다. 세 변수의 상호 작용으로 인한 오류는 4*(30+4) in SYS2 12*(29+12) in SYS1 였습니다. 4개 변수가 포함된 상호작용의 경우 오류는 7*(30+4+7) in SYS2 1*(29+12+1) in SYS1 이었습니다. 4개 이상의 변수와의 상호 작용으로 인한 오류는 3*(29+12+1+3) in SYS1 7*(30+4+7+7) in SYS2 이었습니다. 특히 SYS1에서는 43개의 오류가 발견되지 않았고, SYS2에서는 34개의 오류가 발견되지 않았습니다.


이 예에서 가장 심각한 오류는 찾을 수 없음 범주에 속합니다. 추가 조사를 통해 발견되지 않은 오류의 대부분은 단방향 오류인 것으로 나타났습니다. 즉, 한 변수의 특정 값이 다른 변수 값과 관계없이 오류로 이어졌음을 의미합니다. 쌍별 테스트를 통해 이러한 오류를 발견했어야 했지만 어떤 이유로 발견되지 않은 채 남아 있었습니다. 이러한 찾을 수 없음 오류는 특정 입력 값이 선택되지 않았거나 잘못 선택되었기 때문에 발견되지 않은 주로 단방향 오류입니다.


문제의 본질은 Allpairs 알고리즘을 적용하기 전에 발생한 모든 오류가 지속된다는 사실에 있습니다. 이는 이전 테스트 설계 기법이 잘못 적용되었거나 입력 값이 올바르지 않은 경우 Allpairs Algorithm 또는 Orthogonal Array Testing을 사용하더라도 응용 프로그램의 오류가 지속된다는 것을 의미합니다.


예상 결과 정의의 약점: 최종 결과의 불확실성

예를 들어, 수많은 옵션(이 형식처럼 보이는 것)이 있고 결과적으로 많은 수의 입력 데이터 조합이 있는 애플리케이션 모듈을 고려해 보겠습니다.


모듈에서 2^12 * 3 가능한 조합이 있다고 가정해 보겠습니다. 여기서 문제는 잘못된 입력 값을 선택하는 것이 아닙니다. 가능한 모든 변수 값은 Allpairs 알고리즘을 사용하여 철저하게 테스트할 수 있기 때문입니다. 하지만 이렇게 하면 심각한 오류가 모두 드러날까요? 예상되는 결과에 문제가 있기 때문에 그렇지 않을 수도 있습니다. 이러한 종류의 소프트웨어 모듈에서 각 옵션 조합을 조작한 후에는 옵션이 올바르게 작동하는지, 선택한 옵션을 적용한 후 다른 문제가 발생하지 않는지 확인하기 위해 얼마 동안 시스템을 사용해야 합니다. 이 경우 쉽게 놓칠 수 있는 미묘하고 명백하지 않은 문제가 없다는 보장은 없습니다.


각 테스트 후에는 시스템의 핵심 기능을 철저하게 평가해야 할 수도 있습니다. 여기서 중요한 점은 심각한 결함이 원하는 만큼 명확하지 않은 경우가 많으며 예상되는 결과의 모든 것을 설명하는 것이 사실상 불가능하다는 것입니다.


가장 가능성 있는 조합에 대한 부주의

2^12 * 3 조합(위의 예에서 제안한 대로) 중에서 다른 모든 옵션보다 훨씬 더 자주 발생하는 모듈 옵션 조합이 하나 있을 수 있습니다( 기본 설정). 95%의 사람들이 이 모듈의 기본 설정에서 옵션을 절대 변경하지 않을 경우 거의/거의 기본 옵션에 대한 적용 범위가 충분해야 합니다. 하나의 옵션에서 기본 구성과 다른 모든 변형을 테스트하면 테스트 횟수가 2자리가 됩니다. 기본값과 두 가지 설정에서 편차가 있을 수 있는 옵션의 모든 조합을 테스트하는 경우 약 100개의 테스트 사례가 됩니다. 이러한 테스트 사례와 모든 쌍 테스트 사례를 사용하여 테스트하면 기본 옵션의 존재를 무시하는 것보다 더 나은 결과를 얻을 수 있습니다. 그러나 Allpairs 알고리즘은 테스터가 가장 가능성이 높고 일반적으로 사용되는 변수 조합을 간과하도록 만듭니다.


알 수 없는 변수 상호 작용

쌍별 검정의 성공 또는 실패를 결정하는 핵심 요소는 입력 변수의 조합이 출력 데이터에 어떤 영향을 미치는지 이해하는 것입니다. 테스트된 서로 다른 두 응용 프로그램에 쌍별 테스트를 적용하면 상당히 다른 결과가 나올 수 있습니다. 일부 애플리케이션은 더 적은 수의 입력 데이터를 사용하여 출력 데이터를 생성하는 반면 다른 애플리케이션은 더 많은 입력 데이터를 사용합니다.


예를 들어, 세 개의 입력 변수(X, Y, Z)와 세 개의 가능한 출력 데이터(1, 2, 3)가 있는 프로그램을 생각해 보세요. 화살표는 특정 결과를 생성하기 위해 상호 작용해야 하는 변수를 나타냅니다. 1이라는 결과를 얻으려면 변수 Y와 X가 상호 작용해야 합니다. 2의 결과를 얻으려면 변수 Z와 X가 상호 작용해야 합니다. 이 애플리케이션의 경우 쌍별 테스트를 적용하는 것이 적합한 선택이며 긍정적인 결과가 나올 가능성이 높습니다. 그러나 두 개 이상의 입력 변수의 상호 작용으로 인해 출력 데이터가 생성되는 시나리오가 있는 경우 쌍별 테스트에서 오류를 식별하지 못할 가능성이 높습니다. 단순히 쌍별 테스트를 적용하면 테스트된 애플리케이션의 심각한 오류를 간과할 위험이 높아집니다.


QA 전문가로서 이러한 미묘한 차이를 이해하는 것이 중요합니다. 어떤 경우에는 이론적이지만 이러한 통찰력은 표면을 뛰어넘어 앱의 안정성과 견고성을 보장하는 전체적인 테스트 접근 방식의 필요성을 강조합니다. 조합 테스트 디자인의 복잡성을 이해하면 QA 전문가는 앱의 복잡한 비즈니스 로직을 효과적으로 테스트하고 사용자에게 고품질 소프트웨어를 제공할 수 있습니다.