Tất cả câu hỏi

Severity và priority là hai khái niệm quan trọng trong quy trình kiểm thử phần mềm. Severity thường được định nghĩa là mức độ ảnh hưởng của một lỗi đến hệ thống hoặc người dùng cuối cùng. Điều này có thể bao gồm mức độ nghiêm trọng của lỗi, mức độ ảnh hưởng đến hiệu suất hoặc mức độ ảnh hưởng đến trải nghiệm người dùng. Ví dụ, một lỗi nghiêm trọng có thể khiến hệ thống không thể hoạt động hoặc gây ra thiệt hại tài chính cho người dùng. Priority, mặt khác, thường được định nghĩa là mức độ ưu tiên của việc sửa lỗi. Điều này có thể dựa trên mức độ ảnh hưởng của lỗi, nhưng cũng có thể dựa trên các yếu tố khác như thời gian còn lại trước khi phát hành sản phẩm, mức độ phức tạp của việc sửa lỗi hoặc mức độ ảnh hưởng đến doanh thu. Ví dụ, một lỗi có mức độ ảnh hưởng cao nhưng có thể sửa được nhanh chóng có thể được ưu tiên cao hơn một lỗi có mức độ ảnh hưởng thấp nhưng cần thời gian và công sức để sửa. Do đó, severity và priority không phải là hai khái niệm tương đương, mà là hai khái niệm khác nhau phục vụ cho mục đích khác nhau trong quy trình kiểm thử phần mềm. Tóm lại, severity và priority là hai khái niệm quan trọng trong quy trình kiểm thử phần mềm, phục vụ cho mục đích khác nhau. Severity được định nghĩa là mức độ ảnh hưởng của một lỗi đến hệ thống hoặc người dùng cuối cùng, trong khi priority được định nghĩa là mức độ ưu tiên của việc sửa lỗi.

Testing là một phần quan trọng trong quy trình phát triển phần mềm, và mục đích chính của nó là xác định xem phần mềm có hoạt động đúng như dự kiến hay không. Trong bốn lựa chọn trên, câu trả lời đúng là "Testing is executing Software for the purpose of finding defects". Điều này có nghĩa là mục đích của testing là thực hiện phần mềm để tìm kiếm các lỗi hoặc sai sót trong nó. Điều này giúp phát triển phần mềm ổn định và hiệu quả hơn. Các lựa chọn khác, mặc dù có liên quan đến testing, nhưng không chính xác về mục đích chính của nó. Ví dụ, "The goal of testing is to demonstrate that the program works" chỉ là một phần của mục đích testing, nhưng không bao quát được tất cả. "The purpose of testing is to demonstrate that the program is defect free" cũng không chính xác, vì testing không thể đảm bảo rằng phần mềm hoàn toàn không có lỗi. Cuối cùng, "The purpose of testing is to demonstrate that the program does what it is supposed to do" cũng không đúng, vì mục đích chính của testing là tìm kiếm các lỗi, chứ không phải chỉ là đảm bảo rằng phần mềm hoạt động đúng như dự kiến.

