개요

화면 녹화 동영상 만드는 방법을 설명한다.

동영상은 화면 녹화 프로그램 & 동영상 편집 프로그램 이렇게 2개의 프로그램이 필요하다. 2개가 동시에 가능한 프로그램도 있지만 보통 유료 프로그램이다.

유료 프로그램은 보통 일부 기능만 무료로 제공하고 동영상을 만들고 나면 워터마크가 생겨서 만든 후에 보기 안좋은 경우가 많이 생긴다.  

그래서 유료 프로그램을 결제해서 편하게 사용하거나 아래와 같이 2개의 오픈소스 프로그램을 활용한다. 

화면 녹화: OBS Studio

1. 하단 메뉴의 소스 목록에서 + 버튼을 누른 후 디스플레이 캡쳐 메뉴를 선택한다.

2. 이름은 마음대로 입력 후 확인 버튼을 클릭한다.
3. 화면을 녹화할 디스플레이를 선택 후 커서 캡쳐는 체크를 해제(필요 시에는 체크)하고 확인 버튼을 클릭한다.
4. 하단 항목에서 효과 버튼을 클릭한다.
5. 필터 창에서 + 버튼을 클릭 후 메뉴에서 자르기/덧대기를 선택한다
6. 필터 이름은 마음대로 지정한다.
7. 상,하,좌,우 숫자값을 입력하여 녹화 영역을 녹화하고자 하는 프로그램 영역으로 축소시킨후 닫기 버튼을 클릭한다. 숫자값 입력에 따라 영역 설정이 표시되므로 어렵지 않다.
8. 프로그램 처음 실행 시 기본설정으로 했던 옵션 값을 수정한다. 우측 하단에서 설정 메뉴를 클릭 → 팝업 창에서 비디오 항목 선택 → 출력 해상도를 캔버스 해상도와 동일하게 설정한다.

9. 화질이 마음에 안드는 경우에는 설정 → 출력 메뉴에서 아래와 같이 화질 옵션을 조절한다. 원본으로 하면 파일이 너무 커지기 때문에 아래 옵션이 적절하다.
10. 녹화 시작 및 중지는 우측 하단의 제어 메뉴에서 한다. 녹화 시작 버튼을 클릭 시 녹화가 시작되며 녹화를 종료하려면 녹화 종료 버튼을 클릭하고 이때 mkv 확장자의 동영상 파일이 생성된다.
11. 녹화 파일은 위 캡쳐의 설정 → 출력 메뉴에서 지정되어 있는 녹화 경로에 저장되어 있다. 기본 경로는 내 PC → 동영상이다.

동영상 편집: Shotcut

  1. 실행 후 편집할 파일을 불러오기
  2. 동영상을 아래의 타임라인 영역으로 드래그 앤 드롭
  3. 타임영역에서 자를 영역을 설정 
    1. 자르기 시작할 곳으로 커서를 이동한 후 s키를 입력 → 자르기를 종료할 곳으로 커서를 이동한 후 s키를 입력
    2. 자르기를 2번 해서 동영상이 1 2 3 으로 나눠진 상태이며 우리는 2를 삭제후 1 3 이런식으로 배치하면 2구역이 잘라져서 편집이 되는 것이다.
    3. 주로 대기 상태에서 아무 동작을 하지 않는 시간을 잘라낸다.
  4. 잘라낸 동영상을 파일 내보내기로 저장한다.
  5. 보다 자세한 방법은 아래의 동영상이나 사용 매뉴얼을 참조한다.

shotcut사용법.mp4
3.63MB

설명

검침 데이터 CSV 파일의 데이터를 그래프로 출력하는 간단한 코드다.

Python의 matplotlib 라이브러리를 사용한다. 

검침 데이터는 누적값이므로 부하가 있는 미터는 시간이 증가함에 따라 값이 증가하는 정비례 모양의 그래프가 그려진다.

그래프의 모양이 정비례가 아니거나 이상한 모양으로 나타난다면 기록된 값을 체크하는 용도로 활용이 가능하다.

