Câu hỏi: SWT301 - Phần 2: Kiểm thử trong vòng đời phát triển

Phương pháp kiểm tra được sử dụng để xác minh rằng hệ thống có thể hoạt động đúng khi giới hạn nội bộ của chương trình hoặc hệ thống đã được vượt quá là Stress Testing. Stress Testing là một loại thử nghiệm được thiết kế để đánh giá khả năng chịu đựng của hệ thống khi nó được đặt dưới áp lực cao. Điều này có thể bao gồm việc gửi một lượng lớn dữ liệu vào hệ thống, tạo ra một lượng lớn yêu cầu đồng thời hoặc thử nghiệm hệ thống với các dữ liệu không bình thường. Mục tiêu của Stress Testing là xác minh rằng hệ thống có thể hoạt động đúng ngay cả khi nó được đặt dưới áp lực cao và có thể xử lý được các yêu cầu mà không bị lỗi hoặc gián đoạn.

Sara, loại kiểm tra nào sau đây là một loại kiểm tra?

Một thử nghiệm hồi quy (regression test) là một loại thử nghiệm được sử dụng để xác minh rằng các phần của phần mềm chưa được thay đổi vẫn hoạt động bình thường sau khi thực hiện các thay đổi. Mục đích chính của thử nghiệm hồi quy là đảm bảo rằng các phần của phần mềm chưa được thay đổi không bị ảnh hưởng bởi các thay đổi mới. Điều này giúp đảm bảo rằng phần mềm vẫn hoạt động đúng và không có bất kỳ lỗi nào. Thử nghiệm hồi quy thường được thực hiện tự động và được chạy thường xuyên để đảm bảo rằng phần mềm luôn hoạt động tốt.

Một trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống. Điều này có nghĩa là một yêu cầu không chức năng quan trọng đã không được chỉ định và kiểm tra. Trong khi các yêu cầu chức năng thường tập trung vào các tính năng và chức năng của hệ thống, các yêu cầu không chức năng lại tập trung vào các tính chất của hệ thống như hiệu suất, độ tin cậy, khả năng mở rộng, bảo mật, v.v. Trong trường hợp này, trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống là một yêu cầu không chức năng quan trọng mà không được chỉ định và kiểm tra. Điều này có thể dẫn đến hệ thống không thể xử lý được số lượng người dùng lớn, gây ra sự cố và ảnh hưởng đến hiệu suất của hệ thống.

Khái niệm re-testing và regression testing thường được sử dụng trong lĩnh vực kiểm thử phần mềm. Re-testing là quá trình chạy lại các thử nghiệm đã thực hiện trước đó để đảm bảo rằng các vấn đề đã được sửa chữa. Trong khi đó, regression testing là quá trình kiểm tra lại các phần mềm đã được sửa chữa để đảm bảo rằng các thay đổi không gây ra các tác động phụ không mong muốn. Cụ thể, re-testing là chạy lại các thử nghiệm một lần nữa, trong khi regression testing tìm kiếm các tác động phụ không mong muốn. Điều này cho thấy rằng re-testing và regression testing có mục đích và phạm vi khác nhau trong quá trình kiểm thử phần mềm.

Mỗi giai đoạn trong vòng đời phát triển phần mềm cần được khớp với vòng đời kiểm thử như sau: - Giai đoạn thu thập yêu cầu kinh doanh (Business requirements) nên được kiểm thử bằng các bài kiểm thử chấp nhận (Acceptance tests). - Giai đoạn thiết kế tổng quan (High-level design) nên được kiểm thử bằng các bài kiểm thử tích hợp (Integration tests). - Giai đoạn thiết kế chi tiết (Low-level design) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). - Giai đoạn viết mã (Code) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). Vậy đáp án đúng là: Integration tests i-c, ii-a, iii-d, iv-b.

Đáp án đúng: "Non-functional testing.". Bảo mật, hiệu năng, độ tin cậy và khả năng sử dụng là các đặc tính chất lượng mô tả hệ thống hoạt động tốt tới mức nào chứ không phải hệ thống làm gì; kiểm thử phi chức năng (non-functional testing) là loại kiểm thử đánh giá chính các đặc tính đó, ví dụ hệ thống ngân hàng trực tuyến phải chịu được nhiều người đăng nhập cùng lúc và chống được truy cập trái phép. "Functional testing" kiểm tra các chức năng như chuyển khoản, tra số dư có cho kết quả đúng không, không đo thuộc tính chất lượng. "System integration" là kiểm thử tích hợp hệ thống, xét tương tác với hệ thống bên ngoài như cổng thanh toán, là một cấp kiểm thử chứ không phải loại kiểm thử hướng vào thuộc tính chất lượng. "Requirements testing" là kiểm thử dựa trên yêu cầu, một cách lấy cơ sở kiểm thử, không gắn riêng với nhóm thuộc tính nào.

