Làm thế nào để đối phó với số lượng lớn các bài kiểm tra thất bại? [đóng cửa]

Tôi đang làm việc trong quá trình phát triển một dự án cũ được viết bằng Java. Chúng tôi có hơn 10 triệu LỘC và thậm chí tệ hơn, hơn 4000 thử nghiệm chức năng.

Các thử nghiệm, được lên kế hoạch bởi Hudson, thất bại như điên với mỗi thay đổi mã lớn hơn. Việc xác minh lỗi thử nghiệm - nếu đó là sự cố trong sản phẩm hoặc trong thử nghiệm, phải mất vài tháng. Chúng tôi không thể xóa các bài kiểm tra cũ vì chúng tôi không biết những gì chúng đang kiểm tra!

Chúng ta có thể làm gì? Làm thế nào để tiến hành với số lượng thử nghiệm di sản như vậy?

Bỏ rơi họ.

Tôi biết thật khó để từ bỏ thứ gì đó rõ ràng là rất nhiều nỗ lực để sản xuất, nhưng các thử nghiệm không hiệu quả với bạn, chúng đang chống lại bạn. Một bộ thử nghiệm được cho là mang lại cho bạn sự tự tin rằng hệ thống sẽ làm những gì nó phải làm. Nếu nó không làm điều đó, đó là một trách nhiệm thay vì một tài sản. Việc hệ thống hoặc các bài kiểm tra có lỗi hay không - miễn là việc chạy bộ kiểm thử báo hiệu một lượng lớn lỗi, nó không thể thực hiện được mục đích của nó.

Những gì bạn cần bây giờ là một bộ thử nghiệm mới chạy không có lỗi. Điều đó có nghĩa là ban đầu nó sẽ có phạm vi bảo hiểm ít, trên thực tế hầu như không có bảo hiểm. Mỗi khi bạn sửa chữa hoặc dành thời gian để hiểu thấu đáo điều gì đó về hệ thống của mình, bạn sẽ sắp xếp lại kiến ​​thức đó trong một bài kiểm tra. Theo thời gian, điều này sẽ tạo ra một mạng lưới an toàn mới mà bạn có thể xây dựng trong tương lai. Cố gắng vá một mạng lưới an toàn cũ, không hiểu biết là một khoảng thời gian gần như không bao giờ có giá trị.

Tôi thậm chí sẽ ủng hộ việc chuyển các bài kiểm tra từ bộ cũ sang bộ mới. Chắc chắn, một số trong số họ có thể thành công ngay bây giờ, nhưng đó có phải là vì họ đang thử nghiệm chính xác những gì họ cần thử nghiệm, hoặc chỉ vì một số bức ảnh ngẫu nhiên luôn bắn trúng mục tiêu? Rõ ràng là bạn phải thực dụng về những gì có thể và không thể làm được với nỗ lực bạn có thể bỏ ra, nhưng bạn không thể thỏa hiệp theo nguyên tắc rằng một bộ kiểm tra phải chạy sạch để thực hiện công việc của mình .

Đi và sửa các bài kiểm tra.

Sai lầm lớn nhất của bạn là bạn đã cho phép các bài kiểm tra thất bại, và rõ ràng bạn đã bỏ qua nó trong một thời gian. Những gì bạn có không phải là "kiểm tra di sản" - bạn đang làm việc với một mã kế thừa. Và tôi coi mọi mã được viết mà không cần kiểm tra là di sản.

Việc xác minh lỗi thử nghiệm - nếu đó là sự cố trong sản phẩm hoặc trong thử nghiệm, phải mất vài tháng. Chúng tôi không thể xóa các bài kiểm tra cũ vì chúng tôi không biết những gì chúng đang kiểm tra!

Có vẻ như có một vấn đề thậm chí còn lớn hơn trong tổ chức của bạn, vì bạn không làm việc với các yêu cầu rõ ràng. Tôi không thể hiểu rằng bạn (hoặc người khác) không thể xác nhận hành vi đúng.

Các xét nghiệm có giá trị. Ít nhất, họ ghi lại rằng ai đó đã cân nhắc rằng họ nên dành thời gian viết chúng, vì vậy có lẽ họ đã có một số giá trị với ai đó một lần. Nếu may mắn, chúng sẽ chứa một bản ghi đầy đủ tất cả các tính năng và lỗi mà nhóm đã từng làm việc - mặc dù chúng cũng có thể là một cách để đạt được một số số bao phủ thử nghiệm tùy ý mà không được suy nghĩ cẩn thận. Cho đến khi bạn nhìn vào chúng, bạn sẽ không biết đó là trường hợp nào ở đây.

