Câu hỏi: SWT301 - Phần 6: Công cụ hỗ trợ và tự động hoá kiểm thử

Một đặc điểm nổi bật của một bộ thử nghiệm (test harness) là cung cấp đầu vào cho phần mềm đang được thử nghiệm. Bộ thử nghiệm là một phần mềm độc lập được thiết kế để hỗ trợ quá trình thử nghiệm phần mềm. Nó cung cấp các đầu vào cần thiết để chạy phần mềm và thu thập dữ liệu về kết quả. Bộ thử nghiệm giúp giảm thiểu sự phức tạp của quá trình thử nghiệm và cho phép các nhà phát triển tập trung vào việc viết mã và thử nghiệm phần mềm. Bộ thử nghiệm thường bao gồm các tính năng như cung cấp dữ liệu giả, tạo ra các tình huống thử nghiệm và thu thập dữ liệu về kết quả thử nghiệm.

Khi chọn và triển khai công cụ kiểm thử, có một số hoạt động quan trọng cần được thực hiện. Trước hết, cần phải xác định mục tiêu và yêu cầu của dự án, bao gồm cả các yêu cầu về tính hiệu suất, độ tin cậy và khả năng mở rộng của công cụ kiểm thử. Sau đó, cần phải đánh giá và so sánh các công cụ kiểm thử khác nhau để chọn ra công cụ phù hợp nhất với nhu cầu của dự án. Ngoài ra, cần phải xem xét các yếu tố như chi phí, tính dễ sử dụng và khả năng tích hợp với các hệ thống khác. Cuối cùng, cần phải lập kế hoạch và triển khai công cụ kiểm thử một cách hiệu quả, bao gồm cả việc đào tạo nhân viên và thiết lập quy trình kiểm thử.

Để tìm ra sự không phù hợp trong các lựa chọn, chúng ta cần hiểu rõ chức năng của từng loại công cụ. Công cụ chuẩn bị dữ liệu thử nghiệm (Test data preparation tools) thường được sử dụng để tạo hoặc chỉnh sửa dữ liệu thử nghiệm. Công cụ thiết kế thử nghiệm (Test design tools) giúp tạo ra các đầu vào thử nghiệm. Công cụ quản lý yêu cầu (Requirement management tools) hỗ trợ việc theo dõi các thử nghiệm riêng lẻ. Công cụ quản lý cấu hình (Configuration management tools) giúp kiểm tra sự nhất quán. Tuy nhiên, trong các lựa chọn, 'Manipulate Data bases' không phải là chức năng chính của công cụ chuẩn bị dữ liệu thử nghiệm. Thay vào đó, nó thường liên quan đến việc tạo hoặc chỉnh sửa cơ sở dữ liệu. Do đó, 'Manipulate Data bases' là sự không phù hợp trong các lựa chọn.

Đáp án đúng: "User requirements.". Công cụ ghi và phát lại (capture and replay) ghi các thao tác trên giao diện như nhấp chuột, gõ phím thành kịch bản để chạy lại tự động nhiều lần, nên hợp với "GUI testing", với kiểm thử hồi quy, và với "Performance testing" khi kịch bản đã ghi được nhân lên thành nhiều người dùng ảo để tạo tải. "User requirements." không phải một hoạt động kiểm thử chạy được bằng ghi rồi phát lại: yêu cầu người dùng là tài liệu, được thẩm định bằng rà soát và kiểm thử chấp nhận với người dùng thật, nên đây là chỗ ghi-phát lại ít dùng nhất. Có ý kiến chọn "Recovery testing" vì kiểm thử phục hồi phải cố ý gây sự cố như ngắt điện, rút mạng, điều mà công cụ ghi thao tác không tạo ra được; lập luận đó có lý, nhưng sau khi gây sự cố, kịch bản ghi sẵn vẫn được phát lại để xác nhận hệ thống khôi phục đúng, còn với yêu cầu người dùng thì gần như không có chỗ dùng.

