日本語
EnglishCÁC LOẠI KIỂM THỬ
Các loại kiểm thử thay đổi tùy theo mục đích và không chỉ đánh giá chất lượng chức năng (mức độ hoàn thiện, mức độ chính xác, v.v.) mà còn đánh giá cả chất lượng phi chức năng (mức độ tin cậy, tính dễ sử dụng, v.v.). Ngoài ra, kiểm thử còn được thực hiện để kiểm tra cấu trúc hệ thống, xác nhận phạm vi ảnh hưởng từ các đối ứng sửa lỗi hoặc cập nhật tính năng. Bài viết này sẽ giải thích những khái niệm cơ bản liên quan đến các loại kiểm thử.
1/ Kiểm thử chức năng
“Chức năng” ở đây chỉ “làm gì (what)”, không phải “cách thức hoạt động như thế nào (how)”. Mục tiêu của kiểm thử chức năng là xác minh rằng các chức năng đã được triển khai đúng theo yêu cầu và đặc tả kỹ thuật.
Cấp độ kiểm thử
Kiểm thử chức năng có thể được thực hiện với nhiều đối tượng khác nhau, bao gồm toàn bộ hệ thống hoặc hệ thống con được tích hợp từ nhiều thành phần. Kiểm thử chức năng được thực hiện với nhiều cấp độ kiểm thử. Nếu kiểm thử dựa trên đặc tả của thành phần, thì đây sẽ là kiểm thử chức năng ở cấp độ thành phần; còn nếu kiểm thử dựa trên đặc tả của hệ thống (chức năng cung cấp cho người dùng) thì sẽ là kiểm thử chức năng ở cấp độ hệ thống.
Có thể nói, tùy thuộc vào cấp độ kiểm thử mà loại kiểm thử cần được chú trọng sẽ khác nhau. Chẳng hạn ở cấp độ kiểm thử thành phần, kiểm thử chức năng thường được chú trọng, trong khi ở cấp độ kiểm thử hệ thống, kiểm thử phi chức năng lại được chú trọng hơn.
Kỹ thuật kiểm thử
Kiểm thử chức năng sử dụng Kiểm thử hộp đen để đánh giá động thái và cử động bên ngoài của phần mềm. Phương pháp này bao gồm kỹ thuật Phân vùng tương đương, Phân tích giá trị biên, Kiểm thử bảng quyết định, Kiểm thử chuyển trạng thái, Kiểm thử trường hợp sử dụng, và nhiều kỹ thuật khác.
Độ bao phủ kiểm thử (test coverage)
Độ bao phủ của kiểm thử chức năng được đánh giá bằng mức độ bao phủ các chức năng trong hệ thống. Chỉ số này thể hiện tỷ lệ các chức năng đã được kiểm thử so với tổng thể. Độ bao phủ của kiểm thử chức năng ở cấp độ hệ thống được biểu thị bằng tỷ lệ các yêu cầu chức năng đã thực hiện.
Vấn đề về nghiệp vụ khi phát triển phần mềm
Lấy ví dụ từ việc khảo sát dầu mỏ, các dữ liệu đo lường được sử dụng để suy đoán khả năng tồn tại của dầu trong lòng đất. Kết quả của sự suy đoán này được gọi là mô hình địa chất, và để phát triển phần mềm tạo ra mô hình địa chất này cần có kiến thức về cơ chế kinh doanh trong ngành thăm dò dầu mỏ và phát triển mỏ dầu.
Vai trò của phần mềm
Ví dụ, trong các trò chơi điện tử tương tác, máy tính đảm nhận vai trò của một trò chơi bàn cờ mà thông thường con người chơi với nhau, cho phép dù chỉ một người cũng có thể chơi. Hơn nữa, máy tính còn có thể giao tiếp với người chơi và phản hồi, và vì cuộc trò chuyện này có thể ảnh hưởng đến tiến độ của trò chơi nên cần phải có các phản hồi phù hợp. Do đó, khi tiến hành kiểm thử, việc hiểu rõ kịch bản của trò chơi và nội dung trò chuyện thích hợp để người chơi có thể thưởng thức trò chơi là rất quan trọng.
2/ Kiểm thử phi chức năng
“Phi chức năng” đề cập đến các yếu tố ngoài “chức năng”. Nói cách khác, phi chức năng liên quan đến “cách thức hoạt động như thế nào (how)” thay vì “làm gì (what)”. Mục đích của kiểm thử phi chức năng là đánh giá các đặc tính của các thành phần hoặc hệ thống, chẳng hạn như hiệu suất, tính dễ sử dụng, bảo mật và các thuộc tính chất lượng khác.
Ví dụ về các loại kiểm thử
Kiểm thử phi chức năng bao gồm nhiều loại kiểm thử khác nhau. Ví dụ như kiểm thử hiệu suất (performance test), kiểm thử tải (load test), kiểm thử căng thẳng (stress test), kiểm thử khả năng sử dụng (usability test), kiểm thử khả năng tương tác (interoperability test), kiểm thử tính bảo trì (maintainability test), kiểm thử độ tin cậy (reliability test), kiểm thử tính di động (portability test) và nhiều loại kiểm thử khác.
Kiểm thử hiệu suất (performance test)
Đây là kiểm thử để đánh giá hiệu suất của phần mềm.
Kiểm thử tải (load test)
Đây là một loại kiểm thử hiệu suất, đánh giá cách các thành phần hoặc hệ thống hoạt động dưới các tình huống tải khác nhau. Thông thường, kiểm thử được thực hiện dựa trên các mức tải dự kiến, bao gồm tải tối thiểu, tải bình thường và tải tối đa.
Kiểm thử căng thẳng (stress test)
Đây một loại kiểm thử hiệu suất, đánh giá cách hệ thống hoặc thành phần hoạt động khi chịu tải vượt quá mức dự kiến, hoặc khi thiếu tài nguyên như bộ nhớ và máy chủ.
Kiểm thử khả năng sử dụng (usability test)
Đây là loại kiểm thử được thực hiện để đo lường tính hiệu quả, hiệu suất và sự hài lòng của người dùng khi sử dụng hệ thống trong các tình huống cụ thể.
Kiểm thử khả năng tương tác (interoperability test)
Đây là loại kiểm thử được thực hiện để xác nhận xem các thành phần hoặc hệ thống khác nhau có thể trao đổi thông tin và tương tác lẫn nhau hay không.
Kiểm thử tính bảo trì (maintainability test)
Đây là loại kiểm thử được thực hiện để đo lường mức độ dễ dàng mà phần mềm có thể được sửa chữa hoặc thay đổi bởi những người bảo trì được chỉ định.
Kiểm thử độ tin cậy (reliability test)
Đây là loại kiểm thử được thực hiện để xác nhận xem các thành phần hoặc hệ thống có thể thực thi các chức năng yêu cầu một cách ổn định dưới các điều kiện đã định hay không.
Kiểm thử tính di động (portability test)
Đây là kiểm thử được thực hiện để đánh giá xem phần mềm có thể chuyển giao một cách mượt mà giữa các môi trường khác nhau hay không. Các môi trường ở đây bao gồm sự khác biệt về phần cứng, phần mềm hoặc tổ chức.
Kiểm thử bảo mật (security test)
Đây là kiểm thử được thực hiện để xác nhận xem hệ thống và dữ liệu có được bảo vệ đúng cách trong phạm vi quyền hạn được phép và việc truy cập vào dữ liệu có được kiểm soát một cách thích hợp hay không.
Phương pháp kiểm thử
Trong kiểm tra phi chức năng, các kỹ thuật kiểm thử hộp đen có thể được áp dụng. Ví dụ, khi thiết lập các điều kiện căng thẳng (stress condition) trong kiểm tra hiệu suất, phương pháp Phân tích giá trị biên có thể được sử dụng.
Độ bao phủ kiểm thử
Độ bao phủ trong kiểm tra phi chức năng được đánh giá dựa trên mức độ bao quát các yếu tố phi chức năng. Ví dụ, khi thực hiện kiểm tra phi chức năng cho ứng dụng di động, như kiểm tra tính tương thích của thiết bị, độ bao phủ được đo lường bằng tỷ lệ các thiết bị đã được thử nghiệm so với tổng số thiết bị được định nghĩa.
Kiến thức đặc thù của người dùng
Ví dụ, trong hệ thống hồ sơ y tế điện tử được sử dụng tại các cơ sở y tế, cần quản lý an toàn thông tin cá nhân của bệnh nhân. Khi nhiều y tá và bác sĩ sử dụng, cần đảm bảo cơ chế ngăn chặn việc truy cập trái phép vào thông tin cá nhân. Do đó, việc kiểm tra dựa trên tình huống sử dụng và thời điểm cụ thể là rất cần thiết.
3/ Kiểm thử hộp trắng (white box test)
Kiểm thử hộp trắng là phương pháp kiểm thử thiết kế các trường hợp kiểm thử dựa trên cấu trúc nội bộ hoặc cách triển khai của hệ thống. Mục đích của kiểm thử này là đảm bảo rằng cấu trúc của các thành phần hoặc hệ thống là chính xác, đầy đủ và tuân thủ theo các đặc tả đã định.
Kỹ thuật kiểm thử
Kiểm thử hộp trắng là phương pháp kiểm thử nhằm xác định mức độ bao phủ của cấu trúc phần mềm thông qua các trường hợp kiểm thử. Để thực hiện điều này, các kỹ thuật thuộc nhóm kiểm thử hộp trắng được áp dụng.
Độ bao phủ kiểm thử
Độ bao phủ của kiểm thử hộp trắng được đánh giá dựa trên mức độ bao quát của các yếu tố cấu trúc (còn gọi là độ bao phủ cấu trúc). Trong kiểm thử thành phần hoặc kiểm thử tích hợp thành phần, các công cụ được sử dụng để đo lường độ bao phủ của mã nguồn. Ngược lại, trong kiểm thử hệ thống hoặc kiểm thử chấp nhận, độ bao phủ thường được đo lường dựa trên cấu trúc menu hoặc mô hình kinh doanh.
Ví dụ về kiểm thử thành phần
Trong kiểm thử thành phần, chỉ số độ bao phủ mã nguồn được sử dụng làm tiêu chí đánh giá. Chỉ số này đo lường mức độ bao quát kiểm thử dựa trên tỷ lệ các câu lệnh trong thành phần được thực thi.
Ví dụ về kiểm thử tích hợp thành phần
Trong kiểm thử tích hợp thành phần, các giao diện giữa các thành phần được coi là yếu tố cấu trúc. Độ bao phủ được đo lường dựa trên tỷ lệ các giao diện đã được kiểm thử so với tổng số giao diện.
Kiến thức cần thiết
Việc thiết kế và thực hiện kiểm thử hộp trắng yêu cầu một số kỹ năng chuyên môn và kiến thức nhất định, bao gồm:
・Cách xây dựng mã nguồn: Ví dụ, khi sử dụng công cụ đo độ bao phủ mã nguồn, cần nắm rõ cấu trúc các tệp mã nguồn và quy trình xây dựng (build) mã.
・Cách lưu trữ dữ liệu: Hiểu rõ cách bố trí lược đồ vật lý, từ đó có thể đánh giá được các truy vấn cơ sở dữ liệu có thể thực hiện.
・Sử dụng công cụ đo độ bao phủ và phân tích kết quả: Cần biết cách sử dụng công cụ một cách phù hợp và có kỹ năng để giải thích chính xác kết quả được tạo ra.
4/ Kiểm thử phần thay đổi
Đây là loại kiểm thử theo góc nhìn khác so với trước đây. Khi tiến hành kiểm thử và phát hiện lỗi, cần thực hiện kiểm thử lại sau khi đã sửa lỗi. Tương tự, khi thêm hoặc thay đổi chức năng dẫn đến việc hệ thống được cập nhật, cần tiến hành lại các kiểm thử trước đó. Mục tiêu chính của kiểm thử này như dưới đây:
・Đảm bảo lỗi đã được sửa chữa triệt để.
・Xác nhận các chức năng hoạt động chính xác.
・Kiểm tra xem có ảnh hưởng ngoài dự kiến hay không.
Trong các mô hình Phát triển lặp lại (Iterative Development) hoặc Phát triển tăng dần (Incremental Development) (trong mô hình Agile), việc thêm mới, chỉnh sửa chức năng hoặc tái cấu trúc mã nguồn (refactoring) diễn ra thường xuyên, khiến kiểm thử các phần thay đổi trở thành một yếu tố không thể thiếu. Ngoài ra, với các hệ thống IoT (Internet of Things), nơi thiết bị thường xuyên được cập nhật hoặc thay thế, kiểm thử này cũng đặc biệt quan trọng.
Kiểm thử phần thay đổi có hai loại chính như sau:
- Kiểm thử xác nhận (Confirmation Test): Kiểm tra xem lỗi đã được đúng hay chưa.
- Kiểm thử hồi quy (Regression Test): Kiểm tra xem có lỗi mới phát sinh hay không và đảm bảo rằng không có ảnh hưởng không mong muốn nào xảy ra.
Vì hệ thống luôn trong quá trình phát triển và thay đổi, cả Kiểm thử xác nhận và Kiểm thử hồi quy đều là những kiểm thử vô cùng quan trọng không thể thiếu.
Kiểm thử xác nhận (Confirmation Test)
Kiểm thử xác nhận là loại kiểm thử được thực hiện sau khi sửa lỗi, nhằm đảm bảo rằng sự cố do lỗi đó gây ra không còn tái diễn.
Trong kiểm thử xác nhận, phần code đã được sửa sẽ được chạy lại để xác nhận rằng lỗi đã được sửa. Trong một số trường hợp, các trường hợp kiểm thử mới có thể được thêm vào và thực hiện. Tuy nhiên, cần lưu ý không nhầm lẫn kiểm thử xác nhận với quá trình gỡ lỗi (debugging) trong hoạt động phát triển.
Kiểm thử hồi quy (Regression Test)
Kiểm thử hồi quy là một loại kiểm thử được thực hiện lặp lại trên phần mềm đã được kiểm tra trước đó. Mục đích của kiểm thử hồi quy là phát hiện các lỗi mới hoặc các vấn đề phát sinh do sửa lỗi, hoặc các ảnh hưởng không mong muốn phát sinh từ thay đổi đó.
Lỗi không chỉ có thể ảnh hưởng đến các thành phần đã sửa mà còn có thể ảnh hưởng đến các thành phần liên quan khác. Vì vậy, trong kiểm thử hồi quy, việc thiết lập phạm vi kiểm thử là rất quan trọng. Quyết định phạm vi kiểm thử cần xem xét rủi ro của phần mềm khi có lỗi trong các thành phần đã hoạt động (rủi ro sản phẩm).
Ngoài ra, nếu môi trường vận hành của phần mềm thay đổi, hoặc khi chuyển sang hệ điều hành mới hoặc hệ quản trị cơ sở dữ liệu khác, kiểm thử hồi quy cũng cần được thực hiện. Để có thể nhanh chóng thực hiện kiểm thử bất kỳ lúc nào, việc chuẩn bị một bộ kiểm thử phù hợp là điều cần thiết.
Kiểm thử bảo trì
Sau khi phát triển phần mềm hoặc hệ thống hoàn tất và được phát hành hoặc triển khai vào môi trường sản xuất, việc bảo trì là cần thiết. Phần mềm và hệ thống có thể được sử dụng trong một khoảng thời gian dài, từ vài năm đến thậm chí vài chục năm, trong suốt thời gian đó, các tính năng có thể được thêm mới, thay đổi, hoặc xóa bỏ. Ngoài ra, cần có các sửa đổi để thích ứng với sự thay đổi của môi trường hoạt động. Mặc dù đã thực hiện kiểm thử kỹ lưỡng trong quá trình phát triển, nhưng vẫn có thể phát hiện lỗi sau khi phát hành, và việc sửa chữa chúng cũng sẽ được yêu cầu. Do đó, trong suốt thời gian bảo trì, sẽ có rất nhiều thay đổi diễn ra.
Kiểm thử bảo trì (Maintenance Test) được thực hiện để đối ứng với những thay đổi này. Mục đích chính của kiểm thử bảo trì là:
・Xác nhận rằng các thay đổi đã được phản ánh đúng.
・Kiểm tra rằng không có ảnh hưởng không mong muốn (regression) đối với các phần không thay đổi của hệ thống.
Trong suốt thời gian bảo trì, phần mềm sẽ trải qua nhiều lần cập nhật phiên bản hoặc bản sửa lỗi. Điều này bao gồm cả các bản phát hành có kế hoạch thêm tính năng và các bản phát hành khẩn cấp để sửa lỗi. Kiểm thử bảo trì là không thể thiếu trong tất cả các lần phát hành này.
Trong kiểm thử bảo trì, không chỉ kiểm thử chức năng mà cả kiểm thử phi chức năng cũng cần được thực hiện. Ví dụ, khi có thay đổi để cải thiện hiệu suất, ngoài việc thực hiện kiểm thử hiệu suất, điều quan trọng là phải xác nhận rằng các thay đổi không làm giảm hiệu suất của hệ thống. Mặc dù không cần thực hiện tất cả các loại kiểm thử trong mọi trường hợp, nhưng cần phải cân nhắc các đặc tính chất lượng nào có thể bị ảnh hưởng và chọn loại kiểm thử phù hợp.
Ngoài ra, việc kết hợp nhiều cấp độ kiểm thử cũng là điều cần thiết. Dù chỉ sửa đổi một phần nhỏ của mã nguồn, nhưng vẫn cần phải thực hiện kiểm thử thành phần (component testing), kiểm thử tích hợp (integration testing) để xác nhận giao diện của mã nguồn sửa đổi với các mã nguồn khác, và kiểm thử hệ thống (system testing) để đảm bảo toàn bộ hệ thống hoạt động đúng. Đánh giá phạm vi ảnh hưởng của thay đổi và xác định cấp độ kiểm thử cần thiết là rất quan trọng.
Dưới đây là các yếu tố chính khi xác định phạm vi kiểm thử trong kiểm thử bảo trì:
・Mức độ rủi ro của thay đổi: Nếu phần thay đổi có nhiều tham chiếu hoặc nối kết dữ liệu với các thành phần hoặc hệ thống khác, yêu cầu kiểm thử sẽ cao hơn.
・Quy mô của hệ thống hiện tại: Hệ thống càng lớn, phạm vi kiểm thử có thể càng rộng.
・Quy mô của sự thay đổi: Nếu phạm vi sửa đổi rộng, nội dung kiểm thử sẽ nhiều hơn.
Các trường hợp cần kiểm thử bảo trì
Khi có sự thay đổi phần mềm
Khi phần mềm được thay đổi, chẳng hạn như mở rộng tính năng, thay đổi yêu cầu hoặc sửa lỗi, cần kiểm tra xem các thay đổi này có được phản ánh chính xác hay không.
Khi có thay đổi trong môi trường vận hành
Nếu phần mềm không thay đổi nhưng có thay đổi về hệ điều hành, cơ sở dữ liệu, phần mềm thương mại (COTS) như nâng cấp phiên bản hoặc áp dụng bản vá, cần kiểm tra hoạt động của phần mềm trong môi trường mới.
Khi chuyển đổi sang môi trường mới
Khi chuyển phần mềm sang nền tảng khác, cần kiểm tra xem phần mềm có hoạt động chính xác trong môi trường mới không. Nếu di chuyển dữ liệu từ các ứng dụng khác, cần kiểm tra việc chuyển đổi dữ liệu có chính xác hay không.
Khi phần mềm bị loại bỏ
Khi ngừng sử dụng phần mềm, nếu cần lưu trữ dữ liệu đã sử dụng, phải kiểm tra quá trình chuyển dữ liệu và lưu trữ. Cũng cần kiểm tra rằng dữ liệu được liệt kê chính xác và có thể truy xuất khi cần thiết.
Trong các hệ thống IoT, nơi nhiều phần mềm, thiết bị và dịch vụ tương tác với nhau, kiểm thử bảo trì trở nên rất quan trọng và phức tạp. Khi thay đổi hoặc thêm mới thiết bị và phần mềm trong hệ thống hiện có, cần thực hiện kiểm thử tích hợp để đảm bảo mọi thứ hoạt động liền mạch. Hơn nữa, nếu hệ thống xử lý dữ liệu cá nhân, cần phải kiểm tra nghiêm ngặt để đảm bảo không có vi phạm hoặc rò rỉ dữ liệu khi các yếu tố mới được tích hợp vào hệ thống.
Phân tích phạm vi ảnh hưởng khi bảo trì
Khi thực hiện các công việc bảo trì đã được đề cập ở phần trước và phát hành phần mềm hoặc hệ thống, cần phải điều tra ảnh hưởng của từng xử lý (cập nhật, thêm mới, xóa, v.v.) có thể phát sinh. Quá trình khảo sát này được gọi là “phân tích phạm vi ảnh hưởng”. Hai vấn đề đặc biệt khó khăn trong phân tích phạm vi ảnh hưởng chính là:
・Tác dụng phụ do thay đổi (Regression)
・Xác định các vùng trong hệ thống bị ảnh hưởng bởi thay đổi
Ảnh hưởng có thể phát sinh ở những vùng không lường trước được, và trong trường hợp đó, nếu không thực hiện kiểm tra hồi quy (regression test), có thể sẽ xảy ra lỗi sau khi phát hành. Vì vậy, việc thực hiện kiểm thử hồi quy đối với phạm vi ảnh hưởng từ thay đổi là cực kỳ quan trọng.
Trong kiểm thử hồi quy, đôi khi chỉ cần thực hiện lại các trường hợp kiểm thử hiện có liên quan đến phạm vi bị ảnh hưởng. Tuy nhiên, tùy thuộc vào nội dung thay đổi, có thể cần phải sửa đổi các trường hợp kiểm thử hiện có hoặc thêm mới trường hợp kiểm thử. Ví dụ, nếu tiến hành thêm đối số mới cho một hàm, các trường hợp kiểm thử hiện có chỉ bao gồm các giá trị đầu vào cho các đối số cũ, do đó cần phải thiết lập giá trị đầu vào phù hợp cho đối số mới. Ngoài ra, nếu đang thực hiện tự động hóa kiểm thử, có thể cần sửa đổi các kịch bản kiểm thử tự động. Để thực hiện kiểm thử hồi quy hiệu quả, điều quan trọng là phải ước lượng chính xác công việc bảo trì trước khi thực hiện.
Mặc dù có thể thực hiện phân tích phạm vi ảnh hưởng sau khi thay đổi, nhưng nếu thực hiện phân tích trước khi thay đổi thì cũng sẽ ước lượng được khối lượng công việc và lập kế hoạch công việc cần thiết. Ngoài ra, việc xác định được mức độ và phạm vi của ảnh hưởng cũng có thể giúp lập trình viên cân nhắc lại phương pháp đối ứng sao cho giảm thiểu được phạm vi ảnh hưởng, điều này giúp công việc trở nên hiệu quả hơn.
Để thực hiện phân tích phạm vi ảnh hưởng một cách hiệu quả và chính xác, điều quan trọng là phải thiết lập khả năng truy vết giữa các mục phần mềm cần kiểm tra và các phần mềm kiểm tra. Thêm vào đó, cần nâng cao khả năng bảo trì của phần mềm cần kiểm tra. Thông thường, việc duy trì độ kết dính cao giữa các module và giảm độ kết nối giữa chúng, hợp nhất các đoạn mã lặp lại, và thực hiện tái cấu trúc mã (refactoring) để giữ cho cấu trúc mã sạch sẽ là điều được khuyến khích.
Nếu không thực hiện các biện pháp này, cần lưu ý rằng việc phân tích phạm vi ảnh hưởng sẽ gặp khó khăn trong các trường hợp sau:
・Đặc tả không được cập nhật hoặc không tồn tại
・Các trường hợp kiểm thử không được tài liệu hóa hoặc không phải phiên bản mới nhất
・Không có khả năng truy vết hai chiều giữa các trường hợp kiểm thử và tài liệu thiết kế
・Công cụ hỗ trợ phân tích phạm vi ảnh hưởng không đầy đủ hoặc không tồn tại
・Không có nhân sự có kiến thức về domain hoặc hệ thống
・Không cân nhắc khả năng bảo trì phần mềm khi phát triển
※Bài test kiểm tra độ hiểu: