CÁC CẤP ĐỘ KIỂM THỬ PHẦN MỀM

Kiểm thử được thực hiện ở nhiều cấp độ khác nhau, từ cấp độ theo đơn vị nhỏ (unit) đến cấp độ theo hệ thống (systems) hoặc tập hợp các hệ thống (system of systems) (các hệ thống quy mô lớn được cấu thành từ nhiều hệ thống, chẳng hạn như hệ thống sử dụng ở ngân hàng). 

Kiểm thử có thể được tiến hành để kiểm tra xem code có đúng không và cũng để xác nhận xem người dùng có thể sử dụng một cách thuận tiện trong công việc hay không, do đó tùy vào mục đích và kiểu kiểm thử mà các lỗi được phát hiện ra sẽ khác nhau. Thay vì kiểm thử những yếu tố khác nhau cùng một lúc, sẽ hiệu quả hơn nếu ta hệ thống hóa và quản lý từng yếu tố một cách có tổ chức.

Các cấp độ kiểm thử có thể được liên kết đến các hoạt động trong quy trình phát triển, chẳng hạn như định nghĩa yêu cầu, thiết kế cơ bản, thiết kế chi tiết. 

Trong các dự án thực tế, các hoạt động trong quy trình phát triển có thể trải qua nhiều giai đoạn hơn, tùy thuộc vào đối tượng kiểm thử là gì. Do đó, định nghĩa cho các cấp độ kiểm thử cũng như số lượng các cấp độ kiểm thử sẽ thay đổi tùy theo quy mô đối tượng kiểm thử.

Trong bài viết này, chúng ta sẽ tìm hiểu về 4 cấp độ kiểm thử được tiến hành ở nhiều tổ chức, đó là các cấp độ kiểm thử sau đây: 

・Kiểm thử thành phần (Component Test)

・Kiểm thử tích hợp (Integration Test)

・Kiểm thử hệ thống (System Test)

・Kiểm thử nghiệm thu người dùng (User Acceptance Test)

1/ Kiểm thử thành phần (Component Test)

Các phần mềm có thể tách rời như các thành phần (component) hoặc mô-đun (module) được kiểm thử bằng cách sử dụng các đối tượng giả lập (mock object), ảo hóa dịch vụ (service virtualization), khai thác kiểm thử (harness), mô phỏng (stub), trình điều khiển (driver), hoặc trình mô phỏng (simulator) để tách chúng ra khỏi các phần khác của hệ thống. Loại kiểm thử này còn được gọi là kiểm thử đơn vị (Unit Test) hoặc kiểm thử mô-đun (module test).

Mục đích kiểm thử

Dưới đây là các mục đích của Kiểm thử thành phần: 

・Tìm ra các lỗi của đối tượng kiểm thử

・Xác nhận đối tượng kiểm thử có hoạt động đúng theo đặc tả hay không

・Kiểm tra xem các hành vi phi chức năng (non-functional behavior) của đối tượng kiểm thử có đúng với thiết kế và đặc tả hay không

・Đảm bảo chất lượng của đối tượng kiểm thử là đáng tin cậy

・Phát hiện và không để sót một lỗi nào

・Giảm thiểu rủi ro xuống mức thấp nhất

Đối tượng kiểm thử

Các đối tượng sau đây được liệt kê làm đối tượng của kiểm thử thành phần (Component Test):

・Thành phần (component), đơn vị (unit), mô-đun (module)

・Mã nguồn (code) và cấu trúc dữ liệu

・Class

・Mô-đun cơ sở dữ liệu (database module)

Các kiểu kiểm thử

Các loại kiểm thử chính được thực hiện trong kiểm thử thành phần (Component Test) bao gồm:

・Kiểm thử chức năng (functional test)

・Kiểm thử phi chức năng (non-functional test)

・Kiểm thử hộp trắng (white-box test)

・Kiểm thử hồi quy (regression test)

Các lỗi điển hình

Các lỗi thường được phát hiện trong kiểm thử thành phần (Component Test) bao gồm:

・Chức năng không hợp lệ, không đúng với đặc tả

・Vấn đề về luồng dữ liệu (data flow)

・Lỗi trong mã nguồn (code) hoặc logic

Trong một số dự án, các vấn đề về hiệu suất được phát hiện qua đo lường hiệu suất có thể được xem là lỗi về hiệu suất (performance defect).

Trong kiểm thử thành phần, thường sẽ sửa lỗi ngay sau khi phát hiện. Tuy nhiên, điều này không có nghĩa là không sử dụng công cụ quản lý lỗi. Công cụ vẫn được sử dụng, nhưng không nhất thiết phải tuân thủ nghiêm ngặt quy trình hoặc phân loại lỗi theo tiêu chuẩn tổ chức.

Do đó, cần tránh hiểu lầm rằng “không cần quản lý lỗi trong kiểm thử thành phần.” Trong một số dự án, việc quản lý lỗi trong kiểm thử thành phần cũng được thực hiện để cải thiện quy trình.

Tùy vào tình huống, cần xác định liệu ưu tiên tốc độ hay nhắm tới cải tiến quy trình, từ đó quyết định cách tiếp cận đối với việc quản lý lỗi một cách phù hợp.

Người thực hiện kiểm thử

Kiểm thử thành phần (Component Test) thường do chính lập trình viên đã viết code thực hiện. Tuy nhiên, trong một số trường hợp, kiểm thử có thể được thực hiện bởi các thành viên thuộc đội ngũ kiểm thử chuyên trách.

Việc kiểm thử này không chỉ được tiến hành bởi một mình lập trình viên mà thường được thực hiện với sự tham gia của các lập trình viên khác. Ngoài ra, các lỗi được phát hiện trong kiểm thử thành phần sẽ do chính lập trình viên phụ trách sửa chữa.

Phương pháp đặc thù

Trong mô hình Agile, tự động hóa kiểm thử là việc vô cùng phổ biến. Tạo danh sách kiểm thử, xây dựng cơ chế thực thi kiểm thử tự động, sau đó phát triển mã nguồn dựa trên chu kỳ phát triển các trường hợp kiểm thử, đồng thời lặp đi lặp lại sửa chữa cho đến khi vượt qua (pass) kiểm thử thành phần (Component Test).

Gần đây, phương pháp phát triển với việc thay đổi mã nguồn liên tục như trong mô hình Agile đã trở thành xu hướng chủ đạo. Do đó, việc xác nhận độ tin cậy thông qua kiểm thử hồi quy (regression test) nhằm đảm bảo rằng những thay đổi mã nguồn không ảnh hưởng đến các thành phần hiện có chính là một mục tiêu quan trọng.

Trong nhiều tổ chức hoặc dự án, cách nghĩ rằng “việc kiểm tra hành vi phi chức năng sẽ được thực hiện ở cấp độ kiểm thử hệ thống” có thể được xem là bình thường. Quả là như vậy, thông thường người ta sẽ tiến hành kiểm thử phi chức năng sau khi đã phát hiện đầy đủ lỗi thông qua kiểm thử chức năng. Tuy nhiên, tại giai đoạn kiểm thử thành phần, việc đo lường hiệu suất của các mô-đun quan trọng và điều chỉnh chúng một cách phù hợp cũng rất quan trọng. Nếu bỏ qua điều này, có thể xảy ra các vấn đề về hiệu suất ở giai đoạn kiểm thử hệ thống, dẫn đến tốn nhiều công số trong việc sửa mã nguồn và cuối cùng ảnh hưởng đến thời gian phát hành sản phẩm.

Vì vậy, cần nhận thức rõ rằng trong kiểm thử thành phần cũng có trường hợp phải xác nhận các hành vi phi chức năng.

2/ Kiểm thử tích hợp (Integration Test)

Kiểm thử tích hợp được chia thành hai loại chính:

・Kiểm thử tích hợp thành phần (Component Integration Test)

・Kiểm thử tích hợp hệ thống (System Integration Test)

Kiểm thử tích hợp thành phần