예제 파일은 이전 예제에 첨부된 파일을 그대로 사용한다.

소스 코드

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
 
pd.set_option('display.max_columns', None)
pd.set_option('display.max_rows', None)
df = pd.read_csv("AEtype_LP.csv")
mid = df[" Meter ID"].unique() # 중복되지 않는 미터ID를 추출
 
for i in mid:
    d_ = df[(df[" Meter ID"] == i) & (df[" CTime"].str[11:] == "12:00:00")] # 미터번호와 시간이 12:00인 값으로 df를 추출
    plt.figure(figsize=(7,7)) # 그래프의 크기
    plt.plot(d_[" CTime"], d_[" FAP"], 'bo-', label = str(i)) # CTime이 x축, FAP가 y축이 되고 Label에는 미터번호를 출력하는 그래프를 그린다.
    plt.xticks(rotation=90) # X축의 label을 90도 회전시킴
    plt.legend(fontsize=13) # 미터번호 Label 출력할 폰트 크기
    plt.grid() # 그래프에 격자를 표시

 

실행 결과

아래와 같이 그래프가 그려진다. 데이터는 누적값이므로 그래프가 정방향 함수의 모양이 아닌 경우 데이터가 잘못되었다고 판단한다. 미터 1대만 첨부했고 나머지 미터도 그래프의 모양이 비슷하게 출력된다.

설명

시간이 지날수록 데이터가 쌓이는 시계열 데이터의 경우 데이터 개수를 파악하는 것이 중요한데 수동으로 일일이 하려면 시간이 오래 걸린다. 

이 파일은 대표적인 시계열 데이터로 전력량계의 검침값이 저장된 CSV 파일을 날짜별로 데이터 개수를 필터링해서 확인하는 간단한 코드다. 

Python의 pandas 라이브러리를 사용하여 구현했으며 Jupyter나 Google colab으로 실행이 가능하다. 

구현 코드만 이해할 수 있다면 Column 정보만 수정하여 다른 형식의 CSV 파일에서도 사용이 가능하다.

예제 CSV 파일

  • 데이터 수: 약 5300개
  • 미터 수: 9대
  • 날짜: 7일

AEtype_LP.csv
0.90MB

 

코드

import pandas as pd
from pandas import DataFrame
import numpy as np
import matplotlib.pyplot as plt
 
df = pd.read_csv("AEtype_LP.csv")
pd.set_option('display.max_columns', None)
pd.set_option('display.max_rows', None)
df2 = df[ [" Meter ID", " ITime", " CTime", " FAP", " LARAP", " LERAP", " AP"] ]
mid = df[" Meter ID"].unique() #미터 ID의 집합 (중복 항목을 제거하여 미터 수를 추출함)
ctime1 = df[" CTime"].str[:10].unique() # 날짜의 집합 (뒤에 시간값을 제거하여 날짜만 추출함)
cols = 3 #미터ID,날짜,데이터 수
rows = mid.size * ctime1.size #미터수 * 날짜수
arr = [[0 for j in range(cols)] for i in range(rows)] #배열을 생성
a = 0 # 행번호의 초기값
 
for i in mid: # 미터수만큼 반복
    mid1 = i
    for j in range(0, ctime1.size): # 날짜수만큼 반복
        mid2 = df2[" Meter ID"] == mid1
        ctime2 = df2[" CTime"].str.contains(ctime1[j]) #해당 날짜가 포함된 데이터를 검색
        ctime3 = df2[ctime2] #해당 날짜의 데이터를 저장하기위한 변수
        cnt1 = df2[mid2 & ctime2].shape[0] #해당 미터 ID의 해당 날짜의 데이터 개수를 센다
        #print(mid1, ctime1[j], cnt1)
        arr [a][0] = mid1
        arr [a][1] = ctime1[j]
        arr [a][2] = cnt1
        a = a+1
col_name1 = ["Meter ID","Date","Data Count"] # dataframe 변환시 Column의 name
ds = pd.DataFrame(arr, columns=col_name1) # 배열을 dataframe으로 변환
ds