Đáp án đúng: "System Testing". Kiểm thử hệ thống (system testing) là cấp kiểm thử trên toàn bộ hệ thống đã tích hợp, kiểm tra cả yêu cầu chức năng lẫn phi chức năng như hiệu năng, bảo mật, tính dùng được, và thường chạy một bộ ca kiểm thử định sẵn để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Mô tả trong câu hỏi khớp đúng định nghĩa này: toàn hệ thống, mọi loại yêu cầu, đối chiếu với specifications. "Validation Testing" là khái niệm rộng, hỏi xem sản phẩm có đúng là thứ người dùng cần hay không, không gắn riêng với việc kiểm toàn hệ thống theo đặc tả. "Integration Testing" chỉ kiểm giao diện và tương tác giữa các thành phần khi ghép lại, chưa phải toàn bộ hệ thống. "User Acceptance Testing" do người dùng thực hiện để quyết định có chấp nhận hệ thống hay không, căn cứ vào nhu cầu nghiệp vụ chứ không phải để kiểm đủ mọi yêu cầu cấu trúc và chất lượng trước ban quản lý.

Đáp án đúng: "Component testing does not involve regression testing". Câu hỏi tìm phát biểu không đúng. Kiểm thử thành phần (component testing) hoàn toàn có kiểm thử hồi quy: mỗi khi thành phần bị sửa, các ca kiểm thử đơn vị được chạy lại, thường tự động trong unit test framework, để chắc thay đổi không làm hỏng chức năng cũ; hồi quy áp dụng ở mọi cấp kiểm thử. Các phát biểu kia đúng nên không được chọn. "Component testing should be performed by development" đúng vì kiểm thử thành phần thường do lập trình viên viết mã thực hiện, cần truy cập mã và môi trường phát triển. "Component testing is also known as isolation or module testing" đúng vì thành phần được kiểm cô lập với phần còn lại bằng stub và driver, và còn được gọi là module testing hay unit testing. "Component testing should have completion criteria planned" đúng vì như mọi cấp kiểm thử, nó cần tiêu chí hoàn thành, chẳng hạn mức độ phủ, được lập kế hoạch trước.

Đáp án đúng: "Bottom-up integration". Tích hợp từ dưới lên (bottom-up integration) bắt đầu kiểm thử các mô-đun lá ở tầng thấp nhất, rồi ghép dần lên các mô-đun gọi chúng cho tới mô-đun điều khiển chính; vì mô-đun cấp trên chưa có nên phải viết driver để gọi các mô-đun cấp dưới và truyền dữ liệu kiểm thử. "Top-down integration" đi chiều ngược lại, bắt đầu từ mô-đun điều khiển cao nhất và dùng stub thay cho các mô-đun cấp dưới chưa hoàn thành. "Module integration" không phải tên một chiến lược tích hợp cụ thể, chỉ là cách nói chung về việc ghép mô-đun, không xác định thứ tự từ dưới lên hay từ trên xuống. "None of the others" sai vì tích hợp từ dưới lên khớp đúng mô tả của câu hỏi.

Đáp án đúng: "Purchased/contracted software". Với phần mềm mua sẵn hoặc thuê bên ngoài phát triển (như sản phẩm thương mại đóng gói, COTS), mã nguồn và cấu trúc bên trong thường thuộc quyền nhà cung cấp và không được giao cho bên mua, nên người kiểm thử chủ yếu chỉ kiểm được theo hộp đen, dựa vào đặc tả, tài liệu và kiểm thử chấp nhận. "Traditional system development" là phát triển nội bộ theo mô hình tuần tự, đội kiểm thử có thể tiếp cận mã và thiết kế. "Iterative development" là phát triển theo vòng lặp, mã nguồn cũng do chính tổ chức nắm giữ nên vẫn có thể kiểm thử hộp trắng. "System maintenance" là bảo trì hệ thống đang vận hành, thường do tổ chức sở hữu mã nguồn thực hiện, nên cấu trúc bên trong sẵn có để phân tích tác động và kiểm thử.

Đáp án đúng: "Driver". Khi kiểm thử thành phần (component testing), đơn vị cần kiểm thử thường chưa có mã gọi nó, nên lập trình viên viết một trình điều khiển (driver): đoạn mã thay cho thành phần gọi, có nhiệm vụ gọi hàm cần kiểm thử, truyền dữ liệu kiểm thử vào và nhận kết quả trả về để so sánh. Đó đúng là vai trò câu hỏi mô tả. "Stub" (hàm giả) làm chiều ngược lại: thay cho thành phần mà hàm đang kiểm thử gọi xuống, trả về giá trị dựng sẵn, nên nó được gọi chứ không đi gọi hàm. "Proxy" là mẫu thiết kế hay thành phần mạng làm trung gian chuyển tiếp lời gọi, không phải thuật ngữ cho mã gọi hàm để kiểm thử. "None of the others" sai vì đã có một thuật ngữ chính xác cho vai trò này là driver; trong kiểm thử tích hợp từ dưới lên (bottom-up), driver chính là thứ được dùng để gọi các mô-đun cấp thấp đã hoàn thành.

