Tất cả câu hỏi

Đáp án đúng: "Error guessing". Đoán lỗi (error guessing) là kỹ thuật kiểm thử động dựa trên kinh nghiệm: người kiểm thử dự đoán chỗ phần mềm hay sai rồi thiết kế ca kiểm thử để chạy chương trình nhắm vào chỗ đó, nên nó không phải kỹ thuật tĩnh. Kiểm thử tĩnh (static testing) đánh giá sản phẩm mà không thực thi mã, gồm rà soát và phân tích tĩnh. "Walkthrough" là duyệt qua do tác giả dẫn dắt, một loại rà soát nên là kỹ thuật tĩnh. "Inspections" là thanh tra, loại rà soát chính thức nhất, cũng là kỹ thuật tĩnh. "Data flow analysis" là phân tích luồng dữ liệu, thường do công cụ phân tích tĩnh thực hiện trên mã nguồn để tìm biến dùng trước khi gán hay gán mà không dùng, không cần chạy chương trình nên cũng thuộc nhóm tĩnh.

Regression testing nên được thực hiện trong các trường hợp sau: Mỗi tuần, Sau khi phần mềm đã thay đổi, Nhiều nhất có thể, Khi môi trường đã thay đổi, Khi người quản lý dự án cho phép. Mỗi một trong những trường hợp trên đều có lý do hợp lý để thực hiện regression testing. Ví dụ, nếu phần mềm đã thay đổi, thì cần phải kiểm tra lại để đảm bảo rằng những thay đổi đó không ảnh hưởng đến các chức năng hiện có. Nếu môi trường đã thay đổi, thì cũng cần phải kiểm tra lại để đảm bảo rằng phần mềm vẫn hoạt động đúng như mong đợi. Việc thực hiện regression testing thường xuyên sẽ giúp phát hiện ra các lỗi sớm và giảm thiểu thời gian và chi phí để sửa lỗi.

Để thiết kế thử nghiệm cho các lớp tương đương hợp lệ và biên giới hợp lệ, chúng ta cần xem xét các giá trị có thể xảy ra trong hệ thống kiểm soát tồn kho. Giá trị có thể là các số từ 10000 đến 99999. Trong các lựa chọn trên, chỉ có "10000, 99999" phù hợp với yêu cầu này vì nó bao gồm cả biên giới và lớp tương đương hợp lệ.

Khái niệm mức độ nghiêm trọng (severity) và mức độ ưu tiên (priority) trong kiểm thử phần mềm thường được nhầm lẫn với nhau. Tuy nhiên, chúng có ý nghĩa khác nhau. Mức độ nghiêm trọng của một lỗi (defect) ám chỉ tầm quan trọng của nó đối với người dùng cuối, trong khi mức độ ưu tiên của một lỗi phản ánh tác động của nó lên đội ngũ phát triển. Ví dụ, một lỗi nghiêm trọng có thể không ảnh hưởng đến trải nghiệm người dùng, nhưng lại gây khó khăn cho đội ngũ phát triển. Ngược lại, một lỗi có mức độ ưu tiên cao có thể không nghiêm trọng, nhưng lại cần được sửa chữa ngay lập tức để tránh ảnh hưởng đến kế hoạch phát triển. Do đó, việc hiểu rõ sự khác biệt giữa mức độ nghiêm trọng và mức độ ưu tiên là rất quan trọng để đảm bảo rằng các lỗi được sửa chữa một cách hiệu quả và kịp thời.

Pha yêu cầu là một phần quan trọng trong vòng đời phát triển phần mềm. Mục đích chính của pha này là để hiểu rõ được nhu cầu của người dùng và xác định rõ yêu cầu của dự án. Điều này giúp cho các nhà phát triển có thể xây dựng được sản phẩm đáp ứng được nhu cầu của người dùng. Trong pha yêu cầu, các nhà phát triển sẽ thu thập thông tin từ người dùng, phân tích và xác định rõ yêu cầu của dự án. Qua đó, họ có thể xây dựng được kế hoạch phát triển phần mềm phù hợp và hiệu quả.

