Kiểm tra đơn vị trong DBMS - cách chúng tôi thực hiện trong Sportmaster, phần hai

Phần đầu tiên - đây.

Hãy tưởng tượng tình huống này. Bạn đang phải đối mặt với nhiệm vụ phát triển chức năng mới. Bạn có kinh nghiệm từ những người đi trước. Giả sử rằng bạn không có nghĩa vụ đạo đức, bạn sẽ làm gì?

Thông thường, tất cả những diễn biến cũ đều bị lãng quên và mọi thứ bắt đầu lại từ đầu. Không ai thích đào sâu vào mã của người khác và nếu bạn có thời gian, tại sao không bắt đầu tạo hệ thống của riêng mình? Đây là một cách tiếp cận điển hình và ở nhiều khía cạnh thì nó đúng. Nhưng trong dự án của chúng tôi, chúng tôi đã hành động khác. Chúng tôi xây dựng hệ thống thử nghiệm tự động trong tương lai dựa trên sự phát triển của các thử nghiệm đơn vị trên utPLSQL từ các phiên bản trước và sau đó bắt tay vào làm việc theo một số hướng song song.

1. Khôi phục các bài kiểm tra đơn vị cũ. Khôi phục có nghĩa là điều chỉnh các thử nghiệm cho phù hợp với trạng thái hiện tại của hệ thống khách hàng thân thiết và điều chỉnh các thử nghiệm theo tiêu chuẩn utPLSQL.
2. Giải quyết vấn đề bằng sự hiểu biết và chính xác những gì, phương pháp và quy trình nào, chúng tôi đã đề cập bằng các bài kiểm tra tự động. Bạn phải ghi nhớ thông tin này trong đầu hoặc đưa ra kết luận trực tiếp dựa trên mã tự động kiểm tra. Vì vậy, chúng tôi quyết định tạo một danh mục. Chúng tôi đã chỉ định một mã ghi nhớ duy nhất cho mỗi lần kiểm tra tự động, tạo mô tả và ghi lại cài đặt (ví dụ: trong điều kiện nào nó sẽ được khởi chạy hoặc điều gì sẽ xảy ra nếu quá trình khởi chạy thử nghiệm không thành công). Về cơ bản, chúng tôi đã điền siêu dữ liệu về các cuộc kiểm tra tự động và đặt siêu dữ liệu đó vào các bảng lược đồ utPLSQL tiêu chuẩn.
3. Xác định chiến lược mở rộng, tức là lựa chọn chức năng có thể được xác minh bằng các thử nghiệm tự động. Chúng tôi quyết định chú ý đến ba điều: những cải tiến mới đối với hệ thống, sự cố từ quá trình sản xuất và các quy trình chính của hệ thống. Do đó, chúng tôi phát triển song song với việc phát hành, đảm bảo chất lượng cao hơn, đồng thời mở rộng phạm vi hồi quy và đảm bảo độ tin cậy của hệ thống ở những nơi quan trọng. Nút thắt đầu tiên như vậy là quá trình phân phối chiết khấu và tiền thưởng bằng séc.
4. Đương nhiên, chúng tôi bắt đầu phát triển các bài kiểm tra tự động mới. Một trong những nhiệm vụ phát hành đầu tiên là đánh giá hiệu suất của các mẫu được xác định trước của hệ thống khách hàng thân thiết. Dự án của chúng tôi có một khối truy vấn sql cố định cứng nhắc để chọn khách hàng theo điều kiện. Ví dụ: lấy danh sách tất cả khách hàng có lần mua hàng gần đây nhất ở một thành phố cụ thể hoặc danh sách khách hàng có số tiền mua trung bình cao hơn một giá trị nhất định. Sau khi viết các bài kiểm tra tự động, chúng tôi đã kiểm tra các mẫu được xác định trước, các thông số hiệu suất điểm chuẩn cố định và ngoài ra, chúng tôi còn thực hiện kiểm tra tải.
5. Làm việc với autotests phải thuận tiện. Hai hành động phổ biến nhất là chạy thử nghiệm tự động và tạo dữ liệu thử nghiệm. Đây là cách hai mô-đun phụ trợ xuất hiện trong hệ thống của chúng tôi: mô-đun khởi chạy và mô-đun tạo dữ liệu.

   Trình khởi chạy được biểu diễn dưới dạng một quy trình chung với một tham số văn bản đầu vào. Là một tham số, bạn có thể chuyển mã ghi nhớ tự động kiểm tra, tên gói, tên kiểm tra, cài đặt tự động kiểm tra hoặc từ khóa dành riêng. Quy trình sẽ chọn và chạy tất cả các thử nghiệm tự động thỏa mãn các điều kiện.

   Mô-đun tạo dữ liệu được trình bày dưới dạng một gói trong đó đối với từng đối tượng của hệ thống đang được thử nghiệm (một bảng trong cơ sở dữ liệu), một quy trình đặc biệt đã được tạo để chèn dữ liệu vào đó. Trong quy trình này, các giá trị mặc định được điền càng nhiều càng tốt, điều này đảm bảo việc tạo các đối tượng theo đúng nghĩa đen chỉ bằng một cú nhấp ngón tay. Và để dễ sử dụng, các mẫu cho dữ liệu được tạo đã được tạo. Ví dụ: tạo khách hàng ở một độ tuổi nhất định bằng điện thoại thử nghiệm và giao dịch mua hàng đã hoàn tất.

