새로 생성한 계정으로 전환하여 sudo 명령어를 쓰는 경우 sudoers file에 대상이 존재하지 오류가 발생하게 된다.

해결방법은 sudoers file에 보면 root와 같이 ID를 추가해주면 된다.

Ubuntu나 Debian 계열에서 APT 사용시 아래와 같은 오류가 발생할수 있다.

오류 메시지를 해석하자면 잠금설정이 되어있음.

해결방법은 자동 업데이트 작업에 의해 잠금설정이 되었는지 몇 분간 기다리면 해결되며,

똑같은 오류가 발생된다면 잠금파일을 제거하면 금방 해결된다.(나는 한국인이므로 기다리지 않고 제거를 하겠다..)

새로운 자동차가 출시되기 전 설계자가 설계 후 공장에서 제조와 표준화된 안전성 검사를 하여 소비자에게 판매하는 것 처럼,

IT 소프트웨어도 이전 포스팅 과정처럼 요구사항 분석 → 설계 → 개발 → 테스팅의 일반적인 프로젝트를 수행한다.

하지만, 서비스 오픈 후 일반적으로 수년 또는 길게는 수십 년 정도 서비스가 되는데 시스템과 환경은 수정되거나 변경된다.

<자동차도 사용하다 보면 수리를 맡겨야 한다>

서비스 오픈 후 유지보수를 위한 테스팅(Maintenance testing)을 수행해야 하며, 소프트웨어나 시스템이 변경, 단종되거나 마이그레이션될 떄 발생한다. 이때 변경은 개선활동에 의한 변경, 요구사항 변경에 의한 수정과 긴급변경, 환경의 변경 등이 존재한다.

시스템 단종에 의한 유지보수 테스팅은 데이터를 마이그레이션하는 테스팅을 포함할 수 있으며, 시스템에 의한 변경시 원본 소스에 대한 영향이 발생할 수 있기 때문에 리그레션 테스팅도 반드시 고려해야한다. 유지보수 테스팅 범위는 변경사항에 대한 크기와 관련되어 있기에 테스트 유형에 대해 모든 테스트 레벨에서 수행할 수 있다.

• 마이그레이션 : 현재 운영 중인 환경이나 or DB 등 다른 환경으로 옮겨가는 과정(Ex. Mysql → Oracel ..)

V-모델에 따르면 각 개발에 맞는 테스트 레벨이 매칭되어 수행한다고 포스팅을 하였는데

이번에는 테스트 유형별로 테스팅을 수행하는 의미에 대해 포스팅 하고자 한다.

기능 테스팅(Functional Testing)

명칭 그대로 시스템이 제공하는 기능이 제대로 실행되는지 확인하는 테스팅이다. 기능은 포괄적인 의미인데 시스템이 수행하는 그 "무엇"을 의미한다.

기능 테스팅은 문서화되거나 테스터가 알고 있는 기능과 특징, 시스템 상호운용성을 고려하여 수행하며 모든 테스트레벨에서 수행할 수 있다.

명세기반 기법(기획서, 매뉴얼 등)을 활용하여 테스트 조건과 테스트 케이스를 도출하는데 블랙박스 테스팅(Black-Box) 기법의 일종이다.

<블랙박스 테스팅은 시스템의 내부 구조를 블랙박스로 보고 입출력을 확인하는 방법이다>

비기능 테스팅(Non-functional Testing)

비기능 테스팅은 기능 테스팅과 반대의 의미로 비기능 요구사항을 만족하는지 체크하는 테스트인데,

예를 들면, 해당 시스템이 어느정도 성능을 유지하는지? 테스트하는 성능과 같이 시스템이 "어떻게" 동작하는지를 의미한다.

비기능 테스팅 또한 모든 테스트 레벨에서 수행할 수 있으며, 대부분의 목적 달성을 위해 블랙박스 테스트 설계기법을 활용한다.

기능과 비기능테스트의 차이

구조적 테스팅(Structural Testing)

특정 유형의 구조 커버리지를 평가하여 테스팅의 보장성이나 충분함을 측정하는 것으로 시스템 구조나 아치텍처를 점검한다.

명세기간 기법의 블랙박스 테스팅과 달리 시스템 내부 구조를 확인하는 테스트로 구조적 테스팅은 화이트 박스(White-Box) 로도 불린다.

재테스팅/리그레션 테스팅(Re-tesing and Regression Testing)

테스터에 의해 프로그램이 결함이 발견되었다면 개발자에 수정요청을 해야한다.

개발자가 열심히 결함을 제거하고 나서 테스터가 수정여부를 확인하기 위한 테스팅을 재테스팅=확인 테스팅이라고 부른다.

리그레션 테스팅은 테스트된 프로그램의 테스팅을 반복하는 것으로, 개발자가 결함수정을 하였으나 이로 인한 형상 변경으로 인해 다른 기능이 영향이 있는지 ? 혹은 새로운 결함이 발생되는지 여부를 확인하는 절차이다. 보통 기업에서는 개발자가 기능을 추가하거나 수정시 확인 테스팅보다 리그레션 테스팅을 선호하게 된다.

