Hiệu quả kiểm thử được tính như thế nào
|
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! Show
Kĩ thuật kiểm thử phần mềm phân vùng tương đươngKĩ 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:
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:
Nguyên tắc bao gồm:
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:
Vì vậy có các case:
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
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
Chuyển đổi trạng tháiTrong 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
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
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áchChú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ệmKỹ 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ùngNhữ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 roMụ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 BachKhi 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. |