6. Quá trình tự động kiểm tra sẽ bắt đầu và chạy trong thời gian có thể chấp nhận được đối với hệ thống của bạn. Do đó, một buổi ra mắt vào ban đêm hàng ngày đã được tổ chức, dựa trên kết quả đó sẽ tạo ra một báo cáo về kết quả và gửi đến toàn bộ nhóm phát triển qua thư công ty. Sau khi khôi phục các bài kiểm tra tự động cũ và tạo các bài kiểm tra mới, tổng thời gian hoạt động là 30 phút. Màn trình diễn này phù hợp với tất cả mọi người vì buổi ra mắt diễn ra ngoài giờ làm việc.

   Nhưng chúng tôi phải nỗ lực tối ưu hóa tốc độ làm việc. Hệ thống khách hàng thân thiết sản xuất được cập nhật vào ban đêm. Là một phần của một trong những bản phát hành, chúng tôi đã phải khẩn trương thực hiện các thay đổi vào ban đêm. Chờ đợi nửa giờ để có kết quả kiểm tra tự động vào lúc ba giờ sáng không làm người chịu trách nhiệm phát hành hài lòng (lời chào nồng nhiệt tới Alexey Vasyukov!), và sáng hôm sau, nhiều lời tử tế đã được nói tới hệ thống của chúng tôi. Nhưng kết quả là tiêu chuẩn 5 phút cho công việc đã được đặt ra.

   Để tăng tốc hiệu suất, chúng tôi đã sử dụng hai phương pháp: bắt đầu chạy thử nghiệm tự động trong ba luồng song song, vì điều này rất thuận tiện do cấu trúc của hệ thống khách hàng thân thiết của chúng tôi. Và chúng tôi đã từ bỏ cách tiếp cận này khi autotest không tạo dữ liệu thử nghiệm cho chính nó mà cố gắng tìm thứ gì đó phù hợp trong hệ thống. Sau khi thực hiện thay đổi, tổng thời gian hoạt động giảm xuống còn 3-4 phút.

7. Một dự án có tính năng tự động kiểm tra sẽ có thể được triển khai trên nhiều vị trí khác nhau. Khi bắt đầu hành trình của chúng tôi, đã có những nỗ lực viết các tệp bó của riêng chúng tôi, nhưng rõ ràng là việc cài đặt tự động tự viết là hoàn toàn kinh khủng và chúng tôi đã chuyển sang các giải pháp công nghiệp. Do dự án chứa rất nhiều mã trực tiếp (trước hết, chúng tôi lưu trữ mã tự động kiểm tra) và rất ít dữ liệu (dữ liệu chính là siêu dữ liệu về tự động kiểm tra), nên việc triển khai trong dự án Liquibase hóa ra rất đơn giản.

   Đây là một thư viện mã nguồn mở, độc lập với cơ sở dữ liệu để theo dõi, quản lý và thực thi các thay đổi trong lược đồ cơ sở dữ liệu. Được quản lý thông qua dòng lệnh hoặc các framework như Apache Maven. Nguyên lý hoạt động của Liquibase khá đơn giản. Chúng tôi có một dự án được tổ chức theo một cách nhất định, bao gồm các thay đổi hoặc tập lệnh cần được triển khai đến máy chủ mục tiêu và kiểm soát các tệp xác định trình tự nào và với những tham số nào mà những thay đổi này sẽ được cài đặt.

   Ở cấp độ DBMS, một bảng đặc biệt được tạo trong đó Liquibase lưu trữ nhật ký khôi phục. Mỗi thay đổi có một hàm băm được tính toán được so sánh mỗi lần giữa dự án và trạng thái trong cơ sở dữ liệu. Nhờ Liquibase, chúng tôi có thể dễ dàng triển khai các thay đổi đối với hệ thống của mình cho bất kỳ mạch điện nào. Autotest hiện đang chạy trên các vòng lặp thử nghiệm và phát hành, cũng như trên các vùng chứa (vòng lặp cá nhân của nhà phát triển).

