Khái niệm và nguyên tắc căn bản về kiểm thử

Nội dung bài học

1. Khái niệm căn bản về kiểm thử

1. Khái niệm kiểm thử phần mềm
2. Cấp độ (giai đoạn) kiểm thử
3. Tình huống kiểm thử
4. Loại hình kiểm thử
5. Phương pháp kiểm thử

1.1 Khái niệm kiểm thử phần mềm

• Khái niệm: Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả,và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.
• Mục đích: Tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm.

1.2 Giai đoạn kiểm thử

• Kiểm thử đơn vị– Unit testMột đơn vị-Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit.

  Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra.

  Unit Test thường do lập trình viên thực hiện trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit.

   

• Kiểm thử tích hợp– Intergration TestIntegration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

  Hai mục tiêu chính của Integration Test:

  • Phát hiện lỗi giao tiếp xảy ra giữa các Unit
  • Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test). 
• Kiểm thử hệ thống – System TestMục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

   

• System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. 
• Kiểm thử chấp nhận sản phẩm– Acceptance TestThông thường, sau giai đoạnS ystem Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

  Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

1.3 Tình huống kiểm thử

• Positive test: Còn gọi lại clean test hay valid test. Test những trường hợp mà user sử dụng hệ thống một cách bình thường, đúng ý đồ thiết kế.
• Negative test: Còn gọi là dirty test hay invalid test.. Test  những trường hợp user làm những hành động khác thường hay đưa vào những dữ liệu không hợp lệ.

Các điều kiện mà người ta nghĩ ra để kiểm thử một sản phẩm nào đó có thể được chia làm hai loại: (1) loại thuộc nhóm những điều kiện thông thường mà một người sử dụng theo logic thông thường sẽ tạo ra chúng, (2) loại thuộc nhóm những điều kiện chỉ xảy ra khi NSD nhầm lẫn về logic hay thao tác, hoặc có kẻ cố tình phá hoại hoặc truy cập vào những thông tin mình không được phép vào, hặc khi môi trường sử dụng phần mềm có điểm bất thường (như không kết nối được với Database, mất điện đột ngột, User không được phân quyền…). Tương ứng với đó ta có hai khái niệm: (1) positive test hay còn gọi là test sạch, và (2) negative test hay còn gọi là test bẩn.

1.4 Loại hình kiểm thử

Ứng với mỗi khía cạnh chất lượng nào đó của sản phẩm cần test – có các loại hình kiểm thử

• Kiểm thử chức năng (Functional Test): nhằm bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. 
• Kiểm thử hiệu năng (Performance Test): Bảo đảm hiệu suất hoạt động của hệ thống xét về thời gian cần thiết để phản hồi cho người dùng, tài nguyên (ví dụ RAM, CPU) bị tiêu tốn. Bao gồm các test để bảo đảm tối ưu việc sử dụng bộ nhớ nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn, các test để bảo đảm hệ thống vận hành được dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc)… 
• Kiểm thử tính dễ dùng (Usability testing): bảo đảm người dùng dể hiểu, dễ đoán cách dùng phần mềm và có thể thao tác nhanh chóng trên phần mềm để thực hiện một tác vụ nào đó.
• Kiểm thử bảo mật (Security testing): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. 
• Kiểm thử khả năng cài đặt (Installability testing): bảo đảm phần mềm có thể được cài đặt hoặc gỡ bỏ thành công.
• Kiểm thử khả năng phục hồi (Recovery testing): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn địnhtrước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến… 
• Kiểm thử tính tương thích (Compatibility testing): bảo đảm phần mềm có thể tương thích được với nhiều hệ điều hành/trình duyệt/cấu hình phần mềm/phần cứng khác nhau

1.5 Phương pháp kiểm thử

• Kiểm thử hộp đen – Black box testing 

Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

Ưu, nhược điểm 

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

• Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.

• Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.

2. Vai trò – tầm quan trọng của kiểm thử

• Chi phí phát triển phầm mềm
  • Chi phí thực thi
  • Chi phí kiểm thử
  • Chi phí sửa lỗi
• Hiệu quả đầu tư vào Testing

3. Nguyên tắc cơ bản trong kiểm thử

3.1 Phải truy vết từ Tests-Requirements. 

3.2 Phải chuẩn bị từ đầu dự án. 

3.3 Lỗi quần tụ – 20%  >> 80% lỗi

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.
=> Test kỹ chức năng quan trọng => found bug => test những gì liên quan + những chức năng gần nó để tìm ra bug nhiều hơn.

3.4 Phải test dần từ sớm. 

Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.

3.5 Phải chú ý test các exceptions. – Kiểm thử theo các ngữ cảnh độc lập

Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau. Để hiểu rõ hơn chúng ta xem ví dụ sau:
Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:
– Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
– Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
– Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v….

3.6 Việc sửa lỗi phải được hoạch định song song. 

4. Xác định thời điểm kết thúc kiểm thử?

• Không thể test hết mọi trường hợp
• Test chỉ có thể chỉ ra rằng có lỗi chứ không thể chỉ ra rằng đã hết lỗi
• Có thể dừng test khi
  • Rủi ro về chất lượng ở mức chấp nhận được
  • Các mục tiêu, chỉ tiêu đưa ra trong kế hoạch test đã đạt được
• Phụ thuộc vào mức độ rủi ro của hệ thống
  • Khả năng bỏ sót những lỗi nghiêm trọng?
  • Mức độ ảnh hưởng nếu xảy ra lỗi bỏ sót?

 Nên dùng các biểu đồ, số liệu thống kê để đánh giá xu hướng lỗi của phần mềm nhằm phán đoán khả năng còn lỗi.

——–END————