Để phát hiện mã không thể đạt được (unreachable code), chúng ta nên sử dụng công cụ phân tích tĩnh (static analysis tool). Công cụ này có khả năng phân tích mã nguồn mà không cần thực hiện chạy thử nghiệm (runtime). Nó có thể phát hiện các đoạn mã không thể đạt được, cũng như các vấn đề khác như lặp vô hạn, lỗi null pointer, v.v. Ngoài ra, công cụ phân tích tĩnh cũng có thể giúp phát hiện các vấn đề về bảo mật, như việc sử dụng các hàm có thể bị khai thác để thực hiện tấn công, v.v. Vì vậy, sử dụng công cụ phân tích tĩnh là cách tốt nhất để phát hiện mã không thể đạt được.

Để xác định loại trả lời đúng, chúng ta cần hiểu rõ về các công cụ được đề cập. Công cụ phân tích động (Dynamic analysis tool) là một công cụ được sử dụng để theo dõi và phân tích hành vi của chương trình trong thời gian chạy. Nó có thể giúp phát hiện các vấn đề như memory leaks và unassigned pointers. Công cụ phân tích tĩnh (Static Analysis tool) được sử dụng để phân tích mã nguồn của chương trình mà không cần chạy nó. Nó có thể giúp phát hiện các vấn đề như syntax và logic, nhưng không thể phát hiện các vấn đề về memory leaks và unassigned pointers. Công cụ bảo trì (Maintenance tool) và công cụ cấu hình (Configuration tool) không liên quan đến việc phát hiện memory leaks và unassigned pointers. Vì vậy, công cụ phân tích động (Dynamic analysis tool) là công cụ phù hợp để test flag memory leaks và unassigned pointers.

Khi mua một công cụ kiểm thử mới, nó nên được sử dụng đầu tiên bởi một nhóm nhỏ để thiết lập cách sử dụng tốt nhất công cụ đó. Điều này giúp nhóm nhỏ này có thể tìm hiểu và khám phá các tính năng của công cụ, từ đó họ có thể thiết lập các quy trình và thủ tục sử dụng công cụ một cách hiệu quả. Sau đó, họ có thể hướng dẫn và đào tạo các thành viên khác trong nhóm về cách sử dụng công cụ. Việc này giúp tiết kiệm thời gian và công sức cho cả nhóm, đồng thời đảm bảo rằng công cụ được sử dụng một cách hiệu quả và đúng mục đích.

Trong các loại công cụ so sánh trong kiểm thử phần mềm, công cụ so sánh thường được liên kết với các chức năng giám sát hiệu suất và giám sát. Công cụ này giúp kiểm tra hiệu suất của phần mềm và đảm bảo rằng nó hoạt động đúng như mong đợi. Nó cũng giúp phát hiện ra các vấn đề hiệu suất và cung cấp thông tin để cải thiện hiệu suất của phần mềm. Công cụ so sánh thường được sử dụng trong giai đoạn kiểm thử hiệu suất và giám sát để đảm bảo rằng phần mềm hoạt động ổn định và hiệu quả.

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.

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.

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: "Analyze your needs and requirements". Theo ISTQB, đưa công cụ kiểm thử vào tổ chức bắt đầu bằng việc đánh giá mức trưởng thành của tổ chức và phân tích nhu cầu, xác định yêu cầu rõ ràng mà công cụ phải đáp ứng; chỉ khi biết mình cần gì mới đánh giá nhà cung cấp, làm thử nghiệm khái niệm (proof of concept) và dự trù chi phí. "Attend a tool exhibition" là cách tìm hiểu thị trường, hữu ích ở bước khảo sát sau khi đã có yêu cầu, nếu đi trước dễ bị cuốn theo tính năng hào nhoáng. "Invite a vendor to give a demo" thuộc bước đánh giá nhà cung cấp, chưa có yêu cầu thì không biết xem demo để so với cái gì. "Find out what your budget would be for the tool" cần làm nhưng ngân sách phải dựa trên nhu cầu và lợi ích dự kiến. "Search the internet" cũng chỉ là khảo sát lựa chọn, không phải điểm xuất phát.

