Tất cả câu hỏi

Integration Level Testing là một loại thử nghiệm được thực hiện để lộ ra các lỗi trong các giao diện và trong tương tác giữa các thành phần tích hợp. Đây là một bước quan trọng trong quá trình thử nghiệm phần mềm, giúp đảm bảo rằng các thành phần khác nhau trong hệ thống hoạt động một cách trơn tru và không có lỗi. Trong Integration Level Testing, các thành phần được tích hợp lại với nhau để tạo thành một hệ thống hoàn chỉnh, sau đó được thử nghiệm để kiểm tra xem chúng có hoạt động đúng như mong đợi hay không. Điều này giúp phát hiện ra các lỗi trong giao diện và tương tác giữa các thành phần, từ đó có thể sửa lỗi và cải thiện chất lượng của hệ thống. Ví dụ, nếu một hệ thống có ba thành phần A, B và C, và chúng cần tương tác với nhau để tạo thành một hệ thống hoàn chỉnh, thì Integration Level Testing sẽ bao gồm việc tích hợp các thành phần này lại với nhau và thử nghiệm hệ thống để kiểm tra xem chúng có hoạt động đúng như mong đợi hay không.

Trong quá trình đánh giá và xem xét một tài liệu, có thể có nhiều người tham gia và đóng vai trò khác nhau. Tuy nhiên, người đứng đầu quá trình đánh giá này được gọi là Moderator. Họ chịu trách nhiệm lập kế hoạch đánh giá, tổ chức cuộc họp và theo dõi tiến trình sau cuộc họp. Moderator đóng vai trò quan trọng trong việc đảm bảo rằng quá trình đánh giá được thực hiện một cách công bằng, hiệu quả và chính xác. Họ cũng có thể giúp giải quyết các vấn đề hoặc tranh chấp có thể phát sinh trong quá trình đánh giá. Ngoài ra, Moderator cũng có thể giúp đảm bảo rằng tất cả các bên liên quan đều được thông báo và tham gia vào quá trình đánh giá.

Các công cụ và tự động hóa là những công nghệ quan trọng trong nhiều lĩnh vực, bao gồm sản xuất, xây dựng, y tế và nhiều hơn nữa. Các đặc điểm chính của công cụ và tự động hóa là sự kết hợp giữa tốc độ và hiệu suất, cũng như độ chính xác và độ chính xác. Tốc độ và hiệu suất giúp giảm thời gian và chi phí sản xuất, trong khi độ chính xác và độ chính xác giúp đảm bảo chất lượng sản phẩm và giảm thiểu sai sót. Ví dụ, trong sản xuất ô tô, các công cụ tự động hóa giúp tăng tốc độ sản xuất và giảm chi phí, trong khi đảm bảo độ chính xác và độ chính xác của từng bộ phận. Tương tự, trong y tế, các công cụ tự động hóa giúp tăng tốc độ và độ chính xác trong các thủ tục chẩn đoán và điều trị. Do đó, đáp án đúng là "Both Speed/efficiency and Accuracy/precision".

Câu hỏi này liên quan đến các khái niệm trong quản lý dự án và quy trình làm việc. Trong các workbench, các quy trình và tiêu chuẩn được sử dụng để đảm bảo rằng các sản phẩm đầu ra được sản xuất đúng cách. Các quy trình và tiêu chuẩn này bao gồm các bước cụ thể và các tiêu chí để đánh giá chất lượng của sản phẩm. Chúng giúp đảm bảo rằng các sản phẩm được sản xuất một cách đồng nhất và đáp ứng các yêu cầu của dự án. Các công cụ và kỹ thuật, mặc dù quan trọng, không phải là các yếu tố chính trong việc sản xuất các sản phẩm đầu ra. Các quy trình và tiêu chuẩn là nền tảng của việc sản xuất các sản phẩm đầu ra, vì chúng cung cấp hướng dẫn và tiêu chí để thực hiện các công việc.

