Phát triển và kiểm thử phần mềm luôn đi cùng nhau. Trong thời đại phát triển phần mềm linh hoạt (agile), với các bản phát hành nhanh chóng và liên tục, chúng ta lại cần thực hiện kiểm thử nhiều hơn và thường xuyên hơn.
Để thực hiện kiểm thử phần mềm hiệu quả, chúng ta cần biết về các loại kiểm thử khác nhau và khi nào chúng ta nên sử dụng chúng.
Trong bài viết này, hãy cùng thảo luận về một số loại kiểm thử phần mềm có sẵn để giúp bạn có thể đảm bảo khả năng hoạt động, tính toàn vẹn và bảo mật của các sản phẩm và ứng dụng được xây dựng.
Software Testing Pyramid
Software Testing Pyramid, tạm dịch là Kim tự tháp kiểm thử phần mềm, bao gồm tất cả các giai đoạn của vòng đời phát triển phần mềm (SDLC). Nó bắt đầu từ unit testing, đến kiểm thử tích hợp (integration testing) và kết thúc với kiểm thử chức năng ở đỉnh.
Không có sự phân bổ cố định giữa các loại kiểm thử này. Thay vào đó, bạn nên xác định những bài kiểm thử nào phù hợp nhất với nhu cầu của bạn. Để đưa ra quyết định về các loại kiểm thử cần thiết, chúng ta cần cân đối chi phí, thời gian thực hiện và tài nguyên cần cho từng loại kiểm thử.
Các nhà phát triển phần mềm Agile cũng sử dụng phương pháp góc phần tư kiểm thử phần mềm ( software testing quadrants ) để phân loại các kiểm thử là nghiệp vụ (business-facing) hay công nghệ (technology-facing) và liệu các kiểm thử đó để giúp phê bình phản biện, tìm ra những bất cập của sản phẩm (critique product) hay hỗ trợ đội ngũ phát triển xây dựng và thay đổi ứng dụng một cách tự tin.
Chẳng hạn unit testing là một kiểm thử công nghệ hỗ trợ đội ngũ phát triển, trong khi kiểm tra tính khả dụng (usability testing) là một kiểm thử nghiệp vụ để phê bình phản biện sản phẩm.
Bây giờ chúng ta hãy xem xét các loại kiểm thử phần mềm quan trọng.
Kiểm thử đơn vị – Unit Testing
Kiểm thử đơn vị (Unit Testing) liên quan đến việc kiểm tra các thành phần code riêng lẻ thay vì toàn bộ code. Nó xác minh hoạt động của tất cả logic thành phần của bạn để xác định sớm các lỗi trong vòng đời phát triển phần mềm SDLC, cho phép bạn sửa lỗi trước khi phát triển thêm.
Kiểm thử đơn vị được gọi là kiểm thử hộp trắng (white box), vì kiểm thử diễn ra với đầy đủ kiến thức về cấu trúc và môi trường của ứng dụng.
Một ví dụ về kiểm thử đơn vị là tạo các đối tượng giả để kiểm tra các phần code, chẳng hạn như các hàm với các biến chưa được tạo.
Kiểm thử tích hợp – Integration testing
Một bước tiến từ kiểm thử đơn vị là kiểm tra tích hợp (integration testing), kết hợp các thành phần riêng lẻ và kiểm tra chúng thành nhóm. Kiểm tra tích hợp xác định các vấn đề trong cách các thành phần riêng lẻ tương tác với nhau để xem liệu code có đáp ứng tất cả các thông số kỹ thuật chức năng của nó hay không.
Kiểm thử tích hợp khác với kiểm thử đơn vị ở chỗ nó tập trung vào các mô-đun và thành phần hoạt động độc lập trong mối quan hệ với nhóm tổng thể. Mặt khác, kiểm thử đơn vị tập trung vào việc cô lập các mô-đun hoặc thành phần trước khi kiểm thử.
Mục đích của kiểm thử tích hợp là để lộ ra bất kỳ vấn đề hoặc lỗ hổng nào trong phần mềm giữa các mô-đun hoặc thành phần được tích hợp.
Lấy một ví dụ đơn giản, nếu bạn thực hiện kiểm tra tích hợp của một dịch vụ email mà bạn đang xây dựng, bạn sẽ cần kiểm tra các thành phần riêng lẻ như Soạn thư, Lưu bản nháp, Gửi, Chuyển đến Hộp thư đến, Đăng xuất, v.v..
Trước tiên, bạn sẽ thực hiện kiểm tra đơn vị của các tính năng riêng lẻ, sau đó là kiểm tra tích hợp cho từng chức năng có liên quan.
Kiểm thử đầu cuối – End-to-end Testing
Trên đỉnh của kim tự tháp là kiểm thử end-to-end (E2E), tạm dịch là kiểm thử đầu cuối. Như tên gọi của nó, kiểm thử end-to-end tái tạo toàn bộ hoạt động của ứng dụng để kiểm tra tất cả các kết nối và phụ thuộc của ứng dụng. Chúng bao gồm kết nối mạng, truy cập cơ sở dữ liệu và các phụ thuộc bên ngoài.
Bạn tiến hành kiểm tra E2E trong môi trường mô phỏng môi trường người dùng thực tế.
Bạn có thể xác định mức độ thành công của kiểm thử E2E bằng cách sử dụng một số chỉ số, bao gồm Trạng thái kiểm thử (Status of Test) (được theo dõi bằng hình ảnh, chẳng hạn như biểu đồ), Trạng thái và Báo cáo (phải hiển thị trạng thái thực thi và bất kỳ lỗ hổng hoặc lỗi nào được phát hiện ).
Các loại kiểm thử phần mềm
Trong các cấp độ của kim tự tháp kiểm thử (testing pyramid) có rất nhiều quy trình cụ thể để thử nghiệm các chức năng và tính năng ứng dụng khác nhau, cũng như tính toàn vẹn và bảo mật của ứng dụng.
Kiểm thử Bảo mật Ứng dụng
Một trong những loại kiểm thử quan trọng nhất đối với các ứng dụng là kiểm thử bảo mật ứng dụng (application security testing). Kiểm thử bảo mật giúp bạn xác định các lỗ hổng ứng dụng có thể bị tin tặc khai thác và sửa chúng trước khi bạn phát hành sản phẩm hoặc ứng dụng của mình.
Có sẵn một loạt các bài kiểm tra bảo mật ứng dụng cho bạn với các bài kiểm tra khác nhau có thể áp dụng ở các phần khác nhau của vòng đời phát triển phần mềm.
Bạn có thể tìm thấy các loại thử nghiệm bảo mật ứng dụng khác nhau ở các cấp độ khác nhau của kim tự tháp thử nghiệm. Mỗi bài kiểm tra đều có điểm mạnh và điểm yếu riêng. Bạn nên sử dụng các loại thử nghiệm khác nhau cùng nhau để đảm bảo tính toàn vẹn tổng thể của chúng.
Kiểm thử Bảo mật Ứng dụng Tĩnh (SAST)
Bạn nên sử dụng Kiểm thử bảo mật ứng dụng tĩnh (Static Application Security Testing – SAST) sớm trong SDLC. Đây là một ví dụ về kiểm thử đơn vị.
SAST phản ánh kiến thức của nhà phát triển, bao gồm thiết kế và triển khai chung của ứng dụng và do đó nó là kiểm thử hộp trắng hoặc kiểm thử từ trong ra ngoài ( inside out)
SAST tự phân tích code thay vì ứng dụng cuối cùng và bạn có thể chạy nó mà không thực sự thực thi code.
Theo các nhà phân tích bảo mật tại Cloud Defense
“SAST kiểm tra mã của bạn xem có vi phạm các quy tắc bảo mật hay không và so sánh các lỗ hổng được tìm thấy giữa các nhánh nguồn và mục tiêu (source and target branches) … sau đó bạn sẽ nhận được thông báo nếu các phần phụ thuộc của dự án của bạn bị ảnh hưởng bởi các lỗ hổng mới được tìm thấy.”
Khi bạn đã biết về các lỗ hổng, bạn có thể giải quyết chúng trước khi xây dựng ứng dụng cuối cùng.
Bạn nên áp dụng SAST trong giai đoạn phát triển các dự án phần mềm của mình. Một cách tiếp cận tốt sẽ là thiết kế và viết các ứng dụng để đưa các bản quét SAST vào quy trình phát triển.
Kiểm thử Bảo mật Ứng dụng Động (DAST)
Đối nghịch với SAST là Kiểm thử bảo mật ứng dụng động (dynamic application security testing – DAST), kiểm thử ứng dụng khi đã được biên dịch đầy đủ. Bạn thiết kế và chạy các bài kiểm thử này mà không có bất kỳ kiến thức nào về cấu trúc hoặc mã cơ bản.
Bởi vì DAST áp dụng quan điểm của tin tặc, nó được gọi là kiểm thử hộp đen hoặc kiểm thử ngoài vào trong (outside in).
DAST hoạt động bằng cách tấn công code đang chạy và tìm cách khai thác các lỗ hổng tiềm ẩn. DAST có thể sử dụng các kỹ thuật tấn công phổ biến như cross-site scripting và SQL injection.
DAST được sử dụng muộn trong SDLC và là một ví dụ về kiểm thử bảo mật tích hợp (integration security testing). Mặc dù chậm (kiểm tra DAST hoàn chỉnh của một ứng dụng hoàn chỉnh có thể mất trung bình từ năm đến bảy ngày), nhưng nó sẽ tiết lộ cho bạn những lỗ hổng có khả năng xảy ra nhất trong các ứng dụng của bạn mà tin tặc sẽ khai thác.
Kiểm thử Bảo mật Ứng dụng Tương tác (IAST)
Kiểm thử bảo mật ứng dụng tương tác (Interactive application security testing – IAST) là một phương pháp thử nghiệm mới hơn kết hợp tính hiệu quả của SAST và DAST trong khi khắc phục các vấn đề liên quan đến các thử nghiệm được thiết lập này.
IAST tiến hành quét ứng dụng theo thời gian thực liên tục để tìm lỗi và lỗ hổng bảo mật bằng cách sử dụng tác nhân giám sát được chèn vào. Mặc dù IAST hoạt động trong một ứng dụng đang chạy, nó được coi là một quá trình kiểm thử SDLC sớm.
Bất kể bạn đang muốn kiểm tra loại phần mềm nào, IAST được sử dụng tốt nhất trong môi trường QA (Quality Assurance) hoặc môi trường được thiết kế để tái tạo càng gần càng tốt với sản phẩm mà không cần người sử dụng hoặc khách hàng của bạn thực sự truy cập vào nó.
Kiểm tra khả năng tương thích
Kiểm tra khả năng tương thích (Compatibility testing) đánh giá cách ứng dụng của bạn hoạt động và mức độ an toàn của ứng dụng trên các thiết bị và môi trường khác nhau, bao gồm cả thiết bị di động và trên các hệ điều hành khác nhau.
Kiểm tra khả năng tương thích cũng có thể đánh giá xem phiên bản phần mềm hiện tại có tương thích với các phiên bản khác của phần mềm hay không.
Ví dụ về kiểm tra tính tương thích bao gồm:
- Kiểm tra trình duyệt (kiểm tra để đảm bảo trang web hoặc trang web dành cho thiết bị di động của bạn hoàn toàn tương thích với các trình duyệt khác nhau)
- Thử nghiệm di động (đảm bảo ứng dụng của bạn tương thích với iOS và Android)
- hoặc kiểm tra phần mềm (nếu bạn định tạo nhiều ứng dụng phần mềm cần tương tác với nhau, bạn sẽ cần tiến hành kiểm tra khả năng tương thích để đảm bảo rằng chúng thực sự hoạt động như vậy).
Vượt ra ngoài Kim tự tháp kiểm thử phần mềm
Các phiên bản sửa đổi của kim tự tháp kiểm thử có thể bao gồm một cấp bên cạnh hoặc cao hơn thử nghiệm end-to-end. Cấp độ này bao gồm các bài kiểm tra tập trung vào người dùng ứng dụng.
Kiểm tra Hiệu suất – Performance testing
Bạn cần biết ứng dụng sẽ hoạt động như thế nào trong nhiều điều kiện khác nhau và đây là mục đích của việc kiểm tra hiệu suất (performance testing). Performance testing có thể mô hình hóa các tải và ứng suất ( loads and stresses) khác nhau để đánh giá mức độ mạnh mẽ của ứng dụng. Loại kiểm tra hiệu suất dựa trên các điều kiện được áp dụng.
Một ví dụ về hiệu suất hoạt động là kiểm tra tải, xác định tải tối đa được áp dụng cho hệ thống tại thời điểm xảy ra sự cố.
Một ví dụ khác như kiểm tra khả năng mở rộng, áp dụng tải tăng dần lên hệ thống để đánh giá các cách thích ứng với các ứng suất (stresses) hệ thống được thêm vào.
Và thử nghiệm tăng đột biến đánh giá ảnh hưởng của việc áp dụng các thay đổi tải trọng lớn đột ngột lên hệ thống.
Bạn nên tiến hành kiểm tra hiệu suất trên bất kỳ hệ thống phần mềm nào trước khi đưa nó ra thị trường. Kiểm tra tính ổn định, khả năng mở rộng và tốc độ để bạn có thể xác định những gì cần khắc phục trước khi đưa vào sử dụng.
Kiểm thử tính khả dụng – Usability Testing
Kiểm tra thực tế sử dụng của giao diện ứng dụng là một nhiệm vụ quan trọng. Chúng ta cần phải xem nếu ứng dụng hoạt động như đã thiết kế. Đồng thời xem bản thân thiết kế có được người dùng chấp nhận hay không. Đây chính là sự cần thiết của Usability Testing hay kiểm thử tính khả dụng.
Với kiểm tra khả năng sử dụng, các nhà phát triển có thể đánh giá phản ứng của người dùng đối với các tính năng và chức năng cụ thể của ứng dụng. Điều này bao gồm các tính năng mà bạn có thể biết trước rằng sẽ ít được người dùng mong muốn nhưng cần thiết cho mục đích bảo mật và để hoạt động đúng (như yêu cầu mật khẩu mạnh).
Kiểm tra tính khả dụng không tập trung quá nhiều về các vấn đề thẩm mỹ hoặc sửa lỗi ngữ pháp trong bất kỳ văn bản viết nào (mặc dù cả hai vấn đề đó chắc chắn đều quan trọng theo đúng nghĩa của chúng). Thay vào đó là việc người dùng cuối sử dụng ứng dụng dễ dàng như thế nào.
Kết luận
Kiểm thử không chỉ là việc mà bộ phận QA cần làm sau khi bạn phát triển xong một ứng dụng. Kiểm thử cũng là một phần quan trọng của quá trình phát triển phần mềm.
Biết được những bài kiểm thử nào có sẵn và cách chúng hoạt động sẽ giúp bạn đảm bảo ứng dụng của mình hoạt động tốt, an toàn và được người dùng cuối chấp nhận.
Nguồn bài viết: https://www.freecodecamp.org/news/types-of-software-testing/
Ảnh cover: Photo by Christina @ wocintechchat.com