Kiểm thử tích hợp thành phần được thực hiện sau khi kiểm thử thành phần (Component Test) hoàn tất, tập trung vào giao diện giữa các thành phần và cách chúng hoạt động cùng nhau. Vì chức năng của từng thành phần riêng lẻ đã được đánh giá trong kiểm thử thành phần, nên kiểm thử này chủ yếu tập trung vào các phần kết nối giữa các thành phần.

Đặc biệt, trong phát triển lặp (Iterative Development) hoặc phát triển gia tăng (Incremental Development), việc tự động hóa kiểm thử này và thực hiện nó như một phần của tích hợp liên tục (Continuous Integration) là điều phổ biến.

Chiến lược tích hợp và tầm quan trọng của nó

Có những trường hợp các dự án cố gắng tăng hiệu quả bằng cách tích hợp một lúc nhiều thành phần và kiểm thử tất cả cùng một lần (được gọi là “Tích hợp kiểu Big Bang”). Tuy nhiên, cách tiếp cận này thường không hiệu quả. Nguyên nhân là khi phạm vi tích hợp quá rộng, nếu xảy ra lỗi, rất khó xác định thành phần nào gây ra vấn đề. Điều này dẫn đến việc gỡ lỗi và sửa chữa mất nhiều thời gian hơn.

Để phát hiện và sửa lỗi một cách nhanh chóng, điều quan trọng là tiến hành tích hợp theo từng bước. Vì vậy, hiện nay, thay vì tích hợp tất cả cùng lúc, kiểm thử tích hợp dựa trên một chiến lược tích hợp có hệ thống được áp dụng rộng rãi. Chiến lược này tiến hành tích hợp dần dần dựa trên kiến trúc hệ thống (ví dụ: từ trên xuống – top-down hoặc từ dưới lên – bottom-up), nhiệm vụ chức năng, hoặc trình tự xử lý giao dịch.

Quy trình tích hợp lý tưởng

Khi thực hiện tích hợp theo từng bước, lý tưởng nhất là người thực hiện kiểm thử hiểu rõ cấu trúc của chiến lược tích hợp cũng như tác động của quá trình tích hợp. Điều này giúp quy trình tích hợp diễn ra suôn sẻ, đồng thời cho phép phát hiện và sửa lỗi sớm một cách hiệu quả.

Kiểm thử tích hợp hệ thống

Kiểm thử tích hợp hệ thống được thực hiện song song hoặc sau khi kiểm thử hệ thống hoàn thành, tập trung vào giao diện và các xử lý tương tác với các hệ thống khác.

Trong kiểm thử hệ thống, hành vi của các hệ thống khác thường được mô phỏng, vì vậy cần tiến hành kiểm thử trong môi trường tích hợp thực tế để kiểm tra toàn bộ quy trình kinh doanh. Ví dụ: tích hợp hệ thống xử lý đơn đặt hàng với hệ thống xử lý vận chuyển và hệ thống xử lý hóa đơn để kiểm tra toàn bộ quy trình quản lý bán hàng.

Đối tượng kiểm thử

Kiểm thử tích hợp hệ thống tập trung vào:

・Giao diện và xử lý tương tác với các hệ thống khác

・Các gói phần mềm và dịch vụ vi mô (microservices)

・Dịch vụ web do tổ chức bên ngoài cung cấp

Khi tích hợp với các hệ thống hoặc dịch vụ bên ngoài, các hạn chế về môi trường kiểm thử hoặc lịch trình có thể phát sinh, đặc biệt việc sắp xếp để tiến hành kiểm thử xác nhận có thể mất nhiều thời gian. Tình trạng này có thể xảy ra với bất kể mô hình phát triển nào.

Mục đích kiểm thử

Mục đích của kiểm thử tích hợp bao gồm:

・Phát hiện lỗi tiềm ẩn trong đối tượng kiểm thử và giao diện.

・Kiểm tra xem hành vi chức năng của giao diện khớp với thiết kế và đặc tả hay chưa.

・Kiểm tra xem hành vi phi chức năng (như hiệu suất, độ tin cậy) khớp với thiết kế và đặc tả hay chưa.

