Top các kĩ thuật kiểm thử phần mềm bạn nên biết

Trong kiểm thử phần mềm có vô vàn kiến thức, để có được hiệu quả trong quá trình kiểm thử phần mềm đòi hỏi các kiểm thử viên phải thực sự vững về kiến thức. Các kiến thức từ chuyên ngành kiểm thử phần mềm đến những đặc trưng của từng dự án. Như vậy mới có thể dễ dàng bắt lỗi và đảm bảo sản phẩm phần mềm hoàn chỉnh. Giới thiệu các kĩ thuật kiểm thử phần mềm bạn nên biết!
 

Kĩ thuật kiểm thử phần mềm phân vùng tương đương

Kĩ thuật phân vùng tương đương là việc bạn phân chia tập hợp các điều kiện kiểm thử thành một phân vùng giống nhau 

Phương pháp kiểm thử phần mềm vùng tương đương chia miền đầu vào của chương trình thành các lớp dữ liệu và được gọi là các test cases sẽ được thiết kế.

Test cases của một giá trị đại diện thuộc mỗi lớp sẽ bằng với kiểm thử của bất kỳ giá trị nào đó của cùng một lớp đó. Giúp xác định các lớp tương đương hợp lệ hoặc không hợp lệ

Với các giá trị đầu vào được chia thành các vùng tương đương:

• Vùng tương đương hợp lệ: Là tập hợp các giá trị kiểm thử thỏa mãn các điều kiện của hệ thống

• Vùng tương đương không hợp lệ: Là tập hợp các giá trị kiểm thử mô tả trạng thái khác của hệ thống: sai, thiếu, không đúng,...

Mục đích của nó là giảm đáng kể số lượng test case cần thiết kế vì với mỗi lớp tương đương ta chỉ cần phải test các phần tử đại diện 

Thiết kế Test-case bằng phân lớp tương đương sẽ tiến hành theo 2 bước:

• Xác định các lớp tương đương

• Xác định các ca kiểm thử

Nguyên tắc bao gồm:

• 1 lớp các giá trị lớn hơn

• 1 lớp các giá trị nhỏ hơn

• n lớp các giá trị hợp lệ

Ví dụ: Thiết kế testcase cho ô text chỉ cho nhập số nguyên với độ dài ký tự thuộc [1-10] hoặc [20-30]

Với bài toán trên ta có các vùng sau:

• Nhỏ hơn 1 : vùng không hợp lệ

• Thuộc [1-10] : vùng hợp lệ

• Thuộc lớn hơn 10 và nhỏ hơn 20 : là vùng không hợp lệ

• Thuộc [20-30] : vùng hợp lệ

• Thuộc lớn hơn 30: vùng không hợp lệ

• Nhập các ký tự không phải số nguyên : vùng không hợp lệ

Vì vậy có các case:

• Case hợp lệ:

  • Nhập 5 ký tự

  • Nhập 25 ký tự số

• Case không hợp lệ:

  • Không nhập vào trường

  • Nhập 15 ký tự

  • Nhập số thập phân

  • Nhập 35 kí tự

  • Nhập ký tự chữ: Tiếng việt, Tiếng anh, Full-size, Half-size

  • Nhập ký tự đặc biệt, space, kí tự Enter

  • Nhập câu lệnh SQL injection, HTML, XSS

Phân tích giá trị biên (Boundary Value Analysis (BVA) )

Phân tích giá trị biên dựa vào việc kiểm thử tại các ranh giới giữa các phân vùng, gồm các ranh giới: tối đa, tối thiểu, bên trong, bên ngoài, giá trị điển hình, giá trị lỗi 

Chúng ta thường thấy một số lượng lớn lỗi trên các phần mềm xảy ra tại ranh giới các giá trị đầu vào và các giá trị giữa, hay còn gọi là giá trị biên. 

Kỹ thuật thiết kế test cases này bổ sung cho phân vùng tương đương, dựa trên các nguyên tắc: Nếu một hệ thống hoạt động tốt với các giá trị biên thì nó sẽ hoạt động tốt cho tất cả các giá trị nằm giữa 2 biên 

Các kĩ thuật phân tích giá trị biên 

• Nếu một điều kiện đầu vào bị giới hạn giữa các trị trị x,y thì các test cases được thiết kế với các giá trị x và y, các giá trị ở trên và dưới x và y

• Nếu điều kiện đầu vào là một lượng lớn các giá trị, test cases cần được thiết kế với dữ liệu là các số min hoặc max, các giá trị trên và dưới của min,max

