Bài viết chuyên sâu

[Software Testing] SOA API Testing

[Software Testing] SOA API Testing

by Admin Dathoc -
Number of replies: 0

#koolj_softwaretesting
#chiase
#những_mẫu_testcases_cơ_bản
Về THIẾT KẾ testcase và thực hiện API test cho ứng dụng kiến trúc SOA.
(Ad thấy bài viết quảng cáo nhiều quá cứ remove nhé- còn mình viết bài này với tâm tư share 100% những cái gì mình kinh nghiệm công việc trong 41 năm qua)

Nói về SOA thì năm 1998 tôi thấy nó đã giới thiệu rồi, .NET 2.0 hồi đó api service rất sơ sài. Nhưng là tester các fans cần học kiến trúc đó là gì, và sự khác biệt với các kiến trúc khác để có được những case phù hợp test cho ứng dụng.

👉Cụ thể - SOA:
SOA nhắm tới 6 cái (tới 2009 mới tổng kết): huớng nghiệp vụ; mở; đa nền tảng; chia sẻ; lỏng; dễ tiến hoá
Vậy đơn giản tester sẽ theo đó thiết kế. Và nhìn qua bạn sẽ thấy nó khác với case thông thường của các loại kiểm định chúng ta đã từng qua. Vậy tester cần bám cơ bản vào những layer, level nào và type nào trong SOA API testing:
- Test của bạn chỉ đi qua API xong lưu ý data + logic thực tế phải đi qua 3 layer: GUI (lớp tương tác với người dùng), Process (lớp xử lý ở máy trạm: database, tracker, log), Service (lớp dịch vụ xử lý logic)
- Test của bạn phải cover levels: unit, integration functionality, performance, security, api-oriented end to end syntax

👉VD - việc qua testing API, chúng ta cover các level testing khác:
- unit: dev rất lười, nhưng bạn tester có thể viết case bằng lời cho các bạn dev làm. Đơn giản là: hàm này anh vào mấy biến, anh gọi cái gì, trả ra cái gì; bao của các biến kiểu là gì. Anh kỳ vọng xử lý hàm này trong bao lâu?. Và chỉ thế thôi là tester sẽ cho ít nhát 10 case 1 hàm. Việc giám sát progress làm từ dev sẽ là chính tester. Việc đảm bảo chất lượng làm là techlead chủ động.
- intergration: giữa hàm này với ham khác, comp này với comp khác; tích hợp giữa các service này với service khác, giữa service trong và service ngoài
- function: bạn phải đảm bảo api đó làm đúng chức năng của chính nó, thêm nữa là ổn định
- performance: bắt buộc api đó phải phản hồi trong giới hạn time, tính sẵn sàng phải có
- security: đảm bảo api đó ko bị rò data, chỉ có nơi chỉ định được gọi, có thời hạn gọi, có quy tắc cú pháp, no/yes CORS
- syntax: đảm bảo cú pháp chặt cả gửi đi lẫn về; nếu sai cú pháp sẽ thông báo hoặc không cho thực hiện

Nếu xử lý được như trên, cho các tester không biêt coding thì tôi đảm bảo... lỗi của ứng dụng không còn đường thoát trên mặt trận API.
.
.
.
Để thấy độ biến dị những case và những khía cạnh khác với phân tích thông thường, nhiều chia sẻ của các anh chị đi trước (cần các bạn lưu ý gì trước khi chúng ta đi sâu hơn) các bạn có thể xem clip này tại phút thứ 42: https://www.youtube.com/watch?v=_OeGfAgLgeY

Và khi các bạn đã thành thạo tạo case hoàn chỉnh cho API testing. Vậy các bạn nên chuyển tiếp sang Automation cho API đó.
👉Vậy tester cần học thêm những scripting đơn giản và những tool hỗ trợ ngay việc đó tự động (ko cần script nhiều):
- OpenSoap UI (đầy đủ cho bạn từ function, sytax, security, performance - quản trị các test cases - bạn cần biết Groovy script để mở rộng)
- Postman (chỉ đơn giản là một tool thử api thông thường của dev - quản trị cases- bạn cần script thêm để theo login test của bạn)
Ví dụ đây là một list học miễn phí autotest cho api, bạn Ấn Độ giảng viên giảng rất chậm, và tester Việt có thể bật CC auto translate sang Tiếng Việt để có thể làm theo: https://www.youtube.com/watch?v=juldrxDrSH0...
.
.
.
Xin đưa ra mấy quan tâm từ việc thiết kế case cho kiểm định SOA
👉1. Thiết kế:
- Như hình tổng hợp dưới là một ví dụ
- Unit & Integration: Như clip này tổng hợp code quality cho một ví dụ Unitest. Bạn dev chỉ việc điền thông số, và nó tự sinh ra những logic theo bạn ý mà tester/techlead đánh gia ngay được cái bạn ý đang viết có bị lỗi tiềm năng hay không: https://www.youtube.com/watch?v=E4HGWr0JCUk&t=2s
- Function: API data input chỉ có 3 kiểu: string, num, enum; vậy cần quan tâm cận trên dưới, ký tự hoa thường, số bít thể hiện, tập set của giá trị
- Function: với communicate thì cần thêm case cho trans thông thường và SQL trans. Với trans thông thường thi ok, nhưng với SQL cần thêm case cho injection
- Tôi phát hiện ra rất rất nhiều dự án không có quy trình (đặc biệt startup) họ ko doc api một cách bài bản. Hay nói cách khác tester không có gì đọc để tưởng tượng đầy đủ các template json vào ra. Có thể dev dựa vào ko có time, xong tester cần hỗ trợ là: ngồi và hỏi dev từng chi tiết một
- Các mẫu function khác về bound, về security, performance, load bạn có thể tham khảo các bài viết của tôi về các phần này
Sách tham khảo bạn có thể xem: (tham khảo link bên dưới)
SOA test method: https://1drv.ms/b/s!AoMt1NVPO04zg9VQaSz814qVMPkBjw?e=gICoP9
.
.
.
👉2. Thực hiện:
- Với các tool tự động họ sẽ có set các case có sẵn cho bạn, kiểu như bạn chỉ việc điền api vào mà chạy. Vậy như thế nó sẽ thiếu những case đặc thù của dự án. Vậy chúng ta vẫn phải thiết kế thêm
- Khó dev team nào viết đầy đủ doc api, hay nói cách khác họ không có time để viết. Vậy nên việc api này chạy và với một cấu hình đặc biệt mà khác với api khác đồng dự án... là chuyện đương nhiên
- Ví dụ cách mình loadtest với 250 thread cho 800k request cho 1api gọi service từ Hà Nội tới https://www.here.com/ trong 3 phút:
https://m.facebook.com/story.php?story_fbid=10156803127285079&id=719990078
.
.
.
Vậy bạn có thể kết hợp các gợi ý trên để tạo ra những SOA API test case hoàn hảo hơn.
Gluk!
------------------------------
SÁCH - TẠP CHÍ - TÀI LIỆU ĐÚC KẾT KINH NGHIỆM làm về SOFTWARE TESTING cần tham khảo: dathoc.net/booktest
Bạn muốn thông thạo hơn việc viết thiết kế testcase, sử dụng công cụ automation test HERA để auto test, các framework Appium, TestNG, xin tham gia FREE tại: youtube.com/c/TesterPRO/
By: dathoc.net/cv