소프트웨어를 테스트하는 동안 사용자가 소프트웨어에 대해 이러한 바보 같은 행동을 수행하지 않을 것이라고 가정 할 수 있습니까?


71

예를 들면 : 웹 애플리케이션에서 양식의 기능 테스트를 수행하는 동안 다른 종류의 임의의 입력 값을 입력하여 필드를 테스트합니다.

일반적으로 웹 응용 프로그램 사용자는 실제로 필드에 임의의 값을 입력하지 않습니다.

그렇다면 생산에서 이러한 종류의 문제가 나타날 가능성이 적을 때 버그로 이어질 수도 있고 그렇지 않을 수도있는 모든 테스트 케이스를 통합하여 사용하는 것은 무엇입니까?

참고 : 위의 예는 샘플 사례 일뿐입니다. 이러한 문제는 모든 종류의 기능 / 모듈에서 발생할 수 있습니다.

표준 관행이 따라야하는지 또는 제품, 도메인 및 기타 모든 요소에 전적으로 의존하는지 여부를 알기 위해서만이 질문을하고 있습니다.


4
아마도 관련 : 원숭이 테스트 , 장단점
Christophe

답변:


190

웹 응용 프로그램의 필드에 임의의 값을 입력하지 않을 수도 있지만 분명히 그렇게하는 사람들이 있습니다.

어떤 사람들은 우연히 무작위로 입력하고 다른 사람들은 의도적으로 응용 프로그램을 중단하려고합니다. 두 경우 모두 응용 프로그램이 충돌하거나 원치 않는 다른 동작을 나타내기를 원하지 않습니다.
첫 번째 유형의 사용자에게는 좋지 않은 경험을 제공하고 사용자를 끌 수 있기 때문에 원하지 않습니다.
두 번째 유형의 사용자는 일반적으로 명예로운 의도가 없으며 사용자가 액세스 할 수 없어야하는 정보에 액세스하지 못하게하거나 진정한 사용자가 서비스에 대한 액세스를 거부하도록 허용하지 않습니다.

테스트의 표준 관행은 날씨가 좋은 경우뿐만 아니라 잠재적 인 문제를 찾아 공격자가 시스템에 쉽게 액세스 할 수 없다는 확신을 가지기 위해 특이한 경우를 조사하는 것입니다. 응용 프로그램이 이미 임의 입력으로 충돌하는 경우 공격자가 특수하게 조작 된 입력으로 수행 할 수있는 작업을 알고 싶지 않습니다.


16
그리고 그것을하는 사람들 이 아닌 것들이 있습니다. 👽
kojiro

110
또는 "O'Malley", "姓名"또는 "Robert "와 같은 실제 법적 이름을 입력하려고 시도했을 수 있습니다 . DROP TABLE 학생;-” .
l0b0

90
아니면 진짜 회사 이름 일 수도 있습니다 . DROP TABLE "회사";-LTD .
Ben

25
키보드를 가로 질러 걷는 고양이의 임의의 입력으로 프로그램이 충돌하면 악의적 인 입력으로 인해 거의 확실하게 충돌 (및 악화) 될 것이라고 강조함으로써 마지막 단락을 더 강하게 만들 수 있다고 생각합니다 .
phihag

11
또한 많은 사람들은 이름, 생일 등 실제 데이터를 제공하지 않기 때문에 임의의 입력을 입력합니다. 일부는 컴퓨터가 전화 교환 원처럼 똑똑하다고 가정하고 "2016"대신 "지난 해"와 같은 유형을 입력하여 응용 프로그램이 사람처럼 컴퓨터를 처리 할 것으로 기대할 수 있습니다.
Luaan

102

아무것도 가정하지 마십시오

사용자가 실수로 또는 의도적으로 소프트웨어로 "멍청한"짓을하지 않을 것이라고 가정 할 수 없습니다. 사용자가 실수로 잘못된 버튼을 누르면 고양이가 키보드를 걸을 수 있으며 시스템이 오작동하거나 컴퓨터가 악성 소프트웨어 등으로 도용 당할 수 있습니다.