Vì vậy, hãy nói về kết quả của việc sử dụng hệ thống thử nghiệm đơn vị của chúng tôi.

1. Tất nhiên, trước hết, chúng tôi tin rằng chúng tôi đã bắt đầu phát triển phần mềm tốt hơn. Các cuộc kiểm tra tự động được triển khai hàng ngày và hàng tá lỗi được tìm thấy trong mỗi bản phát hành. Hơn nữa, một số lỗi này chỉ liên quan gián tiếp đến chức năng mà chúng tôi thực sự muốn thay đổi. Có những nghi ngờ nghiêm trọng rằng những lỗi này được tìm thấy bằng cách kiểm tra thủ công.
2. Nhóm hiện tin tưởng rằng chức năng cụ thể đang hoạt động chính xác... Trước hết, điều này liên quan đến các quy trình quan trọng của chúng tôi. Ví dụ: trong sáu tháng qua, chúng tôi không gặp bất kỳ vấn đề nào với việc phân phối các khoản giảm giá và tiền thưởng trên các khoản thu, mặc dù có những thay đổi về phát hành, mặc dù trong các giai đoạn trước, lỗi xảy ra với một số tần suất.
3. Chúng tôi đã cố gắng giảm số lần lặp lại thử nghiệm. Do thực tế là các bài kiểm tra tự động được viết cho chức năng mới nên các nhà phân tích và người kiểm tra bán thời gian nhận được mã có chất lượng cao hơn, bởi vì nó đã được kiểm tra rồi.
4. Một số phát triển trong thử nghiệm tự động được các nhà phát triển sử dụng. Ví dụ: dữ liệu thử nghiệm trên vùng chứa được tạo bằng mô-đun tạo đối tượng.
5. Điều quan trọng là chúng tôi đã phát triển được sự “chấp nhận” của các nhà phát triển đối với hệ thống thử nghiệm tự động. Có một sự hiểu biết rằng điều này là quan trọng và hữu ích. Nhưng từ kinh nghiệm của bản thân, tôi có thể nói rằng điều này còn lâu mới xảy ra. Các bài kiểm tra tự động cần được viết, chúng cần được duy trì và phát triển, các kết quả được phân tích và thường những chi phí thời gian này đơn giản là không đáng có. Việc đi đến sản xuất và giải quyết các vấn đề ở đó dễ dàng hơn nhiều. Ở nước ta, các nhà phát triển xếp hàng và yêu cầu cung cấp chức năng của họ bằng các bài kiểm tra tự động.

những gì tiếp theo

Hãy nói về kế hoạch phát triển của dự án thử nghiệm tự động.

Tất nhiên, miễn là hệ thống khách hàng thân thiết của Sportmaster còn tồn tại và tiếp tục phát triển thì các bài kiểm tra tự động cũng có thể được phát triển gần như vô tận. Vì vậy, hướng phát triển chính là mở rộng vùng phủ sóng.

Khi số lượng bài kiểm tra tự động tăng lên, tổng thời gian hoạt động của chúng sẽ tăng đều đặn và chúng ta sẽ lại phải quay lại vấn đề hiệu suất. Rất có thể, giải pháp sẽ là tăng số lượng luồng song song.

Nhưng đây là những cách phát triển rõ ràng. Nếu chúng ta nói về điều gì đó không tầm thường hơn, chúng ta sẽ nhấn mạnh những điều sau:

