6

Kiểm tra tự động PHẢI nhanh để phản ánh trạng thái dự án thời gian thực. Ý tưởng là:Làm cách nào để giữ các kiểm tra tự động nhanh chóng?

  1. sau khi thực hiện bất kỳ cam kết tự động lưu trữ nào (nhanh nhất có thể).
  2. nếu xây dựng các thử nghiệm tự động thành công được bắt đầu. PHẢI nhanh.

Đây là cách tốt nhất tôi biết để tìm hiểu xem những thay đổi của bạn có phá vỡ bất kỳ điều gì không.

Lúc đầu, có vẻ như việc tạo bản dựng nhanh thật khó, nhưng chúng tôi đã xoay sở để giữ khoảng 100 giây. cho một giải pháp của 105 (!) dự án (MSVS 2008 C#).

Các thử nghiệm dường như không đơn giản (chúng tôi sử dụng NUnit FW). Thử nghiệm đơn vị không phải là một vấn đề lớn. Đó là các bài kiểm tra tích hợp giết chết chúng ta. Và không phải thực tế là chúng chậm hơn (bất kỳ ý tưởng nào về cách làm cho chúng nhanh hơn được nhiều người đánh giá cao) nhưng thực tế là môi trường phải được thiết lập chậm hơn (atm ~ 1000 giây)!

Thử nghiệm tích hợp của chúng tôi sử dụng dịch vụ web/win (19 cho đến nay) cần phải được triển khai lại để phản ánh các thay đổi mới nhất. Điều đó bao gồm khởi động lại dịch vụ và rất nhiều hoạt động HDD R/W.

Bất kỳ ai cũng có thể chia sẻ kinh nghiệm về cách môi trường và luồng công việc nên/có thể được sắp xếp/tối ưu hóa để tăng tốc giai đoạn thử nghiệm tự động. Các tắc nghẽn và giải pháp "cấp thấp" là gì.

P.S. sách và các bài báo rộng được chào đón, nhưng các giải pháp làm việc trên thế giới thực được đánh giá cao hơn nhiều.

Trả lời

5

Có một số chiến lược tối ưu hóa bạn có thể làm để cải thiện thông lượng kiểm tra, nhưng bạn cần phải tự hỏi mục đích của thử nghiệm này là gì và tại sao nó cần phải nhanh.

Một số thử nghiệm cần có thời gian. Đây là một thực tế của cuộc sống. Kiểm tra tích hợp thường mất thời gian và bạn thường phải thiết lập một môi trường để có thể thực hiện chúng. Nếu bạn thiết lập một môi trường, bạn sẽ muốn có một môi trường gần với môi trường sản xuất cuối cùng nhất có thể.

Bạn có hai lựa chọn:

  1. Tối ưu hóa các bài kiểm tra, hoặc việc triển khai các cuộc thử nghiệm.
  2. Không thực hiện chúng thường xuyên.

Theo kinh nghiệm của tôi, tốt hơn là nên có môi trường tích hợp đúng, tìm lỗi và đại diện cho môi trường sản xuất cuối cùng đầy đủ. Tôi thường chọn tùy chọn 2 (1).

Thật hấp dẫn khi nói rằng chúng tôi sẽ kiểm tra mọi thứ mọi lúc, nhưng trong thực tế bạn cần một chiến lược.

(1) Ngoại trừ nếu có vô số lỗi mà chỉ được tìm thấy trong hội nhập, trong trường hợp đó, quên đi mọi thứ tôi đã nói :-)

+0

Chúng tôi đang ở trong trạng thái, khi kiểm tra tích hợp không mất quá nhiều thời gian, nhưng triển khai chúng là một kẻ giết người. Vì vậy, chúng tôi thử (1) vào lúc này. – Dandikas

3

Chúng tôi sử dụng .NET và NUnit, hỗ trợ các danh mục (thuộc tính bạn có thể đưa vào thử nghiệm). Sau đó, chúng tôi thực hiện các thử nghiệm chạy dài và đặt chúng trong một NightlyCategory để chúng chỉ chạy trong các bản dựng hàng đêm chứ không phải trong các bản dựng liên tục mà chúng tôi muốn chạy nhanh.

+0

Có nhiều cách để tránh chạy thử nghiệm tốn thời gian. Tại thời điểm này chúng tôi cố gắng đầu tiên để thực hiện bất kỳ tối ưu hóa có thể và chỉ sau đó bắt đầu trì hoãn các bài kiểm tra, như sau đó bạn mất một câu trả lời cho "đã làm thay đổi của tôi phanh bất cứ điều gì". – Dandikas

+0

Đây là những gì chúng tôi làm. Danh mục cho thử nghiệm trên 30 giây (quy tắc ngón tay cái) nằm trong danh mục "NightBuildTest". Khác đang hoạt động tất cả các thời gian. –

0