Impact analysis là một kỹ thuật được sử dụng trong kiểm thử phần mềm để đánh giá tác động của một thay đổi hoặc một lỗi vào hệ thống. Trong bối cảnh kiểm thử lặp lại (regression testing), impact analysis giúp xác định xem một lỗi đã được sửa chữa đúng cách hay chưa. Nói cách khác, impact analysis giúp đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại hay không. Trong câu hỏi này, có bốn lựa chọn khác nhau, nhưng chỉ có một lựa chọn đúng. Lựa chọn đúng là: "Impact analysis assesses the effect of a change to the system to determine how much regression testing to do". Điều này có nghĩa là impact analysis giúp đánh giá tác động của một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại bao nhiêu. Lựa chọn sai là: "Impact analysis assesses the effect on the system of a defect found in regression testing". Điều này có nghĩa là impact analysis chỉ giúp đánh giá tác động của một lỗi vào hệ thống, nhưng không giúp xác định xem cần phải thực hiện kiểm thử lặp lại hay không. Lựa chọn sai khác là: "Impact analysis assesses the effect of a new person joining the regression test team". Điều này có nghĩa là impact analysis giúp đánh giá tác động của một người mới tham gia vào đội kiểm thử lặp lại, nhưng không liên quan đến việc đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống. Lựa chọn sai cuối cùng là: "Impact analysis assesses whether or not a defect found in regression testing has been fixed correctly". Điều này có nghĩa là impact analysis giúp đánh giá xem một lỗi đã được sửa chữa đúng cách hay chưa, nhưng không liên quan đến việc đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống. Tóm lại, impact analysis là một kỹ thuật quan trọng trong kiểm thử phần mềm giúp đánh giá tác động của một lỗi hoặc một thay đổi vào hệ thống để xác định xem cần phải thực hiện kiểm thử lặp lại hay không.

Mức độ rủi ro của một sự kiện bất lợi được xác định bởi hai yếu tố chính: khả năng xảy ra sự kiện (likelihood) và tác động của sự kiện (impact). Khả năng xảy ra sự kiện đề cập đến xác suất xảy ra sự kiện, trong khi tác động của sự kiện đề cập đến mức độ ảnh hưởng của sự kiện nếu nó xảy ra. Ví dụ, một sự kiện có khả năng xảy ra cao nhưng tác động thấp có thể không được coi là rủi ro cao. Ngược lại, một sự kiện có khả năng xảy ra thấp nhưng tác động cao có thể được coi là rủi ro cao. Do đó, mức độ rủi ro của một sự kiện được xác định bởi sự kết hợp của hai yếu tố này.

Khi thiết kế thử nghiệm sớm trong vòng đời, lợi ích chính là ngăn chặn các lỗi được đưa vào mã nguồn. Điều này đạt được bằng cách xác định và sửa lỗi ngay từ đầu, trước khi mã nguồn trở nên phức tạp hơn. Thiết kế thử nghiệm sớm giúp phát hiện và sửa lỗi ngay từ đầu, giảm thiểu số lượng lỗi cần sửa trong giai đoạn sau. Ngoài ra, thiết kế thử nghiệm sớm cũng giúp cải thiện chất lượng mã nguồn, giảm thiểu thời gian và chi phí cần thiết để sửa lỗi. Điều này giúp tiết kiệm thời gian và chi phí trong giai đoạn thử nghiệm sau này. Thiết kế thử nghiệm sớm cũng giúp tăng cường sự tin tưởng của khách hàng vào sản phẩm, vì sản phẩm đã được kiểm tra kỹ lưỡng và đảm bảo chất lượng.

Khi đánh giá một sản phẩm phần mềm, mục tiêu chính là xác định các lỗi hoặc sai sót trong sản phẩm đó. Điều này bao gồm việc kiểm tra các sản phẩm phần mềm như yêu cầu, thiết kế, mã nguồn, tài liệu và các sản phẩm khác. Mục tiêu này là nhằm đảm bảo rằng sản phẩm phần mềm đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra. Trong quá trình đánh giá, người đánh giá sẽ sử dụng các kỹ thuật và công cụ khác nhau để xác định các lỗi hoặc sai sót trong sản phẩm phần mềm. Điều này có thể bao gồm việc kiểm tra mã nguồn, chạy thử nghiệm, kiểm tra lỗi và các kỹ thuật khác. Mục tiêu chính là đảm bảo rằng sản phẩm phần mềm là chất lượng cao và đáp ứng được các yêu cầu của khách hàng.

