Này Habr!
Tên tôi là Maxim Ponomarenko và tôi là nhà phát triển tại Sportmaster. Tôi có 10 năm kinh nghiệm trong lĩnh vực CNTT. Anh bắt đầu sự nghiệp của mình trong lĩnh vực kiểm thử thủ công, sau đó chuyển sang phát triển cơ sở dữ liệu. Trong 4 năm qua, tích lũy kiến thức thu được trong quá trình thử nghiệm và phát triển, tôi đã tự động hóa thử nghiệm ở cấp DBMS.
Tôi đã làm việc trong nhóm Sportmaster được hơn một năm và đang phát triển thử nghiệm tự động cho một trong những dự án lớn. Vào tháng 4, những người từ Phòng thí nghiệm Sportmaster và tôi đã phát biểu tại một hội nghị ở Krasnodar, báo cáo của tôi có tên là “Thử nghiệm đơn vị trong DBMS” và bây giờ tôi muốn chia sẻ nó với bạn. Sẽ có rất nhiều văn bản nên tôi quyết định chia báo cáo thành hai bài. Trong phần đầu tiên, chúng ta sẽ nói về tự động kiểm tra và thử nghiệm nói chung, và trong phần thứ hai, tôi sẽ trình bày chi tiết hơn về hệ thống thử nghiệm đơn vị của chúng tôi và kết quả ứng dụng của nó.
Đầu tiên, một chút lý thuyết nhàm chán. Kiểm tra tự động là gì? Đây là thử nghiệm được thực hiện bằng phần mềm và trong CNTT hiện đại, nó ngày càng được sử dụng nhiều trong phát triển phần mềm. Điều này là do thực tế là các công ty đang phát triển, hệ thống thông tin của họ đang phát triển và theo đó, số lượng chức năng cần kiểm tra cũng ngày càng tăng. Việc tiến hành kiểm thử thủ công ngày càng trở nên tốn kém hơn.
Tôi làm việc cho một công ty lớn có các bản phát hành được phát hành hai tháng một lần. Đồng thời, phải mất cả tháng để có hàng tá người kiểm tra kiểm tra chức năng theo cách thủ công. Nhờ việc triển khai tự động hóa bởi một nhóm nhỏ các nhà phát triển, chúng tôi đã có thể giảm thời gian thử nghiệm xuống còn 2 tuần trong một năm rưỡi. Chúng tôi không chỉ tăng tốc độ thử nghiệm mà còn cải thiện chất lượng của nó. Các thử nghiệm tự động được triển khai thường xuyên và chúng luôn thực hiện toàn bộ quá trình kiểm tra có trong đó, tức là chúng tôi loại trừ yếu tố con người.
CNTT hiện đại có đặc điểm là nhà phát triển không chỉ được yêu cầu viết mã sản phẩm mà còn phải viết các bài kiểm tra đơn vị để kiểm tra mã này.
Nhưng điều gì sẽ xảy ra nếu hệ thống của bạn chủ yếu dựa trên logic máy chủ? Không có giải pháp phổ quát hoặc phương pháp hay nhất trên thị trường. Theo quy định, các công ty giải quyết vấn đề này bằng cách tạo ra hệ thống kiểm tra tự viết của riêng họ. Đây là hệ thống kiểm tra tự động do chúng tôi tự viết đã được tạo trong dự án của chúng tôi và tôi sẽ nói về nó trong báo cáo của mình.
Kiểm tra lòng trung thành
Đầu tiên, hãy nói về dự án mà chúng tôi đã triển khai hệ thống kiểm tra tự động. Dự án của chúng tôi là hệ thống khách hàng thân thiết Sportmaster (nhân tiện, chúng tôi đã viết về nó trong ).
Nếu công ty của bạn đủ lớn thì hệ thống khách hàng thân thiết của bạn sẽ có ba thuộc tính tiêu chuẩn:
- Hệ thống của bạn sẽ được tải rất cao
- Hệ thống của bạn sẽ chứa các quy trình tính toán phức tạp
- Hệ thống của bạn sẽ được cải thiện tích cực.
Hãy đi theo thứ tự... Tổng cộng, nếu xem xét tất cả các thương hiệu Sportmaster, thì chúng tôi có hơn 1000 cửa hàng ở Nga, Ukraine, Trung Quốc, Kazakhstan và Belarus. Khoảng 300 lượt mua hàng được thực hiện tại các cửa hàng này mỗi ngày. Tức là cứ sau 000-3 giây lại có 4-XNUMX lần kiểm tra được đưa vào hệ thống của chúng tôi. Đương nhiên, hệ thống khách hàng thân thiết của chúng tôi có tải rất cao. Và vì nó được sử dụng tích cực nên chúng tôi phải cung cấp các tiêu chuẩn cao nhất về chất lượng của nó, bởi vì bất kỳ lỗi nào trong phần mềm đều đồng nghĩa với tổn thất lớn về tiền tệ, danh tiếng và các tổn thất khác.
Đồng thời, Sportmaster thực hiện hơn một trăm chương trình khuyến mãi khác nhau. Có nhiều chương trình khuyến mãi khác nhau: có khuyến mãi sản phẩm, có khuyến mãi dành riêng cho các ngày trong tuần, có khuyến mãi gắn liền với một cửa hàng cụ thể, có khuyến mãi cho số tiền nhận được, có khuyến mãi cho số lượng hàng hóa. Nói chung là không tệ. Khách hàng có tiền thưởng và mã khuyến mại được sử dụng khi mua hàng. Tất cả điều này dẫn đến thực tế là việc tính toán bất kỳ thứ tự nào là một nhiệm vụ rất không hề nhỏ.
Thuật toán thực hiện xử lý đơn hàng thực sự khủng khiếp và phức tạp. Và bất kỳ thay đổi nào đối với thuật toán này đều khá rủi ro. Dường như những thay đổi tưởng chừng như không đáng kể nhất lại có thể dẫn đến những tác động khá khó lường. Nhưng chính những quy trình tính toán phức tạp như vậy, đặc biệt là những quy trình thực hiện chức năng quan trọng, mới là ứng cử viên tốt nhất cho tự động hóa. Việc kiểm tra hàng chục trường hợp tương tự bằng tay rất tốn thời gian. Và vì điểm đầu vào của quy trình không thay đổi nên sau khi mô tả nó một lần, bạn có thể nhanh chóng tạo các thử nghiệm tự động và tự tin rằng chức năng này sẽ hoạt động.
Vì hệ thống của chúng tôi được sử dụng tích cực nên doanh nghiệp sẽ muốn điều gì đó mới mẻ từ bạn, sống theo thời đại và hướng đến khách hàng. Trong hệ thống khách hàng thân thiết của chúng tôi, các bản phát hành sẽ được phát hành hai tháng một lần. Điều này có nghĩa là cứ hai tháng một lần chúng tôi cần thực hiện hồi quy hoàn toàn toàn bộ hệ thống. Đồng thời, một cách tự nhiên, giống như trong bất kỳ công nghệ CNTT hiện đại nào, quá trình phát triển không chuyển ngay từ nhà phát triển sang sản xuất. Nó bắt nguồn từ mạch của nhà phát triển, sau đó lần lượt đi qua băng ghế thử nghiệm, phát hành, chấp nhận và chỉ sau đó mới đưa vào sản xuất. Ở mức tối thiểu, trên các mạch thử nghiệm và giải phóng, chúng ta cần thực hiện hồi quy hoàn toàn toàn bộ hệ thống.
Các thuộc tính được mô tả là tiêu chuẩn cho hầu hết mọi hệ thống khách hàng thân thiết. Hãy nói về các tính năng của dự án của chúng tôi.
Về mặt công nghệ, 90% logic của hệ thống khách hàng thân thiết của chúng tôi dựa trên máy chủ và được triển khai trên Oracle. Có một ứng dụng khách được cung cấp ở Delphi, ứng dụng này thực hiện chức năng của một quản trị viên nơi làm việc tự động. Có các dịch vụ web dành cho các ứng dụng bên ngoài (ví dụ: một trang web). Vì vậy, rất hợp lý nếu chúng tôi triển khai hệ thống kiểm thử tự động thì chúng tôi sẽ thực hiện trên Oracle.
Hệ thống khách hàng thân thiết trong Sportmaster đã tồn tại hơn 7 năm và được tạo ra bởi các nhà phát triển đơn lẻ... Số lượng nhà phát triển trung bình trong dự án của chúng tôi trong 7 năm này là 3-4 người. Nhưng trong năm qua, nhóm của chúng tôi đã phát triển đáng kể và hiện có 10 người đang làm việc trong dự án. Nghĩa là, những người đến với dự án không quen thuộc với các nhiệm vụ, quy trình và kiến trúc điển hình. Và có nhiều nguy cơ chúng ta sẽ bỏ lỡ sai lầm.
Đặc điểm của dự án là thiếu vắng những người thử nghiệm chuyên trách như các đơn vị nhân viên. Tất nhiên là có thử nghiệm, nhưng việc thử nghiệm được thực hiện bởi các nhà phân tích, ngoài các trách nhiệm chính khác của họ: giao tiếp với khách hàng doanh nghiệp, người dùng, phát triển các yêu cầu hệ thống, v.v. v.v... Mặc dù thực tế là thử nghiệm được thực hiện với chất lượng rất cao (điều này đặc biệt thích hợp để đề cập, vì một số nhà phân tích có thể lọt vào mắt xanh của báo cáo này), hiệu quả của việc chuyên môn hóa và tập trung vào một thứ vẫn chưa bị hủy bỏ .
Xem xét tất cả những điều trên, để cải thiện chất lượng sản phẩm được giao và giảm thời gian phát triển, ý tưởng tự động hóa thử nghiệm trên một dự án có vẻ rất hợp lý. Và ở các giai đoạn khác nhau trong quá trình tồn tại của hệ thống khách hàng thân thiết, các nhà phát triển cá nhân đã nỗ lực hoàn thiện mã của họ bằng các bài kiểm tra đơn vị. Nhìn chung, đó là một quá trình khá rời rạc, mọi người đều sử dụng kiến trúc và phương pháp của riêng mình. Kết quả cuối cùng là chung cho các bài kiểm tra đơn vị: các bài kiểm tra đã được phát triển, sử dụng một thời gian, được lưu trữ trong bộ lưu trữ tệp đã được phiên bản, nhưng tại một số điểm, chúng ngừng chạy và bị lãng quên. Trước hết, điều này là do thực tế là các bài kiểm tra gắn liền với một người biểu diễn cụ thể hơn là với dự án.
utPLSQL ra tay giải cứu
Bạn có biết gì về Stephen Feuerstein không?
Đây là một chàng trai thông minh, người đã dành phần lớn sự nghiệp của mình để làm việc với Oracle và PL/SQL và đã viết khá nhiều tác phẩm về chủ đề này. Một trong những cuốn sách nổi tiếng của ông có tên là: “Oracle PL/SQL. Dành cho những người chuyên nghiệp." Chính Stephen là người đã phát triển giải pháp utPLSQL, hay còn gọi là khung Kiểm thử đơn vị cho Oracle PL/SQL. Giải pháp utPLSQL đã được tạo ra vào năm 2016, nhưng nó vẫn tiếp tục được tích cực nghiên cứu và phát hành các phiên bản mới. Tại thời điểm báo cáo, phiên bản mới nhất có từ ngày 24 tháng 2019 năm XNUMX.
Nó là gì. Đây là một dự án nguồn mở riêng biệt. Nó nặng vài megabyte, bao gồm các ví dụ và tài liệu. Về mặt vật lý, nó là một lược đồ riêng biệt trong cơ sở dữ liệu ORACLE với một tập hợp các gói và bảng để tổ chức kiểm tra đơn vị. Quá trình cài đặt mất vài giây. Một tính năng đặc biệt của utPLSQL là tính dễ sử dụng.
Trên toàn cầu, utPLSQL là một cơ chế để chạy thử nghiệm đơn vị, trong đó thử nghiệm đơn vị được hiểu là các thủ tục hàng loạt thông thường của Oracle, việc tổ chức tuân theo các quy tắc nhất định. Ngoài việc khởi chạy, utPLSQL còn lưu trữ nhật ký tất cả các lần chạy thử nghiệm của bạn và còn có hệ thống báo cáo nội bộ.
Hãy xem một ví dụ về mã kiểm thử đơn vị trông như thế nào, được triển khai bằng kỹ thuật này.
Vì vậy, màn hình hiển thị mã cho đặc tả gói điển hình kèm theo các bài kiểm tra đơn vị. Các yêu cầu bắt buộc là gì? Gói phải có tiền tố là "utp_". Tất cả các quy trình có bài kiểm tra phải có cùng một tiền tố. Gói phải chứa hai quy trình chuẩn: “utp_setup” và “utp_teardown”. Quy trình đầu tiên được gọi bằng cách khởi động lại từng bài kiểm tra đơn vị, quy trình thứ hai - sau khi khởi chạy.
Theo quy định, “utp_setup” chuẩn bị cho hệ thống của chúng tôi chạy thử nghiệm đơn vị, chẳng hạn như tạo dữ liệu thử nghiệm. “utp_teardown” - ngược lại, mọi thứ trở về cài đặt gốc và đặt lại kết quả khởi chạy.
Dưới đây là ví dụ về thử nghiệm đơn vị đơn giản nhất để kiểm tra việc chuẩn hóa số điện thoại của khách hàng đã nhập về dạng chuẩn cho hệ thống khách hàng thân thiết của chúng tôi. Không có tiêu chuẩn bắt buộc nào về cách viết thủ tục với bài kiểm tra đơn vị. Theo quy định, một lệnh gọi được thực hiện đối với một số phương thức của hệ thống đang được thử nghiệm và kết quả được phương thức này trả về sẽ được so sánh với kết quả tham chiếu. Điều quan trọng là việc so sánh kết quả tham chiếu và kết quả thu được diễn ra thông qua các phương pháp utPLSQL tiêu chuẩn.
Một bài kiểm tra đơn vị có thể có số lần kiểm tra bất kỳ. Có thể thấy từ ví dụ, chúng tôi thực hiện bốn cuộc gọi liên tiếp đến phương thức đã thử nghiệm để chuẩn hóa số điện thoại và đánh giá kết quả sau mỗi cuộc gọi. Khi phát triển một bài kiểm tra đơn vị, bạn phải tính đến việc có những kiểm tra không ảnh hưởng đến hệ thống dưới bất kỳ hình thức nào và sau một số kiểm tra, bạn cần quay trở lại trạng thái ban đầu của hệ thống.
Ví dụ: trong bài kiểm tra đơn vị được trình bày, chúng tôi chỉ định dạng số điện thoại đầu vào, điều này không ảnh hưởng đến hệ thống khách hàng thân thiết dưới bất kỳ hình thức nào.
Và nếu chúng ta viết các bài kiểm thử đơn vị bằng phương pháp tạo một ứng dụng khách mới, thì sau mỗi lần thử nghiệm, một ứng dụng khách mới sẽ được tạo trong hệ thống, điều này có thể ảnh hưởng đến lần khởi chạy thử nghiệm tiếp theo.
Đây là cách các bài kiểm tra đơn vị được chạy. Có hai tùy chọn khởi chạy có thể có: chạy tất cả các bài kiểm tra đơn vị từ một gói cụ thể hoặc chạy bài kiểm tra đơn vị cụ thể trong một gói cụ thể.
Đây là ví dụ về hệ thống báo cáo nội bộ. Dựa trên kết quả của bài kiểm tra đơn vị, utPLSQL xây dựng một báo cáo nhỏ. Trong đó chúng ta thấy kết quả của từng lần kiểm tra cụ thể và kết quả chung của bài kiểm tra đơn vị.
6 quy tắc tự động kiểm tra
Trước khi bắt đầu tạo một hệ thống mới để thử nghiệm tự động hệ thống khách hàng thân thiết, cùng với ban quản lý, chúng tôi đã xác định các nguyên tắc mà các thử nghiệm tự động trong tương lai của chúng tôi phải tuân thủ.
- Autotests phải có hiệu quả và phải hữu ích. Chúng tôi có những nhà phát triển tuyệt vời, những người chắc chắn cần được nhắc đến, bởi vì một số người trong số họ có thể sẽ xem báo cáo này và họ viết những đoạn mã tuyệt vời. Nhưng ngay cả đoạn mã tuyệt vời của họ cũng không hoàn hảo và đã, đang và sẽ tiếp tục có lỗi. Cần phải tự động kiểm tra để tìm ra những lỗi này. Nếu không đúng như vậy thì hoặc là chúng ta đang viết các bài kiểm tra tự động kém hoặc chúng ta đã đi vào vùng chết mà về nguyên tắc là không được phát triển. Trong cả hai trường hợp, chúng tôi đều làm sai điều gì đó và cách tiếp cận của chúng tôi đơn giản là không có ý nghĩa.
- Nên sử dụng các bài kiểm tra tự động. Thật vô nghĩa khi dành nhiều thời gian và công sức để viết một sản phẩm phần mềm, cất nó vào kho lưu trữ và quên nó đi. Các thử nghiệm nên được chạy và chạy thường xuyên nhất có thể.
- Autotests nên hoạt động ổn định. Bất kể thời gian trong ngày, bệ phóng và các cài đặt hệ thống khác, việc chạy thử sẽ dẫn đến kết quả tương tự. Theo quy định, điều này được đảm bảo bởi thực tế là các bài kiểm tra tự động hoạt động với dữ liệu kiểm tra đặc biệt có cài đặt hệ thống cố định.
- Autotests nên hoạt động ở tốc độ chấp nhận được cho dự án của bạn. Thời gian này được xác định riêng cho từng hệ thống. Một số người có đủ khả năng để làm việc cả ngày, trong khi những người khác thấy điều quan trọng là phải làm việc đó trong vài giây. Sau này tôi sẽ cho bạn biết những tiêu chuẩn tốc độ mà chúng tôi đã đạt được trong dự án của mình.
- Phát triển Autotest phải linh hoạt. Không nên từ chối kiểm tra bất kỳ chức năng nào chỉ vì chúng tôi chưa từng thực hiện nó trước đây hoặc vì một số lý do khác. utPLSQL không áp đặt bất kỳ hạn chế nào đối với việc phát triển và về nguyên tắc, Oracle cho phép bạn triển khai nhiều thứ khác nhau. Hầu hết các vấn đề đều có giải pháp, vấn đề chỉ là thời gian và công sức.
- Khả năng triển khai. Chúng tôi có một số gian hàng nơi chúng tôi cần chạy thử nghiệm. Tại mỗi vị trí, kết xuất dữ liệu có thể được cập nhật bất cứ lúc nào. Cần phải tiến hành một dự án với các thử nghiệm tự động để bạn có thể thực hiện cài đặt toàn bộ hoặc một phần một cách dễ dàng.
Và trong bài đăng thứ hai sau vài ngày nữa, tôi sẽ cho bạn biết chúng tôi đã làm gì và đạt được kết quả gì.
Nguồn: www.habr.com