이 시리즈의 첫 번째 기사에서는 매우 작은 한 줄짜리 Bash 스크립트를 만들고 셸 스크립트를 만드는 이유와 컴파일된 프로그램이 아닌 시스템 관리자에게 가장 효율적인 옵션인 이유를 살펴보았습니다.
이 두 번째 기사에서는 다른 Bash 스크립트의 시작점으로 사용할 수 있는 Bash 스크립트 템플릿을 만들기 시작합니다. 템플릿에는 궁극적으로 도움말 기능, 라이선스 설명, 여러 가지 간단한 기능, 이러한 옵션을 처리하기 위한 일부 논리 및 이 템플릿을 기반으로 하는 스크립트에 필요할 수 있는 기타 요소가 포함됩니다.
템플릿을 만드는 이유는 무엇입니까?
일반적인 자동화와 마찬가지로 템플릿을 만드는 배경은 "게으른 시스템 관리자"가 되는 것입니다. 템플릿에는 모든 스크립트에서 원하는 기본 구성 요소가 포함되어 있습니다. 이러한 구성 요소를 모든 새 스크립트에 추가하는 것에 비해 시간을 절약하고 새 스크립트를 쉽게 시작할 수 있습니다.
몇 가지 명령줄 Bash 문을 함께 파일에 넣고 실행 가능하게 만드는 것이 유혹적일 수 있지만 장기적으로 비생산적일 수 있습니다. 도움말 기능과 명령줄 옵션을 허용하는 기능이 포함된 잘 작성되고 주석이 잘 달린 Bash 프로그램은 귀하 작성하고 유지합니다.
요구사항
수행하는 모든 프로젝트에 대해 항상 일련의 요구 사항을 만들어야 합니다. 여기에는 2~3개의 항목만 포함된 간단한 목록일지라도 스크립트가 포함됩니다. 저는 완전히 실패했거나 고객의 요구 사항을 충족하지 못한 많은 프로젝트에 참여했습니다. 일반적으로 요구 사항 설명이 부족하거나 제대로 작성되지 않았기 때문입니다.
이 Bash 템플릿의 요구 사항은 매우 간단합니다.
- 향후 Bash 프로그래밍 프로젝트의 시작점으로 사용할 수 있는 템플릿을 만듭니다.
- 템플릿은 표준 Bash 프로그래밍 방식을 따라야 합니다.
- 다음을 포함해야 합니다.
- 프로그램 및 변경 로그의 기능을 설명하는 데 사용할 수 있는 제목 섹션
- 라이선스 명세서
- 함수 섹션
- 도움말 기능
- 프로그램 사용자가 루트인지 테스트하는 함수
- 명령줄 옵션 평가 방법
기본 구조
기본 Bash 스크립트에는 세 개의 섹션이 있습니다. Bash는 섹션을 설명할 방법이 없지만 섹션 간의 경계는 암시적입니다.
- 모든 스크립트는 shebang(#! ), 이것은 모든 Bash 프로그램의 첫 번째 줄이어야 합니다.
- functions 섹션은 shebang 뒤와 프로그램 본문 앞에서 시작해야 합니다. 모든 것을 문서화해야 하는 필요성의 일환으로 각 기능 앞에 해당 기능이 무엇을 하는지에 대한 간단한 설명과 함께 주석을 추가합니다. 나는 또한 더 자세히 설명하기 위해 함수 내부에 주석을 포함합니다. 짧고 간단한 프로그램에는 기능이 필요하지 않을 수 있습니다.
- 프로그램의 주요 부분은 기능 섹션 다음에 옵니다. 이것은 단일 Bash 문일 수도 있고 수천 줄의 코드일 수도 있습니다. 내 프로그램 중 하나에는 주석을 포함하지 않고 200줄이 조금 넘는 코드가 있습니다. 같은 프로그램에 600개 이상의 주석 줄이 있습니다.
모든 Bash 프로그램 구조에서 세 섹션만 있으면 됩니다.
주요 코멘트
나는 여러 가지 이유로 항상 이것보다 더 많은 것을 추가합니다. 먼저, 나는 shebang 직후에 몇 개의 주석 섹션을 추가합니다. 이 댓글 섹션은 선택 사항이지만 매우 유용합니다.
첫 번째 주석 섹션은 프로그램 이름과 설명 및 변경 이력입니다. IBM에서 일하면서 이 형식을 배웠고 프로그램의 장기 개발 및 적용된 수정 사항을 문서화하는 방법을 제공합니다. 이것은 프로그램을 문서화하는 중요한 시작입니다.
두 번째 의견 섹션은 저작권 및 라이선스 설명입니다. 저는 GPLv2를 사용하는데 이것은 GPLv2에 따라 라이선스가 부여된 프로그램에 대한 표준 설명인 것 같습니다. 다른 오픈 소스 라이선스를 사용하는 경우 괜찮지만 라이선스에 대한 혼동을 방지하기 위해 코드에 명시적인 설명을 추가하는 것이 좋습니다. Scott Peterson의 기사 소스 코드는 라이선스입니다 이유를 설명하는 데 도움이 됩니다.
이제 스크립트는 다음과 같습니다.
#!/bin/bash
################################################################################
# scriptTemplate #
# #
# Use this template as the beginning of a new program. Place a short #
# description of the script here. #
# #
# Change History #
# 11/11/2019 David Both Original code. This is a template for creating #
# new Bash shell scripts. #
# Add new history entries as needed. #
# #
# #
################################################################################
################################################################################
################################################################################
# #
# Copyright (C) 2007, 2019 David Both #
# [email protected] #
# #
# This program is free software; you can redistribute it and/or modify #
# it under the terms of the GNU General Public License as published by #
# the Free Software Foundation; either version 2 of the License, or #
# (at your option) any later version. #
# #
# This program is distributed in the hope that it will be useful, #
# but WITHOUT ANY WARRANTY; without even the implied warranty of #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #
# GNU General Public License for more details. #
# #
# You should have received a copy of the GNU General Public License #
# along with this program; if not, write to the Free Software #
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA #
# #
################################################################################
################################################################################
################################################################################
echo "hello world!"
수정된 프로그램을 실행하여 여전히 예상대로 작동하는지 확인하십시오.
테스트 정보
지금이 테스트에 대해 이야기할 좋은 시간입니다.
<블록 인용>
"항상 버그가 하나 더 있습니다."
— Lubarsky의 사이버네틱 곤충학 법칙
Lubarsky - 그게 누구든지 - 맞습니다. 코드에서 모든 버그를 찾을 수는 없습니다. 제가 발견한 모든 버그에는 항상 다른 버그가 발생하는 것 같습니다. 일반적으로 매우 부적절한 시기에 발생합니다.
테스트는 프로그램에 관한 것이 아닙니다. 또한 하드웨어, 소프트웨어 또는 사용자가 문제를 해결하기 위해 찾을 수 있는 끝이 없어 보이는 방법으로 인해 발생하는 문제가 실제로 해결되어야 하는지 확인하는 것입니다. 그 못지 않게 중요한 것은 테스트는 코드가 사용하기 쉽고 인터페이스가 사용자에게 의미가 있는지 확인하는 것입니다.
셸 스크립트를 작성하고 테스트할 때 잘 정의된 프로세스를 따르면 일관되고 고품질의 결과에 기여할 수 있습니다. 내 절차는 간단합니다.
- 간단한 테스트 계획을 세웁니다.
- 개발 초기부터 테스트를 시작하세요.
- 코드가 완료되면 최종 테스트를 수행합니다.
- 프로덕션으로 이동하고 더 많이 테스트하세요.
테스트 계획
테스트 계획에는 다양한 형식이 있습니다. 나는 모든 것을 머릿속에 담아두는 것부터 모든 범위를 가지고 일했습니다. 한 장의 종이에 적힌 몇 가지 메모에; 그리고 각 테스트에 대한 자세한 설명, 테스트할 기능 코드, 테스트가 수행할 작업, 입력 및 결과가 무엇이어야 하는지에 대한 자세한 설명이 필요한 복잡한 양식 세트에 이르기까지.
테스터였던(지금은 아니지만) 시스템 관리자로서 말하면서 저는 중간 지점을 잡으려고 노력합니다. 최소한 짧은 테스트 계획을 작성하면 한 테스트 실행에서 다음 실행까지 일관성이 보장됩니다. 얼마나 많은 세부 정보가 필요한지는 개발 및 테스트 기능이 얼마나 형식적인지에 따라 다릅니다.
Google을 사용하여 찾은 샘플 테스트 계획 문서는 복잡했으며 매우 공식적인 개발 및 테스트 프로세스가 있는 대규모 조직을 대상으로 했습니다. 이러한 테스트 계획은 직책에 "테스트"가 있는 사람들에게 좋을 것이지만 시스템 관리자의 더 혼란스럽고 시간 종속적인 작업 조건에는 잘 적용되지 않습니다. 작업의 다른 대부분의 측면과 마찬가지로 시스템 관리자는 창의적이어야 합니다. 따라서 테스트 계획에 포함해야 할 사항에 대한 간략한 목록이 있습니다. 필요에 맞게 수정하십시오:
- 테스트 중인 소프트웨어의 이름 및 간단한 설명
- 테스트할 소프트웨어 기능에 대한 설명
- 각 테스트의 시작 조건
- 각 테스트에서 따라야 할 기능
- 각 테스트에서 원하는 결과에 대한 설명
- 부정적인 결과를 테스트하기 위해 고안된 특정 테스트
- 프로그램이 예기치 않은 입력을 처리하는 방법 테스트
- 각 테스트의 합격 또는 불합격에 대한 명확한 설명
- 아래에 설명된 퍼지 테스트
이 목록은 테스트 계획을 만들기 위한 몇 가지 아이디어를 제공합니다. 대부분의 시스템 관리자는 간단하고 상당히 비공식적이어야 합니다.
조기 테스트—자주 테스트
저는 실행 가능한 첫 번째 부분을 완료하자마자 항상 쉘 스크립트 테스트를 시작합니다. 이것은 내가 짧은 명령줄 프로그램을 작성하든 실행 파일인 스크립트를 작성하든 사실입니다.
나는 보통 쉘 스크립트 템플릿으로 새로운 프로그램을 만들기 시작합니다. 도움말 기능에 대한 코드를 작성하고 테스트합니다. 이것은 일반적으로 프로세스의 사소한 부분이지만 시작하는 데 도움이 되고 템플릿의 항목이 처음부터 제대로 작동하는지 확인합니다. 이 시점에서 스크립트의 템플릿 부분의 문제를 수정하거나 표준 템플릿이 제공하지 않는 요구 사항을 충족하도록 수정하기가 쉽습니다.
템플릿과 도움말 기능이 작동하면 프로그램 사양을 충족하는 데 필요한 프로그래밍 단계를 문서화하기 위해 주석을 추가하여 프로그램 본문을 만드는 작업으로 넘어갑니다. 이제 각 주석에 명시된 요구 사항을 충족하는 코드를 추가하기 시작합니다. 이 코드는 아마도 템플릿의 해당 섹션에서 초기화되는 변수를 추가해야 할 것입니다. 이는 이제 쉘 스크립트가 됩니다.
여기서 테스트는 단순히 데이터를 입력하고 결과를 확인하는 것 이상입니다. 약간의 추가 작업이 필요합니다. 때로는 방금 작성한 코드의 중간 결과를 단순히 인쇄하고 확인하는 명령을 추가합니다. 더 복잡한 스크립트의 경우 -t를 추가합니다. "테스트 모드"에 대한 옵션입니다. 이 경우 내부 테스트 코드는 -t 옵션은 명령줄에 입력됩니다.
최종 테스트
코드가 완료된 후 특정 출력을 생성하기 위해 알려진 입력을 사용하여 모든 기능과 기능에 대한 전체 테스트를 수행합니다. 또한 프로그램이 예기치 않은 입력을 처리할 수 있는지 확인하기 위해 일부 임의 입력을 테스트합니다.
최종 테스트는 프로그램이 본질적으로 의도한 대로 작동하는지 확인하기 위한 것입니다. 최종 테스트의 대부분은 개발 주기의 초기에 작동했던 기능이 나중에 추가되거나 변경된 코드로 인해 손상되지 않았는지 확인하는 것입니다.
새 코드를 추가할 때 스크립트를 테스트했다면 최종 테스트에서 놀라움이 없어야 한다고 생각할 수 있습니다. 잘못된! 최종 테스트 중에는 항상 놀라움이 있습니다. 언제나. 이러한 놀라움을 예상하고 시간을 들여 문제를 해결할 준비를 하십시오. 최종 테스트에서 버그가 발견되지 않았다면 최종 테스트를 할 의미가 없겠죠?
프로덕션 테스트
응?
<블록 인용>
"최소 6개월 동안 프로그램을 제작할 때까지는 가장 해로운 오류가 발견될 것입니다."
— Troutman의 프로그래밍 가정
예, 생산 테스트는 이제 정상적이고 바람직한 것으로 간주됩니다. 내가 테스터였기 때문에 이것은 합리적으로 보인다. "하지만 기다려! 그건 위험해."라고 당신은 말합니다. 내 경험에 따르면 전용 테스트 환경에서 광범위하고 엄격한 테스트보다 더 위험하지 않습니다. 어떤 경우에는 테스트 환경이 없고 프로덕션만 있기 때문에 선택의 여지가 없습니다.
시스템 관리자는 프로덕션 환경에서 새 스크립트 또는 수정된 스크립트를 테스트해야 하는 필요성을 잘 알고 있습니다. 스크립트가 프로덕션으로 이동할 때마다 그것이 궁극적인 테스트가 됩니다. 프로덕션 환경은 해당 테스트의 가장 중요한 부분을 구성합니다. 테스터가 테스트 환경에서 상상할 수 있는 어떤 것도 실제 프로덕션 환경을 완전히 복제할 수 없습니다.
프로덕션 환경에서 테스트하는 새로운 방식은 시스템 관리자가 그동안 알고 있었던 사실을 인정하는 것일 뿐입니다. 유일한 테스트가 아닌 한 최고의 테스트는 프로덕션입니다.
퍼지 테스트
이것은 처음에 내 눈을 굴리게 만든 그 유행어 중 하나입니다. 본질적인 의미는 간단합니다. 누군가가 어떤 일이 발생할 때까지 키를 두드리고 프로그램이 이를 얼마나 잘 처리하는지 확인하십시오. 하지만 정말 그 이상의 것이 있습니다.
퍼지 테스팅은 제 아들이 무작위 입력으로 1분도 안 되어 게임 코드를 깨는 것과 같습니다. 그로 인해 그를 위해 게임을 작성하려는 시도가 거의 끝났습니다.
대부분의 테스트 계획은 특정 결과 또는 출력을 생성하는 매우 구체적인 입력을 활용합니다. 테스트가 성공으로 긍정적 또는 부정적 결과를 정의하는지 여부에 관계없이 테스트는 계속 제어되며 특정 실패 모드에 대한 특정 오류 메시지와 같이 입력 및 결과가 지정되고 예상됩니다.
퍼지 테스트는 시작 조건, 매우 무작위적이고 예상치 못한 입력, 선택된 옵션의 무작위 조합, 낮은 메모리, 다른 프로그램과 경쟁하는 높은 수준의 CPU, 테스트 중인 프로그램의 여러 인스턴스와 같은 테스트의 모든 측면에서 무작위성을 처리하는 것입니다. , 그리고 테스트에 적용하기 위해 생각할 수 있는 기타 임의의 조건.
나는 처음부터 약간의 퍼지 테스트를 시도합니다. Bash 스크립트가 초기 단계에서 상당한 임의성을 처리할 수 없는 경우 코드를 더 추가해도 개선될 가능성은 거의 없습니다. 코드가 비교적 단순할 때 이러한 문제를 파악하고 수정할 수 있는 좋은 시간입니다. 각 단계에서 약간의 퍼지 테스트는 더 많은 코드로 가려지기 전에 문제를 찾는 데에도 유용합니다.
코드가 완성된 후에는 좀 더 광범위한 퍼지 테스트를 하고 싶습니다. 항상 퍼지 테스트를 수행하십시오. 나는 확실히 몇몇 결과에 놀랐다. 예상한 일을 테스트하는 것은 쉽지만 사용자는 일반적으로 스크립트로 예상한 일을 하지 않습니다.
향후 명소 미리보기
이 글은 템플릿을 만드는 방법에서 약간의 성취를 이루었지만, 주로 테스트에 대해 이야기했습니다. 테스트는 모든 종류의 프로그램을 만드는 데 중요한 부분이기 때문입니다. 이 시리즈의 다음 기사에서는 -h와 같은 옵션을 감지하고 조치를 취하는 일부 코드와 함께 기본 도움말 기능을 추가합니다. , Bash 스크립트 템플릿으로.
자원
- Bash로 프로그래밍하는 방법:구문 및 도구
- Bash로 프로그래밍하는 방법:논리 연산자 및 셸 확장
- Bash로 프로그래밍하는 방법:루프
이 기사 시리즈는 David Both의 3부작 Linux 자체 학습 과정인 2부, 10장, Linux 사용 및 관리—Zero to SysAdmin을 부분적으로 기반으로 합니다.