・Đảm bảo độ tin cậy của giao diện và nâng cao chất lượng (tạo dựng lòng tin với khách hàng).

・Không bỏ sót lỗi nào.

・Giảm thiểu rủi ro.

Đối tượng của kiểm thử tích hợp

Những đối tượng chính trong kiểm thử tích hợp bao gồm:

・Các hệ thống con (subsystems)

・Cơ sở dữ liệu

・Hạ tầng (infrastructure)

・Giao diện (interfaces)

・API

・Dịch vụ vi mô (microservices)

Loại kiểm thử

Kiểm thử tích hợp bao gồm các loại kiểm thử sau:

・Kiểm thử chức năng: Kiểm tra liệu hệ thống hoạt động đúng theo đặc tả

・Kiểm thử phi chức năng: Kiểm tra các yếu tố như hiệu suất, độ tin cậy, v.v.

・Kiểm thử hộp trắng (white-box test): Xem xét cấu trúc và logic bên trong

・Kiểm thử hồi quy (regression test): Đảm bảo rằng các thay đổi không gây ảnh hưởng đến hệ thống hoặc giao diện hiện có

Đặc biệt, kiểm thử hồi quy đóng vai trò quan trọng trong việc xác nhận rằng các thay đổi không làm ảnh hưởng đến hệ thống. Việc tự động hóa kiểm thử hồi quy cũng giúp nâng cao hiệu quả. Trong một số trường hợp, kiểm thử hiệu suất có thể được thực hiện ở giai đoạn kiểm thử tích hợp thành phần.

Các lỗi thường gặp trong kiểm thử

Lỗi thường gặp trong kiểm thử tích hợp thành phần

・Dữ liệu không chính xác, thiếu dữ liệu, hoặc mã hóa dữ liệu sai

・Thứ tự hoặc thời gian gọi giao diện không chính xác

・Không nhất quán trong giao diện

・Lỗi truyền dữ liệu giữa các thành phần

・Xử lý không đầy đủ hoặc không phù hợp khi phát sinh lỗi truyền dữ liệu.

・Giả định sai về ý nghĩa, đơn vị, hoặc giới hạn của dữ liệu

Lỗi thường gặp trong kiểm thử tích hợp hệ thống

・Cấu trúc lời nhắn không đồng nhất giữa các hệ thống

・Không nhất quán trong giao diện

・Lỗi truyền dữ liệu giữa các hệ thống

・Xử lý không đầy đủ hoặc không phù hợp với khi phát sinh lỗi truyền dữ liệu

・Giả định sai về ý nghĩa, đơn vị, hoặc giới hạn của dữ liệu

・Không tuân thủ các quy định về bảo mật

Trong kiểm thử tích hợp, việc phát hiện sớm các lỗi này rất quan trọng để đảm bảo độ tin cậy giữa các hệ thống.

Người thực hiện kiểm thử (phân chia vai trò)

・Kiểm thử tích hợp thành phần: Thường do các nhà lập trình viên đảm nhận

・Kiểm thử tích hợp hệ thống: Thường được thực hiện bởi đội ngũ chuyên môn kiểm thử

Phương pháp đặc thù

Lập kế hoạch chiến lược tích hợp và kế hoạch kiểm thử tích hợp trước khi phát triển giúp xây dựng kế hoạch kiểm thử phù hợp với kiến trúc phần mềm và hệ thống. Điều này tối ưu hóa hiệu quả kiểm thử trong suốt quá trình phát triển.

3/ Kiểm thử hệ thống

Trong kiểm thử hệ thống, cả khía cạnh chức năng và phi chức năng của toàn bộ sản phẩm phần mềm đều được kiểm tra theo kế hoạch kiểm thử tổng thể và kế hoạch kiểm thử hệ thống. Quá trình này kiểm tra hoạt động từ đầu đến cuối và công suất của hệ thống.

Mục đích của kiểm thử

Kiểm thử hệ thống có các mục đích đa dạng như sau:

・Phát hiện các lỗi tiềm ẩn của đối tượng kiểm thử

・Kiểm tra xem hành vi chức năng của đối tượng kiểm thử giống thiết kế và đặc tả kỹ thuật chưa

・Kiểm tra xem hành vi phi chức năng của đối tượng kiểm thử giống thiết kế và đặc tả kỹ chưa

・Kiểm tra xem hệ thống đã hoàn thiện và hoạt động đúng như mong đợi hay chưa

・Xác nhận rằng hệ thống đáp ứng các yêu cầu hoặc tiêu chuẩn pháp lý và quy định

・Đảm bảo rằng chất lượng tổng thể của hệ thống đáng tin cậy (xây dựng sự tin cậy)

・Tránh bỏ sót các lỗi quan trọng chưa được phát hiện

・Kiểm tra chất lượng dữ liệu

・Giảm thiểu rủi ro

Đối tượng kiểm thử

Các đối tượng kiểm thử trong kiểm thử hệ thống bao gồm:

・Ứng dụng

・Hệ thống phần cứng/phần mềm

・Hệ thống đối tượng kiểm thử (SUT – System Under Test)

・Cấu hình hệ thống và dữ liệu cấu hình

Các loại kiểm thử

Kiểm thử hệ thống bao gồm các loại kiểm thử như:

・Kiểm thử chức năng

・Kiểm thử phi chức năng

・Kiểm thử hộp trắng (White-box Testing)

・Kiểm thử hồi quy (Regression Testing)

Kiểm thử hệ thống kiểm tra các yêu cầu chức năng, yêu cầu phi chức năng, và các đặc tính chất lượng dữ liệu của hệ thống. Để xác minh những yếu tố này, nhiều loại kiểm thử khác nhau được áp dụng.

Kiểm thử hồi quy là một loại kiểm thử đặc biệt quan trọng để xác nhận rằng những thay đổi trong hệ thống không phá hủy các chức năng hoặc khả năng từ đầu đến cuối đã có. Trong một số trường hợp, kiểm thử hồi quy được tự động hóa để nâng cao hiệu quả.

Các lỗi điển hình được phát hiện trong kiểm thử hệ thống

Trong kiểm thử hệ thống, những lỗi điển hình thường được phát hiện bao gồm:

・Sai sót trong tính toán

・Hành vi chức năng hoặc phi chức năng của hệ thống không chính xác hoặc không như mong đợi

・Luồng điều khiển hoặc luồng dữ liệu trong hệ thống không phù hợp

・Không thể thực hiện đầy đủ và chính xác các tác vụ chức năng từ đầu đến cuối

・Hệ thống không hoạt động đúng trong môi trường sản xuất

・Hệ thống không hoạt động theo hướng dẫn trong tài liệu hệ thống hoặc tài liệu hướng dẫn người dùng

Các lỗi liên quan đến yêu cầu đặc tả có thể dẫn đến việc hiểu sai về cử động của hệ thống, từ đó gây ra kết quả kiểm thử sai.

Để tránh những tình trạng như vậy, người kiểm thử nên tham gia vào các hoạt động điều chỉnh câu chuyện người dùng (user story refinement) trước khi thực hiện kiểm thử động. Hoạt động này bao gồm xem xét, sửa đổi, thống nhất nhận thức, và ước lượng nội dung yêu cầu. Đồng thời, việc thực hiện kiểm thử tĩnh sớm trong quá trình phát triển cũng rất quan trọng.

Người thực hiện kiểm thử

Kiểm thử hệ thống có thể do nhóm kiểm thử trong tổ chức phát triển thực hiện. Ngoài ra cũng có thể được đảm nhiệm bởi một nhóm kiểm thử riêng biệt.

Phương pháp tiếp cận đặc thù 

Kiểm thử hệ thống sử dụng các kỹ thuật kiểm thử phù hợp. Ví dụ, sử dụng bảng quyết định (decision table) để kiểm tra cử động của chức năng dựa trên các quy tắc nghiệp vụ.