• Khi áp dụng 2 cách thực hiện trên cho các điều kiện cần của đầu ra, thì sẽ phản ánh được giá trị min và giá trị max cũng như các giá trị trên dưới của min và max

Ví dụ

Điều kiện đầu vào có giá trị từ 1 đến 10

Giá trị biên 0,1,2 và 9,10,11

Bảng quyết định (Decision Table based testing)

Bảng quyết định được gọi với cái tên khác là bảng nguyên nhân - ảnh hưởng. 

Bảng quyết định được sử dụng cho các chứng năng đáp ứng sự kết hợp của các yếu tố đầu vào và các biến cố

 Ví dụ: Nút Submit phải được enable nếu người dùng đã nhập tất cả các trường bắt buộc.

Kĩ thuật kiểm thử phần mềm này đầu tiên là cần xác định các chức năng trong đó đầu ra phụ thuộc vào sự kết hợp của các đầu vào. Nếu tập hợp kết hợp đầu vào lớn thì sẽ chia nó thành các tập hợp nhỏ hữu ích cho việc quản lý bảng quyết định.

Đối với các chứng năng khác, cần tạo 1 bảng và liệt kê tất cả các loại kết hợp của đầu vào và đầu ra. Sẽ giúp xác định các điều kiện tester bị bỏ qua

Các bước tạo bảng quyết định

• Nhập đầu vào theo hàng

• Nhập tất cả các quy tắc trong cột

• Điền vào bảng các sự kết hợp của đầu vào

• Trong hàng cuối cùng, ghi chú đầu ra so với kết hợp đầu vào

Chuyển đổi trạng thái

Trong kĩ thuật chuyển đổi trạng thái, các đầu vào thay đổi sẽ thay đổi trạng thái của ứng dụng. Kỹ thuật kiểm thử này giúp kiểm thử những cách xử lý của AUT. Tester có thể thực hiện hành động này bằng cách nhập các điều kiện đầu vào theo trình tự

Đội kiểm thử phần mềm sẽ cung cấp các giá trị kiểm thử đầu vào tích cực cũng như tiêu cực để đánh giá xử lý hệ thống hiệu quả 

Chuyển đổi trạng thái sử dụng khi nào

• Chuyển đổi trạng thái nên sử dụng khi nhóm kiểm thử đang kiểm thử ứng dụng cho một bộ giá trị đầu vào giới hạn.

• Được sử dụng khi nhóm kiểm thử muốn kiểm thử chuỗi các sự kiện xảy ra trong ứng dụng đang kiểm thử.

Bảng chuyển đổi trạng thái:

Theo như bảng trên thì khi người dùng nhập mã PIN chính xác, trạng thái được chuyển sang "Quyền truy cập được cấp". Người dùng nhập mật khẩu không chính xác sẽ được chuyển sang trạng thái tiếp theo. Người dùng nhập mật khẩu không chính xác lần thứ 3 sẽ đạt đến trạng thái bị chặn tài khoản.

Đoán lỗi (Error Guessing)

Kĩ thuật kiểm thử phần mềm dựa trên việc đoán lỗi có thể chiếm ưu thế trong code. Đây là kĩ thuật đòi hỏi phải có kinh nghiệm sâu, người phân tích kiểm thử sử dụng kinh nghiệm của mình để đoán ra phần có vấn đề hoặc lỗi của ứng dụng kiểm thử

Kĩ thuật tiếp theo đó là xác định danh sách các lỗi có thể xảy ra hoặc các tính huống lỗi có thể xảy ra. Người kiểm thử sẽ viết test cases để tìm những lỗi đó trong sản phẩm. Để có thể làm điều này, kiểm thử phần mềm phải có những kinh nghiệm sẵn có như sau 

• Tester áp dụng các kinh nghiệm trước đây để kiểm thử các ứng dụng tương tự

• Có hiểu biết về hệ thống đang kiểm thử

• Có kiến thức về các lỗi thực hiện điển hình

• Nhớ những chức năng phức tạp trước đây

• Có thể đánh giá lịch sử dữ liệu và kết quả kiểm thử

Kiểm thử bản tóm tắt nhu cầu người dùng (User Story) (AGILE)

Mỗi bản tóm tắt nhu cầu người dùng được dùng để mô tả tính năng được yêu cầu cho phàn mềm, trong bản tóm tắt cần phải xác được nhu cầu của khách hàng là gì, ai sẽ là người sử dụng chức năng đó, mục đích là gì?