Đáp án đúng: "Use of automated test execution tools". Kiểm thử chấp nhận của người dùng (user acceptance testing, UAT) nhằm xác nhận hệ thống phù hợp để người dùng nghiệp vụ sử dụng, do chính người dùng thực hiện trên các kịch bản nghiệp vụ thực tế. Đặc trưng của nó là con người đánh giá sự phù hợp, nên việc dùng công cụ tự động thực thi kiểm thử không phải đặc trưng của UAT; tự động hoá thường gắn với kiểm thử hồi quy, kiểm thử hiệu năng ở các cấp khác. "Testing performed by users." là đặc trưng cốt lõi, đúng như tên gọi. "Testing against acceptance test criteria" cũng là đặc trưng, vì UAT đối chiếu hệ thống với tiêu chí chấp nhận đã thống nhất để quyết định có nhận hệ thống hay không. "Integration of system with user documentation." cũng là đặc trưng, vì UAT kiểm tra hệ thống dùng được cùng tài liệu hướng dẫn sử dụng, quy trình nghiệp vụ thực tế.

Vấn đề này liên quan đến quản lý và kiểm soát các thành phần cấu hình trong một thư viện được kiểm soát. Thư viện này chứa tất cả các cấu hình vật thể. Để trả lời câu hỏi này, chúng ta cần hiểu các khái niệm liên quan. Configuration Control là quá trình kiểm soát và quản lý các thay đổi đối với các thành phần cấu hình. Status Accounting là quá trình theo dõi và cập nhật trạng thái của các thành phần cấu hình. Configuration Identification là quá trình xác định và phân loại các thành phần cấu hình. Trong trường hợp này, câu trả lời đúng là Configuration Control vì nó liên quan đến việc cung cấp và quản lý một thư viện được kiểm soát chứa tất cả các thành phần cấu hình.

Tính chất phần mềm không tốt thường bao gồm cả rủi ro dự án và rủi ro sản phẩm. Rủi ro dự án liên quan đến các vấn đề phát sinh trong quá trình triển khai dự án, chẳng hạn như vượt quá ngân sách, chậm tiến độ, hoặc không đáp ứng yêu cầu khách hàng. Rủi ro sản phẩm liên quan đến chất lượng của sản phẩm phần mềm, chẳng hạn như lỗi, không tương thích, hoặc không đáp ứng yêu cầu kỹ thuật. Vì vậy, lựa chọn đúng là cả rủi ro dự án và rủi ro sản phẩm.

Khi chọn công cụ, có một số nguyên tắc quan trọng cần tuân thủ. Trong số các lựa chọn trên, nguyên tắc không chính xác là "Hiểu rõ về công nghệ được sử dụng bởi các đối thủ cạnh tranh". Nguyên tắc này không phải là một trong những nguyên tắc chính cho việc chọn công cụ. Nguyên tắc chính bao gồm việc đánh giá công cụ dựa trên các yêu cầu và tiêu chí rõ ràng, ước tính tỷ lệ lợi ích và chi phí, và đánh giá độ chín muồi của tổ chức. Việc hiểu rõ về công nghệ của đối thủ cạnh tranh có thể hữu ích trong một số trường hợp, nhưng nó không phải là một trong những nguyên tắc cơ bản cho việc chọn công cụ.

Đáp án đúng: "Cultural difference". Khi kiểm thử phần mềm do nhà thầu bên ngoài phát triển (outsourced, contracted software), các rủi ro như mất quyền kiểm soát, khó điều chuyển nguồn lực, sản phẩm có thể không đáp ứng nhu cầu đều có mặt bất kể nhà thầu ở trong hay ngoài nước. Điểm khác biệt riêng khi nhà thầu ở nước ngoài là khác biệt văn hoá: ngôn ngữ, cách hiểu yêu cầu, thói quen làm việc, múi giờ, chuẩn mực giao tiếp, khiến yêu cầu dễ bị hiểu lệch và cần kiểm thử, đối chiếu kỹ hơn. "Does not meet people needs" là rủi ro chung của mọi phần mềm mua hoặc thuê làm, không phân biệt vị trí nhà thầu. "Loss of control over reallocation of resources" cũng xảy ra với nhà thầu trong nước, vì nguồn lực nằm ở phía nhà thầu. "Relinquishments of control" là việc từ bỏ quyền kiểm soát quy trình phát triển, đặc điểm chung của mọi hình thức thuê ngoài.