Nếu hầu hết các bài kiểm tra của bạn vượt qua hầu hết thời gian, thì bạn chỉ cần cắn viên đạn và đầu tư thời gian để tìm ra những bài kiểm tra thất bại đang cố gắng làm gì, và sửa chữa hoặc cải thiện chúng để lần sau công việc sẽ dễ dàng hơn. Trong trường hợp đó, bỏ qua phần Xác định ý định cho từng phần kiểm tra , để có một số lời khuyên về những việc cần làm với một số lượng nhỏ các bài kiểm tra thất bại.

Mặt khác, bây giờ bạn có thể phải đối mặt với bản dựng Đỏ và hàng trăm hoặc thậm chí hàng nghìn bài kiểm tra đã không được thực hiện trong một thời gian và Jenkins đã không còn Xanh trong một thời gian dài. Tại thời điểm này, trạng thái bản dựng Jenkins đã trở nên vô dụng và một chỉ báo chính về các vấn đề với việc đăng ký của bạn không còn hoạt động. Bạn cần khắc phục điều này, nhưng không đủ khả năng để ngăn chặn mọi tiến bộ trong khi bạn dọn dẹp mớ hỗn độn trong phòng khách của bạn.

Để giữ sự tỉnh táo của bạn trong khi thực hiện khảo cổ học cần thiết để xác định giá trị nào có thể được phục hồi từ các thử nghiệm đã thất bại, tôi khuyên bạn nên thực hiện các bước sau:

Tạm thời vô hiệu hóa các bài kiểm tra thất bại.

Có một số cách bạn có thể làm điều này, tùy thuộc vào môi trường của bạn, mà bạn không mô tả rõ ràng để tôi thực sự không thể đề xuất bất kỳ cách cụ thể nào.

Một số khung hỗ trợ khái niệm về những thất bại dự kiến. Nếu là của bạn thì điều này thật tuyệt vời, vì bạn sẽ thấy đếm ngược xem có bao nhiêu bài kiểm tra còn lại trong danh mục này và thậm chí bạn sẽ được thông báo nếu một số trong số chúng bắt đầu vượt qua bất ngờ.

Một số khung hỗ trợ các nhóm thử nghiệm và cho phép bạn chỉ cho Hudson chạy một số thử nghiệm hoặc bỏ qua một nhóm các thử nghiệm. Điều này có nghĩa là đôi khi bạn có thể chạy nhóm thử nghiệm theo cách thủ công để xem liệu có bất kỳ hiện đang đi qua.

Một số khung cho phép bạn chú thích hoặc đánh dấu các bài kiểm tra đơn lẻ bị bỏ qua. Điều này khó hơn để điều hành chúng như một nhóm trong trường hợp này, nhưng điều đó ngăn chúng làm bạn mất tập trung.

Bạn có thể di chuyển các bài kiểm tra đến một cây nguồn thường không có trong bản dựng.

Trong trường hợp cực đoan, bạn có thể xóa mã khỏi ĐẦU của hệ thống kiểm soát phiên bản, nhưng điều này sẽ khiến việc nhận biết khi giai đoạn thứ ba hoàn thành khó khăn hơn.

Mục tiêu là khiến Jenkins đi Green càng sớm càng tốt, vì vậy bạn có thể bắt đầu đi đúng hướng càng sớm càng tốt.

Giữ các bài kiểm tra có liên quan.

Giải quyết để thêm các thử nghiệm mới khi bạn thêm hoặc sửa đổi mã và cam kết giữ tất cả các thử nghiệm vượt qua.

Các thử nghiệm có thể thất bại vì nhiều lý do, bao gồm cả thực tế là các thử nghiệm được viết tốt để bắt đầu. Nhưng một khi bạn có được Jenkins màu xanh lá cây, giữ nó theo cách đó thực sự quan trọng.

Làm quen với việc viết các bài kiểm tra tốt, và làm cho nó trở thành một vấn đề lớn nếu các bài kiểm tra bắt đầu thất bại.

Xác định ý định cho mỗi bài kiểm tra.

Trải qua các bài kiểm tra khuyết tật từng cái một. Bắt đầu với những mô-đun ảnh hưởng đến các mô-đun mà bạn thay đổi thường xuyên nhất. Xác định ý định của bài kiểm tra, và lý do thất bại.

• Nó có kiểm tra một tính năng đã bị xóa khỏi cơ sở mã trên mục đích không? Sau đó, bạn có thể xóa nó.

• Có phải nó đang bắt một lỗi mà chưa ai nhận thấy? Phục hồi thử nghiệm và sửa lỗi.

