Nội dung tiếng Việt sau nội dung tiếng Nhật.
皆さんこんにちは、JPQのマイです。
皆さんはAPIの開発をしていますか。テストはどうしていますか。
APIテストについて聞いたことがあるけれど、よく分からないという方は多いのではないでしょうか。
今回はそんな方のために、APIテストについてお話ししたいと思います。
APIについて
私はWeb開発が大好きです。
一番最初に参加したプロジェクトはLaravelというPHPフレームワークで開発していました。Laravelは素晴らしいフレームワークで、PHPでの開発では大変人気です。しかし、私にとっては、サーバーの管理が大変、チーム内での分担が難しい、そしてテストが大変という難点もありました。そして、次に出会ったのはReactでした。ちょうどサーバレスが話題になった頃なので、Reactとサーバレスというコンビで開発してみました。APIという言葉はよく耳にしていましたが、ちゃんと調べ始めたのはその時からでした。
APIはApplication Programming Interfaceの頭文字です。人間とアプリケーションとの間でやり取りをするためには、ユーザインターフェース(UI)というものがあります。同様に、アプリケーションとアプリケーションとの間でやり取りするための仕組みが必要です。これがAPIです。
当初は成り行きで採用していたAPIですが、開発してみて、いろいろ色々なメリットがあることが分かりました。
まずはなんといっても開発プロセスの簡略化ですね。 FrontendとBackendに分けることで、開発スピードが上がりました。また、モバイルデバイスやブラウザーごと毎に開発する必要がなくなるため、開発量も削減できました。
次のメリットは組み立てやすいことです。APIは独立性が高く、「部品」のように考えると分かりやすいです。その部品は新規プロジェクトはもちろん、既存プロジェクトに組み込むことが簡単です。プロジェクト間でも共通化はできます。例えば、ホームページにGoogle Map APIやFacebookのAPIが組み込まれることがよく見られるでしょう。また、デプロイすることも楽です。独立しているため、アップデートするときに、プロジェクト丸ごとをデプロイする必要がなく、必要なところだけをデプロイすれば済みます。
APIテストについて
APIを導入した当初、開発プロセスを変えましたが、テストのプロセスは今まで通りに行いました。FrontendとBackendでそれぞれ単体テストを書いてから、結合テストを行いました。そしてシステムテストをやって、最後は受け入れテストです。ただ、ここで問題に気づきました。
問題はBackend内の結合やBackendと外部システムとの結合のテストにあります。ここはどうしてもユニットテストではカバーできず、UIで行うことになっていました。UIでのテストなので、かなり実施コストがかかっています。しかし、もっと致命的なのは、テストが開始できるのが開発のかなり終盤の方になることです。ここでバグが見つかれば修正コストが非常に高いです。参考までに、Capers Jones氏が発表した以下のグラフを見れば分かりやすいでしょう。
もっと早めに結合テストを開始できないでしょうか。
いろいろ調べたところ、APIレベルでテストすることで上記問題を回避できることが分かりました。UIの完成を待つことなく、APIが出来上がる時点でテストが可能なため、早期に結合テストを開始できるようになります。
他にもメリットがあります。まず、UIでは実施が難しいテストケースでもAPIを直接叩くなら、実施が可能になります。例えば、入力値チェックが実装されたフォームがあるとします。異常なデータを入力すると、エラーが表示され、「送信」ボタンが非活性になります。そのとき、Backend側でも異常なデータが送信されても期待通りに処理されることを確認しないといけません。UIからテストを行う場合、入力値チェックを一時的に無効化してから、異常のデータを入力し、送信することになります。一方、 APIテストではその必要がありません。
また、APIテストはUIテストと比べて、単純であり、実施時間も短いため、自動化に向いています。
APIテストは単体テストの後に行うことになります。下記のテストピラミッドにあるように、しっかり単体テストを行った上で幅広いAPIテストを実施すべきです。
実際にどうすれば良いのか
APIは「部品」なので、テストでは、「部品」ごとのテスト、つまり単体テスト、と「部品」と「部品」との結合テストをすれば良いでしょう。
APIの「単体テスト」はいわばコンポーネントテストですね。ここでは、Requestに対して、Responseが期待通りに返却されるかを確認します。正常の場合、異常の場合、考え得るRequestに対して、サーバーがそれを処理して、正しいResponseを返却するかどうかをテストします。様々なデータパターンがあるので、テストケースが多くなるでしょう。
次は「部品」と「部品」との結合テスト、つまりAPIのシナリオテストです。ユーザがアプリケーションを使用する際に起きるシナリオを想定してテストを行います。例えば、オンラインショップであれば、下記のシナリオテストが想定できます。
ログインAPI
商品リストAPI
商品詳細 API
カート追加 API
決済API
APIテストでの課題
APIテストをしようとしたとき、最初に直面するのはやはり「どうテストすれば良いか」ということです。実際にRequestを投げて、Responseを受けるところは調べればすぐ出てきますが、難しいのは「どんなテストするか」、いわゆるテスト設計のところですね。
次は作業量ですね。まずテストケース作成だけでも一苦労されるでしょう。テストデータを考え、そのデータを組み合わせて、テストケースを作ることになります。次にテストケースができたら、テスト実行の環境を構築し、テストを実行します。データの組み合わせなので、テストケースが多く、テスト実行に時間がかかることが多いです。
また、テストケース作成・編集など、テストケース管理が大変です。何かアップデートするとき、またテストケースを修正し、再実施するという繰り返し作業となります。
メリットがあるものの、その作業量を考えて諦める人も少なくないでしょう。
その問題を解決できるか
試行錯誤しながらAPIテストを行って、APIテストの大変さを痛感しました。APIテストをもっと簡単にできないかという思いで、チームと協力して、あるツールを開発し始めました。
RakAPItは「Raku API Testing」の略で、「楽で楽しい APIテスト 」を目指しているという意味です。では、RakAPItは上記の問題をどう解決するのでしょうか？
まず、どうテストするか分からない、つまりAPIテストの敷居が高い問題です。RakAPItでは設計をサポートし、データパターンを入力するだけで、テスト ケースを自動生成する機能を搭載しました。また、API定義がSwaggerファイルで書かれている場合、なんとそのテストデータも自動生成され、さらにResponseのアサーションも自動生成されるようにしました。実行に関しても、機能が整っており、ボタンを押すだけで、テストが実行されます。
次は作業量が多い問題です。 RakAPItでは、テスト設計もテスト実行も自動化されます。
また、テストケース作成から、テストケース追加・修正、結果確認など、全てWebで一元管理できることでテスト管理の手間が大幅に省けます。さらに、Webサービスであるため、環境設定は一切必要とせず、ユーザ登録するだけで、すぐ始められます。
まとめ
今回はAPIテストとは何か、そして APIテストの考え方についてお話ししました。
次回はRakAPItを使って、APIテストは実際にどう行うかについてお話ししたいと思います。
お楽しみに！
Còn chờ đến khi nào nữa?
Test API thôi nào!
Xin chào mọi người, tôi là Mai Cường- đến từ công ty Japan Quality Co.,Ltd.
Bạn có đang phát triển API? Việc kiểm thử diễn ra như thế nào?
Chắc hẳn có nhiều người từng nghe về API Testing nhưng không hiểu rõ về nó lắm.
Chính vì vậy, bài viết hôm nay tôi sẽ viết về chủ đề này.
Về API
Tôi rất đam mê phát triển Web.
Dự án đầu tiên tôi làm là phát triển Web trên một PHP framework với tên gọi là Laravel. Laravel là một framework tuyệt vời, rất phổ biến trong việc phát triển bằng ngôn ngữ PHP. Tuy nhiên, tôi đã gặp một số vấn đề như: khá là vất vả trong việc quản lý server, phân chia công việc trong team, và việc kiểm thử cũng rất khó khăn.
Sau đó tôi biết đến một framework khác có tên là React. Đúng thời điểm đó, khái niệm Serverless đang là chủ đề rất hot, tôi đã bắt đầu phát triển bằng cách kết hợp giữa React và Serverless. Tôi đã từng nghe về API nhưng phải đến lúc đó tôi mới bắt đầu tìm hiểu kỹ về nó.
API là viết tắt của cụm từ Application Programming Interface. Như chúng ta biết, cơ chế để tương tác giữa người dùng và ứng dụng được gọi là giao diện người dùng (UI). Tương tự, bạn cũng cần một cơ chế để tương tác giữa các ứng dụng với nhau, đó chính là API.
Ban đầu, tôi chỉ sử dụng API chỉ bởi vì “thời thế xu đẩy”, nhưng trong quá trình phát triển sản phẩm, tôi nhận ra nó có rất nhiều ưu điểm.
Trước hết, điểm nổi bật nhất chính là đơn giản hóa được quá trình phát triển. Bằng cách chia thành Frontend và Backend, tốc độ phát triển sản phẩm được nâng cao hơn. Hơn nữa, nhờ việc không cần phải phát triển bản dành cho điện thoại, bản dành cho PC riêng biệt mà chúng ta có thể giảm bớt đi đáng kể lượng công việc.
Ưu điểm tiếp theo là dễ lắp ghép. API mang tính độc lập cao và có thể coi chúng như một "bộ phận" (object). Chúng ta có thể dễ dàng nhúng các bộ phận đó không chỉ vào các dự án mới mà cả những dự án đã có sẵn,và cũng có thể dùng chung giữa các dự án khác nhau. Chẳng hạn, chúng ta vẫn hay thấy Google Map API hay Facebook API được nhúng vào các trang Web hay ứng dụng.
Ngoài ra, việc triển khai (deployment) API cũng rất dễ dàng. Vì API mang tính độc lập, nên khi cập nhật, chúng ta không cần phải triển khai toàn bộ dự án mà chỉ cần triển khai những nội dung cần thiết.
Về API Testing
Thời gian đầu khi mới làm việc với API, mặc dù đã thay đổi quy trình phát triển, nhưng quy trình kiểm thử vẫn được tiến hành giống như trước đây vẫn làm. Sau khi viết Unit Testing cho Frontend và Backend, sẽ tiến hành kiểm thử kết hợp (Integration Testing). Sau đó là System Testing và cuối cùng là Acceptance Testing. Nhưng tôi bắt đầu nhận ra là có vấn đề.
Vấn đề nằm ở việc kiểm tra kết hợp, gồm kết hợp bên trong Backend và kết hợp Backend với các hệ thống bên ngoài. Chúng tôi không thể giải quyết được vấn đề này bằng Unit Testing, và chỉ có thể tiến hành trên UI. Tuy nhiên việc kiểm thử trên UI sẽ mất rất nhiều công sức và thời gian. Điểm mấu chốt hơn nữa là việc kiểm thử bắt đầu rất muộn trong tiến trình phát triển sản phẩm. Nếu phát hiện lỗi tại đây thì công sức cho việc chỉnh sửa là rất lớn. Để có thể hiểu rõ hơn về vấn đề này, mời bạn tham khảo biểu đồ của Capers Jones dưới đây.
Liệu chúng ta có thể tiến hành kiểm tra kết hợp sớm hơn?
Sau quá trình tìm hiểu, tôi biết được rằng việc kiểm tra ở cấp độ API có thể giải quyết được những vấn đề trên. Chúng ta có thể bắt đầu kiểm tra kết hợp ở giai đoạn sớm hơn, vì có thể bắt đầu kiểm thử ngay thời điểm vừa hoàn thành API mà không cần phải đợi UI hoàn thành.
Bên cạnh đó còn có nhiều lợi ích khác nữa. Đầu tiên, ngay cả khi Test case khó thực hiện với UI, nếu gọi trực tiếp API thì vẫn có thể thực hiện được. Ví dụ: giả sử bạn có một biểu mẫu có kiểm tra giá trị đầu vào (Input Validation). Nếu bạn nhập dữ liệu không đúng, thông báo lỗi sẽ được hiển thị và nút "Gửi" sẽ bị vô hiệu hóa.
Chúng ta cần xác nhận rằng phía Backend sẽ được xử lý như mong đợi ngay cả khi dữ liệu bất thường được gửi đi. Nếu làm kiểm thử từ UI, chúng ta sẽ phải tạm thời vô hiệu hóa chức năng Input Validation, sau đó nhập dữ liệu bất thường và gửi đi.Tuy nhiên, bằng việc kiểm thử API thì không cần thiết phải làm những điều đó.
Hơn nữa, kiểm thử API đơn giản hơn và mất ít thời gian hơn so với kiểm thử UI nên sẽ phù hợp hơn với việc tự động hóa.
Kiểm thử API sẽ được tiến hành sau khi thực hiện Unit Testing. Giống như Test Pyramid bên dưới, chúng ta thấy rằng, sau khi thực hiện một cách cẩn thận Unit Testing thì tiếp đến là việc tiến hành kiểm thử API với phạm vi càng rộng càng tốt.
Thực tế thì phải làm gì?
Vì API được coi như một "bộ phận", nên chúng ta sẽ thực hiện kiểm thử từng "bộ phận" (giống như Unit Testing) và kiểm thử kết hợp giữa các “bộ phận” với nhau.
Unit Testing của API ở đây cũng có nghĩa là Component Testing. Tại đây, chúng ta sẽ xác nhận xem đối với mỗi Request thì Response có được trả về như mong đợi hay không. Chúng ta sẽ tiến hành kiểm tra rằng đối với những trường hợp Request bình thường, bất thường hoặc bất kỳ trường hợp nào có thể xảy ra, thì máy chủ có xử lý và trả Response về đúng hay không. Vì có nhiều mẫu dữ liệu khác nhau nên thường có khá nhiều Test case tại đây.
Tiếp theo là việc kiểm tra kết hợp giữa “bộ phận” với nhau, nghĩa là việc kiểm tra kịch bản API. Chúng ta sẽ tưởng tượng các kịch bản xảy ra khi người dùng sử dụng ứng dụng và tiến hành kiểm tra chúng. Ví dụ, tại cửa hàng bán hàng trực tuyến, có thể giả định kiểm tra theo kịch bản sau:
Đăng nhập API
Danh sách sản phẩm API
Thông tin chi tiết sản phẩm API
Thêm giỏ hàng API
Thanh toán API
Những thách thức khi kiểm thử API
Khi bạn quyết định kiểm thử API, điều đầu tiên bạn phải đối mặt đó là “ Nên làm thế nào để kiểm thử?”. Nhìn chung là có thể tìm hiểu được ngay cách gửi Request và nhận Response, nhưng điều khó khăn hơn cả đó là “kiểm thử như thế nào”, hay nói cách khác đó là việc thiết kế kiểm thử.
Tiếp theo đó là khối lượng công việc. Trước hết, tạo Test case cũng là một việc không hề dễ dàng. Chúng ta sẽ phải suy nghĩ về dữ liệu kiểm thử và kết hợp các dữ liệu đó để tạo ra các Test cases. Sau khi đã có Test cases thì phải xây dựng môi trường kiểm thử và tiến hành việc kiểm thử. Do phải kết hợp các dữ liệu với nhau nên sẽ có nhiều Test case và thường sẽ mất khá nhiều thời gian để thực hiện kiểm thử.
Ngoài ra, việc quản lý Test case như tạo, chỉnh sửa Test case, cũng rất vất vả. Khi tiến hành cập nhật ở đâu đó của sản phẩm, chúng ta điều chỉnh testcase và chạy lại, và cứ thế lặp đi lặp lại.
Mặc dù có nhiều lợi ích, nhưng có rất nhiều người đã từ bỏ việc API Testing khi nghĩ đến khối lượng công việc lớn như vậy.
Liệu có thể giải quyết được các vấn đề đó hay không?
Khi tiến hành kiểm thử API, tôi đã phải thử đi thử lại nhiều bằng nhiều khác nhau và cảm nhận rất sâu sắc về sự vất vả của việc kiểm thử API. Với suy nghĩ, liệu có thể nào làm cho việc kiểm thử API trở nên đơn giản hơn không, tôi cùng đội ngũ của mình đã hợp tác để bắt đầu phát triển một công cụ có tên RakAPIt.
RakAPIt là từ viết tắt của "Raku API Testing", với ý nghĩa là hướng đến một “API Testing dễ dàng và thú vị”. Vậy, RakAPIt sẽ giải quyết các vấn đề trên như thế nào?
Đầu tiên, việc không biết phải thực hiện kiểm thử như thế nào, nói một cách khác là việc khó tiếp cận API Testing. RakAPIt hỗ trợ việc thiết kế và được tích hợp sẵn chức năng tự động tạo Testcase chỉ bằng việc nhập Data Pattern. Không những thế, khi định nghĩa API được viết bằng Swagger thì ngay cả dữ liệu kiểm thử, cũng như dữ liệu để kiểm tra Response (Response Assertion) cũng sẽ được tạo tự động. Chức năng thực thi cũng được trang bị sẵn và chỉ với thao tác nhấn nút là có thể thực hiện được việc kiểm thử.
vấn đề tiếp theo là khối lượng công việc nhiều. Với RakAPIt, việc thiết kế cũng như thực hiện kiểm thử đều được tự động hóa. Ngoài ra, từ việc tạo Test cases; thêm, chỉnh sửa Test cases; xác nhận kết quả, v.v., tất cả đều được quản lý trên nền tảng Web, do đó sẽ giúp tiết kiệm đáng kể công sức trong việc quản lý kiểm thử. Hơn nữa, do là Web Service, việc thiết lập môi trường là không cần thiết, và có thể bắt đầu ngay chỉ với việc đăng ký User.
Tóm lại
Trong bài viết này, tôi đã nói về thế nào là API Testing và cách suy nghĩ trong API Testing.
Bài viết tới tôi sẽ đề cập về việc làm thế nào để thực hiện API Testing bằng việc sử dụng RakAPIt. Hãy cùng chờ đón các nội dung tiếp theo trong lần tới nhé!