[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"_public_topic_publications_ki%E1%BB%83m%20th%E1%BB%AD%20ph%E1%BA%A7n%20m%E1%BB%81m{\"limit\":5}":3,"_public_topic_byId_kiểm thử phần mềm":11},{"code":4,"data":5,"meta":10},"SUCCESS",{"latest":6,"mostCited":7,"vietnamFeatured":8,"vietnamLatest":9},[],[],[],[],null,{"code":4,"data":12,"meta":10},{"id":13,"title":14,"description":15,"content":16,"term":13,"englishTitle":17,"synonyms":18,"definition":20,"discipline":21,"references":22,"faqs":71,"createUser":81,"publishUser":85,"keywords":89,"keywordCount":86,"enrichTopicLink":90,"status":91,"createTime":92,"updateTime":93,"publishTime":94,"linkEnrichedTime":10,"publicationScanTime":10,"contentErrorMessage":10,"viewCount":95,"relateTopics":96},"kiểm thử phần mềm","Kiểm thử phần mềm là gì? Các kỹ thuật và nguyên lý cốt lõi","Kiểm thử phần mềm là quy trình đánh giá kỹ thuật nhằm phát hiện khiếm khuyết. Tìm hiểu kiểm thử hộp trắng, hộp đen, đột biến và thực thi ký hiệu.","\u003Cp>Kiểm thử phần mềm (software testing) là quá trình khảo sát và đánh giá kỹ thuật một hệ thống hoặc thành phần phần mềm nhằm xác định mức độ đáp ứng các yêu cầu thiết kế đã định và phát hiện các khiếm khuyết tiềm ẩn. Hoạt động này cung cấp cho các bên liên quan thông tin khách quan về chất lượng sản phẩm và rủi ro vận hành trước khi triển khai vào môi trường thực tế. Bài viết này trình bày toàn diện các nguyên lý cốt lõi, mô hình phân cấp kiểm thử, các kỹ thuật hộp đen và hộp trắng, kiểm thử hồi quy, kiểm thử đột biến, kỹ thuật thực thi ký hiệu và các phương pháp sinh ca kiểm thử tự động dựa trên tìm kiếm.\u003C\u002Fp>\n\n\u003Ch2>Bản chất và các nguyên lý nền tảng của kiểm thử phần mềm\u003C\u002Fh2>\n\u003Cp>Trong kỹ nghệ phần mềm, kiểm thử đóng vai trò là một trụ cột then chốt thuộc quy trình đảm bảo chất lượng. Khác với hoạt động gỡ lỗi (debugging) vốn tập trung vào việc định vị và khắc phục nguyên nhân gốc rễ của sai sót trong mã nguồn, kiểm thử là quá trình chủ động kích hoạt các tình huống thực thi để làm bộc lộ các lỗi chức năng và phi chức năng. Trong giáo trình kinh điển The Art of Software Testing, Myers và cs. (2011) nhấn mạnh rằng kiểm thử là một quá trình thực thi chương trình với chủ đích tìm ra lỗi, đòi hỏi tư duy phản biện và các kỹ thuật thiết kế ca kiểm thử có phương pháp.\u003C\u002Fp>\n\n\u003Ch3>Nguyên lý giới hạn của kiểm thử\u003C\u002Fh3>\n\u003Cp>Một trong những nguyên lý căn bản nhất được nhà khoa học máy tính Edsger Dijkstra đúc kết: kiểm thử chỉ có thể chứng minh sự hiện diện của lỗi chứ không bao giờ có thể chứng minh phần mềm hoàn toàn không có lỗi. Do không gian trạng thái của phần mềm hiện đại gần như vô hạn, việc kiểm thử vét cạn mọi tổ hợp đầu vào và đường đi thực thi là điều bất khả thi về mặt toán học và kinh tế. Do đó, mục tiêu của kiểm thử là tối đa hóa khả năng phát hiện lỗi nghiêm trọng với nguồn lực hữu hạn thông qua các phương pháp chọn mẫu khoa học.\u003C\u002Fp>\n\n\u003Ch3>Nguyên lý phân cụm lỗi và nghịch lý thuốc trừ sâu\u003C\u002Fh3>\n\u003Cp>Kinh nghiệm thực tiễn và các nghiên cứu thực nghiệm chỉ ra rằng phần lớn các khiếm khuyết thường tập trung vào một số mô-đun phức tạp hoặc có tần suất thay đổi cao của hệ thống. Đồng thời, nếu một bộ ca kiểm thử cố định được lặp đi lặp lại mà không được cập nhật, bộ kiểm thử đó sẽ dần mất đi khả năng phát hiện các lỗi mới, hiện tượng này được gọi là nghịch lý thuốc trừ sâu trong kiểm thử phần mềm.\u003C\u002Fp>\n\n\u003Ch2>Các cấp độ kiểm thử trong vòng đời phát triển phần mềm\u003C\u002Fh2>\n\u003Cp>Để kiểm soát độ phức tạp của hệ thống, quy trình kiểm thử được cấu trúc thành nhiều cấp độ kế tiếp nhau theo mô hình chữ V hoặc các vòng lặp phát triển linh hoạt:\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử đơn vị\u003C\u002Fh3>\n\u003Cp>Kiểm thử đơn vị (unit testing) là cấp độ kiểm thử mức thấp nhất, tập trung kiểm tra các khối mã nguồn nhỏ nhất có thể cô lập được, chẳng hạn như từng hàm, phương thức hoặc lớp đối tượng riêng lẻ. Ở cấp độ này, các phụ thuộc bên ngoài như cơ sở dữ liệu, dịch vụ mạng hoặc hệ điều hành thường được thay thế bằng các đối tượng giả lập nhằm cô lập hoàn toàn logic của đơn vị cần kiểm tra.\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử tích hợp\u003C\u002Fh3>\n\u003Cp>Kiểm thử tích hợp (integration testing) đánh giá giao diện và sự tương tác giữa các mô-đun hoặc dịch vụ khác nhau sau khi đã vượt qua kiểm thử đơn vị. Mục tiêu chính là phát hiện các lỗi phát sinh do sự không tương thích về định dạng dữ liệu truyền nhận, sai lệch giao thức truyền thông, xung đột tài nguyên dùng chung hoặc lỗi xử lý ngoại lệ giữa các thành phần.\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử hệ thống\u003C\u002Fh3>\n\u003Cp>Kiểm thử hệ thống (system testing) đánh giá toàn bộ ứng dụng hoàn chỉnh và tích hợp đầy đủ nhằm xác minh hệ thống có thỏa mãn toàn bộ các yêu cầu chức năng và phi chức năng đã quy định hay không. Cấp độ này bao gồm kiểm thử bảo mật, kiểm thử hiệu năng dưới tải cao, kiểm thử khả năng chịu lỗi và kiểm thử tính tương thích trên các môi trường phần cứng và hệ điều hành khác nhau.\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử chấp nhận\u003C\u002Fh3>\n\u003Cp>Kiểm thử chấp nhận (acceptance testing) là giai đoạn đánh giá cuối cùng do người dùng cuối hoặc khách hàng thực hiện nhằm xác định xem phần mềm đã sẵn sàng để đưa vào vận hành thực tế hay chưa. Cấp độ này bảo đảm hệ thống giải quyết đúng bài toán nghiệp vụ của tổ chức.\u003C\u002Fp>\n\n\u003Ch2>Chiến lược và kỹ thuật thiết kế ca kiểm thử\u003C\u002Fh2>\n\u003Cp>Dựa trên mức độ tiếp cận thông tin về cấu trúc nội bộ của mã nguồn, các kỹ thuật kiểm thử được phân định thành hai nhóm chính:\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử hộp đen\u003C\u002Fh3>\n\u003Cp>Kiểm thử hộp đen (black-box testing) tiếp cận phần mềm hoàn toàn từ bên ngoài, chỉ dựa trên tài liệu đặc tả yêu cầu mà không cần biết đến cấu trúc mã lệnh bên trong. Hai kỹ thuật nền tảng của kiểm thử hộp đen bao gồm:\u003C\u002Fp>\n\u003Cp>Phân vùng tương đương (equivalence partitioning) chia toàn bộ miền giá trị đầu vào thành các lớp tương đương, trong đó các giá trị trong cùng một lớp được giả định sẽ kích hoạt cùng một hành vi của chương trình, từ đó chỉ cần chọn một phần tử đại diện cho mỗi lớp.\u003C\u002Fp>\n\u003Cp>Phân tích giá trị biên (boundary value analysis) tập trung kiểm tra các giá trị nằm ngay tại biên hoặc lân cận sát biên của các phân vùng tương đương, bởi vì sai sót lập trình thường có xác suất xuất hiện cao nhất tại các điểm chuyển tiếp điều kiện.\u003C\u002Fp>\n\n\u003Ch3>Kiểm thử hộp trắng\u003C\u002Fh3>\n\u003Cp>Kiểm thử hộp trắng (white-box testing) sử dụng cấu trúc điều khiển và luồng dữ liệu bên trong mã nguồn để thiết kế ca kiểm thử. Kỹ thuật này đo lường chất lượng kiểm thử thông qua các tiêu chí độ bao phủ mã:\u003C\u002Fp>\n\u003Cp>Độ bao phủ câu lệnh (statement coverage) đo lường tỷ lệ phần trăm các dòng lệnh mã nguồn được thực thi ít nhất một lần bởi bộ kiểm thử.\u003C\u002Fp>\n\u003Cp>Độ bao phủ nhánh (branch coverage) yêu cầu mọi nhánh rẽ tại các câu lệnh điều kiện (nhánh đúng và nhánh sai) đều phải được thực thi.\u003C\u002Fp>\n\u003Cp>Độ bao phủ điều kiện sửa đổi và quyết định (modified condition and decision coverage) đòi hỏi mỗi điều kiện đơn lẻ trong một biểu thức logic phức tạp phải chứng minh được khả năng độc lập làm thay đổi kết quả của toàn bộ quyết định, đây là tiêu chuẩn bắt buộc đối với các hệ thống nhúng đòi hỏi độ an toàn sinh mệnh cao.\u003C\u002Fp>\n\n\u003Ch2>Bảng so sánh các phương pháp kiểm thử phần mềm\u003C\u002Fh2>\n\u003Cp>Dưới đây là bảng đối chiếu tổng hợp các đặc tính kỹ thuật cốt lõi của các phương pháp và cấp độ kiểm thử phổ biến:\u003C\u002Fp>\n\n\u003Ctable>\n    \u003Cthead>\n        \u003Ctr>\n            \u003Cth>Cấp độ và phương pháp\u003C\u002Fth>\n            \u003Cth>Đối tượng kiểm tra\u003C\u002Fth>\n            \u003Cth>Mục tiêu chính\u003C\u002Fth>\n            \u003Cth>Mức độ tiếp cận mã\u003C\u002Fth>\n            \u003Cth>Kỹ thuật chủ đạo\u003C\u002Fth>\n        \u003C\u002Ftr>\n    \u003C\u002Fthead>\n    \u003Ctbody>\n        \u003Ctr>\n            \u003Ctd>\u003Cstrong>Kiểm thử đơn vị\u003C\u002Fstrong>\u003C\u002Ftd>\n            \u003Ctd>Hàm, phương thức, lớp đối tượng\u003C\u002Ftd>\n            \u003Ctd>Xác minh tính đúng đắn logic cục bộ\u003C\u002Ftd>\n            \u003Ctd>Hộp trắng toàn phần\u003C\u002Ftd>\n            \u003Ctd>Bao phủ nhánh, kiểm thử cô lập với đối tượng giả\u003C\u002Ftd>\n        \u003C\u002Ftr>\n        \u003Ctr>\n            \u003Ctd>\u003Cstrong>Kiểm thử tích hợp\u003C\u002Fstrong>\u003C\u002Ftd>\n            \u003Ctd>Giao diện giữa các mô-đun\u003C\u002Ftd>\n            \u003Ctd>Phát hiện xung đột dữ liệu và giao thức\u003C\u002Ftd>\n            \u003Ctd>Hộp xám hoặc hộp đen\u003C\u002Ftd>\n            \u003Ctd>Tích hợp từ dưới lên hoặc từ trên xuống\u003C\u002Ftd>\n        \u003C\u002Ftr>\n        \u003Ctr>\n            \u003Ctd>\u003Cstrong>Kiểm thử hệ thống\u003C\u002Fstrong>\u003C\u002Ftd>\n            \u003Ctd>Toàn bộ ứng dụng hoàn chỉnh\u003C\u002Ftd>\n            \u003Ctd>Kiểm tra chức năng và phi chức năng\u003C\u002Ftd>\n            \u003Ctd>Hộp đen\u003C\u002Ftd>\n            \u003Ctd>Kiểm thử tải, kiểm thử bảo mật, kiểm thử phục hồi\u003C\u002Ftd>\n        \u003C\u002Ftr>\n        \u003Ctr>\n            \u003Ctd>\u003Cstrong>Kiểm thử chấp nhận\u003C\u002Fstrong>\u003C\u002Ftd>\n            \u003Ctd>Kịch bản nghiệp vụ người dùng\u003C\u002Ftd>\n            \u003Ctd>Xác nhận sẵn sàng triển khai thực tế\u003C\u002Ftd>\n            \u003Ctd>Hộp đen\u003C\u002Ftd>\n            \u003Ctd>Kiểm thử người dùng, thử nghiệm bản alpha và beta\u003C\u002Ftd>\n        \u003C\u002Ftr>\n        \u003Ctr>\n            \u003Ctd>\u003Cstrong>Kiểm thử hồi quy\u003C\u002Fstrong>\u003C\u002Ftd>\n            \u003Ctd>Các chức năng cũ sau sửa đổi\u003C\u002Ftd>\n            \u003Ctd>Đảm bảo không phát sinh lỗi mới\u003C\u002Ftd>\n            \u003Ctd>Hộp trắng hoặc hộp đen\u003C\u002Ftd>\n            \u003Ctd>Chọn lọc ca kiểm thử hồi quy, kiểm thử tự động CI\u002FCD\u003C\u002Ftd>\n        \u003C\u002Ftr>\n    \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch2>Kiểm thử hồi quy và tối ưu hóa bộ kiểm thử\u003C\u002Fh2>\n\u003Cp>Khi phần mềm liên tục được nâng cấp, vá lỗi hoặc tái cấu trúc, việc thực thi lại toàn bộ kho ca kiểm thử tích lũy (retest-all) trở nên vô cùng tốn kém và không khả thi về mặt thời gian. Điều này dẫn đến sự ra đời của các kỹ thuật lựa chọn ca kiểm thử hồi quy (regression test selection).\u003C\u002Fp>\n\n\u003Cp>Nghiên cứu kinh điển của Rothermel và Harrold (1996) trên tạp chí IEEE Transactions on Software Engineering đã thiết lập khung phân tích toàn diện để đánh giá và so sánh các kỹ thuật lựa chọn ca kiểm thử hồi quy. Rothermel và Harrold (1996) phân loại các phương pháp tiếp cận dựa trên các tiêu chí nền tảng: tính bao quát (khả năng lựa chọn mọi ca kiểm thử có thể làm lộ lỗi phát sinh do sửa đổi mã), tính chính xác (khả năng loại bỏ các ca kiểm thử không bị ảnh hưởng bởi sửa đổi), tính hiệu quả (thời gian tính toán cần thiết để chọn ca kiểm thử) và tính khái quát (khả năng áp dụng cho các cấu trúc ngôn ngữ lập trình khác nhau). Công trình này đặt nền móng lý thuyết cho việc tối ưu hóa chu trình kiểm thử trong các hệ thống tích hợp liên tục hiện đại.\u003C\u002Fp>\n\n\u003Ch2>Đánh giá chất lượng bộ kiểm thử bằng kiểm thử đột biến\u003C\u002Fh2>\n\u003Cp>Độ bao phủ mã nguồn truyền thống (như bao phủ câu lệnh hay nhánh) chỉ cho biết mã có được chạy qua hay không, nhưng không bảo đảm rằng bộ kiểm thử có khả năng bắt được lỗi logic nếu lỗi đó xảy ra. Để đánh giá thực chất năng lực phát hiện khiếm khuyết của bộ kiểm thử, kỹ nghệ phần mềm sử dụng kiểm thử đột biến (mutation testing).\u003C\u002Fp>\n\n\u003Cp>Trong nghiên cứu tổng quan hệ thống toàn diện, Jia và Harman (2011) đã phân tích sâu sắc quá trình phát triển của kiểm thử đột biến từ các ý tưởng ban đầu đến các kỹ thuật đương đại. Jia và Harman (2011) giải thích cơ chế đưa các lỗi nhân tạo nhỏ (gọi là đột biến - mutants) vào chương trình gốc thông qua các toán tử đột biến. Một ca kiểm thử được xem là tiêu diệt được đột biến nếu kết quả thực thi của nó trên chương trình đột biến khác biệt so với chương trình gốc. Tỷ lệ đột biến bị tiêu diệt phản ánh trực tiếp chất lượng của bộ kiểm thử. Nghiên cứu của Jia và Harman (2011) cũng hệ thống hóa các giải pháp nhằm vượt qua rào cản chi phí tính toán khổng lồ của kiểm thử đột biến, bao gồm kỹ thuật tối ưu hóa toán tử đột biến và phương pháp đột biến bậc cao.\u003C\u002Fp>\n\n\u003Ch2>Tự động sinh dữ liệu kiểm thử dựa trên tìm kiếm\u003C\u002Fh2>\n\u003Cp>Việc viết ca kiểm thử thủ công chiếm tỷ trọng lớn trong chi phí phát triển phần mềm. Để tự động hóa quy trình này, nhánh nghiên cứu kiểm thử phần mềm dựa trên tìm kiếm (Search-Based Software Testing) đã chuyển hóa bài toán sinh ca kiểm thử thành bài toán tối ưu hóa toán học.\u003C\u002Fp>\n\n\u003Cp>McMinn (2004) đã công bố bài báo tổng quan trên tạp chí Software Testing, Verification and Reliability, khảo sát toàn diện việc ứng dụng các thuật toán tìm kiếm tối ưu hóa siêu phỏng đoán trong tự động sinh dữ liệu kiểm thử. McMinn (2004) phân tích cách thức áp dụng giải thuật di truyền, tìm kiếm leo đồi và mô phỏng luyện kim để định hướng không gian đầu vào của chương trình nhằm thỏa mãn các mục tiêu bao phủ cụ thể. Trọng tâm của phương pháp này là việc xây dựng hàm mục tiêu (fitness function) phản ánh khoảng cách thực thi từ luồng điều khiển hiện tại đến nhánh rẽ mục tiêu cần bao phủ, cung cấp động lực toán học để thuật toán hội tụ về ca kiểm thử hợp lệ.\u003C\u002Fp>\n\n\u003Ch2>Phương pháp tiếp cận sinh toàn bộ bộ kiểm thử\u003C\u002Fh2>\n\u003Cp>Phương pháp sinh ca kiểm thử truyền thống thường tập trung vào từng mục tiêu bao phủ đơn lẻ (target-by-target), dẫn đến tình trạng bộ kiểm thử phình to về số lượng và dễ rơi vào bẫy tối ưu cục bộ khi gặp các nhánh rẽ khó tiếp cận.\u003C\u002Fp>\n\n\u003Cp>Để khắc phục hạn chế này, Fraser và Arcuri (2013) đã đề xuất phương pháp tiếp cận đột phá mang tên sinh toàn bộ bộ kiểm thử (Whole Test Suite Generation), được công bố trên IEEE Transactions on Software Engineering. Thay vì tối ưu hóa từng ca kiểm thử riêng biệt cho từng nhánh, Fraser và Arcuri (2013) sử dụng giải thuật di truyền để tối ưu hóa trực tiếp toàn bộ một tập hợp các ca kiểm thử hướng tới việc cực đại hóa tổng độ bao phủ của toàn bộ chương trình cùng một lúc. Kết quả thực nghiệm của Fraser và Arcuri (2013) chứng minh rằng phương pháp tiếp cận toàn thể này không chỉ đạt được độ bao phủ mã nguồn cao hơn đáng kể mà còn sản sinh ra các bộ kiểm thử có kích thước gọn gàng hơn nhiều so với các kỹ thuật đơn mục tiêu truyền thống.\u003C\u002Fp>\n\n\u003Ch2>Kiểm thử tự động bằng thực thi ký hiệu\u003C\u002Fh2>\n\u003Cp>Bên cạnh các kỹ thuật tối ưu hóa ngẫu nhiên, thực thi ký hiệu (symbolic execution) là phương pháp phân tích chương trình hình thức mạnh mẽ cho phép tự động khám phá các đường đi thực thi phức tạp trong mã nguồn.\u003C\u002Fp>\n\n\u003Cp>Cadar và Sen (2013) đã tổng kết sự tiến hóa của thực thi ký hiệu trên tạp chí Communications of the ACM sau nhiều thập kỷ nghiên cứu và ứng dụng. Cadar và Sen (2013) giải thích cơ chế gán các giá trị ký hiệu thay cho các giá trị cụ thể tại đầu vào của chương trình. Khi bộ thực thi duyệt qua các câu lệnh điều kiện, nó tích lũy các ràng buộc đại số biểu diễn điều kiện để đi theo nhánh rẽ tương ứng. Nhờ sự đột phá về hiệu năng của các bộ giải lý thuyết thỏa mãn mệnh đề hiện đại, kỹ thuật thực thi ký hiệu kết hợp thực thi cụ thể có thể tự động giải các hệ phương trình ràng buộc để sinh ra các đầu vào kích hoạt chính xác những lỗi bảo mật ẩn sâu như tràn bộ đệm hay phân chia cho không. Cadar và Sen (2013) cũng phân tích các thách thức lớn của phương pháp này, đặc biệt là vấn đề bùng nổ không gian đường đi khi chương trình có các vòng lặp phức tạp.\u003C\u002Fp>\n\n\u003Ch2>Xu hướng kiểm thử tự động trong kỷ nguyên mô hình ngôn ngữ lớn\u003C\u002Fh2>\n\u003Cp>Trong nghiên cứu nhìn lại quá trình phát triển công bố trên IEEE Transactions on Software Engineering, Fraser và Arcuri (2025) đã phân tích sự chuyển dịch của các kỹ thuật sinh ca kiểm thử tự động từ giải thuật di truyền sang việc ứng dụng các mô hình ngôn ngữ lớn. Fraser và Arcuri (2025) chỉ ra rằng mặc dù các mô hình ngôn ngữ lớn có khả năng sinh mã kiểm thử dễ đọc và tự nhiên hơn đối với lập trình viên, phương pháp tối ưu hóa dựa trên tìm kiếm vẫn giữ vai trò thiết yếu trong việc bảo đảm độ bao phủ mã nghiêm ngặt và tính đúng đắn logic của dữ liệu kiểm thử. Sự kết hợp giữa năng lực hiểu ngữ cảnh của trí tuệ nhân tạo tạo sinh và độ chính xác toán học của các giải thuật tối ưu hóa đang định hình tương lai của kỹ thuật kiểm thử tự động.\u003C\u002Fp>","software testing",[19],"thử nghiệm phần mềm","Kiểm thử phần mềm (software testing) là quá trình khảo sát và đánh giá kỹ thuật một hệ thống hoặc thành phần phần mềm nhằm xác định mức độ đáp ứng các yêu cầu thiết kế đã định và phát hiện các khiếm khuyết tiềm ẩn.","ENGINEERING_TECHNOLOGY",[23,29,37,45,51,59,65],{"citationText":24,"title":10,"authors":25,"source":26,"year":27,"doi":10,"url":28},"Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3rd ed.). John Wiley & Sons.","Myers, G. J., Sandler, C., Badgett, T.","John Wiley & Sons",2011,"https:\u002F\u002Flccn.loc.gov\u002F2011030026",{"citationText":30,"title":31,"authors":32,"source":33,"year":34,"doi":35,"url":36},"Rothermel, G., & Harrold, M. J. (1996). Analyzing regression test selection techniques. IEEE Transactions on Software Engineering, 22(8), 529–551.","Analyzing regression test selection techniques","Rothermel, G., Harrold, M. J.","IEEE Transactions on Software Engineering",1996,"10.1109\u002F32.536955","https:\u002F\u002Fdoi.org\u002F10.1109\u002F32.536955",{"citationText":38,"title":39,"authors":40,"source":41,"year":42,"doi":43,"url":44},"McMinn, P. (2004). Search-based software test data generation: a survey. Software Testing, Verification and Reliability, 14(2), 105–156.","Search-based software test data generation: a survey","McMinn, P.","Software Testing, Verification and Reliability",2004,"10.1002\u002Fstvr.294","https:\u002F\u002Fdoi.org\u002F10.1002\u002Fstvr.294",{"citationText":46,"title":47,"authors":48,"source":33,"year":27,"doi":49,"url":50},"Jia, Y., & Harman, M. (2011). An Analysis and Survey of the Development of Mutation Testing. IEEE Transactions on Software Engineering, 37(5), 649–678.","An Analysis and Survey of the Development of Mutation Testing","Jia, Y., Harman, M.","10.1109\u002Ftse.2010.62","https:\u002F\u002Fdoi.org\u002F10.1109\u002Ftse.2010.62",{"citationText":52,"title":53,"authors":54,"source":55,"year":56,"doi":57,"url":58},"Cadar, C., & Sen, K. (2013). Symbolic execution for software testing: three decades later. Communications of the ACM, 56(2), 82–90.","Symbolic execution for software testing","Cadar, C., Sen, K.","Communications of the ACM",2013,"10.1145\u002F2408776.2408795","https:\u002F\u002Fdoi.org\u002F10.1145\u002F2408776.2408795",{"citationText":60,"title":61,"authors":62,"source":33,"year":56,"doi":63,"url":64},"Fraser, G., & Arcuri, A. (2013). Whole Test Suite Generation. IEEE Transactions on Software Engineering, 39(2), 276–291.","Whole Test Suite Generation","Fraser, G., Arcuri, A.","10.1109\u002Ftse.2012.14","https:\u002F\u002Fdoi.org\u002F10.1109\u002Ftse.2012.14",{"citationText":66,"title":67,"authors":62,"source":33,"year":68,"doi":69,"url":70},"Fraser, G., & Arcuri, A. (2025). A Retrospective on Whole Test Suite Generation: On the Role of SBST in the Age of LLMs. IEEE Transactions on Software Engineering.","A Retrospective on Whole Test Suite Generation: On the Role of SBST in the Age of LLMs",2025,"10.1109\u002Ftse.2025.3539458","https:\u002F\u002Fdoi.org\u002F10.1109\u002Ftse.2025.3539458",[72,75,78],{"question":73,"answer":74},"Kiểm thử phần mềm khác gì so với hoạt động gỡ lỗi?","Kiểm thử là quá trình thực thi có chủ đích nhằm kích hoạt và phát hiện các khiếm khuyết hoặc sự sai lệch so với yêu cầu thiết kế. Ngược lại, gỡ lỗi là hoạt động diễn ra sau khi phát hiện lỗi, tập trung vào việc điều tra, định vị chính xác nguyên nhân gốc rễ trong mã nguồn và chỉnh sửa mã để khắc phục lỗi đó.",{"question":76,"answer":77},"Tại sao không thể kiểm thử vét cạn toàn bộ phần mềm?","Do không gian giá trị đầu vào, các cấu hình môi trường và số lượng đường đi thực thi tiềm năng trong các chương trình phần mềm hiện đại gần như là vô hạn. Việc chạy thử tất cả mọi tổ hợp trạng thái là điều bất khả thi về mặt toán học và chi phí kinh tế, do đó kỹ nghệ phần mềm phải áp dụng các kỹ thuật chọn mẫu đại diện như phân vùng tương đương và phân tích biên.",{"question":79,"answer":80},"Kiểm thử đột biến đánh giá chất lượng bộ kiểm thử như thế nào?","Kiểm thử đột biến chủ động cấy các lỗi nhân tạo nhỏ vào mã nguồn gốc để tạo ra các chương trình đột biến. Nếu bộ kiểm thử thực thi và phát hiện được sự sai khác của chương trình đột biến so với chương trình gốc thì đột biến đó được xem là đã bị tiêu diệt. Tỷ lệ đột biến bị tiêu diệt đo lường trực tiếp năng lực bắt lỗi thực tế của bộ kiểm thử.",{"id":82,"researcherId":10,"name":83,"imageUrl":84},2681,"Cuong Ta","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocKFuWh0ZD601Hp0_V_2xAK3kIOs20Kyv3V5ZLBo6fwfjyymJYzE=s96-c",{"id":86,"researcherId":10,"name":87,"imageUrl":88},1,"Nguyễn Ngọc Sơn","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocLGfGsF1nYQqYK5BasTLhNu1dBrBXg2fcEgBNPXJ0p2gqLQnO7i=s96-c",[13],false,"PUBLISHED","2025-12-01T09:43:02.066+00:00","2026-09-04T05:15:23.687+00:00","2026-09-04T05:15:23.681+00:00",0,[97,106,109,119,125,131,136,141,146,151],{"id":98,"title":99,"term":98,"englishTitle":98,"definition":100,"discipline":101,"disciplineCode":102,"disciplineLabel":103,"disciplineColor":104,"disciplineIcon":105},"competency development","Competency development là gì? Nghiên cứu khoa học liên quan","khái niệm và đối tượng nghiên cứu cơ bản trong khoa học xã hội, phản ánh các đặc trưng bản chất, cơ chế vận hành và các quy luật tương tác hệ thống trong thực tiễn.","SOCIAL_SCIENCES","social-sciences","Khoa học xã hội","#E08600","users",{"id":107,"title":108,"term":107,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"temps","Temps là gì? Các bài báo nghiên cứu khoa học về Temps",{"id":110,"title":111,"term":112,"englishTitle":113,"definition":114,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"chương trình máy tính","Chương trình máy tính là gì? Ý nghĩa và ứng dụng chuyên sâu","Chương trình máy tính","computer program","Chương trình máy tính (computer program) là tập hợp tuần tự các chỉ thị và cấu trúc dữ liệu được viết bằng ngôn ngữ lập trình theo quy tắc logic xác định, chỉ dẫn bộ vi xử lý thực thi các phép toán số học và thao tác logic nhằm giải quyết một bài toán tính toán cụ thể.","engineering-technology","Kỹ thuật và công nghệ","#5B62F4","cpu",{"id":120,"title":121,"term":122,"englishTitle":123,"definition":124,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"thử nghiệm hệ thống","Thử nghiệm hệ thống là gì? Các bài báo nghiên cứu khoa học","Thử nghiệm hệ thống","System testing","Thử nghiệm hệ thống là một cấp độ kiểm thử phần mềm toàn diện, trong đó toàn bộ hệ thống phần mềm hoàn chỉnh và tích hợp đầy đủ được kiểm tra đối chiếu với các tài liệu đặc tả yêu cầu chức năng và phi chức năng ban đầu.",{"id":126,"title":127,"term":128,"englishTitle":129,"definition":130,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"thuật toán heuristic","Thuật toán heuristic là gì? Phân loại, nguyên lý và ứng dụng","Thuật toán heuristic","heuristic algorithm","Thuật toán heuristic (heuristic algorithm, hay phương pháp phỏng đoán) là kỹ thuật giải quyết bài toán được thiết kế nhằm tìm kiếm lời giải đủ tốt và chấp nhận được trong khoảng thời gian tính toán thực tế cho các bài toán tối ưu hóa phức tạp, đánh đổi tính tối ưu tuyệt đối để lấy tốc độ thực thi.",{"id":132,"title":133,"term":132,"englishTitle":134,"definition":135,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"hỏa hoạn","Hỏa hoạn là gì? Các bài báo nghiên cứu khoa học liên quan","fire","Hỏa hoạn là sự cố cháy lớn ngoài tầm kiểm soát do phản ứng hóa học tỏa nhiệt nhanh giữa chất cháy và chất oxy hóa (thường là oxy trong không khí), gây thiệt hại nghiêm trọng về người, tài sản và môi trường.",{"id":137,"title":138,"term":137,"englishTitle":139,"definition":140,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"hệ thống hỗ trợ quyết định","Hệ thống hỗ trợ quyết định là gì? Các nghiên cứu khoa học","decision support system","Hệ thống hỗ trợ quyết định (Decision Support System - DSS) là hệ thống thông tin tích hợp dữ liệu, mô hình phân tích và giao diện tương tác nhằm hỗ trợ con người giải quyết các bài toán ra quyết định phức tạp và bán cấu trúc.",{"id":142,"title":143,"term":142,"englishTitle":144,"definition":145,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"tổn thất công suất","Tổn thất công suất là gì? Nguyên nhân, công thức và giải pháp","power loss","Tổn thất công suất là hiện tượng tiêu hao năng lượng điện dưới dạng nhiệt hoặc từ trường trong các phần tử của hệ thống điện như dây dẫn, máy biến áp và thiết bị truyền tải trong quá trình vận hành.",{"id":147,"title":148,"term":147,"englishTitle":149,"definition":150,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"khí động học","Khí động học: Khái niệm, nguyên lý và ứng dụng","Aerodynamics","Khí động học là một thuật ngữ và phạm trù học thuật then chốt trong lĩnh vực engineering technology, phản ánh các nguyên lý, cơ chế và phương pháp luận chuyên sâu đã được chuẩn hóa trong nghiên cứu và ứng dụng thực tiễn.",{"id":152,"title":153,"term":152,"englishTitle":154,"definition":155,"discipline":21,"disciplineCode":115,"disciplineLabel":116,"disciplineColor":117,"disciplineIcon":118},"ứng suất nhiệt","Ứng suất nhiệt là gì? Các bài nghiên cứu khoa học liên quan","ung suat nhiet","khái niệm và đối tượng nghiên cứu cơ bản trong khoa học kỹ thuật và công nghệ, phản ánh các đặc trưng bản chất, cơ chế vận hành và các quy luật tương tác hệ thống trong thực tiễn."]