Software Testing - SWT301

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.

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.

Các đánh giá hỗ trợ đảm bảo chất lượng phần mềm bằng cách cung cấp một cách để kiểm tra tuân thủ các tiêu chuẩn. Điều này có nghĩa là các đánh giá giúp xác định xem phần mềm có đáp ứng các yêu cầu và tiêu chuẩn đã được thiết lập hay không. Các đánh giá cũng giúp xác định các vấn đề và lỗi trong phần mềm, từ đó giúp các nhà phát triển cải thiện và hoàn thiện phần mềm. Ngoài ra, các đánh giá còn giúp xây dựng niềm tin với khách hàng và người dùng, bởi họ có thể thấy được chất lượng và độ tin cậy của phần mềm.

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.

Quá trình đánh giá sản phẩm công việc là một phần quan trọng trong chuỗi hoạt động của một dự án. Trong quá trình này, các thành viên tham gia đánh giá và thảo luận về sản phẩm công việc đã được tạo ra. Các hoạt động chính của quá trình đánh giá sản phẩm công việc bao gồm: xác định mục tiêu và yêu cầu của sản phẩm, đánh giá chất lượng và hiệu suất của sản phẩm, xác định điểm mạnh và điểm yếu của sản phẩm, đề xuất cải tiến và sửa lỗi, và xác định kế hoạch triển khai sản phẩm. Các hoạt động này giúp đảm bảo rằng sản phẩm công việc đáp ứng được yêu cầu và mục tiêu của dự án, đồng thời giúp cải thiện chất lượng và hiệu suất của sản phẩm.

Các công cụ phân tích tĩnh là một phần quan trọng trong quy trình phát triển phần mềm. Chúng giúp kiểm tra mã nguồn trước khi thực thi, nhằm đảm bảo rằng mã nguồn tuân thủ các tiêu chuẩn lập trình và tránh các lỗi tiềm ẩn. Một trong những đặc điểm chính của các công cụ phân tích tĩnh là khả năng kiểm tra các tiêu chuẩn lập trình. Điều này bao gồm việc kiểm tra mã nguồn để đảm bảo rằng nó tuân thủ các quy tắc lập trình, tránh các lỗi syntax và đảm bảo rằng mã nguồn được viết một cách rõ ràng và dễ đọc. Việc kiểm tra các tiêu chuẩn lập trình giúp cải thiện chất lượng mã nguồn và giảm thiểu thời gian phát triển.

Static testing là một phương pháp kiểm thử phần mềm mà trong đó các sản phẩm phần mềm được kiểm tra bằng cách sử dụng các công cụ hoặc thủ công mà không cần thực hiện việc chạy chương trình. Phương pháp này giúp phát hiện các lỗi và đánh giá các tính chất chất lượng của mã nguồn mà không cần thực hiện việc chạy chương trình. Các kỹ thuật thường được sử dụng trong static testing bao gồm kiểm tra mã nguồn, phân tích mã nguồn, và sử dụng các công cụ kiểm thử tự động. Mục đích của static testing là giúp phát hiện các lỗi và cải thiện chất lượng của phần mềm trước khi nó được triển khai.

Kỹ thuật kiểm thử dựa trên yêu cầu (specification-based testing) là một phương pháp kiểm thử phần mềm nhằm đánh giá và xác minh rằng phần mềm đáp ứng các yêu cầu chức năng và không gian trạng thái đã được xác định trước đó. Mục đích chính của kỹ thuật này là để đánh giá hành vi của hệ thống từ góc độ bên ngoài, tức là kiểm thử phần mềm dựa trên các yêu cầu chức năng và không gian trạng thái đã được xác định trước đó. Điều này giúp đảm bảo rằng phần mềm hoạt động đúng như mong đợi và đáp ứng các yêu cầu của người dùng.