Đáp án đúng: "ii , iii are true and i is false". Trình điều khiển kiểm thử (driver) là mã thay cho thành phần gọi, dùng để gọi thành phần đang kiểm thử và truyền dữ liệu vào. Trong thuật ngữ kiểm thử, driver cùng với stub tạo thành môi trường giàn giáo bao quanh thành phần, nên driver còn được gọi là test harness (giàn kiểm thử, bộ khung chứa driver, stub và dữ liệu để chạy kiểm thử) và scaffolding (giàn giáo, mã phụ trợ dựng tạm để chạy kiểm thử rồi bỏ đi). Vì thế mục ii và iii đúng. Mục i, "Spade", không phải thuật ngữ nào trong kiểm thử phần mềm cả. "i , ii are true and iii is false" sai vì nhận Spade và loại scaffolding. "i , iii are true and ii is false" sai vì nhận Spade và loại test harness. "All of i, ii and iii are true" sai vì Spade không phải tên gọi khác của driver.

Đáp án đúng: "Top-down integration testing". Kiểm thử hệ thống (system testing) xét toàn bộ hệ thống đã tích hợp đầy đủ, đối chiếu với đặc tả yêu cầu cả chức năng lẫn phi chức năng; còn tích hợp từ trên xuống là một chiến lược của cấp kiểm thử tích hợp (integration testing), ghép dần các mô-đun từ mô-đun điều khiển cao nhất xuống và dùng stub thay cho mô-đun cấp dưới chưa có, nên nó diễn ra trước và không thuộc kiểm thử hệ thống. "Business process-based testing" thuộc kiểm thử hệ thống vì ca kiểm thử dựng theo quy trình nghiệp vụ, kịch bản sử dụng đầu cuối. "Performance, load and stress testing" là kiểm thử phi chức năng tiêu biểu ở cấp hệ thống, đo thời gian phản hồi và khả năng chịu tải trên môi trường gần giống thật. "Requirements-based testing" thiết kế ca kiểm thử từ đặc tả yêu cầu, chính là cơ sở kiểm thử chủ yếu của cấp hệ thống. "Usability testing" đánh giá mức dễ học, dễ dùng của hệ thống hoàn chỉnh, cũng là kiểm thử phi chức năng ở cấp này.

Đáp án đúng: "Driver". Khi kiểm thử một thành phần riêng lẻ mà mô-đun gọi nó chưa có, lập trình viên viết một driver (trình điều khiển): đoạn mã đứng ở vị trí bên gọi, gọi hàm cần kiểm thử, truyền dữ liệu kiểm thử vào và nhận kết quả để so sánh với kết quả mong đợi; driver được dùng nhiều trong tích hợp từ dưới lên. "Stub" là chiều ngược lại: nó thay thế cho thành phần mà hàm đang kiểm thử gọi tới, chỉ trả về giá trị giả định đơn giản, dùng nhiều trong tích hợp từ trên xuống. "Proxy" là mẫu thiết kế hay thành phần trung gian chuyển tiếp lời gọi tới một đối tượng khác, không phải thuật ngữ kiểm thử chỉ đoạn mã gọi thành phần đang kiểm thử. "None of the others" sai vì driver chính là thứ câu hỏi mô tả.

Đáp án đúng: "Verification activities should not involve testers (reviews, inspections etc)". Phát biểu này sai vì ISTQB Foundation khuyến khích người kiểm thử tham gia hoạt động kiểm chứng (verification) như rà soát và thanh tra ngay từ sớm: họ góp góc nhìn về khả năng kiểm thử, phát hiện yêu cầu mơ hồ và học sản phẩm để thiết kế kiểm thử tốt hơn, đúng nguyên tắc kiểm thử sớm. Câu hỏi tìm phát biểu không đúng nên đây là đáp án. "Performance testing can be done during unit testing as well as during the testing of whole system" là đúng, vì kiểm thử hiệu năng có thể áp ở cấp đơn vị, ví dụ đo thời gian một thuật toán, lẫn cấp hệ thống. "The acceptance test does not necessarily include a regression test" cũng đúng, vì mục tiêu kiểm thử chấp nhận là xây dựng niềm tin và xác nhận sẵn sàng triển khai, hồi quy không bắt buộc phải nằm trong đó. "Test environments should be as similar to production environments as possible" đúng, vì môi trường càng giống thực tế càng giảm rủi ro lỗi chỉ lộ ra khi vận hành.