Đáp án đúng: "A test management tool". Công cụ quản lý kiểm thử (test management tool) hỗ trợ quản lý toàn bộ hoạt động kiểm thử: lưu yêu cầu và ca kiểm thử cùng liên kết truy vết (traceability) giữa chúng, lên lịch chạy kiểm thử, ghi kết quả và sự cố, báo cáo tiến độ; cả ba chức năng câu hỏi nêu đều thuộc nhóm này. "A dynamic analysis tool" theo dõi chương trình lúc chạy để phát hiện rò rỉ bộ nhớ, con trỏ hỏng. "A test execution tool" chạy kịch bản kiểm thử tự động và so sánh kết quả, không quản lý truy vết hay lịch. "A debugging tool" giúp lập trình viên chạy từng bước, xem giá trị biến để tìm nguyên nhân lỗi. "A configuration management tool" quản lý phiên bản và baseline của phần mềm cùng testware, không ghi sự cố hay lên lịch kiểm thử.

Đáp án đúng: "(2) Record/Playback". Kiểm thử hồi quy (regression testing) là chạy lại các ca kiểm thử đã có sau mỗi thay đổi để chắc rằng phần chưa sửa không bị ảnh hưởng; vì bộ ca này lặp lại nhiều lần với cùng các bước, công cụ ghi và phát lại (record/playback), một dạng công cụ thực thi kiểm thử tự động, là lựa chọn điển hình: ghi thao tác một lần rồi phát lại ở mỗi bản dựng mới và so kết quả. "(1) Performance" là công cụ đo hiệu năng, mô phỏng tải và thời gian đáp ứng, phục vụ kiểm thử phi chức năng chứ không nhằm xác nhận chức năng cũ còn chạy đúng. "Both of (1) and (2)" sai vì công cụ hiệu năng không phải loại công cụ dành cho hồi quy chức năng. "None of (1) nor (2)" sai vì record/playback chính là loại công cụ được dùng phổ biến nhất cho kiểm thử hồi quy.

Đáp án đúng: "Generating expected outputs". Câu hỏi dạng EXCEPT: cần tìm việc mà công cụ thực thi kiểm thử thương mại thông thường không làm được. Công cụ thực thi chạy và đối chiếu, nhưng kết quả mong đợi phải đến từ một nguồn hiểu đặc tả, tức test oracle như yêu cầu, người kiểm thử hay hệ thống tham chiếu; công cụ không tự biết đầu ra đúng là gì, đó là bài toán oracle. Các phát biểu kia đều là năng lực điển hình của công cụ nên không được chọn. "Replaying inputs according to a programmed script" đúng vì chạy lại kịch bản đã lập trình là chức năng cốt lõi. "Comparison of expected outcomes with actual outcomes" đúng vì công cụ so kết quả thực tế với kết quả mong đợi đã được cung cấp sẵn. "Recording test inputs" đúng vì kiểu record/playback ghi lại thao tác đầu vào. "Reading test values from a data file" đúng vì kiểm thử hướng dữ liệu (data-driven) đọc giá trị từ tệp dữ liệu.

Công cụ quản lý yêu cầu là công cụ lưu trữ các tuyên bố về yêu cầu, kiểm tra tính nhất quán và cho phép ưu tiên các yêu cầu và cho phép các thử nghiệm riêng lẻ có thể theo dõi được đến các yêu cầu, chức năng và tính năng. Công cụ này giúp đảm bảo rằng các yêu cầu được thống nhất và dễ dàng theo dõi trong suốt quá trình phát triển sản phẩm. Nó cũng giúp xác định và ưu tiên các yêu cầu quan trọng nhất, từ đó giúp tối ưu hóa quá trình phát triển và giảm thiểu rủi ro.