Buildbot: http://buildbot.net/trac Tôi không thể đề xuất đủ điều này nếu bạn đang thực hiện Tích hợp liên tục (kiểm tra tự động). Với cấu hình nhanh, tất cả các bài kiểm tra đơn vị của chúng tôi sẽ chạy mỗi khi có một cam kết, và các bài kiểm tra tích hợp dài hơn sẽ chạy định kỳ suốt cả ngày (3 lần cuối cùng tôi đã kiểm tra, nhưng điều này có thể dễ dàng thay đổi).

+0

Chúng tôi sử dụng CC.net, nhưng tôi sẽ xem xét buildbot – Dandikas

1

Tôi đã tổng hợp bản trình bày trên Turbo-Charged Test Suites. Phần thứ hai là nhằm vào các nhà phát triển Perl, nhưng nửa đầu có thể hữu ích cho bạn. Tôi không biết đủ về phần mềm của bạn để biết nó có phù hợp không. Về cơ bản, nó đề cập đến các kỹ thuật để tăng tốc sử dụng cơ sở dữ liệu trong các bộ kiểm thử và chạy thử nghiệm trong một quá trình duy nhất để tránh việc tải lại liên tục các thư viện.

1

tôi muốn đề nghị có một vài cấp cao đầu đến cuối bài kiểm tra, và nếu bất kỳ một trong số đó không thành công, hãy chạy thử nghiệm 'độ phân giải cao hơn'.

Hãy nghĩ đến việc hỗ trợ kỹ thuật qua điện thoại ...

Máy tính của bạn có hoạt động không? nếu có, đã hoàn tất. Nếu không, máy tính của bạn có bật không? ...

Để thử nghiệm đơn vị của mình, tôi có một vài thử nghiệm nhanh như "máy tính của tôi có hoạt động không?" nếu vượt qua, tôi không thực hiện phần còn lại của bộ phần mềm của tôi. Nếu bất kỳ thử nghiệm nào trong số đó không thành công, tôi thực thi bộ kiểm tra mức thấp hơn có liên quan để cho tôi một khung nhìn có độ phân giải cao hơn vào lỗi đó.

Quan điểm của tôi là chạy một bộ kiểm tra cấp cao nhất toàn diện sẽ mất chưa đầy nửa giây.

Cách tiếp cận này mang lại cho tôi cả tốc độ và chi tiết.

+0

Chắc chắn vấn đề với điều đó là nếu các bài kiểm tra cấp cao nhất của bạn bỏ lỡ một số điều kiện mà nên làm cho các bài kiểm tra thất bại. Để sử dụng sự tương tự của bạn, "máy tính của bạn có hoạt động không?" - nếu con chuột bị hỏng - nó * sẽ * thất bại trong kiểm tra, nhưng "máy tính hoạt động" – dbr

+0

Tôi đồng ý, chọn kết thúc của bạn để kết thúc kiểm tra cẩn thận và chạy tất cả các bài kiểm tra chi tiết trong khi bạn ngủ. Nếu các kiểm tra chi tiết của bạn cho thấy một lỗi mà kết thúc của bạn để kết thúc kiểm tra không, xem làm thế nào bạn có thể cải thiện kết thúc của bạn để kết thúc kiểm tra. Bắt đầu một nơi nào đó, sau đó cải thiện. – shapr

1

thực tế là môi trường phải được thiết lập chậm hơn (atm ~ 1000 giây)!

Ít nhất bạn biết phải tập trung ở đâu ... Bạn có biết thời gian đó đang được chi tiêu không?

Rõ ràng là mọi giải pháp sẽ phụ thuộc vào các chi tiết cụ thể tại đây.

Có ba giải pháp mà tôi đã sử dụng trong loại tình huống này:

  1. sử dụng nhiều máy móc. Có lẽ bạn có thể phân vùng dịch vụ của mình thành hai máy? Điều đó sẽ cho phép bạn giảm thời gian thiết lập của bạn trong 1/2?

  2. sử dụng máy nhanh hơn? Trong một tình huống mà tôi biết ở nhóm, việc kiểm tra tích hợp của họ thực hiện từ 18 giờ đến 1 giờ bằng cách nâng cấp phần cứng (nhiều CPU, bộ nhớ RAID nhanh, RAM nhiều hơn, công việc). Chắc chắn nó chi phí cho họ vào thứ tự của $ 10k USD nhưng nó đã được giá trị nó.

  3. sử dụng cơ sở dữ liệu trong bộ nhớ để kiểm tra tích hợp. Có, tôi biết bạn cũng sẽ muốn thử nghiệm với cơ sở dữ liệu thực, nhưng có lẽ bạn có thể chạy thử nghiệm ban đầu dựa vào phiên bản bộ nhớ để nhận phản hồi nhanh.

1

Giải pháp tốt nhất cho tình huống là sao lưu hình ảnh ma của môi trường và khôi phục hình ảnh trước khi đặt lại môi trường. Điều này sẽ có ý nghĩa hơn đối với thời gian được sử dụng.

Các vấn đề liên quan