Ôn tập thi lại SWT301 Summer 2025

Các đánh giá kỹ thuật khác với đánh giá không chính thức ở chỗ chúng tuân theo một quy trình được định nghĩa và được dẫn dắt bởi một người điều hành được đào tạo. Trong các đánh giá kỹ thuật, người điều hành sẽ đảm bảo rằng quá trình đánh giá được thực hiện một cách công bằng và có hệ thống. Họ sẽ hướng dẫn các thành viên tham gia đánh giá và đảm bảo rằng tất cả các ý kiến đều được lắng nghe và xem xét. Điều này giúp đảm bảo rằng các đánh giá kỹ thuật là một quá trình nghiêm túc và có hệ thống, giúp cải thiện chất lượng của sản phẩm.

Phương pháp kiểm thử tĩnh và động là hai kỹ thuật kiểm thử khác nhau trong lập trình. Phương pháp kiểm thử tĩnh không liên quan đến việc thực thi mã, trong khi phương pháp kiểm thử động lại liên quan đến việc thực thi mã. Điều này có nghĩa là kiểm thử tĩnh được thực hiện trước khi mã được thực thi, trong khi kiểm thử động được thực hiện sau khi mã được thực thi. Kiểm thử tĩnh bao gồm các kỹ thuật như phân tích mã, kiểm tra mã, và đánh giá mã, trong khi kiểm thử động bao gồm các kỹ thuật như kiểm thử đơn vị, kiểm thử tích hợp, và kiểm thử hệ thống. Mỗi phương pháp có ưu và nhược điểm riêng, và được sử dụng trong các giai đoạn khác nhau của quá trình phát triển phần mềm.

Dynamic testing là một phương pháp kiểm thử phần mềm, trong đó phần mềm được thực hiện (chạy) với một bộ giá trị đầu vào và kết quả được kiểm tra và so sánh với kết quả mong đợi. Phương pháp này cho phép phát hiện ra các lỗi hoặc vấn đề trong phần mềm một cách nhanh chóng và hiệu quả. Trong dynamic testing, phần mềm được chạy với các trường hợp thử nghiệm khác nhau, bao gồm các giá trị đầu vào khác nhau, các điều kiện ngoại lệ, và các tình huống sử dụng thực tế. Kết quả của phần mềm được so sánh với kết quả mong đợi để xác định xem phần mềm hoạt động đúng hay không. Phương pháp này giúp phát hiện ra các lỗi hoặc vấn đề trong phần mềm một cách nhanh chóng và hiệu quả, từ đó giúp cải thiện chất lượng phần mềm.

Trong các lựa chọn trên, hoạt động được thực hiện bởi các nhà phát triển thường liên quan đến việc đánh giá kỹ thuật của một tài liệu chức năng. Điều này bao gồm việc kiểm tra tính chính xác và đầy đủ của các yêu cầu kỹ thuật, cũng như đảm bảo rằng tài liệu chức năng phù hợp với các tiêu chuẩn và quy định của dự án. Các nhà phát triển thường có kiến thức chuyên môn sâu về công nghệ và kỹ thuật, vì vậy họ có thể đánh giá kỹ thuật một cách hiệu quả. Ngoài ra, hoạt động này cũng giúp đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện đúng cách.

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.

Non-functional testing là một loại kiểm thử phần mềm tập trung vào các tính chất không liên quan trực tiếp đến chức năng của hệ thống. Điều này bao gồm các yếu tố như hiệu suất, độ tin cậy, khả năng chịu tải, bảo mật và tương thích. Non-functional testing giúp đảm bảo rằng hệ thống hoạt động một cách ổn định và hiệu quả trong các tình huống khác nhau. Ví dụ, hiệu suất của hệ thống có thể được kiểm thử bằng cách đo thời gian tải dữ liệu hoặc thực hiện các tác vụ phức tạp. Độ tin cậy có thể được kiểm thử bằng cách đánh giá khả năng hệ thống hoạt động mà không gặp lỗi trong thời gian dài. Khả năng chịu tải có thể được kiểm thử bằng cách đo khả năng hệ thống xử lý số lượng lớn dữ liệu hoặc người dùng. Mục tiêu của non-functional testing là đảm bảo rằng hệ thống đáp ứng các yêu cầu về hiệu suất, độ tin cậy và khả năng chịu tải.

Stress testing và load testing đều là các phương pháp kiểm tra hiệu suất của hệ thống, nhưng chúng phục vụ cho các mục đích khác nhau. Stress testing tập trung vào việc kiểm tra hệ thống khi nó hoạt động ở mức tải cao, vượt quá khả năng hoạt động bình thường. Điều này giúp xác định giới hạn chịu tải của hệ thống và đảm bảo rằng nó có thể xử lý được các tình huống khẩn cấp. Ngược lại, load testing tập trung vào việc kiểm tra hệ thống khi nó hoạt động ở mức tải bình thường, giúp xác định xem hệ thống có thể xử lý được các yêu cầu thông thường hay không. Tóm lại, stress testing là một phương pháp kiểm tra hiệu suất của hệ thống ở mức tải cao, trong khi load testing là một phương pháp kiểm tra hiệu suất của hệ thống ở mức tải bình thường.

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.