Alpha testing và System testing thường được thực hiện tại phòng thí nghiệm hoặc môi trường kiểm thử được kiểm soát. Trong khi đó, Field testing được thực hiện tại địa điểm thực tế, nơi mà sản phẩm hoặc hệ thống sẽ được sử dụng. Điều này cho phép kiểm thử viên đánh giá sản phẩm hoặc hệ thống trong môi trường thực tế, bao gồm các yếu tố như thời tiết, thiết bị và người dùng. Field testing giúp xác định các vấn đề và cải thiện sản phẩm hoặc hệ thống trước khi nó được triển khai rộng rãi. Performance testing là một loại kiểm thử khác, tập trung vào việc đánh giá hiệu suất của sản phẩm hoặc hệ thống. Nó không phải là một loại kiểm thử được thực hiện tại địa điểm thực tế.

Các công cụ phân tích tĩnh (static analysis tools) thường được sử dụng bởi cả các nhà thử nghiệm (testers) và các nhà phát triển (developers). Các công cụ này giúp phân tích mã nguồn của ứng dụng hoặc hệ thống để phát hiện ra các lỗi, lỗ hổng bảo mật, và các vấn đề khác mà không cần thực hiện các thử nghiệm hoặc chạy ứng dụng. Các nhà thử nghiệm có thể sử dụng các công cụ phân tích tĩnh để xác định các vấn đề tiềm ẩn trong mã nguồn trước khi ứng dụng được triển khai, trong khi các nhà phát triển có thể sử dụng chúng để cải thiện chất lượng mã nguồn và ngăn chặn các vấn đề trước khi chúng xảy ra. Vì vậy, đáp án đúng là "Testers and Developers".

Đáp án đúng: "Business scenarios". Use case (ca sử dụng) mô tả tương tác giữa tác nhân (actor) và hệ thống để hoàn thành một mục tiêu nghiệp vụ, gồm luồng chính, luồng thay thế và luồng ngoại lệ; kiểm thử dựa trên use case vì vậy rất hữu ích để kiểm các kịch bản nghiệp vụ, luồng quy trình từ đầu đến cuối, thường ở cấp kiểm thử hệ thống và chấp nhận, và hay phát hiện lỗi ở chỗ các thành phần phối hợp với nhau. "Performance testing" là kiểm thử phi chức năng về tốc độ, tải, tài nguyên; use case có thể cung cấp kịch bản tải nhưng bản thân nó không đo hiệu năng. "Unit testing" kiểm từng thành phần riêng lẻ, quá nhỏ so với một use case trải qua nhiều thành phần. "Static testing" là xem xét sản phẩm mà không chạy mã, trong khi kiểm thử theo use case là kiểm thử động, thực thi kịch bản trên hệ thống.

Poor software characteristics là những đặc điểm không tốt của phần mềm. Điều này có thể bao gồm các yếu tố như độ phức tạp cao, khó bảo trì, không linh hoạt, không tương thích với các hệ thống khác, v.v. Những đặc điểm này có thể gây ra các rủi ro cho cả dự án (project risks) và sản phẩm (product risks). Dự án rủi ro (project risks) có thể bao gồm các vấn đề như thời gian phát triển kéo dài, chi phí cao, thiếu nhân lực, v.v. Sản phẩm rủi ro (product risks) có thể bao gồm các vấn đề như không đáp ứng được yêu cầu của khách hàng, không tương thích với các hệ thống khác, v.v. Vì vậy, poor software characteristics có thể gây ra cả dự án rủi ro và sản phẩm rủi ro.