실행결과

아래와 같이 배열을 표 형태로 출력한다. 이 결과를 통해 날짜별로 어떤 미터의 데이터가 누락되었는지 판단할 수 있다.

Meter ID Date Data count
8190005804 2021-02-25 55
8190005804 2021-02-26 100
8190005804 2021-02-27 99
8190005804 2021-02-28 100
8190005804 2021-03-01 99
8190005804 2021-03-02 101
8190005804 2021-03-03 37
8190000105 2021-02-25 55
8190000105 2021-02-26 100
8190000105 2021-02-27 99
8190000105 2021-02-28 100
8190000105 2021-03-01 99
8190000105 2021-03-02 101
8190000105 2021-03-03 37
24190005408 2021-02-25 55
24190005408 2021-02-26 100
24190005408 2021-02-27 99
24190005408 2021-02-28 100
24190005408 2021-03-01 99
24190005408 2021-03-02 101
24190005408 2021-03-03 37
24190005412 2021-02-25 55
24190005412 2021-02-26 100
24190005412 2021-02-27 99
24190005412 2021-02-28 100
24190005412 2021-03-01 99
24190005412 2021-03-02 101
24190005412 2021-03-03 37
24190005413 2021-02-25 55
24190005413 2021-02-26 100
24190005413 2021-02-27 99
24190005413 2021-02-28 129
24190005413 2021-03-01 99
24190005413 2021-03-02 101
24190005413 2021-03-03 37
54190000117 2021-02-25 56
54190000117 2021-02-26 100
54190000117 2021-02-27 99
54190000117 2021-02-28 100
54190000117 2021-03-01 99
54190000117 2021-03-02 102
54190000117 2021-03-03 37
54190000120 2021-02-25 55
54190000120 2021-02-26 100
54190000120 2021-02-27 99
54190000120 2021-02-28 100
54190000120 2021-03-01 99
54190000120 2021-03-02 101
54190000120 2021-03-03 37
24190000132 2021-02-25 55
24190000132 2021-02-26 100
24190000132 2021-02-27 99
24190000132 2021-02-28 100
24190000132 2021-03-01 99
24190000132 2021-03-02 101
24190000132 2021-03-03 37
8190005797 2021-02-25 55
8190005797 2021-02-26 100
8190005797 2021-02-27 99
8190005797 2021-02-28 100
8190005797 2021-03-01 99
8190005797 2021-03-02 101
8190005797 2021-03-03 37

 

설명

Jenkins는 대표적인 CI 툴이며 Git은 형상관리 시스템이다. 이 두가지 툴과 Jmeter 파일을 연동하여 관리하는 방법에 대한 외부 링크 문서 모음이다.

Jmeter에서 생성하고 저장한 jmx 파일을 Git을 통해 관리한다. 

  • Git Repository: Github or Bitbucket
  • Git GUI 관리도구: Sourcetree
  • CI 도구:  Jenkins

링크 자료

하나의 문서로 작성하기에는 내용이 너무 방대하여 각각의 설정 및 내용에 대한 문서를 참조 링크로 대체한다. 순서대로 따라한다면 큰 문제없이 연동환경 구성이 가능하다.

저장소는 Bitbucket이나 Github 중 편한 것을 사용하면 되고 연구 목적이라면 두 가지 모두 사용해봐도 무방하다. 

실행 결과

연동 환경이 구성된 후 실행 결과는 아래와 같다.

'테스트 자동화 > Jmeter' 카테고리의 다른 글

Jmeter 기본 사용법  (0) 2022.04.04
Jmeter 소개 및 설치  (0) 2022.04.04

설명

프로세스가 실행중인지 체크하고 실행되고 있지 않으면 정해진 주소로 이메일을 전송한다.

24시간 실행되어야 하는 서버용 에뮬레이터 Windows 프로그램에서 활용했다. 실행만 잘 시켜놓으면 되는거 아니냐고 할 수 있지만 뜻밖의 변수들 (윈도우즈 업데이트, 갑작스런 재부팅, 프로그램 자체의 오류)이 많이 발생하여 그런 변수들에 대응하고자 만들었다. 

