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

Các loại kiểm thử không phải là kiểm thử thay đổi liên quan bao gồm kiểm thử cấu trúc, kiểm thử chức năng, kiểm thử không chức năng và kiểm thử hiệu suất. Kiểm thử cấu trúc tập trung vào việc kiểm tra các thành phần cơ bản của chương trình, chẳng hạn như các hàm, lớp và phương thức. Kiểm thử chức năng tập trung vào việc kiểm tra các yêu cầu chức năng của chương trình, chẳng hạn như các tính năng và chức năng. Kiểm thử không chức năng tập trung vào việc kiểm tra các tính chất không chức năng của chương trình, chẳng hạn như hiệu suất, độ tin cậy và khả năng tương thích. Kiểm thử hiệu suất tập trung vào việc kiểm tra hiệu suất của chương trình, chẳng hạn như tốc độ và dung lượng bộ nhớ sử dụng.

Performance testing đóng vai trò quan trọng trong quá trình kiểm thử hệ thống. Mục đích chính của performance testing là xác minh hệ thống hoạt động đúng cách dưới tải trọng lớn. Điều này bao gồm việc kiểm tra hệ thống có thể xử lý số lượng lớn yêu cầu, dữ liệu và giao diện người dùng một cách hiệu quả hay không. Performance testing giúp đảm bảo hệ thống có thể đáp ứng được nhu cầu của người dùng, giảm thiểu thời gian tải và tăng cường độ tin cậy. Ngoài ra, performance testing còn giúp phát hiện ra các vấn đề về hiệu suất, chẳng hạn như chậm chạp, lỗi thời gian chờ đợi và lỗi kết nối.

Mô hình Big-bang model trong phát triển phần mềm đề cập đến một phương pháp tiếp cận cụ thể. Theo mô hình này, tất cả các thành phần của dự án đều được tích hợp lại với nhau một lần, mà không thực hiện các thử nghiệm trước đó. Điều này có nghĩa là các thành phần sẽ được xây dựng và tích hợp lại với nhau ngay từ đầu dự án, và sau đó mới thực hiện các thử nghiệm để đảm bảo rằng dự án hoạt động đúng như mong đợi. Phương pháp này có thể giúp giảm thiểu thời gian phát triển dự án, nhưng cũng có thể dẫn đến các vấn đề về bảo trì và sửa lỗi sau này.

Trong mô hình Waterfall, chuỗi hoạt động kiểm thử thông thường bao gồm các bước sau: kiểm thử thành phần, kiểm thử tích hợp và kiểm thử hệ thống. Kiểm thử thành phần được thực hiện đầu tiên, sau đó là kiểm thử tích hợp và cuối cùng là kiểm thử hệ thống. Kiểm thử hệ thống đảm bảo rằng hệ thống đáp ứng được các yêu cầu của khách hàng, kiểm thử tích hợp đảm bảo rằng các thành phần của hệ thống được tích hợp đúng cách và kiểm thử thành phần đảm bảo rằng từng thành phần của hệ thống hoạt động đúng cách.

Trong quá trình kiểm thử, có một số mức độ kiểm thử khác nhau. Mức độ kiểm thử mà bạn sẽ kiểm tra các lỗi trong giao diện và tương tác giữa các thành phần tích hợp được gọi là kiểm thử tích hợp. Kiểm thử tích hợp là mức độ kiểm thử cao hơn kiểm thử thành phần, nhưng thấp hơn kiểm thử hệ thống. Mục tiêu chính của kiểm thử tích hợp là đảm bảo rằng các thành phần được tích hợp một cách chính xác và hoạt động như dự kiến. Điều này bao gồm việc kiểm tra giao diện và tương tác giữa các thành phần, cũng như đảm bảo rằng các thành phần hoạt động một cách độc lập và không ảnh hưởng đến nhau.

Quá trình kiểm tra một đơn vị mã code trong môi trường cách ly được gọi là Unit Testing. Trong quá trình này, một đơn vị mã code được kiểm tra một cách độc lập, không phụ thuộc vào các đơn vị khác. Unit Testing có thể được áp dụng cho một phương thức, một lớp hoặc một mô-đun. Mục đích của Unit Testing là đảm bảo rằng mỗi đơn vị mã code hoạt động chính xác và không có lỗi. Điều này giúp phát hiện ra lỗi sớm và cải thiện chất lượng của mã code.

Các loại kiểm tra trả lời bao gồm Contract và regulation testing là một phần của kiểm tra System testing. Trong quá trình kiểm tra System testing, các nhà phát triển sẽ kiểm tra toàn bộ hệ thống để đảm bảo rằng nó hoạt động đúng như mong đợi. Kiểm tra Contract và regulation testing là một phần quan trọng của quá trình này, giúp đảm bảo rằng hệ thống tuân thủ các hợp đồng và quy định đã được thiết lập.

Các tài xế (drivers) là công cụ được sử dụng để kiểm soát và vận hành phần mềm đang được kiểm thử. Họ đóng vai trò quan trọng trong việc tương tác với phần mềm và thực hiện các hành động cụ thể để kiểm tra tính đúng đắn của nó. Ví dụ, một tài xế có thể được sử dụng để tương tác với một ứng dụng web, nhập dữ liệu, nhấp vào các nút và kiểm tra phản hồi của ứng dụng. Mục đích của việc sử dụng tài xế là để mô phỏng các hành động của người dùng thực và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

