위키백과:Lua 유닛 테스트
Wikipedia | 이것은 에세이입니다. 여기에는 한 명 이상의 위키백과 기여자의 조언이나 의견이 포함되어 있습니다.이 페이지는 백과사전 기사도 아니고, 위키백과의 정책이나 지침 중 하나도 아닙니다. 커뮤니티의 철저한 검증이 이루어지지 않았기 때문입니다.일부 에세이는 광범위한 규범을 나타내고, 다른 에세이는 소수의 관점만을 나타냅니다. |
이 에세이는 위키백과 기사를 작성하는 데 사용되는 Lua 스크립트의 단위를 테스트하거나 위키백과 운영 분석을 지원하는 문제에 대해 설명합니다.
통합 및 장치 테스트 개요
모듈이 실제 "고객"을 위해 사용될 때 "YAGNI"(You Non Gone Need It) 때문에 모든 가능한 옵션이 작동하지 않는 "수용 테스트"에서 고객의 바람을 통과시키기 위해 "단위 테스트"와 결합된 관련 문제가 있습니다.주요 업그레이드 후에는 일반적으로 전체 하위 시스템이 "회귀 테스트"를 통해 주요 기능이 계속 작동하는지 다시 확인합니다.제품이 "산업 강도" 작업에 광범위하게 사용될 경우 450개의 인용문 등이 포함된 거대한 기사로 Lua 기반 도시를 테스트하는 것과 같이 무거운 작업량을 처리할 수 있는지 확인하기 위해 "스트레스 테스트"를 실행하는 것이 좋습니다.
유닛 테스트를 위한 전술:이제 유닛 테스트로 돌아가서 유닛 내부에서 추가 테스트를 실행하는 디버그 모드 스위치와 장치로 전송되는 부적절한 데이터를 포착하고 보고하는 일반적인 "매개 변수 유효성 검사"와 같은 유닛 자체 테스트 전략이 있습니다.그러나 종종 데이터를 입력하고 결과를 비교하기 위해 별도의 장치를 반복적으로 호출하는 특수하게 작성된 장치 테스트 루틴의 외부 "테스트 하니스"가 있습니다.화면 지향 출력의 경우 장치 테스트 하니스가 화면 데이터를 읽어 잘못된 결과를 확인하는 것처럼 출력을 직접 캡처하는 경우가 많습니다.
장치의 결과 보고:이제 주요 문제는 일반적으로 데이터 값과 논리적 제어 흐름(여러 장치를 통해 실행)의 두 가지 측면에서 발견됩니다.작업 중에 각 장치는 논리적 흐름을 나타내는 "추적문"을 발행하여 장치 간에 논리적 흐름을 나타낼 수 있으며, 한 변수를 잘못 사용하여 다른 변수에 대한 결과를 저장하는 등 실수로 방해를 받는 경우에도 변수의 값을 표시할 수 있습니다.실시간 화면으로 보기 위해 변경되는 세부 정보가 너무 많기 때문에 추적된 정보는 종종 거대한 "로그 파일"(또는 그 집합)에 기록됩니다. 따라서 로그 파일은 광범위한 실행이 끝날 때 다시 검사됩니다.드문 매개 변수 조합으로 인해 트리거된 작동 오류가 비정상적인 조합이 반복되기 전에 며칠 또는 몇 주 동안 수집된 로그 파일에서 감지되어 세부 정보가 파일에 기록되는 경우가 있습니다.
단위별 오류 감지 및 보고:전체적으로 유닛 테스트에서 각 유닛은 로그 파일(종종 기사의 편집 미리보기 페이지) 또는 유지 관리 범주에 데이터를 적절하게 기록하거나 디버그 추적 문을 작성하는 것이 오류 보고의 오류로 인해 잘못된 데이터를 며칠 동안 파일에 기록하는 것보다 더 나쁜 것은 없기 때문에 해당 유닛을 점검해야 합니다.통합 테스트 전에 "각 유닛 테스트"를 강조하는 것은 "테스트 우선 개발"의 일부로, 잘못된 데이터를 확인하지 않는 한, 장치 내에서 정말 이상한 결과를 생성하기 훨씬 전에 장치 내에서 오류를 조기에 감지하는 "시간 내의 스티치가 9개를 절약한다"는 것을 보여줍니다."블랙박스 엔지니어링"에서.이러한 전술을 따르지 않는 사용자의 경우, 문제가 정확히 파악될 때까지 시행착오를 통해 변경하는 데 수개월이 걸릴 수 있습니다. 또는 장치 내부의 오류가 더 복잡한 시스템에 영향을 미치면 문제를 해결하는 방법을 아무도 볼 수 없었기 때문에 버그가 몇 년 동안 수동 해결 방법을 사용하여 시스템에 남아 있을 가능성이 높습니다. -Wikid77 (talk) 2013년 3월 15일 08:45 (UTC) [