Ngoài ra, khi tiến hành kiểm thử hệ thống, lý tưởng nhất là nên thực hiện trong môi trường kiểm thử càng giống môi trường sản xuất (staging environment) càng tốt, thay vì trong môi trường phát triển nơi đã thực hiện kiểm thử tích hợp thành phần. Điều này giúp phát hiện các lỗi liên quan đến môi trường mà không thể tìm thấy trong môi trường phát triển.

Kết quả từ kiểm thử hệ thống thường là cơ sở để quyết định xem hệ thống có thể được phát hành (release) hay chưa. 

4/ Kiểm thử nghiệm thu người dùng (User Acceptance Test)

Kiểm thử nghiệm thu đánh giá các khía cạnh chức năng và phi chức năng của toàn bộ hệ thống hoặc sản phẩm phần mềm, tương tự như kiểm thử hệ thống. Tuy nhiên, kiểm thử nghiệm thu không chỉ thực hiện ngay trước khi phát hành mà còn có thể diễn ra ở nhiều giai đoạn khác nhau trong vòng đời phát triển phần mềm. Dưới đây là các loại kiểm thử nghiệm thu phổ biến:

・Kiểm thử nghiệm thu người dùng (User Acceptance Testing – UAT)

・Kiểm thử nghiệm thu vận hành (Operational Acceptance Testing)

・Kiểm thử nghiệm thu theo hợp đồng (Contract Acceptance Testing)

・Kiểm thử nghiệm thu theo quy định (Regulatory Acceptance Testing)

・Kiểm thử alpha và beta (Alpha Testing và Beta Testing)

Kiểm thử nghiệm thu người dùng

Đây là quá trình người dùng xác minh xem hệ thống có vận hành đúng theo nghiệp vụ hay không. Kiểm thử này thường được thực hiện trong môi trường vận hành thực tế hoặc môi trường vận hành giả lập, nơi người dùng sử dụng hệ thống và đánh giá xem hệ thống có đáp ứng được các yêu cầu và nhu cầu của họ hay không.

Kiểm thử nghiệm thu vận hành

Kiểm thử vận hành tập trung vào các khía cạnh vận hành của hệ thống và thường do các nhà quản trị hệ thống hoặc người vận hành thực hiện. Thông thường, kiểm thử được tiến hành trong môi trường thực tế hoặc giả lập với các nội dung sau:

・Kiểm thử sao lưu và phục hồi dữ liệu

・Cài đặt, gỡ bỏ cài đặt, và nâng cấp hệ thống

・Phục hồi sau sự cố

・Quản lý người dùng

・Bảo trì

・Chuyển đổi và tải dữ liệu

・Kiểm tra lỗ hổng bảo mật

・Kiểm tra hiệu năng

Kiểm thử nghiệm thu theo hợp đồng

Loại kiểm thử này được áp dụng khi phát triển phần mềm theo yêu cầu riêng (custom software). Nó xác minh xem hệ thống có đáp ứng các tiêu chí chấp nhận mà đã được thỏa thuận trong hợp đồng giữa khách hàng và nhóm phát triển hay không. Các tiêu chí này được đặt ra tại thời điểm ký kết hợp đồng và là cơ sở để đánh giá.

Kiểm thử nghiệm thu theo quy định

Kiểm thử này đảm bảo rằng hệ thống hoặc phần mềm tuân thủ các quy định của chính phủ, pháp luật, hoặc các tiêu chuẩn về an toàn. Các lĩnh vực như kế toán, bảo mật, y tế thường có các tiêu chuẩn pháp lý cụ thể cần được kiểm tra và xác nhận thông qua loại kiểm thử này.

Kiểm thử alpha và beta

Trường hợp là phần mềm thương mại, kiểm thử alpha và beta được thực hiện trước khi phát hành sản phẩm ra thị trường nhằm thu thập phản hồi từ người dùng tương lai hoặc khách hàng hiện tại.

Kiểm thử alpha thường diễn ra trước kiểm thử beta, với mục tiêu phát hiện lỗi lớn và cải thiện hệ thống. Kiểm thử beta được thực hiện bởi người dùng thực tế trong môi trường gần như thật để thu thập phản hồi cuối cùng trước khi phát hành sản phẩm.

