Một bài kiểm tra tích hợp chính xác là gì?

Bạn bè của tôi và tôi đã đấu tranh để phân loại chính xác bài kiểm tra tích hợp là gì.

Bây giờ, trên đường về nhà, tôi mới nhận ra rằng, mỗi khi tôi cố gắng đưa ra một ví dụ thực tế về một bài kiểm tra tích hợp, thì hóa ra đó là một bài kiểm tra chấp nhận, tức là. một cái gì đó mà một người kinh doanh sẽ nói to mà chỉ ra những gì hệ thống sẽ được cung cấp.

Tôi đã kiểm tra tài liệu Ruby on Rails để phân loại các loại thử nghiệm này và giờ nó đã hoàn toàn ném tôi.

Bạn có thể cho tôi một mô tả học thuật ngắn về một bài kiểm tra tích hợp với một ví dụ thực tế không?

Hiện tại tôi thích câu nói này: "Không quan trọng bạn gọi nó là gì, nhưng nó làm gì" được thực hiện bởi Gojko Adzic trong bài viết này .

Bạn thực sự cần phải xác định với những người nói về các bài kiểm tra những gì bạn dự định kiểm tra.

Có rất nhiều người có quan điểm khác nhau, tùy thuộc vào vai trò của họ.

Đối với người thử nghiệm, một phương pháp thử nghiệm được chấp nhận chung ở Hà Lan là TMap . TMap làm cho sự khác biệt sau đây.

• kiểm tra đơn vị
• kiểm tra tích hợp đơn vị
• kiểm tra hệ thống
• kiểm tra tích hợp hệ thống
• kiểm tra chấp nhận (tất cả các loại / cấp độ)
• kiểm tra chấp nhận chức năng
• kiểm tra sự chấp nhận của người dùng
• kiểm tra nghiệm thu

Họ có loại xét nghiệm cụ thể hơn có thể được thực hiện trong các thử nghiệm được đề cập ở trên. Nhìn vào tài liệu từ này để biết tổng quan.

Wikipedia cũng có một cái nhìn tổng quan tốt đẹp .

Các cuốn sách lập trình viên thực dụng nói:

• một bài kiểm tra đơn vị là một bài kiểm tra thực hiện một mô-đun
• kiểm tra tích hợp cho thấy các bộ phận chính của một hệ thống hoạt động tốt với nhau

Nhìn vào các nguồn khác nhau này và đưa vào một số kinh nghiệm và ý kiến ​​của riêng tôi, tôi sẽ bắt đầu bằng cách phân biệt theo ba loại

• ai làm xét nghiệm nói chung
• những gì được thử nghiệm

• mục tiêu của bài kiểm tra là gì

  • Kiểm thử đơn vị : kiểm tra logic trong các lớp bởi các lập trình viên để hiển thị độ chính xác của mã. Chúng phải nhanh và không phụ thuộc vào các phần khác của hệ thống mà bạn không có ý định kiểm tra
  • Kiểm tra chấp nhận chức năng : kịch bản trường hợp sử dụng thử nghiệm trên tập dữ liệu giới hạn (được tạo đặc biệt) được thực hiện bởi bộ phận kiểm tra để cho thấy rằng mọi kịch bản được chỉ định đều hoạt động như được chỉ định.
  • Kiểm tra chấp nhận của người dùng : kiểm tra kịch bản ca sử dụng trong sản xuất như dữ liệu được thực hiện bởi đại diện của người dùng để khiến họ chính thức chấp nhận ứng dụng
  • Kiểm thử tích hợp : Kiểm tra đường dẫn liên lạc giữa các phần khác nhau của mô-đun được thực hiện bởi bộ phận kiểm tra hoặc bởi các nhà phát triển để cho thấy rằng tất cả các mô-đun hoạt động chính xác với nhau.

Danh sách của tôi ở trên chỉ là một sự khởi đầu và một gợi ý nhưng tôi thực sự nghĩ rằng: "Không quan trọng bạn gọi nó là gì, nhưng nó làm gì"

Hi vọng điêu nay co ich.

26-10-2016 Chỉnh sửa: Gần đây, một phần giới thiệu rất hay đã được đặt trong các bài kiểm tra Đơn vị YouTube so với các bài kiểm tra Tích hợp - MPJ's Musings - FunFunFunction # 55

kiểm tra tích hợp, hóa ra là một bài kiểm tra chấp nhận

Hiển nhiên, rõ ràng.

Hai cái này gần như giống nhau. Nhưng có một số kích thước hơi khác với định nghĩa thử nghiệm.

Tích hợp == toàn bộ hệ thống.

Chấp nhận == toàn bộ hệ thống.

Sự khác biệt duy nhất - và điều này là tinh tế - là định nghĩa của các trường hợp thử nghiệm.

