Kiểm thử đơn vị tự động, kiểm thử tích hợp hoặc kiểm tra chấp nhận [đóng]

TDD và thử nghiệm đơn vị dường như là cơn thịnh nộ lớn tại thời điểm này. Nhưng nó thực sự hữu ích so với các hình thức kiểm tra tự động khác?

Theo trực giác tôi đoán rằng thử nghiệm tích hợp tự động là cách hữu ích hơn so với thử nghiệm đơn vị. Theo kinh nghiệm của tôi, hầu hết các lỗi dường như nằm ở sự tương tác giữa các mô-đun và không quá nhiều logic thực tế (giới hạn thông thường) của mỗi đơn vị. Ngoài ra, hồi quy thường xảy ra do thay đổi giao diện giữa các mô-đun (và thay đổi điều kiện trước và sau điều kiện.)

Có phải tôi đang hiểu nhầm điều gì đó, hoặc tại sao kiểm thử đơn vị lại tập trung quá nhiều so với kiểm thử tích hợp? Nó đơn giản là vì người ta cho rằng kiểm thử tích hợp là thứ bạn có, và kiểm thử đơn vị là điều tiếp theo chúng ta cần học để áp dụng với tư cách là nhà phát triển?

Hoặc có thể đơn giản thử nghiệm đơn giản mang lại mức tăng cao nhất so với sự phức tạp của việc tự động hóa nó?

Bạn có kinh nghiệm gì với thử nghiệm đơn vị tự động, thử nghiệm tích hợp tự động và thử nghiệm chấp nhận tự động và theo kinh nghiệm của bạn, điều gì đã mang lại ROI cao nhất? và tại sao?

Nếu bạn phải chọn chỉ một hình thức thử nghiệm để được tự động hóa trong dự án tiếp theo của bạn, thì đó sẽ là gì?

Cảm ơn trước.

Một yếu tố quan trọng làm cho các bài kiểm tra đơn vị cực kỳ hữu ích là phản hồi nhanh .

Xem xét những gì xảy ra khi ứng dụng của bạn được bảo vệ đầy đủ với các bài kiểm tra tích hợp / Hệ thống / chức năng (vốn đã là một tình huống lý tưởng, khác xa với thực tế ở hầu hết các cửa hàng phát triển). Chúng thường được điều hành bởi một nhóm thử nghiệm chuyên dụng.

• Bạn cam kết thay đổi repo SCM,
• đôi khi (có thể vài ngày) sau đó, những người thử nghiệm có được một bản phát hành nội bộ mới và bắt đầu thử nghiệm nó,
• họ tìm thấy một lỗi và nộp báo cáo lỗi,
• (trong trường hợp lý tưởng) ai đó gán lại báo cáo lỗi cho bạn.

Tất cả điều này có thể mất vài ngày hoặc thậm chí vài tuần. Vào thời điểm này, bạn đã thực hiện các nhiệm vụ khác, vì vậy bạn không có chi tiết nhỏ về mã được viết trước đó trong tâm trí. Hơn nữa, bạn thường không có bất kỳ bằng chứng trực tiếp nào về lỗi thực sự ở đâu, vì vậy cần có thời gian đáng kể để tìm và sửa lỗi.

Trong khi đó trong thử nghiệm đơn vị (TDD)

• bạn viết một bài kiểm tra,
• bạn viết một số mã để đáp ứng bài kiểm tra,
• bài kiểm tra vẫn thất bại
• bạn nhìn vào mã và thông thường bạn có trải nghiệm "oops" trong vài giây (như "oops, tôi quên kiểm tra tình trạng đó!"), sau đó
• sửa lỗi ngay lập tức.

Tất cả điều này xảy ra trong vài phút .

