Trong bài đầu tiên của loạt bài này, bạn đã tạo một tập lệnh Bash rất nhỏ, một dòng và khám phá lý do tạo các tập lệnh shell và tại sao chúng là lựa chọn hiệu quả nhất cho quản trị viên hệ thống, thay vì các chương trình đã biên dịch.
Trong bài viết thứ hai này, bạn sẽ bắt đầu tạo một mẫu tập lệnh Bash có thể được sử dụng làm điểm khởi đầu cho các tập lệnh Bash khác. Mẫu cuối cùng sẽ chứa một phương tiện Trợ giúp, một tuyên bố cấp phép, một số chức năng đơn giản và một số logic để xử lý các tùy chọn đó và những tùy chọn khác có thể cần cho các tập lệnh dựa trên mẫu này.
Tại sao phải tạo một mẫu?
Giống như tự động hóa nói chung, ý tưởng đằng sau việc tạo một khuôn mẫu là trở thành "lazy sysadmin." Một mẫu chứa các thành phần cơ bản mà bạn muốn có trong tất cả các tập lệnh của mình. Nó tiết kiệm thời gian so với việc thêm các thành phần đó vào mọi tập lệnh mới và giúp dễ dàng bắt đầu một tập lệnh mới.
Mặc dù có thể hấp dẫn nếu chỉ ném một vài câu lệnh Bash dòng lệnh vào một tệp và làm cho nó có thể thực thi được, nhưng điều đó có thể phản tác dụng về lâu dài. Chương trình Bash được viết tốt và được bình luận tốt với cơ sở Trợ giúp và khả năng chấp nhận các tùy chọn dòng lệnh cung cấp một điểm khởi đầu tốt cho các sysadmins duy trì chương trình, bao gồm các chương trình mà bạn viết và duy trì.
Yêu cầu
Bạn nên luôn tạo ra một tập hợp các yêu cầu cho mọi dự án bạn thực hiện. Điều này bao gồm các tập lệnh, ngay cả khi đó là một danh sách đơn giản chỉ có hai hoặc ba mục trên đó. Tôi đã tham gia vào nhiều dự án thất bại hoàn toàn hoặc không đáp ứng được nhu cầu của khách hàng, thường là do thiếu bản tuyên bố yêu cầu hoặc bản viết kém.
Các yêu cầu đối với mẫu Bash này khá đơn giản:
- Tạo một mẫu có thể được sử dụng làm điểm khởi đầu cho các dự án lập trình Bash trong tương lai.
- Mẫu phải tuân theo các phương pháp lập trình Bash tiêu chuẩn.
- Nó phải bao gồm:
- Một phần tiêu đề có thể được sử dụng để mô tả chức năng của chương trình và một bảng thay đổi
- Tuyên bố cấp phép
- Một phần cho các chức năng
- Chức năng Trợ giúp
- Một chức năng để kiểm tra xem người dùng chương trình có phải là root hay không
- Một phương pháp để đánh giá các tùy chọn dòng lệnh
Cấu trúc cơ bản
Một tập lệnh Bash cơ bản có ba phần. Bash không có cách nào để phân định các phần, nhưng ranh giới giữa các phần là ẩn.
- Tất cả các tập lệnh phải bắt đầu bằng shebang ( #! ) và đây phải là dòng đầu tiên trong bất kỳ chương trình Bash nào.
- Phần chức năng phải bắt đầu sau phần shebang và trước phần nội dung của chương trình. Là một phần nhu cầu của tôi để ghi lại mọi thứ, tôi đặt một nhận xét trước mỗi chức năng với một mô tả ngắn về những gì nó dự định làm. Tôi cũng bao gồm các nhận xét bên trong các chức năng để giải thích thêm. Các chương trình ngắn, đơn giản có thể không cần chức năng.
- Phần chính của chương trình nằm sau phần chức năng. Đây có thể là một câu lệnh Bash đơn lẻ hoặc hàng nghìn dòng mã. Một trong những chương trình của tôi có hơn 200 dòng mã, không tính các bình luận. Cũng chương trình đó có hơn 600 dòng bình luận.
Đó là tất cả những gì có — chỉ ba phần trong cấu trúc của bất kỳ chương trình Bash nào.
Nhận xét hàng đầu
Tôi luôn thêm nhiều hơn thế này vì nhiều lý do khác nhau. Đầu tiên, tôi thêm một vài phần nhận xét ngay sau shebang. Các phần nhận xét này là tùy chọn, nhưng tôi thấy chúng rất hữu ích.
Phần nhận xét đầu tiên là tên và mô tả chương trình và lịch sử thay đổi. Tôi đã học được định dạng này khi làm việc tại IBM và nó cung cấp một phương pháp ghi lại sự phát triển lâu dài của chương trình và bất kỳ bản sửa lỗi nào được áp dụng cho nó. Đây là bước khởi đầu quan trọng trong việc ghi lại chương trình của bạn.
Phần bình luận thứ hai là tuyên bố về bản quyền và giấy phép. Tôi sử dụng GPLv2 và đây dường như là một tuyên bố tiêu chuẩn cho các chương trình được cấp phép theo GPLv2. Nếu bạn sử dụng một giấy phép nguồn mở khác, điều đó là tốt, nhưng tôi khuyên bạn nên thêm một tuyên bố rõ ràng vào mã để loại bỏ bất kỳ sự nhầm lẫn nào có thể xảy ra về việc cấp phép. Bài báo của Scott Peterson Mã nguồn là giấy phép giúp giải thích lý do đằng sau điều này.
Vì vậy, bây giờ tập lệnh trông giống như sau:
#!/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 #
# LinuxGeek46@both.org #
# #
# 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!"
Chạy chương trình đã sửa đổi để xác minh rằng nó vẫn hoạt động như mong đợi.
Giới thiệu về thử nghiệm
Bây giờ là thời điểm tốt để nói về thử nghiệm.
" Luôn có thêm một lỗi."
- Định luật côn trùng học điều khiển từ của Lubarsky
Lubarsky - dù đó có thể là ai - đều đúng. Bạn không bao giờ có thể tìm thấy tất cả các lỗi trong mã của mình. Đối với mỗi lỗi tôi tìm thấy, dường như luôn có một lỗi khác xuất hiện, thường là vào thời điểm rất không thích hợp.
Kiểm tra không chỉ là về các chương trình. Nó cũng liên quan đến việc xác minh rằng các vấn đề — cho dù do phần cứng, phần mềm gây ra hay những cách dường như vô tận mà người dùng có thể tìm thấy để phá vỡ mọi thứ — được cho là sẽ được giải quyết thực sự là như vậy. Cũng quan trọng không kém, kiểm tra cũng nhằm đảm bảo rằng mã dễ sử dụng và giao diện có ý nghĩa đối với người dùng.
Tuân theo một quy trình được xác định rõ khi viết và thử nghiệm các tập lệnh shell có thể góp phần tạo ra các kết quả nhất quán và chất lượng cao. Quy trình của tôi rất đơn giản:
- Tạo một kế hoạch thử nghiệm đơn giản.
- Bắt đầu thử nghiệm ngay khi bắt đầu phát triển.
- Thực hiện kiểm tra cuối cùng khi mã hoàn tất.
- Chuyển sang sản xuất và thử nghiệm nhiều hơn.
Kế hoạch thử nghiệm
Có rất nhiều định dạng khác nhau cho kế hoạch kiểm tra. Tôi đã làm việc với toàn bộ phạm vi — từ việc có tất cả trong đầu; đến một vài ghi chú được ghi nhanh trên một tờ giấy; và tất cả các cách đến một tập hợp các biểu mẫu phức tạp yêu cầu mô tả đầy đủ về từng bài kiểm tra, mã chức năng mà nó sẽ kiểm tra, kiểm tra sẽ hoàn thành những gì, đầu vào và kết quả nên là gì.
Nói như một sysadmin đã từng (nhưng không phải bây giờ) là một người thử nghiệm, tôi cố gắng lấy điểm trung bình. Có ít nhất một kế hoạch thử nghiệm bằng văn bản ngắn sẽ đảm bảo tính nhất quán từ lần chạy thử nghiệm này đến lần chạy thử nghiệm tiếp theo. Bạn cần bao nhiêu chi tiết phụ thuộc vào mức độ chính thức của các chức năng kiểm tra và phát triển của bạn.
Các tài liệu kế hoạch thử nghiệm mẫu mà tôi thấy khi sử dụng Google rất phức tạp và dành cho các tổ chức lớn có quy trình phát triển và thử nghiệm rất bài bản. Mặc dù những kế hoạch kiểm tra đó sẽ tốt cho những người có "bài kiểm tra" trong chức danh công việc của họ, nhưng chúng không áp dụng tốt cho điều kiện làm việc hỗn loạn hơn và phụ thuộc vào thời gian của sysadmins. Như trong hầu hết các khía cạnh khác của công việc, các sysadmins cần phải sáng tạo. Vì vậy, đây là danh sách ngắn những điều cần xem xét đưa vào kế hoạch kiểm tra của bạn. Sửa đổi nó cho phù hợp với nhu cầu của bạn:
- Tên và mô tả ngắn gọn về phần mềm đang được thử nghiệm
- Mô tả về các tính năng phần mềm sẽ được kiểm tra
- Điều kiện bắt đầu cho mỗi bài kiểm tra
- Các chức năng cần tuân theo cho mỗi bài kiểm tra
- Mô tả về kết quả mong muốn cho mỗi bài kiểm tra
- Các bài kiểm tra cụ thể được thiết kế để kiểm tra các kết quả tiêu cực
- Kiểm tra cách chương trình xử lý các đầu vào không mong muốn
- Mô tả rõ ràng về yếu tố cấu thành đạt hoặc không đạt đối với mỗi bài kiểm tra
- Kiểm tra mờ, được mô tả bên dưới
Danh sách này sẽ cung cấp cho bạn một số ý tưởng để tạo kế hoạch thử nghiệm của bạn. Hầu hết các sysadmins nên giữ cho nó đơn giản và khá trang trọng.
Kiểm tra sớm — kiểm tra thường xuyên
Tôi luôn bắt đầu thử nghiệm các tập lệnh shell của mình ngay sau khi tôi hoàn thành phần đầu tiên có thể thực thi được. Điều này đúng cho dù tôi đang viết một chương trình dòng lệnh ngắn hay một tập lệnh là một tệp thực thi.
Tôi thường bắt đầu tạo các chương trình mới với mẫu kịch bản shell. Tôi viết mã cho chức năng Trợ giúp và kiểm tra nó. Đây thường là một phần nhỏ của quy trình, nhưng nó giúp tôi bắt đầu và đảm bảo rằng mọi thứ trong mẫu hoạt động bình thường ngay từ đầu. Tại thời điểm này, có thể dễ dàng khắc phục sự cố với các phần mẫu của tập lệnh hoặc sửa đổi nó để đáp ứng các nhu cầu mà mẫu chuẩn không có.
Khi mẫu và chức năng Trợ giúp đang hoạt động, tôi chuyển sang tạo phần nội dung của chương trình bằng cách thêm các chú thích để ghi lại các bước lập trình cần thiết để đáp ứng các thông số kỹ thuật của chương trình. Bây giờ tôi bắt đầu thêm mã để đáp ứng các yêu cầu được nêu trong mỗi nhận xét. Mã này có thể sẽ yêu cầu thêm các biến được khởi tạo trong phần đó của mẫu — hiện đang trở thành một tập lệnh shell.
Đây là nơi kiểm tra không chỉ là nhập dữ liệu và xác minh kết quả. Phải mất thêm một chút công việc. Đôi khi tôi thêm một lệnh chỉ đơn giản là in ra kết quả trung gian của đoạn mã tôi vừa viết và xác minh điều đó. Đối với các tập lệnh phức tạp hơn, tôi thêm -t tùy chọn cho "chế độ kiểm tra". Trong trường hợp này, mã kiểm tra nội bộ chỉ thực thi khi -t được nhập trên dòng lệnh.
Thử nghiệm cuối cùng
Sau khi mã hoàn tất, tôi quay lại để thực hiện kiểm tra hoàn chỉnh tất cả các tính năng và chức năng bằng cách sử dụng các đầu vào đã biết để tạo ra các đầu ra cụ thể. Tôi cũng kiểm tra một số đầu vào ngẫu nhiên để xem liệu chương trình có thể xử lý đầu vào không mong muốn hay không.
Thử nghiệm cuối cùng nhằm xác minh rằng chương trình về cơ bản hoạt động như dự kiến. Một phần lớn của thử nghiệm cuối cùng là đảm bảo rằng các chức năng hoạt động trước đó trong chu kỳ phát triển không bị phá vỡ bởi mã được thêm vào hoặc thay đổi sau đó trong chu kỳ.
Nếu bạn đang thử nghiệm tập lệnh khi thêm mã mới vào nó, bạn có thể nghĩ rằng sẽ không có bất kỳ điều gì ngạc nhiên trong quá trình thử nghiệm cuối cùng. Sai! Luôn có những điều bất ngờ trong quá trình thử nghiệm cuối cùng. Luôn luôn. Hãy mong đợi những điều bất ngờ đó và sẵn sàng dành thời gian sửa chữa chúng. Nếu không bao giờ có bất kỳ lỗi nào được phát hiện trong quá trình thử nghiệm cuối cùng, thì sẽ chẳng có ích gì khi thực hiện thử nghiệm cuối cùng, phải không?
Thử nghiệm trong sản xuất
Hả — cái gì?
"Không phải cho đến khi một chương trình được sản xuất trong ít nhất sáu tháng, lỗi có hại nhất mới được phát hiện."
- Định đề lập trình của Troutman
Vâng, thử nghiệm trong sản xuất hiện được coi là bình thường và mong muốn. Bản thân đã là một người thử nghiệm, điều này có vẻ hợp lý. "Nhưng chờ đã! Điều đó nguy hiểm," bạn nói. Kinh nghiệm của tôi là không có gì nguy hiểm hơn việc thử nghiệm rộng rãi và nghiêm ngặt trong một môi trường thử nghiệm chuyên dụng. Trong một số trường hợp, không có sự lựa chọn vì không có môi trường thử nghiệm — chỉ có sản xuất.
Sysadmins không xa lạ với nhu cầu thử nghiệm các tập lệnh mới hoặc sửa đổi trong quá trình sản xuất. Bất cứ khi nào một kịch bản được chuyển vào sản xuất, điều đó sẽ trở thành bài kiểm tra cuối cùng. Môi trường sản xuất là phần quan trọng nhất của thử nghiệm đó. Không gì mà người thử nghiệm có thể mơ ước trong môi trường thử nghiệm có thể tái tạo hoàn toàn môi trường sản xuất thực sự.
Thực tiễn mới được cho là thử nghiệm trong sản xuất chỉ là sự công nhận những gì mà các sysadmins đã biết từ trước đến nay. Thử nghiệm tốt nhất là sản xuất — miễn là nó không phải là thử nghiệm duy nhất.
Kiểm tra mờ
Đây là một trong những từ thông dụng ban đầu khiến tôi phải đảo mắt. Ý nghĩa cơ bản của nó rất đơn giản:nhờ ai đó đập vào các phím cho đến khi điều gì đó xảy ra và xem chương trình xử lý nó tốt như thế nào. Nhưng thực sự còn nhiều điều hơn thế nữa.
Thử nghiệm mờ hơi giống như lần con trai tôi phá mã cho một trò chơi trong vòng chưa đầy một phút với đầu vào ngẫu nhiên. Điều đó đã kết thúc khá nhiều nỗ lực của tôi để viết trò chơi cho anh ấy.
Hầu hết các kế hoạch kiểm tra sử dụng đầu vào rất cụ thể để tạo ra một kết quả hoặc đầu ra cụ thể. Bất kể thử nghiệm xác định kết quả tích cực hay tiêu cực là thành công, nó vẫn được kiểm soát và các đầu vào và kết quả được chỉ định và mong đợi, chẳng hạn như thông báo lỗi cụ thể cho một chế độ lỗi cụ thể.
Kiểm tra mờ là xử lý tính ngẫu nhiên trong tất cả các khía cạnh của kiểm tra, chẳng hạn như điều kiện bắt đầu, đầu vào rất ngẫu nhiên và bất ngờ, kết hợp ngẫu nhiên của các tùy chọn được chọn, bộ nhớ thấp, mức CPU cao cạnh tranh với các chương trình khác, nhiều phiên bản của chương trình đang được kiểm tra và bất kỳ điều kiện ngẫu nhiên nào khác mà bạn có thể nghĩ ra để áp dụng cho các bài kiểm tra.
Tôi cố gắng thực hiện một số thử nghiệm mờ ngay từ đầu. Nếu tập lệnh Bash không thể đối phó với sự ngẫu nhiên đáng kể trong giai đoạn đầu của nó, thì nó khó có thể trở nên tốt hơn khi bạn thêm nhiều mã. Đây là thời điểm tốt để nắm bắt những vấn đề này và khắc phục chúng trong khi mã tương đối đơn giản. Một chút kiểm tra mờ ở mỗi giai đoạn cũng hữu ích trong việc xác định các vấn đề trước khi chúng bị che bởi nhiều mã hơn nữa.
Sau khi mã hoàn thành, tôi muốn thực hiện một số thử nghiệm mờ mở rộng hơn. Luôn luôn thực hiện một số thử nghiệm mờ. Tôi chắc chắn đã rất ngạc nhiên bởi một số kết quả. Thật dễ dàng để kiểm tra những điều mong đợi, nhưng người dùng thường không thực hiện những điều mong đợi với một tập lệnh.
Xem trước các điểm du lịch sắp tới
Bài viết này hoàn thành một chút về cách tạo mẫu, nhưng nó chủ yếu nói về thử nghiệm. Điều này là do thử nghiệm là một phần quan trọng trong việc tạo ra bất kỳ loại chương trình nào. Trong phần tiếp theo của loạt bài này, bạn sẽ thêm chức năng Trợ giúp cơ bản cùng với một số mã để phát hiện và hành động trên các tùy chọn, chẳng hạn như -h , vào mẫu tập lệnh Bash của bạn.
Tài nguyên
- Cách lập trình với Bash:Cú pháp và công cụ
- Cách lập trình với Bash:Toán tử logic và mở rộng shell
- Cách lập trình với Bash:Loops
Loạt bài viết này một phần dựa trên Tập 2, Chương 10 của khóa học tự học Linux ba phần của David Cả hai, Sử dụng và Quản trị Linux — Zero to SysAdmin.