Khi đánh giá sự khác biệt giữa việc kiểm tra phần mềm được phát triển bởi một nhà thầu bên ngoài quốc gia của bạn và phần mềm được phát triển bởi một nhà thầu bên trong quốc gia của bạn, cần xem xét nhiều yếu tố. Thứ nhất, sự khác biệt về văn hóa có thể là một yếu tố quan trọng. Các nhà thầu bên ngoài quốc gia của bạn có thể có nền tảng văn hóa, ngôn ngữ và quy trình làm việc khác biệt so với các nhà thầu bên trong quốc gia của bạn. Điều này có thể ảnh hưởng đến cách họ tiếp cận và giải quyết các vấn đề, cũng như cách họ tương tác với bạn và các thành viên khác trong dự án. Ví dụ, các nhà thầu bên ngoài có thể có cách tiếp cận linh hoạt hơn, nhưng cũng có thể gặp khó khăn trong việc hiểu và thích nghi với quy trình và quy định của quốc gia bạn. Ngược lại, các nhà thầu bên trong có thể có kiến thức sâu sắc hơn về văn hóa và quy trình của quốc gia bạn, nhưng cũng có thể bị hạn chế bởi các quy định và quy trình hiện có. Thứ hai, sự khác biệt về kiểm soát và quản lý cũng là một yếu tố quan trọng. Khi làm việc với các nhà thầu bên ngoài, bạn có thể gặp khó khăn trong việc kiểm soát và quản lý dự án, đặc biệt là khi họ không có kinh nghiệm làm việc với quốc gia của bạn. Ngược lại, khi làm việc với các nhà thầu bên trong, bạn có thể có nhiều quyền kiểm soát hơn và quản lý dự án dễ dàng hơn. Tuy nhiên, điều này cũng có thể dẫn đến sự phụ thuộc quá mức vào các nhà thầu bên trong và giảm khả năng linh hoạt của dự án. Cuối cùng, sự khác biệt về chi phí và thời gian cũng là một yếu tố quan trọng. Các nhà thầu bên ngoài có thể cung cấp giá cả cạnh tranh hơn, nhưng cũng có thể mất nhiều thời gian hơn để hoàn thành dự án. Ngược lại, các nhà thầu bên trong có thể mất nhiều thời gian hơn để hoàn thành dự án, nhưng cũng có thể cung cấp giá cả cạnh tranh hơn. Tóm lại, sự khác biệt giữa việc kiểm tra phần mềm được phát triển bởi một nhà thầu bên ngoài quốc gia của bạn và phần mềm được phát triển bởi một nhà thầu bên trong quốc gia của bạn phụ thuộc vào nhiều yếu tố, bao gồm sự khác biệt về văn hóa, kiểm soát và quản lý, cũng như chi phí và thời gian.

Khái niệm preventative và reactive trong testing liên quan đến thời điểm và mục đích của các bài kiểm tra. Preventative testing là quá trình kiểm tra được thực hiện trước khi sản phẩm hoặc phần mềm được phát hành, nhằm phát hiện và sửa lỗi ngay từ đầu. Điều này giúp giảm thiểu rủi ro và đảm bảo chất lượng sản phẩm. Ngược lại, reactive testing là quá trình kiểm tra được thực hiện sau khi sản phẩm hoặc phần mềm đã được phát hành, nhằm phát hiện và sửa lỗi đã tồn tại. Preventative testing thường được thiết kế sớm hơn reactive testing, vì nó giúp ngăn chặn các vấn đề tiềm ẩn và đảm bảo chất lượng sản phẩm ngay từ đầu. Trong khi đó, reactive testing thường được thiết kế sau khi sản phẩm hoặc phần mềm đã được phát hành, nhằm đáp ứng các yêu cầu và phản hồi từ khách hàng.

