Chương 7: KIỂM THỬ PHẦN MỀM

Xác minh và thẩm định phần mềm là 1 quá trình liên tục và xuyên suốt mọi giai đoạn của quá trình phần mềm, xác  minh và thẩm định là từ chung cho các quá trình kiểm tra để đảm bảo phần mềm thỏa mãn các yêu cầu của chúng là thỏa mãn người dùng . Xác minh và kiểm thử có 2 mục tiêu :Phát hiện các khuyết tật trong hệ thống; Đánh giá xem hệ thống liệu có dùng đc hay ko?

 Sự khác nhau giữa xác minh và thẩm định :Thẩm định: Xem xét cái được xây dựng có là sản phẩm đúng không? Tức làkiểm tra xem chương trình có được như mong đợi của người dùng hay không.; Xác minh: Xem xét cái được xây dựng có đúng là sản phẩm không? Nhưthế, xác minh là kiểm tra chương trình có phù hợp với đặc tả hay không.

Tại sao phải kiểm thử phần mềm ? Kiểm thử phần mềm là yếu tố quyết định chất lượng phần mềm và khâu điển hình của rà soát đặc tả thiết kế và lập mã

Lý do cần kiểm thử phần mềm: Muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động;Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này.    

Mục tiêu của kiểm thử phần mềm là tìm ra lỗi (nếu có) với chi phí thấp nhất. Theo Glen Myers: *) Kiểm thử là một quá trình vận hành chương trình để tìm ra lỗi.Một ca kiểm thử thắng lợi là phải làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ.

 Kiểm thử phần mềm giúp:Phát hiện được lỗi trong chương trình (nếu có).Chứng minh phần mềm hoạt động đúng như đã thiết kế.Chứng minh phần mềm được viết đúng Chứng minh phần mềm đáp ứng yêu cầu của user.Góp phần chứng minh chất lượng của phần mềm.

Phân loại kiểm thử :Thử thống kê :cho nhiều bộ dữ liệu khác nhau để chạy thử và tính tần suất thất bại. Thử khuyết tật : cho những dữ liệu thật đặc biệt để chạy thử , phép thử thành công nếu phơi đc nhiều khuyết tật. Thử giới hạn : tăng dần tải cho tới khi không chịu đc

Ca kiểm thử : Một ca kiểm thử tốt: là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa được phát hiện.Một ca kiểm thử thành công: là một ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện

Biểu đồ dòng thông tin kiểm thử

(1) Cấu hình phần mềm: Bản Đặc tả yêu cầu phần mềm, bản Đặc tả thiết kế, chương trình gốc

(2) Cấu hình kiểm thử: Kế hoạch và thủ tục kiểm thử, các công cụ kiểm thử dự định dùng, các ca kiểm thử cùng kết quả dự kiến.

Kỹ thuật kiểm thử :

Kiểm thử hộp trắng:Đối với cách test Black Box Testing thì chỉ quan tâm dến giá trị đầu vào và giá trị đầu ra có đúng không mà không quân tâm đến code bên trong ra sao.Nhưng đối với cách test White Box Testing  không nhửng kiểm tra giá trị đầu vào và đầu ra mà còn test dựa trên code của chương trình.Phương pháp test này kiểm tra chặt chẻ hơn , tạo ra các trường hợp thử nghiệm để thực hiện chương trình 1 cách logic hơn., thường dùng cho những những module nhỏ.

Kiểm thử các đường độc lập cơ bản , bảo đảm số phép thử là ít nhất đủ để phát hiện lỗi;Tất cả các đường thực thi độc lập được qua ít nhất 1 lần ;Thử các điều kiện rẽ nhánh ở 2 nhánh : true và false;Thử qua vòng lặp tại biên cũng như bên trong;Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó

 Có 2 loại test White Testing: Control Flow : Là việc test dựa vào các lệnh trong cách ngôn ngử lập trình như lệnh tuần tự,lệnh rẽ  nhánh(như if... else...) ,vòng lập (for, while, loop…).

 Data Flow Là tập trung vào kiểm tra giá trị của các biến trong chương trình Biến sẽ xuất hiện theo 2 dạng: khai báo và gán giá trị Biến sẽ được sử dụng theo 2 cách: predicate (kiểm tra điều kiện) và computational (tính toán) .

*** chú ý : kiểm thử viên hiểu rõ cấu trúc bên trong mã nguồn.thực hiện kiểm thử sự đúng đắn của mã nguồn.thường được sử dụng để thẩm định.