해외에 공개된 이메일 전송 소스에 프로세스의 실행체크하는 부분만 연계하여 만들었다. 

이 프로그램을 시작 프로그램에 등록하면 PC가 재부팅되어도 자동 실행되므로 편하다.

 

소스코드

ProcessCheck1.au3
0.01MB

사용법

  1. 첨부한 소스코드에서 아래의 E-mail 설정란에 정보를 입력 (Google, naver 등의 smtp 서버 설정 사용)
  2. 감시할 프로세스 이름을 설정: 이 소스에서는 Server.exe로 입력되어 있음

  3. 소스 컴파일 후 실행 파일을 시작 프로그램에 등록: 등록방법은 https://mudnji.tistory.com/474 참조
  4. 체크 간격은 기본 2시간이며 이 간격을 수정하고 싶다면 While 문 안의 두번째 Sleep(6900000) 에서 괄호안의 시간을 수정
  5. 실제 전송된 이메일 예

'테스트 자동화 > Autoit' 카테고리의 다른 글

Autoit script  (0) 2022.04.04

설명

실무에서 사용하던 품질시험 의뢰 규칙이다. 개발팀에서 개발 완료 후에 테스트를 요청할 때 작성하는 공식 문서의 양식이 되어 활용했다. 기존에는 일부 개발팀만 알고 진행하는 업무였지만 전체적인 내용을 문서로 작성하고 배포하여 정식으로 사내의 프로세스가 되었다.

이 규칙은 품질시험에 대한 프로세스가 고민되는 경우 참고할 수 있는 하나의 방안이다.

품질시험 의뢰 규칙

  1. 의뢰 방법: 개발자는 제품의 개발이 완료된 후 Confluence Test request 페이지에서 해당 연도를 선택한 후 품질시험 평가 의뢰서를 작성한다. 
  2. 작성 항목: 포함되어야 할 필수 항목은 아래와 같다. (공통 + 각 제품에 맞는 항목 작성)
    1. 공통 (모든 품질시험 의뢰에 포함)
      1. 시험 의뢰자, 시험의뢰 날짜
      2. 개발 제품의 변경사항이 기록된 개발 릴리즈 문서
        1. 개발 릴리즈 문서에는  반드시 수정된 Jira의 이슈번호와 제목을 포함시켜야 한다.
        2. Jira의 이슈번호 없이 설명만 기술된 문서만 전달하고 방치하는 경우에 품질시험 의뢰는 거절 처리된다.
      3. 개발자의 단위 테스트 결과 체크리스트 문서
        • 단위 테스트를 수행한 항목에는 O로 표시하고 실행하지 않은 항목은 공란으로 둔다.
        • 예시 문서: 예시 문서 첨부
      4. 기능 요구사항 문서: ex) 구매 규격서 or SRS 문서 or RFP 문서
      5. 기능에 대한 설명 및 테스트 방법 
        • 개발자가 작성한 테스트케이스 목록 excel 파일을 제공하거나 Jira xray에 직접 테스트케이스를 작성하는 방식으로 전달
      6. 버전 정보 

    2. 펌웨어
      • 펌웨어 파일
      • 펌웨어 테스트에 필요한 정보
        • 시험 의뢰 제품의 Hardware 모델 정보
        • 테스트 환경 구성 방법
        • 연동 서버 정보
          • 서버 주소 및 로그인 정보
          • 에뮬레이터의 경우 에뮬레이터 설치 파일 및 매뉴얼
    3.  웹 서비스
      • 시험 대상의 웹 주소
      • 웹 서비스 테스트에 필요한 정보
        • 웹 서비스 로그인 정보
        • 웹 서비스를 테스트하기 위해 알아야 하는 순서나 흐름에 대한 정보
        • 연동 제품이 있는 경우 연동 제품에 대한 정보
        • 웹 API 정보

    4. 모바일 App
      • 설치 파일 (APK 또는 파일을 받을 수 있는 주소)
      • 모바일 App 테스트에 필요한 정보
        • App 로그인 정보
        • 모바일 App 테스트를 수행하기 위해 알아야 하는 순서나 흐름에 대한 정보
        • 웹 연동을 하는 서비스 App의 경우 연동되는 웹에 대한 정보

  3. 진행 절차: 개발자는 의뢰서를 작성한 후 메일로 품질시험 담당자 및 업무 관련자에게 공지하며 품질시험 담당자는 품질시험 의뢰서를 검토하고 검토 결과에 따라 Result 항목의 상태를 변경한다. 
    • 접수: 의뢰서가 정상적으로 작성되어 테스트를 대기하는 상태
    • 거절: 필수 항목이 누락되거나 정보가 부족하여 테스트를 시작할 수 없는 상태
    • 보류: 다른 테스트 일정이나 리소스 부족으로 가까운 시일 내에 테스트 진행이 불가능한 경우

      전체적인 흐름은 아래와 같다.
     

  • 시험 의뢰서에 필수 항목이 누락되거나 테스트에 필요한 정보가 부족한 경우 품질 담당자는 추가적인 자료의 제공을 시험 의뢰자에게 요청해야 하며 시험 의뢰자는 요청에 따라 정확한 자료와 정보를 제공해야 한다.
  • 자료 및 정보 제공 요청을 했음에도 시험 의뢰자가 대응을 하지 않아서 테스트가 어려운 경우 품질 담당자는 시험 의뢰를 거절처리하고 시험 의뢰자 및 상위 관리자에게 시험 의뢰 거절 사유를 전달한다.
    • 품질시험 의뢰가 거절처리된 경우 당일에 재의뢰하는 것은 금지하며 다음날부터 다시 재의뢰가 가능하다.
    • 당일 재의뢰를 금지하는 이유는 자료 누락에 의한 습관적인 재의뢰를 막기 위함이다.