Đáp án đúng: "Plan, Do, Check, Act". PDCA là chu trình cải tiến liên tục, gắn với tên Deming (còn gọi là vòng Deming hay Shewhart), gồm bốn bước: Plan (lập kế hoạch, đặt mục tiêu và cách làm), Do (thực hiện), Check (kiểm tra, đo kết quả so với mục tiêu) và Act (hành động điều chỉnh, chuẩn hoá cái tốt rồi bắt đầu vòng mới). Trong kiểm thử, chu trình này là nền cho cải tiến quy trình kiểm thử. "Plan, Do, Correct, Act" sai ở bước thứ ba: chu trình cần kiểm tra, đánh giá trước rồi mới điều chỉnh, sửa chữa thuộc về bước Act. "Plan, Debug, Check, Act" sai vì gỡ lỗi (debug) là hoạt động của lập trình viên, không phải bước của chu trình quản lý chất lượng. "Plan, Do, Check, Accept" sai ở bước cuối: Act là hành động cải tiến, không phải chấp nhận kết quả.

Exhaustive Testing là phương pháp kiểm thử đảm bảo rằng ứng dụng hệ thống hoạt động đúng bằng cách đánh giá mọi khả năng và điều kiện có thể xảy ra. Phương pháp này liên quan đến việc tạo ra một danh sách tất cả các khả năng và điều kiện có thể xảy ra trong ứng dụng và sau đó kiểm thử từng khả năng và điều kiện đó. Điều này đảm bảo rằng ứng dụng hoạt động đúng trong mọi tình huống có thể xảy ra.

Đáp án đúng: "Management". Rà soát kỹ thuật (technical review) là buổi thảo luận giữa đồng nghiệp và chuyên gia kỹ thuật nhằm đạt đồng thuận về nội dung kỹ thuật và tìm khiếm khuyết; ISTQB mô tả nó có thể thực hiện như rà soát đồng cấp (peer review) không có sự tham gia của quản lý, vì sự có mặt của quản lý khiến người tham gia ngại nêu vấn đề và dễ biến buổi rà soát thành đánh giá con người. "Analysts" là người viết hoặc hiểu sâu yêu cầu, thường tham gia rà soát kỹ thuật tài liệu yêu cầu và thiết kế. "Developers" là đồng nghiệp kỹ thuật cốt lõi, rà soát mã và thiết kế của nhau. "Testers" tham gia để kiểm tra khả năng kiểm thử và phát hiện mâu thuẫn trong sản phẩm được rà soát, cũng là thành phần kỹ thuật bình thường.

Đáp án đúng: "Technical Review". Theo ISTQB, rà soát kỹ thuật (technical review) là quá trình được ghi lại, tập trung đạt đồng thuận và tìm khiếm khuyết, có sự tham gia của đồng nghiệp và chuyên gia kỹ thuật, và có thể tiến hành như rà soát đồng cấp (peer review) không có quản lý tham gia; vì thế peer review thường được gọi đồng nghĩa với technical review. "Inspection" là thanh tra, loại rà soát chính thức nhất do người điều phối được đào tạo dẫn dắt, có vai trò định sẵn, tiêu chí vào ra và số đo; nó cũng có đồng nghiệp tham gia nhưng có tên gọi riêng. "Walkthrough" là duyệt qua do chính tác giả dẫn dắt nhằm chia sẻ hiểu biết, không phải tên khác của peer review. "Formal Review" là thuật ngữ chung chỉ mọi rà soát có quy trình chính thức, bao trùm nhiều loại chứ không trùng với peer review.

Đáp án đúng: "Test Analysis and Design". Trong quy trình kiểm thử cơ bản (Fundamental Test Process) của ISTQB, nhiệm vụ đầu tiên của pha phân tích và thiết kế kiểm thử là rà soát cơ sở kiểm thử (test basis) như yêu cầu, kiến trúc, thiết kế, giao diện, đánh giá khả năng kiểm thử của chúng, rồi xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Implementation and execution" diễn ra sau đó, khi ca kiểm thử đã có: xây quy trình kiểm thử, chuẩn bị dữ liệu, môi trường, chạy kiểm thử và ghi kết quả. "Test Closure Activities" là pha kết thúc: lưu trữ testware, bàn giao, rút kinh nghiệm, không quay lại đọc cơ sở kiểm thử. "Evaluating exit criteria and reporting" là đối chiếu kết quả chạy với tiêu chí thoát và viết báo cáo tổng kết, cũng không phải lúc rà soát tài liệu đầu vào.