Kiểm thử hộp đen: Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao,bao gồm các đặc tả yêu cầu(requirements), các sự kiện(events). Phương pháp này thường dùng để test chức năng của chương trình. 

Kiểm thử hộp đen tìm  các lỗi thuộc nhóm sau : Hàm không có hoặc không đúng ;Lỗi giao diện ;Lỗi trong cấu trúc dữ liệu được sử dụng bởi các giao diện;Lỗi hiệu năng hoặc lỗi hành vi;Lỗi bắt đầu và lỗi chấm dứt.

Các phương pháp testing phổ biến :Phương pháp phân đoạn tương đương (Equivalence Class Partitioning):Chia dữ liệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu vì vậy việc kiểm thử chỉ thực hiện trên đại diện đó.Mục đích làm giảm số lượng test bằng cách chọn các tập dữ liệu đại diện.Phương pháp này thường được dùng để test các yêu cầu ở mức trừu tượng hơn là test theo trường.Áp dụng để test màn hình,menu hay test mức quá trình. Phương Pháp Phân Tích Giá Trị Biên (Boundary Value Analysis) : Là trường hợp riêng của phương pháp phân đoạn tương đương (Equivalence.Partitioning).Phương pháp này thường dùng để test giá trị biên của các giá trị đầu vào, các miền giá trị. Thường sử dụng để test module chức năng của chương trình.Kỹ Thuật Cause-Effect Graphing : đối với kỹ thuật Cause-Effect Graphing  cho phép xác định ra các trường hợp kiểm thử hiểu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các lớp Kỹ thuật này gồm 4 bước như sau : Xác định Cause ( điều kiện nhập vào) và effect ( là hành động) cho mổi một module cần kiểm định;  Xây dựng đồ thị cause-effect; Đồ thị được chuyển thành bảng quyết định; Những phần/luật trong bảng quyết định được chuyển thành các trường hợp kiểm thử.

Ưu điểm của kiểm thử hộp đen là khả năng đơn giản hóa việc kiểm thử tại các mức độ được đánh giá là khó kiểm thử. 

Nhược điểm của kiểm thử hộp đen là khó đánh giá nhửng giá trị nào chưa được kiểm thử hay không. kiểm thử viên không cần (không nên) biết mã nguồn.( nên không nhất thiết phải là lập trình viên).Mã nguồn như 1 hộp đen đối với họ.Họ chỉ biết đưa vào hộp đen cái gì và hộp đen sẽ trả ra ngoài cái gì.

Chiến thuật kiểm thử phần mềm :tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm thử  phần mềm thành công với chi phí thấp.Bao gồm các công việc:  Lập kế hoạch kiểm thử ; Sinh test-case; Thực hiện kiểm thử , thu thập kết qủa và đánh giá; Xác minh : các hành động để đảm bảo cho phần mềm được thực thi đúng theo 1 chứu năng cụ thể nào đó;Thẩm định : các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng

Một chiến thuật kiểm thử phổ biến : gồm Phát triển(Phân tích toàn bộ hệ thống ;Phân tích yêu cầu ;Thiết kế;Lập trình ) .Kiểm thử gồm (Kiểm thử đơn vị ;Kiểm thử tích hợp ;Kiểm thử tính năng ;Kiểm thử toàn bộ hệ thống)

Kiểm thử từng module :Tiến hành kiểm thử  trên từng đơn vị nhỏ nhất của phần mềm, đó là module mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công

Thường dùng kỹ thuật kiểm thử  white-box;Có thể tiến hành kiểm thử  cùng lúc nhiều module;Một số vấn đề trong việc xây dựng các test case;Test case nào?Dữ liệu đầu vào và đầu ra có tử đâu?Tính độc lập/phụ thuộc hoạt động của các module;Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm thử  khác à có thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%)

Kiểm thử tích hợp :Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không?

Phải tiến hành kiểm thử  tích hợp để phát hiện lỗi liên quan đến giao tiếp giữa các module; Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, và toàn bộ chương trình sẽ được kiểm thử  một lúc;Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên;Module chính được dùng như là driver, và stub được thay thế bởi các module con trực tiếp của của module chính nàyTuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi module tương ứng đã kiểm thử ;Tiến hành kiểm thử  khi có sự thay thế mới;Tiến hành kiểm thử  hồi quy để phát hiện các lỗi khác trong từng module ;Gồm có : Tích hợp từ trên xuống và Tích hợp từ dưới lên