Việc kiểm tra phần mềm trước khi phát hành là một phần quan trọng của quy trình phát triển phần mềm. Mục đích chính của việc kiểm tra phần mềm trước khi phát hành là để quyết định khi nào phần mềm đã đạt được chất lượng đủ để phát hành. Điều này có nghĩa là các nhà phát triển và kiểm tra viên sẽ kiểm tra phần mềm để đảm bảo rằng nó hoạt động đúng, không có lỗi và đáp ứng các yêu cầu của khách hàng. Việc kiểm tra phần mềm trước khi phát hành giúp giảm thiểu rủi ro phát hành phần mềm không ổn định hoặc không đáp ứng được yêu cầu của khách hàng. Ngoài ra, việc kiểm tra phần mềm trước khi phát hành cũng giúp tiết kiệm thời gian và tiền bạc trong dài hạn bằng cách phát hiện và sửa lỗi sớm.

Equivalence partition (hay còn gọi là lớp tương đương) là một khái niệm quan trọng trong lĩnh vực kiểm thử phần mềm. Nó được định nghĩa là một tập hợp các giá trị đầu vào hoặc đầu ra có tính tương đương, nghĩa là các giá trị này có thể được nhóm lại thành một lớp duy nhất dựa trên tính chất tương tự của chúng. Mục đích của việc phân tích lớp tương đương là xác định các trường hợp thử nghiệm cần thiết để đảm bảo rằng phần mềm hoạt động đúng cách trong mọi tình huống có thể xảy ra. Trong quá trình kiểm thử, các lớp tương đương được sử dụng để xác định các giá trị đầu vào hoặc đầu ra có thể được nhóm lại thành một lớp duy nhất, từ đó chỉ cần thực hiện các trường hợp thử nghiệm cho lớp đó thay vì từng giá trị riêng lẻ. Điều này giúp giảm thiểu số lượng trường hợp thử nghiệm cần thực hiện và tăng hiệu quả của quá trình kiểm thử.

Informal review là một quá trình đánh giá không chính thức, thường được sử dụng trong các dự án hoặc công việc để đánh giá chất lượng và hiệu suất của một sản phẩm, dự án hoặc dịch vụ. Mục đích chính của Informal review là tìm kiếm một cách nhanh chóng và hiệu quả về lợi ích mà không cần phải đầu tư quá nhiều thời gian và nguồn lực. Điều này giúp cho các bên liên quan có thể nhận được phản hồi và đánh giá nhanh chóng, từ đó có thể điều chỉnh và cải thiện sản phẩm hoặc dự án một cách kịp thời.

Để xác định số lượng thử nghiệm cần thiết cho đoạn mã pseudo-code đã cho, chúng ta cần phân tích từng phần của đoạn mã và xác định các điểm kiểm tra cần thiết.

Test estimation, test control và test monitoring là ba khái niệm quan trọng trong quản lý thử nghiệm phần mềm. Test estimation liên quan đến việc ước tính thời gian và nguồn lực cần thiết để thực hiện các hoạt động thử nghiệm. Điều này bao gồm việc ước tính số lượng thử nghiệm cần thực hiện, thời gian cần thiết để thực hiện từng thử nghiệm và nguồn lực cần thiết để hỗ trợ quá trình thử nghiệm. Test control liên quan đến việc quản lý và điều chỉnh quá trình thử nghiệm để đảm bảo rằng mục tiêu thử nghiệm được đạt được. Điều này bao gồm việc phân bổ nguồn lực, quản lý thời gian và đảm bảo rằng quá trình thử nghiệm được thực hiện một cách hiệu quả. Test monitoring liên quan đến việc theo dõi và đánh giá quá trình thử nghiệm để đảm bảo rằng mục tiêu thử nghiệm được đạt được. Điều này bao gồm việc theo dõi tiến độ, đánh giá hiệu suất và thực hiện các điều chỉnh cần thiết để quá trình thử nghiệm hiệu quả. Vì vậy, đáp án đúng là ['1-b, 2-c, 3-a'], vì test estimation liên quan đến việc ước tính thời gian và nguồn lực cần thiết (b), test control liên quan đến việc quản lý và điều chỉnh quá trình thử nghiệm (c) và test monitoring liên quan đến việc theo dõi và đánh giá (a).

