Giải pháp thay thế hiệu quả hơn cho việc giảm thiểu quy mô bộ kiểm thử hồi quy CI

Làm thế nào để bạn có thể tập trung vào đúng vấn đề khi bị "đắm chìm" trong hàng tá kết quả từ một bộ kiểm thử hồi quy (regression test suite) khổng lồ? Bài viết này sẽ mô tả một phương pháp tiếp cận xác suất (stochastic approach) dựa trên mức độ dư thừa nhất định trong bộ kiểm thử CI của bạn.

Phương pháp này không đảm bảo bạn sẽ bắt được mọi lỗi mọi lúc, nhưng nó sẽ đưa ra cơ hội tốt nhất để không bỏ sót các dấu hiệu tinh vi của tất cả các lỗi được phát hiện bởi các lần chạy kiểm thử hồi quy CI.

Lời hứa giả tạo của việc cắt giảm bài kiểm thử CI

Có nên bạn giảm số lượng bài kiểm thử đơn vị (unit tests) và kiểm thử hồi quy chạy thường xuyên trong CI để đổi lấy tốc độ và phản hồi nhanh không? Lợi ích của việc cắt giảm quy mô lớn các bộ kiểm thử đã được tranh luận trong nhiều năm. Bạn có thể dễ dàng tìm thấy các máy chủ xây dựng (build servers) hoặc các công ty tư vấn đề xuất các chiến lược để giảm đáng kể số lượng bài kiểm thử trung bình chạy với mỗi bản build. Lợi ích chính được tuyên bố là thời gian quay vòng nhanh hơn cho các nhà phát triển đang chờ kết quả kiểm thử và cải thiện hiệu suất sử dụng dung lượng phòng thí nghiệm CI.

Tuy nhiên, với tư cách là một kiến trúc sư kiểm thử trong đội ngũ DevOps, tôi nhận thấy ý tưởng này hấp dẫn về nguyên tắc nhưng thường gây thất vọng trong thực tế. Khi áp dụng cho các bài kiểm thử mức cao hơn như kiểm thử tích hợp (integration tests) và kiểm thử đầu cuối (end-to-end tests), bạn không còn cách trực tiếp và đáng tin cậy để giảm bộ kiểm thử.

Nếu bạn sử dụng độ tương đồng từ vựng để loại bỏ các bài kiểm thử E2E dư thừa, bạn sẽ bắt được các lỗi rõ ràng nhanh hơn. Nhưng nếu bạn thu nhỏ kích thước mẫu kết quả kiểm thử bằng cách bỏ qua có chiến lược nhiều bài kiểm thử trên hầu hết các bản build, bạn sẽ làm cho tín hiệu yếu từ các lỗi tinh vi trở nên vô hình. Đây là rủi ro lớn không đáng để take, bởi vì các lỗi tinh vi chính là thứ có khả năng thoát ra phần mềm đã phát hành cao nhất, gây ra thiệt hại về tài chính và uy tín.

Hiệu quả hóa các bộ kiểm thử CI lớn

Bạn nên liên tục tối ưu hóa bộ kiểm thử hồi quy CI để loại bỏ các bài kiểm thử cũ hoặc dư thừa. Tuy nhiên, một bộ bài kiểm thử liên quan lớn với mức độ bao phủ mã (code coverage) và chức năng cao là tài sản, không phải bất lợi. Hai vấn đề chính của việc chạy các bộ kiểm thử hồi quy lớn là phản hồi chậm và quá tải dung lượng phòng thí nghiệm CI. Chúng ta sẽ thấy rằng các vấn đề này có thể được giải quyết bằng cách cải thiện kiến trúc kiểm thử của bạn.

Bài viết này sẽ thảo luận về các biện pháp phù hợp để cải thiện kiến trúc kiểm thử sau khi phác thảo một cách tiếp cận để xử lý vấn đề còn lại: tìm ra điều gì là quan trọng cần tập trung trong một "biển" kết quả từ bộ kiểm thử hồi quy lớn. Phương pháp xác suất mà tôi mô tả thực sự dựa vào một mức độ dư thừa nhất định trong bộ kiểm thử CI.

Thuần hóa "Nghịch lý thuốc trừ sâu"

Lý tưởng nhất, các bài kiểm thử hồi quy của chúng ta sẽ luôn nói to và rõ về nơi nằm ra vấn đề. Tuy nhiên, sự rõ ràng đó thường bị thwarted bởi thứ gọi là "nghịch lý thuốc trừ sâu" (pesticide paradox). Thuật ngữ này đề cập đến nghịch lý rằng khi các bài kiểm thử thành công trong việc ngăn chặn lỗi, sức mạnh của bộ kiểm thử hiện tại để tìm ra các lỗi mới sẽ giảm đi. Điều này là do hầu hết các khiếm khuyết mà chúng có thể bắt được đã được tìm thấy hoặc ngăn chặn rồi. Thực tế này để lại một tỷ lệ lớn hơn các lỗi ngẫu nhiên, liên quan đến thời gian (timing-related), ít xác định hơn chỉ xuất hiện trong các điều kiện cụ thể như tắc nghẽn mạng, tải CPU cao, nhiệt độ cao...