Đáp án đúng: "Regression Testing". Định nghĩa ISTQB của kiểm thử hồi quy (regression testing) là kiểm thử lặp lại một chương trình đã được kiểm thử, sau khi sửa đổi, nhằm phát hiện lỗi mới bị đưa vào hoặc bị làm lộ ra do thay đổi, kể cả thay đổi ở thành phần phần mềm khác có liên quan hay không liên quan; câu hỏi chép gần như nguyên văn định nghĩa này. Điểm mấu chốt là nó tìm tác dụng phụ ngoài chủ đích của thay đổi. "Re Testing" và "Confirmation Testing" là cùng một khái niệm, kiểm thử xác nhận: chạy lại đúng ca kiểm thử từng thất bại để xác nhận lỗi đó đã được sửa, chứ không đi tìm lỗi mới nảy sinh ở chỗ khác. "Negative Testing" (kiểm thử phủ định) là dùng dữ liệu không hợp lệ hoặc thao tác sai để xem hệ thống xử lý lỗi có đúng không, không gắn với việc phần mềm vừa bị sửa đổi.

Đáp án đúng: "Big-bang". Kiểm thử tích hợp tăng dần (incremental integration testing) ghép từng thành phần hoặc từng nhóm nhỏ vào rồi kiểm thử ngay, nên khi lỗi xuất hiện dễ khoanh vùng nguyên nhân. Tích hợp vụ nổ lớn (big-bang integration) thì ngược lại: ghép tất cả thành phần một lần rồi mới kiểm thử cả khối, nên không phải cách tiếp cận tăng dần và khó định vị lỗi. "Top down" (từ trên xuống) là cách tăng dần, bắt đầu từ mô-đun điều khiển cấp cao, dùng stub thay cho mô-đun cấp dưới chưa có. "Bottom up" (từ dưới lên) cũng tăng dần, bắt đầu từ mô-đun cấp thấp, dùng driver để gọi chúng. "Functional incrementation." là tích hợp tăng dần theo từng chức năng hay tính năng, ghép những thành phần cần cho một chức năng rồi mới chuyển sang chức năng kế tiếp, nên cũng thuộc nhóm tăng dần.

Đáp án đúng: "i is true and ii,iii,iv are false". Kiểm chứng (verification) trả lời câu hỏi chúng ta có xây sản phẩm đúng cách không, tức đối chiếu sản phẩm làm ra với đặc tả và tiêu chuẩn, nên nó giúp kiểm tra chất lượng của sản phẩm đã xây (mục i). Mục ii nói xây đúng sản phẩm, đó là định nghĩa của thẩm định (validation), kiểm tra sản phẩm có đáp ứng nhu cầu thật của người dùng không. Mục iii nói giúp phát triển sản phẩm, nhưng verification là hoạt động đánh giá chứ không phải hoạt động phát triển, và mục iv về hao phí công cụ thì không liên quan. "i,ii,iii are true and iv is false" là phương án một số nguồn chấm đúng, nhưng nó gộp nhầm validation vào verification và coi hoạt động đánh giá là hoạt động phát triển, nên không đứng được. "Options i,ii,iii,iv are true." còn thêm cả mục iv vô can. "ii is true and i,iii,iv are false." chọn đúng mục thuộc validation và loại mục duy nhất thuộc verification.

Đáp án đúng: "i-c , ii-a , iii-d , iv-b". Mô hình chữ V (V-model) ghép mỗi bước phát triển bên trái với một cấp kiểm thử bên phải dùng sản phẩm của bước đó làm cơ sở kiểm thử: yêu cầu nghiệp vụ (business requirements) là căn cứ của kiểm thử chấp nhận nên iv ghép b, thiết kế mức cao (hi-level design) mô tả kiến trúc toàn hệ thống nên ứng với kiểm thử hệ thống, i ghép c, thiết kế mức thấp (low-level design) mô tả các mô-đun và giao diện giữa chúng nên ứng với kiểm thử tích hợp, iii ghép d, còn mã (code) ứng với kiểm thử đơn vị, ii ghép a. "i-d , ii-a , iii-c , iv-b" đảo cặp thiết kế mức cao và mức thấp, gán kiểm thử hệ thống cho thiết kế mức thấp. "i-c , ii-d , iii-a , iv-b" đặt kiểm thử tích hợp cho mã và kiểm thử đơn vị cho thiết kế mức thấp, ngược thứ bậc. "i-b , ii-a , iii-d , iv-c" gán kiểm thử chấp nhận cho thiết kế mức cao và kiểm thử hệ thống cho yêu cầu nghiệp vụ, trong khi chấp nhận phải đối chiếu với nhu cầu nghiệp vụ.