Mã code không thể tiếp cận thường được phát hiện tốt nhất bằng cách sử dụng công cụ kiểm tra bao phủ. Công cụ kiểm tra bao phủ là một công cụ giúp xác định phần mã code nào đã được thực hiện trong quá trình kiểm thử. Nó giúp phát hiện ra các phần code không được thực hiện, bao gồm cả code không thể tiếp cận. Code không thể tiếp cận là code được viết nhưng không bao giờ được thực hiện trong quá trình chạy chương trình. Nó có thể do nhiều lý do khác nhau, chẳng hạn như vị trí code nằm ngoài phạm vi kiểm thử, hoặc code bị lỗi và không thể thực hiện được. Công cụ kiểm tra bao phủ giúp phát hiện ra code không thể tiếp cận và giúp nhà phát triển sửa lỗi và hoàn thiện code.

Các công cụ phân tích tĩnh có thể phát hiện các lỗi sau: i. Biến không bao giờ được sử dụng. ii. Các lỗ hổng bảo mật. iii. Vi phạm tiêu chuẩn lập trình. iv. Các hàm và thủ tục không được gọi. Trong các lựa chọn trên, câu trả lời đúng là "1, ii, iii, iv là đúng" vì các công cụ phân tích tĩnh có thể phát hiện tất cả các lỗi này. Các công cụ này có thể giúp phát hiện các vấn đề tiềm ẩn trong mã nguồn, bao gồm cả các biến không được sử dụng, các lỗ hổng bảo mật và vi phạm tiêu chuẩn lập trình. Điều này giúp các nhà phát triển cải thiện chất lượng mã nguồn và giảm thiểu các vấn đề bảo mật.

Khi triển khai giải pháp ngân hàng trực tuyến, việc kiểm thử là một phần quan trọng để đảm bảo tính ổn định và hiệu suất của hệ thống. Trong đó, có bốn loại kiểm thử được đề cập trong câu hỏi: kiểm thử tích hợp hệ thống, kiểm thử chức năng, kiểm thử không chức năng và kiểm thử yêu cầu. Kiểm thử chức năng là quá trình kiểm tra xem các tính năng của hệ thống có hoạt động đúng như mong đợi hay không, bao gồm cả việc kiểm tra các giao dịch, thanh toán và quản lý tài khoản. Điều này giúp đảm bảo rằng hệ thống có thể xử lý các yêu cầu của khách hàng một cách chính xác và hiệu quả.

Đáp án đúng: "Available skills and experience in the proposed techniques.". Theo ISTQB, khi chọn cách tiếp cận kiểm thử (test approach) phải xét bối cảnh: rủi ro thất bại của dự án và sản phẩm, kỹ năng và kinh nghiệm của con người với kỹ thuật, công cụ, phương pháp đề xuất, mục tiêu kiểm thử, quy định pháp lý và bản chất sản phẩm; trong các yếu tố được nêu ở đây, kỹ năng và kinh nghiệm sẵn có quyết định trực tiếp việc kỹ thuật có áp dụng được hiệu quả hay không. "Availability of tools to support the proposed techniques." là yếu tố phụ: công cụ chỉ hỗ trợ, thiếu người biết dùng kỹ thuật thì công cụ không cứu được. "The budget allowed for training in proposed techniques." chỉ là cách bù đắp khi thiếu kỹ năng, không phải tiêu chí trung tâm. "The willingness of the test team to learn new techniques." là thái độ đáng quý nhưng không bảo đảm năng lực thực hiện ngay trong dự án hiện tại.

Để theo dõi tiến độ kiểm thử, có nhiều yếu tố quan trọng cần xem xét. Đầu tiên, phần trăm thực thi các trường hợp kiểm thử (i) giúp chúng ta đánh giá hiệu suất và tốc độ thực hiện các trường hợp kiểm thử. Thứ hai, phần trăm công việc đã hoàn thành trong việc chuẩn bị môi trường kiểm thử (ii) cho chúng ta biết tiến độ của dự án. Thứ ba, thông tin về lỗi, chẳng hạn như mật độ lỗi, số lỗi đã tìm thấy và sửa chữa (iii) giúp chúng ta đánh giá chất lượng sản phẩm. Cuối cùng, kích thước của đội kiểm thử và kỹ năng của kỹ sư (iv) cũng rất quan trọng vì nó ảnh hưởng đến hiệu suất và chất lượng của quá trình kiểm thử.

