Cách thực hiện kiểm tra API bên ngoài (hộp đen)


14

Giả sử bạn đang sử dụng API từ nhà cung cấp, làm thế nào để đảm bảo API của họ hoạt động như mong đợi?

Mối quan tâm chính của tôi đôi khi là nhà cung cấp đã thay đổi mã của họ và phá vỡ API, chúng tôi muốn có một số loại phần mềm tự động để kiểm tra chúng liên tục. Làm thế nào để đối phó với điều này?


Tùy thuộc vào ngôn ngữ, có thể có các công cụ có thể trợ giúp (Tôi đang nghĩ Pex cho các thư viện / API C #).
Steven Evers

Câu trả lời:


10

Câu trả lời ngắn: bạn cần một bộ kiểm tra cho API của nhà cung cấp bên thứ ba - vì vậy bạn sẽ phải phát triển một bộ.

Đừng mong đợi bất cứ ai khác làm điều đó cho bạn và đừng mong đợi một "viên đạn ma thuật" để tự động tạo ra các bài kiểm tra phù hợp.

Một số điều bạn có thể thử thêm:

  • hỏi nhà cung cấp nếu họ cung cấp danh sách "phá vỡ thay đổi" cho mỗi bản phát hành mới
  • hỏi họ xem họ quan tâm đến khả năng tương thích API như thế nào / thông báo cho họ rằng đây là một tính năng quan trọng đối với bạn
  • kiểm tra xem API có cung cấp các móc kiểm tra cụ thể, đầu ra đăng nhập hoặc một cái gì đó tương tự cho các bộ phận không thể kiểm tra dễ dàng không
  • bọc các lệnh gọi API quan trọng bằng mã đăng nhập của riêng bạn, ghi đầu vào và đầu ra liên quan của API vào tệp nhật ký, điều này sẽ giúp gỡ lỗi mọi thứ dễ dàng hơn nếu có điều gì đó bất ngờ xảy ra
  • thêm các xác nhận vào các lệnh gọi API để kiểm tra trước và sau điều kiện, vì vậy nếu một bản phát hành mới của API xuất hiện hành vi không mong muốn trong ứng dụng của bạn, bạn sẽ được thông báo sớm bởi một thông báo lỗi

Nếu những điều này hoạt động hay không phụ thuộc vào ai là nhà cung cấp của bạn và loại API bạn có trong đầu. API tạo ra một số đầu ra có thể kiểm tra như các tệp dễ kiểm tra hơn API kiểm soát một số thiết bị vật lý nơi bạn phải quan sát hành vi của sự việc để quyết định liệu cuộc gọi API có thành công hay không.


Tôi hoàn toàn đồng ý, nhưng dường như với tôi, người hỏi không có kinh nghiệm với các đơn vị thử nghiệm và không biết kế hoạch làm việc với họ. Ý tôi là: tìm điểm quan trọng, viết đơn vị kiểm tra, chạy tất cả kiểm tra, gỡ lỗi, trong quá trình gỡ lỗi tìm điểm quan trọng mới, viết đơn vị mới, lặp lại 4 bước cuối cùng sau mỗi thay đổi API.
Gangnus

@Gangnus: IMHO OP không cho chúng tôi biết bất cứ điều gì về kinh nghiệm trước đây của anh ấy với thử nghiệm đơn vị. Nếu anh ta có vấn đề với điều đó, tôi chắc chắn anh ta biết hỏi một câu hỏi cụ thể hơn. Hơn nữa, chủ đề ở đây không phải là "kiểm tra đơn vị", mà là "kiểm tra tích hợp tự động". Những yêu cầu thường là một sơ đồ khác với, ví dụ, kiểm tra đơn vị theo kiểu TDD.
Đốc nâu

Vâng, anh ấy đã không nói điều đó. Nhưng nếu anh ta hỏi "làm thế nào để đảm bảo API của họ hoạt động như mong đợi" không đề cập đến các bài kiểm tra hợp nhất, "có vẻ như với tôi", rằng anh ta không biết họ. Đối với các thử nghiệm tích hợp tự động, anh ta không biết chúng thậm chí với xác suất cao hơn, anh ta chỉ đề cập đến "một số loại phần mềm tự động". Bạn đang chờ đợi từ những người có cùng kiến ​​thức như bạn, nhưng trong các chủ đề này, 99% lập trình viên (bao gồm cả tôi) biết ít hơn nhiều. và 90% xa rất xa.
Gangnus

0

Dựa trên phrasing của người đăng, nó không chỉ là thử nghiệm, IMO. Sau khi bạn viết bài kiểm tra đơn vị cho API và đảm bảo mọi thứ đều hoạt động như mong đợi, bạn cần theo dõi API của bên thứ ba để bạn nắm bắt được các vấn đề trước khi người dùng thực hiện. Đó là rủi ro thực sự với API của bên thứ ba - đó không phải là mã của bạn và bạn không kiểm soát được bao nhiêu thử nghiệm đã được thực hiện trên API hoặc khi / nếu nó thay đổi.

(Tuyên bố miễn trừ trách nhiệm: tên sản phẩm được sử dụng tại đây) Nếu bạn sử dụng SoapUI để viết các bài kiểm tra API của mình, các bài kiểm tra đó có thể được sử dụng lại trong AlertSite như một trình giám sát hoạt động để đảm bảo API tiếp tục hoạt động như mong đợi. Nếu thử nghiệm thất bại, bạn có thể được cảnh báo trước khi người dùng gọi cho bạn và phàn nàn rằng ứng dụng của bạn không hoạt động.


0

Thực hiện các bài kiểm tra học tập cho lĩnh vực bạn quan tâm (các tính năng mà bạn dự định sử dụng). Các bài kiểm tra học tập là các bài kiểm tra tích hợp được viết bởi nhà phát triển so với hợp đồng công khai của API. Các bài kiểm tra không nên được viết dựa trên các chi tiết triển khai nội bộ ngay cả khi mã nguồn cho API có sẵn. Loại bài kiểm tra học tập này phục vụ hai mục đích -

  1. Nó cải thiện đáng kể sự hiểu biết của bạn về API của bên thứ ba.
  2. Các thử nghiệm giúp xác minh xem phiên bản mới được yêu cầu có thực sự tương thích ngược hay không.

0

Có 2 cách tiếp cận cho vấn đề này ...

ứng dụng của bạn đang được sản xuất với lưu lượng người dùng thực:

nếu bạn có một ứng dụng trong sản xuất có lưu lượng truy cập trực tiếp và phụ thuộc vào api bên ngoài, bạn không có lựa chọn nào khác ngoài việc theo dõi chặt chẽ và có ngưỡng tốt để biết càng nhanh càng tốt khi api bên ngoài thay đổi mà không cần thông báo.

bạn nên luôn luôn tính đến rằng:

  • thay đổi theo thời gian
  • nhà cung cấp api có thể có lỗi
  • bộ dụng cụ thử nghiệm của nhà cung cấp api có thể có lỗi hoặc không bao gồm đầy đủ tất cả các chức năng của api sản xuất

ứng dụng của bạn là bản cài đặt và đã có phiên bản / bản phát hành theo kế hoạch:

trong trường hợp này, bạn có một giai đoạn ân hạn để thất bại ... người dùng trực tiếp không bị ảnh hưởng ngay lập tức với các thay đổi phá vỡ api bên ngoài.

Theo tôi đây là một nhiệm vụ dễ dàng hơn. viết một bài kiểm tra (kiểm tra toàn bộ từ đầu đến cuối) để thực hiện các giao dịch / http / yêu cầu thực sự cho ứng dụng của bạn để gọi api bên ngoài và kiểm tra xem không có lỗi nào. không có bộ dụng cụ kiểm tra không giả giao dịch thực sự.

sau khi hoàn thành nhiệm vụ này, bạn có thể chọn chạy nó cứ sau 24 giờ, 1 phút, v.v ...

thực hành tốt:

  • tự động hóa mọi thứ
  • có một người bạn có thể nhanh chóng liên hệ từ nhà cung cấp api bên ngoài
  • đừng mù quáng tin tưởng nhà cung cấp kiểm tra mọi thứ
  • thất bại nhanh chóng - nếu dịch vụ của bạn phụ thuộc nhiều vào api bên ngoài, đừng để dịch vụ của bạn gặp sự cố. thất bại nhanh và trả lại thông báo lỗi thích hợp

công cụ:

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.