Cyclomatic complexity là một thước đo độ phức tạp của mã nguồn, được định nghĩa bởi Thomas J. McCabe Jr. vào năm 1976. Nó được sử dụng để đo độ phức tạp của một đoạn mã nguồn dựa trên số lượng đường đi độc lập (independent paths) mà đoạn mã đó có thể thực hiện. Các biến số chính trong công thức Cyclomatic complexity bao gồm L (số lượng đường đi hoặc liên kết), N (số lượng nút hoặc node) và P (số lượng đường đi độc lập). Công thức Cyclomatic complexity được định nghĩa như sau: V(G) = L - N + P, trong đó V(G) là độ phức tạp của đồ thị G. Công thức này cho thấy rằng độ phức tạp của một đoạn mã nguồn tăng lên khi số lượng đường đi hoặc liên kết (L) tăng lên, nhưng giảm xuống khi số lượng nút hoặc node (N) tăng lên. Trong trường hợp của câu hỏi, chúng ta được yêu cầu chọn công thức đúng cho Cyclomatic complexity. Các lựa chọn bao gồm: - L - N + 2P - N - L + 2P - N - L + P - L + N - P Sau khi phân tích, chúng ta thấy rằng công thức đúng cho Cyclomatic complexity là L - N + 2P. Công thức này cho thấy rằng độ phức tạp của một đoạn mã nguồn tăng lên khi số lượng đường đi hoặc liên kết (L) tăng lên, nhưng giảm xuống khi số lượng nút hoặc node (N) tăng lên, và tăng lên khi số lượng đường đi độc lập (P) tăng lên. Tóm lại, công thức Cyclomatic complexity là một công cụ quan trọng để đo độ phức tạp của mã nguồn, và công thức đúng cho nó là L - N + 2P.

Test Implementation and execution là một phần quan trọng trong quy trình kiểm thử phần mềm. Nó bao gồm các nhiệm vụ chính như sau: - Phát triển và ưu tiên các trường hợp kiểm thử (i): Đây là bước đầu tiên trong quy trình kiểm thử, nơi các kỹ sư kiểm thử sẽ xác định các trường hợp kiểm thử cần thực hiện để đảm bảo rằng phần mềm đáp ứng các yêu cầu và tiêu chuẩn. - Tạo bộ kiểm thử (ii): Sau khi phát triển các trường hợp kiểm thử, bước tiếp theo là tạo bộ kiểm thử từ các trường hợp kiểm thử này. Bộ kiểm thử sẽ bao gồm các trường hợp kiểm thử đã được xác định và sắp xếp theo thứ tự ưu tiên. - Xác minh môi trường kiểm thử (iii): Trước khi thực hiện kiểm thử, cần đảm bảo rằng môi trường kiểm thử đã được thiết lập đúng cách. Điều này bao gồm việc cài đặt các công cụ và phần mềm cần thiết, cũng như cấu hình các thiết bị và hệ thống. - Xác định tiêu chí thoát (iv): Tiêu chí thoát là các điều kiện cần thiết để kết thúc kiểm thử. Nó có thể bao gồm việc đạt được một số kết quả nhất định, hoặc việc phát hiện ra một số lỗi nhất định. Tóm lại, Test Implementation and execution có các nhiệm vụ chính như phát triển và ưu tiên các trường hợp kiểm thử, tạo bộ kiểm thử, xác minh môi trường kiểm thử và xác định tiêu chí thoát. Do đó, đáp án đúng là "i, ii, iii are true and iv is false".