1. Giờ đây, việc tự động kiểm tra được quản lý ở cấp DBMS, tức là. Cần có kiến ​​thức về PL/SQL để làm việc thành công. Nếu cần, việc quản lý hệ thống (ví dụ: khởi chạy hoặc tạo siêu dữ liệu) có thể được loại bỏ bởi một loại bảng quản trị nào đó bằng cách sử dụng Jenkins hoặc một cái gì đó tương tự.
2. Mọi người đều yêu thích các chỉ số định lượng và định tính. Đối với thử nghiệm tự động, chỉ báo chung như vậy là Độ bao phủ mã hoặc số liệu độ bao phủ mã. Bằng cách sử dụng chỉ báo này, chúng tôi có thể xác định bao nhiêu phần trăm mã của hệ thống đang được thử nghiệm được kiểm tra tự động. Bắt đầu từ phiên bản 12.2, Oracle cung cấp khả năng tính toán số liệu này và cung cấp việc sử dụng gói DBMS_PLSQL_CODE_COVERAGE tiêu chuẩn.

   Hệ thống kiểm tra tự động của chúng tôi mới hoạt động được hơn một năm và có lẽ bây giờ là lúc để đánh giá mức độ phù hợp của chúng tôi. Trong dự án cuối cùng của tôi (không phải dự án Sportmaster), đây là điều đã xảy ra. Một năm sau khi thực hiện các cuộc kiểm tra tự động, ban quản lý đặt ra nhiệm vụ đánh giá xem chúng tôi xử lý bao nhiêu phần trăm mã. Với mức độ bao phủ hơn 1%, ban quản lý sẽ rất vui. Chúng tôi, những nhà phát triển, mong đợi kết quả khoảng 10%. Chúng tôi đã cài đặt phạm vi bảo hiểm của mã, đo lường nó và nhận được 20%. Để ăn mừng, chúng tôi đã đến nhận giải thưởng, nhưng chúng tôi đến lấy nó như thế nào và đi đâu sau đó lại là một câu chuyện hoàn toàn khác.

3. Autotests có thể kiểm tra các dịch vụ web được hiển thị. Oracle cho phép bạn làm điều này và chúng ta sẽ không còn gặp phải một số vấn đề nữa.
4. Và tất nhiên, hệ thống kiểm tra tự động của chúng tôi có thể được áp dụng cho dự án khác. Giải pháp chúng tôi nhận được mang tính phổ quát và chỉ yêu cầu sử dụng Oracle. Tôi nghe nói rằng có mối quan tâm đến việc thử nghiệm tự động trên các dự án Sportmaster khác và có lẽ chúng tôi sẽ đến với họ.

Những phát hiện

Hãy tóm tắt. Trong dự án hệ thống khách hàng thân thiết trong Sportmaster, chúng tôi đã triển khai hệ thống kiểm tra tự động. Cơ sở của nó là giải pháp utPLSQL của Stephen Feuerstein. Xung quanh utPLSQL là mã dành cho các mô-đun tự động kiểm tra và tự viết phụ trợ: trình khởi chạy, mô-đun tạo dữ liệu và các mô-đun khác. Các cuộc kiểm tra tự động diễn ra hàng ngày và quan trọng nhất là hoạt động và mang lại lợi ích. Chúng tôi tin rằng chúng tôi đã bắt đầu phát hành phần mềm có chất lượng cao hơn. Đồng thời, giải pháp thu được có tính phổ quát và có thể được áp dụng miễn phí cho bất kỳ dự án nào cần tổ chức thử nghiệm tự động trên Oracle DBMS.

PS Bài viết này không cụ thể lắm: có rất nhiều văn bản và thực tế không có ví dụ kỹ thuật. Nếu chủ đề nhìn chung thú vị thì chúng tôi sẵn sàng tiếp tục chủ đề đó và quay lại phần tiếp theo, nơi chúng tôi sẽ cho bạn biết những gì đã thay đổi trong sáu tháng qua và cung cấp các ví dụ về mã.

Viết nhận xét nếu có những điểm cần nhấn mạnh trong tương lai hoặc những câu hỏi cần tiết lộ.

Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. Đăng nhập, xin vui lòng.

Chúng ta sẽ viết thêm về điều này nhé?

• Vâng, tất nhiên

• Không, cám ơn

12 người dùng bình chọn. 4 người dùng bỏ phiếu trắng.

Nguồn: www.habr.com