제품 버전관리 규칙

QA 업무를 하면서 개발하는 제품군이 많은데 버전관리 규칙이 없이 개발 버전, 테스트 버전 구분도 잘 안되고 혼란스러운 경우를 많이 보았다.

보통은 3 ~ 4 자리 소수점을 많이 사용하는데 자리수는 크게 상관없고 일관된 기준만 있으면 된다.

일관된 하나의 규칙 또는 통일이 어려운 경우 제품군마다 별도의 규칙을 정해서 관리해야 한다. 아래는 하나의 예시이다.

버전 관리 규칙의 예

  • Version + Build 의 의미이며 앞자리 V, B 문자를 축약하여 뒤에 숫자를 붙여서 사용하고 대소문자는 구분하지 않는다.
    • Version은 소수점 1자리 (메이저 버전 + 마이너 버전) Build는 정수 2자리로 표기하며 빌드 횟수에 따라 자릿수는 확장될 수 있다.
    • Version은 V1.0부터 시작하고 Build는 01부터 시작한다. 
      • ex) 최초 빌드 버전 → V1.0 B01 
    • 아래와 같은 양식으로 사용이 가능하다. 
      • V1.0 B01  → V + 버전 (소수) + B + 빌드번호
      • V1.0 Build 01 → V + 버전 (소수)+ Build + 빌드번호
      • V10 B01, V10 Build 01 → V + 버전 (정수) + B + 빌드번호  :  소수점 입력이 어려운 환경의 경우 정수로 붙여서 표현한다.
  • 버전과 빌드 날짜를 설치 파일명에 포함시켜서 다른 버전과 구분할 수 있어야 한다.
    • ex) ProjectA_V10B05_2022-05-25.bin :  Version 1.0에 Build 05 이며 2022년 5월 25일에 빌드됨
  • 메이저 버전은 제품의 큰 변화가 있을 경우에 증가한다. ex) OS 변경, 내부 모듈 구조변경 등
  • 마이너 버전은 제품의 일부 기능이 추가되거나 변경된 경우 증가한다. ex) Watchdog 기능 추가, 로그 Lotate 기능 추가 등
  • 빌드번호는 일반적인 Bugfix 시 증가한다.
  • 사이트에서 사업적인 목적을 위해 특별한 요청이 있는 경우에는 예외적으로 위 규칙과 다른 규칙으로 버전을 생성할 수 있으나 반드시 QA팀의 승인을 받고 별도로 기록해서 구분해야 한다.