Quá trình bắt đầu từ các mô-đun cuối cùng được gọi là tích hợp từ trên xuống. Trong quá trình này, các mô-đun cuối cùng được tích hợp vào các mô-đun cao hơn để tạo thành một hệ thống phức tạp hơn. Điều này thường được sử dụng trong các hệ thống lớn và phức tạp, nơi mà các mô-đun cuối cùng cần được tích hợp vào các mô-đun cao hơn để tạo thành một hệ thống toàn diện. Ví dụ, trong một hệ thống tự động hóa, các mô-đun cuối cùng như cảm biến và động cơ cần được tích hợp vào các mô-đun cao hơn như hệ thống điều khiển và giao tiếp để tạo thành một hệ thống tự động hóa toàn diện.

Đá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ế.

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.

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: "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ế.

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ả.

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.

Đáp án đúng: "Confirmation testing". Kiểm thử xác nhận (confirmation testing, còn gọi re-testing, kiểm thử lại) là chạy lại đúng những ca kiểm thử đã thất bại sau khi khiếm khuyết được sửa, để xác nhận khiếm khuyết gốc thật sự đã được loại bỏ; đây chính là tình huống câu hỏi mô tả. "Regression testing" là kiểm thử hồi quy: chạy lại các ca kiểm thử trên phần đã kiểm thử trước đó để phát hiện khiếm khuyết mới bị đưa vào hoặc bị lộ ra do thay đổi, tức là tìm tác dụng phụ ở chỗ khác chứ không kiểm tra lỗi gốc đã hết chưa. "Maintenance testing" là kiểm thử bảo trì, áp dụng khi hệ thống đang vận hành bị sửa đổi, chuyển đổi môi trường hoặc ngừng sử dụng; nó là một bối cảnh kiểm thử chứ không phải tên của việc chạy lại ca thất bại. "None of the above" sai vì đã có thuật ngữ khớp chính xác với mô tả.

SSSR (Software System Safety and Reliability) Impact Analysis là một phương pháp giúp đánh giá tác động của thay đổi trong hệ thống phần mềm. Nó giúp xác định mức độ ảnh hưởng của thay đổi này đến các phần khác của hệ thống. Trong quá trình này, SSSR Impact Analysis giúp quyết định mức độ kiểm tra lặp lại (regression testing) cần thực hiện. Điều này bao gồm việc xác định số lượng kiểm tra lặp lại cần thực hiện để đảm bảo rằng hệ thống vẫn hoạt động đúng sau khi thay đổi. Vì vậy, câu trả lời đúng cho câu hỏi này là "How much regression testing should be done."

Strategy tích hợp là một phần quan trọng trong quản lý dự án. Có nhiều phương pháp tích hợp khác nhau, bao gồm cả Design based, Big-bang, Bottom-up và Top-down. Tuy nhiên, Design based không phải là một phương pháp tích hợp. Thay vào đó, nó là một phương pháp thiết kế, được sử dụng để tạo ra một bản thiết kế chi tiết cho dự án trước khi bắt đầu triển khai. Big-bang, Bottom-up và Top-down là các phương pháp tích hợp khác nhau, mỗi phương pháp đều có ưu và nhược điểm riêng. Big-bang là một phương pháp tích hợp toàn diện, trong đó tất cả các phần của dự án được tích hợp cùng một lúc. Bottom-up là một phương pháp tích hợp từ dưới lên, trong đó các phần nhỏ của dự án được tích hợp trước và sau đó được kết hợp lại. Top-down là một phương pháp tích hợp từ trên xuống, trong đó các phần lớn của dự án được tích hợp trước và sau đó được chia nhỏ hơn.

Đáp án đúng: "Breadth Test and Depth Test". Kiểm thử bảo trì (maintenance testing) diễn ra khi hệ thống đang vận hành bị sửa đổi, nâng cấp, chuyển môi trường hoặc gỡ bỏ. Cách tiếp cận của nó gồm hai chiều: kiểm thử theo chiều sâu (depth test) để kiểm kỹ chính phần vừa thay đổi, và kiểm thử theo chiều rộng (breadth test) để rà hồi quy trên các phần khác của hệ thống xem thay đổi có gây ảnh hưởng ngoài ý muốn hay không, phạm vi được quyết định qua phân tích tác động (impact analysis). "Re-testing" chỉ là việc chạy lại ca kiểm thử đã thất bại sau khi lỗi được sửa, là một hoạt động nằm bên trong chứ không phải phương pháp tổng thể. "Confirmation Testing" là tên gọi khác của re-testing, nên cũng chỉ là một phần của chiều sâu. "Sanity Testing" là phép kiểm nhanh xem bản dựng có đủ ổn định để kiểm tiếp hay không, không phải phương pháp riêng của kiểm thử bảo trì.

SSS ae là một phiên bản rất sớm được thiết kế cho phân phối hạn chế đến một số khách hàng quan trọng và cho marketing để mục đích trình diễn. Đây là giai đoạn đầu tiên trong quá trình phát triển phần mềm, khi mà sản phẩm vẫn còn nhiều lỗi và chưa được hoàn thiện. Các phiên bản này thường được sử dụng để thu thập phản hồi từ khách hàng và để thử nghiệm các tính năng mới. Trong trường hợp này, SSS ae được mô tả là một phiên bản được thiết kế cho phân phối hạn chế, cho thấy nó không phải là một phiên bản hoàn chỉnh và đã được thử nghiệm kỹ lưỡng.