Một công cụ thực thi thử nghiệm (test execution tool) có chức năng chính là tự động chạy các thử nghiệm và ghi lại kết quả. Điều này giúp cho quá trình thử nghiệm trở nên nhanh chóng và hiệu quả hơn. Công cụ này có thể tự động chạy các thử nghiệm trên nhiều nền tảng khác nhau, từ đó giúp cho việc theo dõi và phân tích kết quả trở nên dễ dàng hơn. Ngoài ra, công cụ này cũng có thể tự động ghi lại các kết quả thử nghiệm, giúp cho việc theo dõi tiến độ thử nghiệm trở nên dễ dàng hơn. Tóm lại, tự động chạy thử nghiệm và ghi lại kết quả là một trong những tính năng quan trọng của một công cụ thực thi thử nghiệm.

Một công cụ quản lý thử nghiệm thường bao gồm các tính năng như lập kế hoạch thử nghiệm, tạo dữ liệu thử nghiệm, lưu trữ kết quả thử nghiệm và quản lý hoạt động thử nghiệm. Tuy nhiên, một số tính năng không phải là đặc điểm của một công cụ quản lý thử nghiệm. Ví dụ, lập kế hoạch thử nghiệm là một tính năng quan trọng của một công cụ quản lý thử nghiệm, vì nó cho phép người dùng lập kế hoạch và sắp xếp các thử nghiệm một cách hiệu quả. Tạo dữ liệu thử nghiệm cũng là một tính năng quan trọng, vì nó giúp người dùng tạo ra dữ liệu thử nghiệm cần thiết cho các thử nghiệm. Lưu trữ kết quả thử nghiệm cũng là một tính năng quan trọng, vì nó giúp người dùng theo dõi và phân tích kết quả thử nghiệm. Quản lý hoạt động thử nghiệm cũng là một tính năng quan trọng, vì nó giúp người dùng quản lý và theo dõi các hoạt động thử nghiệm. Tuy nhiên, lập kế hoạch thời gian (scheduling tests) không phải là một tính năng đặc biệt của một công cụ quản lý thử nghiệm, vì nó có thể được thực hiện bằng các công cụ quản lý dự án khác.

Decision coverage là một thước đo để đánh giá mức độ hoàn thiện của các thử nghiệm. Nó đo lường số lượng kết quả quyết định trong mã nguồn được thử nghiệm. Để đạt được quyết định hoàn toàn, mỗi quyết định trong mã nguồn phải được thử nghiệm với cả hai kết quả có thể xảy ra. Điều này có nghĩa là mỗi 'if' trong mã nguồn phải được thử nghiệm với cả hai trường hợp true và false. Điều này giúp đảm bảo rằng mã nguồn đã được thử nghiệm đầy đủ và giảm thiểu khả năng tồn tại của các lỗi.

Để ước tính thời gian và nguồn lực cần thiết cho một thử nghiệm, yếu tố quan trọng nhất là thời gian và nguồn lực cần thiết để hoàn thành thử nghiệm. Điều này bao gồm cả thời gian và nguồn lực cần thiết để thực hiện các hoạt động thử nghiệm, chẳng hạn như lập kế hoạch, thiết kế, thực hiện và kiểm tra thử nghiệm. Thời gian và nguồn lực cần thiết cũng bao gồm cả thời gian và nguồn lực cần thiết để thực hiện các hoạt động khác liên quan đến thử nghiệm, chẳng hạn như lập báo cáo và phân tích kết quả. Việc ước tính thời gian và nguồn lực cần thiết chính xác là rất quan trọng vì nó giúp đảm bảo rằng thử nghiệm được thực hiện một cách hiệu quả và tiết kiệm nguồn lực.

Các công cụ quản lý yêu cầu (Requirement management tools) thường được sử dụng bởi các nhà phát triển để quản lý và theo dõi yêu cầu của sản phẩm. Chúng giúp các nhà phát triển hiểu rõ hơn về yêu cầu của sản phẩm, từ đó có thể xây dựng sản phẩm đúng theo yêu cầu. Vì vậy, các công cụ quản lý yêu cầu thường được sử dụng bởi các nhà phát triển hơn là các tester. Ví dụ, các công cụ như JIRA, Trello, Asana,... được sử dụng để quản lý và theo dõi yêu cầu của sản phẩm.

