Kiểm tra giao diện là gì? Các loại & ví dụ

Kiểm tra giao diện là gì?

Kiểm tra giao diện Nó được định nghĩa là một loại kiểm thử phần mềm nhằm xác minh xem quá trình giao tiếp giữa hai hệ thống phần mềm khác nhau có được thực hiện chính xác hay không.

Một kết nối tích hợp hai thành phần được gọi là giao diện. Trong thế giới máy tính, giao diện này có thể là bất cứ thứ gì, chẳng hạn như API, dịch vụ web, v.v. Việc kiểm thử các dịch vụ kết nối hoặc giao diện này được gọi là kiểm thử giao diện.

Giao diện thực chất là phần mềm bao gồm các tập hợp lệnh, thông báo và các thuộc tính khác cho phép giao tiếp giữa thiết bị và người dùng.

Điểm quan trọng là giao diện có một nhược điểm.tract: một định dạng yêu cầu đã được thống nhất, một định dạng phản hồi đã được thống nhất, một tập hợp mã lỗi đã được thống nhất và một thời gian chờ đã được thống nhất. Các bài tập kiểm thử giao diện có thểtracLưu lượng truy cập đến từ cả hai phía, vì vậy một thay đổi do một nhóm thực hiện sẽ không âm thầm gây ảnh hưởng đến nhóm kia. Bởi vì hầu hết lưu lượng truy cập này không bao giờ đến được màn hình, nên các lỗi mà nó tìm thấy đều không thể nhìn thấy được. kiểm tra hộp đen Được thực hiện hoàn toàn thông qua giao diện người dùng.

Cách thực hiện Kiểm tra giao diện

Kiểm tra giao diện bao gồm kiểm tra hai phân đoạn chính:

1. Giao diện máy chủ web và máy chủ ứng dụng
2. Giao diện máy chủ ứng dụng và máy chủ cơ sở dữ liệu.

Đối với các tình huống nêu trên, việc kiểm tra giao diện được thực hiện để

• Kiểm tra máy chủ có được thực thi đúng hay không
• Lỗi được xử lý đúng cách hoặc trả về thông báo lỗi cho bất kỳ truy vấn nào do ứng dụng thực hiện
• Kiểm tra kết quả khi kết nối với máy chủ web được đặt lại giữa chừng

Sơ đồ bên dưới thể hiện hai phân đoạn đó như một chuỗi duy nhất, trong đó trình duyệt giao tiếp với máy chủ web, máy chủ web giao tiếp với máy chủ ứng dụng, và máy chủ ứng dụng giao tiếp với máy chủ cơ sở dữ liệu.

Trên thực tế, người kiểm thử sẽ thực hiện quy trình từng bước một trong chuỗi đó. Mỗi bước được thực hiện với một yêu cầu hợp lệ trước, sau đó với một yêu cầu không hợp lệ, rồi với việc cố tình để đầu cuối không khả dụng, sao cho cả đường dẫn thành công và đường dẫn thất bại đều được ghi lại trên cùng một máy. trường hợp thử nghiệm.

Ví dụ về kiểm tra giao diện

Giả sử đối với bất kỳ ứng dụng xyz nào, giao diện có dạng như sau: XML tệp tin làm đầu vào và cung cấp JSON Tệp tin được xuất ra dưới dạng file. Để kiểm tra giao diện của ứng dụng này, tất cả những gì cần là thông số kỹ thuật của định dạng file XML và định dạng file JSON.

Với sự hỗ trợ của các thông số kỹ thuật này, chúng ta có thể tạo ra các tệp XML đầu vào mẫu và đưa vào giao diện. Sau đó, việc xác thực tệp đầu vào (XML) và tệp đầu ra (JSON) so với yêu cầu được gọi là kiểm thử giao diện.

Hãy chú ý những gì ví dụ này không cần: không cần màn hình, không cần xây dựng giao diện người dùng, và không cần biết mã bên trong giao diện. Chỉ cần hai đặc tả định dạng là đủ để viết các bài kiểm tra, đó là lý do tại sao việc kiểm thử giao diện có thể bắt đầu rất lâu trước khi giao diện người dùng tồn tại.

Tại sao phải kiểm tra giao diện

Kiểm tra giao diện được thực hiện

