엘에스웨어시스템

현재 메일공유를 통해

   => 1단계) 현 패키지가 이정도 테스트가 됐구나 알림 정도 

   => 2단계) 제가 품질방향 접근에 있어서 부족한 부분들 정리하면서 저 자체적으로 보완 

   => 3단계) 보완된 부분들 정리가 되면 툴로 만들어 자동 운영 단계로 나아갑니다.

[금주 진행한 테스트]

 1) 사전테스트

 2) 부분확인회귀테스트

 3) Resolved된 항목 확인/회귀테스트

 4) 리스크 분석 위험/품질요소를 고려 테스트

[테스트 상세설명]

1) 사전테스트

  - 목      적 : 사전확인항목 (기본기능 또는 그 기능으로 다음 테스트 불가 항목) 중 결함 발생될 경우 재패키지 요청 

  - 진행요일 : 월요일 오전 (패키지 설치 후 빠른 테스트 진행)

                  *월요일 결함 수정 불가능, 재패키지 어려울 시 추후 항목 Resolved된 후 버전 확인 절차 

  - 비     고 : 재패키지 요청 히스토리

                  1/24 (월) 재패키지 요청 - 결과: 지연

2) 부분확인회귀테스트

 - 목     적 : 고객사에서 발생된 critical 항목이 동일하게 발생되지 않겠끔 방어전략 진행

 - 진행요일: 월요일

3) Resolved된 항목 확인테스트

 - 목     적: 살충제 패러독스 현상을 막기 위한 진행

 - 진행요일: 화~수 또는 화~목요일

 - 메일전송내용: 타조직 분들 결함들도 확인하면서 수정/방치된 결함들을 closed 진행(진행예정) 건  2022/01/06 목요일 오전 11:02:12

      기존 테스트케이스를 반복적으로 진행하다보면 살충제 패러독스 현상으로 다양한 결함을 발견하지

      못해 기존 등록되어 있는 결함들 중 Resolved된 항목들 확인(회귀) 진행하기도 하는데요.

      품질자동화 외 분들 결함들도 확인하면서 수정/방치된 결함들을 closed 진행(진행예정)을 했습니다.

      혹시 문제가 되면 말씀해주시면 요청하셨던 분 결함 항목은 제외하고 진행하고,

      항목과 다르게 테스트해서 재현되더라도 너그럽게 이해 부탁드립니다.

      PS) 참고로 VOC는 고객사에서 중요한 요구사항이 포함될 수 있기에 Resolved 장기간 방치된 항목만 확인

           예정입니다.

4) 리스크 분석 위험/품질요소를 고려 테스트

 - 목     적: 장애 발생가능성, 사업영향도 고려 후 기능 선별 후 집중 테스트 진행

 - 진행요일: 무관

1.3 개인정보의 유형 및 종류 
개인정보는 일반적으로 이름, 주민등록번호 등과 같이 일반 정보만으로 이해될 수 있으나. 신체적
정보, 정신적 정보, 재산적 정보, 사회적 정보 등으로 범주화하여 다양한 형태의 정보를 포함할
수 있다. 특히, 정보통신기술의 발달로 인해 개인정보의 보호 대상은 넓어지고 있으며, RFID에 
의한 개인 위치정보, 생체인식 기술과 바이오 정보, CCTV에 의해 수집되는 화상정보 등까지 확대되는
추세이다.


개인정보는 최초 서비스 가입 과정에서 이용자에게 직접적으로 수집하는 정보와 이용자가
서비스를 이용하는 과정에서 생성되는 정보로 나누어 볼 수 있다.

* 이용자가 사업자에게 직접 제공하는 정보
- 사업자 서비스에 회원으로 가입할 때 기입하는 성명, 주소, 이메일, 전화번호,
  생년월일, 성별, 취미, 가족관계, 혼인여부, 출신학교 등

* 서비스를 이용하는 과정에서 생성되는 정보
- 서비스 이용 기록, 접속 로그(log), 쿠키(cookie), 결제 기록, 이용정지 기록,
  페이지뷰 내역, 이용 시간대, 검색 사항, 사이트 방문 내역 등


02. 개인정보 보호의 중요성
 2.2 개인정보 침해 원인 및 유형
  2.2.1 개인정보 침해 정의
정보주체의 개인정보자기결정권에 기하지 않거나 법적 근거 없이 개인정보가 처리되는 등, 개인정보와 관련한 정보주체의 권리를 침해하는 일체의 작위,부작위로 인한 피해를 말한다.
  2.2.2 개인정보 침해 원인 p30
(1) 정보주체 관점에서 발생되는 개인정보 침해 원인
개인
- 개인정보 보호에 대한 인식 부족, 이용자의 부주의로 타인에게 노출 공유
기업
- 타깃 마케팅, CRM 등의 활용하는 기업의 개인정보의 과도한 수집
- 주민등록번호 수집의 관행화, 개인정보의 기술적 보호조치 미흡
정부
- 개인정보 보호 관련 법규 및 제도 마련의 사각지대에서 발생되는 개인정보 침해 원인