Điều này không có nghĩa là các bài kiểm tra tích hợp / hệ thống không hữu ích; họ chỉ phục vụ các mục đích khác nhau. Với các bài kiểm tra đơn vị được viết tốt, bạn có thể bắt được một tỷ lệ lớn các lỗi trong mã trước khi chúng đến giai đoạn tích hợp, nơi nó đã tốn kém hơn đáng kể để tìm và sửa chúng. Bạn đúng rằng các bài kiểm tra tích hợp là cần thiết để bắt những loại lỗi khó hoặc không thể bắt được bằng các bài kiểm tra đơn vị. Tuy nhiên, theo kinh nghiệm của tôi thì đó là những loại hiếm hơn; hầu hết các lỗi tôi đã thấy là do một số thiếu sót đơn giản hoặc thậm chí tầm thường ở đâu đó bên trong một phương thức.

Chưa kể rằng kiểm thử đơn vị cũng kiểm tra các giao diện của bạn về tính khả dụng / an toàn, v.v., do đó cung cấp cho bạn phản hồi cực kỳ quan trọng để cải thiện thiết kế và API của bạn. IMHO nào có thể làm giảm đáng kể khả năng xảy ra lỗi tích hợp mô-đun / hệ thống susbs: API càng dễ dàng và sạch sẽ thì càng ít có khả năng hiểu nhầm hoặc bỏ sót.

Bạn có kinh nghiệm gì với thử nghiệm đơn vị tự động, thử nghiệm tích hợp tự động và thử nghiệm chấp nhận tự động và theo kinh nghiệm của bạn, điều gì đã mang lại ROI cao nhất? và tại sao?

ROI phụ thuộc vào rất nhiều yếu tố, có lẽ điều quan trọng nhất trong số đó là liệu dự án của bạn là lĩnh vực xanh hay di sản. Với sự phát triển của Greenfield, lời khuyên của tôi (và kinh nghiệm cho đến nay) là thực hiện thử nghiệm đơn vị theo kiểu TDD ngay từ đầu. Tôi tự tin rằng đây là phương pháp hiệu quả nhất trong trường hợp này.

Tuy nhiên, trong một dự án cũ, xây dựng phạm vi kiểm tra đơn vị đủ là một công việc khổng lồ sẽ rất chậm để mang lại lợi ích. Sẽ hiệu quả hơn khi cố gắng bao gồm các chức năng quan trọng nhất bằng các kiểm tra hệ thống / chức năng thông qua UI nếu có thể. (các ứng dụng GUI trên máy tính để bàn có thể khó kiểm tra tự động thông qua GUI, mặc dù các công cụ hỗ trợ kiểm tra tự động đang dần cải thiện ...). Điều này cung cấp cho bạn một mạng lưới an toàn thô nhưng hiệu quả nhanh chóng. Sau đó, bạn có thể bắt đầu dần dần xây dựng các bài kiểm tra đơn vị xung quanh các phần quan trọng nhất của ứng dụng.

Nếu bạn phải chọn chỉ một hình thức thử nghiệm để tự động hóa trong dự án tiếp theo của bạn, thì đó sẽ là gì?

Đó là một câu hỏi lý thuyết và tôi thấy nó vô nghĩa. Tất cả các loại thử nghiệm đều được sử dụng trong hộp công cụ của một kỹ sư SW giỏi và tất cả các thử nghiệm này đều có các tình huống không thể thay thế.

Tất cả các loại thử nghiệm đều rất quan trọng và đảm bảo các khía cạnh khác nhau của hệ thống nằm trong thông số kỹ thuật. Vì vậy, để làm việc ngược, "Nếu tôi phải chọn một loại thử nghiệm ..." thì tôi sẽ không. Kiểm thử đơn vị cung cấp cho tôi thông tin phản hồi khác với kiểm tra tích hợp hoặc kiểm tra tương tác của một người.

Đây là loại / lợi ích của thử nghiệm chúng tôi làm:

