Làm thế nào để giảm bớt thời gian dành cho thử nghiệm?

Question

Tôi chỉ nhìn lại dự án gần như đã hoàn thành gần đây và tìm thấy một vấn đề rất nghiêm trọng. Tôi đã dành hầu hết thời gian ngân hàng để thử nghiệm mã, tái tạo các tình huống khác nhau "có thể" gây ra lỗi mã.

Bạn có bất kỳ ý tưởng hoặc kinh nghiệm nào để chia sẻ về cách giảm thời gian dành cho thử nghiệm để làm cho sự phát triển thuận lợi hơn không?

Tôi đã cố gắng làm theo khái niệm kiểm thử cho tất cả mã của tôi, nhưng tôi thấy thật khó để đạt được điều này, thực sự cần một số trợ giúp từ những người cao cấp ở đây.

Cảm ơn

Re: tất cả

Cám ơn các câu trả lời trên đây, ban đầu câu hỏi của tôi là làm thế nào để giảm thời gian trên thử nghiệm chung, nhưng bây giờ, vấn đề là xuống thế nào để viết tự động hóa effecient mã kiểm tra.

Tôi sẽ cố gắng cải thiện kỹ năng của mình về cách viết bộ đồ thử nghiệm để cắt giảm phần thời gian này.

Tuy nhiên, tôi vẫn thực sự đấu tranh với cách giảm thời gian để tạo lại lỗi, ví dụ: Dự án blog chuẩn sẽ dễ tái tạo các tình huống có thể gây ra lỗi nhưng hệ thống nội bộ phức tạp có thể "không bao giờ "có thể được kiểm tra một cách dễ dàng, có xứng đáng không? Bạn có bất kỳ ý tưởng về cách xây dựng một kế hoạch thử nghiệm về loại dự án này không?

Cảm ơn bạn vẫn còn câu trả lời.

Answer 1

Thiết kế điều khiển thử nghiệm không phải là về thử nghiệm (đảm bảo chất lượng). Nó đã được đặt tên kém ngay từ đầu.

Đó là về việc có các giả định và thông số kỹ thuật có thể chạy được của chương trình và được thực hiện bởi các lập trình viên trong quá trình lập trình để đảm bảo rằng các giả định là rõ ràng.

Vì các tác vụ đó phải được thực hiện tại một số thời điểm trong vòng đời của sản phẩm, nó chỉ đơn giản là một sự thay đổi của công việc. Cho dù đó là nhiều hơn hoặc ít hiệu quả hơn là một cuộc tranh luận cho một thời điểm khác.

Những gì bạn đề cập đến tôi sẽ không gọi thử nghiệm. Có TDD mạnh có nghĩa là giai đoạn thử nghiệm không phải dựa vào các lỗi mà sẽ bị đánh bắt lâu trước khi chúng đạt đến một thử nghiệm (vì chúng có kinh nghiệm lập trình với thông số tốt và các bên liên quan trong một TDD không môi trường).

Nếu bạn nghĩ rằng các kiểm tra trả trước (specnable spec) là một vấn đề nghiêm trọng, tôi đoán nó đi xuống bao nhiêu công việc các giai đoạn tương đối của phát triển dự kiến ​​sẽ chi phí trong thời gian và tiền bạc?

Answer 2

Không có gì sai với việc dành nhiều thời gian thử nghiệm nếu bạn đang thử nghiệm hiệu quả. Hãy nhớ, phát triển theo hướng thử nghiệm có nghĩa là viết các bài kiểm tra (chủ yếu là tự động) trước tiên (điều này có thể mất một thời gian dài nếu bạn viết một bộ kiểm tra toàn diện). Chạy thử nghiệm không mất nhiều thời gian.

Answer 3

Nhóm Subversion đã phát triển một số pretty good test routines, bằng cách tự động hóa toàn bộ quá trình.

Tôi đã tự bắt đầu sử dụng quy trình này, ví dụ bằng cách viết các bài kiểm tra trước khi thực hiện các tính năng mới. Nó hoạt động rất tốt và tạo ra thử nghiệm nhất quán thông qua toàn bộ quá trình lập trình.

SQLite cũng có hệ thống kiểm tra phong nha với một số very good documentation về cách thực hiện.

Answer 4

Có vẻ như vấn đề của bạn là bạn không làm thử nghiệm tự động. Việc sử dụng các bài kiểm tra tích hợp và đơn vị tự động có thể làm giảm đáng kể lượng thời gian bạn thử nghiệm.

