Hướng dẫn kiểm thử SOA: Phương pháp kiểm thử dành cho mô hình kiến trúc SOA
Bài đăng này đã không được cập nhật trong 3 năm
Ngày nay phần mềm thay đổi không ngừng và dễ kiểm soát sự thay đổi mong muốn của người dùng sau tất cả , một mô hình độc lập thì không hữu ích.
Ở nơi đó, SOA phù hợp như là một giải pháp.
Đó là lý do tại sao, rất nhiều công ty đang dần thích nghi hoặc cố gắng để thích nghi với cách tiếp cận SOA vì ưu điểm của nó như: Cắt giảm chi phí, sự linh hoạt trong kinh doanh, dễ dàng bảo trì vv. Với thị trường sắp tới đầy kiến trúc SOA, nó trở nên cần thiết cho nhân viên kiểm thử có được một ý tưởng đúng đắn về nghề thử nghiệm SOA. Trong bài viết này sẽ giới thiệu những điều cơ bản của SOA với các ví dụ của nó.
Điều này sẽ cung cấp cho độc giả một ý tưởng cơ bản về SOA. Điều tiếp theo sẽ được đề cập là cách tiếp cận các dịch vụ web thực hiện. Cuối cùng, chúng ta sẽ được vào quy trình kiểm thử mà có thể được theo dõi trong một mô hình kiến trúc SOA.
Vậy SOA là gì?
SOA (Service-Oriented Architecture) - kiến trúc hướng dịch vụ. Hiểu một cách cơ bản, SOA là tập hợp các dịch vụ kết nối “mềm dẻo” với nhau, có giao tiếp được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới. Nói cách khác, SOA là:
- Một kiểu kiến trúc phần mềm gồm nhiều thành phần độc lập được thể hiện thành những dịch vụ (service), mỗi dịch vụ thực hiện quy trình nghiệp vụ nào đó của doanh nghiệp.
- Các thành phần được nối kết qua cổng giao tiếp, có tính kế thừa các thành phần đang tồn tại, và sự tương tác giữa chúng không cần quan tâm đến việc chúng được phát triển trên nền tảng công nghệ nào. Điều này khiến hệ thống có thể mở rộng và tích hợp một cách dễ dàng.
Bản chất SOA chỉ đơn thuần là sự đáp ứng đối với một thách thức ngày càng lớn: đó là yêu cầu thực tế của doanh nghiệp thay đổi ngày càng nhanh, đến mức những cấu trúc ứng dụng kiểu truyền thống khó giải quyết nổi. SOA sẽ đáp ứng được yêu cầu đó, nó sẽ trợ giúp cho hoạt động doanh nghiệp có thể quản lý được (manageable), linh hoạt hơn và sẵn sàng thay đổi hơn. Một chuyên gia của IBM từng nói: “SOA được xây dựng để thay đổi (built to change), chứ không chỉ để tồn tại (not built to last)“. Từ góc độ doanh nghiệp thì có thể coi SOA là một phương pháp để tái cấu trúc hạ tầng thông tin của doanh nghiệp.
Một số ưu điểm của việc phát triển ứng dụng hướng dịch vụ (SOA)
- Thứ nhất, tái sử dụng phần mềm. Nếu một dịch vụ có quy mô và kích thước phù hợp sau đó nó có thể được tái sử dụng cho lần kế tiếp. Điều này đồng nghĩa sẽ làm giảm công sức phát triển và chi phí về mặt tài chính cho cả hai phía: nhà phát triển phần mềm và các khách hàng (doanh nghiệp).
- Thứ hai, linh hoạt khi mở rộng, kết nối và tích hợp. Giả sử rằng các dịch vụ sẽ không được tái sử dụng, thì ta có thể đưa ra nhiều giá trị nếu ta làm cho hệ thống CNTT chỉnh sửa dễ dàng hơn.
Ví dụ về SOA
Yêu cầu nghiệp vụ: Ứng dụng mà người dùng có thể đăng nhập và tìm kiếm các Nhà hàng dựa trên định vị vị trí địa lý, Tải chi tiết về Nhà hàng và Menu từ máy chủ khi quá trình tìm kiếm hoàn tất và cuối cùng có thể thực hiện thanh toán để đặt hàng.
Yêu cầu nghiệp vụ này có thể đạt được bằng cách thực hiện SOA.
Có thể có dịch vụ / vi dịch vụ như sau để thực hiện các nhiệm vụ khác nhau:
- Trong quá trình đăng nhập, dịch vụ sẽ được sử dụng là 'Dịch vụ xác thực'
- Tìm kiếm các nhà hàng sẽ được thực hiện bằng 'Dịch vụ định vị địa lý'
- Tải Menu nên được thực hiện bởi 'Menu Downloader service'
- Cuối cùng, thanh toán sẽ được thực hiện bằng 'Dịch vụ thanh toán'
Mỗi dịch vụ nói trên làm một chức năng duy nhất để làm cho hệ thống làm việc và cung cấp những gì nó được yêu cầu phải làm. Bây giờ, nếu một khách hàng chỉ cần nhìn thấy nhà hàng và thực đơn của nó nhưng không cần giao diện cổng thanh toán thì họ chỉ mua / triển khai ba dịch vụ đầu tiên.
Điều này làm cho công việc đơn giản để phát triển, Triển khai, Bán hàng, Bảo trì và sau tất cả các khách hàng / Người dùng cuối.
Web services
Web services là các API [Giao diện lập trình ứng dụng] tạo điều kiện cho sự tương tác giữa các chương trình phần mềm khác nhau. Có một nhà cung cấp dịch vụ lưu trữ các dịch vụ trên Web. Như một phần của máy chủ, một WSDL được lưu trữ bởi nhà cung cấp. Khi khách hàng gửi một thông báo yêu cầu đến nhà cung cấp dịch vụ, giao tiếp được thiết lập với việc sử dụng URL / WSDL. Ở ví dụ bên dưới, máy chủ định vị địa lý sở hữu một dịch vụ Web được sử dụng bởi người yêu cầu dịch vụ.
Quá trình kiểm thử SOA
Mỗi sản phẩm, mô hình, cơ sở hạ tầng cần phải đi vào giai đoạn Thử nghiệm để đáp ứng người dùng cuối về mặt chất lượng sản phẩm. Kiểm tra SOA không chỉ giới hạn trong thử nghiệm của một lớp / dịch vụ kiểm tra giao thức Web. Đây là thử nghiệm tổng thể của kiến trúc và mỗi phút một phần của nó.
Cách tiếp cận thử nghiệm có thể tương tự như trong quy trình kiểm thử thông thường. Tức là
- Quy trình xem xét yêu cầu
- Lập kế hoạch Kiểm tra
- Thiết kế kiểm thử
- Thiết lập môi trường
- Giai đoạn tiến hành kiểm thử
- Giai đoạn báo cáo kết quả kiểm thử
Quy trình kiểm thử SOA xoay quanh 3 lớp trong kiến trúc:
- Người tiêu dùng dịch vụ
- Các lớp xử lý
- Các lớp dịch vụ
Đi cùng một ví dụ ở trên, chúng ta có thể có các lớp như sau:
- Lớp khách hàng của dịch vụ giúp tương tác người tiêu dùng. Điều này giúp đọc được đầu vào từ người dùng cuối và trả lời phản hồi thích hợp cho yêu cầu nhận được. Nói cách khác, điều này về cơ bản có giao diện người dùng.
- Đây là lớp tập trung vào việc thực hiện. Trong lớp này,chúng ta sẽ có các phương pháp xác thực, tạo ra một người sử dụng vv
- Các lớp dịch vụ là các chức năng nghiệp vụ về dịch vụ. Tất cả các dịch vụ được đặt tên khi một nhiệm vụ cụ thể được thực hiện được trong lớp này.
Về cơ bản việc kiểm tra có thể được chia thành 4 giai đoạn khác nhau;
Cấp # 1
- Thử nghiệm cấp dịch vụ:
- Mỗi dịch vụ tham gia vào hệ thống được kiểm tra riêng lẻ dựa trên một yêu cầu và phương pháp phản hồi.
- Thử nghiệm này là bắt buộc và rất quan trọng để tiến hành các quy trình kiểm tra khác.2) Thử nghiệm chức năng:
- Kiểm thử được tiến hành đối với các dịch vụ về nhu cầu kinh doanh của họ để tìm ra nếu respond nhận được là đúng.
- Khi mà các yêu cầu nghiệp vụ được chuyển thành các Test case và các câu lệnh yêu cầu được hình thành.
- Sau đó các câu lệnh yêu cầu được xử lý để xem các câu trả lời có chính xác không.
- Trong trường hợp dữ liệu đầu vào không hợp lệ, phải gửi mã sai đúng hoặc phải thông báo lỗi thích hợp.
- Các định dạng của respond, cũng như các kịch bản tiêu cực, phải được thực hiện.
- Kiểm thử bảo mật:
- Bất cứ khi nào nói đến một web services, Kiểm thử bảo mật đóng một vai trò quan trọng trong sự thành công của Quy trình kiểm thử.
- Cổng thông tin xác thực, Cổng thanh toán vv.. nên được mã hóa khi dữ liệu được phân tích.
- Khi nói đến XML, các lỗ hổng như CSRF, SQL injection nên được xác minh.
- Kiểm thử hiệu năng:
- Các dịch vụ được sử dụng trong kiến trúc được lưu trữ để nhiều ứng dụng khác nhau có thể sử dụng nó. Kiểm thử hiệu năng đảm bảo độ tin cậy của các dịch vụ đó.
- Việc kiểm tra các dịch vụ nên được thực hiện để tìm ra các kết quả sau; - Để xác định tính ổn định của dịch vụ. - Để xác nhận khả năng mở rộng của các dịch vụ. - Hành vi dịch vụ trong điều kiện tải cao điểm - Để tìm thời gian phản hồi thông qua các dịch vụ.
Cấp 2
- Quy trình kiểm thử:
- Quá trình này liên quan đến việc kiểm tra các quy trình nghiệp vụ khác nhau.
- Điều này nên bao gồm các kịch bản tích hợp các dịch vụ Web và ứng dụng bao gồm các yêu cầu nghiệp vụ.
- Mô phỏng việc sử dụng phải được thực hiện để tạo ra dữ liệu đầu vào mẫu và phải được thực hiện cho các đầu ra tương ứng.
- Luồng dữ liệu từ các lớp khác nhau nên được thực hiện để chứng minh khi nó được tích hợp các chức năng của hệ thống này chạy trơn tru .
Cấp # 3
- Kiểm thử đầu cuối:
- Giai đoạn này là để xác nhận các yêu cầu nghiệp vụ cả chức năng và phi chức năng.
- UI của ứng dụng được xác nhận.
- Quy trình nghiệp vụ liên quan được kiểm tra.
- Dòng dữ liệu đầu cuối được xác nhận trong giai đoạn này.
- Hoạt động với tất cả các dịch vụ khi các dịch vụ được tích hợp với nhau được xác nhận.
Cấp # 4
- Kiểm tra hồi quy:
- Sự ổn định của hệ thống trong bản release được xác nhận bởi kiểm thử này.
- Điều này có thể đạt được bằng kiểm thử bằng tay hoặc tự động hóa.
Những thách thức trong kiểm thử SOA Với rất nhiều phần cấu thành kiến trúc SOA, nó trở thành một công việc thực sự khó khăn để chứng nhận nó trong kiểm thử.
- Khó khăn để mô phỏng các môi trường kiểm thử để tiến hành quá trình kiểm thử.
- Các sản phẩm có liên quan đến mô hình có thể cùng công nghệ / nhà cung cấp. Nhưng, chúng cũng có thể khác. Vấn đề sẽ nhiều hơn?
- Các kiểm thử kết hợp gặp UP với một số lượng dịch vụ / các thành phần liên quan.
- Tính phức tạp trong mô hình
- Lặp lại các issue / kiểm thử là một công việc khó khăn.
- Không giống như các mô hình khác, trọng tâm chính của kiểm thử nên nằm trong phạm vi nghiệp vụ hơn là dịch vụ và tính năng của nó.
Các công cụ kiểm thử SOA
Có rất nhiều ứng dụng để kiểm thử SOA. Các công cụ kiểm thử SOA được lựa chọn dựa trên kết quả chính xác và năng suất tốt hơn.
1. SoapUI: Đây là một công cụ miễn phí nhằm thử nghiệm dịch vụ Web. SoapUI có khả năng thực hiện kiểm tra chức năng, kiểm tra hiệu suất, và kiểm tra tải 2. Apache Jmeter: Đây cũng là tiện ích OPEN SOURCE được sử dụng để phân tích hiệu suất của lời gọi SOAP. 3. JProfiler: Sử dụng để ngăn chặn hoặc phát hiện sự rò rỉ bộ nhớ, tìm các nút thắt cổ chai trong quá trình thực hiện ... 4. Thử nghiệm dịch vụ HP: Đây được tích hợp với HP QC. Đây là một công cụ kiểm tra chức năng, cũng hỗ trợ UI và chia sẻ dịch vụ thử nghiệm
Kết Luận:
Thông qua bài viết này, chúng ta đã hiểu được tính dị thường của mô hình. Điều này rất khác so với mô hình kế thừa và bài viết đưa ra một ý tưởng hay về nó. Bài viết này cũng đưa ra một số thông tin về phương thức SOA và cách tiến hành kiểm thử.
Nguồn dịch và tham khảo: http://www.softwaretestinghelp.com/soa-testing/ http://meliasoft.com/Default.aspx?tabid=86&News=208&CategoryID=9
All rights reserved