• Kiểm tra đơn vị - đảm bảo rằng các đơn vị đang thực hiện công việc như chúng tôi mong đợi. Chúng tôi kiểm tra cả hợp đồng nhà cung cấp và người tiêu dùng cho mọi giao diện - và điều này khá dễ dàng để tự động hóa. Chúng tôi cũng kiểm tra các điều kiện biên của chúng tôi, vv
• Kiểm tra tích hợp - đảm bảo rằng các đơn vị đang làm việc cùng nhau trong buổi hòa nhạc. Điều này chủ yếu là để kiểm tra thiết kế của chúng tôi. Nếu có gì đó bị hỏng ở đây, chúng tôi phải điều chỉnh các bài kiểm tra đơn vị của mình để đảm bảo điều đó không xảy ra lần nữa.
• Kiểm tra hệ thống - đảm bảo hệ thống đáp ứng các yêu cầu / thông số kỹ thuật. Thông thường mọi người làm loại thử nghiệm này.
• Kiểm tra chấp nhận - khách hàng thực hiện việc này để xác minh sản phẩm cuối cùng thực hiện những gì được quảng cáo.

Tùy chọn nhưng đề nghị thử nghiệm:

• Kiểm tra trải nghiệm người dùng: Mặc dù chúng tôi nhận được phản hồi tốt từ kiểm tra hệ thống, nhưng việc mọi người từ khách hàng xem trước một số bản phát hành trước có thể thực sự giúp xác định xem chúng tôi có cần thay đổi mọi thứ trước khi quá muộn hay không.

Chỉ cần hiểu lý do tại sao Kiểm thử đơn vị có lợi thế hơn kiểm thử tích hợp, bạn phải hiểu các đơn đặt hàng kiểm tra cường độ bổ sung mà bạn sẽ cần phải toàn diện. Đối với mọi kết quả có thể có cho đơn vị A, cần phải có một bài kiểm tra. Tương tự cho đơn vị B. Bây giờ, nếu cả hai cùng hoạt động cho một giải pháp hoàn chỉnh hơn, số lượng thử nghiệm là kết hợp. Nói tóm lại, để kiểm tra mọi hoán vị tương tác giữa đơn vị A và đơn vị B, bạn cần kiểm tra A * B. Thêm vào đơn vị C, và số lượng thử nghiệm cho bộ ba sẽ là A * B * C.

Đây là nơi mà khái niệm giao diện và ranh giới đối tượng trở nên rất quan trọng. Giao diện đại diện cho một hợp đồng nhất định. Một người thực hiện giao diện đồng ý rằng nó sẽ hành xử theo một cách nhất định. Tương tự như vậy, một người tiêu dùng của một giao diện đồng ý rằng nó sẽ sử dụng việc thực hiện theo một cách nhất định. Bằng cách viết một bài kiểm tra thu thập mọi lớp thực hiện một giao diện, bạn có thể dễ dàng kiểm tra rằng mỗi lần thực hiện quan sát các hợp đồng giao diện. Đó là một nửa phương trình. Nửa còn lại là để kiểm tra phía người tiêu dùng - đó là nơi các đối tượng giả đến chơi. Giả được cấu hình để đảm bảo rằng các tương tác luôn ở trong spec. Tại thời điểm này, tất cả những gì cần thiết là một vài thử nghiệm tích hợp để đảm bảo rằng chúng tôi đã có người thực hiện / hợp đồng người tiêu dùng chính xác.

Đây là những công cụ khác nhau với các mục tiêu khác nhau:

• Kiểm thử đơn vị là một công cụ thiết kế (TDD) và gần như là điều kiện tiên quyết để tái cấu trúc.

• Các thử nghiệm tích hợp là tuyệt vời để hình dung tiến trình của dự án, và cũng tuyệt vời để tránh các lỗi hồi quy.

Điểm cần nhớ là bạn không thể thực sự thiết kế với các bài kiểm tra tích hợp và bạn sẽ không tìm thấy hồi quy với các bài kiểm tra đơn vị.

Tôi đã sử dụng Selenium rộng rãi để kiểm tra độ tỉnh táo.

Tại một công ty xuất bản web lớn, khi một bản phát hành mới được tạo ra, thông thường phải mất khoảng 3 người thử nghiệm trong khoảng một hoặc hai giờ để truy cập tất cả các gia đình của trang web và đảm bảo mọi thứ đều ổn, theo kịch bản thử nghiệm. Với Selenium, chúng tôi có thể tự động hóa thử nghiệm và phân phối nó trên nhiều máy và trình duyệt. Hiện tại, khi các kịch bản thử nghiệm được chạy, phải mất 3 PC khoảng 10 phút để tự động làm điều tương tự VÀ đưa ra một báo cáo đẹp.