Answer 5

Theo kinh nghiệm của tôi với sự phát triển theo thử nghiệm, tiết kiệm thời gian đến sau khi bạn đã viết các bài kiểm tra, hoặc ít nhất là sau khi bạn đã viết các trường hợp kiểm tra cơ bản. Điều quan trọng ở đây là bạn thực sự phải viết các bài kiểm tra tự động của mình. Cách bạn đặt câu hỏi của bạn khiến tôi tin rằng bạn không thực sự viết các bài kiểm tra tự động. Sau khi bạn có các bài kiểm tra, bạn có thể dễ dàng quay lại sau và cập nhật các bài kiểm tra để che lỗi mà trước đây họ không tìm thấy (để kiểm tra hồi quy tốt hơn) và bạn có thể dễ dàng và tương đối nhanh chóng cấu trúc lại mã của bạn. vẫn hoạt động như mong đợi sau khi bạn đã thay đổi đáng kể nó.

Answer 6

Một trong những điều khó khăn nhất về bất kỳ dự án có kích thước đáng kể nào là thiết kế kiến ​​trúc cơ bản và API. Tất cả điều này được phơi bày ở cấp độ của các bài kiểm tra đơn vị. Nếu bạn đang viết bài kiểm tra trước, thì khía cạnh thiết kế đó sẽ xảy ra khi bạn viết mã các bài kiểm tra của bạn, thay vì logic chương trình. Điều này là phức tạp bởi nỗ lực thêm làm cho mã có thể kiểm tra. Một khi bạn đã có các bài kiểm tra của bạn, logic chương trình thường khá rõ ràng.

Điều đó đang được nói, dường như có một số nhà xây dựng thử nghiệm automatic thú vị trên đường chân trời.

Answer 7

Đầu tiên, nó là tốt mà bạn nhận ra rằng bạn cần sự giúp đỡ - bây giờ đi và tìm thấy một số :)

Ý tưởng là để sử dụng các xét nghiệm để giúp bạn suy nghĩ về những gì mã nên làm, chúng là một phần thời gian thiết kế của bạn.

Bạn cũng nên suy nghĩ về tổng chi phí sở hữu mã. Chi phí của một lỗi làm cho nó thông qua sản xuất chứ không phải là cố định đầu tiên là gì? Nếu bạn đang ở trong một ngân hàng, có ý nghĩa nghiêm trọng nào về việc sai số không? Đôi khi, nội dung phù hợp chỉ mất thời gian.

Answer 8

Tôi nghĩ tôi hiểu. Trên cấp độ phát triển thử nghiệm, bạn có cấp độ kiểm tra của khách hàng và có vẻ như ở cấp độ đó, bạn đang tìm thấy rất nhiều lỗi.

Đối với mọi lỗi bạn tìm thấy, bạn phải dừng lại, lấy mũ thử nghiệm của bạn ra, đặt mũ sinh sản của bạn trên, và tìm ra một chiến lược tái tạo chính xác. Sau đó, bạn phải tài liệu lỗi, có lẽ đặt nó trong một hệ thống theo dõi lỗi. Sau đó, bạn phải đặt mũ thử nghiệm vào. Trong thời gian đó, bạn đã mất bất kỳ thiết lập nào bạn đang làm việc và mất dấu vị trí của bạn trên bất kỳ kế hoạch kiểm tra nào mà bạn đang theo dõi.

Bây giờ - nếu điều đó không phải xảy ra - nếu bạn có rất ít lỗi - bạn có thể zip cùng với quá trình kiểm tra, đúng không?

Chắc chắn rằng tự động hóa kiểm tra lái xe-GUI sẽ giúp giải quyết vấn đề này. Bạn sẽ dành rất nhiều thời gian ghi âm và duy trì các bài kiểm tra, và những bài kiểm tra hồi quy này sẽ mất một khoảng thời gian hợp lý để trả lại khoản đầu tư. Ban đầu, bạn sẽ đi chậm hơn nhiều với các bài kiểm tra hướng đối tượng với GUI-Lái xe.

Vì vậy, (tôi gửi) rằng những gì thực sự có thể giúp ích là chất lượng cao/ban đầu/mã sắp ra khỏi hoạt động phát triển. Kiểm tra vi mô - còn được gọi là kiểm tra nhà phát triển hoặc thử nghiệm theo định hướng phát triển theo nghĩa ban đầu - thực sự có thể trợ giúp với điều đó. Một điều khác có thể giúp là lập trình ghép nối.