Đây là thông tin cơ bản nhất mà nhóm phát triển cần biết để có thể hoàn thành công việc của mình. 

Định nghĩa hoàn thành (DOD): Định nghĩa các tiêu chuẩn hoàn thành như là: thực hiện xong việc viết mã lệnh, thực hiện xong kiểm thử mức đơn vị, thực hiện xong quá trình kiểm thử, thực hiện xong UAT….NHóm Scrum chịu trách nhiệm về kết quả thành công của sản phẩm, có trách nhiệm thực hiện DOD

Tiêu chuẩn hoàn thành sản phẩm phải được thể hiện rõ ràng bởi PO. PO phân cho nhóm phát triển 1 kịch bản thử nghiệm cho mỗi tiêu chí chấp nhận của sản phẩm. Các tiêu chí chấp nhận cần được kiểm thử cẩn thận 

Các tiêu chí kiểm thử và kết quả mong muốn cần được xác định trước khi bắt đầu chạy thử nghiệm.

Sử dụng các trường hợp kiểm thử

Các yêu cầu chức năng của một phần mềm sẽ được xác định và quản lý bằng cách trường hợp sử dụng. Công việc từ đó sẽ được xác định 1 cách cụ thể 

Các kịch bản kiểm thử được xây dựng lên bằng cách xem xét các đầu vào và đầu ra của từng bước thực hiện do người dùng xác định để đạt được mục đích cụ thể. Kết quả thực hiện được xác định bằng cách so sánh đầu ra mong đợi với kết quả thực tế 

Khi viết các trường hợp ra, chúng ta sẽ sử dụng ngôn ngữ kinh doanh hơn là ngôn ngữ kĩ thuật. Có ít nhất 1 kịch bản kiểm thử được chuẩn bị cho 1 yêu cầu, để đáp ứng tất cả các yêu cầu cần chuẩn bị đầy đủ các trường hợp kiểm thử

Kiểm thử dựa trên bảng danh sách

Chúng ta sẽ tạo ra danh sách kiểm tra chung độc lập từ các user story. Các mục danh sách này đều được sử dụng để kiểm thử 

Ví dụ các danh sách như sau

- Tất cả các liên kết trong hệ thống (Web / Di động) sẽ phải hoạt động chính xác. 

- Không nên có bất kì  lỗi ngữ pháp nào trong các bài viết trong hệ thống. 

- Kích thước phông chữ phải đẹpi. Không nên có bất kỳ hình ảnh nào không thể tải / hỏng trong hệ thống. 

- Hình ảnh, văn bản, vv sự liên kết giữa các thành phần với nhau phải như kì vọng

- Tất cả các nút cần được hoạt động đúng và mỗi nút hướng người dùng đến các hoạt động tương ứng. 

- Mỗi trang phải có biểu tượng trang chủ và sẽ được chuyển hướng đến trang chủ khi click

- Cảnh báo, thông báo thông tin sẽ được hiển thị theo đúng định dạng của nó.

- Nếu mà tải được trang thì nó phải được kiểm tra ở tất cả các độ phân giải. 

- Tất cả các thành phần trên trang web (danh sách thả xuống, popup, nút radio, v.v.) sẽ hoạt động chính xác nhất

- Các điều kiện đặc biệt (số, chữ và số, vv) trong các trường yêu cầu nhập phải được kiểm tra. 

- Mọi hoạt động của trang web không được kéo dài quá 3 đến 14 giây…

Kiểm thử thăm dò

Kiểm thử thăm dò là phương pháp thử nghiệm có sự kết hợp giữa thăm dò và kinh nghiệm, sự hiểu biết, khả năng phân tích và trí tuệ của kĩ sư kiểm tra trong các quy trình của agile

Để kiểm thử thăm dò bạn cần lên một kế hoạch gồm có: phạm vi chức năng, công cụ sử dụng, dữ liệu thử nghiệm, môi trường….Tài liệu cần được hoàn thành đầy đủ sau khi các bài kiểm tra kết thúc 

các công cụ được áp dụng trong thử nghiệm thăm dò gồm có: "Session Tester" có thể được sử dụng như để quản lý và thu âm “Session-Based Testing”. Kỹ thuật này bao gồm các bước sau:

Các hoạt động chính

- Thời gian kiểm tra khoảng 1-2 giờ

- Phiên hoạt động bao gồm: Thiết lập phiên, Kiểm thử thiết kế và thực hiện kiểm thử, tìm lỗi và báo cáo

