메뉴

애플리케이션을 테스트하기 전에 읽어야 할 20 가지 실용적인 소프트웨어 테스트 팁

top 20 practical software testing tips you should read before testing any application

문제를 제거하기 위해 도구를 사용해보십시오

모든 테스터가이 기사에서 업데이트 된 소프트웨어 테스팅 관행을 읽기를 바랍니다. . 각 요점을주의 깊게 읽고 일상적인 테스트 활동에서 구현해보십시오. 이것이이 기사를 통해 독자들에게 기대하는 것입니다. 테스트 연습을 이해하지 못한다면 아래 댓글 섹션에서 더 자세한 설명을 요청하십시오.

그러나 경험을 통해 이러한 모든 테스트 방법을 배우게됩니다. 하지만 실수하기 전에이 모든 것을 배우는 것이 어떻습니까?

와서 살펴 보자 그들!

실용적인 소프트웨어 테스트 팁

경험을 통해 배운 모범 테스트 사례는 다음과 같습니다.

소프트웨어 개발 라이프 사이클의 단계는 무엇입니까

#1) 테스트 결과를 철저히 분석하는 방법을 배우십시오. 테스트 결과를 무시하지 마십시오. 최종 테스트 결과는 '통과'또는 '실패'일 수 있지만 '실패'의 근본 원인을 해결하면 문제에 대한 해결책을 얻을 수 있습니다. 테스터는 기록 만하는 것이 아니라면 존경받을 것입니다. 버그 솔루션도 제공합니다.

#두) 최대화하는 방법 배우기 테스트 범위 응용 프로그램을 테스트 할 때마다. 100 % 테스트 커버리지는 불가능할 수 있지만, 항상 가까운 곳에 도달 할 수 있습니다.

#삼) 최대 테스트 범위를 보장하기 위해 AUT (Application Under Test)를 더 작은 기능 모듈로 나눕니다. 이러한 개별 단위 모듈에 대한 테스트 케이스를 작성하십시오. 또한 가능하면 이러한 모듈을 더 작은 부분으로 나누십시오.
예를 들어, 웹 사이트 애플리케이션을 모듈로 나누고 '사용자 정보 허용'이 모듈 중 하나라고 가정 해 보겠습니다. 이 '사용자 정보'화면을 테스트 케이스 작성을 위해 작은 부분으로 나눌 수 있습니다. UI 테스트와 같은 부분, 보안 테스트 , 기능 테스트 '사용자 정보'양식 등

모든 양식 필드 유형 및 크기 테스트, 네거티브 및 유효성 검사 테스트를 입력 필드에 적용하고 이러한 모든 테스트 케이스를 작성하여 최대 범위를 확보하십시오.

# 4) 동안 테스트 케이스 작성 , 의도 한 기능에 대한 테스트 케이스를 먼저 작성하십시오. 그런 다음 유효하지 않은 조건에 대한 테스트 케이스를 작성하십시오. 여기에는 테스트중인 애플리케이션의 예상되는 동작과 예상치 못한 동작이 포함됩니다.

# 5) 긍정적으로 생각하십시오. 버그 / 오류를 찾기 위해 애플리케이션 테스트를 시작합니다. 응용 프로그램에 버그가 없을 것이라고 미리 생각하지 마십시오. 버그를 찾을 의도로 애플리케이션을 테스트한다면 확실히 성공할 것입니다. 미묘한 버그 또한.

# 6) 요구 사항 분석 및 설계 단계 자체에서 테스트 사례를 작성하십시오. 이렇게하면 모든 요구 사항을 테스트 할 수 있습니다.

# 7) 너의 ~을 만들어라 코딩 전에 개발자가 사용할 수있는 테스트 케이스. 더 많은 버그를 기록 할 수 있다고 생각하면서 테스트를위한 최종 애플리케이션 출시를 기다리는 동안 테스트 케이스를 보관하지 마세요. 개발자가 테스트 케이스를 철저히 분석하여 양질의 애플리케이션을 개발하도록하십시오. 이렇게하면 재 작업 시간도 절약됩니다.

# 8) 가능한 경우 식별하고 테스트 케이스 그룹화 회귀 테스트 . 이렇게하면 빠르고 효과적인 수동 회귀 테스트가 보장됩니다.

# 9) 중요한 응답 시간이 필요한 애플리케이션의 성능을 철저히 테스트해야합니다. 성능 시험 많은 응용 프로그램에서 중요한 부분입니다. 에 안내서 테스트, 이것은 성능 테스트에서 필요한 대용량 데이터가 부족하기 때문에 테스터가 가장 무시하는 부분입니다.

애플리케이션의 성능을 테스트하는 방법을 알아보십시오. 테스트 데이터를 수동으로 생성 할 수없는 경우 몇 가지 기본 스크립트를 작성하여 성능 테스트를위한 테스트 데이터를 생성하거나 개발자에게 직접 작성하도록 요청하십시오.