또한, 사용자 자신도 악의적 일 수 있으며, 의도적으로 소프트웨어를 활용하여 자신의 이점을 활용할 수있는 방법을 찾을 수 있기를 바랍니다. 그들이 악용 할 수없는 버그를 발견하더라도 QA 절차가 부족하다는 것을 알면서 공격 할 수있는 것을 시스템에서 조사하기 위해 찾은 것이 무엇이든 발견 할 수 있습니다.

테스트와 관련하여 임의의 입력을 방지하는 것이 유용하지만 테스트 입력을 완전히 무작위로 선택하는 것은 (즉, 유스 케이스 또는 엣지 케이스를 특별히 고려하지 않는) 쓸모없는 경계입니다. 테스트의 목적은 고용주 / 고객 / 사용자의 요구 사항과 기대에 대해 솔루션을 검증하는 것입니다. 즉, 모든 예상 사례 및 경계 조건뿐만 아니라 사용자의 예상 된 워크 플로에 맞지 않는 '퇴화'사례를 대상으로하는 데 집중해야합니다.

물론 나중에 고칠 가치가 없다고 결정한 버그를 드러내는 테스트를 실행할 수도 있습니다. 이것은 모든 종류의 이유 일 수 있습니다-버그는 사용자에게 미치는 영향과 관련하여 수정하기에는 너무 비쌀 수 있습니다. 또는 아무도 사용하지 않는 기능의 버그를 발견하거나 시스템에 버그가 이미 잘 설정되어있을 수 있습니다. 사용자는이를 기능으로 취급합니다.

또는 버그를 수정하는 데 시간을 소비하는 데 상업적 이점이없는 '전문가'사용자의 대상이 엄격하게 제한된 맞춤형 소프트웨어를 작성하는 경우도 있습니다. 이러한 사용자는 버그가있는 소프트웨어 (예 : 진단 도구)로 작업을 수행 할 수 있기 때문입니다. 내부 IT 팀에서 사용하는 수익은 제공되지 않으므로 간혹 충돌이 발생하면이를 해결하는 데 필요한 시간을 지불 할 사람이 아무도 없습니다. IT 팀에 대신 버그를 해결하도록 지시합니다.) .

그러나 이러한 버그에 대해 알고있는 경우에만 결정을 내릴 수 있습니다. 예를 들어, 사용자가 전체 데이터베이스를 지우는 악의적 인 입력을 입력 할 수 있습니다.이 시나리오에 대해 명시 적으로 보호 및 테스트하지 않은 경우 이러한 상황이 발생했는지 여부를 확신 할 수있는 방법이 없습니다. 시스템에 발견되지 않은 버그가 남을 위험은 해당 버그 중 하나가 실제 세계에서 드러나 사용자에게 큰 영향을 미치는 경우 실제 문제에 노출 될 가능성이 있음을 의미합니다.

따라서 버그를 고칠 지 여부를 결정하려면 소프트웨어 소유자 (보통 급여를 지불 한 사람)의 의견이 필요할 수 있지만 버그 테스트 여부와 테스트 사례에 대한 결정은 엔지니어링 문제입니다. 시간 / 돈 / 자원에 대한 제약을 감안할 때 합리적으로 가능한 한 전체 범위에 가까운 목표를 달성해야하는 견적 및 프로젝트 계획에 포함됩니다.


12
전적으로 무작위로 테스트하는 것은 유용하지 않으며 생각할 수있는만큼 많은 경우를 명시 적으로 테스트해야하지만 일정량의 임의의 퍼징은 때때로 예상치 못한 문제를 확인하는 데 유용 할 수 있습니다.
Sean Burton

10
우리는 "멍청한 사람들이 영리한 사람이기 때문에 바보 증거 소프트웨어를 작성하는 것이 너무 어렵다"고 말합니다. 따라서 "넌센스"입력을 테스트하십시오!
Ralf Kleberhoff 2014

For example, a user may enter a malicious input which wipes the entire database - if you haven't explicitly protected against and tested for this scenario, then there's no way you can be sure whether or not this can happen. XKCD 만화의 작은 바비 테이블처럼 ? ;)
nick012000