개요

소프트웨어의 품질은 한마디로 정의하기 어렵다. IEEE는 소프트웨어의 품질을 다양한 이해 관계자의  명시적이고 암묵적인 요구사항을 충족시킬 수 있는 소프트웨어의 기능 및 특성이라고 정의한다.

품질 모델은 제품 품질 평가 시스템의 초석이며, 소프트웨어 제품의 속성을 평가할 때 고려해야 할 품질 특성을 결정한다.

ISO 25010에 정의된 제품 품질 모델은 아래와 같이 8가지 주특성과 하위 부특성으로 구성된다.

ISO 25010의 주특성 및 부특성에 대한 설명

주특성 부특성 설명
기능성 기능 성숙도 기능 집합이 지정된 요구사항을 만족하는 정도
기능 정확성 제품 또는 시스템이 필요한 정밀도로 정확한 결과를 제공하는 정도
기능 타당성 기능이 특정 업무 및 목표 달성을 용이하게 하는 정도
효율성 시간 반응성 기능 수행 시 제품 또는 시스템의 응답 및 처리 시간, 처리속도가 요구 사항을 충족하는 정도
자원 활용성 기능 수행 시 제품 또는 시스템에서 사용하는 자원의 양과 유형이 요구 사항을 충족하는 정도
기억 용량 제품 또는 시스템 매개 변수(최근 사용자 수, 통신 대역폭, 데이터 베이스 저장 용량 등)의 최대 한도가 요구 사항을 충족하는 정도
호환성 공존성 다른 제품에 해로운 영향을 미치지 않고 환경 및 자원을 공유하면서 요구된 기능을 효과적으로 수행하는 정도
상호 운용성 둘 이상의 시스템, 제품 또는 구성 요소가 정보를 교환하고 교환된 정보를 사용할 수 있는 정도
사용성 타당성 식별도 제품이나 시스템이 자신의 필요에 적합한지 여부를 사용자가 인식할 수 있는 정도
학습성 사용자가 제품이나 시스템의 사용법을 배워서 명시된 목적을 달성할 수 있는 정도
운용성 제품 또는 시스템의 작동 및 제어를 쉽게 할 수 있는 정도
사용자 오류 보호 시스템이 사용자를 오류로부터 보호하는 정도
사용자 인터페이스 미학 사용자 인터페이스가 사용자에게 만족스러운 정도
접근성 연령과 장애에 관계없이 시스템을 사용할 수 있는 정도
신뢰성 성숙성 시스템이 정상 작동 상태에서의 신뢰성에 대한 필요성을 충족시키는 정도
가용성 사용이 요구되는 시기에 제품 또는 구성요소의 사용 및 접근이 가능한 정도
결점 완화 시스템 또는 제품의 구성요소가 하드웨어 또는 소프트웨어의 결함이 존재하더라도 이를 극복하고 의도한 대로 동작해야 함
회복 가능성 중단 또는 실패가 발생하는 경우 제품 또는 시스템이 영향을 받는 데이터를 직접 복구하고 시스템의 원하는 정도를 다시 설정할 수 있는 정도
보안성 기밀성 제품 또는 시스템이 접근 권한이 있는 사람에게만 데이터 접근을 허용하는 정도
무결성 시스템 또는 제품의 구성요소가 소프트웨어 또는 데이터에 대한 무단 접근 및 수정을 방지하는 정도
부인 방지 사건 및 행위에 대해 부인하지 못하도록 행동 및 사건에 대해 입증되는 정도
책임성 시스템 내의 각 개인을 유일하게 식별하여 언제 어떤 행동을 하였는지 기록하여 필요 시 그 행위자를 추적할 수 있는 능력
인증성 사건 및 행동에 대해 행위자임을 증명할 수 있는 능력
유지보수성 모듈성 하나의 구성요소에 대한 변경이 다른 구성 요소에 미치는 영향이 최소화되도록 시스템 또는 소프트웨어가 개별 구성요소로 구성되는 정도
재사용성 하나 이상의 시스템에서 자산을 사용하거나 다른 자산을 구축할 수 있는 정도
분석성 하나 이상의 의도된 변경 사항이 제품 또는 시스템에 미치는 영향을 평가하거나 결함 또는 결함 원인에 대해 제품을 진단하거나 수정할 부분을 식별할 수 있는 정도
수정 가능성 제품이나 시스템에 결함이 발생한 경우 기존 제품의 품질을 저하시키지 않고 효과적으로 수정할 수 있는 정도
시험 가능성 제품 사용 전 사용에 필요한 검증 기능 제공 여부
이식성 적용성 제품 또는 시스템이 다른 하드웨어나 소프트웨어 또는 기타 사용 환경에 효과적이고 효율적으로 적용될 수 있는 정도
설치성 제품 또는 시스템이 성공적으로 설치 및 제거될 수 있는 정도
대체성 제품이 동일한 환경에서 동일한 목적을 위해 다른 지정 소프트웨어 제품으로 대체될 수 있는 정도