Đáp án đúng: "Mediates between people". Người điều phối (moderator) dẫn dắt quy trình rà soát: lập kế hoạch, chủ trì cuộc họp, giữ thảo luận đúng hướng và làm trung gian hòa giải giữa các quan điểm khác nhau, đặc biệt giữa tác giả và người rà soát, để buổi họp tập trung vào lỗi trong tài liệu chứ không thành chỉ trích cá nhân. "Takes minutes of the meeting" là việc của người ghi chép (scribe), người lưu lại lỗi và vấn đề được nêu. "Writes the documents to be reviewed" là vai trò tác giả (author), người không nên làm điều phối trong rà soát hình thức để giữ khách quan. "Takes telephone calls" không phải vai trò nào trong rà soát; cuộc họp rà soát cần tập trung và không có ai được giao việc nghe điện thoại.

Static tests là một loại kiểm thử được sử dụng trong các giai đoạn khác nhau của vòng đời phần mềm. Trong giai đoạn Requirements, các static tests được sử dụng để kiểm tra các yêu cầu của phần mềm, đảm bảo rằng chúng được rõ ràng và chính xác. Trong giai đoạn Design, các static tests được sử dụng để kiểm tra các thiết kế của phần mềm, đảm bảo rằng chúng đáp ứng được các yêu cầu và tiêu chuẩn. Trong giai đoạn Coding, các static tests được sử dụng để kiểm tra mã nguồn của phần mềm, đảm bảo rằng chúng không chứa các lỗi và không đáp ứng được các tiêu chuẩn. Vì vậy, các static tests được sử dụng trong tất cả các giai đoạn khác nhau của vòng đời phần mềm.

Đáp án đúng: "Pole Coverage". Độ phủ logic (logic coverage) là nhóm tiêu chí hộp trắng đo mức các cấu trúc logic của chương trình đã được thực thi. Các dạng chuẩn gồm độ phủ câu lệnh, độ phủ nhánh hay quyết định, độ phủ điều kiện, độ phủ kết hợp điều kiện và độ phủ đường đi. Không có tiêu chí nào gọi là pole coverage, nên đây là dạng không hợp lệ. "Statement Coverage" (độ phủ câu lệnh) là dạng cơ bản nhất, đo tỉ lệ câu lệnh đã chạy. "Condition Coverage" (độ phủ điều kiện) yêu cầu mỗi điều kiện đơn trong một biểu thức quyết định nhận cả giá trị đúng và sai. "Path Coverage" (độ phủ đường đi) yêu cầu thực thi mọi đường đi qua chương trình, là tiêu chí mạnh nhất trong nhóm nhưng thường không khả thi đầy đủ khi có vòng lặp. Cả ba đều là dạng hợp lệ nên không phải đáp án.

Một trong những lý do chính khiến các nhà phát triển gặp khó khăn khi kiểm tra công việc của mình là sự thiếu khách quan. Khi tự kiểm tra công việc của mình, các nhà phát triển thường có xu hướng nhìn nhận công việc của mình theo cách tích cực, bỏ qua các lỗi và hạn chế. Điều này dẫn đến việc kiểm tra không đầy đủ và hiệu quả, khiến các lỗi và hạn chế không được phát hiện và sửa chữa kịp thời. Sự thiếu khách quan này có thể được giải thích bởi sự gắn bó cảm xúc và tâm lý của các nhà phát triển với công việc của mình, cũng như sự khó khăn trong việc đánh giá công việc của mình một cách khách quan.