12
"아무것도 가정하지 마십시오." 나는 이것이 좋은 조언이라고 생각합니다.
candied_orange

모든 "버그"가 "수정"인 것은 아닙니다. Edge Case를 인식하고 Edge Case를 수정하는 데 시간과 비용을 소비하는 데 큰 차이가 있습니다. 웹 양식에 가능한 모든 입력을 허용하고 모든 경우에 대해 응답을 설정하는 것이 좋을 수도 있지만 특정 소프트웨어와 관련이 없을 수도 있습니다. 입력에 따라 프런트 엔드의 숫자 만 허용되므로 백엔드에서는 숫자가 아닌 숫자를받는 것이 불가능합니다. 숫자만으로 숫자가 아닌 잠재적 버그를 "고정"하면 시간과 돈을 낭비하게됩니다.
EvSunWoodard

60

고려해야 할 몇 가지 요소가 있습니다. 이러한 요점을 설명하기 위해 사용자가 작업이 사용할 수있는 디스크 공간과 관련하여 특정 작업에 대해 정의 된 할당량 컨텍스트에서 백분율을 입력해야하는 필드의 예를 사용하겠습니다. 0 %는 작업이 디스크에 아무것도 쓸 수 없음을 의미합니다. 100 %는 작업이 모든 디스크 공간을 채울 수 있음을 의미합니다. 사이의 값은 의미를 의미합니다.

개발자는 아마도 허용 가능한 값이 [0, 1, 2, 3, ⋯ 99, 100]이고 다른 모든 것은 어리 석다는 것을 고려하고있을 것입니다. 사용자가 왜 이러한 "실리적인"값을 입력 할 수 있는지 알아 봅시다.

오타

%^

사용자가 값 56 Shift을 입력 했지만 입력하는 동안 실수로 눌렀 습니다 (예를 들어 프랑스어 키보드에서는 Shift숫자를 입력 하기 위해를 눌러야 하며 사용자는 프랑스어 키보드와 QWERTY간에 계속 전환하고 있음).

같은 방법으로, 그 전후에 또는 사이에 숫자를 넣을 수 있습니다.

56q

여기서 사용자는 아마도 숫자를 입력 한 후 다음 필드로 이동하기위한 탭이있을 것입니다. 를 누르는 대신   ⇆  사용자는 이웃 키를 눌렀습니다.

오해와 오해

빈 입력이 가장 일반적 일 것입니다. 사용자는이 필드가 선택 사항이거나이 필드에 무엇을 넣을지 몰랐습니다.

56.5

사용자는 부동 소수점 값이 허용 가능하다고 생각했습니다. 사용자가 틀렸고 응용 프로그램에서 정수 값만 허용되거나 초기 요구 사항이 잘못된 이유를 정중하게 설명해야하며 사용자가 부동 소수점 값을 입력하도록하는 것이 좋습니다.

none

사용자는 작업을 수행 할 수있는 공간을 물었을 때 앱이 숫자를 예상한다고 오해했습니다. 이는 사용자 인터페이스가 불량 함을 나타냅니다. 예를 들어, 사용자에게 "작업을 수행하는 데 필요한 디스크 공간은 얼마입니까?" 많은 의미.

150

이 경우 사용자는 백분율의 의미를 잘못 이해했습니다. 사용자는 작업이 현재 사용 된 공간의 150 %를 차지할 수 있다고 말하고 싶기 때문에 2TB의 디스크에서 100GB를 사용하는 경우 150GB를 사용할 수 있습니다. 더 나은 사용자 인터페이스가 도움이 될 수 있습니다. 예를 들어 퍼센트 기호가 추가 된 베어 입력 필드 대신 다음을 가질 수 있습니다.

[____] % of disk space (2 TB)

사용자가 입력을 시작하면 즉시 텍스트가 다음과 같이 변경됩니다.

[5___] % of disk space (102.4 GB of 2 TB)

대표