Giả sử bạn không thể lấy người khác để ghép nối, tôi dành một giờ để xem xét hệ thống theo dõi lỗi của bạn. Tôi sẽ xem xét 100 lỗi trong quá khứ và cố gắng phân loại chúng thành các nguyên nhân gốc rễ. "Vấn đề đào tạo" không phải là nguyên nhân, nhưng "có thể do một lỗi" có thể xảy ra.

Khi bạn đã phân loại và tính chúng, hãy đặt chúng vào bảng tính và sắp xếp. Bất kỳ nguyên nhân gốc rễ nào xảy ra thường xuyên nhất là nguyên nhân gốc rễ bạn ngăn ngừa trước tiên. Nếu bạn thực sự muốn có được ưa thích, nhân nguyên nhân gốc bởi một số số đó là số tiền đau nó gây ra. (Ví dụ: Nếu trong 100 lỗi đó, bạn có 30 lỗi chính tả trên các menu, dễ sửa lỗi và 10 lỗi javascript khó tạo lại, trước tiên bạn có thể khắc phục vấn đề javascript.)

Giả sử bạn có thể áp dụng một số phép thuật 'sửa chữa' cho mỗi nguyên nhân gốc rễ đó, nhưng nó đáng để bắn. Ví dụ: Biểu tượng trong suốt trong IE6 có thể là do IE6 không thể dễ dàng xử lý tệp .png. Vì vậy, có một kích hoạt kiểm soát phiên bản mà từ chối .gif trên checkin và vấn đề được cố định.

Tôi hy vọng điều đó sẽ hữu ích.

Answer 9

Bạn đã viết:

"Cảm ơn câu trả lời trên đây, ban đầu câu hỏi của tôi là làm thế nào để giảm thời gian trên thử nghiệm chung, nhưng bây giờ, vấn đề là xuống thế nào để viết kiểm tra tự động hiệu quả mã. "

Một phương pháp đã được chứng minh trong nhiều nghiên cứu thực nghiệm để hoạt động cực tốt nhằm tối đa hóa hiệu quả thử nghiệm là thử nghiệm tổ hợp. Trong phương pháp này, người kiểm thử sẽ xác định NHỮNG LOẠI GÌ của những thứ cần được kiểm tra (và nhập nó vào một công cụ đơn giản) và công cụ sẽ xác định CÁCH để kiểm tra ứng dụng. Cụ thể, công cụ sẽ tạo ra các trường hợp thử nghiệm xác định kết hợp các điều kiện thử nghiệm nào sẽ được thực thi trong đó kịch bản thử nghiệm và thứ tự mà mỗi tập lệnh thử nghiệm sẽ được thực thi.

Trong ví dụ August, 2009 IEEE Computer article I co-wrote with Dr. Rick Kuhn, Dr. Raghu Kacker, and Dr. Jeff Lei Tôi đã dẫn đến nơi một nhóm người thử nghiệm đã sử dụng phương pháp thiết kế thử nghiệm tiêu chuẩn của họ và nhóm thử nghiệm thứ hai, thử nghiệm cùng một ứng dụng, sử dụng trình tạo trường hợp thử nghiệm tổ hợp để xác định các trường hợp thử nghiệm cho chúng. Các nhóm sử dụng máy phát hiện trường hợp thử nghiệm tổ hợp tìm thấy, trung bình, nhiều hơn gấp đôi so với nhiều lỗi trong mỗi giờ thử nghiệm. Đó là bằng chứng mạnh mẽ cho hiệu quả. Ngoài ra, các xét nghiệm tổ hợp tìm thấy 13% nhiều khiếm khuyết hơn. Đó là bằng chứng mạnh mẽ về chất lượng/tính toàn diện.

Kết quả đó không phải là bất thường. Thông tin bổ sung về phương pháp này có thể được tìm thấy tại http://www.combinatorialtesting.com/clear-introductions-1 và tổng quan về công cụ của chúng tôi here. Nó chứa ảnh chụp màn hình và giải thích về cách công cụ của chúng tôi làm cho thử nghiệm hiệu quả hơn bằng cách xác định một tập hợp con các thử nghiệm tối đa hóa mức độ phù hợp.

Ngoài ra phiên bản miễn phí của trường hợp máy phát điện thử nghiệm Hexawise của chúng tôi có thể được tìm thấy tại www.hexawise.com/users/new