• Có phải nó thất bại bởi vì nó đang đưa ra các giả định không chính đáng (ví dụ: giả sử văn bản nút sẽ luôn bằng tiếng Anh, nhưng bây giờ bạn đã bản địa hóa ứng dụng của mình cho nhiều ngôn ngữ)? Sau đó tìm ra cách làm cho bài kiểm tra tập trung vào một điều duy nhất và cách ly nó khỏi những thay đổi không liên quan nhất có thể.

• Thử nghiệm có mở rộng ra toàn bộ ứng dụng và đại diện cho thử nghiệm Hệ thống không? Sau đó xóa nó khỏi bộ kiểm tra Jenkins chính của bạn và thêm nó vào bộ Regression chạy ít thường xuyên hơn.

• Kiến trúc của ứng dụng đã thay đổi ngoài sự công nhận, vì vậy bài kiểm tra không còn có ích gì nữa không? Xóa đi.

• Thử nghiệm đã được thêm vào để tăng số liệu thống kê bảo hiểm mã một cách giả tạo, nhưng thực tế không có gì khác hơn là xác nhận rằng mã biên dịch chính xác và không đi vào một vòng lặp vô hạn? Hoặc nếu không, thử nghiệm chỉ đơn giản xác nhận rằng khung mô phỏng đã chọn của bạn trả về kết quả mà bạn vừa nói với nó? Xóa đi.

Do đó, một số thử nghiệm sẽ đứng, một số được sửa đổi, một số được chia thành nhiều phần độc lập, có kích thước khớp cắn và một số được loại bỏ. Miễn là bạn vẫn đạt được tiến bộ với các yêu cầu mới, dành ra một chút thời gian để xử lý nợ kỹ thuật như thế này là điều có trách nhiệm phải làm.

4000 bài kiểm tra là một vấn đề khó khăn. 40 bài kiểm tra là dễ dàng hơn. Chọn ngẫu nhiên một số lượng kiểm tra có thể quản lý để chạy và phân tích. Phân loại kết quả như sau:

1. Kiểm tra vô dụng
2. Kiểm tra hữu ích chạy sạch
3. Kiểm tra hữu ích mà thất bại

Nếu rất nhiều bài kiểm tra thuộc danh mục đầu tiên, có lẽ đã đến lúc bỏ bộ kiểm tra hiện tại của bạn và tập hợp một bài kiểm tra hữu ích cho mã hiện tại.

Nếu rất nhiều bài kiểm tra thất bại theo những cách cho bạn biết về một vấn đề trong mã của bạn, bạn cần phải làm việc thông qua các bài kiểm tra thất bại để sửa chữa mọi thứ. Bạn có thể thấy rằng việc sửa một hoặc hai lỗi sẽ khiến một số lượng lớn các bài kiểm tra chạy.

Nếu tuyên bố này là đúng,

Các thử nghiệm ... đang thất bại như điên với mỗi thay đổi mã lớn hơn.

sau đó điều đó ngụ ý rằng nếu bạn quay lại mã ngay trước khi "thay đổi mã lớn hơn", thì nhiều bài kiểm tra sẽ lại vượt qua. Sau khi làm điều đó, lấy một phần nhỏ các thay đổi và xem thử nghiệm nào mới thất bại. Điều này sẽ giúp bạn cách ly tốt hơn những thay đổi mã nào đang gây ra lỗi thử nghiệm nào. Đối với mỗi thử nghiệm, một khi bạn đã tách được vấn đề, thì bạn sẽ có thể xác định xem mã mới có bị lỗi hay không, hoặc thử nghiệm là. Nếu đó là một vấn đề với mã mới, hãy đảm bảo so sánh nó với phiên bản mới nhất chỉ trong trường hợp lỗi cụ thể đó đã được sửa.

Lặp lại cho đến khi bạn có cơ sở mã mới nhất.

Điều này có vẻ như là một nhiệm vụ quá sức, nhưng rất có thể là một khi bạn đi xuống con đường này và bắt đầu cô lập một số vấn đề, một mô hình sẽ bắt đầu xuất hiện, điều này có thể đẩy nhanh quá trình. Ví dụ:

• Bạn có thể nhận thấy rằng nhiều bài kiểm tra phụ thuộc vào một cái gì đó còn thiếu sót. Sửa một mảnh có thể sửa nhiều bài kiểm tra.
• Bạn có thể nhận thấy rằng nhiều bài kiểm tra là thiếu sót và cần phải được sửa chữa hoặc loại bỏ.
• Bạn có thể nhận thấy rằng một nhà phát triển cụ thể có tần suất khiến các bài kiểm tra bị phá vỡ cao hơn nhiều. Nhà phát triển đó có thể cần đào tạo hoặc giám sát nhiều hơn.