부동 소수점이있는 큰 숫자 또는 숫자는 다르게 표시 될 수 있습니다. 예를 들어 숫자 1234.56은 다음과 같이 쓸 수 있습니다 1,234.56. 문화권에 따라 같은 숫자의 텍스트 표현이 달라집니다. 프랑스어로 같은 숫자가 다음과 같이 작성됩니다 1 234,56. 예상하지 못한 쉼표와 공백을 참조하십시오.

다른 국가의 사용자는 숫자, 날짜 및 시간 등을 쓰는 습관이 다르기 때문에 특정 로캘을 사용하여 특정 형식을 항상 기대하면 조만간 문제가 발생할 수 있습니다.

인간 대 컴퓨터

Twenty-four

평범한 인간은 컴퓨터와 같은 방식으로 생각하지 않습니다. “24” PC가 말하는 것과 관계없이 실제 숫자입니다.

(1) 대부분의 시스템은이 유형의 입력을 모두 처리하지 않으며 (2) 거의 모든 사용자가 전체 문자로 작성된 숫자를 입력한다고 상상하지는 않지만 그러한 입력이 바보라는 것을 의미하지는 않습니다. 에서 얼굴 3 약 , 앨런 쿠퍼는 입력을 처리하지 않은 점은 인간에 적응하고, 이상적으로, 인터페이스가 제대로 그 입력을 처리 할 수 있어야합니다 컴퓨터의 무능력을 나타낸다 수 있습니다.

Alan Cooper의 책에 추가해야 할 유일한 것은 많은 경우 실수 로 숫자 숫자로 쓰여진다는 입니다. 컴퓨터가 사용자가 실수를 할 것을 기대하고 (정확하게 쓰는 사용자를 용납하지 않음) 사실 성가신 일입니다.

유니 코드

5𝟨

유니 코드는 놀라움을 선사합니다. 똑같이 보일 수있는 문자는 동일하지 않습니다. 확신이 없습니까? "5𝟨" === "56"브라우저의 개발자 도구에 복사하여 붙여 넣고을 누릅니다 Enter.

해당 문자열이 동일하지 않은 이유는 유니 코드 문자 𝟨가 문자 와 동일하지 않기 때문 6입니다. 이로 인해 화가 난 고객이 전화를 걸어 앱이 작동하지 않는다고 알리고 합법적으로 보이는 입력의 스크린 샷을 제공하고 입력이 유효하지 않다고 주장하는 앱을 만들 수 있습니다.

왜 숫자처럼 보이는 유니 코드 문자를 입력해야합니까? 사용자가 의도하지 않게 입력하는 것을 기대하지는 않지만 다른 소스의 복사 붙여 넣기로 인해 문제가 발생할 수 있으며 사용자가 실제로는 그렇지 않은 유니 코드 문자가 포함 된 문자열의 복사 붙여 넣기를 수행 한 경우가 있습니다. 화면에 나타납니다.

결론

이것들은 당신이 기본 숫자 입력 필드를 얻는 경우입니다. 날짜 나 주소와 같은 더 복잡한 양식을 처리하기 위해 무엇을 처리해야하는지 상상해 보도록하겠습니다.

내 대답은 당신이 "바보"입력이라고 부르는 것에 중점을 둡니다. 테스트는 행복한 길을 확인하는 것이 아닙니다. 또한 악의적 인 사용자가 의도적으로 이상한 것을 입력하여 깨뜨 리려고 할 때 앱이 중단되지 않는지 확인하는 것입니다. 즉, 백분율을 요청할 때 사용자가 1,000,000 자 또는 음수 또는 bobby table을 포함하는 문자열로 응답 할 때 발생하는 상황을 테스트해야 합니다 .


9
Ah, U + 1D7E8 : 수학 SANS-SERIF DIGIT SIX.
Andreas Rejbrand

23
다른 유니 코드 문자 다시 : 일본어 키보드에서는 숫자가 한자만큼 넓은 일반 자릿수에서 전각 자릿수로 전환하는 것이 일반적입니다. 따라서 일본어 사용자가 영어가 아닌 일본어로 입력하고 실수로 전각 숫자를 입력했을 수 있습니다.
Jan

