Tác giả: Nahla Davies
Kiểm thử phần mềm đang phát triển ngày một nhanh và đòi hỏi người tester phải kịp thời nắm bắt các vấn đề mới nhất.
Tháp công thức kiểm thử phần mềm
Công thức kiểm thử phần mềm được mô tả ở trên bao gồm tất cả các giai đoạn của vòng đời phát triển phần mềm (Software Development Life Cycle – SDLC). Nó mở rộng từ unit test ở phần đáy tháp, đến test tích hợp ở phần giữa và kết thúc với test chức năng ở đỉnh.
Unit testing là gì?
Kiểm thử đơn vị 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 tính logic của tất cả thành phần để xác định sớm các lỗi trong SDLC, cho phép bạn sửa lỗi trước khi làm tiếp các bước tiếp theo.
Kiểm thử đơn vị được gọi là kiểm thử “hộp trắng”, 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.
const mocha = require('mocha')
const chai = require('chai') // It is an assertion library
describe('Test to check add function', function(){
it('should add two numbers', function(){
(add(2,3)).should.equal(5) //Checking that 2+3 should equal 5 using the given add function
});
});Integration testing là gì?
Bước tiếp sau kiểm thử đơn vị là kiểm tra tích hợp, kết hợp các thành phần riêng lẻ và kiểm tra chúng theo 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 module hoặc thành phần trước khi kiểm thử.
Điểm 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 module hoặc thành phần được tích hợp. Như một ví dụ đơn giản hơn, nếu bạn thực hiện kiểm tra tích hợp của 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,…
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.
End-to-end Testing – kiểm thử đầu cuối
Việc cuối cùng của testing là kiểm tra end-to-end (E2E). Đúng như tên gọi của nó, kiểm tra 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. Điều này 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 tra E2E bằng cách sử dụng một số chỉ số, bao gồm Trạng thái kiểm tra (được theo dõi bằng hình ảnh, chẳng hạn như biểu đồ) và 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
Kiểm tra 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. Kiểm tra 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ó một loạt các bài kiểm tra bảo mật ứng dụng có sẵn 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.
Static Application Security Testing (SAST) – Kiểm tra bảo mật ứng dụng tĩnh
Bạn nên sử dụng thử nghiệm bảo mật ứng dụng tĩnh (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. 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ự triển khai code.
Theo định nghĩa của các nhà phân tích bảo mật tại Cloud Defense:
“SAST kiểm tra code 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à đích… sau đó bạn sẽ nhận được thông báo nếu các phụ thuộc dự án của bạn bị ảnh hưởng bởi các lỗ hổng mới được tiết lộ.”
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.
Dynamic Application Security Testing (DAST) – Kiểm tra bảo mật ứng dụng động
Một phần khác là kiểm tra bảo mật ứng dụng động (DAST), kiểm tra ứng dụng được biên dịch đầy đủ. Bạn thiết kế và chạy các bài kiểm tra này mà không có bất kỳ kiến thức nào về cấu trúc hoặc code cơ bản.
Bởi vì DAST áp dụng quan điểm của tin tặc, nó được gọi là hộp đen, hoặc bên ngoài trong, thử nghiệm. DAST hoạt động bằng cách tấn công nhữ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ư kịch bản trang web chéo và chèn SQL.
DAST được sử dụng muộn trong SDLC và là một ví dụ về thử nghiệm bảo mật tích hợp. 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.
Interactive Application Security Testing – Kiểm tra bảo mật ứng dụng tương tác
Kiểm tra bảo mật ứng dụng tương tác (IAST) là một phương pháp kiểm tra 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 nhiều hơn 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. 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 tra SDLC sớm.
Bất kể loại phần mềm bạn đang muốn kiểm tra là gì, IAST được sử dụng tốt nhất trong môi trường QA (Đảm bảo chất lượng) hoặc môi trường được thiết kế để tái tạo sản xuất càng gần càng tốt mà không cần khách hàng hoặc khách hàng của bạn thực sự truy cập vào nó.
Compatibility Testing – Kiểm tra khả năng tương thích
Kiểm tra khả năng tương thích đá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 phần mềm khác hay không. Thử nghiệm phiên bản có thể quay ngược trở lại hoặc quay về phía trước.
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 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)
- 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ự làm như vậy).
Một số cách thức kiểm thử khác
Performance Testing – Kiểm tra hiệu suất phần mềm
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. Kiểm tra hiệu suất có thể mô hình hóa vấn đề loading và hiệu suất 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ốc độ loading, xác định khả năng load tối đa được áp dụng cho hệ thống tại thời điểm xảy ra sự cố.
Mặt khá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 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 phát trực tiếp.
Usability Testing – Kiểm tra khả năng phần mềm
Kiểm tra thực tế sử dụng giao diện ứng dụng là một nhiệm vụ quan trọng. Đó là một điều cần hiểu nếu ứng dụng hoạt động như thiết kế. Đó là một điều khác để hiểu xem bản thân thiết kế có được người dùng chấp nhận hay không. Đây là lúc thử nghiệm khả năng sử dụng được đưa vào.
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ủa ứng dụng cụ thể. Điều này bao gồm các tính năng mà bạn có thể biết trước sẽ ít được mong muốn hơn từ góc độ người dùng nhưng cần thiết để bảo mật mạnh mẽ và hoạt động thích hợp (như yêu cầu mật khẩu mạnh).
Kiểm tra khả năng sử dụng không phải là 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 đã hoàn thành dễ dàng như thế nào.
Phỏng dịch theo bài viết gốc được đăng tải tại freecodecamp.org
Có thể bạn quan tâm:
- 7 lãng phí trong kiểm thử phần mềm
- Từ vựng kiểm thử phần mềm
- Sử dụng bảng quyết định trong kiểm thử phần mềm
Xem thêm Việc làm Developer hấp dẫn trên TopDev