Các trường hợp kiểm thử được tạo từ các trường hợp sử dụng thường được sử dụng để phát hiện các lỗi trong quá trình luồng làm việc trong môi trường thực tế của hệ thống. Điều này có nghĩa là các trường hợp kiểm thử này được tạo dựa trên cách người dùng thực tế sẽ tương tác với hệ thống, giúp phát hiện các lỗi và vấn đề trong quá trình sử dụng thực tế. Điều này giúp đảm bảo rằng hệ thống hoạt động đúng cách và đáp ứng được nhu cầu của người dùng.

Kết quả mong đợi của một thử nghiệm được định nghĩa là những gì xảy ra khi một thử nghiệm được thực hiện. Nó là kết quả cuối cùng của quá trình thử nghiệm, bao gồm cả dữ liệu đầu vào và dữ liệu đầu ra. Kết quả của một thử nghiệm thường được thể hiện dưới dạng số liệu, hình ảnh hoặc các thông tin khác. Để xác định kết quả mong đợi của một thử nghiệm, người ta thường sử dụng các phương pháp như mô hình hóa, phân tích dữ liệu và đánh giá. Kết quả của một thử nghiệm có thể được sử dụng để đánh giá hiệu suất của một hệ thống, sản phẩm hoặc quy trình. Nó cũng có thể được sử dụng để xác định nguyên nhân của một vấn đề và tìm ra giải pháp.

Hệ thống quản lý yêu cầu (Requirements Management Tools) là công cụ giúp lưu trữ các tuyên bố yêu cầu, kiểm tra tính nhất quán và cho phép sắp xếp ưu tiên các yêu cầu. Đồng thời, nó cho phép từng thử nghiệm riêng biệt có thể được theo dõi đến các yêu cầu, chức năng và tính năng. Hệ thống này giúp đảm bảo rằng các yêu cầu được quản lý một cách hiệu quả và chính xác, từ đó giúp giảm thiểu các sai sót trong quá trình phát triển phần mềm.

Đáp án đúng: "Preventative tests are designed early; reactive tests are designed after the software has been produced.". ISTQB Foundation phân loại cách tiếp cận kiểm thử theo thời điểm thiết kế ca kiểm thử: cách tiếp cận phòng ngừa (preventative) thiết kế kiểm thử càng sớm càng tốt, ngay từ khi có yêu cầu và thiết kế, để ngăn lỗi lọt vào sản phẩm; cách tiếp cận phản ứng (reactive) chỉ thiết kế kiểm thử sau khi phần mềm đã được làm ra, phản ứng với sản phẩm thực tế, ví dụ kiểm thử thăm dò. Khác biệt then chốt vì vậy là thời điểm. "Preventative tests and reactive tests are designed as early as possible." sai vì xoá mất khác biệt, gán cả hai vào thiết kế sớm. "Preventative testing is always analytical; reactive testing is always heuristic." sai vì phân tích (analytical) hay dựa kinh nghiệm (heuristic) là một trục phân loại chiến lược khác, không gắn cứng với phòng ngừa hay phản ứng. "Preventative tests are designed after the software has been produced; reactive tests are designed early in response to review comments." đảo ngược hai định nghĩa.

Phương pháp kiểm thử chức năng có thể được thực hiện ở tất cả các mức độ kiểm thử. Điều này bao gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận. Mục đích của kiểm thử chức năng là đảm bảo rằng sản phẩm hoặc hệ thống đáp ứng các yêu cầu chức năng và yêu cầu của người dùng. Kiểm thử chức năng có thể được thực hiện ở tất cả các mức độ kiểm thử vì nó giúp xác định và sửa lỗi chức năng sớm trong quá trình phát triển sản phẩm. Điều này giúp tiết kiệm thời gian và chi phí trong dài hạn.