3
동일한 상형 문자 문제에 관한 5𝟨 섹션을보기 전에 실제로 숫자 1 234,56문자열 (또는 U + 202F를 사용하여 U + 00A0 NO-BREAK SPACE 대신 U + 00A0 NO-BREAK SPACE 사용)을 예상하고있었습니다. 좁은 노스페이스 공간, peroahps). 사용자에게 제시하기 전에 로케일에 따라 숫자를 형식화하는 모든 애플리케이션에서 값을 복사하면 해당 값을 쉽게 생성 할 수 있습니다.
Ángel

4
복사 붙여 넣기는 훨씬 더 큰 문제입니다. 붙여 넣기 공백, 줄 바꿈, 보이지 않는 문자를 복사하는 것이 일반적입니다.
Sulthan

7
@Arseni Mourzenko 운이 좋을 것입니다. 예를 들어 PDF에서 복사하여 붙여 넣기는 원에 따라 바람직하지 않을 수있는 모든 종류의 문자, 예를 들어 합자 (fi 등의 경우), 스마트 인용 부호, ASCII 마이너스가 필요한 en 또는 em 대시 등을 붙여 넣을 수 있습니다.
Rosie F

12

여기에 이것이 중요한 이유를 설명하는 좋은 답변이 많이 있지만 애플리케이션을 현명하게 보호하는 방법에 대한 조언은 많지 않습니다. "표준 사례"는 클라이언트와 서버 모두에서 강력한 입력 유효성 검사 를 사용 하는 것입니다. 무의미한 입력은 방어하기 쉽습니다. 특정 상황에서 의미가없는 것을 거부하면됩니다. 예를 들어, 사회 보장 번호는 대시와 숫자로만 구성됩니다. 사용자가 사회 보장 번호 필드에 입력 한 다른 내용은 안전하게 거부 할 수 있습니다.

작성하는 모든 응용 프로그램마다 두 가지 종류의 테스트가 수행되어야하며 각각 다른 목적을 가지고 있습니다. 자신의 응용 프로그램에서 수행하는 테스트긍정적 인 테스트입니다. 그 목적은 프로그램이 작동한다는 것을 증명하는 것입니다. 테스터가 애플리케이션에서 추가로 수행하는 테스트네거티브 테스트입니다. 그 목적은 프로그램이 작동하지 않음증명하는 것입니다. 왜 이것이 필요한가요? 자신의 소프트웨어를 테스트하는 가장 좋은 사람은 아니기 때문입니다. 결국, 당신은 그 일을 썼으므로 분명히 이미 작동합니다.

입력 유효성 검사를 작성할 때 유효성 검사가 작동하는지 확인하기 위해 긍정적 인 테스트를 수행합니다. 테스터는 임의의 입력을 사용하여 작동하지 않는다는 것을 증명하려고 시도합니다. 랜덤 입력의 문제 공간은 본질적으로 제한이 없습니다. 목표는 가능한 모든 순열을 테스트하는 것이 아니라 잘못된 입력을 거부하여 문제 공간을 제한하는 것입니다.

또한 최종 사용자 만이 프로그램에 입력을 제공하는 것은 아닙니다. 작성하는 모든 클래스에는 고유 한 API와 유효한 입력으로 간주되는 것에 대한 자체 제약 조건이 있으므로 강력한 유효성 검사 (예 : "코드 계약")도 클래스에 중요합니다. 아이디어는 예기치 않은 동작이 거의 또는 거의 존재하지 않도록 소프트웨어를 강화하는 것입니다.

마지막으로 워크 플로우가 중요합니다. 사용자가 무의미한 것을 입력했기 때문이 아니라 응용 프로그램에서 예기치 않은 순서로 작업을 수행했기 때문에 응용 프로그램이 넘어지는 것을 보았습니다. 응용 프로그램은 이러한 가능성을 인식하고 예기치 않은 워크 플로를 정상적으로 처리하거나 사용자가 지정된 순서대로 작업을 수행하도록 요구합니다.


특정 순서를 예상하는 응용 프로그램의 일반적인 예로는 예약되지 않은 핸들을 해제하는 "teardown"기능이 있습니다.
wizzwizz4