Maintenance releases và technical assistance centers là những ví dụ về chi phí chất lượng bên ngoài (External failure). Chi phí chất lượng bên ngoài là những chi phí liên quan đến việc sửa chữa hoặc khắc phục các lỗi hoặc vấn đề đã xảy ra trong quá trình sản xuất hoặc cung cấp dịch vụ. Maintenance releases và technical assistance centers là những ví dụ về chi phí chất lượng bên ngoài vì chúng liên quan đến việc sửa chữa hoặc khắc phục các lỗi hoặc vấn đề đã xảy ra trong quá trình sản xuất hoặc cung cấp dịch vụ. Maintenance releases là những bản cập nhật hoặc sửa đổi được thực hiện để sửa chữa các lỗi hoặc vấn đề đã xảy ra trong sản phẩm hoặc dịch vụ, trong khi technical assistance centers là những trung tâm hỗ trợ kỹ thuật cung cấp dịch vụ hỗ trợ khách hàng để sửa chữa hoặc khắc phục các lỗi hoặc vấn đề đã xảy ra.

Câu hỏi này liên quan đến khái niệm về hệ thống lỗi và các giai đoạn phát triển phần mềm. Hệ thống lỗi là một phần quan trọng trong việc đảm bảo chất lượng phần mềm và hiệu suất của nó. Trong quá trình phát triển phần mềm, các lỗi có thể xảy ra ở nhiều giai đoạn khác nhau, bao gồm giai đoạn yêu cầu (Requirements Phase), giai đoạn phân tích và thiết kế (Analysis and Design Phase), giai đoạn phát triển (Development Phase) và giai đoạn kiểm thử (Testing Phase). Tuy nhiên, theo thống kê và nghiên cứu, đa số các lỗi hệ thống thường xảy ra ở giai đoạn yêu cầu (Requirements Phase). Điều này là do giai đoạn yêu cầu là giai đoạn đầu tiên trong quá trình phát triển phần mềm, nơi mà các yêu cầu và yêu cầu chức năng của phần mềm được xác định. Nếu các yêu cầu không được xác định rõ ràng và chính xác, thì các lỗi hệ thống có thể xảy ra ngay từ đầu và ảnh hưởng đến toàn bộ quá trình phát triển phần mềm. Giai đoạn yêu cầu là giai đoạn quan trọng nhất trong quá trình phát triển phần mềm, vì nó quyết định chất lượng và hiệu suất của phần mềm. Vì vậy, việc xác định và quản lý các yêu cầu một cách chính xác và hiệu quả là rất quan trọng để giảm thiểu các lỗi hệ thống và đảm bảo chất lượng phần mềm. Tóm lại, đa số các lỗi hệ thống thường xảy ra ở giai đoạn yêu cầu (Requirements Phase) do các yêu cầu không được xác định rõ ràng và chính xác. Vì vậy, việc quản lý và xác định các yêu cầu một cách hiệu quả là rất quan trọng để đảm bảo chất lượng phần mềm và giảm thiểu các lỗi hệ thống.

Đáp án đúng: "Test Closure Activities". Theo quy trình kiểm thử cơ bản của ISTQB Foundation, hoạt động đóng kiểm thử (test closure activities) gồm kiểm tra sản phẩm bàn giao đã đủ chưa, đóng báo cáo sự cố, lập tài liệu chấp nhận hệ thống, hoàn thiện và lưu trữ testware, bàn giao testware cho bộ phận bảo trì (handover of testware), và rút kinh nghiệm cho các dự án sau. Bàn giao testware nằm đúng ở giai đoạn này vì chỉ diễn ra khi kiểm thử đã kết thúc. "Test Analysis and Design" là lúc rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Planning and control" là lúc xác định mục tiêu, phạm vi, cách tiếp cận và theo dõi tiến độ, điều chỉnh khi lệch kế hoạch. "Evaluating exit criteria and reporting" là lúc so kết quả thực thi với tiêu chí thoát và viết báo cáo tóm tắt, chưa phải lúc bàn giao.