Tích hợp == trường hợp kiểm tra để kiểm tra độ sâu và mức độ tích hợp. Nó hoạt động cho tất cả các trường hợp cạnh và trường hợp góc? Các trường hợp thử nghiệm có xu hướng kỹ thuật, được viết bởi các nhà thiết kế và lập trình viên.

Chấp nhận == trường hợp kiểm tra để thực hiện chỉ 80% tập trung vào người dùng cuối. Không phải tất cả các trường hợp cạnh và góc. Các trường hợp thử nghiệm có xu hướng phi kỹ thuật, được viết bởi người dùng cuối.

Cá nhân tôi thích nghĩ về một thử nghiệm tích hợp như một thử nghiệm tính năng khi mọi thành phần của hệ thống là có thật , không có đối tượng giả.

Một kho lưu trữ thực, một cơ sở dữ liệu thực, một giao diện người dùng thực. Bạn kiểm tra chức năng cụ thể khi hệ thống được lắp ráp hoàn chỉnh và giống như được cho là khi được triển khai.

Theo kinh nghiệm nhỏ bé của tôi (tôi thừa nhận), tôi hiểu rằng việc tích hợp từ thực sự có thể tạo ra sự hiểu lầm: thực sự, rất khó để tìm thấy một cái gì đó hoàn toàn bị cô lập trong một hệ thống, một số yếu tố sẽ cần một sự tích hợp chắc chắn.

Vì vậy, tôi đã quen với việc phân biệt như sau:

• Tôi sử dụng kiểm tra đơn vị để xác định, ghi lại và nhấn mạnh tất cả các hành vi mà lớp tôi đang kiểm tra có trách nhiệm thực hiện.
• Tôi đang thực hiện các bài kiểm tra tích hợp bất cứ khi nào tôi có một thành phần (có thể nhiều hơn một) trong hệ thống của mình đang có một số cuộc trò chuyện với một hệ thống " bên ngoài " khác. (tiếp tục bên dưới ...)
• Tôi thực hiện một thử nghiệm chấp nhận để xác định, ghi lại và nhấn mạnh một quy trình công việc nhất định mà hệ thống mong đợi.

Trong định nghĩa kiểm thử tích hợp, bên ngoài tôi có nghĩa là hệ thống nằm ngoài phạm vi phát triển của tôi : Tôi không thể thay đổi ngay lập tức cách họ hành xử, vì bất kỳ lý do nào. Nó có thể là một thư viện, một thành phần của hệ thống không thể thay đổi (nghĩa là nó được chia sẻ với các dự án khác trong công ty), một dbms, v.v. sẽ hoạt động trong: một hệ thống bên ngoài phải được khởi tạo và được đặt ở trạng thái nhất định; dữ liệu thực tế phải được đăng ký trong db; Vân vân.

Thay vào đó, khi tôi đang thực hiện kiểm tra chấp nhận Tôi giả mạo : Tôi đang làm việc trên một cái gì đó khác biệt, tôi đang làm việc trên các thông số kỹ thuật của hệ thống, chứ không phải khả năng cộng tác với các thực thể bên ngoài.

Đây thực sự là một góc nhìn hẹp hơn so với những gì KeesDijk đã mô tả trước đó, tuy nhiên tôi cho rằng các dự án tôi đã làm cho đến nay đủ nhỏ để cho tôi mức độ đơn giản hóa này.

Một thử nghiệm tích hợp xác minh rằng các thành phần của một hệ thống phức tạp (ví dụ: phần mềm, máy bay, nhà máy điện) đang hoạt động cùng nhau như thiết kế.

Hãy tưởng tượng chúng ta đang nói về một chiếc máy bay (với phần mềm thì nó trừu tượng hơn và khó tạo ra sự khác biệt). Các bài kiểm tra tích hợp bao gồm, xác minh:

• tương tác chính xác giữa một số thành phần. Ví dụ: khi nhấn vào nút khởi động, động cơ khởi động và cánh quạt đạt tốc độ quay dự kiến ​​(máy bay vẫn ở trên mặt đất)
• tương tác chính xác với các thành phần bên ngoài. Ví dụ: kiểm tra xem radio nhúng có thể liên lạc với radio cố định (máy bay vẫn ở trên mặt đất)
• tương tác chính xác giữa tất cả các thành phần liên quan, để toàn bộ hệ thống hoạt động như mong đợi. Ví dụ: một phi công thử nghiệm và kỹ sư khởi động máy bay, và bay cùng nó (tất cả họ đều mặc dù ...).

Các thử nghiệm tích hợp giải quyết một vấn đề kỹ thuật , cụ thể là hệ thống hoạt động mặc dù phân của nó thành các thành phần. Trong phần mềm, các thành phần có thể là trường hợp sử dụng, mô-đun, chức năng, giao diện, thư viện, v.v ...

