Recommended
More Related Content
Similar to Seminar 062017 seminar
Similar to Seminar 062017 seminar (20)
Seminar 062017 seminar
- 2. Margarita 1.Trần Thị Thuỳ Dương 2.Vũ Thị Hiền 3.Ngô Thị Thu Hường 4.Đào Thị Hường 5.Nguyễn Thị Hoa 6.Nguyễn Thị Huệ 7.Nguyễn Thị Thanh Huyền
- 3. Nội dung chính 1. Giới thiệu về kiểm thử API 1. API là gì? 2. Tổng quan về kiểm thử API 3. Tại sao cần kiểm thử API 4. Chuẩn bị những gì để kiểm thử API 5. Một số kiểu bug cần chú ý 6. Kiểm thử API thủ công và tự động 7. Tool kiểm thử API 1. Kiểm thử tự động API bằng SoapUI 1. Giới thiệu SoapUI 2. Cách sử dụng SoapUI 3. So sánh SoapUI và PostMan 4. Demo autotest REST API bằng SoapUI
- 5. 1.1 API là gì? ○ API - Application Programming Interface: là cầu nối giữa client và server, cho phép giao tiếp và trao đổi dữ liệu giữa hai hệ thống phần mềm riêng biệt.
- 6. 1.2 Kiểm thử API là gì? ● Kiểm thử API là thử nghiệm mà trong đó bạn sử dụng phần mềm để gọi tới API, nhận kết quả đầu ra và ghi lại phản hồi của hệ thống. ● Không tập trung vào giao diện mà chủ yếu tập trung vào lớp business logic của phần mềm.
- 7. ○ Vẫn thực hiện test được, không cần phụ thuộc vào client, trong trường hợp client chưa phát triển xong. ○ Dễ dàng hơn trong việc tìm ra nguyên nhân lỗi phát sinh từ server hay client –> sửa lỗi sẽ nhanh hơn. ○ Trong trường hợp chỉ độc lập phát triển API mà không có client thì việc test API là cần thiết. 1.3 Tại sao kiểm thử API là quan trọng?
- 8. A. Thiết lập môi trường kiểm thử API B. Xác định phạm vi và yêu cầu kiểm thử C. Quyết định xem bạn muốn thử nghiệm API của mình như thế nào? D. Testcase API 1.4 Cần chuẩn bị những gì để bắt đầu kiểm thử API?
- 9. ○ Thiết lập môi trường kiểm thử API với tập hợp các tham số cần thiết của API. ○ Cấu hình cơ sở dữ liệu và máy chủ theo các yêu cầu của ứng dụng. ○ Thử thực hiện gọi API để đảm bảo không có lỗi gì trước khi bạn tiến hành kiểm thử. A. Thiết lập môi trường kiểm thử API
- 10. ○ Đặt các câu hỏi liên quan đến API để xác định phạm vi và yêu cầu kiểm thử. ○ Ví dụ: ◦ Những môi trường nào nên sử dụng API như thế nào? ◦ Độ ưu tiên trong kiểm thử API? ◦ Điều gì sẽ xảy ra trong những trường hợp bình thường, trường hợp bất thường ◦ API nào khác có thể tương tác với API này? ◦ ... B. Xác định phạm vi và yêu cầu kiểm thử
- 11. ○ Một số phương pháp kiểm thử API phổ biến: ◦ Functionality testing - Xác nhận API hoạt động chính xác theo đúng chức năng mà nó được tạo ra. ◦ Usability testing - Xác nhận API có thể sử dụng một cách dễ dàng ◦ Reliability testing - Xác nhận việc gọi API và trả kết quả hoạt động ổn định và nhất quán C. Quyết định xem bạn muốn thử nghiệm API của mình như thế nào?
- 12. ○ Một số phương pháp kiểm thử API phổ biến: ◦ Load testing - Xác nhận API hoạt động đúng với một lượng cuộc gọi lớn nhất định ◦ Security testing - Xác nhận API đã define những yêu cầu về bảo mật như authentication, permissions và access controls ◦ API documentation testing - Discovery testing: Xác nhận tài liệu hướng dẫn sử dụng của API là dễ sử dụng cho user C. Quyết định xem bạn muốn thử nghiệm API của mình như thế nào?
- 13. ○ Các trường hợp thử nghiệm về kiểm tra API dựa trên: ◦ Kiểm tra các giá trị trả về dựa trên điều kiện đầu vào. ◦ Xác minh nếu API không trả lại bất kỳ kết quả gì hoặc kết quả sai. ◦ Xác minh nếu API kích hoạt một số sự kiện khác hoặc gọi một API khác. ◦ Xác minh xem API đang cập nhật bất kỳ cấu trúc dữ liệu nào. D. Testcase API
- 14. ○ Vấn đề bảo mật ○ Các vấn đề về sự tin cậy. Khó khăn khi kết nối và nhận phản hồi từ API. ○ Vấn đề hiệu năng. API thời gian phản hồi rất cao. ○ Lỗi / cảnh báo không đúng cho người gọi ○ Xử lý sai số giá trị đối số hợp lệ ○ Dữ liệu phản hồi không được cấu trúc chính xác (JSON hoặc XML) 1.5 Một số kiểu bug cần chú ý khi kiểm thử API
- 15. 1.6 Kiểm thử thủ công hay Kiểm thử tự động? ○ Kiểm tra API là một trong những lĩnh vực mà kiểm thử tự động được đánh giá cao, đặc biệt là đối với DevOps (Development and Operations), vòng đời phát triển agile và continuous delivery. ○ Khi nào thực hiện kiểm thử tự động API?
- 16. 1.7 Một số tool kiểm thử API ○ SoapUI ○ Postman ○ Runscope ○ Eclipse SDK tool- Automated kiểm thử API ○ Curl ○ ...
- 17. 2. Giới thiệu SoapUI
- 18. 2.1 Giới thiệu SoapUI ○ SOAP UI là công cụ kiểm thử mã nguồn mở API. Giúp bạn dễ dàng thực hiện kiểm thử tự động chức năng, kiểm thử tải và kiểm thử bảo mật các Web API khác nhau.
- 19. 2.1 Giới thiệu SoapUI ○ Tạo bộ test suite, có thể chạy từng case hoặc tất cả các testcase ○ Có kết quả trả về pass fail của từng case ○ Thực hiện Functional Testing dễ dàng ○ Có thể thực hiện Test Generator, SQL Injection ○ Automation test với Groovy ○ Hỗ trợ assertion ○ Có thể dùng và kế thừa lại ○ Có thể import postman collection Tính năng đặc trưng
- 20. 2.1 Giới thiệu SoapUI ○ Functional testing ○ Load testing ○ Security testing Các loại test có thể sử dụng SoapUI
- 21. 2.2 Cách sử dụng SoapUI Download SoapUI free version: ○ http://sourceforge.net/projects/SoapUI/files/ hoặc ○ http://SoapUI.org/downloads/SoapUI/open- source.html ○ Chọn phiên bản cho hệ điều hành của bạn và tải về bộ cài SoapUI. Các bước cài đặt: ○ https://www.SoapUI.org/getting- started/installing-SoapUI.html Cài đặt SoapUI
- 22. B1: Add REST Project B2: Thiết lập resource, method, parameter cho request B3: Tạo Test Suite B4: Tạo Test Case B5: Tạo Properties B6: Tạo REST Request B7: Add Property Transfer/ hoặc Property Expansion B8: Add assertion Các bước cơ bản tạo một project thực hiện auto-test API
- 23. Cấu trúc một Project
- 24. ● Resource: Là những tài nguyên mà bên cung cấp service cung cấp cho. Trong cùng một Resource có thể sử dụng nhiều method khác nhau. ● End Point: địa chỉ của service Một số khái niệm cơ bản
- 25. Method: ● POST: thực hiện tạo mới đối tượng (create) ● GET: thực hiện lấy dữ liệu (read) ● DELETE : thực hiện xóa dữ liệu ● PUT: thực hiện update dữ liệu (update/replace) ● PATCH: thực hiện update dữ liệu (update/modify) ● HEAD: tương tự như GET nhưng không trả về response body Một số khái niệm cơ bản trong SOAPUI
- 26. ● Parameter: thông tin trường sẽ thực hiện test Ví dụ muốn test trường địa chỉ mail thì add tên trường mail chính xác đã được định nghĩa trong docs sử dụng API ● Properties: Nhập data test - các dữ liệu đầu vào mà tester cần sử dụng để truyền vào các parameter cho mỗi request thực hiện ● REST Request: Chọn request sẽ thực hiện (Đây chính là Request mà đã được add và setup ở bước 2) Một số khái niệm cơ bản trong SOAPUI
- 27. ● Properties Transfer: Chỉ định truyền dữ liệu Properties nào cho REST Request nào ● Assertion: Nhập trường muốn kiểm tra kết quả, và kết quả kỳ vọng. Nếu sau khi chạy request, kết quả trả về = kết quả kỳ vọng sẽ báo PASS. Ngược lại sẽ báo FAIL. Một số khái niệm cơ bản trong SOAPUI
- 28. ● Contains Assertion: Kiểm tra sự tồn tại của một chuỗi. ● Not contains Assertion: Kiểm tra sự không tồn tại của một chuỗi. ● JsonPath Match: Xác thực value của biểu thức JsonPath có đúng như mong muốn không ● JsonPath Existence Match: Xác minh value đặc biệt của JsonPath có tồn tại trong chuỗi Json hay không ● JsonPath Count Match: Xác minh số phần tử khớp với biểu thức JsonPath (nếu đánh giá mảng thì sẽ đếm số phần tử của mảng) có là giá trị mong muốn không ● ... Một số loại Assertions
- 29. 2.3 So sánh SoapUI với Postman ○ Cùng test API ○ Cùng bao gồm các chức năng: ◦ Cho phép gửi HTTP Request ◦ Cho phép thay đổi header của các request ◦ Cho phép post dữ liệu dưới dạng form (key- value), text, JSON ◦ Hiện kết quả trả về dạng text, image, XML, JSON Giống nhau
- 30. 2.3 So sánh SoapUI với Postman Khác nhau SoapUI Postman Thực hiện kiểm thử tự động cả SOAP API và REST API Chỉ kiểm thử tự động được REST API Giao diện phức tạp Giao diện đơn giản Gọi request chạy test đơn giản Phải viết cú pháp chạy request phức tạp Nội dung viết cho assertion đơn giản Cú pháp viết cho assertion phức tạp hơn Có thể thực hiện cả functional testing, security testing, load testing Thực hiện functional testing, security testing Có thể import collection từ postman sang -
- 31. 2.4 Demo autotest REST API bằng SOAP UI ○ Endpoint: http://krk-stg.framgia.vn/ ○ Resources: /api/v1/registration/member Test cases: Tạo test case đơn giản validate cho các trường hợp đăng ký tài khoản: ○ Đăng ký failed do username chứa ký tự số ○ Đăng ký failed do email đã tồn tại
Editor's Notes
- Nói đơn giản, API là cái cầu nối giữa client và server. Client ở đây có thể là máy tính, điện thoại sử dụng hệ điều hành khác nhau và được viết bằng những ngôn ngữ khác nhau. Tương tự, server back-end cũng được viết bằng các ngôn ngữ khác nhau. Để 2 thằng này có thể nói chuyện được với nhau chúng phải nói cùng 1 ngôn ngữ. Ngôn ngữ ấy chính là API.
- kiểm thử API là thử nghiệm mà trong đó bạn sử dụng phần mềm để gọi tới API, nhận kết quả đầu ra và ghi lại phản hồi của hệ thống. Không tập trung vào giao diện mà chủ yếu tập trung vào lớp business logic layer của phần mềm.
- Dưới đây là một số ví dụ về các bài kiểm tra bảo mật phổ biến mà API: API đưa ra giá trị của ứng dụng. Đó là làm cho điện thoại của chúng ta "thông minh" và đó là những gì hợp lý hóa business processes. Nếu bất kỳ API nào không hoạt động hiệu quả, nó sẽ không bao giờ được chấp nhận, bất kể đó là một API miễn phí hay API mở. Điều tồi tệ hơn, nếu một API bị phá vỡ vì lỗi không được phát hiện, nó không chỉ có thể phá vỡ một ứng dụng duy nhất mà còn là một chuỗi quy trình nghiệp vụ gắn liền với nó.
- Dưới đây là một số ví dụ về các bài kiểm tra bảo mật phổ biến mà API: API đưa ra giá trị của ứng dụng. Đó là làm cho điện thoại của chúng ta "thông minh" và đó là những gì hợp lý hóa business processes. Nếu bất kỳ API nào không hoạt động hiệu quả, nó sẽ không bao giờ được chấp nhận, bất kể đó là một API miễn phí hay API mở. Điều tồi tệ hơn, nếu một API bị phá vỡ vì lỗi không được phát hiện, nó không chỉ có thể phá vỡ một ứng dụng duy nhất mà còn là một chuỗi quy trình nghiệp vụ gắn liền với nó.
- Đối tượng mục tiêu là ai? Ai là người dùng API đến của bạn? Những môi trường nào nên sử dụng API như thế nào? Bạn đang thử nghiệm những khía cạnh nào? Bạn đang thử nghiệm những vấn đề gì? Độ ưu tiên trong kiểm thử API? Điều gì sẽ xảy ra trong những trường hợp bình thường? Điều gì có thể xảy ra trong những trường hợp bất thường? Xác định Pass/ Fail ? Dữ liệu đầu ra mong muốn? Chuỗi sự kiện là gì? API nào khác có thể tương tác với API này? Ai trong nhóm của bạn có trách nhiệm kiểm tra cái gì?
- Functionality testing - Kiểm tra chức năng : API hoạt độn. Usability testing - Kiểm tra khả năng sử dụng: API rất dễ sử dụng. Reliability testing - Thử nghiệm độ tin cậy: API có thể được kết nối liên tục và dẫn đến kết quả nhất quán. Load testing - Kiểm thử tải: API có thể xử lý một số lượng lớn các request. Creativity testing - Thử nghiệm sáng tạo: API có thể xử lý được sử dụng theo những cách khác nhau. Security testing - Kiểm tra bảo mật: API đã xác định yêu cầu bảo mật bao gồm xác thực, cho phép và điều khiển truy cập. API documentation testing - Kiểm thử tài liệu API : còn được gọi là kiểm tra phát hiện, tài liệu API cung cấp đầy đủ các thông tin để tương tác với API và dễ dàng hướng dẫn người dùng.
- Functionality testing - Kiểm tra chức năng : API hoạt động. Usability testing - Kiểm tra khả năng sử dụng: API rất dễ sử dụng. Reliability testing - Thử nghiệm độ tin cậy: API có thể được kết nối liên tục và dẫn đến kết quả nhất quán. Load testing - Kiểm thử tải: API có thể xử lý một số lượng lớn các request. Creativity testing - Thử nghiệm sáng tạo: API có thể xử lý được sử dụng theo những cách khác nhau. Security testing - Kiểm tra bảo mật: API đã xác định yêu cầu bảo mật bao gồm xác thực, cho phép và điều khiển truy cập. API documentation testing - Kiểm thử tài liệu API : còn được gọi là kiểm tra phát hiện, tài liệu API cung cấp đầy đủ các thông tin để tương tác với API và dễ dàng hướng dẫn người dùng.
- Kiểm thử tự động và kiểm thử thủ công là gì? Kiểm thử tự động API là bạn sử dụng tool để test, trong khi kiểm tra thủ công là bạn viết code của riêng bạn để kiểm tra API. Kiểm tra API là một trong những lĩnh vực mà kiểm thử tự động được đánh giá cao, đặc biệt là đối với DevOps, vòng đời phát triển agile và bàn giao liên tục. DevOps là từ viết tắt của cụm từ Development and Operations. Devops là một thuật ngữ trong phát triển phần mềm để chỉ mối liên quan giữa quá trình phát triển và quá trình vận hành. Mục đích của DevOps làđể thay đổi và cải tiến mối quan hệ giữa hai quá trình này. Khi nào có thể kiểm thử API tự động? Kiểm thử chức năng API. Tạo nhiều dữ liệu động để đưa vào thử nghiệm API. Thiết kế thử nghiệm lặp lại. Phân tích phạm vi kiểm tra chức năng để biết bạn đang bị miss TH nào. Thử nghiệm ad hoc. Sử dụng command-line để nối thử nghiệm với hệ thống xây dựng của bạn. Chuyển đổi giữa nhiều môi trường một cách nhanh chóng, bao gồm cả môi trường phát triển, thử nghiệm và môi trường staging. Kiểm tra các giao thức trong một framework thống nhất. Sử dụng nhiều bộ dữ liệu cùng lúc để bao gồm các kịch bản kiểm tra khác nhau. Đẩy nhanh quá trình thử nghiệm tổng thể. Lỗi kiểm tra, nơi mà bạn ném các lỗi bắt buộc tại API để hiểu nó sẽ phản ứng như thế nào. Thử nghiệm bằng nhiều ngôn ngữ.
- SOAP UI hỗ trợ tất cả các chuẩn giao thức và công nghệ để test tất cả các loại API. Ngoài ra SOAP UI còn cho phép chúng ta thực hiện thử nghiệm phi chức năng như kiểm thử hiệu suất và kiểm thử bảo mật.
- SOAP UI hỗ trợ tất cả các chuẩn giao thức và công nghệ để test tất cả các loại API. Ngoài ra SOAP UI còn cho phép chúng ta thực hiện thử nghiệm phi chức năng như kiểm thử hiệu suất và kiểm thử bảo mật.
- Resource: là những tài nguyên mà bên cung cấp service cung cấp cho. Người sử dụng muốn dùng resource nào thì gọi resource đó ra, theo đúng docs sử dụng API Trong cùng một Resource có thể add nhiều method khác nhau End Point: địa chỉ của service Method: GET, POST, DELETE, PUT, HEAD, PATCH POST : là method create GET : là method UPDATE : Cập nhật một DELETE : Xóa một PUT Parameter: thông tin trường sẽ thực hiện test Ví dụ muốn test trường địa chỉ mail thì add tên trường mail chính xác đã được định nghĩa trong docs sử dụng API TestSuite: Bao gồm nhiều TestCases. Có thể tạo nhiều TestSuites trong 1 project để hỗ trợ nhiều test scenerios TestCase: Bao gồm nhiều TestSteps. TestStep: Mỗi TestStep thực hiện kiểm tra một chức năng của project. Trong một TestStep kiểm tra một chức năng, có thể thực hiện nhiều trường hợp test khác nhau với các dữ liệu đầu vào khác nhau: ví dụ nhập tên bình thường, tên dài, tên có ký tự đặc biệt …. Các dữ liệu đầu vào muốn sử dụng trong tất cả các case test thì tạo chung trong 1 Properites Với 1dữ liệu đầu vào cần tạo riêng 1 REST request và 1 Property Transfer, và chỉ định dữ liệu đầu vào đó sẽ được truyền vào tương ứng với Parameter nào của request nào Properties: Nhập data test - các dữ liệu đầu vào mà tester cần sử dụng để truyền vào các parameter cho mỗi request thực hiện REST Request: Chọn request sẽ thực hiện (Đây chính là Request mà đã được add vào setup ở bước 2) Properties Transfer: Chỉ định truyền dữ liệu Properties nào cho REST Request nào
- TestSuite => TestCase => Test Steps => Step ~ Từng case test nhỏ nhất. Việc cấu trúc testsuite, testcase, test step cũng linh hoạt như việc tổ chức viết testcase bản cứng, chia function lớn => function nhỏ => case test nhỏ nhất. Cần phân chia cấu trúc và đặt tên rõ ràng để đảm bảo Nhìn vào sẽ hiểu ngay được phần đó check cho chức năng nào, check những trường hợp nào Người review có thể phát hiện ra được là đã check đủ chức năng chưa, đã check đủ các trường hợp test chưa Properites để nhập dữ liệu đầu vào cần được đặt tên rõ ràng, không gây nhầm lẫn, và dễ dàng tìm lại khi cần phải chỉnh sửa lại testcase
- Resource: là những tài nguyên mà bên cung cấp service cung cấp cho. Người sử dụng muốn dùng resource nào thì gọi resource đó ra, theo đúng docs sử dụng API
- Resource: là những tài nguyên mà bên cung cấp service cung cấp cho. Người sử dụng muốn dùng resource nào thì gọi resource đó ra, theo đúng docs sử dụng API