[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"_public_topic_publications_th%E1%BB%AD%20nghi%E1%BB%87m%20h%E1%BB%87%20th%E1%BB%91ng{\"limit\":5}":3,"_public_topic_byId_thử nghiệm hệ thống":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":17,"englishTitle":18,"synonyms":10,"definition":19,"discipline":20,"references":21,"faqs":43,"createUser":53,"publishUser":57,"keywords":61,"keywordCount":72,"enrichTopicLink":73,"status":74,"createTime":75,"updateTime":76,"publishTime":77,"linkEnrichedTime":78,"publicationScanTime":10,"contentErrorMessage":10,"viewCount":79,"relateTopics":80},"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 là giai đoạn kiểm thử phần mềm trên toàn bộ ứng dụng sau khi tích hợp các module, nhằm xác minh hệ thống đáp ứng đầy đủ yêu cầu chức năng và phi chức năng. Phạm vi thực hiện bao gồm kiểm tra giao diện người dùng, API, cơ sở dữ liệu, hiệu năng, bảo mật và tương thích môi trường để đảm bảo độ ổn định và chất lượng sản phẩm trước khi triển khai. ","\u003Cp>\u003Cstrong>Thử nghiệm hệ thống\u003C\u002Fstrong> (\u003Cem>System testing\u003C\u002Fem>) là giai đoạn then chốt trong chu trình phát triển phần mềm (V-model hoặc Agile\u002FDevOps). Thử nghiệm hệ thống đánh giá sản phẩm từ góc nhìn tổng thể đầu-cuối (end-to-end), đảm bảo toàn bộ các module phần cứng, phần mềm và cơ sở dữ liệu phối hợp trơn tru trước khi chuyển giao người dùng nghiệm thu. giai đoạn kiểm thử phần mềm thực hiện trên toàn bộ ứng dụng sau khi tích hợp các thành phần, module với nhau. Mục đích là xác minh xem hệ thống có đáp ứng đầy đủ yêu cầu chức năng và phi chức năng đã được xác lập trong tài liệu đặc tả hay không.\u003C\u002Fp>\u003Cp>Phạm vi kiểm thử bao gồm mọi {{topic|%7B%22topic%22%3A%22giao%20di%E1%BB%87n%20ng%C6%B0%E1%BB%9Di%20d%C3%B9ng%22%7D}}, dịch vụ web (API), tương tác với cơ sở dữ liệu, và liên kết với các hệ thống bên ngoài. Việc kiểm thử ở mức hệ thống giúp phát hiện lỗi do tích hợp, các vấn đề hiệu năng và bảo mật mà kiểm thử đơn vị (Unit Testing) hoặc kiểm thử tích hợp (Integration Testing) có thể bỏ sót.\u003C\u002Fp>\u003Cp>Thử nghiệm hệ thống {{topic|%7B%22topic%22%3A%22%C4%91%E1%BA%A3m%20b%E1%BA%A3o%20ch%E1%BA%A5t%20l%C6%B0%E1%BB%A3ng%22%7D}} đầu ra, giảm thiểu rủi ro lỗi khi đưa phần mềm vào môi trường sản xuất. Kết quả kiểm thử được đánh giá trên cơ sở test report, defect log và các {{topic|%7B%22topic%22%3A%22ch%E1%BB%89%20s%E1%BB%91%20ch%E1%BA%A5t%20l%C6%B0%E1%BB%A3ng%22%7D}} như tỷ lệ lỗi, độ bao phủ yêu cầu và {{topic|%7B%22topic%22%3A%22th%E1%BB%9Di%20gian%20ph%E1%BA%A3n%20h%E1%BB%93i%22%7D}}.\u003C\u002Fp>\u003Cul>\u003Cli>Kiểm thử toàn bộ hệ thống sau khi tích hợp\u003C\u002Fli>\u003Cli>Xác minh chức năng và phi chức năng\u003C\u002Fli>\u003Cli>Phát hiện lỗi tích hợp, hiệu năng và bảo mật\u003C\u002Fli>\u003Cli>Báo cáo chi tiết: Test Report, Defect Log\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Mục tiêu và phạm vi\u003C\u002Fh2>\u003Cp>Mục tiêu chính của thử nghiệm hệ thống là đảm bảo toàn bộ nghiệp vụ hoạt động đúng như kỳ vọng và đáp ứng các tiêu chí chất lượng. Các {{topic|%7B%22topic%22%3A%22y%C3%AAu%20c%E1%BA%A7u%20ch%E1%BB%A9c%20n%C4%83ng%22%7D}} phải được thực thi chính xác, dữ liệu phải được xử lý đúng, và kết quả trả về đúng theo kịch bản nghiệp vụ.\u003C\u002Fp>\u003Cp>Đối với phi chức năng, thử nghiệm hệ thống tập trung vào các khía cạnh như hiệu năng (performance), {{topic|%7B%22topic%22%3A%22kh%E1%BA%A3%20n%C4%83ng%20ch%E1%BB%8Bu%20t%E1%BA%A3i%22%7D}} (stress\u002Fload), {{topic|%7B%22topic%22%3A%22kh%E1%BA%A3%20n%C4%83ng%20m%E1%BB%9F%20r%E1%BB%99ng%22%7D}} (scalability), bảo mật (security) và khả năng khôi phục sau sự cố (reliability). Phạm vi kiểm thử bao trùm nhiều môi trường thực nghiệm khác nhau để đảm bảo tính tương thích và ổn định khi triển khai.\u003C\u002Fp>\u003Cul>\u003Cli>Functional Testing: xác thực kịch bản nghiệp vụ\u003C\u002Fli>\u003Cli>Performance Testing: đo thời gian phản hồi, throughput\u003C\u002Fli>\u003Cli>Security Testing: kiểm tra lỗ hổng OWASP Top 10\u003C\u002Fli>\u003Cli>Compatibility Testing: trình duyệt, thiết bị, hệ điều hành\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Tiêu chuẩn và khung tham chiếu\u003C\u002Fh2>\u003Cp>ISTQB® Glossary định nghĩa các khái niệm, mức độ kiểm thử và thuật ngữ liên quan, làm cơ sở chung cho đội kiểm thử và phát triển. Tài liệu chi tiết có tại \u003Ca href=\"https:\u002F\u002Fwww.istqb.org\u002F\">ISTQB.org\u003C\u002Fa>, bao gồm thuật ngữ System Testing và các kỹ thuật liên quan.\u003C\u002Fp>\u003Cp>ISO\u002FIEC\u002FIEEE 29119-1:2013 cung cấp khung quy trình {{topic|%7B%22topic%22%3A%22ki%E1%BB%83m%20th%E1%BB%AD%20ph%E1%BA%A7n%20m%E1%BB%81m%22%7D}} từ việc lập kế hoạch, thiết kế, triển khai đến {{topic|%7B%22topic%22%3A%22%C4%91%C3%A1nh%20gi%C3%A1%20ch%E1%BA%A5t%20l%C6%B0%E1%BB%A3ng%22%7D}}. Phần 2 và 3 của tiêu chuẩn này quy định cách phát triển test case, test data và quản lý test cho giai đoạn hệ thống.\u003C\u002Fp>\u003Cp>IEEE 829–2008 là chuẩn tài liệu kiểm thử bao gồm Test Plan, Test Design Specification, Test Case Specification, Test Procedure và Test Report. Việc tuân thủ chuẩn giúp đảm bảo tính minh bạch, dễ kiểm tra, và có thể tái sử dụng tài liệu trong các dự án tương tự.\u003C\u002Fp>\u003Cul>\u003Cli>ISTQB® Glossary – định nghĩa thuật ngữ, kỹ thuật kiểm thử\u003C\u002Fli>\u003Cli>ISO\u002FIEC\u002FIEEE 29119 – quy trình và tài liệu kiểm thử chuẩn\u003C\u002Fli>\u003Cli>IEEE 829 – chuẩn tài liệu kiểm thử (Test Plan, Test Case, Report)\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Quy trình thực hiện\u003C\u002Fh2>\u003Cp>Lập kế hoạch kiểm thử hệ thống bao gồm xác định mục tiêu, phạm vi, chiến lược, công cụ và nguồn lực. Test Plan phải mô tả rõ môi trường thử nghiệm, cách thiết lập dữ liệu đầu vào, tiêu chí bắt đầu và kết thúc, cũng như phân công trách nhiệm.\u003C\u002Fp>\u003Cp>Chuẩn bị môi trường thử nghiệm: cài đặt hệ thống staging giống production, tạo cơ sở dữ liệu mẫu, cấu hình mạng, bảo mật, và công cụ giám sát. Môi trường phải được xác minh trước khi bắt đầu chạy test case.\u003C\u002Fp>\u003Col>\u003Cli>Thiết kế Test Case: mô tả điều kiện tiền xử lý, bước thực hiện và kết quả mong đợi.\u003C\u002Fli>\u003Cli>Thực hiện Test Case: ghi nhận kết quả, log lỗi (defect), đính kèm hình ảnh\u002Fchứng cứ khi phát hiện sai lệch.\u003C\u002Fli>\u003Cli>Regression Testing: chạy lại các kịch bản đã passed sau khi sửa lỗi để đảm bảo không phát sinh lỗi mới.\u003C\u002Fli>\u003C\u002Fol>\u003Cfigure class=\"table\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Bước\u003C\u002Fth>\u003Cth>Nội dung\u003C\u002Fth>\u003Cth>Công cụ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Planning\u003C\u002Ftd>\u003Ctd>Xác định phạm vi, tiêu chí, tài nguyên\u003C\u002Ftd>\u003Ctd>Confluence, MS Project\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Preparation\u003C\u002Ftd>\u003Ctd>Cấu hình môi trường, dữ liệu\u003C\u002Ftd>\u003Ctd>Docker, AWS, SQL scripts\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Execution\u003C\u002Ftd>\u003Ctd>Chạy Test Case, ghi nhận defect\u003C\u002Ftd>\u003Ctd>Jira, TestRail, Selenium\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Reporting\u003C\u002Ftd>\u003Ctd>Tổng hợp kết quả, báo cáo chất lượng\u003C\u002Ftd>\u003Ctd>Excel, TestRail\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Ffigure>\u003Cp>Báo cáo cuối cùng (Test Report) tóm tắt mức độ hoàn thành test case, danh sách defect, đề xuất mức độ rủi ro và khuyến nghị trước khi chuyển giao hệ thống sang giai đoạn User Acceptance Testing (UAT).\u003C\u002Fp>\u003Ch2>Thiết lập môi trường và công cụ\u003C\u002Fh2>\u003Cp>Môi trường thử nghiệm hệ thống yêu cầu xây dựng một bản sao đầy đủ của hệ thống production gồm server ứng dụng, cơ sở dữ liệu và các dịch vụ ngoại vi để đảm bảo khả năng tái tạo lỗi và đánh giá chính xác. Sử dụng công cụ ảo hóa hoặc containerization như Docker giúp triển khai nhanh các thành phần, đồng thời giữ nguyên cấu hình môi trường.\u003C\u002Fp>\u003Cp>Thiết lập dữ liệu thử cần gồm dữ liệu hợp lệ, dữ liệu biên và dữ liệu bất thường để kiểm chứng tính toàn vẹn. Dữ liệu nên được sinh tự động hoặc dùng kỹ thuật masking từ dữ liệu production để bảo vệ thông tin nhạy cảm. Công cụ quản lý dữ liệu như Flyway hoặc Liquibase hỗ trợ versioning và rollback schema trong cơ sở dữ liệu.\u003C\u002Fp>\u003Cul>\u003Cli>Máy chủ ứng dụng: Docker Compose, Kubernetes\u003C\u002Fli>\u003Cli>Cơ sở dữ liệu: MySQL\u002FPostgreSQL clone hoặc minikube volumes\u003C\u002Fli>\u003Cli>Công cụ giám sát: Prometheus, Grafana\u003C\u002Fli>\u003Cli>Quản lý cấu hình: Ansible, Terraform\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Automated test frameworks tích hợp vào môi trường CI\u002FCD (Jenkins, GitLab CI) cho phép chạy thử nghiệm hệ thống tự động sau mỗi lần deploy lên staging. Điều này đảm bảo feedback nhanh về vấn đề tích hợp và hiệu năng trước khi triển khai vào production.\u003C\u002Fp>\u003Ch2>Thiết kế và quản lý Test Case\u003C\u002Fh2>\u003Cp>Test Case được tổ chức theo Test Suite, mỗi suite ứng với một module chức năng hoặc kịch bản nghiệp vụ. Mỗi Test Case ghi rõ ID, mô tả, điều kiện tiền xử lý (precondition), bước thực hiện, và kết quả mong đợi để đảm bảo tính lặp lại và minh bạch.\u003C\u002Fp>\u003Cp>Sử dụng ma trận truy vết (Requirements Traceability Matrix) giúp theo dõi mối liên hệ giữa yêu cầu và Test Case, đảm bảo không bỏ sót bất kỳ yêu cầu nào. Ma trận này được lưu trữ và cập nhật trong công cụ quản lý Test như TestRail hoặc Zephyr.\u003C\u002Fp>\u003Col>\u003Cli>Xác định danh sách yêu cầu từ tài liệu đặc tả.\u003C\u002Fli>\u003Cli>Phân tích rủi ro và ưu tiên viết Test Case cho các chức năng quan trọng.\u003C\u002Fli>\u003Cli>Tạo Test Case chi tiết, gán tag (functional, performance, security).\u003C\u002Fli>\u003Cli>Đánh giá và review Test Case với đội phát triển và quản lý sản phẩm.\u003C\u002Fli>\u003C\u002Fol>\u003Cp>Test Case tự động hóa bằng Selenium WebDriver (UI), Postman\u002FNewman (API) và JMeter (load test) giúp mở rộng phạm vi kiểm thử và tăng tốc độ thực thi. Kết quả tự động được báo cáo về Jira hoặc Allure Test Report để theo dõi và phân tích.\u003C\u002Fp>\u003Ch2>Các loại thử nghiệm hệ thống\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cstrong>Functional Testing:\u003C\u002Fstrong> kiểm thử luồng nghiệp vụ chính xác, validate business rules và data flows.\u003C\u002Fli>\u003Cli>\u003Cstrong>Performance Testing:\u003C\u002Fstrong> load test, stress test, soak test sử dụng Apache JMeter để đo throughput, latency và xác định điểm nghẽn.\u003C\u002Fli>\u003Cli>\u003Cstrong>Security Testing:\u003C\u002Fstrong> kiểm tra lỗ hổng OWASP Top 10 bằng công cụ OWASP ZAP hoặc Burp Suite (\u003Ca href=\"https:\u002F\u002Fowasp.org\u002Fwww-project-zap\u002F\">owasp.org\u003C\u002Fa>).\u003C\u002Fli>\u003Cli>\u003Cstrong>Compatibility Testing:\u003C\u002Fstrong> kiểm thử đa trình duyệt (Chrome, Firefox, Edge) và đa nền tảng (Windows, macOS, Linux) sử dụng BrowserStack (\u003Ca href=\"https:\u002F\u002Fwww.browserstack.com\u002F\">browserstack.com\u003C\u002Fa>).\u003C\u002Fli>\u003Cli>\u003Cstrong>Usability Testing:\u003C\u002Fstrong> đánh giá {{topic|%7B%22topic%22%3A%22tr%E1%BA%A3i%20nghi%E1%BB%87m%20ng%C6%B0%E1%BB%9Di%20d%C3%B9ng%22%7D}}, khả năng sử dụng giao diện qua khảo sát và session recording.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Mỗi loại thử nghiệm cần có bộ tiêu chí kết xuất riêng như thời gian phản hồi <200 ms cho các API quan trọng, khả năng chịu tải tối thiểu 1.000 concurrent users và không có lỗ hổng mức nghiêm trọng (severity ≥ High) sau security scan.\u003C\u002Fp>\u003Ch2>Thách thức và giải pháp\u003C\u002Fh2>\u003Cp>Đồng bộ hóa môi trường staging với production thường khó khăn do khác biệt về cấu hình mạng, dữ liệu và phiên bản service. Giải pháp là áp dụng Infrastructure as Code (IaC) với Terraform và Ansible để tự động hóa thiết lập, đảm bảo môi trường staging luôn đồng nhất.\u003C\u002Fp>\u003Cp>Số lượng Test Case lớn gây khó khăn trong quản lý và ưu tiên. Áp dụng phương pháp Risk-Based Testing giúp tập trung vào các kịch bản quan trọng nhất, đồng thời kết hợp với test coverage tools (JaCoCo cho Java) để đánh giá độ phủ mã nguồn và yêu cầu.\u003C\u002Fp>\u003Cul>\u003Cli>Vấn đề: Dữ liệu thử không đủ đa dạng → Sử dụng Synthetic Data Generator.\u003C\u002Fli>\u003Cli>Vấn đề: Thời gian thực thi dài → Tự động hóa, parallel testing trên Selenium Grid.\u003C\u002Fli>\u003Cli>Vấn đề: Bảo mật dữ liệu → Data Masking và environment isolation.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Quản lý test result phân tán bằng công cụ TestOps như Xray for Jira hoặc TestRail, cho phép theo dõi feedback real-time và tích hợp với alert system (Slack, MS Teams) để phản ứng nhanh với lỗi nghiêm trọng.\u003C\u002Fp>","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.","ENGINEERING_TECHNOLOGY",[22,29,36],{"citationText":23,"title":24,"authors":25,"source":26,"year":27,"doi":28,"url":10},"Borjesson, E., Feldt, R. (2012). Automated System Testing Using Visual GUI Testing Tools: A Comparative Study in Industry. 2012 IEEE Fifth International Conference on Software Testing, Verification and Validation.","Automated System Testing Using Visual GUI Testing Tools: A Comparative Study in Industry","Borjesson, E., Feldt, R.","2012 IEEE Fifth International Conference on Software Testing, Verification and Validation",2012,"10.1109\u002Ficst.2012.115",{"citationText":30,"title":31,"authors":32,"source":33,"year":34,"doi":35,"url":10},"Zimmermann, D. (2022). Automated GUI-based Software-Testing Using Deep Neuroevolution. 2022 IEEE Conference on Software Testing, Verification and Validation (ICST).","Automated GUI-based Software-Testing Using Deep Neuroevolution","Zimmermann, D.","2022 IEEE Conference on Software Testing, Verification and Validation (ICST)",2022,"10.1109\u002Ficst53961.2022.00060",{"citationText":37,"title":38,"authors":39,"source":40,"year":41,"doi":42,"url":10},"Feldmeier, P. (2023). Fully Automated Game Testing via Neuroevolution. 2023 IEEE Conference on Software Testing, Verification and Validation (ICST).","Fully Automated Game Testing via Neuroevolution","Feldmeier, P.","2023 IEEE Conference on Software Testing, Verification and Validation (ICST)",2023,"10.1109\u002Ficst57152.2023.00058",[44,47,50],{"question":45,"answer":46},"Thử nghiệm hệ thống nằm ở vị trí nào trong phân cấp kiểm thử chuẩn?","Nằm ở cấp độ thứ ba sau Thử nghiệm đơn vị (Unit Testing) và Thử nghiệm tích hợp (Integration Testing), và diễn ra ngay trước Thử nghiệm chấp nhận của người dùng (User Acceptance Testing - UAT).",{"question":48,"answer":49},"Những loại kiểm thử phi chức năng (non-functional testing) chủ đạo trong thử nghiệm hệ thống là gì?","Bao gồm kiểm thử hiệu năng (performance\u002Fload\u002Fstress testing), kiểm thử an toàn bảo mật (security testing), kiểm thử tính tương thích (compatibility testing), kiểm thử khả năng phục hồi sau sự cố (recovery testing) và kiểm thử tính khả dụng (usability testing).",{"question":51,"answer":52},"Sự khác nhau giữa kiểm thử hộp đen (black-box) và kiểm thử hộp trắng (white-box) trong bối cảnh thử nghiệm hệ thống là gì?","Thử nghiệm hệ thống chủ yếu áp dụng phương pháp hộp đen, tức là người kiểm thử chỉ tập trung vào đầu vào, hành vi bên ngoài và đầu ra của hệ thống mà không cần biết đến cấu trúc mã nguồn nội bộ bên dưới.",{"id":54,"researcherId":10,"name":55,"imageUrl":56},1,"Nguyễn Ngọc Sơn","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocLGfGsF1nYQqYK5BasTLhNu1dBrBXg2fcEgBNPXJ0p2gqLQnO7i=s96-c",{"id":58,"researcherId":10,"name":59,"imageUrl":60},2681,"Cuong Ta","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocKFuWh0ZD601Hp0_V_2xAK3kIOs20Kyv3V5ZLBo6fwfjyymJYzE=s96-c",[62,63,64,65,66,67,68,69,70,71],"giao diện người dùng","đảm bảo chất lượng","chỉ số chất lượng","thời gian phản hồi","yêu cầu chức năng","khả năng chịu tải","khả năng mở rộng","kiểm thử phần mềm","đánh giá chất lượng","trải nghiệm người dùng",10,true,"PUBLISHED","2025-07-13T02:19:31.589+00:00","2026-09-11T15:12:36.622+00:00","2025-07-18T03:43:27.839+00:00","2026-09-11T15:12:36.267+00:00",279,[81,84,87,90,93,96,99,102,105,108],{"id":82,"title":83,"term":82,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"bibliometrics","Bibliometrics là gì? Các nghiên cứu khoa học về Bibliometrics",{"id":85,"title":86,"term":85,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"chất lượng thông tin","Chất lượng thông tin là gì? Nghiên cứu khoa học liên quan",{"id":88,"title":89,"term":88,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"nghiên cứu tổng quan","Nghiên cứu tổng quan là gì? Các bài báo nghiên cứu khoa học",{"id":91,"title":92,"term":91,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"cường độ chịu uốn","Cường độ chịu uốn là gì? Các nghiên cứu về Cường độ chịu uốn",{"id":94,"title":95,"term":94,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"density","Density là gì? Các công bố khoa học về Density",{"id":97,"title":98,"term":97,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"thu thập thông tin","Thu thập thông tin là gì? Các nghiên cứu khoa học liên quan",{"id":100,"title":101,"term":100,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"webgis","WebGIS là gì? Các bài báo nghiên cứu khoa học về WebGIS",{"id":103,"title":104,"term":103,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"sf 36","SF-36 là gì? Các công bố nghiên cứu khoa học về SF-36",{"id":106,"title":107,"term":106,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"giao thông xanh","Giao thông xanh là gì? Các nghiên cứu về Giao thông xanh",{"id":109,"title":110,"term":109,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"eortc qlq c30","EORTC QLQ-C30 là gì? Các bài nghiên cứu khoa học liên quan"]