shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
대니얼에게는 제이콥 그레이트하우스라는 형제가 있었다. 앨런 엑커트의 "프론티어맨"에 따르면, 제이콥 그레이트하우스는 1791년에 옐로 크리크 학살에 참여했다는 이유로 미국 원주민에게 붙잡혀 고문당하고 살해되었다. 그러나 다른 문서는 제이콥 그레이트하우스가 1777년 9월 윌리엄 포먼과 함께 사망했음을 보여준다. 그리고 1791년 오하이오 강에서 학살에 대한 복수로 인디언들에게 붙잡혀 고문당한 그레이트하우스는 조나단 그레이트하우스였다.
뉴모피즘(neumorphism)은 그래픽 사용자 인터페이스에서 사용되는 디자인 스타일이다. 일반적으로 부드럽고 가벼운 외관(그래서 때로는 소프트 UI라고도 불린다)과 함께 요소가 배경 위에 떠 있는 것처럼 보이는 대신 배경에서 튀어나오거나 배경 안으로 들어가 있는 것처럼 보이는 특징을 가지고 있다. 때로는 스큐어모피즘과 플랫 디자인 사이의 중간으로 간주되기도 한다.
뉴모피즘이라는 용어는 2019년 제이슨 켈리가 네오와 스큐어모피즘의 혼성어로 만들었으며, 스큐어모피즘의 준 부활로서의 역할을 강조한다. 많은 뉴모피즘 디자인 개념은 알렉산더 플류토에게서 비롯되었는데, 그는 다양한 뉴모피즘 디자인 요소들을 보여주는 온라인 뱅킹 앱의 실물 모형을 만들었다. 그는 이것을 웹사이트 드리블 (웹사이트)에 게시했고, 그곳에서 빠르게 조회수 3,000회를 기록하며 큰 인기를 얻었다.
2020년 11월 12일, 애플은 macOS 빅서를 출시했다. 이 업데이트에는 아이콘과 투명 사용 등 뉴모피즘을 특징으로 하는 그래픽 디자인이 포함되었다.
2025년 6월 9일, 애플은 IOS, IPadOS, MacOS, WatchOS, TvOS, VisionOS 운영체제를 위한 새로운 리퀴드 글래스 디자인 언어를 도입했다.
특징 및 목적.
뉴모피즘은 부드럽고 가벼운 외관을 특징으로 하는 미니멀리즘의 한 형태로, 종종 낮은 대비를 가진 파스텔 색을 사용한다. 요소는 일반적으로 배경과 동일한 색상이며, 요소 주변의 그림자와 하이라이트로만 구별된다. 이것은 요소들이 배경에서 "튀어나오거나" 또는 배경 안으로 들어가 있는 것처럼 보이게 한다.
디자이너들은 뉴모피즘이 스큐어모피즘과 플랫 디자인 사이의 중간 지점을 제공하기 때문에 뉴모피즘의 모양과 느낌을 선호할 수 있다. 구체적으로, 깔끔하고 미니멀리즘을 고수하면서도 그럴듯하게 사실적으로 보이도록 하는 것을 목표로 한다.
뉴모피즘은 특히 접근성 부족, 구현의 어려움, 낮은 대비, 그리고 특정 브랜드와의 비호환성 등으로 많은 비판을 받았다.
코콘테(Kokonte)는 토고, 가나 등 아프리카 일부 지역에서 먹는 주요 스왈로 음식이다. 가나에서는 코콘테가 가족, 아칸족, 하우사인과 같은 대부분의 민족 집단에 의해 먹힌다. 코콘테는 요리를 준비하는 민족 집단에 따라 일반적으로 갈색, 회색 및 짙은 녹색을 띤다. 코콘테는 주로 말린 카사바 또는 마로 준비된다.
코콘테는 카사바 가루로 만든 가나 요리로, 주로 팜나무 열매나 땅콩으로 만든 수프와 함께 먹는다. 나이지리아와 같은 서아프리카 국가에서 인기가 많으며 카리브 제도에서도 먹는다.
가나의 볼타주에서도 인기 있는 브라질 요리인 타피오카와 매우 유사하다.
이것은 말린 카사바 또는 마니옥 뿌리를 빻아 만든 간단한 요리로, 만들어지면 갈색을 띤다. 가나에서는 아칸족이 이 요리를 현지에서 준비하며, 현지 이름은 콰어군에서 유래했다.
완성된 코콘테의 겉모습은 사용된 카사바의 종류와 건조 정도에 따라 달라진다. 일반적으로 갈색을 띠지만 초콜릿 갈색일 수도 있다. 그 색깔은 가나 대부분의 지역에서 기본 학생이 입는 상위 교복의 색깔과 비슷하다.
코콘테를 요리하는 기본은 농장이나 가장 가까운 시장에서 카사바를 구하는 것에서 시작한다. 카사바는 상대적으로 저렴하기 때문에 가나 전역에서 가장 널리 먹는 주식 중 하나이다. 비교적 적은 양의 가루를 사도 온 가족이 먹을 수 있다. 이 동일한 카사바는 플랜틴과 결합하여 현지 가나 요리인 푸푸 (일부 사람들은 푸푸오라고 발음)를 준비한다.
예비 조리.
식용 가능한 카사바를 얻으려면 먼저 껍질을 벗겨야 한다. 껍질은 가축 사료로 사용하거나 농장 마당을 비옥하게 하는 거름으로 사용할 수 있다(농부의 경우). 식용 카사바는 그 다음 씻는다. 이것을 칩으로 자른다. 이 카사바 칩은 보통 햇볕에 말린 다음 제분소에서 가루로 갈아낸다.
카사바 칩을 말리는 방법은 여러 가지가 있다. 가나에서는 일부 농부들이 트위어로 '아파'라고 불리는 것을 가지고 있는데, 이는 농부들이 수확한 옥수수를 놓는 일종의 팜 잎으로 만든 부스를 의미한다. 이 부스는 묵아라고 불리는 현지 주방 유형 위에 의도적으로 만들어진다. 이렇게 하면 장작에서 나오는 연기가 옥수수를 건조시키고, 이 경우에는 카사바 칩을 건조시킨다. 이 건조 방법은 카사바 칩에 검게 그을린 모습을 주며, 이는 최종 제품(준비되고 조리된 코콘테)의 전반적인 모습에 영향을 미친다. 하지만 가장 좋은 방법은 자연적인 방법이다. 카사바 칩을 건조 쟁반(보통 나무나 알루미늄으로 만들어진, 칩을 넓게 펼칠 수 있을 만큼 큰)에 펼쳐 직사광선에 말리는 것이다.
주목할 만한 사실은, 건조되지 않은 카사바 칩을 충분한 시간 동안 방치하면 표면에 갈색을 띠는 조류의 형태가 나타나기 시작한다는 것이다. 이 곰팡이가 생기면 최종 요리의 모습에 영향을 미친다. 따라서 최종 요리의 흰색을 유지하려면 칩이 신선할 때 건조하는 것이 좋다. 그러나 많은 사람들은 칩의 갈변이 코콘테의 전체적인 맛을 더해준다고 믿는다.
말린 칩을 가루로 만들려면 막자사발과 막자에 빻거나 방앗간에 가서 갈아야 한다. 그러면 물을 넣고 불 위에서 익을 때까지 반죽하여 요리하는 최종 제품이 나온다. 그렇게 하면 코콘테 요리가 완성된다.
요리 및 서빙.
코콘테 가루는 실온의 물이나 뜨거운 물과 섞을 수 있다. 어떤 사람들은 요리하기 전에 먼저 가루에 뜨거운 물을 넣는 것을 선호한다. 불 위에서 저어주어 걸쭉해지면 더 반죽하고 요리한다. 너무 걸쭉하면 뜨거운 물을 조금 더 넣고 몇 분 동안 뚜껑을 덮은 다음 물이 잘 섞일 때까지 냄비에 대고 반죽한다(필요한 경우 적절한 농도가 될 때까지 뜨거운 물 추가와 반죽을 반복해야 할 수 있다).
서빙 1: 익으면 깊은 그릇 주위를 물로 살짝 적신 후 식사에 적합한 양을 떠서 그릇 중앙에 놓는다. 코콘테의 모든 가장자리를 중앙으로 당겨주면 아래쪽에 부드러운 코콘테 바닥이 생긴다. 뒤집으면 위에 수프를 얹을 부드러운 공 모양이 된다.
서빙 2: 어떤 사람들은 그냥 그릇에 일정량을 떠서 그 위에 수프를 붓는다.
컴퓨팅에서 미니멀리즘(minimalism)은 미니멀리즘 철학과 원칙을 하드웨어 및 소프트웨어의 설계 및 사용에 적용하는 것을 의미한다. 이러한 의미에서 미니멀리즘은 가능한 최소한의 하드웨어 및 소프트웨어 자원을 사용하는 시스템을 설계하는 것을 의미한다.
1970년대 후반과 1980년대 초반에 프로그래머들은 일반적인 플랫폼의 상대적으로 비싸고 제한적인 자원 내에서 작업했다. 8~16 킬로바이트의 랜덤 액세스 메모리가 일반적이었으며, 64 킬로바이트는 막대한 양으로 간주되었고 개인용 컴퓨터 초기 세대에서 지배적이었던 8비트 CPU가 접근할 수 있는 전체 주소 공간이었다. 가장 일반적인 저장 매체는 88~170킬로바이트를 저장할 수 있는 5.25인치 플로피 디스크였다. 5~10 메가바이트 용량의 하드 드라이브는 수천 달러가 들었다.
시간이 지남에 따라 개인용 컴퓨터의 메모리 용량이 비약적으로 확장되었고, 주류 프로그래머들은 추가된 저장 공간을 활용하여 소프트웨어의 기능을 늘리고 고급 언어를 사용하여 개발을 더 쉽게 만들었다. 대조적으로, 레거시 소프트웨어의 시스템 요구 사항은 동일하게 유지되었다. 결과적으로, 과거의 가장 정교하고 기능이 풍부한 프로그램조차도 현재 소프트웨어와 비교하면 미니멀리즘적으로 보인다.
시스템 요구 사항으로 인해 한때 고용량으로 명성이 높았던 프로그램의 한 예는 GNU 이맥스 텍스트 편집기인데, 이는 8메가바이트가 많은 RAM이었던 시대에 "Eight Megabytes And Constantly Swapping"(항상 8메가바이트를 스와핑함)이라는 역두문자어를 얻었다. 오늘날 이맥스의 주로 텍스트 버퍼 (컴퓨터 과학) 기반 패러다임은 이클립스 또는 넷빈즈와 같은 유사한 기능을 가진 데스크톱 메타포 GUI 통합 개발 환경보다 훨씬 적은 자원을 사용한다. 2002년 국제 리스프 컨퍼런스 연설에서 리처드 스톨먼은 당시 저사양 미니컴퓨터의 리스프 및 시스템 사양 경험을 바탕으로 GNU와 이맥스 개발에서 미니멀리즘이 중요한 관심사였음을 밝혔다.
1980년대와 1990년대에 걸쳐 일반적인 데스크톱 소프트웨어와 운영 체제의 기능 및 시스템 요구 사항이 증가하고, 소프트웨어 개발이 상충되고 유행하는 소프트웨어 개발 방법론을 지지하는 팀에 의해 지배되면서 일부 개발자들은 미니멀리즘을 철학으로 채택하고 프로그램의 크기나 범위를 미리 정해진 한도로 제한하기로 선택했다. 소프트웨어 최적화에 중점을 두면 미니멀리즘 소프트웨어가 될 수 있는데, 프로그래머가 실행 속도를 높이기 위해 프로그램이 수행하는 작업 수를 줄이기 때문이다.
21세기 초, 컴퓨팅의 새로운 발전은 미니멀리즘을 전면에 내세웠다. 이른바 포스트-PC 시대에는 일반적인 컴퓨팅 작업을 수행하기 위해 더 이상 고성능 개인용 컴퓨터를 구매할 필요가 없다. 스마트폰, 태블릿 컴퓨터, 넷북 및 플러그 컴퓨터와 같은 모바일 컴퓨팅 장치는 대체할 것으로 예상되는 개인용 컴퓨터에 비해 메모리 용량이 작고 그래픽 하위 시스템의 성능이 떨어지며 프로세서가 느린 경우가 많다. 또한 알파 블렌딩과 같은 그래픽 효과를 많이 사용하면 "평면 UI"보다 배터리가 더 빨리 소모된다. 이러한 장치들의 인기가 높아지면서 미니멀리즘이 중요한 디자인 고려 사항이 되었다.
구글의 크롬 브라우저 및 크롬OS는 미니멀리즘 디자인의 예로 자주 인용된다.
또 다른 예는 마이크로소프트가 "단순하고 네모난" 메트로 모양을 구현한 윈도우 8로, 이전 윈도우 7 및 윈도우 비스타에서 사용된 윈도우 에어로 인터페이스보다 그래픽 집약도가 낮았다. 이러한 변경은 부분적으로 더 작고 배터리로 작동하는 장치의 증가와 전력 절약의 필요성 때문에 이루어졌다. 애플의 IOS 버전 7도 사용자 경험상의 이유로 유사한 변경을 했다.
개발자들은 사용자에게 혼란을 줄 수 있는 버튼과 대화 상자를 제거하여 사용자 인터페이스를 최대한 단순하게 만들 수 있다. 미니멀리즘은 때때로 시각 예술적 의미로, 특히 하드웨어 장치나 소프트웨어 테마의 산업 디자인에서 사용된다.
일부 개발자들은 주어진 플랫폼에서 가장 적은 코드 라인 또는 가장 작은 컴파일된 실행 파일 크기로 특정 기능을 수행하는 프로그램을 만들려고 시도했다. 일부 리눅스 배포판은 미니멀리즘을 목표로 언급한다. 알파인, 아치, 퍼피, 보디, 크런치뱅, dynebolic 및 타이니 코어가 그 예이다. 유닉스 시스템의 초기 개발은 저전력 하드웨어에서 이루어졌으며, 데니스 리치와 켄 톰프슨은 이러한 제약이 시스템의 "설계의 우아함"에 기여했다고 의견을 밝혔다.
프로그래밍 언어 설계자들은 신택틱 슈거와 광범위한 라이브러리 함수를 피함으로써 최소한의 프로그래밍 언어를 만들 수 있다. 이러한 언어는 일반적인 프로그래밍 작업에 대한 표준 지원을 제공하지 않아 튜링 함정이 될 수 있다. 최소한의 리스프 인터프리터를 만드는 것은 컴퓨터 과학 학생들에게 흔히 주어지는 학습 과제이다. 알론조 처치가 개발한 람다 대수는 함수 정의와 함수 적용만을 사용하는 최소한의 프로그래밍 언어이다. 스킴, 포스, 및 Go는 실용적이고 최소한의 프로그래밍 언어의 예로 인용된다.
코드 골프라는 프로그래밍 취미는 미니멀리즘 소프트웨어를 만들어내지만, 이는 일반적으로 연습이나 코드 시이며, 사용 가능한 응용 소프트웨어는 아니다.
존 밀라 캐롤은 그의 저서 《뉘른베르크 깔때기를 넘어서는 미니멀리즘》에서 미니멀리즘의 사용이 비디오 게임, ATM, 투표기, 쇼핑몰 키오스크와 같이 사용자가 매뉴얼을 읽을 필요가 없는 거의 또는 전혀 학습 곡선이 없는 "즉시 사용 가능한" 장치로 이어진다고 지적했다. 사용자 인터페이스 연구원들은 절약 및 투명성의 설계 원칙으로 예시된 미니멀리즘이 효율성과 학습 가능성을 강화한다는 실험을 수행했다. 미니멀리즘은 "모든 것은 텍스트 스트림이다" 및 "하나의 일을 잘 한다"는 유닉스 철학에 내재되어 있지만, 현대 유닉스/리눅스 배포판은 이러한 철학을 엄격하게 지키지는 않는다.
오모 투오(; "쌀 경단")는 쌀로 만든 가나의 주식이다. 주로 "부서진 쌀" 또는 잘게 부서진 긴 쌀이 사용된다. 이것은 나이지리아의 하우사인들의 주식인 투원 신카파의 가나 버전으로, 이 요리와 투원 마사라와 같은 하우사인 기원의 또 다른 인기 있는 가나 요리인 "투오 자피"에 사용되는 "투오"라는 이름의 기원이 된다. 쌀은 보통 평소보다 물을 더 많이 넣어 부드럽게 익힌다. 그런 다음 부드러워지도록 두드리고, 적당한 크기의 경단으로 만든다. 가나에서는 보통 땅콩이나 팜 너트로 만든 수프와 함께 제공된다. 나이지리아에서는 미얀 쿠카(말린 오크라와 바오밥나무 잎 수프)와 함께 나올 수 있다.
컴퓨터에서 효율적으로 사용되려면 모든 소프트웨어는 특정 하드웨어 구성 요소나 다른 소프트웨어 리소스가 존재해야 한다. 이러한 전제 조건은 (컴퓨터) 시스템 요구사항(System requirements)으로 알려져 있으며, 절대적인 규칙이 아닌 지침으로 자주 사용된다. 대부분의 소프트웨어는 최소 및 권장 두 가지 시스템 요구사항 세트를 정의한다. 소프트웨어의 새 버전에서 더 높은 처리 능력과 리소스에 대한 수요가 증가함에 따라 시스템 요구사항은 시간이 지남에 따라 증가하는 경향이 있다. 업계 분석가들은 이러한 추세가 기술 발전보다 기존 컴퓨터 시스템 업그레이드를 유도하는 데 더 큰 역할을 한다고 제안한다. 시스템 요구사항이라는 용어의 두 번째 의미는 이 첫 번째 정의를 일반화하여 시스템 또는 하위 시스템 설계에서 충족되어야 하는 요구사항을 제공하는 것이다.
권장 시스템 요구사항.
종종 게임 제조업체는 소비자에게 소프트웨어를 실행하는 데 필요한 것과는 다른 요구사항 세트를 제공한다. 이러한 요구사항은 일반적으로 권장 요구사항이라고 불린다. 이러한 요구사항은 최소 요구사항보다 훨씬 높은 수준이며, 소프트웨어를 실행하기에 이상적인 상황을 나타낸다. 일반적으로 이는 해당 소프트웨어로 완전히 사용 가능하고 즐거운 경험을 하기 위한 최소 시스템 요구사항보다 더 나은 지침이다.
모든 운영체제 또는 소프트웨어 애플리케이션이 정의하는 가장 일반적인 요구사항은 물리적 컴퓨터 리소스, 즉 하드웨어이다. 하드웨어 요구사항 목록은 종종 하드웨어 호환 목록 (HCL)과 함께 제공되며, 특히 운영체제의 경우 그러하다. HCL은 특정 운영체제 또는 애플리케이션에 대해 테스트되고 호환되며 때로는 호환되지 않는 하드웨어 장치를 나열한다. 다음 하위 섹션에서는 하드웨어 요구사항의 다양한 측면을 다룬다.
모든 컴퓨터 운영체제는 특정 컴퓨터 구조를 위해 설계된다. 대부분의 소프트웨어 애플리케이션은 특정 아키텍처에서 실행되는 특정 운영체제로 제한된다. 아키텍처 독립적인 운영체제 및 애플리케이션이 존재하지만, 대부분은 새로운 아키텍처에서 실행하기 위해 재컴파일되어야 한다. 일반적인 운영체제 및 지원 아키텍처 목록도 참조하라.
중앙 처리 장치(CPU)의 성능은 모든 소프트웨어의 기본적인 시스템 요구사항이다. x86 아키텍처에서 실행되는 대부분의 소프트웨어는 처리 능력을 CPU의 모델 및 클럭 속도로 정의한다. 버스 속도, 캐시, MIPS 등 CPU의 속도와 성능에 영향을 미치는 많은 다른 기능은 종종 무시된다. 이러한 성능 정의는 종종 유사한 클럭 속도에서 다른 제조사 및 모델의 CPU가 다른 처리량 속도를 갖기 때문에 오류가 있다.
모든 소프트웨어는 실행될 때 컴퓨터의 랜덤 액세스 메모리(RAM)에 상주한다. 메모리 요구사항은 애플리케이션, 운영체제, 지원 소프트웨어 및 파일, 기타 실행 중인 프로세스의 요구사항을 고려하여 정의된다. 다중 작업 컴퓨터 시스템에서 실행되는 다른 관련 없는 소프트웨어의 최적 성능도 이 요구사항을 정의할 때 고려된다.
보조 저장 장치.
데이터 저장 장치 요구사항은 소프트웨어 설치 크기, 소프트웨어를 설치하거나 실행하는 동안 생성 및 유지되는 임시 파일, 그리고 스왑 공간 (RAM이 부족한 경우) 사용 가능성에 따라 달라진다.
디스플레이 어댑터.
그래픽 편집기 및 고급 게임과 같이 평균 이상의 컴퓨터 그래픽스 디스플레이를 요구하는 소프트웨어는 종종 시스템 요구사항에 고급 디스플레이 어댑터를 정의한다.
일부 소프트웨어 애플리케이션은 특정 주변기기를 광범위하게 또는 특별히 사용해야 하므로, 해당 주변기기의 더 높은 성능이나 기능을 요구한다. 이러한 주변기기에는 CD-ROM 드라이브, 키보드, 포인팅 장치, 네트워크 장치 등이 포함된다.
소프트웨어 요구사항.
소프트웨어 요구사항은 애플리케이션의 최적 기능을 제공하기 위해 컴퓨터에 설치되어야 하는 소프트웨어 리소스 요구사항 및 전제 조건을 정의하는 것을 다룬다. 이러한 요구사항 또는 전제 조건은 일반적으로 소프트웨어 설치 패키지에 포함되어 있지 않으며 소프트웨어를 설치하기 전에 별도로 설치해야 한다.
컴퓨팅 플랫폼은 소프트웨어를 실행할 수 있도록 하는 하드웨어 또는 소프트웨어 형태의 프레임워크를 설명한다. 일반적인 플랫폼에는 컴퓨터의 아키텍처, 운영체제, 또는 프로그래밍 언어 및 해당 런타임 라이브러리가 포함된다.
운영체제는 시스템 요구사항(소프트웨어)을 정의할 때 언급되는 요구사항 중 하나이다. 소프트웨어는 동일한 운영체제 계열의 다른 버전과 호환되지 않을 수 있지만, 어느 정도의 하위 호환성은 종종 유지된다. 예를 들어, Microsoft Windows XP용으로 설계된 대부분의 소프트웨어는 Microsoft Windows 98에서 실행되지 않지만, 그 반대는 항상 참이 아니다. 마찬가지로, Linux Kernel v2.6의 새로운 기능을 사용하여 설계된 소프트웨어는 일반적으로 Kernel v2.2 또는 v2.4를 사용하는 Linux 배포판에서 제대로 실행되거나 컴파일되지 않는다 (또는 전혀 안 된다).
API 및 드라이버.
고급 디스플레이 어댑터와 같은 특수 하드웨어 장치를 광범위하게 사용하는 소프트웨어는 특별한 API 또는 최신 장치 드라이버가 필요하다. 좋은 예는 Microsoft 플랫폼에서 멀티미디어, 특히 게임 프로그래밍과 관련된 작업을 처리하기 위한 API 모음인 DirectX이다.
대부분의 웹 애플리케이션 및 소프트웨어는 시스템에 설치된 기본 브라우저를 사용하기 위해 웹 기술에 크게 의존한다. Microsoft Edge는 취약점에도 불구하고 ActiveX 컨트롤을 사용하는 Microsoft Windows에서 실행되는 소프트웨어의 일반적인 선택이다.
일부 소프트웨어는 적절한 성능을 위해 다른 요구사항도 가진다. 인터넷 연결 (유형 및 속도) 및 디스플레이 화면의 해상도가 주목할 만한 예이다.
다음은 인기 있는 PC 게임의 시스템 요구사항 정의와 끊임없이 증가하는 리소스 요구 사항의 추세에 대한 몇 가지 예시이다. 한술 더 떠서 동일한 게임도 패치가 거듭됨에 따라서 사양이나 운영체제 버전이 상승하는 일이 있다. 스타크래프트2는 공허의 유산 즈음부터 시스템 요구사양이 높아졌다. 2024년말 부터는 윈도우7에서 제대로 실행이 되지 않는다.
예를 들어, 스타크래프트 (1998)는 다음을 요구한다.
둠 3 (2004)는 다음을 요구한다.
(2009)는 다음을 요구한다.
그랜드 테프트 오토 V (2015)는 다음을 요구한다.
우잉제(; 1956년 12월 출생)는 티베트를 기반으로 활동하는 중국의 정치인으로, 이전에는 티베트의 최고 책임자인 티베트 자치구 당위원회 서기를 역임했다. 원래 산둥성 출신이지만, 우잉제는 티베트에서 성장하여 평생 이 지역에서 일했다. 2011년 티베트 부서기가 되었고 약 5년 동안 이 직책을 맡은 후 당 대표로 승진했다.
우잉제는 산둥성 창이시에서 태어났다. 그의 아버지는 그가 한 살 때 티베트고원에 직장을 배정받아 가족과 함께 이 지역으로 이주했다. 1974년 10월 문화대혁명 기간 동안 하향 지식 청년으로 린즈시에 도착했다. 우잉제는 티베트 민족대학교를 졸업하고 중국공산당 중앙당교에서 리더십 교육을 받았다. 1977년 라싸 서부 교외의 발전소에서 일하기 시작했다. 1983년 8월 티베트 자치구 교육부에 합류했다. 그는 다음 20년 동안 교육 분야에서 일했다. 1987년에는 지역 공무원으로 초등 및 중등 교육을 감독하기 시작했다. 1990년에는 전국 각지에서 교육 자원 기부를 받는 일을 담당했다. 1994년에는 자치구 교육 위원회에 합류하여 1998년 5월 부비서로 승진했다. 2000년 3월 교육부 부부장으로 임명되었고, 2000년에 부장으로 승진했다.
2003년 1월, 우잉제는 티베트 자치구 부주석으로 임명되었고, 2005년 6월에는 지역 선전 담당으로 일했으며 다음 달에는 지역 당 상임위원회에 합류했다. 2006년 11월에는 티베트 자치구 상무 부주석이 되었다.
2011년 11월, 그는 지역 당 부서기로 임명되었다. 2013년 4월에는 상무 부서기로 임명되었다. 2016년 8월, 그는 티베트 자치구 당위원회 서기가 되었다. 우잉제는 부서기 직책에서 당위원회 서기 직책으로 곧바로 승진했는데, 이는 티베트 자치구 당위원회 서기가 중국의 다른 지역에서 임명되는 전통을 깬 것이다.
2021년 10월 23일, 그는 전국인민대표대회 교육과학문화위생위원회 부주임으로 임명되었다. 2023년 3월, 우잉제는 중국인민정치협상회의 제14기 전국위원회 상무위원 겸 문화문사학습위원회 주임으로 선출되었다.
2022년 12월, 미국 재무부는 티베트에서의 인권 침해에 대해 글로벌 매그니츠키법에 따라 우잉제를 제재했다.
2024년 12월 11일 세계 인권의 날, 캐나다 외교부 장관 멜라니 졸리는 우잉제와 심각한 인권 침해에 연루된 신장과 티베트의 다른 7명의 정부 관료에 대한 캐나다의 제재를 발표했다.
2024년 6월 16일, 우잉제는 당의 내부 기율 기관인 중국공산당 중앙기율검사위원회(CCDI)와 중국 최고 반부패 기관인 국가감찰위원회로부터 "심각한 법규 위반" 혐의를 받았다. 7월 24일, 중국인민정치협상회의 제14기 전국위원회 상무위원회 제8차 회의는 우잉제를 위원회 위원 및 문화문사학습위원회 주임에서 해임하기로 결정했다. 그에 대한 조사를 통해 그가 '당의 정책'을 이행하지 않고 개인적인 이득을 위해 지역 사업에 개입한 것이 밝혀진 후 공산당에서 제명되었다. 12월 24일, 중화인민공화국 최고인민검찰원은 그의 체포를 발표했다.
소프트웨어 요구사항(Software requirements)은 시스템이 무엇을 해야 하는지, 시스템이 제공하는 서비스 또는 서비스 및 운영 제약 조건에 대한 설명이다. IEEE 소프트웨어 공학 용어 표준 용어집은 요구사항을 다음과 같이 정의한다.
소프트웨어 요구사항 작업과 관련된 활동은 크게 도출, 분석, 명세화 및 관리로 나눌 수 있다.
소프트웨어 요구사항이라는 용어는 특정 소프트웨어를 빌드/설치/사용하기 위해 소프트웨어 패키지에 따라 필요한 소프트웨어 릴리스 노트를 설명하는 데 추가로 사용된다.
도출은 이해관계자 및 기타 소스로부터 요구사항을 수집하고 발견하는 것이다. 결합 응용 설계(JAD) 세션, 인터뷰, 문서 분석, 포커스 그룹 등 다양한 기술을 사용할 수 있다. 도출은 요구사항 개발의 첫 번째 단계이다.
분석은 도출에서 진행되는 논리적 세분화이다. 분석은 각 요구사항에 대한 더 풍부하고 정확한 이해에 도달하고 여러 보완적인 방식으로 요구사항 집합을 표현하는 것을 포함한다.
요구사항 분류 또는 요구사항 우선순위 지정은 종종 분석을 따르는 또 다른 활동이다. 이는 계획 단계에서 애자일 소프트웨어 개발과 관련이 있으며, 예를 들어 플래닝 포커를 통해 이루어지지만, 프로젝트 및 요구사항 또는 구축 중인 제품/서비스의 맥락과 성격에 따라 다를 수 있다.
명세화.
명세화는 수집된 요구사항 지식을 효과적인 의사소통 및 변경 관리를 용이하게 하는 지속적이고 잘 정리된 방식으로 표현하고 저장하는 것을 포함한다. 유스 케이스, 유저 스토리, 기능 요구사항 및 시각적 분석 모델은 요구사항 명세화를 위한 인기 있는 선택이다.
유효성 검사는 프로젝트의 비즈니스 목표를 충족하는 솔루션을 구축하기 위해 올바른 요구사항 집합이 명세화되었는지 확인하는 기술을 포함한다.
요구사항은 프로젝트 중에 변경되며 종종 많은 요구사항이 존재한다. 이러한 변경 관리는 이해관계자를 위해 올바른 소프트웨어가 구축되도록 보장하는 데 가장 중요하다.
요구공학을 위한 도구 지원.
요구사항 도출, 분석 및 유효성 검사를 위한 도구.
이러한 활동에는 관찰 보고서(사용자 관측), 설문지(인터뷰, 설문조사 및 투표), 유스 케이스, 유저 스토리와 같은 아티팩트가 포함될 수 있으며, 요구사항 워크숍(샤레트), 브레인스토밍, 마인드맵, 역할연기와 같은 활동, 심지어 프로토타이핑까지 포함될 수 있다는 점을 고려할 때, 이러한 기능 중 일부 또는 전부를 제공하는 소프트웨어 제품을 사용하여 이러한 작업을 수행하는 데 도움을 받을 수 있다.
프리마인드와 같은 마인드맵 도구와 Concordion과 같은 specification by example 도구의 사용을 명시적으로 옹호하는 저자가 적어도 한 명 있다.
또한 이러한 활동으로 인해 발생하는 아이디어 및 진술은 위키 및 트렐로와 같은 기타 협업 도구로 수집 및 정리될 수 있다. 실제로 구현되는 기능 및 표준 준수는 제품마다 다르다.
요구사항 명세화를 위한 도구.
소프트웨어 요구 명세(SRS) 문서는 워드 프로세서와 같은 범용 소프트웨어 또는 여러 특수 도구 중 하나를 사용하여 생성될 수 있다. 이러한 도구 중 일부는 SRS 문서를 가져오고, 편집하고, 내보내고, 게시할 수 있다. ISO/IEC/IEEE 29148:2018과 같은 표준화된 구조 및 방법론을 따르면서 SRS 문서를 작성하는 데 도움이 될 수 있다. 마찬가지로 소프트웨어는 요구사항을 가져오거나 내보내는 데 일부 표준(ReqIF 등)을 사용하거나 이러한 교환을 전혀 허용하지 않을 수 있다.
요구사항 문서 검증을 위한 도구.
이러한 종류의 도구는 예상되는 구조 또는 표준에 따라 요구사항 문서에 오류가 있는지 확인한다.
요구사항 비교를 위한 도구.
이러한 종류의 도구는 예상되는 문서 구조 및 표준에 따라 두 가지 요구사항 집합을 비교한다.
요구사항 병합 및 업데이트를 위한 도구.
이러한 종류의 도구는 요구사항 문서를 병합하고 업데이트할 수 있도록 한다.
요구사항 추적성을 위한 도구.
이러한 종류의 도구는 모델 및 소스 코드와 같은 다른 아티팩트로 요구사항을 추적하거나(전방 추적성), 비즈니스 규칙 및 제약 조건과 같은 이전 아티팩트로 추적할 수 있다(후방 추적성).
모델 기반 소프트웨어 또는 시스템 요구사항 엔지니어링을 위한 도구.
모델 기반 시스템 엔지니어링(MBSE)은 개념 설계 단계부터 개발 및 이후 라이프사이클 단계에 걸쳐 시스템 요구사항, 설계, 분석, 검증 및 유효성 검사 활동을 지원하기 위한 모델링의 공식적인 적용이다.
요구공학의 일부 단계에 대해 모델 기반 접근 방식을 취하고 다른 단계에 대해서는 보다 전통적인 접근 방식을 취하는 것도 가능하다. 매우 많은 조합이 가능할 수 있다.
형식성 및 복잡성의 수준은 관련된 기본 방법론에 따라 달라진다(예를 들어, i*는 SysML보다 훨씬 더 형식적이며, UML보다도 더 형식적이다).
일반 요구공학을 위한 도구.
이 범주의 도구는 이전에 언급된 기능 및 요구사항 구성 관리 및 협업과 같은 기타 기능을 혼합하여 제공할 수 있다. 실제로 구현되는 기능 및 표준 준수는 제품마다 다르다.
다른 단계 및 활동을 지원하는 더 강력하거나 일반적인 도구도 있다. 이러한 도구는 ALM 도구로 분류된다.
소프트웨어 품질 보증에서 성능 테스트(performance testing)는 일반적으로 특정 작업 부하에서 시스템이 응답성 및 안정성 측면에서 어떻게 작동하는지 결정하기 위해 수행되는 테스트 방식이다. 또한 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 확인하는 데 사용될 수도 있다.
성능 테스트는 성능 공학의 하위 집합으로, 시스템의 구현, 설계 및 아키텍처에 성능 표준을 구축하려는 컴퓨터 과학 실습이다.
테스트 유형.
부하 테스트.
부하 테스트는 가장 간단한 형태의 성능 테스트이다. 부하 테스트는 일반적으로 특정 예상 부하에서 시스템의 동작을 이해하기 위해 수행된다. 이 부하는 설정된 기간 내에 특정 수의 트랜잭션을 수행하는 응용 프로그램에 대한 예상 동시 사용자 수일 수 있다. 이 테스트는 모든 중요한 비즈니스 핵심 트랜잭션의 응답 시간을 알려준다. 데이터베이스, 웹 애플리케이션 서버 등도 테스트 중에 모니터링되며, 이는 응용 소프트웨어 및 소프트웨어가 설치된 하드웨어의 병목 현상을 식별하는 데 도움이 된다.
스트레스 테스트.
스트레스 테스트는 일반적으로 시스템 내의 용량 상한을 이해하는 데 사용된다. 이러한 종류의 테스트는 극한 부하 측면에서 시스템의 견고성을 결정하기 위해 수행되며, 응용 프로그램 관리자가 현재 부하가 예상 최대치를 훨씬 초과할 경우 시스템이 충분히 작동하는지 여부를 결정하는 데 도움이 된다.
침투 테스트.
침투 테스트, 즉 내구성 테스트는 일반적으로 시스템이 지속적인 예상 부하를 견딜 수 있는지 여부를 결정하기 위해 수행된다. 침투 테스트 중에 메모리 사용률이 모니터링되어 잠재적인 메모리 누수를 감지한다. 또한 중요하지만 종종 간과되는 것은 성능 저하, 즉 일정 기간 동안 지속된 활동 후 처리량 및 응답 시간이 테스트 시작 시와 같거나 더 좋은지 확인하는 것이다. 이는 본질적으로 상당한 부하를 시스템에 장기간 적용하는 것을 포함한다. 목표는 지속적인 사용 시 시스템이 어떻게 동작하는지 파악하는 것이다.
스파이크 테스트.
스파이크 테스트는 매우 많은 수의 사용자가 생성하는 부하를 갑자기 늘리거나 줄이고 시스템의 동작을 관찰하여 수행된다. 목표는 성능이 저하되는지, 시스템이 실패하는지, 또는 부하의 극적인 변화를 처리할 수 있는지 여부를 결정하는 것이다.
분기점 테스트.
분기점 테스트는 스트레스 테스트와 유사하다. 미리 정해진 실패 조건을 위해 시스템을 모니터링하면서 시간이 지남에 따라 점진적인 부하가 적용된다. 분기점 테스트는 시스템이 요구되는 사양 또는 서비스 수준 협약에 따라 작동할 최대 용량을 결정한다고 말할 수 있으므로 때로는 용량 테스트라고도 한다. 고정된 환경에 적용된 분기점 분석 결과는 필요한 하드웨어 측면에서 최적의 스케일링 전략 또는 클라우드 환경에서 스케일아웃 이벤트를 트리거해야 하는 조건을 결정하는 데 사용될 수 있다.
구성 테스트.
부하 관점에서 성능을 테스트하는 대신, 시스템 구성 요소에 대한 구성 변경이 시스템의 성능 및 동작에 미치는 영향을 결정하기 위해 테스트가 생성된다. 일반적인 예는 부하 분산의 다양한 방법을 실험하는 것이다.
격리 테스트.
격리 테스트는 성능 테스트에만 고유한 것은 아니지만 시스템 문제를 초래한 테스트 실행을 반복하는 것을 포함한다. 이러한 테스트는 종종 결함 도메인을 격리하고 확인할 수 있다.
인터넷 테스트.
이는 페이스북, 구글, 위키백과와 같은 글로벌 응용 프로그램을 실제 대상 대륙에 배치된 부하 생성기(물리적 머신 또는 클라우드 VM)에서 성능 테스트하는 비교적 새로운 형태의 성능 테스트이다. 이러한 테스트는 성공적으로 실행되기 위해 엄청난 양의 준비와 모니터링이 필요하다.
성능 목표 설정.
성능 테스트는 다양한 목적을 수행할 수 있다:
많은 성능 테스트는 충분히 현실적이고 목표 지향적인 성능 목표를 설정하지 않고 수행된다. 비즈니스 관점에서 첫 번째 질문은 항상 "왜 성능 테스트를 하는가?"여야 한다. 이러한 고려 사항은 테스트의 사업 사례의 일부이다. 성능 목표는 시스템의 기술 및 목적에 따라 달라지지만, 항상 다음 중 일부를 포함해야 한다:
동시성 및 처리량.
시스템이 어떤 형태의 로그인 절차를 통해 최종 사용자를 식별하는 경우 동시성 목표는 매우 바람직하다. 정의에 따르면 이는 시스템이 주어진 순간에 지원해야 하는 동시 시스템 사용자의 최대 수이다. 스크립트된 트랜잭션의 작업 흐름은 특히 반복적인 부분이 로그인 및 로그아웃 활동을 포함하는 경우 진정한 동시성에 영향을 미칠 수 있다.
시스템이 최종 사용자 개념을 가지고 있지 않은 경우, 성능 목표는 최대 처리량 또는 트랜잭션 속도를 기반으로 할 가능성이 높다.
서버 응답 시간.
이는 한 시스템 노드가 다른 노드의 요청에 응답하는 데 걸리는 시간을 나타낸다. 간단한 예는 브라우저 클라이언트에서 웹 서버로의 HTTP 'GET' 요청일 것이다. 응답 시간 측면에서 이는 모든 부하 테스트 도구가 실제로 측정하는 것이다. 시스템의 모든 노드 간에 서버 응답 시간 목표를 설정하는 것이 적절할 수 있다.
렌더 응답 시간.
부하 테스트 도구는 렌더 응답 시간을 측정하는 데 어려움이 있다. 일반적으로 '온 와이어' 활동이 없는 기간을 인식하는 것 외에는 노드 내에서 발생하는 일에 대한 개념이 없기 때문이다. 렌더 응답 시간을 측정하려면 일반적으로 기능 테스트 스크립트를 성능 테스트 시나리오의 일부로 포함해야 한다. 많은 부하 테스트 도구는 이 기능을 제공하지 않는다.
성능 사양.
성능 사양(요구사항)을 자세히 설명하고 모든 성능 테스트 계획에 문서화하는 것이 중요하다. 이상적으로는 이는 시스템 개발 프로젝트의 요구사항 개발 단계에서, 즉 어떤 설계 노력 이전에 수행된다. 자세한 내용은 성능 공학을 참조하라.
그러나 성능 테스트는 사양에 대해 자주 수행되지 않는다. 예를 들어, 특정 사용자 집단에 대한 최대 허용 응답 시간이 무엇이어야 하는지에 대해 아무도 표현하지 않았을 것이다. 성능 테스트는 종종 성능 프로파일 튜닝 과정의 일부로 사용된다. 아이디어는 "가장 약한 고리"를 식별하는 것이다. 즉, 더 빠르게 응답하도록 만들면 전체 시스템이 더 빠르게 실행될 시스템의 일부가 불가피하게 존재한다. 시스템의 어떤 부분이 이 핵심 경로를 나타내는지 식별하는 것은 때때로 어려운 작업이며, 일부 테스트 도구에는 서버에서 실행되는 (에이전트) 계측 기능을 포함하거나 추가 기능을 제공하여 트랜잭션 시간, 데이터베이스 접근 시간, 네트워크 오버헤드 및 기타 서버 모니터를 보고하며, 이를 원시 성능 통계와 함께 분석할 수 있다. 이러한 계측 기능이 없으면 윈도우 작업 관리자를 통해 서버에서 성능 테스트가 얼마나 많은 CPU 부하를 생성하는지 확인해야 할 수도 있다(테스트 중인 시스템이 윈도우 시스템이라고 가정).
성능 테스트는 웹을 통해 수행될 수 있으며, 심지어는 인터넷 자체의 응답 시간이 지역에 따라 다르다는 점을 고려하여 다른 국가에서도 수행될 수 있다. 또한 내부적으로도 수행할 수 있지만, 라우터는 공용 네트워크에서 일반적으로 발생하는 지연을 도입하도록 구성해야 할 것이다. 시스템에 대한 부하는 현실적인 지점에서 도입되어야 한다. 예를 들어, 시스템 사용자 기반의 50%가 56K 모뎀 연결을 통해 시스템에 접근하고 나머지 절반이 T1을 통해 접근한다면, 부하 주입기(실제 사용자를 시뮬레이션하는 컴퓨터)는 동일한 혼합 연결을 통해 부하를 주입하거나(이상적) 동일한 사용자 프로필에 따라 이러한 연결의 네트워크 지연 시간을 시뮬레이션해야 한다.
피크 시간대에 시스템을 사용할 것으로 예상되는 최대 사용자 수를 명시하는 것이 항상 도움이 된다. 또한 최대 허용 95백분위 응답 시간이 무엇인지 명시할 수 있다면, 제안된 시스템이 해당 사양을 충족하는지 테스트하는 데 주입기 구성을 사용할 수 있다.
성능 사양은 최소한 다음 질문을 해야 한다.
가능한 한 생산 환경과 유사해야 하는 안정적인 시스템 빌드.
일관된 결과를 보장하기 위해 성능 테스트 환경은 UAT (User Acceptance Testing) 또는 개발과 같은 다른 환경과 격리되어야 한다. 가장 좋은 방법은 가능한 한 생산 환경과 유사한 별도의 성능 테스트 환경을 갖는 것이 항상 권장된다.
테스트 조건.
성능 테스트에서는 테스트 조건이 예상되는 실제 사용과 유사해야 하는 것이 종종 중요한다. 그러나 실제로는 이를 마련하기 어렵고 완전히 가능하지 않다. 생산 시스템은 예측할 수 없는 작업 부하에 노출되기 때문이다. 테스트 작업 부하는 가능한 한 생산 환경에서 발생하는 상황을 모방할 수 있지만, 가장 단순한 시스템에서만 이 작업 부하 변동성을 정확하게 복제할 수 있다.
느슨하게 결합된 아키텍처 구현(예: SOA)은 성능 테스트에 추가적인 복잡성을 야기했다. 생산과 유사한 상태를 진정으로 복제하려면 공통 인프라 또는 플랫폼을 공유하는 엔터프라이즈 서비스 또는 자산은 모든 소비자가 생산과 유사한 트랜잭션 볼륨 및 공유 인프라 또는 플랫폼에 부하를 생성하는 조정된 성능 테스트를 요구한다. 이 활동은 돈과 시간 면에서 매우 복잡하고 비용이 많이 들기 때문에 일부 조직에서는 이제 성능 테스트 환경(PTE)에서 생산과 유사한 조건(일명 "노이즈")을 모니터링하고 시뮬레이션하는 도구를 사용하여 용량 및 리소스 요구 사항을 이해하고 품질 속성을 확인/검증한다.
새로운 시스템의 비용 성능에 있어 성능 테스트 노력이 개발 프로젝트의 시작부터 배포까지 확장되는 것이 중요하다. 성능 결함이 늦게 감지될수록 개선 비용이 더 높아진다. 이는 기능 테스트의 경우에도 마찬가지이지만, 범위의 엔드-투-엔드 특성 때문에 성능 테스트에서는 더욱 그렇다. 성능 테스트 팀이 가능한 한 빨리 참여하는 것이 중요하다. 테스트 환경 및 기타 주요 성능 필수 요소를 획득하고 준비하는 데 시간이 많이 걸리기 때문이다.
성능 테스트는 주로 두 가지 주요 범주로 나뉜다:
성능 스크립팅.
성능 테스트의 이 부분은 주로 주요 식별된 비즈니스 프로세스의 작업 흐름을 생성/스크립팅하는 것과 관련이 있다. 이는 다양한 도구를 사용하여 수행할 수 있다.
위 목록에 언급된 각 도구(포괄적이거나 완전하지 않음)는 스크립팅 언어(C, Java, JS) 또는 일부 형태의 시각적 표현(드래그 앤 드롭)을 사용하여 최종 사용자 작업 흐름을 생성하고 시뮬레이션한다. 대부분의 도구는 "기록 및 재생"이라는 기능을 허용하며, 성능 테스터가 테스트 도구를 실행하고 브라우저 또는 두꺼운 클라이언트에 연결하여 클라이언트와 서버 간에 발생하는 모든 네트워크 트랜잭션을 캡처한다. 이렇게 함으로써 다양한 비즈니스 시나리오를 에뮬레이션하기 위해 향상/수정될 수 있는 스크립트가 개발된다.
성능 모니터링.
이것은 성능 테스트의 다른 측면을 형성한다. 성능 모니터링을 통해 테스트 중인 응용 프로그램의 동작 및 응답 특성이 관찰된다. 아래 매개변수는 일반적으로 성능 테스트 실행 중에 모니터링된다.
서버 하드웨어 매개변수
첫 번째 단계로, 이 네 가지 매개변수에 의해 생성된 패턴은 병목 현상이 어디에 있는지에 대한 좋은 지표를 제공한다. 문제의 정확한 근본 원인을 파악하기 위해 소프트웨어 엔지니어는 프로파일러와 같은 도구를 사용하여 장치 또는 소프트웨어의 어떤 부분이 성능 저하에 가장 큰 영향을 미치는지 측정하거나, 허용 가능한 응답 시간을 유지하기 위한 처리량 수준(및 임계값)을 설정한다.
성능 테스트 기술은 하나 이상의 PC 또는 유닉스 서버를 주입기로 사용하여, 각각 여러 사용자의 존재를 에뮬레이트하고 각각 자동화된 상호작용 시퀀스(스크립트로 기록되거나 다른 유형의 사용자 상호작용을 에뮬레이트하는 일련의 스크립트로 기록됨)를 실행하여 성능을 테스트할 호스트와 상호작용한다. 일반적으로 별도의 PC가 테스트 지휘자 역할을 하여 각 주입기로부터 메트릭을 조율하고 수집하며 보고 목적으로 성능 데이터를 수집한다. 일반적인 시퀀스는 부하를 증가시키는 것이다. 즉, 소수의 가상 사용자로 시작하여 시간이 지남에 따라 미리 정해진 최대로 사용자 수를 늘리는 것이다. 테스트 결과는 사용자 수 대 응답 시간으로 주어지는 부하에 따라 성능이 어떻게 달라지는지 보여준다. 이러한 테스트를 수행하기 위한 다양한 도구가 있다. 이 범주의 도구는 일반적으로 시스템에 대해 실제 사용자를 에뮬레이트하는 일련의 테스트를 실행한다. 때로는 결과가 이상한 점을 드러낼 수 있다. 예를 들어, 평균 응답 시간은 허용될 수 있지만, 몇 가지 주요 트랜잭션의 특이값이 완료하는 데 훨씬 더 오래 걸리는 경우가 있다. 이는 비효율적인 데이터베이스 쿼리, 그림 등으로 인해 발생할 수 있다.
성능 테스트는 스트레스 테스트와 결합하여 허용 가능한 부하가 초과될 때 어떤 일이 발생하는지 확인할 수 있다. 시스템이 충돌하는가? 큰 부하가 줄어들면 복구하는 데 얼마나 걸리는가? 실패가 부수적인 피해를 초래하는가?
분석 성능 모델링은 스프레드시트에서 시스템의 동작을 모델링하는 방법이다. 모델은 트랜잭션 리소스 요구(CPU, 디스크 I/O, LAN, WAN) 측정값에 트랜잭션 혼합(시간당 비즈니스 트랜잭션)으로 가중치를 부여하여 공급된다. 가중 트랜잭션 리소스 요구는 시간당 리소스 요구를 얻기 위해 합산되고 시간당 리소스 용량으로 나누어 리소스 부하를 얻는다. 응답 시간 공식(R=S/(1-U), R=응답 시간, S=서비스 시간, U=부하)을 사용하여 응답 시간을 계산하고 성능 테스트 결과와 함께 보정할 수 있다. 분석 성능 모델링은 실제 또는 예상 비즈니스 사용을 기반으로 설계 옵션 및 시스템 크기 조정을 평가할 수 있도록 한다. 따라서 성능 테스트보다 훨씬 빠르고 저렴하지만 하드웨어 플랫폼에 대한 철저한 이해가 필요하다.
수행할 작업.
이러한 테스트를 수행하기 위한 작업은 다음과 같다.
웹 애플리케이션 성능 테스트.
마이크로소프트 개발자 네트워크에 따르면 성능 테스트 방법론은 다음 활동으로 구성된다.
부하 테스트(load testing) 또는 스트레스 테스트라는 용어는 전문 소프트웨어 테스트 커뮤니티에서 다양하게 사용된다. 부하 테스트는 일반적으로 여러 사용자가 동시에 프로그램에 액세스하는 것을 시뮬레이션하여 소프트웨어 프로그램의 예상 사용량을 모델링하는 방식을 의미한다. 따라서 이 테스트는 다중 사용자 시스템, 특히 웹 서버와 같은 클라이언트/서버 모델을 사용하여 구축된 시스템에 가장 관련성이 높다. 그러나 다른 유형의 소프트웨어 시스템도 부하 테스트를 할 수 있다. 예를 들어, 워드 프로세서 또는 그래픽 편집기가 매우 큰 문서를 읽도록 강제할 수 있으며, 금융 패키지가 수년치 데이터를 기반으로 보고서를 생성하도록 강제할 수 있다. 가장 정확한 부하 테스트는 이론적 또는 분석적 모델링을 사용하는 대신 실제 사용을 시뮬레이션한다.
부하 테스트를 통해 실제 고객 행동을 기반으로 웹사이트의 서비스 품질 (QOS) 성능을 측정할 수 있다. 거의 모든 부하 테스트 도구와 프레임워크는 고전적인 부하 테스트 패러다임을 따른다. 고객이 웹사이트를 방문하면 스크립트 레코더가 통신을 기록하고 관련 상호 작용 스크립트를 생성한다. 부하 생성기는 기록된 스크립트를 재생하려고 시도하며, 재생 전에 다른 테스트 매개변수로 수정될 수 있다. 재생 절차에서 하드웨어 및 소프트웨어 통계는 모두 지휘자에 의해 모니터링되고 수집되며, 이러한 통계에는 물리적 서버의 CPU, 메모리, 디스크 IO 및 테스트 대상 시스템 (SUT)의 응답 시간, 처리량 등이 포함된다. 마지막으로 이 모든 통계가 분석되어 부하 테스트 보고서가 생성된다.
부하 및 성능 테스트는 다양한 수의 가상 및 실제 사용자를 대상으로 소프트웨어를 테스트하고 이러한 다른 부하에서 성능 측정값을 모니터링하여 다중 사용자 대상 소프트웨어를 분석한다. 부하 및 성능 테스트는 일반적으로 소프트웨어 시스템이 운영 환경에 배포되기 전에 생산 환경과 동일한 테스트 환경에서 수행된다.
부하 테스트의 목표:
예를 들어, 쇼핑 카트 기능을 갖춘 웹사이트는 다음 활동으로 나뉜 100명의 동시 사용자를 지원해야 한다.
테스트 분석가는 다양한 부하 테스트 도구를 사용하여 이러한 VUser와 그 활동을 생성할 수 있다. 테스트가 시작되어 안정 상태에 도달하면 위에서 설명한 100 VUser 부하에서 애플리케이션이 테스트된다. 그런 다음 애플리케이션의 성능을 모니터링하고 캡처할 수 있다.
부하 테스트 계획 또는 테스트 스크립트의 세부 사항은 일반적으로 조직마다 다르다. 예를 들어, 위 글머리 기호 목록에서 첫 번째 항목은 개발된 테스트 계획 또는 스크립트에 따라 25 VUser가 고유 항목, 무작위 항목 또는 선택된 항목 집합을 탐색하는 것을 나타낼 수 있다. 그러나 모든 부하 테스트 계획은 예상되는 최고 워크플로우 및 볼륨 범위에 걸쳐 시스템 성능을 시뮬레이션하려고 시도한다. 부하 테스트 통과 또는 실패 기준(통과/실패 기준) 또한 조직마다 일반적으로 다르다. 허용 가능한 부하 테스트 성능 메트릭을 지정하는 표준은 없다.
일반적인 오해는 부하 테스트 소프트웨어가 회귀 테스트 도구와 같은 기록 및 재생 기능을 제공한다는 것이다. 부하 테스트 도구는 전체 OSI 프로토콜 스택을 분석하는 반면, 대부분의 회귀 테스트 도구는 GUI 성능에 중점을 둔다. 예를 들어, 회귀 테스트 도구는 웹 브라우저에서 버튼의 마우스 클릭을 기록하고 재생하지만, 부하 테스트 도구는 사용자가 버튼을 클릭한 후 웹 브라우저가 보내는 하이퍼텍스트를 보낸다. 다중 사용자 환경에서 부하 테스트 도구는 각 사용자가 고유한 로그인 ID, 암호 등을 가지고 여러 사용자에게 하이퍼텍스트를 보낼 수 있다.
사용 가능한 인기 있는 부하 테스트 도구는 느린 성능의 원인에 대한 통찰력도 제공한다. 느린 시스템 성능의 원인은 다음과 같은 것을 포함하지만 이에 국한되지 않는다.
부하 테스트는 애플리케이션, 시스템 또는 서비스가 서비스 수준 협약 또는 SLA의 적용을 받는 경우 특히 중요하다.
부하 테스트는 정상 부하 조건과 예상되는 최고 부하 조건 모두에서 시스템의 동작을 결정하기 위해 수행된다. 이는 애플리케이션의 최대 작동 용량뿐만 아니라 병목 현상을 식별하고 어떤 요소가 성능 저하를 일으키는지 결정하는 데 도움이 된다. 시스템에 가해지는 부하가 비정상적으로 높거나 최고 부하에서 시스템의 응답을 테스트하기 위해 정상적인 사용 패턴을 초과하여 증가하면 이를 스트레스 테스트라고 한다. 부하는 일반적으로 오류 조건이 예상되는 결과일 정도로 크지만, 활동이 부하 테스트를 중단하고 스트레스 테스트가 되는 명확한 경계는 없다.
"부하 테스트"라는 용어는 특정 시나리오에 대해 동시성 테스트, 소프트웨어 성능 테스트, 신뢰성 테스트, 볼륨 테스트와 종종 동의어로 사용된다. 이 모든 것은 특정 소프트웨어의 사용 적합성을 검증하는 데 사용되는 기능 테스트의 일부가 아닌 비기능 테스트 유형이다.
부하 테스트 시 사용자 경험.
위 예시에서 피시험 장치 (DUT)가 프로덕션 부하(100 VUser)에 있을 때 대상 애플리케이션을 실행한다. 여기서 대상 애플리케이션의 성능은 부하 시 사용자 경험이 된다. 이는 DUT가 얼마나 빠르게 또는 느리게 반응하는지, 그리고 사용자가 성능을 얼마나 만족하거나 실제로 인식하는지 설명한다.
브라우저 수준 vs. 프로토콜 수준 사용자.
역사적으로 모든 부하 테스트는 프로토콜 계층에서 동시 상호 작용을 통해 트래픽을 시뮬레이션하는 자동화된 API 테스트(종종 프로토콜 수준 사용자 또는 PLU라고 함)로 수행되었다. 컨테이너와 클라우드 인프라의 발전으로 이제 실제 브라우저(종종 브라우저 수준 사용자 또는 BLU라고 함)로 테스트할 수 있는 옵션이 생겼다. 각 접근 방식은 다른 유형의 애플리케이션에 대해 장점이 있지만, 일반적으로 브라우저 수준 사용자는 웹사이트가 경험할 실제 트래픽에 더 가깝고 더 현실적인 부하 프로필 및 응답 시간 측정을 제공한다. BLU는 확실히 테스트를 실행하는 데 더 비싼 방법이며 모든 유형의 애플리케이션, 특히 웹 브라우저를 통해 액세스할 수 없는 데스크톱 클라이언트 또는 API 기반 애플리케이션과 같은 애플리케이션에서는 작동할 수 없다.
긴급 할당량법()은 1921년 긴급 이민법(Emergency Immigration Act of 1921), 1921년 이민 제한법(Immigration Restriction Act of 1921), 백분율법(Per Centum Law), 존슨 할당량법(Johnson Quota Act)(ch. 8, of 1921년 5월 19일)으로도 알려져 있으며, 주로 남유럽과 동유럽으로부터의 대규모 이민 유입에 대한 대응으로 제정되어 미국의 이민을 제한했다. 비록 임시 법률로 의도되었지만, 이는 "결과적으로 미국 이민 정책에서 가장 중요한 전환점"이었다. 왜냐하면 이 법은 미국 이민법에 두 가지 새로운 특징을 추가했기 때문이다. 그것은 이민에 대한 수치적 제한과 이러한 제한을 설정하기 위한 할당량 시스템의 사용이었는데, 이는 국가별 출신 쿼터로 알려지게 되었다.
긴급 할당량법은 매년 어떤 국가에서든 입국이 허용되는 이민자의 수를 1910년 미국 인구 조사 기준으로 해당 국가 출신 미국 거주자 수의 3%로 제한했다. 이는 북유럽과 서유럽 출신 사람들이 동유럽이나 남유럽 또는 비유럽 국가 출신 사람들보다 더 높은 할당량을 가지고 있었고 미국 입국 가능성이 더 높았다는 것을 의미했다.
그러나 전문직 종사자는 출신 국가에 관계없이 입국이 허용되었다. 또한 캐나다, 뉴펀들랜드, 쿠바, 멕시코, 중남미 국가 또는 "인접 섬"으로부터의 이민에는 제한이 없었다. 이 법은 미국과 양자 협정을 맺은 국가나 1917년 이민법, 즉 아시아 제외 지역법에 나열된 아시아 국가에는 적용되지 않았다.