Nếu bạn không biết những gì họ đang thử nghiệm, hãy xóa chúng cho đến khi bạn biết. Các thử nghiệm là những thứ linh hoạt, nếu bạn loại bỏ một tính năng không còn cần thiết, thì bạn sẽ phải thay đổi thử nghiệm kiểm tra tính năng đó! Vì vậy, trừ khi bạn biết những gì các bài kiểm tra đang thử nghiệm, bạn không có hy vọng thay đổi cơ sở mã với chúng.

Bạn có thể thiết lập hệ thống kiểm tra được thiết lập trên các máy của nhà phát triển và chạy ở đó để các nhà phát triển có thể thấy các phần mà các bài kiểm tra đang tương tác với, hy vọng cung cấp tài liệu còn thiếu này và trở nên quen thuộc hơn với cơ sở mã mà bạn không thay đổi chính xác hoặc không kiểm tra lâu hơn chính xác.

Nói tóm lại - nếu các thử nghiệm cũ của bạn không thành công khi bạn thực hiện thay đổi, mã của bạn sẽ không tốt. Sử dụng các bài kiểm tra đó như một phương tiện giáo dục trong cách hệ thống hoạt động.

Điều quan trọng nhất tôi sẽ làm là quay trở lại các nguyên tắc cơ bản của những gì kiểm tra được cho là phải làm, và những gì doanh nghiệp cần để tiếp tục di chuyển. Công việc của kiểm tra là xác định các vấn đề trước khi chúng trở nên đắt đỏ để khắc phục sau này. Tôi nghĩ từ khóa trong câu đó là "đắt tiền". Những vấn đề này cần một giải pháp kinh doanh. Là vấn đề đắt tiền hiển thị trong lĩnh vực này? Nếu vậy, thử nghiệm là thất bại hoàn toàn.

Quản lý của bạn và bạn cần phải đi kiểm tra thực tế. Bạn đang thấy rằng chi phí phát triển đang tăng vọt vì một loạt các thử nghiệm kế thừa. Làm thế nào để những chi phí đó so với chi phí cung cấp một sản phẩm bị lỗi vì bạn đã vô hiệu hóa các thử nghiệm? Làm thế nào để họ so sánh với nhiệm vụ khó khăn là thực sự tìm ra những hành vi người dùng cần (đó là những điều cần được kiểm tra)?

Đây là những vấn đề cần giải pháp kinh doanh vì chúng chạm vào khía cạnh kinh doanh của công việc. Bạn đang phân phối sản phẩm cho khách hàng và đó là ranh giới mà doanh nghiệp rất quan tâm. Họ có thể xác định các giải pháp mà bạn, với tư cách là nhà phát triển, không thể. Ví dụ, có thể hợp lý khi họ cung cấp hai sản phẩm: một sản phẩm "di sản" cho những người cần độ tin cậy và sẵn sàng từ bỏ các tính năng mới, với một sản phẩm "có tầm nhìn" có thể có nhiều lỗi hơn, nhưng đang đi tiên phong. Điều này sẽ cho bạn cơ hội để phát triển hai bộ thử nghiệm độc lập ... một thử nghiệm kế thừa với 4000 thử nghiệm và một thử nghiệm với nhiều thử nghiệm mà bạn nghĩ cần phải thực hiện (và ghi lại chúng để quá trình này không lặp lại).

Sau đó, nghệ thuật bắt đầu: làm thế nào bạn có thể quản lý con thú hai đầu này để những tiến bộ trong một chi nhánh cũng giúp cho chi nhánh khác? Làm thế nào các bản cập nhật của bạn cho nhánh "trực quan" có thể chảy ngược về nhánh "di sản", mặc dù các yêu cầu kiểm tra cứng nhắc. Làm thế nào có thể tiếp tục yêu cầu của khách hàng trên chi nhánh "di sản" hình thành tốt hơn sự hiểu biết của bạn về các yêu cầu mà khách hàng cũ của bạn sẽ cần nếu cuối cùng bạn sáp nhập lại các sản phẩm?

Chúng tôi không thể xóa các bài kiểm tra cũ vì chúng tôi không biết những gì chúng đang kiểm tra!

Đó chính xác là lý do tại sao bạn nên loại bỏ các bài kiểm tra cũ! Nếu bạn không biết những gì họ đang làm, thì thất bại là vô nghĩa và điều hành chúng là một sự lãng phí thời gian. Ném chúng ra và bắt đầu lại.