Chế độ xem "rắc rối" trên bảng điều khiển

Các lỗi tinh vi nhất (và thường là tồi tệ nhất) là theo từng đợt (episodic), nghĩa là không nhất quán xảy ra. Nếu bạn có phương pháp phân tích các mẫu thất bại mức thấp, bạn có thể bắt được các lỗi tinh vi này bất chấp "nghịch lý thuốc trừ sâu". Chìa khóa để khai thác tiềm năng nằm trong tính biến đổi đó là ngừng nhìn vào kết quả kiểm thử tĩnh chỉ từ đêm qua và thay vào đó chuyển trọng tâm sang chuỗi thời gian của kết quả kiểm thử, để xem xu hướng phát triển như thế nào theo thời gian.

Giải pháp xác suất: Phân tích xu hướng

Hệ thống tôi xây dựng cho phương pháp tiếp cận này xem xét xu hướng 30 ngày cho mỗi bài kiểm thử mỗi khi nó nhận được kết quả mới từ các bài kiểm thử E2E. Nó sử dụng khung Python được truyền cảm hứng bởi lập trình chức năng để đặt tên định tính cho các loại xu hướng đáng kể (ví dụ: không ổn định/flaky, ổn định_lỗi, hồi quy, v.v.). Ngoài nhãn văn bản này, nó còn tạo ra một dải xu hướng đỏ-xanh trong 30 ngày đại diện cho mẫu số lượt qua và thất bại cho mỗi bài kiểm thử.

Sau đó, tôi tạo một chế độ xem đặc biệt trên bảng điều khiển (dashboard) của nhóm hiển thị cả hai yếu tố này cho mỗi bài kiểm thử có xu hướng có vấn đề. Trong trực quan hóa này, chế độ xem "rắc rối", chúng tôi lọc và tập trung vào các bài kiểm thử có xu hướng chỉ ra các hồi quy tiềm năng. Sau khi đưa chế độ xem này vào bảng điều khiển, nhóm của tôi đã học được rằng không đáng để điều tra mọi thất bại từ lần chạy kiểm thử đêm qua. Chúng tôi hiệu quả hơn nhiều trong việc tìm ra hồi quy nếu tập trung vào các bài kiểm thử có xu hướng xấu xuất hiện trong chế độ xem rắc rối của chúng tôi.

Sức mạnh của các bài kiểm thử Non-Gating

Các bài kiểm thử mức cao hơn, đặc biệt là kiểm thử E2E, tự nhiên là không ổn định (flaky) vì chúng bị ảnh hưởng bởi nhiều yếu tố bên ngoài. Do đó, chúng tôi thấy rằng tốt hơn là nên làm cho các bài kiểm thử như vậy trở thành non-gating (không chặn), để chúng không làm hỏng bản build khi thất bại. Phương pháp theo dõi xu hướng được phác thảo đủ tinh chỉnh để xác định các hồi quy, do đó chúng tôi không cần điểm dừng cứng của việc làm thất bại bản build để giữ các hồi quy ngoài bản phát hành phần mềm.

Các vấn đề vẫn đủ "trước mặt" chúng tôi trong trực quan hóa chế độ xem rắc rối để chúng tôi có nhiều cơ hội nhìn thấy và giải quyết chúng. Một lập luận mạnh mẽ để sử dụng công cụ này là nó chuyển trọng tâm từ làm cho các bài kiểm thử sang thành việc thu thập thông tin về tính đúng đắn của phần mềm.

Chữ ký hồi quy rõ ràng

Bạn có thể thấy trong chế độ xem trên là một ví dụ về hồi quy. Các hồi quy là không thể bỏ sót. Kể từ khi triển khai phương pháp này, chúng tôi chỉ xác định được một trường hợp duy nhất mà một lỗi tinh vi phát triển xu hướng xấu, được gắn cờ trong chế độ xem "rắc rối", được nhiều người xem xét và vẫn thoát ra dưới dạng lỗi khách hàng. Nhưng ngay cả trong những trường hợp hiếm hoi khi nó thất bại, lợi thế chính của phương pháp này là chúng tôi nắm bắt được đầy đủ hồ sơ về sự phát triển của trạng thái "rắc rối" để mọi thứ được biết vào mỗi ngày đều có thể kiểm toán hoàn toàn trong các bài phân tích hậu kiểm (post-mortems).

Tận dụng sự dư thừa: Khớp mẫu đa ngữ cảnh

Tôi đã tập trung vào việc bắt các mẫu rắc rối phát triển trong các bài kiểm thử riêng lẻ theo thời gian. Tuy nhiên, nếu bạn đang kiểm tra cùng một chức năng trong các bối cảnh khác nhau, từ các góc độ khác nhau hoặc thông qua các sản phẩm khác nhau sử dụng cùng một mã được chia sẻ, thì một điều thú vị sẽ xảy ra: Bạn có thể tìm thấy các mẫu chỉ ra các vấn đề lặp đi lặp lại và các hồi quy tiềm năng trong một lần chạy kiểm thử của một đêm, thay vì phải đợi vài đêm để xu hướng phát triển.