2
불행히도, 표준 관행은 이해가되지 않는 것을 거부하고 사용자를 혼란스럽고 좌절하게 만드는 것입니다. 올바른 방법은 입력이 거부 된 이유를 정확하게 설명 (예 : 오류 메시지 / 피드백 사용)하여 사용자가 입력을 수정하고 승인하는 방법을 알 수 있도록하는 것입니다. 간단한 "1에서 100까지 정수 얻기"에는 최소 4 개의 다른 오류 메시지 (빈 문자열, 지원되지 않는 문자, 너무 크거나 너무 작은)가 필요합니다. 각 경우에 올바른 피드백이 제공되는지 테스트합니다.
Brendan

2
@Brendan : 하나의 메시지 만 필요합니다 : "이것은 1에서 100 사이의 숫자 여야합니다." 사용자는 문자열 이 무엇인지 또는 "지원되지 않는 문자"가 무엇을 의미하는지 알 수 없으며 알 필요도 없습니다 . 이는 사용자의 도움이 아닌 프로그래머의 영향입니다.
Robert Harvey

@RobertHarvey 아마도 "숫자로 구성된"줄을 따라 그 문장에 무언가를 추가 할 것입니다. 입력 "Seventy-Nine"은 1에서 100 사이의 숫자이지만 대부분의 프로그램이 작업 할 수있는 입력은 아닙니다.
Delioth

1
@Delioth : 당신은 바보를 고칠 수 없습니다.
Robert Harvey

11

일반적으로 '무작위'값은 무작위가 아닙니다. "알 수없는 알려지지 않은"엣지 케이스를 캡처하려고합니다.

예를 들어 # 문자가 앱을 중단시킵니다. 당신은 이것을 미리 알지 못하고 가능한 모든 입력에 대해 테스트 케이스를 작성하는 것은 불가능합니다. 그러나 우리는 테스트를 작성하여 "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"실패하는지 확인할 수 있습니다


2
+1 놀랍게도 그 임의의 캐릭터가 얼마나 자주 버그를 발견하는지 알 수 있습니다. 사용자 입력의 데이터는 많은 구성 요소 / 서비스를 통해 많은 작업을 수행 할 수 있습니다. 체인에 하나의 구성 요소 만 있으면 시스템에서 버그를 처리 할 수 없습니다 .
Lan

4
esp. 모바일 키보드에는 모두 이모티콘이 있습니다.
Ewan

.Net 개발자의 경우 IntelliTest 도구 (이전의 Pex)는 실제 사례를 찾기 위해 코드 경로를 연습 할 수있는 좋은 방법입니다. 특히 입력 유효성 검사 및 코드 적용 범위를 넓히는 데 유용합니다.
James Snell

7

한 번은 60 명의 학생들과 함께 실험실에서 테스트 한 프로그램을 작성했습니다. 나는 60 대의 컴퓨터 화면 뒤에 서서 그것을 사용하는 것을 보았다. 그들이 우스운 일을하는 것은 머리를 기르는 일이었습니다. 나는 그들의 "창의력"을보고 땀에 흠뻑 젖었다. 그들은 평생 한 명의 개인이 환상을 가질 수있는 것보다 훨씬 많은 일을했습니다. 물론 그들 중 하나가 고장났습니다.

그 후 나는 접근 방식을 따릅니다. if "a very specific use case" do, else show error

여러 유스 케이스가있는 경우 엄격하게 정의하고 위의 체인을 연결합니다.


1
그러나 이러한 특정 사용 사례는 너무 구체적 일 수 있습니다 . 우리는 항상 유효한 입력 공간을 과소 평가합니다 . (오하라, 현지 형식의 소수 자릿수 등). 마이너스 금리를 처리하기 위해 몇 가지 재정적 인 루틴이 준비 되었습니까?
Guran December

6