Các công cụ được đề cập trong câu hỏi bao gồm: (i) Công cụ kiểm tra hiệu suất, (ii) Công cụ đo lường độ bao phủ, (iii) Công cụ so sánh thử nghiệm, (iv) Công cụ phân tích động và (v) Công cụ quản lý sự cố. Để xác định những công cụ nào được thiết kế cho mục đích sử dụng của nhà phát triển, chúng ta cần xem xét từng loại công cụ một cách cụ thể. (i) Công cụ kiểm tra hiệu suất được sử dụng để đo lường hiệu suất của một hệ thống hoặc ứng dụng. Mặc dù nó có thể hữu ích cho các nhà phát triển, nhưng nó không phải là công cụ được thiết kế đặc biệt cho họ. (ii) Công cụ đo lường độ bao phủ được sử dụng để đo lường mức độ bao phủ của mã nguồn. Điều này giúp các nhà phát triển xác định các khu vực của mã nguồn cần được cải thiện. Công cụ này được thiết kế đặc biệt cho các nhà phát triển. (iii) Công cụ so sánh thử nghiệm được sử dụng để so sánh kết quả của các thử nghiệm khác nhau. Mặc dù nó có thể hữu ích cho các nhà phát triển, nhưng nó không phải là công cụ được thiết kế đặc biệt cho họ. (iv) Công cụ phân tích động được sử dụng để phân tích mã nguồn trong thời gian thực. Điều này giúp các nhà phát triển xác định các vấn đề trong mã nguồn và cải thiện hiệu suất. Công cụ này được thiết kế đặc biệt cho các nhà phát triển. (v) Công cụ quản lý sự cố được sử dụng để quản lý và giải quyết các sự cố trong hệ thống hoặc ứng dụng. Mặc dù nó có thể hữu ích cho các nhà phát triển, nhưng nó không phải là công cụ được thiết kế đặc biệt cho họ. Tóm lại, các công cụ được thiết kế đặc biệt cho các nhà phát triển là (ii) Công cụ đo lường độ bao phủ và (iv) Công cụ phân tích động. Do đó, câu trả lời đúng là "ii và iv là những công cụ dành cho các nhà phát triển".

Validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Trong quá trình phát triển sản phẩm, validation giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn, giúp giảm thiểu các lỗi và sai sót. Điều này giúp đảm bảo rằng sản phẩm cuối cùng được xây dựng là đúng và đáp ứng được các yêu cầu của khách hàng. Validation không chỉ giúp kiểm tra chất lượng sản phẩm mà còn giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Điều này giúp giảm thiểu các lỗi và sai sót trong quá trình phát triển sản phẩm. Trong khi đó, các lựa chọn khác không chính xác. Lựa chọn i nói rằng validation giúp kiểm tra chất lượng sản phẩm, nhưng điều này không hoàn toàn chính xác. Validation không chỉ giúp kiểm tra chất lượng sản phẩm mà còn giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Lựa chọn iii nói rằng validation giúp phát triển sản phẩm, nhưng điều này không chính xác. Validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn, không phải là quá trình phát triển sản phẩm. Lựa chọn iv nói rằng validation giúp theo dõi công cụ bị hao mòn và lỗi thời, nhưng điều này không liên quan đến validation. Validation chỉ liên quan đến quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Tóm lại, validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Lựa chọn ii là đúng, còn các lựa chọn khác không chính xác.

Configuration Management (CM) là một phần quan trọng của quá trình kiểm thử phần mềm. Từ góc độ kiểm thử, mục đích chính của CM là đảm bảo rằng các thành phần phần mềm và testware được quản lý và kiểm soát một cách hiệu quả. Điều này bao gồm việc quản lý phiên bản của phần mềm và testware, theo dõi các thay đổi và đảm bảo rằng các thành phần được sử dụng trong quá trình kiểm thử là chính xác và đáng tin cậy. Mục đích chính của CM trong kiểm thử là (i) xác định phiên bản của phần mềm đang được kiểm thử, (ii) kiểm soát phiên bản của các item testware và (iv) theo dõi các thay đổi đến các item testware. Điều này giúp đảm bảo rằng các thử nghiệm được thực hiện trên phiên bản phần mềm và testware chính xác, và rằng các thay đổi được theo dõi và quản lý một cách hiệu quả. Các mục đích khác như (iii) phát triển các item testware mới và (v) phân tích nhu cầu mới của các item testware là quan trọng nhưng không phải là mục đích chính của CM trong kiểm thử.