Điều tuyệt vời về selen là bạn có thể kết hợp nó với các khung kiểm tra đơn vị như XUnit, TestNG hoặc MSTest.

Theo kinh nghiệm của tôi, nó cực kỳ có giá trị, tuy nhiên việc thiết lập một thứ như thế thực sự phụ thuộc vào dự án của bạn và nhóm của bạn, vì vậy ROI chắc chắn sẽ thay đổi.

ROI tốt nhất thường là thử nghiệm sớm nhất có thể tìm thấy loại lỗi đó.

Kiểm thử đơn vị sẽ tìm thấy hầu hết các lỗi chỉ trong một phương thức, hoặc có thể là một thành phần. Nó tìm thấy các lỗi thường có thể được sửa trong vài phút, với tổng thời gian quay vòng dưới một giờ. RẤT kiểm tra giá rẻ, RẤT lỗi giá rẻ để tìm và sửa chữa! Nếu những lỗi đó biến nó thành thử nghiệm tích hợp, thì việc quay vòng có thể giống như một ngày (chạy thử thường xảy ra hàng đêm), giả sử lỗi không bị lỗi bởi một lỗi khác; cộng với nhiều khả năng sẽ có nhiều lỗi được giới thiệu do mã khác được viết so với mã lỗi ban đầu; cộng với bất kỳ thiết kế lại nào sẽ tác động đến nhiều đoạn mã hơn. Ngoài ra, để nhiều lỗi hơn thông qua có nghĩa là phải thực hiện nhiều lần chạy thử trước khi thử nghiệm tích hợp có thể được hoàn thành. Kiểm tra đơn vị kém thường là trung tâm của lâu dài, khó khăn, tốn kémkiểm tra chu kỳ tích hợp. Bỏ qua thử nghiệm đơn vị có thể giảm một nửa thời gian phát triển, nhưng thử nghiệm sẽ mất ít nhất 3 đến 4 lần, toàn bộ dự án sẽ tăng gấp đôi thời gian và bạn vẫn sẽ có chất lượng thấp hơn so với khi bạn thử nghiệm IME.

Kiểm thử tích hợp thường là kiểm thử thực tế sớm nhất có thể tìm thấy các lỗi tích hợp (mặc dù các quy trình xem xét có thể tìm thấy một số lỗi trước khi phần mềm được viết hoặc trước khi mã đi kiểm tra). Bạn muốn tìm những lỗi đó trước khi bắt đầu hiển thị phần mềm cho người dùng hoặc phát hành, vì việc sửa lỗi vào phút cuối (hoặc sửa lỗi nóng!) Rất tốn kém. Bạn không thể tìm thấy những lỗi đó sớm hơn, khi chúng sẽ rẻ hơn để sửa, bởi vì bạn cần nhiều thành phần làm việc để tích hợp (theo định nghĩa). Kiểm thử tích hợp bị chậm lại khi các lỗi không liên quan đến các phần tương tác (như lỗi chính tả nhỏ) cần được giải quyết trước khi thử nghiệm thú vị hơn thậm chí có thể bắt đầu.

Kiểm tra chấp nhận của người dùng đảm bảo rằng phần mềm thực hiện những gì khách hàng muốn (mặc dù khách hàng hy vọng đã tham gia toàn bộ thời gian, để giảm rủi ro tìm thấy khoảng cách lớn giữa kỳ vọng và phần mềm thực tế ngay khi kết thúc dự án - RẤT tốn kém !). Vào thời điểm bạn đến giai đoạn thử nghiệm này, bạn thực sự nên tin rằng hầu hết các lỗi trong sản phẩm của bạn, so với thông số kỹ thuật ít nhất, đã được tìm thấy. Kiểm tra chấp nhận của người dùng liên quan nhiều hơn đến việc đảm bảo sản phẩm phù hợp với nhu cầu của khách hàng hơn là đảm bảo không có lỗi so với thông số kỹ thuật.