(2) 시스템 관점에서 발생되는 침해 원인
PC 등 단말 영역
- 이메일, 메신저, UCC(User Created Contents) 등을 통한 악성코드 감염에 따른 P2P프로그램 설정 오류에 따른 이력서 등 개인정보 유출
네트워크 영역
- 패킷 스니핑(Packet Sniffing), MTM(Man In The Middle) 공격 데이터 변조 및 유출에 따른 라우터 등 주요 네트워크 장비 공격에 따른 개인정보 유출
  및 네트워크 인프라 파괴
서버 및 DB영역
- 서버 및 DB에 저장된 개인정보에 대한 암호화 미비, 패치관리 미흡, 설계 오류, 접근제어 미흡으로 인해 해커 등 접근권한이 없는 자에 의해 고객DB가
  탈취되거나 개인정보가 노출되는 경우

 2.2.4. 개인정보 유출사고에 따른 개인정보 침해 사례 p33
개인정보 유출사고란 생존하는 개인에 관한 정보가 본인 동의 없이 다른 사람에게 노출,악용되어 개인의 안전과 재산에 손실을 초래하는 것을 말한다.
개인정보 유출사고에 따른 개인정보 침해 사례 유형으로 해킹, 내부자 유출, 개인의 관리 소홀 등으로 인하여 발생하게 된다.

(1) 외부해킹 또는 악성코드에 의한 유출
- 외부 해킹이나 악성코드에 의한 유출을 통해 개인컴퓨터 또는 기관,기업 등의 시스템에 침입하여 본인 동의 없이 개인정보를 수집하여 개인정보 유출 및
  침해사고가 발생한다.
(2) 내부자의 의도적 개인정보 유출

Software Testing 사이트들입니다.

​

https://www.javatpoint.com/software-testing-tutorial

https://www.softwaretestingmagazine.com/

https://users.ece.cmu.edu/~koopman/des_s99/sw_testing/

https://www.applause.com/blog/software-testing-life-cycle-stlc-phases

https://www.guru99.com/software-testing-introduction-importance.html (SW 테스팅 사용 이점)

비용 효율성: 소프트웨어 테스팅의 중요한 이점 중 하나. IT 프로젝트를 적시에 테스트하면 장기적으로 비용을 절약하는 데 도움, 소프트웨어 테스팅 초기 단계에서 버그가 잡힐 경우 수정 비용 감소

보안: 소프트웨어 테스트의 가장 취약하고 민감한 이점, 사람들은 신뢰할 수 있는 제품을 탐색, 위험과 문제를 조기에 제거하는 데 도움

제품 품질: 모든 소프트웨어 제품의 필수 요구 사항 테스트를 통해 고품질 제품이 고객에게 전달되는지 확인

고객 만족: 모든 제품의 주요 목표는 고객에게 만족을 제공. UI/UX 테스팅은 최고의 사용자 경험을 보장

블록암호? 기밀성있는 정보를 고정된 크기의 블록단위로 구성하여 암호화 작업을 하는 대칭키 암호 시스템

암호문은 평문의 반복되는 회전 함수로 생산되며 회전함수의 입력은 key와 Output of Previous Round(전 번 회전 출력)으로 구성

이러한 블록암호는 운용방식이 존재하는데 만약 암호화하려하는 데이터가 블록 길이보다 길 경우에는 특정한 운용방식이 사용
ex) ECB / CBC / CTR 등

ECB  (Electronic Codebook)
운용 방식 중 가장 간단한 구조를 가지며, 암호화 작업을 하려는 메세지를 여러 블록으로 나누어 각각 암호화하는 방식

CBC (Cipher-block chaining)
암호 블록 체인 방식은 1976년 IBM에 의해 개발되었으며 각 블록은 암호화 되기 전에 이전 블록의 암호화 결과와
XOR 연산을 수행하며, 첫 블록의 경우 IV(초기화벡터)를 사용. 초기화 벡터의 경우 출력 결과가 항상 동일하기 때문에,
매 암호화마다 다른 IV를 사용

CTR(Counter)
암,복호화 모두 병렬처리가 가능
블록암호 알고리즘의 암호화 로직만 사용
암호문의 한 비트 오류는 복화화되는 평문의 한 비트에만 영향

https://blog.naver.com/jsky10503/221258926405

[RAID]
1. 여러 개의 디스크를 하나로 묶어 하나의 논리적 디스크로 작동한다.
2. 여러 개의 독립된 디스크가 일부 중복된 데이터를 나눠서 저장하고 성능을 향상시키는 기술을 말한다.
3. 레벨에 따라 저장장치의 신뢰성을 높이거나 전체적인 성능을 향상시키는 목적을 만족시킨다.

RAID 0 : 스트라이핑 모드
 - 두 개 이상의 디스크를 사용하여 두 개 이상의 볼륨을 구성한 구조
 - 오류 검출 기능을 없으므로 드라이브에서 장애가 발생하면 데이터는 모두 손실
 - 신뢰성보다는 성능과 용량을 중요시
 