당신이 설명하는 것은 퍼징 또는 퍼즈 테스트는 시스템에서 무작위 잘못된 입력을 던져 무슨 일을 참조하십시오. 사용자가 그렇게하기를 기대하기 때문에이 작업을 수행하지 않습니다. 당신은 자신의 가정과 편견을 드러내어 시스템의 가장자리를 강조하여 어떤 일이 일어나는지 알 수 있습니다.

인간이 작성한 정상적인 테스트 입력에는 가정과 편견이 있습니다. 이러한 편견은 테스트를 통해 특정 종류의 버그를 찾을 수 없습니다.

예를 들어, 대부분의 입력이 ASCII 안전 유니 코드 범위에 있으면 코드의 문자 인코딩에 대한 가정이 수행되지 않습니다. 또는 항상 특정 크기보다 작을 수 있으므로 고정 크기의 필드 또는 버퍼가 적중되지 않습니다. 또는 사용자 입력이 쉘에 제공되거나 안전하지 않은 방식으로 쿼리를 작성하는 데 사용되는 놀라운 방법으로 해석되는 특수 문자가있을 수 있습니다. 또는 "행복한 경로"테스트가 너무 많고 오류 처리를 시도하지 않을 수도 있습니다.

퍼징에는 입력에 대한 선입견이 없습니다. "유효한"입력 조합으로 잔인하게 시스템을 작동시킵니다. 유니 코드, ASCII, 크고 작고 많은 오류가 있습니다. 시스템은 모든 시스템에 정상적으로 응답해야합니다. 절대 충돌하지 않아야합니다. 사용자는 항상 무엇이 잘못되었고 어떻게 고쳐야하는지에 대한 합리적인 메시지를 받아야합니다. 가비지 입력 / 쓰레기 없음, 가비지 입력 / 오차 출력 입니다.

"실제 사용자가 그렇게하지 않기 때문에"폭발로 인한 결과는 사라질 수 있지만, 연습의 요점을 놓치게됩니다. 퍼징은 가능한 입력에 대한 편견을 없애는 저렴한 방법입니다. 사용자가 시스템에서하려고하는 모든 이상한 일을 던질 수있는 저렴한 방법입니다. 엔지니어는 시스템이 정상적으로 작동하지 않는지 확인해야합니다.


더군다나 퍼지 "입력"은 사용자에 관한 것이 아닙니다. 타사 서비스에 대한 API 쿼리의 결과 일 수 있습니다. 엉망인 결과를 보내기 시작하면 어떻게됩니까? 시스템은 어떻게 처리합니까? 적절한 시스템은 관리자에게 구성 요소가 잘못되었음을 경고해야합니다. 부적절한 시스템은 잘못된 쿼리를 자동으로 거부하거나 더 나쁜 데이터로 받아들입니다.

마지막으로 일부 사용자는 악의적입니다. 시스템을 퍼지 테스트하지 않으면 다른 사람이 시스템을 테스트합니다. 그들은 일반적인 실수에 대해 시스템의 가장자리를 조사하고 보안 허점으로 사용하려고 시도합니다. 퍼즈 테스트는이를 어느 정도까지 시뮬레이션 할 수 있으며 문제가되기 전에 발견 된 보안 허점을 처리 할 수 ​​있습니다.


비슷한 기능을 수행 하는 빠른 검사 테스트 도구가 있습니다
icc97

4

양질의 제품을 만드는 것이 목표라면 사용자가 실제로 제출할 수있는 모든 유형의 입력을 테스트하십시오. 그렇지 않으면 누군가가 한 가지 유형의 입력을 제출할 때 하루를 기다리는 것입니다.

내가 일했던 지역 당국에서 새로운 전자 경매 소프트웨어를 시연하는 동안, 상사는 부당한 값으로 경매 입찰에 참여하면 무슨 일이 있었는지 알 필요가 있다고 결정했다. 놀랍게도 경매 소프트웨어는이 무의미한 입찰과 전체 경매 과정을 중단시킬 수있었습니다. 입증되는 경매의 유형은 절대 금액을 제출할 수 없었어야합니다.