Nếu tôi chỉ tự động hóa một loại thử nghiệm, thì đó sẽ là thử nghiệm đơn vị. Kiểm tra tích hợp có thể được thực hiện thủ công và được thực hiện theo cách đó bởi nhiều công ty lớn trong nhiều năm. Mất nhiều thời gian hơn để thực hiện công việc thủ công có thể được thực hiện bởi máy tính nhiều lần và tốn kém hơn nhiều đối với hầu hết các dự án, chưa kể nhàm chán và dễ bị lỗi, nhưng có thể được thực hiện. Các thử nghiệm chấp nhận của người dùng thường là thủ công, vì người dùng thường không biết cách tự động hóa các thử nghiệm của họ trong khi vẫn kiểm tra những gì họ quan tâm. Kiểm tra đơn vị PHẢI được tự động. Bạn cần có thể chạy tất cả các bài kiểm tra đơn vị trong vòng vài giây theo yêu cầu thường xuyên cứ sau vài phút. Con người thậm chí không thể đến gần với các bài kiểm tra thủ công. Chưa kể rằng các bài kiểm tra đơn vị nằm trong mã và không thể được thực thi mà không gọi chúng thông qua mã, tức là tự động hóa chúng.

Một điều cần lưu ý là đây là một diễn đàn chủ yếu dành cho các nhà phát triển, không phải người thử nghiệm. Kiểm thử tích hợp chủ yếu được thực hiện bởi người kiểm tra. Kiểm thử đơn vị được thực hiện bởi các nhà phát triển. Đương nhiên, các nhà phát triển nói nhiều về thử nghiệm đơn vị hơn các loại thử nghiệm khác. Điều này không có nghĩa là họ không nghĩ rằng thử nghiệm khác là quan trọng. Điều đó chỉ có nghĩa là họ không thực sự làm điều đó (hoặc làm điều đó ít thường xuyên hơn).

Tôi cảm thấy như các bài kiểm tra chấp nhận là vua trong kịch bản này.

Nếu một cam kết phá vỡ các bài kiểm tra chấp nhận, nó cần phải được sắp xếp.

Kiểm tra chấp nhận cho bạn biết phần mềm của bạn ở đâu, kiểm tra đơn vị thì không.

Do đó kiểm tra đơn vị có thể cung cấp một cảm giác an toàn rất sai.

Câu hỏi không phải là những gì quan trọng hơn, vì những gì có thể được tự động hóa và chạy nhanh.

Các thử nghiệm đơn vị cho thấy liệu một thành phần nhỏ có phù hợp với mục đích theo một cách cụ thể hay không, và thường nhỏ và nhanh để chạy. Nhỏ, chúng thường dễ dàng tự động hóa.

Kiểm tra tích hợp cho thấy các thành phần làm việc cùng nhau. Chúng thường lớn hơn rất nhiều và có thể không dễ tự động hóa. Họ có thể mất nhiều thời gian hơn để chạy. Có giá trị trong việc có thể chạy chúng tự động, nhưng đó là một nhiệm vụ lớn hơn và chúng sẽ không được chạy thường xuyên.

Các thử nghiệm chấp nhận cho thấy một dự án có được chấp nhận hay không. Điều này thường không thể tự động hóa hoàn toàn (mặc dù các kiểm tra tự động có thể đóng một phần), vì thông thường không thể đưa ra các yêu cầu chính xác và đầy đủ trong một vấn đề chính thức, ít phức tạp hơn chính mã nguồn. Kiểm tra chấp nhận thường bao gồm người dùng tiềm năng thực hiện mọi việc với hệ thống và quan sát rằng kết quả là thỏa đáng ở tất cả các khía cạnh, thường là một phần chủ quan. Vì thử nghiệm chấp nhận thường được chạy một lần (các khách hàng khác nhau thường muốn thực hiện các thử nghiệm chấp nhận riêng của họ) nên thực sự không đáng để tự động hóa.