Các nghiệm thu xác nhận rằng sản phẩm là phù hợp với mục đích. Họ về nguyên tắc được thực hiện bởi khách hàng. Lấy sự tương tự máy bay, họ bao gồm xác minh rằng:

• kịch bản kinh doanh dự kiến ​​dẫn đến kết quả mong đợi trong một tình huống gần như có thật. Ví dụ: diễn tập lên máy bay với hành khách thử nghiệm để kiểm tra xem nhân viên có thể giám sát việc lên máy bay như mong đợi với quy trình vận hành hay không. Một số kịch bản có thể đơn giản đến mức trông giống như thử nghiệm đơn vị, nhưng chúng được thực hiện bởi người dùng (ví dụ: thử phích cắm điện với thiết bị của công ty).
• hệ thống hoạt động trong một tình huống kinh doanh gần như thực tế. Ví dụ: thực hiện chuyến bay thử nghiệm trống giữa hai điểm đến thực tế, với các phi công mới được đào tạo từ hãng hàng không để kiểm tra mức tiêu thụ nhiên liệu như đã hứa.

Các bài kiểm tra chấp nhận giải quyết nhiều hơn một vấn đề trách nhiệm . Trong mối quan hệ khách hàng / nhà cung cấp, đó có thể là trách nhiệm theo hợp đồng (tuân thủ tất cả các yêu cầu). Nhưng trong mọi trường hợp, tổ chức sử dụng cũng phải có trách nhiệm đảm bảo rằng nhiệm vụ của họ có thể được thực hiện với hệ thống và ngăn chặn một cách thận trọng bất kỳ vấn đề không lường trước nào (ví dụ như tập đoàn đường sắt này đã phát hiện ra trong các bài kiểm tra chấp nhận rằng họ phải rút ngắn một số thông qua vì các toa xe mới quá lớn 5 cm - không đùa!).

Kết luận: Các thử nghiệm tích hợp và chấp nhận là chồng chéo. Cả hai đều có ý định cho thấy rằng toàn bộ hệ thống hoạt động. Tuy nhiên, "toàn bộ" có thể lớn hơn đối với khách hàng (vì hệ thống có thể là một phần của hệ thống tổ chức lớn hơn) và nhiều kỹ thuật hơn cho nhà tích hợp hệ thống:

Kiểm thử tích hợp không là gì ngoài việc kiểm tra kết nối và tính chính xác của luồng dữ liệu giữa hai mô-đun nữa.

Ví dụ: Khi chúng tôi soạn thư (một mô-đun) và gửi nó đến một số ID người dùng hợp lệ (mô-đun thứ hai), kiểm tra tích hợp là để kiểm tra xem thư đã gửi có trong các mục đã gửi hay không.

Một định nghĩa thực tế của kiểm thử tích hợp là: Bất kỳ thử nghiệm nào yêu cầu tương tác với một thứ gì đó ngoài quy trình.

Ví dụ:

• Hệ thống tập tin
• Mạng
• Một cơ sở dữ liệu
• API bên ngoài

Tồn tại một hợp đồng sắp xếp giữa quá trình của bạn và thế giới bên ngoài, và xác minh tối thiểu rằng hợp đồng đó sẽ là mục tiêu của một bài kiểm tra tích hợp. tức là không nên làm gì hơn là xác minh hợp đồng. Nếu vậy thì bạn đang di chuyển về phía không gian hệ thống / đầu cuối.

Các thử nghiệm đơn vị có thể kiểm tra tất cả logic trong ranh giới quy trình của bạn và chúng có thể thực hiện điều đó một cách dễ dàng chính xác do thiếu phụ thuộc vào "thế giới bên ngoài" chậm / dễ vỡ / phức tạp.

Trong khi có các kiểm tra tích hợp thì định nghĩa này không bao gồm (do đó tại sao tôi gọi nó là định nghĩa thực tế ) Tôi nghĩ rằng chúng ít phổ biến / hữu ích hơn nhiều.

NB Nói đúng ra, vâng, định nghĩa này cũng sẽ bao gồm các bài kiểm tra hệ thống / đầu cuối. Trong triết lý của tôi, chúng là một dạng thử nghiệm tích hợp 'cực đoan', do đó tên của chúng nhấn mạnh đến một khía cạnh khác. Theo hướng khác, một bài kiểm tra đơn vị có thể được coi là một bài kiểm tra tích hợp các thành phần bằng 0, tức là tất cả các bài kiểm tra có thể được coi là nằm ở đâu đó trên phổ tích hợp, tích hợp giữa các thành phần 0-n :-)