hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
웹 테스트 웹 애플리케이션 성능 도구
웹 애플리케이션 성능 도구(WAPT)는 웹 애플리케이션 및 웹 관련 인터페이스를 테스트하는 데 사용된다. 이 도구들은 웹 애플리케이션, 웹사이트, 웹 API, 웹 서버 및 기타 웹 인터페이스의 성능, 부하 및 스트레스 테스트에 사용된다. WAPT는 기록된 URL 또는 지정된 URL을 반복하는 가상 사용자를 시뮬레이션하고, 가상 사용자가 기록된 URL을 반복해야 하는 횟수 또는 반복 횟수를 지정할 수 있도록 한다. 이를 통해 이 도구는 테스트 중인 웹사이트 또는 웹 애플리케이션의 병목 현상 및 성능 누출을 확인하는 데 유용하다.
WAPT는 테스트 중 다양한 문제에 직면하며 다음 사항에 대한 테스트를 수행할 수 있어야 한다.
WAPT를 사용하면 가상 사용자가 테스트 환경에 어떻게 참여하는지 지정할 수 있다. 즉, 사용자 증가, 고정 사용자 또는 주기적인 사용자 부하 등이다. 사용자 부하를 단계별로 증가시키는 것을 램프(RAMP)라고 하며, 가상 사용자가 0명에서 수백 명으로 증가한다. 고정 사용자 부하는 지정된 사용자 부하를 항상 유지한다. 주기적인 사용자 부하는 사용자 부하를 수시로 증가시키고 감소시키는 경향이 있다.
웹 테스트 웹 보안 테스트
웹 보안 테스트는 웹 기반 애플리케이션이 악의적인 입력 데이터를 받았을 때 요구 사항을 충족하는지 여부를 알려준다.
파이어폭스용 웹 애플리케이션 보안 테스트 플러그인 모음이 있다.
웹 테스트 웹 API 테스트
API는 다른 소프트웨어 구성 요소에 서비스를 노출하며, 이 구성 요소는 API를 쿼리할 수 있다. API 구현은 서비스를 계산하고 쿼리를 보낸 구성 요소에 결과를 반환하는 역할을 한다. 웹 테스트의 일부는 이러한 웹 API 구현을 테스트하는 데 초점을 맞춘다.
GraphQL은 특정 쿼리 및 API 언어이다. 이는 맞춤형 테스트 기술의 초점이다. 검색 기반 테스트 생성은 GraphQL API용 테스트 케이스를 생성하는 데 좋은 결과를 산출한다.
웹 테스트 더 읽어보기
James A. Whittaker: How to Break Web Software: Functional and Security Testing of Web Applications and Web Services, Addison-Wesley Professional, February 2, 2006.  ISBN 0-321-36944-0
S. Sampath, R. Bryce, Gokulanand Viswanath, Vani Kandimalla, A. Gunes Koru. Prioritizing User-Session-Based Test Cases for Web Applications Testing. Proceedings of the International Conference on Software Testing, Verification, and Validation (ICST), Lillehammer, Norway, April 2008.
웹 테스트 더 읽어보기
"An Empirical Approach to Testing Web Applications Across Diverse Client Platform Configurations" by Cyntrica Eaton and Atif M. Memon. International Journal on Web Engineering and Technology (IJWET), Special Issue on Empirical Studies in Web Engineering, vol. 3, no. 3, 2007, pp. 227–253, Inderscience Publishers.
테스트 자동화
소프트웨어 테스트에서 테스트 자동화(test automation)는 테스트 대상 소프트웨어와는 별개의 소프트웨어를 사용하여 테스트 실행을 제어하고 실제 결과와 예측된 결과를 비교하는 것이다. 테스트 자동화는 이미 진행 중인 공식화된 테스트 프로세스에서 반복적이지만 필요한 일부 작업을 자동화하거나 수동으로 수행하기 어려운 추가 테스트를 수행할 수 있다. 테스트 자동화는 지속적 전달 및 지속적 테스트에 매우 중요하다.
테스트 자동화 일반적인 접근법
테스트 자동화에는 여러 가지 접근법이 있지만, 다음은 널리 사용되는 일반적인 접근법이다.
API 기반 테스트. 애플리케이션에 대한 프로그래밍 인터페이스를 사용하여 테스트 중인 동작을 확인하는 테스트 프레임워크. 일반적으로 API 기반 테스트는 애플리케이션 사용자 인터페이스를 완전히 건너뛴다. 또한 클래스, 모듈 또는 라이브러리에 대한 (일반적으로) 공용 인터페이스를 다양한 입력 인수로 테스트하여 반환되는 결과가 올바른지 확인할 수도 있다.
테스트 자동화 기타 접근법
테스트 케이스를 자동으로 생성하는 한 가지 방법은 테스트 케이스 생성을 위해 시스템 모델을 사용하는 모델 기반 테스트이지만, 이를 위한 다양한 대체 방법론에 대한 연구가 계속되고 있다. 어떤 경우에는 모델 기반 접근 방식을 통해 비기술적 사용자도 일반 영어로 자동화된 비즈니스 테스트 케이스를 만들 수 있으므로 여러 운영 체제, 브라우저 및 스마트 장치에 맞게 구성하는 데 어떤 종류의 프로그래밍도 필요하지 않다.
일부 소프트웨어 테스트 작업(예: 광범위한 하위 수준 인터페이스 회귀 테스트)은 수동으로 수행하기에 힘들고 시간이 많이 소요될 수 있다. 또한 수동 접근 방식은 특정 유형의 결함을 찾는 데 항상 효과적이지 않을 수 있다. 테스트 자동화는 이러한 유형의 테스트를 효과적으로 수행할 가능성을 제공한다.
자동화된 테스트가 개발되면 신속하고 반복적으로 여러 번 실행될 수 있다. 이는 유지보수 수명이 긴 소프트웨어 제품의 회귀 테스트를 위한 비용 효율적인 방법이 될 수 있다. 애플리케이션의 수명 주기 동안 사소한 패치조차도 이전에 작동하던 기존 기능이 손상될 수 있다.
테스트 자동화 기타 접근법
API 테스트는 소프트웨어 테스터들이 GUI 구현과 독립적으로 요구 사항을 검증하고, 일반적으로 개발 초기 단계에서 테스트하며, 테스트 자체도 깔끔한 코드 원칙, 특히 단일 책임 원칙을 준수하는지 확인하는 데 널리 사용되고 있다. 이는 통합 테스트의 일부로 API를 직접 테스트하여 기능성, 신뢰성, 성능 및 보안에 대한 기대치를 충족하는지 확인하는 것을 포함한다. API에는 GUI가 없으므로 API 테스트는 메시지 계층에서 수행된다. API가 애플리케이션 로직의 기본 인터페이스 역할을 할 때 API 테스트는 중요하게 간주된다.
테스트 자동화 기타 접근법
많은 테스트 자동화 도구는 기록 및 재생 기능을 제공하여 사용자가 대화식으로 사용자 작업을 기록하고 원하는 만큼 여러 번 재생하며 실제 결과를 예상 결과와 비교할 수 있도록 한다. 이 접근 방식의 장점은 소프트웨어 개발이 거의 또는 전혀 필요하지 않다는 것이다. 이 접근 방식은 그래픽 사용자 인터페이스를 가진 모든 애플리케이션에 적용할 수 있다. 그러나 이러한 기능에 의존하는 것은 주요 신뢰성 및 유지보수 문제를 야기한다. 버튼의 레이블을 변경하거나 창의 다른 부분으로 이동하면 테스트를 다시 기록해야 할 수 있다. 기록 및 재생은 또한 종종 관련 없는 활동을 추가하거나 일부 활동을 잘못 기록하기도 한다.
이러한 유형의 도구의 변형은 웹 사이트 테스트를 위한 것이다. 여기서 "인터페이스"는 웹 페이지이다. 그러나 이러한 프레임워크는 운영 체제 이벤트 대신 HTML을 렌더링하고 DOM 이벤트를 수신하기 때문에 완전히 다른 기술을 사용한다. 일반적으로 이 목적을 위해 헤드리스 브라우저 또는 셀레늄 웹 드라이버 기반 솔루션이 사용된다.
이러한 유형의 테스트 자동화 도구의 또 다른 변형은 모바일 애플리케이션 테스트용이다. 모바일 폰에서 사용되는 다양한 크기, 해상도 및 운영 체제를 고려할 때 매우 유용하다. 이 변형의 경우, 모바일 장치에서 작업을 인스턴스화하고 작업 결과를 수집하기 위해 프레임워크가 사용된다.
또 다른 변형은 기록 및 재생을 사용하지 않는 스크립트 없는 테스트 자동화이지만, 대신 애플리케이션 모델을 구축한 다음 테스터가 테스트 매개변수와 조건을 단순히 삽입하여 테스트 케이스를 생성할 수 있도록 하여 스크립팅 기술이 필요하지 않다.
테스트 자동화 방법론
주로 유닛 테스트를 사용하는 테스트 자동화는 익스트림 프로그래밍 및 애자일 소프트웨어 개발의 핵심 기능으로, 테스트 주도 개발(TDD) 또는 테스트 우선 개발로 알려져 있다. 유닛 테스트는 코드가 작성되기 전에 기능을 정의하기 위해 작성될 수 있다. 그러나 이러한 유닛 테스트는 코딩이 진행되고, 문제가 발견되고, 코드가 리팩터링될 때 진화하고 확장된다. 요구되는 모든 기능에 대한 모든 테스트가 통과될 때만 코드는 완성된 것으로 간주된다. 옹호자들은 이것이 수동 탐색으로 테스트되는 코드보다 더 안정적이고 비용이 적게 드는 소프트웨어를 생산한다고 주장한다. 코드 커버리지가 더 좋고, 폭포수 모델 개발 주기 끝에 한 번 실행되는 대신 개발 중에 지속적으로 실행되기 때문에 더 신뢰할 수 있는 것으로 간주된다. 개발자는 변경 즉시 결함을 발견하며, 이때 수정하는 것이 가장 저렴하다. 마지막으로, 유닛 테스트를 사용할 때 리팩터링이 더 안전하다. 코드를 코드 중복이 적고 동등한 동작을 가진 더 간단한 형태로 변환하는 것은 리팩터링된 코드가 유닛 테스트로 커버될 때 새로운 결함을 도입할 가능성이 훨씬 적다.
테스트 자동화 방법론
지속적 테스트는 소프트웨어 릴리스 후보와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 전달 파이프라인의 일부로 자동화된 테스트를 실행하는 프로세스이다. 지속적 테스트의 경우 테스트 범위는 상향식 요구 사항 또는 사용자 스토리를 검증하는 것에서부터 전반적인 비즈니스 목표와 관련된 시스템 요구 사항을 평가하는 것까지 확장된다.
테스트 자동화 고려 사항
무엇을 자동화할지, 언제 자동화할지, 심지어 자동화가 정말 필요한지 여부는 테스트(또는 개발) 팀이 내려야 하는 중요한 결정이다. 52개의 실무자 출처와 26개의 학술 출처를 대상으로 한 다중음성 문헌 검토 결과, 테스트 자동화 결정에 고려해야 할 다섯 가지 주요 요소는 다음과 같다: 1) 테스트 대상 시스템(SUT), 2) 테스트 유형 및 수, 3) 테스트 도구, 4) 인적 및 조직적 주제, 5) 교차적 요소. 연구에서 가장 자주 식별된 개별 요소는 회귀 테스트의 필요성, 경제적 요인, SUT의 성숙도였다.
자동화된 테스트의 재사용성은 소프트웨어 개발 회사에서 중요하게 여기지만, 이 속성은 단점으로도 볼 수 있다. 이는 반복적으로 실행되는 스크립트가 프레임워크를 넘어선 오류를 감지하지 못하게 되는 이른바 "살충제 역설"을 초래한다. 이러한 경우 수동 테스트가 더 나은 투자가 될 수 있다. 이러한 모호성은 프로젝트 요구사항과 특성을 고려하여 테스트 자동화 결정을 개별적으로 내려야 한다는 결론으로 다시 이어진다.
테스트 자동화 고려 사항
테스트 도구는 제품 설치, 테스트 데이터 생성, GUI 상호 작용, 문제 감지(테스트 오라클을 갖춘 파싱 또는 폴링 에이전트 고려), 결함 로깅 등과 같은 작업을 자동화하는 데 도움이 될 수 있으며, 반드시 종단 간 방식으로 테스트를 자동화할 필요는 없다.
테스트 자동화를 생각할 때 인기 있는 요구 사항을 계속 충족해야 한다.
테스트 자동화 역할
테스트 자동화 도구는 비용이 많이 들 수 있으며, 일반적으로 수동 테스트와 함께 사용된다. 테스트 자동화는 장기적으로, 특히 회귀 테스트에서 반복적으로 사용될 때 비용 효율적일 수 있다. 테스트 자동화에 적합한 후보는 애플리케이션의 일반적인 흐름에 대한 테스트 케이스이다. 이는 애플리케이션이 향상될 때마다 (회귀 테스트를 통해) 실행되어야 하기 때문이다. 테스트 자동화는 수동 테스트와 관련된 노력을 줄여준다. 자동화된 검사를 개발하고 유지 관리하며 테스트 결과를 검토하는 데는 수동 노력이 필요하다.
자동화된 테스트에서 테스트 엔지니어 또는 소프트웨어 품질보증 담당자는 소프트웨어 코딩 능력을 갖추어야 한다. 테스트 케이스는 실행될 때 포함된 어설션에 따라 출력을 생성하는 소스 코드 형태로 작성되기 때문이다. 일부 테스트 자동화 도구는 코딩 대신 키워드로 테스트 작성을 허용하여 프로그래밍이 필요하지 않다.
테스트 자동화 다양한 수준에서의 테스트
테스트 자동화량을 결정하는 전략은 테스트 자동화 피라미드이다. 이 전략은 서로 다른 세분화 수준을 가진 세 가지 유형의 테스트를 작성할 것을 제안한다. 수준이 높을수록 작성할 테스트 양은 줄어든다.
테스트 피라미드의 한 가지 개념은 유닛, 통합, 종단 간 유닛 테스트를 포함한다. 구글의 테스트 블로그에 따르면, 유닛 테스트가 테스트 전략의 대부분을 차지해야 하며, 통합 테스트는 더 적게, 종단 간 테스트는 아주 적게 구성해야 한다.
테스트 자동화 자동화에서의 프레임워크 접근법
테스트 자동화 프레임워크는 특정 제품의 자동화 규칙을 설정하는 통합 시스템이다. 이 시스템은 함수 라이브러리, 테스트 데이터 소스, 객체 세부 정보 및 다양한 재사용 가능한 모듈을 통합한다. 이러한 구성 요소는 비즈니스 프로세스를 나타내기 위해 조립해야 하는 작은 빌딩 블록 역할을 한다. 이 프레임워크는 테스트 자동화의 기반을 제공하고 자동화 노력을 단순화한다.
자동화된 소프트웨어 테스트를 지원하는 가정, 개념 및 도구의 프레임워크의 주요 장점은 유지보수 비용이 저렴하다는 것이다. 어떤 테스트 케이스에 변경이 발생하면 테스트 케이스 파일만 업데이트하면 되고 드라이버 스크립트와 시작 스크립트는 동일하게 유지된다. 이상적으로는 애플리케이션 변경 시 스크립트를 업데이트할 필요가 없다.
올바른 프레임워크/스크립팅 기술을 선택하는 것은 비용을 낮게 유지하는 데 도움이 된다. 테스트 스크립팅과 관련된 비용은 개발 및 유지 관리 노력 때문이다. 테스트 자동화에 사용되는 스크립팅 접근 방식은 비용에 영향을 미친다.
테스트 자동화 자동화에서의 프레임워크 접근법
일반적으로 다양한 프레임워크/스크립팅 기술이 사용된다:
테스트 프레임워크는 다음을 담당한다.
소프트웨어 개발에서 증가하는 추세는 유닛 테스트 프레임워크, 예를 들어 xUnit 프레임워크(예: JUnit 및 NUnit)의 사용이다. 이 프레임워크는 유닛 테스트 실행을 허용하여 코드의 다양한 섹션이 다양한 상황에서 예상대로 작동하는지 여부를 결정한다. 테스트 케이스는 프로그램이 예상대로 실행되는지 확인하기 위해 프로그램에서 실행되어야 하는 테스트를 설명한다.
테스트 자동화 인터페이스는 테스트 대상 애플리케이션의 시스템/통합 테스트를 위해 여러 테스트 도구와 프레임워크를 통합하기 위한 단일 작업 공간을 제공하는 플랫폼이다. 테스트 자동화 인터페이스의 목표는 코딩이 프로세스를 방해하지 않고 테스트를 비즈니스 기준에 매핑하는 프로세스를 단순화하는 것이다. 테스트 자동화 인터페이스는 테스트 스크립트 유지 관리의 효율성과 유연성을 향상시킬 것으로 기대된다.
테스트 자동화 자동화에서의 프레임워크 접근법
테스트 자동화 인터페이스는 다음 핵심 모듈로 구성된다.
인터페이스 엔진은 인터페이스 환경 위에 구축된다. 인터페이스 엔진은 구문 분석기와 테스트 실행기로 구성된다. 구문 분석기는 객체 저장소에서 오는 객체 파일을 테스트별 스크립팅 언어로 구문 분석하기 위해 존재한다. 테스트 실행기는 테스트 하네스를 사용하여 테스트 스크립트를 실행한다.
객체 저장소는 테스트 도구가 테스트 중인 애플리케이션을 탐색하면서 기록한 UI/애플리케이션 객체 데이터 모음이다.
테스트 자동화 자동화 프레임워크와 테스트 도구 간의 경계 정의
도구는 Windows 및 웹 자동화 도구 등 특정 테스트 환경을 대상으로 특별히 설계되었다. 도구는 자동화 프로세스의 구동 에이전트 역할을 한다. 그러나 자동화 프레임워크는 특정 작업을 수행하는 도구가 아니라 다른 도구가 통합된 방식으로 작업을 수행할 수 있는 솔루션을 제공하는 인프라이다. 이는 자동화 엔지니어에게 공통 플랫폼을 제공한다.
다양한 유형의 프레임워크가 있다. 이들은 활용하는 자동화 구성 요소에 따라 분류된다.
모델 기반 테스트
모델 기반 테스트(Model-based testing)는 모델 기반 설계를 적용하여 소프트웨어 테스트 또는 시스템 검사를 수행하기 위한 아티팩트를 설계하고 선택적으로 실행하는 방법이다. 모델은 테스트 대상 시스템(SUT)의 원하는 동작을 나타내거나 테스트 전략 및 테스트 환경을 나타내는 데 사용될 수 있다. 오른쪽 그림은 전자의 접근 방식을 묘사한다.
모델 기반 테스트
SUT를 설명하는 모델은 일반적으로 SUT의 원하는 동작을 추상적이고 부분적으로 표현한 것이다. 이러한 모델에서 파생된 테스트 케이스는 모델과 동일한 추상화 수준의 기능 테스트이다. 이러한 테스트 케이스는 통칭하여 추상 테스트 스위트라고 불린다. 추상 테스트 스위트는 추상화 수준이 맞지 않기 때문에 SUT에 대해 직접 실행될 수 없다. 실행 가능한 테스트 스위트는 해당 추상 테스트 스위트에서 파생되어야 한다. 실행 가능한 테스트 스위트는 테스트 대상 시스템과 직접 통신할 수 있다. 이는 추상 테스트 케이스를 실행에 적합한 구체적인 테스트 케이스로 매핑함으로써 달성된다. 일부 모델 기반 테스트 환경에서는 모델에 실행 가능한 테스트 스위트를 직접 생성하기에 충분한 정보가 포함되어 있다. 다른 환경에서는 추상 테스트 스위트의 요소가 소프트웨어의 특정 명령문이나 메서드 호출에 매핑되어 구체적 테스트 스위트를 생성해야 한다. 이를 "매핑 문제" 해결이라고 한다. 온라인 테스트(아래 참조)의 경우, 추상 테스트 스위트는 개념적으로만 존재하며 명시적인 아티팩트로는 존재하지 않는다.
테스트는 여러 가지 방법으로 모델에서 파생될 수 있다. 테스트는 일반적으로 실험적이며 휴리스틱에 기반을 두기 때문에, 테스트 파생을 위한 단일 최상의 접근 방식은 알려져 있지 않다. 모든 테스트 파생 관련 매개변수를 종종 "테스트 요구사항", "테스트 목적" 또는 심지어 "사용 사례"라고 알려진 패키지로 통합하는 것이 일반적이다. 이 패키지는 모델의 어떤 부분에 집중해야 하는지에 대한 정보나 테스트 종료 조건(테스트 중지 기준)을 포함할 수 있다.
테스트 스위트가 소스 코드에서가 아닌 모델에서 파생되기 때문에, 모델 기반 테스트는 일반적으로 블랙박스 검사의 한 형태로 간주된다.
복잡한 소프트웨어 시스템을 위한 모델 기반 테스트는 여전히 발전 중인 분야이다.
모델 기반 테스트 모델
특히 모델 기반 개발이나 OMG의 모델 구동형 아키텍처에서는 모델이 해당 시스템과 병행하여 또는 그 전에 구축된다. 모델은 완성된 시스템에서 구축될 수도 있다. 테스트 생성을 위한 일반적인 모델링 언어로는 UML, SysML, 주류 프로그래밍 언어, 유한 상태 기계 표기법, 그리고 Z, B (Event-B), 알로이 또는 Coq와 같은 수학적 형식론이 있다.
모델 기반 테스트 모델 기반 테스트 배포
모델 기반 테스트를 배포하는 여러 가지 알려진 방법이 있으며, 여기에는 온라인 테스트, 실행 가능한 테스트의 오프라인 생성, 그리고 수동으로 배포 가능한 테스트의 오프라인 생성이 포함된다.
온라인 테스트는 모델 기반 테스트 도구가 SUT에 직접 연결하여 동적으로 테스트하는 것을 의미한다.
실행 가능한 테스트의 오프라인 생성은 모델 기반 테스트 도구가 테스트 케이스를 나중에 자동으로 실행할 수 있는 컴퓨터 판독 가능한 자산으로 생성하는 것을 의미한다. 예를 들어, 생성된 테스트 로직을 구현하는 파이썬 클래스 모음 등이 있다.
수동으로 배포 가능한 테스트의 오프라인 생성은 모델 기반 테스트 도구가 테스트 케이스를 나중에 수동 테스트에 도움이 될 수 있는 사람이 읽을 수 있는 자산으로 생성하는 것을 의미한다. 예를 들어, 생성된 테스트 단계를 설명하는 PDF 문서 등이 있다.
모델 기반 테스트 알고리즘을 이용한 테스트 도출
모델 기반 테스트의 효과는 주로 제공하는 자동화 가능성 때문이다. 모델이 기계 판독 가능하고 잘 정의된 동작 해석을 가질 정도로 형식적이라면, 테스트 케이스는 원칙적으로 기계적으로 도출될 수 있다.
종종 모델은 유한 상태 기계나 상태 전이 시스템으로 번역되거나 해석된다. 이 오토마톤은 테스트 대상 시스템의 가능한 구성을 나타낸다. 테스트 케이스를 찾기 위해 오토마톤에서 실행 가능한 경로를 탐색한다. 가능한 실행 경로는 테스트 케이스로 사용될 수 있다. 이 방법은 모델이 결정론적이거나 결정론적으로 변환될 수 있는 경우에 작동한다. 이러한 모델에서 지정되지 않은 전환을 활용하여 가치 있는 비정상 테스트 케이스를 얻을 수 있다.
모델 기반 테스트 알고리즘을 이용한 테스트 도출
테스트 대상 시스템과 해당 모델의 복잡성에 따라 경로의 수는 시스템의 가능한 구성이 매우 많기 때문에 매우 클 수 있다. 적절하지만 유한한 수의 경로를 커버할 수 있는 테스트 케이스를 찾으려면 선택을 안내할 테스트 기준이 필요하다. 이 기술은 모델 기반 테스트를 시작한 논문에서 오풋(Offutt)과 압두라지크(Abdurazik)가 처음 제안했다. 테스트 케이스 생성에 대한 여러 기술이 개발되었으며 러쉬비(Rushby)에 의해 조사되었다. 테스트 기준은 테스트 교과서에서 일반 그래프로 설명된다.
정리 증명은 원래 논리적 공식의 자동 증명에 사용되었다. 모델 기반 테스트 접근 방식의 경우, 시스템은 시스템의 동작을 지정하는 술어 집합으로 모델링된다. 테스트 케이스를 도출하기 위해 모델은 테스트 대상 시스템을 설명하는 술어 집합의 유효한 해석에 대한 동치류로 분할된다. 각 클래스는 특정 시스템 동작을 설명하므로 테스트 케이스로 사용될 수 있다. 가장 간단한 분할은 선언적 정규 형식 접근 방식이며, 여기서 시스템의 동작을 설명하는 논리적 표현식은 선언적 정규 형식으로 변환된다.
모델 기반 테스트 알고리즘을 이용한 테스트 도출
제약 프로그래밍은 변수 집합에 대한 제약 조건을 해결함으로써 특정 제약 조건을 만족하는 테스트 케이스를 선택하는 데 사용될 수 있다. 시스템은 제약 조건으로 설명된다. 제약 조건 집합의 해결은 부울 해결기(충족 가능성 문제 기반 SAT-해결기 등) 또는 가우스 소거법과 같은 수치해석학을 통해 수행될 수 있다. 제약 조건 공식을 해결하여 찾은 솔루션은 해당 시스템의 테스트 케이스로 사용될 수 있다.
제약 프로그래밍은 기호 실행과 결합될 수 있다. 이 접근 방식에서는 시스템 모델이 기호적으로 실행된다. 즉, 다른 제어 경로에 대한 데이터 제약 조건을 수집한 다음 제약 프로그래밍 방법을 사용하여 제약 조건을 해결하고 테스트 케이스를 생성한다.
모델 기반 테스트 알고리즘을 이용한 테스트 도출
모델 검증기는 테스트 케이스 생성에도 사용될 수 있다. 원래 모델 검증은 사양의 속성이 모델에서 유효한지 확인하는 기술로 개발되었다. 테스트에 사용될 때, 테스트 대상 시스템의 모델과 테스트할 속성이 모델 검증기에 제공된다. 이 속성이 모델에서 유효한지 증명하는 절차 내에서 모델 검증기는 증거와 반례를 감지한다. 증거는 속성이 만족되는 경로인 반면, 반례는 모델 실행에서 속성이 위반되는 경로이다. 이러한 경로는 다시 테스트 케이스로 사용될 수 있다.
마르코프 연쇄는 모델 기반 테스트를 처리하는 효율적인 방법이다. 마르코프 연쇄로 구현된 테스트 모델은 사용 모델로 이해될 수 있다. 이를 사용/통계 모델 기반 테스트라고 한다. 사용 모델, 즉 마르코프 연쇄는 주로 두 가지 아티팩트로 구성된다. 테스트 대상 시스템의 모든 가능한 사용 시나리오를 나타내는 유한 상태 기계(FSM)와 시스템이 통계적으로 어떻게 사용되거나 사용될 것인지를 나타내도록 FSM을 정량화하는 운영 프로필(OP)이다. 첫 번째(FSM)는 무엇을 테스트할 수 있거나 테스트했는지 아는 데 도움이 되며, 두 번째(OP)는 운영 테스트 케이스를 도출하는 데 도움이 된다.
사용/통계 모델 기반 테스트는 시스템을 철저히 테스트하는 것이 불가능하고, 매우 낮은 비율로도 오류가 발생할 수 있다는 사실에서 출발한다. 이 접근 방식은 테스트 대상 시스템의 신뢰성을 향상시키는 데 중점을 둔 테스트 케이스를 정적으로 도출하는 실용적인 방법을 제공한다. 사용/통계 모델 기반 테스트는 최근 임베디드 소프트웨어 시스템에 적용될 수 있도록 확장되었다.
모델 기반 테스트 더 읽어보기
Bringmann, E.; Krämer, A. (2008). 〈2008 International Conference on Software Testing, Verification, and Validation〉. 《2008 International Conference on Software Testing, Verification, and Validation》. International Conference on Software Testing, Verification, and Validation (ICST). 485–493쪽. CiteSeerX 10.1.1.729.8107. doi:10.1109/ICST.2008.45. ISBN 978-0-7695-3127-4.
모델 기반 테스트 더 읽어보기
Santos-Neto, P.; Resende, R.; Pádua, C. (2007). 〈Proceedings of the 2007 ACM symposium on Applied computing - SAC '07〉. 《Proceedings of the 2007 ACM symposium on Applied computing - SAC '07》. 응용 컴퓨터학 심포지엄. 1409–1415쪽. doi:10.1145/1244002.1244306. ISBN 978-1-59593-480-2.
Zander, Justyna; Schieferdecker, Ina; Mosterman, Pieter J., 편집. (2011). 《Model-Based Testing for Embedded Systems》. Computational Analysis, Synthesis, and Design of Dynamic Systems 13. 보카러톤: CRC Press. ISBN 978-1-4398-1845-9.
그레이박스 검사
그레이박스 검사 또는 그레이박스 테스트(gray-box testing, 국제 영어 철자: grey-box testing)는 화이트박스 검사와 블랙박스 검사의 조합이다. 이 테스트의 목표는 부적절한 구조나 애플리케이션의 부적절한 사용으로 인한 결함(있는 경우)을 찾아내는 것이다.
그레이박스 검사 개요
블랙박스 테스터는 테스트할 애플리케이션의 내부 구조를 알지 못하지만, 화이트박스 테스터는 애플리케이션의 내부 구조에 접근할 수 있다. 그레이박스 테스터는 내부 데이터 구조 및 사용된 알고리즘 문서를 포함하여 내부 구조를 부분적으로 알고 있다.
그레이박스 테스터는 테스트 케이스를 정의하기 위해 애플리케이션을 설명하는 상위 수준 및 상세 문서를 모두 필요로 한다.
그레이박스 검사 그레이박스 검사의 필요성
그레이박스 검사는 블랙박스 검사의 간단한 기술을 취하여 화이트박스 검사의 코드 대상 시스템과 결합하기 때문에 유익하다.
그레이박스 검사는 단언(assertion) 방법을 사용하여 프로그램이 테스트되기 전에 모든 조건을 제시하므로 요구 사항 테스트 케이스 생성에 기반을 둔다. 요구 사항 명세 언어는 요구 사항을 쉽게 이해하고 정확성을 확인하는 데 사용된다.
그레이박스 검사 객체 지향 소프트웨어에 대한 그레이박스 검사 가정
객체 지향 소프트웨어는 주로 객체로 구성된다. 여기서 객체는 실행 가능한 코드 및 데이터를 가진 단일 불가분 단위이다. 그레이박스 검사를 적용하는 데 필요한 몇 가지 가정이 아래에 명시되어 있다.
그레이박스 검사 기술
셈 캐너는 "그레이박스 검사를 입력 및 출력을 포함하지만, 테스트 설계는 일반적으로 테스터에게 보이지 않는 종류의 코드 또는 프로그램 작동에 대한 정보에 의해 교육된다"라고 정의한다. 그레이박스 검사 기술은 다음과 같다.
그레이박스 검사 응용
그레이박스 검사는 웹 애플리케이션에 매우 적합하다. 웹 애플리케이션은 분산 네트워크 또는 시스템을 가지며, 소스 코드나 바이너리가 없기 때문에 화이트박스 검사를 사용할 수 없다. 블랙박스 검사도 고객과 개발자 간의 계약 때문에 사용되지 않으므로, WSDL에 중요한 정보가 포함되어 있어 그레이박스 검사를 사용하는 것이 더 효율적이다.
그레이박스 검사 향후 범위
웹 서비스의 분산된 특성은 그레이박스 검사가 서비스 지향 아키텍처 (SOA) 내의 결함을 감지하도록 허용한다. 화이트박스 검사는 내부 구조를 직접 다루기 때문에 웹 서비스에 적합하지 않다. 화이트박스 검사는 최신 방법, 예를 들어 소스 코드나 바이너리 없이 예외 처리 상태, 흐름을 돕기 위해 대규모 배열에 대한 자동 테스트를 생성하는 메시지 변이(message mutation)에 사용될 수 있다. 이러한 전략은 그레이박스 검사를 화이트박스 검사 결과에 더 가깝게 만드는 데 유용하다.
호환성 테스트
호환성 테스트(Compatibility testing)는 다양한 컴퓨팅 환경에서 애플리케이션의 호환성을 보장하기 위해 비기능 테스트의 일환으로 수행되는 응용 소프트웨어 테스트이다.
ISO 25010 표준(시스템 및 소프트웨어 품질 모델)은 호환성을 소프트웨어 시스템이 동일한 소프트웨어 및 하드웨어를 공유하면서 다른 시스템과 정보를 교환할 수 있는 특성 또는 정도로 정의한다. 제품이 다른 제품에 해로운 영향을 주지 않으면서 다른 제품과 공통 환경 및 자원을 공유하며 필요한 기능을 효율적으로 수행할 수 있는 정도를 공존성이라 하며, 상호 운용성은 두 개 이상의 시스템, 제품 또는 구성 요소가 정보를 교환하고 교환된 정보를 사용할 수 있는 정도를 말한다. 이러한 맥락에서 호환성 테스트는 테스트 중인 시스템에서 나타나는 공존성 및 상호 운용성 정도를 결정하기 위한 제품 또는 소프트웨어 시스템에 대한 정보 수집이 될 것이다.
메가헤르츠 신화
메가헤르츠 신화(megahertz myth) 또는 최근의 경우 기가헤르츠 신화(gigahertz myth)는 클럭 속도(예를 들어 메가헤르츠 또는 기가헤르츠 단위로 측정)만을 사용하여 서로 다른 마이크로프로세서의 성능을 비교하는 오해를 말한다. 클럭 속도는 동일한 모델과 유형의 프로세서에서 서로 다른 속도의 성능을 비교하는 유효한 방법이지만, 실행 장치의 양, 파이프라인 깊이, 캐시 계층, 분기 예측 및 명령어 집합과 같은 다른 요소들은 다른 프로세서를 고려할 때 성능에 크게 영향을 미칠 수 있다. 예를 들어, 한 프로세서는 두 개의 숫자를 더하는 데 두 번의 클럭 사이클이 걸리고 세 번째 숫자로 곱하는 데 또 다른 클럭 사이클이 걸릴 수 있지만, 다른 프로세서는 동일한 계산을 두 번의 클럭 사이클 내에 수행할 수 있다. 서로 다른 유형의 프로세서 간의 비교는 작업 유형에 따라 성능이 달라지기 때문에 어렵다. 벤치마크는 컴퓨터 성능을 측정하고 비교하는 더 철저한 방법이다.
메가헤르츠 신화
이 신화는 1984년경 애플 II와 IBM PC를 비교하면서 시작되었다. IBM 컴퓨터는 인텔 8088 프로세서의 클럭 속도가 애플 II에 사용된 MOS 테크놀로지 6502의 클럭 속도보다 약 4.7배 빨랐기 때문에 애플 II보다 5배 빠르다는 주장이었다. 그러나 실제로 중요한 것은 기계의 명령어가 얼마나 미세하게 분할되어 있는지가 아니라 주어진 작업을 완료하는 데 걸리는 시간이다. LDA # (누산기 즉시 로드) 명령어를 생각해보자. 6502에서 이 명령어는 2클럭 사이클, 즉 1MHz에서 2 μs가 필요하다. 4.77 MHz 8088의 클럭 사이클은 더 짧지만, LDA #는 적어도 4클럭 사이클이 필요하므로 적어도 4 / 4.77 MHz = 0.84 μs가 걸린다. 따라서 이 명령어는 오리지널 IBM PC에서 애플 II보다 고작 2배 이상 빠른 속도로 실행된다.
메가헤르츠 신화 역사
인텔이 1978년에 출시한 x86 CISC 기반의 CPU 아키텍처는 DOS 기반의 IBM PC의 표준으로 사용되었고, 이의 발전은 마이크로소프트 윈도우 시장을 계속 지배하고 있다. IBM RISC 기반 아키텍처는 1992년에 출시된 파워PC CPU에 사용되었다. 1994년 애플 컴퓨터는 이 파워PC CPU를 사용하는 매킨토시 컴퓨터를 출시했다. 처음에는 이 아키텍처가 성능에 대한 기대를 충족시켰고, 다양한 범위의 파워PC CPU가 개발되었으며, 종종 동일한 클럭 속도에서 다른 성능을 제공했다. 비슷하게, 이 시기에는 인텔 80486과 함께 펜티엄이 판매되었는데, 펜티엄은 동일한 클럭 속도에서 80486보다 거의 두 배의 성능을 제공했다.
메가헤르츠 신화 역사
이 신화는 클럭 속도가 프로세서 성능의 간단한 척도로 흔히 받아들여졌고, 다른 요소를 고려하지 않고 광고와 열광자들에 의해 홍보되었기 때문에 생겨났다. 이 용어는 파워PC 기반 애플 매킨토시 컴퓨터와 인텔 기반 PC를 비교하는 맥락에서 사용되었다. 이 신화에 기반한 마케팅은 클럭 속도가 실제 성능보다 더 높은 우선순위를 갖게 했고, AMD가 실제 클럭 속도의 인지된 부족을 극복하기 위해 비교 성능을 기반으로 한 가상의 클럭 속도를 나타내는 모델 번호를 도입하게 했다.
파워PC와 펜티엄 간의 비교는 애플 프레젠테이션의 단골 메뉴가 되었다. 2001년 7월 18일 뉴욕 맥월드 엑스포에서 스티브 잡스는 자신의 "스티브노트"에서 867 MHz 파워PC G4가 45초 만에 작업을 완료하는 반면 1.7 GHz 펜티엄 4는 동일한 작업을 하는 데 82초가 걸렸다고 설명하며, 이를 "메가헤르츠 신화라고 이름 붙였다"고 말했다. 그는 이어서 하드웨어 담당 수석 부사장인 존 루빈스타인을 소개했는데, 루빈스타인은 더 짧은 파이프라인이 클럭 속도가 절반일 때 더 나은 성능을 제공하는 방법을 설명하는 튜토리얼을 진행했다. 온라인 만화인 조이 오브 테크는 이후 루빈스타인의 튜토리얼에서 영감을 받은 일련의 만화를 선보였다.
메가헤르츠 신화 프로세서 속도 제한
약 1995년부터 2005년까지 인텔은 AMD의 경쟁 제품과 비교하여 주로 클럭 속도만을 기준으로 펜티엄 주류 프로세서를 광고했다. 언론 기사들은 컴퓨터 프로세서가 다음 몇십 년 내에 10~20기가헤르츠만큼 빠르게 작동할 수도 있다고 예측했다.
이러한 추세는 약 2005년까지 계속되었고, 이때 펜티엄 익스트림 에디션은 거의 4기가헤르츠의 속도로 작동하면서 열 손실 한계에 도달했다. 이 프로세서는 열을 빠르게 제거하기 위해 칩 자체에 내장된 미세유체 냉각 채널과 같은 복잡한 냉각 설계 변경 없이는 더 빨라질 수 없었다.
그 후 2006년 코어 2 데스크톱 프로세서가 출시되었는데, 이는 이전 인텔 데스크톱 프로세서에서 크게 변화하여 동일한 성능을 유지하면서 프로세서 클럭을 거의 50%까지 줄일 수 있게 되었다.
코어 2는 에너지 효율이 순수 성능보다 더 중요했던 펜티엄 M 모바일 프로세서에서 시작되었으며, 처음에는 펜티엄 4와 펜티엄 D에서는 사용할 수 없었던 절전 옵션을 제공했다.
메가헤르츠 신화 더 높은 주파수
넷버스트 마이크로아키텍처와 3+ GHz CPU의 종말 이후 몇 년 동안 마이크로프로세서 클럭 속도는 처음 약 1 GHz 감소한 후 서서히 증가했다. 몇 년간의 제조 공정 및 전력 관리(특히 코어별로 클럭 속도를 설정할 수 있는 능력) 발전으로 구형 넷버스트 펜티엄 4 및 펜티엄 D보다 높거나 같은 클럭 속도를 달성했지만 훨씬 높은 효율과 성능을 제공했다. 2018년 현재, 많은 인텔 마이크로프로세서는 4 GHz의 기본 클럭 속도를 초과할 수 있다(예를 들어, 인텔 코어 i7-7700K 및 i3-7350K는 4.20 GHz의 기본 클럭 속도를 가진다).
2011년, AMD는 초기 불도저 기반 AMD FX CPU의 출시와 함께 x86 마이크로프로세서에서 처음으로 4 GHz 장벽을 돌파할 수 있었다. 2013년 6월, AMD는 최대 5.0 GHz의 속도에 도달할 수 있는 FX-9590을 출시했지만, 전력 사용 및 열 출력과 관련된 유사한 문제가 다시 발생했다.
메가헤르츠 신화 더 높은 주파수
인텔과 AMD 모두 업계에서 4 GHz 및 5 GHz 장벽을 돌파한 최초의 마이크로프로세서를 생산하지는 않았다. IBM z10은 2008년에 4.4 GHz를 달성했으며, IBM z196은 2010년에 5.2 GHz를 달성했고, 이어서 z12는 2012년 가을에 5.5 GHz를 달성했다.
스티브노트
스티브노트(Stevenote)는 애플의 전 CEO인 스티브 잡스가 애플 세계 개발자 회의, 맥월드 엑스포, 애플 엑스포와 같은 행사에서 행한 기조연설을 지칭하는 구어체 용어이다. 대부분의 애플 제품 출시는 이 기조연설에서 처음 대중에게 공개되었기 때문에, "스티브노트"는 애플의 주가에 상당한 변동을 일으켰다.
마지막 스티브노트는 2011년 6월 6일 아이클라우드(애플의 클라우드 컴퓨팅 서비스)가 발표될 때였다. OS X 라이언과 iOS 5도 같은 날 발표되었다. 이 날은 잡스가 그해 8월 24일 CEO직을 사임하고 10월 5일 사망하기 전의 마지막 대중 강연 중 하나였다.
스티브노트 역사
1996년 말, 애플은 NeXT를 인수했고, 잡스는 1985년 회사에서 강제 사임한 후 11년 만에 애플로 복귀했다. 1997년 중반, 그는 마이크로소프트 CEO 빌 게이츠의 위성 출연과 함께 회사 상태에 대한 자세한 보고서를 담은 기조연설을 했다. 잡스는 몇 가지 핵심 협정을 포함한 마이크로소프트와의 파트너십을 발표했는데, 그에 따르면 이는 애플에 이익을 가져다주고 1990년대 초중반의 장기적인 침체에서 회복할 수 있게 할 것이었다. 기조연설 동안 두 가지 주요 발표가 이루어졌다: 다음 마이크로소프트 오피스 (Office 98) 버전이 매킨토시용으로 개발될 것이며, 마이크로소프트의 인터넷 익스플로러가 매킨토시 컴퓨터의 기본 웹 브라우저가 될 것이라는 것이었다. 청중의 야유에도 불구하고 잡스는 왜 이 파트너십이 애플에 유리한지 설명했다:
스티브노트 역사
저의 생각으로는 애플과 마이크로소프트 간의 경쟁 구도를 만드는 시대는 끝났습니다. 이것은 애플을 건강하게 만들고, 애플이 업계에 엄청나게 큰 기여를 하여 다시 건강해지고 번영할 수 있도록 하는 것입니다.— 스티브 잡스, MacWorld Boston 1997 – Steve Jobs returns – Bill Gates appears on-screen, Mac History (6 August 1997), Christoph Dernbach
잡스는 이후 최소 1년에 한 번 이상 무역 박람회와 컨퍼런스에서 기조연설을 했으며, 이 자리에서 애플 제품 업데이트를 발표하거나 신제품 및 서비스를 시연했다. 다음 13년 동안의 거의 모든 제품 업그레이드 또는 발표는 스티브노트 동안 이루어졌다. 이렇게 발표된 제품으로는 1998년 오리지널 iMac 올인원 데스크톱 컴퓨터, 1999년 조개 껍질 모양의 iBook, 2000년 Mac OS X 운영 체제, 2001년 iPod 음악 플레이어, 2007년 iPhone 스마트폰, 2010년 iPad 태블릿 등이 있다.
스티브노트 형식
스티브노트 연설은 대개 주요 무역 박람회에서 진행되었다. 과거에는 샌프란시스코와 보스턴의 맥월드 컨퍼런스 & 엑스포와 파리의 애플 엑스포가 포함되었다. 그러나 애플은 두 엑스포 모두에 더 이상 전시하지 않는다. 2010년 이후, 애플이 샌프란시스코의 모스콘 센터에서 자체적으로 조직하고 개최하는 세계 개발자 회의는 애플이 전시하고 잡스가 기조연설을 한 유일한 주요 컨퍼런스였다. 최근 몇 년 동안 잡스는 애플 본사 캠퍼스의 강당에서 스티브노트를 진행했다. 과거 애플이 참석했던 대규모 무역 박람회에서 발표된 것과는 대조적으로, 이 스티브노트는 초대 전용이었고 비교적 소수의 언론인, 직원, 손님만 참석했으며, 기조연설이라기보다는 "특별 행사"라고 불렸다. 2010년 아이패드 발표와 2009년 애플의 "록앤롤" 아이팟 이벤트와 같은 유사한 스티브노트도 예르바 부에나 예술 센터에서 열렸다.
잡스는 1998년 이후 거의 모든 기조연설에서 동일한 복장을 착용하는 것으로 유명했다. 그의 의상은 보통 이세이 미야케의 검은색 긴팔 모크 터틀넥, 리바이스 501 청바지, 그리고 뉴발란스 991 운동화로 구성되었다.
스티브노트 주목할 만한 스티브노트
1998년 애플 세계 개발자 회의(WWDC) 기조연설에서 잡스는 회사가 다시 정상 궤도에 올랐다고 발표했다. 그는 애플의 재고 회전율을 검토하고 유통 시스템 및 온라인 스토어인 apple.com의 변화에 대해 설명했다. 잡스는 애플이 출시 첫 6개월 동안 Power Macintosh G3 50만 대를 판매했으며, PowerBook G3에 대해 설명하고 "스팀롤러" 광고를 보여주었다. 그는 1천만 대의 애플 컴퓨터가 소비자용으로 사용되고 있으며 6백만 명의 교육 사용자가 있다고 주장했고, iMac과 QuickTime에 대해 논의했다. 잡스는 국제 표준화 기구가 퀵타임 파일 형식을 MPEG-4의 기반으로 채택했다고 말했다. 잡스는 애플이 1998년 가을 출시될 퀵타임 3.0에 인터넷 "라이브" 스트리밍(실시간 전송 프로토콜)을 추가할 것이라고 말했고 퀵타임의 수석 아키텍트인 피터 호디를 소개했다. 잡스는 애플이 자바에 대해 개선하고자 하는 세 가지 사항을 설명했다. 즉, 자바 가상 머신을 통합하고, 호환성을 높이며, 속도를 빠르게 만드는 것이다. 그는 Mac OS X에 대한 애플의 전략을 발표하며 6,000개 이상의 좋은 애플리케이션 프로그래밍 인터페이스(API)를 카본 (API)이라고 부를 것이라고 말했고, 카본을 시연하기 위해 아바디스 테바니안을 소개했다. 테바니안은 마이크로소프트의 매킨토시 사업부 총괄 관리자인 벤 월드먼, 매크로미디어 제품 사장인 놈 메이로비츠, 어도비 시스템즈의 그래픽 애플리케이션 개발 담당 부사장인 그렉 길리를 소개했고, 이들은 포토샵을 시연했다. 잡스는 Mac OS 8 코드명 소나타가 1999년 3분기에 출시될 것이라고 발표했으며, 랩소디 1.0은 1998년 3분기에 출시될 것이라고 말했다.
스티브노트 주목할 만한 스티브노트
WWDC 1999는 HAL9000으로 시작되었다. 잡스는 1998년 5월 6일(iMac 출시일) 이후 3,106개의 Mac 앱이 발표되었다고 업데이트를 전달했다. 드래곤 시스템즈는 음성 인식 소프트웨어를 Mac에 출시할 예정이었고, 그는 드래곤 시스템즈의 공동 창립자이자 CEO인 재닛 베이커를 소개했다. 잡스는 애플의 이익, 판매량, 재고, 현금에 대한 업데이트를 전달하며 시어스가 전국 유통망에 추가될 것이라고 발표했다. Apple Inc.는 1999년 현충일에 스토어를 개설했으며, 잡스는 PowerBook 라인을 발표했다. 일주일간의 컨퍼런스 동안 애플은 참석 개발자들에게 50대의 PowerBook을 증정했다. 잡스는 OpenGL, 자바, 퀵타임에 대한 업데이트를 전달하며 아비 테바니안과 필 실러를 무대 위로 초대했다. 실러는 OpenGL, 퀵타임 4, 셜록 2, 쿼츠 그래픽 모델, 파인더, 메일뷰어 앱을 시연했다. 잡스는 현재까지 가장 빠른 Mac 자바인 자바 MRJ 2.1.2를 발표했으며, 그와 테바니안은 자바를 시연했다. 그는 Mac OS 8.5(1998년 10월 출시)를 검토하고, Mac OS 8.6을 발표했으며, 소나타(1999년 가을 출시 예정)를 미리 보여주었으며, Mac OS X 서버 1.0에 대한 업데이트를 전달했다. 잡스는 다윈 오픈 소스 소프트웨어 프로그램에 2만 명 이상의 등록 개발자와 17만 5천 건 이상의 구성 요소 다운로드가 있었고, 다윈-쿼츠 기반의 세 가지 애플리케이션 환경을 설명했다. 첫 번째는 클래식 환경(이전 이름은 블루 박스)이었고, 두 번째는 카본 (API)(WWDC 1998에서 발표)이었으며, 세 번째는 코코아 (API)(이전 이름은 옐로우 박스)였다. 애플은 새로운 파인더와 새로운 메일을 개발하고 있었다.
스티브노트 주목할 만한 스티브노트
1999년 8월 31일, 세이볼드 세미나 엑스포에서 잡스는 애플에 대한 업데이트를 전달하며 6월 분기별 이익, 갭의 미키 드렉슬러의 이사회 임명, 그리고 퀵타임에 대한 개요를 발표했다. 애플은 아카마이 테크놀로지스와 방송 네트워크 파트너십을 맺었고, BBC 뉴스, 블룸버그 텔레비전, 폭스 뉴스, 폭스 스포츠, HBO, NPR, 더 웨더 채널, WGBH-TV, ABC 뉴스, ESPN, 롤링 스톤, VH1, 디즈니가 콘텐츠를 제공했으며, 새로운 콘텐츠는 라이노 레코드와 워너 브라더스 레코드에서 제공되었다. 필 실러는 퀵타임 TV, 셜록 2, 보이스프린트, 애플스크립트, 파워 맥 G4를 시연했고, 잡스는 Mac OS 9를 미리 보여주었다. 그는 아홉 가지 기능을 시연했다. 쇼핑 앱인 셜록 2, 여러 사용자를 위한 개인 정보 보호 및 기본 설정을 가진 다중 사용자, 음성 인식 소프트웨어인 보이스프린트 암호, 하나의 암호로 된 키체인, 최신 업데이트를 위한 자동 업데이트, 개인 파일을 위한 암호화, 인터넷을 통한 파일 공유, 컴퓨터 간 워크플로우 관리를 위한 TCP/IP를 통한 AppleScript, 그리고 네트워크 브라우저였다. 잡스는 iMac을 검토하며 IBM의 음성 시스템 총괄 관리자인 오지 오스본을 소개하여 ViaVoice를 시연했다. 잡스는 iBook(두 개의 TV 광고를 보여주었다), AirPort(AirPort 베이스 스테이션 TV 광고를 보여주었다), PowerBook, Power Mac G4를 검토하며 컴퓨터 과학자 리처드 크랜들을 무대 위로 불러 G4를 시연하게 했다. 잡스는 어도비 시스템즈의 회장이자 최고 사업 책임자(CCO)인 존 워녹을 소개했다. 잡스는 Power Mac G4 TV 광고를 보여주고 Apple Cinema Display를 소개했다.
스티브노트 주목할 만한 스티브노트
1999년 10월 5일, 잡스는 소니의 모리타 아키오가 이틀 전 사망했다고 말하며 Mac OS 9를 발표하고 아홉 가지 인터넷 파워 툴에 대해 설명했다. 필 실러는 셜록 2, 다중 사용자, 보이스프린트 암호, 키체인, 암호화, 네트워크 브라우저, 자동 업데이트를 시연했다. 잡스는 Power Mac G4를 검토하고 TV 광고를 보여주었으며, Apple Cinema Display, PowerBook, iBook을 검토했다. 그는 새로운 iMac을 발표했고, 실러는 그래픽 카드를 시연했다. 잡스는 iMac DV와 iMovie를 소개하고 시연했으며, 세 개의 TV 광고를 보여주었다.
스티브노트 제품 소개
잡스 사망 후 주목할 만한 기조연설:
2020: Apple Watch Series 6, Apple Watch SE, 4세대 iPad Air, HomePod Mini, 아이폰 12 및 아이폰 12 미니, 아이폰 12 Pro 및 아이폰 12 Pro 맥스, Apple M1 칩, 그리고 MacBook Air, Mac Mini, 13인치 MacBook Pro의 첫 Apple Silicon Mac 모델.
스티브노트 "하나 더..."
일반적인 스티브노트(Stevenote)는 잡스가 애플 제품의 판매 실적과 지난 몇 달간 출시된 제품 검토를 발표하는 것으로 시작되었다. 그런 다음 그는 하나 이상의 신제품을 발표했다. 피터 포크의 콜롬보를 연상시키듯, 그는 일반적으로 결론적인 말을 하는 척하고 무대를 떠나려는 듯 돌아서서 "하지만 하나 더 있습니다"라고 말했다.
일부 "하나 더..." 부분은 다음과 같다.
자기확언
자기확언(self-affirmation)은 사람이 자신의 자아개념(self-concept)에 위협을 가하는 정보나 경험에 적응하는 방식에 주목하는 심리학 이론이다. 원래 1980년대 후반에 클라우드 스틸(Claude Steele)이 자기확언을 대중화하였고 사회심리학 연구에 분야에서 깊이 연구된 이론으로 남아 있다.
자기확언 이론은 사람이 자기감(sense of self)에 반대되거나 이를 위협하는 정보를 접하였을 때 자기와 사적으로 관련된 가치를 되돌아보면, 고통을 덜 겪고 방어적으로 반응할 가능성이 높다고 주장한다.
저기확언 이론의 실험적 연구는 자기확언이 위협이나 스트레스를 다루는데 도움을 줄 수 있고 학업과 건강을 상승시키고 방어적 태도를 줄이는데 도움된다고 주장한다.
자기확언 개요
자기확언 이론의 4가지 주요 원칙은 다음과 같다.
자기확언 개요
자기확언 이론애서는 사람은 자기완정성(self-integrity)을 지키고자 움직인다고 말한다. 자기확언 이론에 의하면, 자기완정성이란 문화적 사회적 규범에 일치하는 방식으로 행동하는 착하고 도덕적인 사람으로서 자기를 인지하는 자기 개념이다. 스틸은 자기가 역할(role), 가치(value), 신념체계(belief system)라는 영역으로 구성된다고 주장하였다. 역할이란, 부모, 친구, 학생, 전문가와 같이 사람이 지는 책임(responsibility)을 포함한다. 가치란, 건강하게 살기나 타인을 존중하기와 같이, 사람이 바라며 살아가고자 하는 염원(aspiration)을 말한다. 신념체계란, 종교적 믿음이나 정치적 신념과 같이 사람이 자신의 생각이나 믿음의 근원을 두는 이념(ideology)을 포함한다. 자기완정성은 많은 형태를 띨 수 있다. 예를 들어, 자기완정성은 독립적으로 되기, 지성을 갖추기, 한 사회의 유익한 구성원 되기, 가족의 일부가 되기, 한 집단의 일부가 되기와 같은 식일 수 있다. 자기완정성에 가해지는 위협이란, 한 사람이 사적 영역에서 좋지 못하다거나 부적절하다는 암시를 주는 사건이나 메시지이다. 자기확언 이론은 이러한 영역 가운대 하나에 가해지는 위협을 직면하였을 때, 사람은 자신에 대한 전반적인 이미지를 긍정적으로 유지하려는 동기가 생긴다.