다수의 조립 조달 및 재무 책임자 그룹 중 일부는 무의미한 가치를 제출 한 것에 대해 관리자에게 화가났습니다. 그러나 나 자신을 포함한 다른 사람들은 그러한 명백한 유형의 무효 입력을 테스트하고 거부하지 않은 소프트웨어 개발자들에게 짜증을 냈다. 소프트웨어가 다른 유형의 유효하지 않은 입력 (코드 삽입 시도, 데이터베이스 테이블에서 표현할 수없는 이국적인 문자 등)을 변형시키는 데 얼마나 약한 지 상상할 수 있습니다.

그것은 나에게 달려 있었고, 나는 소프트웨어를 반환하고 목적에 맞지 않는 것으로 간주했다. 약한 소프트웨어 제품과 강한 소프트웨어 제품의 차이점은 테스트 수준입니다.


2
test every possible type of input that a user will be physically able to submit.그 문제 공간은 본질적으로 무한하며, 모든 것을 시험해 보면서 시간을 낭비하고 있습니다. 음의 입력을 확인하는 것은 단일 분기입니다. 그것은 현명 할뿐만 아니라 유능한 개발자들에게도 기대됩니다. 이러한 유효성 검사가 작동한다는 것을 증명하기 위해 모든 음수를 확인할 필요는 없습니다.
Robert Harvey

13
이것이 내가 가능한 모든 입력이 아니라 모든 유형 의 입력을 말한 이유 입니다. 그리고 저는 요점을 되풀이하겠습니다. 모든 유형의 입력을 테스트하지 않으면 결국 사용자가 할 것입니다.
Arkanon

1

예를 들면 : 웹 애플리케이션에서 양식의 기능 테스트를 수행하는 동안 다른 종류의 임의의 입력 값을 입력하여 필드를 테스트합니다.

예. 이것은 일종의 테스트 이지만 기능 테스트는 아닙니다 . 이것을 스트레스 테스트 라고 합니다 . 시스템에 압력을 가하여 처리 할 수 ​​있는지 확인하는 작업입니다.

그렇다면 생산에서 이러한 종류의 문제가 나타날 가능성이 적을 때 버그로 이어질 수도 있고 그렇지 않을 수도있는 모든 테스트 케이스를 통합하여 사용하는 것은 무엇입니까?

당신이 때 스트레스 테스트 소프트웨어는 소프트웨어의 한계가 무엇인지의 경계를 발견하기 위해 노력하고 있습니다.

테스트는 본질적으로 철저합니다. 사용 제한, 중단 점을 찾아야하는 경우 모든 논리적 분기를 확인하거나 부분 고장이 전체 시스템에 미치는 영향을 확인하십시오.

모든 기능 테스트는 통과 할 수 있지만 스트레스 테스트는 여전히 실패 합니다 .

표준 관행이 따라야하는지 또는 제품, 도메인 및 기타 모든 요소에 전적으로 의존하는지 여부를 알기 위해서만이 질문을하고 있습니다.

예, 이것은 표준 관행입니다.

소프트웨어 테스트는 예상되는 동작 에 대한 질문을하는 것이며 모든 테스트를 통과하면 소프트웨어가 의도 한대로 작동한다는 것을 나타냅니다. 이것이 업데이트 배포에 대한 사전 조건을 테스트하는 이유입니다.

스트레스 테스트는 명확한 특정 통과 또는 실패 표시기를 제공하지 않습니다. 결과는 더 유익합니다. 시스템에서 처리 할 수있는 내용을 알려주고 해당 정보로 결정을 내립니다.

개발의 다음 단계를 계속하기 위해 통과해야하는 스트레스 테스트의 특정 목표를 정의 할 수 있습니다. 그것들은 품질 보증 프로세스의 일부로 포함될 수 있지만 환경의 변화는 스트레스 테스트의 결과를 바꿀 수 있습니다. 따라서 사람들 은 다른 시간스트레스 테스트 를 실행 하여 시스템이 변화하는 조건을 어떻게 처리하는지 확인합니다.

내 말은 소프트웨어의 새 버전을 배포 할 때마다 스트레스 테스트를 실행할 수 없다는 것입니다. 나중에 모든 것이 스트레스 테스트를 통과한다고 가정합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.