따라서, 리그레션 테스팅은 프로그램 배포전이나 배포 후 동일한 테스팅 절차를 수행하기 때문에 자동화 테스팅에 매우 유용하다!!!!

이전 2.1 소프트웨어 개발 모델 에서 SDLC에 따른 각 개발모델에 주저리 주저리 써보았다.

그 중 V-모델에서 모든 개발단계에 따른 테스트 레벨이 구성되어 있는데 조금더 상세한 정의에 대해 포스팅하고자 한다.

테스트 단계는 어떻게 되는가?

1. 컴포넌트 테스트 : 단위테스트라고도 불리며, 개별적 테스트가 가능한 단위에 대해 테스트를 진행하는 것.

                           우리나라에서 정확한 의미의 단위테스트를 수행하는 곳은 별로 없다고 한다.

2. 통합 테스트 : 컴포넌트(단위)와 컨포넌트(단위) 사이의 인터페이를 테스트 하는 것을 의미한다.

2.1 컴포넌트 통합 테스트 : 한 시스템 내에서 컴포넌트 사이의 상호작용을 테스트

2.2 시스템 통합 테스트 : 시스템과 시스템 즉 다른 시스템 간의 상호작용을 테스트

3. 시스템 테스트 : 프로젝트 차원에서 정의한 전체 시스템 또는 제품의 동작에 대한 테스트를 하는 것이다.

4. 인수 테스트 : 일반적으로 고객사가 요구한 사항대로 동작하는지 테스트를 하는 것이다.

                     따라서, 결함을 찾는 것은 인수테스트의 주 관심사가 아니며 시스템을 배포할 준비가 되었는지 평가한다.

                     위 그래프에서는 마지막 단계로 표기되고 있지만 최종단계의 테스팅이라고 보기 어렵다.

                      (* 대규모 시스텝 통합테스트를 개별 시스템에 대한 이수 테스트 이후 실행할수도 있음)

# 용어정리

 ㄴ 알파환경 : 개발 조직내에서 사용하는 환경

 ㄴ 베타환경 : 실제 환경과 동일한 환경으로 사용자 혹은 잠재 고객을 위한 환경

테스트 단계에 따른 비교정리

소프트웨어 개발 프로세스의 기본 개념 중 하나는 소프트웨어 개발 수명 주기 모델을 의미하는 SDLC 모델이다.

SDLC는 프로젝트가 시작순간부터 시작되는 연속적인 프로세스로, 개발에서 완전히 제거되는 순간부터 종료된다. 

여러개의 개발방법에 따라 SDLC 모델에서 진화하였는데 그 중 장 오래된 폭포수모델(Waterfall Model)에서부터 최근 애자일 모델(Agile Model)까지 다양하다. 어떤 종류의 모델을 선택했든지 간에, 각각의 모델은 모든 소프트웨어 개발 회사에서 사용하는 기본 단계를 가지고 있다. 각각의 SDLC 모델과 차이를 이해하는 것이 중요하므로 각 모델별로 확인해보자.

테스팅에 참여하는 것은 외부에 유출해서는 안되는 기밀정보나 특권정보를 접하게 되는데,

엔지니어를 위한 ACM과 IEEE의 윤리강령을 갖추고 있다고 한다..별로 중요하지는 않는듯..

가볍게 읽고 넘어가도 될 것 같다.

1. 공공성 – 공공의 이익을 위해 행동

2. 고객과 고용주 – 공공의 이익과 부합하면서 고객과 고용주의 이익을 최우선으로 행동

3. 제품 - 제공하는 결과물이 최상의 전무가적 표준을 충족

4. 판단 – 전문적인 판단을 함에 있어서 위상과 독립성을 유지

5. 관리 – 테스트 관리자 및 리더는 SW 테스팅 관리에 대해 윤리적 접근을 취하도록 지지하고 장려

6. 전문성 – 공공의 이익에 부합하는 전문 직업인으로서 위상과 평판을 선도

7. 동료 – 동료에게 공정하고 협조적이며, SW 개발자와 협력을 도모

8. 자기자신 – 테스터의 전문 직업관련 평생학습에 참여하며 직업 관행에 윤리적 접근 방식을 취해야 함

이번 포스팅은 테스터 <> 개발자간의 역할분리에 대한 내용이다.

개발자와 테스터를 분리해야할까? Why..?

개발자도 자신이 만든 코드를 스스로 테스트케이스(TC)를 만들고 테스트 수행에 참여할 수 있다.

하지만, 개발하면서 그에 대한 리소스 투입시간이 말처럼 쉽지가 않다

이에 전문적인 테스트 리소스에 의한 독립적인 시각의 제공 등 추가적인 이점을 얻기 위해서이기도 하다.

<프로젝트 오픈일정이 다가올수록..개발자는 우왕자왕>