Khi thực hiện tự động hóa kiểm thử, có một số rủi ro cần được xem xét. Thứ nhất, việc sử dụng công cụ tự động hóa không được hỗ trợ trong tương lai có thể khiến bạn gặp khó khăn khi cần cập nhật hoặc sửa lỗi. Điều này có thể dẫn đến chi phí và thời gian lãng phí để tìm kiếm và triển khai công cụ mới. Thứ hai, việc tự động hóa kiểm thử cho các khu vực kiểm thử thủ công phức tạp có thể không hiệu quả nếu không được thực hiện đúng cách. Điều này có thể dẫn đến việc lãng phí thời gian và nguồn lực. Cuối cùng, việc sử dụng kỹ sư kiểm thử để triển khai tự động hóa có thể không hiệu quả nếu họ không có kinh nghiệm hoặc kỹ năng cần thiết. Tuy nhiên, việc tự động hóa báo cáo có thể là một lợi ích của tự động hóa kiểm thử, giúp giảm thời gian và chi phí trong quá trình kiểm thử.

Trong quản lý sự cố, mục tiêu không phải là sửa chữa tất cả các lỗi bất kể mức độ ảnh hưởng. Mục tiêu chính của quản lý sự cố là giảm thiểu sự cố và giảm thiểu thời gian ngừng hoạt động. Điều này bao gồm việc giảm thiểu rủi ro của các lỗi trong tương lai và đảm bảo sự hài lòng của các bên liên quan với sản phẩm. Tuy nhiên, mục tiêu không phải là sửa chữa tất cả các lỗi, vì điều này có thể không cần thiết và có thể không hiệu quả về mặt kinh tế. Thay vào đó, mục tiêu là tập trung vào việc sửa chữa các lỗi quan trọng và ảnh hưởng đến sản phẩm.

Để theo dõi tiến độ thực thi thử nghiệm, cần sử dụng chỉ số phù hợp. Trong số các lựa chọn trên, chỉ số "Số lượng lỗi mở so với lỗi đã đóng" là lựa chọn đúng. Điều này giúp theo dõi số lượng lỗi mới phát hiện và số lượng lỗi đã được sửa trong quá trình thử nghiệm. Điều này cho phép quản lý dự án đánh giá tiến độ thử nghiệm và đưa ra quyết định điều chỉnh phù hợp. Chỉ số này cũng giúp theo dõi hiệu suất của đội ngũ thử nghiệm và xác định khu vực cần cải thiện.

Báo cáo lỗi/bug là một tài liệu kỹ thuật được sử dụng để mô tả các triệu chứng của một lỗi. Nó thường bao gồm thông tin chi tiết về lỗi, bao gồm cả các bước để tái tạo lỗi và các ảnh chụp màn hình để minh họa. Báo cáo lỗi/bug giúp cho các nhà phát triển hiểu rõ về lỗi và có thể sửa lỗi một cách hiệu quả. Nó cũng giúp cho các nhà quản lý dự án theo dõi tiến độ và đảm bảo rằng lỗi được sửa chữa một cách kịp thời. Báo cáo lỗi/bug thường được sử dụng trong suốt vòng đời kiểm thử phần mềm (STLC) để đảm bảo rằng phần mềm được kiểm thử một cách đầy đủ và hiệu quả.

Equivalence phân loại là một kỹ thuật thiết kế thử nghiệm hiệu quả vì nó phân chia dữ liệu đầu vào thành các phân đoạn hợp lệ và không hợp lệ, giúp đơn giản hóa quá trình thử nghiệm. Điều này cho phép các nhà phát triển tập trung vào các trường hợp thử nghiệm quan trọng và giảm thiểu số lượng thử nghiệm cần thiết. Bằng cách phân loại dữ liệu đầu vào, các nhà phát triển có thể xác định các trường hợp thử nghiệm cần thiết và tránh các trường hợp thử nghiệm không cần thiết, giúp tiết kiệm thời gian và nguồn lực. Đồng thời, kỹ thuật này cũng giúp đảm bảo rằng các trường hợp thử nghiệm được thực hiện một cách đầy đủ và chính xác.

Vai trò chịu trách nhiệm lãnh đạo nỗ lực kiểm thử là vai trò của người quản lý kiểm thử. Người quản lý kiểm thử là người có trách nhiệm toàn diện về quá trình kiểm thử, bao gồm lập kế hoạch, tổ chức, thực hiện và theo dõi tiến độ kiểm thử. Họ phải đảm bảo rằng quá trình kiểm thử được thực hiện một cách hiệu quả và hiệu quả, đồng thời đảm bảo rằng các yêu cầu kiểm thử được thực hiện một cách chính xác. Người quản lý kiểm thử cũng phải có khả năng giải quyết vấn đề và đưa ra quyết định sáng suốt trong quá trình kiểm thử.

Mục đích chính của việc kiểm tra use case là xác định các lỗi trong quá trình luân chuyển liên quan đến việc sử dụng hệ thống thông thường. Việc kiểm tra này giúp xác định các lỗi trong các trường hợp sử dụng điển hình của hệ thống, bao gồm cả các lỗi trong các quy trình và giao diện người dùng. Điều này giúp đảm bảo rằng hệ thống hoạt động đúng như mong đợi và đáp ứng được nhu cầu của người dùng. Việc kiểm tra use case thường được thực hiện sau khi hệ thống đã được thiết kế và phát triển, và trước khi hệ thống được triển khai.