- Mục đích của thực nghiệm là gì?

_ Mục tiêu của thử nghiệm là gì?

- Các chức năng có trong thử nghiệm (báo cáo thử nghiệm - điều lệ) đều nên được viết ra.

Kiểm thử dựa trên kinh nghiệm

Kỹ thuật kiểm tra dựa trên kiến thức kỹ năng và kinh nghiệm của người kiểm thử. Bằng trải nghiệm của người thực hiện kiểm thử để có được kế hoạch kiểm tra, chiến lược kiểm tra, đầu vào thử nghiệm và các kịch bản thử nghiệm. 

Với vị trí này yêu cầu bạn phải là người có kinh nghiệm với kiến thức kỹ thuật và kiến thức kinh doanh đầy đủ. Bạn sẽ dễ dàng xác định được những gì đang diễn ra trong hệ thống là đúng hay sai. Vì bạn đã có những trải nghiệm từ các dự án trước đây 

Nếu hệ thống đang được thử nghiệm chứa nhiều rủi ro thì không nên sử dụng kỹ thuật kiểm thử dựa trên kinh nghiệm vì nó không đi vào chi tiết để bao phủ toàn hệ thống

Kiểm thử hành trình người dùng

Những hành trình quan trọng mà người dùng sẽ thực hiện trong trang web được xác định dựa vào đó và dựng lên các trường hợp kiểm thử. Các kiểm thử này thường là các ca kiểm thử “từ đầu đến cuối” nên với phương pháp thử nghiệm này sẽ mất thời gian hơn các thử nghiệm khác, nhưng tỷ lệ bao phủ là cực cao

Kiểm thử hành trình người dùng là kiểm thử toàn diện và rộng, bao gồm các trường hợp có các xử lý quan trọng của hệ thống. Sẽ có lợi trong việc phát hiện sớm các lỗi nghiêm trọng trong quá trình phát triển phần mềm, được thử nghiệm rộng rãi. 

Thử nghiệm dựa trên rủi ro

Mục tiêu cơ bản của phương pháp này là tìm ra các lỗi quan trọng và quan trọng nhất càng sớm càng tốt với những chi phí thấp nhất. 

Tầm quan trọng của rủi ro = Khả năng * Tác động

Việc áp dụng sớm phương pháp thử nghiệm dựa trên rủi ro trong các dự án lớn là rất quan trọng để các vấn đề sớm được phát hiện

Các bước của thực hiện thử nghiệm rủi ro như sau

1- Bạn cần xác định các rủi ro và lập danh sách rủi ro theo thứ tự ưu tiên.

2- Lập kế hoạch kiểm tra theo danh sách rủi ro được ưu tiên và tiến hành các thử nghiệm thực hiện cho từng rủi ro sẵn có

3- Sau thử nghiệm sẽ là một số rủi ro sẽ được loại bỏ và một số trong số chúng sẽ bị phát sinh. Rủi ro mới sẽ được tiến hành kiểm thử lại một lần nữa. Giai đoạn này, mục tiêu cơ bản nhất của chúng tôi là tìm ra những khiếm khuyết quan trọng nhất.

Nếu bạn phụ trách dự án cho sản phẩm có khả năng lỗi cao thì bạn sẽ cần phân tích rủi ro một cách chi tiết. Có thể sử dụng các mô hình thống kê để thực hiện phương pháp này. Một trong những mô hình được dùng nhiều đó là mô hình PHÂN TÍCH TÁC ĐỘNG VÀ HÌNH THỨC SINH RA LỖI SAI (FMEA).

Thử nghiệm dựa trên rủi ro theo kinh nghiệm của James Bach

Khi bạn bắt đầu dự án, việc phân tích rủi ro không thể đủ đầy và chính xác 100%. Khi vào dự án, sự tiến triển và sản phẩm của bạn được cải thiện, ước tính và phân tích rủi ro của bạn sẽ ngày càng trở nên mạnh mẽ hơn. 

Hai yếu tố quan trọng nhất đối với rủi ro là kinh nghiệm và tinh thần đồng đội. Trong khoảng thời gian giữa dự án, các sản phẩm hoặc công nghệ sẽ bắt đầu lộ ra các vấn đề đặc trưng

Điều quan trọng là quan sát và tìm hiểu để làm phân tích rủi ro được chính xác nhất. 

Kết luận
Hy vọng bài viết này của NIIT ICT đã giúp các bạn hiểu rõ hơn kiểm thử phần mềm là gì, có những loại nào.