• Để đảm bảo rằng người dùng cuối hoặc khách hàng không gặp phải bất kỳ vấn đề nào khi sử dụng một sản phẩm phần mềm cụ thể
• Để xác định khu vực ứng dụng nào thường được người dùng cuối truy cập và kiểm tra tính thân thiện với người dùng của nó.
• Để xác minh các yêu cầu bảo mật trong khi truyền thông lan truyền giữa các hệ thống
• Để kiểm tra xem giải pháp có khả năng xử lý lỗi mạng giữa máy chủ ứng dụng và trang web hay không

Ngoài ra còn có yếu tố chi phí. Việc sửa lỗi định dạng yêu cầu sẽ rẻ khi hai hệ thống vẫn đang được kết nối với nhau, nhưng sẽ tốn kém khi hệ thống phía sau đã lưu trữ dữ liệu bị lỗi.

Các loại thử nghiệm giao diện

Trong quá trình Kiểm thử giao diện, nhiều loại thử nghiệm khác nhau được thực hiện trên giao diện có thể bao gồm

• Quy trình làm việc: Nó đảm bảo rằng công cụ giao diện xử lý quy trình làm việc tiêu chuẩn của bạn như mong đợi.
• Các trường hợp ngoại lệ - giá trị không mong đợi: Điều này được xem xét khi kiểm tra bao gồm ngày, tháng và thứ được đảo ngược.
• Kiểm tra hiệu năng, tải và mạng: Giao diện có lưu lượng truy cập cao có thể yêu cầu nhiều hơn. Kiểm tra Tải hơn giao diện có dung lượng thấp, tùy thuộc vào công cụ giao diện và cơ sở hạ tầng kết nối
• Các hệ thống riêng lẻ: Điều này bao gồm việc kiểm tra từng hệ thống riêng lẻ. Ví dụ, hệ thống thanh toán và hệ thống quản lý hàng tồn kho cho cửa hàng bán lẻ phải có thể hoạt động riêng biệt.

Mục đầu tiên khá gần với kiểm thử quy trình làm việc để tái sử dụng các kịch bản của nó, và mục cuối cùng trùng lặp với kiểm thử mô-đunVì một hệ thống tự hỏng sẽ lại hỏng một lần nữa khi được kết nối.

Chiến lược kiểm tra giao diện

Chiến lược kiểm thử giao diện là một phương pháp được sử dụng để kiểm thử các giao diện bằng các bài kiểm thử chung bất kể cách triển khai. Chúng ta có thể sử dụng abstracXây dựng các trường hợp kiểm thử và tạo ra các thể hiện cụ thể của Trường hợp Kiểm thử cho mỗi cách triển khai chiến lược kiểm thử giao diện. Cơ sở/tuyệt đốitracCác trường hợp kiểm thử t thực hiện các bài kiểm thử trung lập về mặt triển khai, trong khi các bài kiểm thử cụ thể đảm nhiệm việc khởi tạo các đối tượng cần kiểm thử và thực hiện các bài kiểm thử đặc thù cho từng triển khai.

Lợi ích của cấu trúc đó là khả năng tái sử dụng. Khi một phiên bản triển khai thứ ba của cùng một giao diện xuất hiện, thì khả năng tái sử dụng sẽ giảm đi.tracBộ mã lệnh chạy mà không có thay đổi gì, và chỉ cần viết mã khởi tạo. Ý tưởng tương tự được áp dụng ở quy mô lớn hơn trong kiểm tra thành phần, nơi có sự đồng thuậntracBộ kiểm thử t được chạy trên mọi thành phần tuyên bố đáp ứng được nó.

Công cụ kiểm thử giao diện

Vì giao diện không có màn hình, công cụ phải trực tiếp xây dựng các yêu cầu và xác nhận dựa trên phản hồi thô. Các nhóm thường kết hợp ba loại công cụ.

• Các ứng dụng khách API và trình tạo yêu cầu: Các công cụ như Postman, SoapUIInsomnia và Hoppscotch gửi các lệnh gọi REST, SOAP hoặc GraphQL, lưu trữ chúng dưới dạng các tập hợp có thể tái sử dụng và xác nhận dựa trên mã trạng thái, tiêu đề và nội dung phản hồi.
• Code- thư viện kiểm thử cấp độ: Các thư viện chạy bên trong bộ kiểm thử hiện có cho phép kiểm tra giao diện tồn tại song song với các bài kiểm thử đơn vị và được thực thi trên mỗi bản dựng, giúp chúng không bị lỗi thời.
• Công cụ tải và giao thức: Một công cụ như JMeter điều khiển cùng một giao diện ở mức âm lượng lớn, đó là điều biến một bài kiểm tra chức năng thành... kiểm tra năng suất của kết nối.
• Ảo hóa dịch vụ và mô phỏng: Một đầu nối tạm thời thay thế cho đầu kia cho phép kiểm tra một phía trong khi phía còn lại không hoạt động, chưa hoàn thiện hoặc quá tốn kém để gọi đi gọi lại.