이에, 개발자로부터 멀리 멀리 독립적인 테스터일수록 결함과 장애를 찾아내는 데 더 효과적일 수 있게 해준다.

예를 들면 테스팅의 독립성 정도(★)를 오름차순으로 아래와 같이 볼수 있다.

1. 개발자 자신이 테스트 : ★

2. 개발조직 내에 다른사람이 테스트 : ★★

3. 독립적인 테스트 팀과 같은 다른 조직의 일원 혹은 테스터 : ★★★

4. 다른 조직이나 회사(아웃소싱) : ★★★★

개발자가 아닌 다른 테스터에 의해 결함이나 오류 발견시 긍정적으로 의사소통이 되지 않는 다면 감정적으로 변할 수 있어,

현명하게 전달할 수 있는 좋은 대인관계 역시 필요하다.(다투지 말고 사이좋게 지내자..)

전체 테스트과정 중 테스팅을 효율적으로 실행하기 위해 계획..설계 등 활동을 구성해야한다.

논리적으로 순차적이나 테스트 제어는 모니터링으로 간주하여 중복되거나 동시에 발생할수 있기 때문에 주요활동을 조정해야한다.

1. 테스트 계획과 제어 단계

테스트 계획은 테스트 목표와 임무를 달성하기 위해 명세사항을 정의하는 활동이다.(말 그대로 계획하는 단계.)

테스트 제어는 계획대비 진행상황을 비교하는 활동으로 진행상태를 보고하는 것을 포함한다.

2. 테스트 분석과 설계

테스트 분석과 설계는 테스트 조건 및 테스트 케이스(TC)로 변환하는 활동이다.

Ex) 테스트 케이스(TC)

3. 테스트 구현과 실행

테스트 구현과 실행은 테스트 실행을 위해 테스트케이스(TC)를 순서에 따라 결합하여 테스트 프로시저를 명세화하고

테스트 환경 구축 및 테스트를 실행하는 활동이다.

Ex) 테스트 프로시저 = 테스트 케이스(TC) 실행순서

4. 완료 조건의 평가와 보고

말 그래도 테스트가 어느정도 실행되었는지 평가하는 활동..

5. 테스트 마감활동

완료된 테스트 활동에서 데이터를 수집하여 경험과 정보를 활용..혹은 테스트를 통해 얻어진 교훈분석

1.2 테스팅이란 무엇인가? 에서는 테스팅이란 무엇인가..를 보았는데 요약하자면

테스팅 활동은 테스트 전과 후로 나뉘며 결함을 찾아내는것..

그리고 디버깅과의 차이점을 보면 될것 같다.

이번 포스팅은 테스팅의 7가지 원리를 보면 아래와 같다고 한다.

컴퓨터 발명 후 약 40여년간 아래의 원리에 대해 가이드라인 역할을 해오고 있다고 하네요..

원리1 - 테스팅은 결함이 존재함을 밝히는 활동

SW 테스팅에 대해 결함을 찾아 위험을 감소하는데 의미를 두고 있는데..

만약 결함을 못찾는경우!!!

이런 경우라도 SW 결함이 없다고 100% 증명할 수는 없다고 봐야한다.

버그는 반드시 있는법

원리2 - 완벽한 테스팅은 불가능

매우 간단한 SW를 제외하고는 모든 가능성에 대해 테스팅은 불가능에 가깝기 떄문에,

완벽한 테스팅보다는 리스크분석과 우선순위를 토대로 테스팅하는데 집중해야 한다.

원리3 - 테스팅을 개발 초기에 시작

뭐 당연한 이야기이지만 개발 수명주기 중 초기단계에서 테스트 활동을 하면 초기에 결함이 발견하여 위험에 방지 할수 있다.

원리4 - 결함집중

테스팅에 대한 리소스는 SW의 각 모듈별로 추정되는 기능과 차후 관찰된 결함 밀도에 따라 분배해야하는데, 보통 대다수의 결함은 소수 특정 모듈에 집중되어 결함이 발생되는 경우가 많다고 한다.

원리5 - 살충제 패러독스(Pesticide paradox)

살충제 패러독스란 테스트 케이스로 동일한 절차를 반복 수행하면 새로운 결함을 찾을수 없다! 라는 걸 의미한다.

말 그대로 A와 B중 A에 대한 모듈을 100번 반복해서 테스팅을 모두 완료하였다라고 볼수 없으며,

A와 B를 혼합하여..그리고 B에 대한 모듈도 동일하게 테스팅을 해야 잠재적인 결함을 발견 할 수 있다.

따라서 테스트 케이스를 작성한데 이 부분에 대해 고려를 해야한다.

원리6 - 테스팅은 정확(Context)에 의존적

SW 종류에 따라 테스팅도 영향을 받는다.

원리7 - 오류 부재의 궤변

개발이 완료된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용이 없다. 말 그대로 사용하는 사람이 없는데 테스팅을 해보았자 무슨소용이 있는가? 라는 원리이다..