Exit Criteria là các tiêu chí để quyết định khi nào một dự án thử nghiệm hoặc kiểm thử đã đạt được yêu cầu. Trong trường hợp này, có bốn lựa chọn được đề cập: (i) Thoroughness measures: Đây là các chỉ số đo độ đầy đủ của thử nghiệm, bao gồm cả việc kiểm tra code, chức năng hoặc rủi ro. Các chỉ số này giúp đảm bảo rằng thử nghiệm đã được thực hiện một cách đầy đủ và toàn diện. (ii) Estimates of Defect density hoặc reliability measures: Đây là các ước tính về mật độ lỗi hoặc các chỉ số đo độ tin cậy của hệ thống. Các chỉ số này giúp đánh giá khả năng xảy ra lỗi trong hệ thống và đảm bảo rằng hệ thống đã được kiểm tra một cách đầy đủ. (iii) Residual risk: Đây là các rủi ro còn lại sau khi thử nghiệm đã được thực hiện. Các rủi ro này có thể bao gồm các lỗi chưa được phát hiện hoặc các khu vực chưa được kiểm tra đầy đủ. (iv) Verifying the Test Environment: Đây là việc xác minh môi trường thử nghiệm. Môi trường thử nghiệm là nơi mà thử nghiệm được thực hiện, và việc xác minh môi trường này giúp đảm bảo rằng thử nghiệm được thực hiện một cách chính xác và đáng tin cậy. Dựa trên các lựa chọn trên, có thể thấy rằng Exit Criteria có thể bao gồm cả Thoroughness measures, Estimates of Defect density hoặc reliability measures và Residual risk. Tuy nhiên, Verifying the Test Environment không phải là một Exit Criteria. Vì vậy, đáp án đúng là: i, ii, iii are correct và iv là incorrect.

Static analysis là một kỹ thuật kiểm tra mã nguồn bằng cách phân tích mã mà không cần thực thi nó. Mục đích của static analysis là tìm kiếm các lỗi hoặc vấn đề trong mã nguồn trước khi nó được triển khai. Trong câu hỏi này, chúng ta được hỏi về các loại lỗi mà các công cụ phân tích tĩnh (static analysis tools) có thể phát hiện. Lựa chọn (i) Variables that are never used: Các biến không bao giờ được sử dụng là một loại lỗi phổ biến trong mã nguồn. Các công cụ phân tích tĩnh có thể phát hiện các biến này bằng cách phân tích mã nguồn và xác định các biến không được sử dụng. Lựa chọn (ii) Security vulnerabilities: Các lỗ hổng bảo mật là một loại lỗi nghiêm trọng trong mã nguồn. Các công cụ phân tích tĩnh có thể phát hiện các lỗ hổng bảo mật bằng cách phân tích mã nguồn và xác định các lỗ hổng có thể được khai thác bởi kẻ tấn công. Lựa chọn (iii) Programming Standard Violations: Các vi phạm tiêu chuẩn lập trình là một loại lỗi trong mã nguồn. Các công cụ phân tích tĩnh có thể phát hiện các vi phạm tiêu chuẩn lập trình bằng cách phân tích mã nguồn và xác định các vi phạm tiêu chuẩn lập trình. Lựa chọn (iv) Uncalled functions and procedures: Các hàm và thủ tục không được gọi là một loại lỗi trong mã nguồn. Các công cụ phân tích tĩnh có thể phát hiện các hàm và thủ tục không được gọi bằng cách phân tích mã nguồn và xác định các hàm và thủ tục không được gọi. Tóm lại, các lựa chọn (i), (ii), (iii) và (iv) đều là đúng. Các công cụ phân tích tĩnh có thể phát hiện các lỗi này bằng cách phân tích mã nguồn và xác định các lỗi có thể xảy ra trong mã nguồn.