Decision coverage là một phần quan trọng trong white-box testing. Nó đảm bảo rằng tất cả các nhánh trong điểm quyết định của chương trình đều được thực thi. Điều này giúp phát hiện ra các lỗi hoặc vấn đề tiềm ẩn trong mã nguồn. Khi tất cả các nhánh được thực thi, chúng ta có thể tin tưởng rằng chương trình sẽ hoạt động chính xác và không có lỗi logic. Việc đảm bảo decision coverage giúp cải thiện chất lượng của sản phẩm và giảm thiểu rủi ro khi phát hành. Nó cũng giúp phát hiện ra các vấn đề về bảo mật và đảm bảo rằng chương trình tuân thủ các quy định và tiêu chuẩn.

Kịch bản lý tưởng để sử dụng thử nghiệm khám phá (Exploratory Testing) là khi có thời gian hạn chế và không có các yêu cầu chi tiết. Trong trường hợp này, người kiểm thử không có hướng dẫn cụ thể để thực hiện các thử nghiệm, vì vậy họ phải tự mình khám phá và tìm hiểu về sản phẩm để xác định các lỗi và vấn đề. Điều này đòi hỏi sự sáng tạo, kỹ năng phân tích và khả năng tư duy logic của người kiểm thử. Họ phải tự mình quyết định các trường hợp thử nghiệm, các bước thực hiện và các yếu tố cần kiểm tra. Mục tiêu của thử nghiệm khám phá là tìm ra các lỗi và vấn đề mà các phương pháp thử nghiệm khác có thể bỏ qua.

Vì trường password yêu cầu tối thiểu 8 ký tự và tối đa 12 ký tự, nên các giá trị biên bao gồm 7 ký tự và 13 ký tự. 7 ký tự là giá trị biên thấp nhất vì nó nhỏ hơn 8 ký tự, trong khi 13 ký tự là giá trị biên cao nhất vì nó lớn hơn 12 ký tự. Các giá trị 8 ký tự và 10 ký tự không phải là giá trị biên vì chúng nằm trong khoảng giá trị cho phép.

Kỹ thuật hộp trắng có mục tiêu chính là đảm bảo mỗi một trong các chi nhánh có thể xảy ra từ mỗi điểm quyết định được thực thi ít nhất một lần. Điều này giúp đảm bảo rằng mã nguồn được kiểm tra một cách đầy đủ và chính xác. Kỹ thuật này được gọi là Branch coverage testing. Nó tập trung vào việc đảm bảo rằng mỗi một quyết định trong mã nguồn đều được kiểm tra một cách đầy đủ, giúp giảm thiểu khả năng xảy ra lỗi.

Kỹ thuật thiết kế thử nghiệm dựa trên kỹ năng, trực giác và kinh nghiệm của người kiểm thử được gọi là Experience-based testing. Điều này có nghĩa là người kiểm thử sử dụng kiến thức và kinh nghiệm của mình để xác định các trường hợp thử nghiệm và kiểm tra sản phẩm. Kỹ thuật này không dựa trên các yêu cầu chức năng hoặc đặc điểm kỹ thuật của sản phẩm, mà dựa trên sự hiểu biết và kinh nghiệm của người kiểm thử về cách sản phẩm hoạt động và có thể bị lỗi. Experience-based testing thường được sử dụng trong các trường hợp thử nghiệm khi yêu cầu chức năng hoặc đặc điểm kỹ thuật của sản phẩm không rõ ràng hoặc không đầy đủ.

Để đánh giá độ chính xác của mã nguồn, chúng ta cần xác định số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh. Mã nguồn được cung cấp là một đoạn mã pseudo-code với các câu lệnh và điều kiện logic. Để đạt được sự bao phủ đầy đủ về câu lệnh, chúng ta cần thực hiện ít nhất 2 thử nghiệm. Thử nghiệm đầu tiên sẽ đọc giá trị của A và B, sau đó thực hiện câu lệnh IF A-B > 50. Thử nghiệm thứ hai sẽ đọc giá trị của B và thực hiện câu lệnh IF B > 10. Để đạt được sự bao phủ đầy đủ về nhánh, chúng ta cần thực hiện thêm 1 thử nghiệm nữa. Thử nghiệm này sẽ đọc giá trị của A và B, sau đó thực hiện cả hai câu lệnh IF A-B > 50 và IF B > 10. Vì vậy, số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh là 2 thử nghiệm cho câu lệnh và 2 thử nghiệm cho nhánh.

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.

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.

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

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

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.

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