프로그래머에게 테스트가 필요한 이유는 무엇입니까?
다음 몇 가지 수준은 프로그래머가 필요로 하는 방식으로 테스트하는 데 전념할 것입니다 . 그러나 먼저 테스트가 무엇이며 왜 필요한지 알아 봅시다.
소프트웨어와 관련하여 테스트 작업은 프로그램이 다음과 같은지 확인하는 것이라고 말할 수 있습니다.
- 그녀가해야 할 일을
- 그녀는 하지 말아야 할 일을 하지 않는다
그런데 두 번째 요점은 첫 번째 요점보다 중요하지 않지만 나중에 더 중요합니다.
첫 번째 요점부터 시작하겠습니다. "프로그램이 해야 할 일을 합니다"는 무슨 뜻인가요?
먼저 누군가 프로그램의 모든 사용 사례 목록을 작성해야 합니다. 둘째, 프로그램이 어떻게 작동해야 하는지, 사용자가 어떻게 행동해야 하는지, 예상되는 결과는 무엇인지 설명해야 합니다. 더 이상 계속할 수 없습니다.
"사용자가 어떻게 행동해야 하는가"를 작성하자마자 좋은 문서 작성에 대한 전체 아이디어가 무너졌습니다. 사람은 기계가 아니며, 더욱이 사람들은 종종 자신이 원하는 대로 소프트웨어를 사용하여 행동합니다 . 아무도 지침을 연구함으로써 기술에 익숙해지기 시작하지 않습니다. 그것은 사실이다.
따라서 우리는 새로운 사실을 얻습니다. 소프트웨어의 특징은 다양한 작업 시나리오가 있다는 것입니다. 그들 중 일부는 명백하고, 다른 것들은 문서화될 수 있고, 다른 것들은 추측될 수 있고, 다른 것들은 추측될 수 있으며, 나머지 50%는 당신에게 떠오르지 않을 것입니다.
프로그래머의 관점에서 볼 때 대부분의 버그는 전혀 버그가 아닙니다. 오류는 프로그램이 정상적으로 또는 예상대로 작동하지 않는 경우입니다. 그리고 프로그램이 어떻게 작동해야 하는지 명확하지 않거나 서로 모순되는 시나리오가 많은 상황이 있습니다 ...
무한한 수의 시나리오가 있으며 제품에는 프로그램이 예상대로 작동하지 않는 경우가 항상 있을 것입니다(프로그래머는 수십 개의 시나리오에 대해서만 코드를 작성했습니다). 따라서 모든 프로그램에는 항상 버그가 있고 모든 제품은 끝없이 개선될 수 있다고 주장할 수 있습니다 .
그 후에는 모든 것이 편의에 달려 있습니다. 먼저 프로그래머는 가장 큰 버그를 수정한 다음 더 작은 버그를 수정합니다. 그리고 마지막으로 제품 소유자가 계속해서 작업하는 것이 경제적으로 타당하지 않다고 믿는 단계가 옵니다.
그러나 모든 사람이 오류로 인식하는 오류로 돌아가서 프로그램이 분명히 뭔가 잘못하고, 넘어지고, 부러지는 등의 오류가 발생합니다. 이러한 오류는 조건부로 대, 중, 소의 세 가지 범주로 나눌 수 있습니다.
그리고 프로젝트에 여전히 더 심각한 문제가 많이 있지만 프로그래머가 중간 또는 작은 버그를 수정하는 작업을 하는 경우가 매우 많습니다. 그는 그것들을 찾지 못했을 뿐이고 , 그래서 그는 그가 알고 있는 가장 큰 것들에 대해 연구하고 있습니다.
따라서 모든 프로젝트에는 테스터가 있어야 합니다. 이 사람들은 특히 다른 각도에서 제품을 보는 법을 배웁니다. 따라서 프로그램의 더 많은 시나리오를 볼 수 있습니다. 그들의 임무는 오류를 찾아 기록하는 것입니다(동일한 오류를 여러 번 찾지 않도록).
테스트는 오류를 찾는 것을 목표로 하는 프로세스입니다. 이러한 버그를 찾아 설명하고 우선 순위를 지정해야 합니다. 오류의 우선 순위를 지정한 후에야 효과적인 소프트웨어 개선 프로세스에 대해 이야기할 수 있습니다.
문제 해결의 첫 번째 단계는 문제가 있음을 인정하는 것임을 기억하십시오 . 당신이 모르는 실수를 고칠 수는 없습니다.
테스트 자동화
우리 모두 테스트가 중요하다는 데 동의했다고 생각하므로 프로그래머처럼 테스트를 살펴봅시다. 프로그래머는 테스트를 어떻게 봅니까? 프로그래머는 다른 사람의 작업을 자동화합니다. 마지막으로 사라질 직업은 프로그래밍 직업이 될 것입니다.
발생하는 모든 프로세스를 자동화합니다. 따라서 테스트는 자동화되어야 합니다. 오류 검색을 자동화하는 방법은 무엇입니까? 짧은 답변: 아니요. 그러나 여기서 다시 우리가 프로그래머라는 사실이 우리에게 도움이 됩니다.
소프트웨어 개발 프로세스는 지속적인 변경으로 구성됩니다. 끊임없이 변경하는 과정에서 프로그래머는 최근까지 잘 작동했던 것을 깨뜨리는 경우가 많습니다.
그리고 테스터는 새로운 오류를 찾는 대신 오랫동안 잘 작동해 온 무언가를 깨뜨리지 않았는지 지속적으로 확인해야 합니다. 소위 회귀 테스트. 자동화할 수 있고 자동화해야 하는 것은 바로 이러한 유형의 테스트입니다.
여기에서 모든 소프트웨어는 두 부분으로 나눌 수 있습니다.
- 프로그램은 사람과 상호 작용합니다
- 프로그램이 다른 프로그램과 상호 작용
첫 번째 옵션은 자동화하기가 더 어렵고 특수 자동화 테스터가 필요하며 QA 자동화 또는 소프트웨어 테스트 엔지니어라고도 합니다.
그러나 두 번째 옵션은 독립적으로 자동화할 수 있고 자동화해야 합니다. 다음과 같은 소프트웨어가 있는 경우:
- 잘 작동
- 이미 테스트
- 별도의 모듈 또는 논리 블록으로 구현
- 바꿀 계획이 없다
- 다른 모듈이나 프로그램이 이에 의존합니다.
- 기능적 실패는 비용이 많이 듭니다
현재 기능의 주요 측면을 캡처하는 테스트를 작성하는 데 시간을 할애하는 것이 좋습니다. 작업 시간의 5% 또는 한 달에 하루를 할당하는 것이 합리적 입니다 .
테스트를 위해 테스트를 작성할 필요가 없습니다.
아무도 귀하의 테스트를 지원하지 않습니다. 다른 프로그래머도 아니고 당신 자신도 아닙니다. 아무도 그렇게 하지 않습니다. 모든 필기 시험의 99%가 포기 및/또는 비활성화됩니다. 테스트를 작성할 수 없다면 작성하지 마십시오. 그들 없이는 절대 할 수 없는 경우에만 쓰십시오.
테스트 유형
특별한 교육을 받지 않은 각 프로그래머는 자신의 말로 테스트가 무엇인지 말할 수 있습니다. 즉, 프로그램이 제대로 작동하는지 확인하는 것입니다. 그러나 이 분야의 전문가들은 테스트의 전체 영역(유형)을 구분합니다.
모든 테스트는 실제로 소프트웨어의 안정성과 가용성을 중심으로 이루어지지만 테스트의 방향을 더 잘 이해하기 위해 몇 가지 예를 살펴보겠습니다.
일반적인 온라인 상점을 테스트한다고 가정해 보겠습니다. 그런 다음 테스트 영역은 성능 테스트, 기능 테스트, 통합 테스트 및 단위 테스트 유형으로 나눌 수 있습니다.
사이트 소유자가 진지한 광고 캠페인을 시작하기로 결정하면 많은 사용자가 동시에 사이트를 방문하게 됩니다. 사이트가 떨어지지 않을 수도 있지만 일부 섹션이 느리거나 작동을 멈출 수도 있습니다.
이를 방지하기 위해서는 이러한 문제를 사전에 파악하고 이를 제거하기 위한 조치를 취해야 합니다. 이것은 로드 테스트를 사용하여 수행되거나 성능 테스트라고도 합니다.
백엔드 API가 어떻게 작동하는지 테스트하고 모든 기능(등록, 로그인, 장바구니에 추가, 결제 처리, 데이터베이스 쓰기 등)을 테스트하고 싶을 수도 있습니다. 모든 것이 TOR에 따라 작동해야 합니다. 이 경우 기능 테스트를 수행해야 합니다 .
귀하의 온라인 상점은 편지 및 SMS 전송, 결제 시스템, 온라인 지원 채팅, 사용자로부터 피드백 수집, 광고 시스템 등 타사 서비스와 통합되었을 가능성이 큽니다. 이 모든 것이 의도한 대로 작동하는지 확인하려면 통합 테스트가 필요합니다 . .
마지막으로 복잡한 제품은 종종 독립적인 모듈로 분류됩니다. 이러한 모듈에서 생성자에서와 같이 최종 제품을 어셈블할 수 있습니다. 그러한 모듈을 개발하거나 그러한 모듈과 상호 작용하는 경우 단위 테스트를 수행해야 합니다 .
요약하면 사이트의 각 개별 기능을 테스트하려면 기능 테스트가 필요하다고 말할 수 있습니다. 통합 - 제품의 대형 모듈과 시스템의 상호 작용을 테스트합니다. 모듈식 - 별도의 모듈 테스트, 성능 테스트 - 로드 중인 사이트의 작동을 확인합니다.
더 많은 유형의 테스트가 있을 수 있습니다. 제품이 복잡할수록 개발의 더 많은 측면을 제어해야 합니다.