Trong một số trường hợp, kiểm thử beta có thể được tiến hành mà không cần kiểm thử alpha.

Mục đích của kiểm thử nghiệm thu 

・Xác nhận hệ thống hoạt động chức năng theo đúng đặc tả kỹ thuật

・Xác nhận hệ thống hoạt động phi chức năng theo đúng đặc tả kỹ thuật

・Đánh giá tính hợp lệ của hệ thống để đảm bảo rằng nó hoàn thiện và hoạt động như mong đợi

・Xác nhận rằng chất lượng tổng thể của hệ thống là đáng tin cậy

Đối tượng kiểm thử 

Trong kiểm thử nghiệm thu, các đối tượng kiểm thử bao gồm:

・Hệ thống được kiểm thử

・Cấu hình và dữ liệu cấu hình của hệ thống

・Quy trình kinh doanh của hệ thống được tích hợp đầy đủ

・Quy trình vận hành và quy trình bảo trì

・Báo cáo

・Định dạng

・Dữ liệu vận hành được lưu trữ hoặc chuyển đổi

Những lỗi điển hình 

Các lỗi thường được phát hiện trong kiểm thử nghiệm thu bao gồm:

・Luồng công việc của hệ thống không đáp ứng yêu cầu kinh doanh hoặc yêu cầu người dùng

・Quy tắc kinh doanh không được triển khai chính xác

・Hệ thống không đáp ứng các yêu cầu hợp đồng hoặc quy định

・Các lỗi về đặc tính phi chức năng, chẳng hạn như lỗ hổng bảo mật, hiệu năng không đủ khi tải cao, hoặc lỗi hoạt động trên các nền tảng được hỗ trợ

Người thực hiện kiểm thử 

Kiểm thử nghiệm thu được thực hiện bởi khách hàng, người dùng doanh nghiệp, chủ sở hữu sản phẩm, người vận hành hệ thống và các bên liên quan khác.

Người thực hiện kiểm thử chính theo từng loại kiểm thử nghiệm thu:

• Kiểm thử nghiệm thu người dùng
  • Khách hàng
  • Người dùng doanh nghiệp
• Kiểm thử nghiệm thu vận hành
  • Người vận hành
  • Quản trị viên hệ thống
• Kiểm thử nghiệm thu theo hợp đồng
  • Người dùng
  • Người kiểm thử độc lập
• Kiểm thử nghiệm thu theo quy định
  • Người dùng
  • Người kiểm thử độc lập
  • Cơ quan quản lý (trong trường hợp cần xác minh hoặc kiểm toán kết quả kiểm thử)
• Kiểm thử Alpha
  • Khách hàng tiềm năng
  • Khách hàng hiện tại
  • Người vận hành hệ thống
  • Đội ngũ kiểm thử độc lập

Phương pháp tiếp cận đặc thù 

Trong phát triển tuần tự (sequential development), kiểm thử nghiệm thu thường được thực hiện vào cuối vòng đời phát triển. Tuy nhiên, nó cũng có thể được thực hiện trong các tình huống sau:

・Phần mềm thương mại (COTS): Kiểm thử nghiệm thu được thực hiện trong quá trình cài đặt hoặc tích hợp

・Phát triển tính năng mới theo ủy thác: Kiểm thử nghiệm thu có thể được thực hiện trước kiểm thử hệ thống để xác nhận không có lỗi trong giao diện hoặc xử lý tương tác

Trong Phát triển lặp (iterative development), kiểm thử nghiệm thu được thực hiện vào cuối hoặc sau mỗi vòng lặp, hoặc sau nhiều vòng lặp.

Dựa trên kết quả kiểm thử nghiệm thu, có thể đánh giá hệ thống đã sẵn sàng phát hành hoặc khách hàng đã có thể sử dụng hệ thống hay chưa.

※Bài tập luyện tập:

https://exam-site.briswell-vn.com/startTest/jstqb-5-vn