공식 사이트: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

실무 프로젝트에서의 적용 예

아래는 원격검침 시스템에서의 품질 특성에 따른 평가의 기준이다.

  • 기능성 - 기능 성숙도: 검침 기능이 요구된 시간 간격에 맞게 정상적으로 동작하는가? 
  • 기능성 - 기능 정확성: 웹서버에 전송되어 기록된 검침 데이터가 실제 미터의 검침 데이터와 일치하는가? 
  • 효율성 - 시간 반응성: 웹에서 동작 실행 시 기준 시간 내에 응답하는가? (기준 시간: 일반적인 웹의 경우 3초 이내)
  • 효율성 - 자원 활용성: 시스템의 CPU나 메모리 사용량이 적절한가? 
  • 호환성 - 상호 운용성: 모뎀과 웹서버의 연동 및 데이터 교환 기능이 정상적으로 동작하는가?
  • 사용성 - 사용자 오류 보호: 사용 시 입력 창에 잘못된 값을 입력해도 시스템 오류로부터 안전한가?
  • 사용성 - 사용자 인터페이스 미학: 사용자에게 만족할 만한 UI(화면 구성, 글자 폰트, 이미지) 를 제공하는가?
  • 신뢰성 - 가용성: 데이터 처리량이 많을 때 시스템이 다운되거나 문제가 생기지 않는가?
  • 신뢰성 - 회복 가능성: 시스템에 문제가 발생한 경우 데이터가 깨지거나 손실되지 않는가?
  • 신뢰성 - 결점완화: 검침주기에 데이터 전송이 실패한 경우 전송 실패한 데이터를 다음 검침 주기에 다시 전송하는가?
  • 보안성 - 기밀성: 제품의 동작을 변경하기 위한 위한 CLI (Command Line Interface) 접근이 가능한가?
  • 보안성 - 무결성: 시스템을 무단으로 접근하여 파일 변경을 시도하는 경우 이를 막거나 복구하는 기능이 있는가?
  • 보안성 - 부인 방지: 시스템의 사건이나 행위 발생 시 이를 로그로 기록하는가?
  • 유지보수성 - 분석성: 결함 발생 시 출력되는 오류코드로부터 결함의 원인을 파악할 수 있는가?
  • 유지보수성 - 시험 가능성: 검침 데이터 전송을 확인하기 전에 통신 상태나 네트워크 상태를 확인하는 기능이 있는가?
  • 이식성 - 설치성: 설치 또는 제거, 업그레이드가 용이한가?

 

+ Recent posts