Kiểm thử hồi quy :Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module.

Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm thử  theo đơn vị nên  Phải kiểm thử  hồi quy khi tích hợp

Kiểm thử  hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động.

Kiểm thử tính năng : hiểu theo cách đơn giản nhất là: kiểm tra các chức năng của phần mềm đáp ứng được nhu cầu của khách hàng đã được xác định trong văn bản đặc tả yêu cầu của phần mềm.  Áp dụng kỹ thuật black-box

Kiểm thử  tính năng bao gồm:  Xem xét lại cấu hình phần mềm theo lược đồ triển khai; Kiểm thử  alpha; Kiểm thử  beta

Kiểm thử hướng đối tượng :  về cơ bản giống thứ tự như kiểm thử cổ điển :

Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm thử ; Tác vụ được đóng bao trong lớp; Các lớp con có thể override một tác vụ nào đó;Kiểm thử  đơn vị hướng đối tượng tập trung vào các lớp à kiểm thử  hành vi của lớp

Kiểm thử theo kịch bản: dựa vào các use – case để soạn ra các kịch bản

Nghệ thuật gỡ rối : gỡ rối là 1 quá trình nhằm loại bỏ các lỗi được phát hiện trong quá trình kiểm tra .Gỡ rối được thực hiện như là một kết quả của việc kiểm tra: lỗi phát hiện được à tìm kiếm nguyên nhân à sửa lỗi.  Có 3 hình thức gỡ rối:Brute force : là phương pháp phổ biến nhất nhưng lại hiểu quả nhất Triết lý của phương pháp này là : hãy để máy tính tìm ra lỗi Loại trừ nguyên nhân  : dưạ trên nguyên tắc chia nhị phân; Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi;  Danh sách này được thử  lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất;  Khi đó dữ liệu kiểm thử  sẽ được tinh chế lại để tiếp tục tìm lỗi  và theo vết: Là 1 phương pháp gỡ lỗi phổ biến , cách thực hiện : bắt đầu từ dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm được thấy dòng gây ra lỗi . Nên dùng kết hợp cả 3 hình thức này.

Các lỗi có thể mắc trong thiết kế và cài đặt phần mềm :Lỗi thứ 1 : lỗi về ý đồ thiết kế sai: Đây là lỗi nặng nhất. Hệ thống mà chúng ta xây dựng sẽ không thể đáp ứng được yêu cầu của khách hàng.Lỗi thứ 2 : lỗi phân tích các yêu cầu không đầy đủ hoặc sai lệch :Đây là lỗi cũng thường xảy ra. Thực tế cho thấy, những người làm chuyên môn thì không hiểu sâu về tin học nên không cung cấp được những thông tin cần thiết cho những người làm tin học. Ngược lại, những người làm tin học là không hiểu hết về chuyên môn nghiệp vụ của khách hàng. Do vậy mà việc thu thập thông tin sẽ không đầy đủ hoặc thiếu chính xác. Chính vì vậy mà dễ mắc lỗi. Lỗi thứ 3 : lỗi hiểu sai chức năng :Đây là lỗi thường hay mắc phải do trong hệ thống có thể có các chức năng hay lĩnh vực có tính chuyên môn cao. Các từ chuyên ngành. Dẫn đến khó hiểu đối với nhà phát triển phần mềm. Lỗi thứ 4 :lỗi bỏ sót các chức năng :. Lỗi này các nhà phát triển phần mềm cũng hay mắc phải, do điều kiện thời gian và chuyên môn có hạn, đôi khi các chức năng không thể được đưa ra một cách đầy đủ.Lỗi thứ 5 : lỗi tại các đối tượng chịu tải:Lỗi xảy ra tại các hàm hoặc các thủ tục cấp thấp xây dựng lên các thủ tục khác. Lỗi này cũng là một lỗi nặng, có thể kéo theo sai xót ở một loạt các hàm hoặc thủ tục khác. Lỗi thứ 6 :lỗi lây lan :Đây là lỗi do virus có thể lây từ chương trình này sang chương trình khác.Lỗi thứ 7 : lỗi cú pháp: Lỗi này sinh ra do việc viết sai các quy định về văn phạm. Lỗi thứ 8 : lỗi do hiệu ứng phụ :Lỗi xảy ra do việc sử dụng hàm, thủ tục hay chương trình con, có các phép tính biến đổi chương trình con nằm ngoài ý muốn của người lập trình.