# 10) 프로그래머는 자신의 코드를 테스트해서는 안됩니다. 우리의 이전 게시물 , 개발 된 애플리케이션의 기본 단위 테스트는 개발자가 테스터 용 애플리케이션을 출시하기에 충분해야합니다. 그러나 귀하 (테스터)는 개발자에게 테스트를 위해 제품을 출시하도록 강요해서는 안됩니다.

그들 자신의 시간을 가지게하십시오. 리드에서 관리자에 이르는 모든 사람은 테스트를 위해 모듈 / 업데이트가 릴리스되는시기를 알고 있으며 그에 따라 테스트 시간을 예측할 수 있습니다. 이것은 전형적인 상황입니다 기민한 프로젝트 환경.

Windows 7 용 무료 정크 파일 클리너

# 11) 요구 사항 테스트를 넘어서십시오. 하지 말아야 할 작업에 대해 응용 프로그램을 테스트합니다.

# 12) 회귀 테스트를하는 동안 이전 버그 그래프 사용 (버그 그래프 – 다른 모듈의 시간에 대해 발견 된 버그 수). 이 모듈 별 버그 그래프는 응용 프로그램에서 가장 가능성이 높은 버그 부분을 예측하는 데 유용 할 수 있습니다.

# 13) 테스트하는 동안 배운 새로운 용어, 개념을 기록해 둡니다. 응용 프로그램을 테스트하는 동안 텍스트 파일을 열어 둡니다. 테스트 진행 상황 및 관찰 내용을 기록합니다. 그것에. 최종 테스트 릴리스 보고서를 준비하는 동안 이러한 메모장 관찰을 사용하십시오. 이 좋은 습관은 완전한 모호하지 않은 테스트 보고서 및 릴리스 세부 정보를 제공하는 데 도움이됩니다.

# 14) 테스터 또는 개발자는 테스트중인 애플리케이션의 코드베이스를 여러 번 변경합니다. 이것은 은행 프로젝트에서와 같이 실시간 거래 처리의 실행을 피하기 위해 개발 또는 테스트 환경에서 필요한 단계입니다.

테스트 목적으로 수행 된 모든 코드 변경 사항을 기록해 둡니다. 최종 릴리스시 최종 클라이언트 측 배포 파일 리소스에서 이러한 모든 변경 사항을 제거했는지 확인하십시오.

# 15) 개발자를 테스트 환경에서 멀리하십시오. 릴리스 또는 배포 문서에서 누락 된 구성 변경 사항을 감지하는 단계가 필요합니다. 때때로 개발자는 일부 시스템 또는 애플리케이션 구성 변경을 수행하지만 배포 단계에서 언급하는 것을 잊습니다.

개발자가 테스트 환경에 액세스 할 수없는 경우 실수로 테스트 환경에서 그러한 변경을 수행하지 않으며 이러한 누락 된 사항을 올바른 위치에서 캡처 할 수 있습니다.

# 16) 다음을 수행하는 것이 좋습니다. 소프트웨어 요구 사항 및 설계 단계 자체부터 테스터를 참여시킵니다. 이러한 방식으로 테스터는 애플리케이션 신뢰성에 대한 지식을 얻을 수있어 세부적인 테스트 범위를 얻을 수 있습니다. 이 개발주기에 참여하도록 요청받지 않은 경우 리드 또는 관리자에게 모든 의사 결정 프로세스 또는 회의에 테스트 팀을 참여시킬 것을 요청할 수 있습니다.

# 17) 테스트 팀은 모범 테스트 사례 공유 , 조직의 다른 팀과의 경험.

# 18) 개발자와의 대화 늘리기 제품에 대해 더 많이 알 수 있습니다. 가능할 때마다 신속하게 분쟁을 해결하고 오해를 피하기 위해 대면 커뮤니케이션을하십시오.

또한 요구 사항을 이해하거나 분쟁을 해결할 때 이메일과 같이 덮어 쓰여진 통신 방식으로 전달해야합니다. 어떤 것도 구두로 유지하지 마십시오.

# 19) 뛰지 마세요 시간 중 우선 순위가 높은 테스트 작업을 수행합니다. 높은 우선 순위에서 낮은 우선 순위로 테스트 작업의 우선 순위를 정하고 그에 따라 작업을 계획하십시오. 모든 관련 위험을 분석하여 작업의 우선 순위를 지정하십시오.

# 20) 명확하고 설명 적이며 모호하지 않은 작성 버그 신고 . 버그 증상을 제공 할뿐만 아니라 버그의 영향과 가능한 모든 솔루션을 제공하십시오.

테스트는 창의적이고 도전적인 작업이라는 것을 잊지 마십시오. 마지막으로, 모든 것은이 도전을 어떻게 처리하는지에 대한 당신의 기술과 경험에 달려 있습니다.

너에게 :

아래 의견에 자신의 테스트 경험, 팁 또는 테스트 비밀을 공유하면이 기사가 더 흥미롭고 도움이 될 것입니다!

당신의 생각을 알려주세요 / 제안 이 기사에 대해.

추천 도서

^