Đáp án đúng: "Both of (1) and (2)". Công cụ và tự động hoá kiểm thử mang lại hai thuộc tính cốt lõi: tốc độ và hiệu suất, vì máy chạy hàng nghìn ca kiểm thử lặp lại nhanh hơn người rất nhiều, giảm việc thủ công lặp đi lặp lại; và độ chính xác, độ chuẩn xác, vì máy thực hiện đúng từng bước như nhau mọi lần, so sánh kết quả không bỏ sót và không mệt mỏi. ISTQB Foundation cũng nêu lợi ích của công cụ là giảm việc lặp lại, tăng tính nhất quán và khả năng lặp lại, cung cấp đánh giá khách quan. Vì cả hai thuộc tính cùng đúng nên phải chọn cả hai. "(1) Speed & efficiency" chỉ nêu một nửa, bỏ mất tính chính xác. "(2) Accuracy & precision" cũng chỉ nêu một nửa, bỏ mất tốc độ. "None of (1) nor (2)" sai vì phủ nhận cả hai lợi ích cơ bản nhất mà tự động hoá mang lại.

Đáp án đúng: "ii. and iv. are more for developers.". Theo cách ISTQB phân loại công cụ, công cụ đo độ phủ (coverage measurement) và công cụ phân tích động (dynamic analysis, ví dụ dò rò rỉ bộ nhớ, con trỏ treo) gắn chặt với mã nguồn và thường do lập trình viên dùng khi kiểm thử thành phần, nên mục ii và iv là nhóm thiên về lập trình viên. Công cụ kiểm thử hiệu năng (mục i) chủ yếu do kiểm thử viên chuyên trách dùng ở cấp hệ thống, bộ so sánh kết quả (test comparator, mục iii) là công cụ hỗ trợ thực thi kiểm thử chung, còn quản lý sự cố (mục v) thuộc nhóm quản lý kiểm thử. "i, iii. and iv. are more for developers." sai vì gộp cả công cụ hiệu năng và bộ so sánh. "ii, iii. and iv. are more for developers." sai vì thêm bộ so sánh vốn không riêng cho lập trình viên. "ii. and iii. are more for developers." sai vì bỏ mất phân tích động và đưa bộ so sánh vào.

Đáp án đúng: "Requirements management tools". Theo phân loại công cụ trong ISTQB Foundation, công cụ quản lý yêu cầu (requirements management tool) lưu trữ các phát biểu yêu cầu cùng thuộc tính của chúng, kiểm tra tính nhất quán và yêu cầu chưa định nghĩa, cho phép xếp mức ưu tiên và lập truy vết (traceability) từ từng ca kiểm thử tới yêu cầu, chức năng, tính năng; đó đúng là bộ chức năng câu hỏi mô tả. "Incident management tools" (công cụ quản lý sự cố) lưu và theo dõi báo cáo lỗi, sự cố cùng trạng thái xử lý, không quản lý yêu cầu. "Configuration management tools" (công cụ quản lý cấu hình) lưu phiên bản và bản dựng của phần mềm, testware, giúp truy vết phiên bản chứ không kiểm tra tính nhất quán hay ưu tiên yêu cầu. "None of the others" sai vì đã có một loại công cụ khớp đúng mô tả.

Đáp án đúng: "A small team to establish the best way to use the tool". Theo ISTQB Foundation, khi đưa một công cụ mới vào tổ chức nên bắt đầu bằng dự án thí điểm (pilot project) với một nhóm nhỏ: tìm hiểu công cụ chi tiết, xác định cách nó khớp với quy trình hiện có, đặt ra cách dùng chuẩn, quy ước đặt tên và cách bảo trì, đánh giá lợi ích so với chi phí. Chỉ sau khi thí điểm thành công mới triển khai rộng. "Everyone who may eventually have some use for the tool" sai vì triển khai cho mọi người ngay khi chưa có cách dùng chuẩn dễ dẫn tới dùng lộn xộn và thất bại. "The independent testing team" không phải câu trả lời đúng vì việc thí điểm do một nhóm nhỏ được chọn đảm nhận, không gắn cứng với đội kiểm thử độc lập. "The vendor contractor to write the initial scripts" sai vì nhà cung cấp viết kịch bản thì tổ chức không tự học được cách dùng phù hợp với mình.