RAID 1 : 미러링 모드
 - 동일한 내용을 갖는 RAID 볼륨을 추가적으로 구성
 - 모든 데이터를 반사 디스크에 복사하고 비교하여 오류를 검사하고 수정할 수 있다.
 - 다른 레벨에 비해 실시간으로 모든 데이터에 대한 복구가 가능하므로 신뢰성이 높다.
 
RAID 2 : 
 - ECC 기능이 없는 드라이브를 위해 해밍오류 정정 코드를 사용
 - RAID 3에 비해 장점이 없어 거의 사용하지 않는다.
 
RAID 3 :
 - 한 드라이브에 패리티 정보를 저장, 나머지 드라이브들 사이에 데이터를 분산 저장한다.
 - RAID 4와 유사하나 분산 저장을 경제적으로 수행하기 위해 하드웨어적인 지원이 요구되며 효율적인 동작을
   위해 동기 가능한 드라이브를 사용
 
RAID 4 :
 - 한 드라이브에 패리티 정보를 저장하고 나머지 드라이브에 데이터를 블록단위로 분산 저장
 
RAID 5 :
 - 모든 패리티 비트를 볼륨에 라운드 로빈 방식으로 분산 저장함으로 패리티 볼륨에 대한 병목 현상을 방지
 
RAID 6 :
 - 이중 분산 패리티 방식

**********
RAID 레벨 0에서 성능 향상을 위해 채택한 기법은 ? 스트라이핑(striping) 기법 
**********

리눅스 데몬 제어

# ntsysv
# setup - 시스템 서비스
어떤 서비스를 자동으로 실행시켜 주겠는 가를 설정하거나 보기

chkconfig를 사용하면 시스템을 부팅할 때 런레벨에 따라 자동으로 실행되는 데몬들을 확인, 추가, 수정

# chkconfig option 데몬 상태
:: option은 
 --level 적용할 런레벨을 선택
 --add 데몬 추가
 --del 데몬 삭제
 --list 현재 데몬들의 목록출력

ex)
# chkconfig --list 
전체나옴 (뒤에 | more 옵션으로 화면나누어 보기 가능)

# chkconfig --list 데몬d
데몬d 데몬에 대해서만 나옴

# chkconfig --level 2345 데몬d on
데몬d가 레벨 2,3,4,5에서 활성화 된다.

service

현재 실행중인 데몬을 제어하려면 service 명령어나
/etc/rc.d/init.d 에 있는 실행스크립트를 이용하여 제어할 수 있다.

# service 데몬 상태
상태는 start ,stop, restart, status 이다.

ex) service 데몬d status
데몬d의 서비스 상태를 보여준다.

----------------------------------------------------------------------------------------------------------------

죽은 데몬 자동 실행

0. 개요
  서버 관리를 하다 보면, 죽으면 안되는 데몬이 갑자기 죽는 경우가 있다. 이럴때 서버 앞에서 작업을 하고 있거나, 모니터링을 하고 있는 경우면 다시 데몬을 띄워 주면 되지만, 그렇지 않은 경우는 죽었는지 살았는지 알지도 못하고, 설령 알고있다고 하더라도 서버로 접속이 가능한 PC를 찾아 움직여야 한다.
  이런 경우를 대비해 데몬이 죽었으면 재 실행 시켜 주는 스크립트를 만들어 보겠다.


1. 준비
  특별히 툴을 설치하거나, 라이브러리를 다운 받는 등의 준비 작업을 없다.
  다만, 약간의 프로그래밍 지식만 있으면 누구나 쉽게 만들 수 있고 또, 쉽게 응용이 가능하다.


2. 스크립트 작성
  예) 아파치 데몬이 죽었을 경우 자동 재 시작

vi /root/check.sh

#!/bin/bash

http="`pgrep http  | wc -l`"

if [ "$http" -eq "0" ] ; then
        /usr/local/apache/bin/apachectl restart
fi

  위 스크립트는 아주 간단하다. http라는 변수에 pgrep http로 아파치 프로세서를 검색 한다음 wc -l로 카운터를 세어 넣는다.
  그리고, if문에서 http변수에 들어 있는 값이 0과 같으면 아파치를 리스타트 한다.


3. 클론에 등록해서 1분마다 체크 하기
  위 스크립트를 만들었다고 해서 끝이 아니다. 왜냐 하면 우리가 원하는 것은 자동을 데몬을 체크해서 그 데몬이 죽었을 경우 해당 데몬을 다시 시작 해주는 것을 원하고 있기 때문이다.
  이럴때 cron을 이용하자, 물론 매 초 체크 하는것은 안되지만, 1분 단위로는 가능하다.

  예) 클론에 1분마다 아파치 데몬이 죽었을 경우 자동 리스타트 되는 스크립트 실행

crontab -e

* * * * * su - root -c '/root/check.sh >&  /dev/null'

  위와 같이 한줄만 추가 해주면 해당 스크립트는 1분마다 실행 되며, 실행 되었을때 아파치 데몬이 죽어 있다면
자동으로 재 시작 한다.
  ps. 클론에 위와 같이 등록 할경우 미리 check.sh 파일의 퍼미션을 700으로 바꿔야 한다.