Việc lựa chọn ít quan trọng hơn phạm vi bao phủ. Bất kể chọn ứng dụng khách nào, tập hợp các yêu cầu phải được lưu trữ trong hệ thống kiểm soát phiên bản cùng với mã nguồn, để thay đổi giao diện và thay đổi kiểm thử của nó được ghi nhận trong cùng một commit. Chi tiết về phạm trù rộng hơn được đề cập trong phần tiếp theo. Thử nghiệm API.

Danh sách kiểm tra và các phương pháp thực hành tốt nhất về kiểm thử giao diện

Một danh sách kiểm tra ngắn gọn giúp đảm bảo tính nhất quán về phạm vi bao phủ giao diện giữa các phiên bản. Hãy thực hiện kiểm tra cho từng kết nối riêng lẻ thay vì cho toàn bộ ứng dụng.

• vớitracĐầu tiên: Hãy xác nhận rằng lược đồ yêu cầu và phản hồi khớp với đặc tả đã công bố, từng trường một, bao gồm cả kiểu dữ liệu và các trường tùy chọn.
• Giá trị biên: Gửi các tải trọng trống, các trường có độ dài tối đa, các bộ ký tự không mong muốn và định dạng ngày tháng đảo ngược.
• Đường dẫn lỗi: Hãy đảm bảo rằng mọi lỗi đều trả về mã và thông báo có ý nghĩa thay vì chỉ là một chuỗi lệnh. tracmột thành công thầm lặng.
• Thời gian chờ và thử lại: Ngắt kết nối giữa chừng yêu cầu và xác nhận người gọi có thể thử lại một cách an toàn mà không làm trùng lặp giao dịch.
• An ninh: Kiểm tra xác thực, ủy quyền và mã hóa trên liên kết, và xác nhận rằng các thông báo lỗi không làm lộ thông tin nội bộ.
• Tính nhất quán của dữ liệu: Đọc lại bản ghi từ phía bên kia và xác nhận rằng không có gì bị cắt xén, mã hóa lại hoặc sắp xếp lại trong quá trình truyền tải.
• Khối lượng: Lặp lại cuộc gọi có lưu lượng truy cập cao nhất dưới tải đồng thời và theo dõi tình trạng cạn kiệt nhóm kết nối.

Ba phương pháp sau giúp cho danh sách kiểm tra đó có thể lặp lại. Thứ nhất, tự động hóa bộ kiểm thử và chạy nó trên mọi bản dựng, vì giao diện thay đổi âm thầm hơn so với màn hình. Thứ hai, ghi lại toàn bộ yêu cầu và phản hồi cho mỗi lỗi, vì lỗi giao diện hầu như không thể tái hiện từ ảnh chụp màn hình. Thứ ba, giữ cho bộ kiểm thử độc lập với dữ liệu kiểm thử được tạo bởi các bộ kiểm thử khác, để lỗi chỉ ra giao diện chứ không phải do thiếu bản ghi.

Những bước kiểm tra này nằm trong khuôn khổ kế hoạch tổng thể được mô tả trong... các loại kiểm thử phần mềmvà chúng hoạt động trước khi các kết nối tương tự được thực hiện từ đầu đến cuối trong quá trình Thử nghiệm hệ thống.

Kiểm tra giao diện và kiểm tra tích hợp

Hai thuật ngữ này có liên quan chứ không đối lập: kiểm thử giao diện là phần của công việc tích hợp tập trung vào chính kết nối. Bảng dưới đây nêu rõ trọng tâm của mỗi khía cạnh.

Bất kỳ ai mới làm quen với lĩnh vực rộng lớn này sẽ thấy các cấp độ xung quanh được mô tả trong Thử nghiệm hội nhập và nói chung kiểm thử phần mềm phần giới thiệu, trong khi thuật ngữ được sử dụng ở trên xuất phát từ tiêu chuẩn kỹ thuật phần mềm thực hành. Đối với các hệ thống hướng đến trình duyệt, các kết nối tương tự cuối cùng sẽ được sử dụng lại trong quá trình thực hành. kiểm tra ứng dụng web.

Câu Hỏi Thường Gặp