Khớp mẫu đa ngữ cảnh với tag cloud

Chúng ta có thể sử dụng các trực quan hóa được ghép cặp cho tình huống này. Ví dụ, chúng ta có thể so sánh các đám mây thẻ (tag clouds) của các thẻ tên miền chức năng cấp cao nhất từ các bài kiểm thử thất bại đêm qua với cùng một đám mây thẻ từ lần chạy kiểm thử đêm trước đó. Kích thước tương đối của mỗi thẻ trong đám mây thẻ đại diện cho quy mô, cho biết số lượng thất bại kiểm thử trong từng tên miền chức năng.

Chìa khóa để tìm các mẫu như vậy là có sự dư thừa đủ trong bộ kiểm thử của bạn. Nếu mọi tên miền chức năng đều được kiểm tra ở mức tối thiểu tuyệt đối, không có sự trùng lặp nào, thì chỉ một bài kiểm tra không ổn định sẽ làm sai lệch kết quả và nhóm của bạn sẽ lãng phí thời gian điều tra các dương tính giả. Mẫu thất bại kiểm thử trong một tên miền lặp lại với biên độ đủ lớn, ví dụ như trên nhiều dòng sản phẩm khác nhau sử dụng cùng một mã chia sẻ, mang lại sự tự tin cao hơn nhiều rằng mẫu thất bại xuất phát từ một hồi quy thực sự hoặc vấn đề cơ sở hạ tầng kiểm thử.

Kiến trúc cho Tốc độ, Quy mô và Xác định Hồi quy Hiệu quả

Bạn có thể giảm thiểu thời gian quay vòng chậm bằng cách làm việc trên song song hóa kiểm thử và đảm bảo rằng bạn báo cáo kết quả liên tục, thay vì vào cuối các lần chạy kiểm thử. Ngay cả khi bạn có nhiều bài kiểm tra E2E chạy trên các mục tiêu nhúng thực, bạn vẫn có thể thành công trong việc cung cấp thời gian quay vòng nhanh bằng cách xây dựng một phòng thí nghiệm đủ lớn và cấu trúc các công việc kiểm thử của bạn để chạy song song hàng loạt trên nhiều thiết bị nhúng khác nhau. Khi làm điều này, hãy đảm bảo mỗi công việc liên tục báo cáo kết quả kiểm thử của nó.

Phân tích hậu kiểm

Ngay cả khi nhóm của bạn không làm việc với phần mềm nhúng, việc giả lập (mocking) các phụ thuộc nặng như cơ sở dữ liệu, hệ thống tệp và dữ liệu cảm biến sẽ tăng tốc kiểm thử và do đó giúp với dung lượng phòng thí nghiệm CI. Đối với các giải pháp nhúng trên các máy lớn mà bạn không thể vừa nhiều thiết bị trong phòng thí nghiệm do hạn chế về không gian và chi phí, bạn vẫn có một tùy chọn tốt để song song hóa. Bạn có thể sử dụng phương pháp tiếp cận phần cứng trong vòng lặp (HIL - hardware-in-the-loop) thông minh và thực hiện phần lớn kiểm thử trên các thành phần con nhỏ hơn của hệ thống được lưu trữ trong các giá trong phòng thí nghiệm kiểm thử của bạn.

Kết luận

Vì tôi tiếp cận công việc một cách phân tích và chiến lược, ban đầu tôi thấy đề xuất giảm lượng kiểm thử chạy với mỗi bản build rất hấp dẫn. Với các bài kiểm thử đơn vị, nơi cả kiểm thử và hành vi phần mềm nên hoàn toàn mang tính xác định, tôi không có vấn đề gì với ý tưởng đó.

Tuy nhiên, khi bạn đến mức độ tích hợp và E2E, bạn đang xử lý nhiều lớp phức tạp của hệ thống được kiểm tra sẽ che giấu phần lớn các lỗi tinh vi. Các mẫu tiềm ẩn có thể xác định các lỗi như vậy thường chỉ xuất hiện theo thời gian và chỉ có thể nhìn thấy bởi những người có công cụ được nhắm mục tiêu cụ thể để phát hiện ra chúng. Thu nhỏ kích thước mẫu kết quả kiểm thử của bạn bằng cách bỏ qua có chiến lược nhiều bài kiểm thử phức tạp trên hầu hết các bản build sẽ làm cho tín hiệu yếu từ các lỗi tinh vi trở nên vô hình.

Phương pháp xác suất tôi đã phác thảo mang lại cho bạn cơ hội tốt hơn nhiều để bắt được những lỗi có nguy cơ cao nhất thoát ra phần mềm đã phát hành. Điều đó rất quan trọng bởi vì mặc dù chúng có thể tinh vi, nhưng khi nhân với hàng ngàn khách hàng, các lỗi này có thể có tác động tiêu cực rất lớn.