Kiểm thử phần mềm

TS. Trần Cao Đệ

Năm 2010

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

• Testing is the process of executing a program with the intention of finding errors. (Myers)
• Mục đích của kiểm thử
• Nhằm phát hiện lỗi phần mềm.
• Chứng tỏ phần mềm thực hiện đúng các chức năng mong đợi.
• Nhằm xác lập độ tin cậy của cái mà chương trình muốn thực hiện.
• Một kiểm thử tốt phải kiểm tra được những hành vi bất thường của chương trình.
• Testing can show the presence of bugs but never their absence. (Dijkstra)

Các mức độ kiểm thử

• Kiểm thử đơn vị (Unit Testing)
• Kiểm thử tích hợp (Integration Testing)
• Kiểm thử hệ thống (System testing)
• Kiểm thử chấp nhận (Acceptance Testing)

​

Kiểm thử đơn vị

• Một đơn vị là một thành phần nhỏ nhất của phần mềm có thể kiểm tra được
• Functions, Procedures, Classes, và Methods có thể xem là “đơn vị”
• Ví dụ :
• C++ or Java: lớp (Class)
• C: hàm hoặc chương trình con
• Pascal: hàm hoặc thủ tục
• 4GL: Menu hoặc GUI

Nội dung kiểm thử đơn vị

• Giải thuật và logic
• Cấu trúc dữ liệu
• Giao diện (Interfaces)
• Các nhánh độc lập (Independent paths)
• Giá trị biên, điều kiện biên
• Bẫy lỗi và kiểm soát lỗi (Error handling)

Qui trình kiểm thử đơn vị

Qui trình kiểm thử

Kiểm thử đơn vị trong tiến trình phần mềm

Kiểm thử tích hợp

• Kiểm thử tích hợp là kiểm thử một tổ hợp các thành phần của một phần mềm (tạo thành một chức năng đầy đủ)
• Tập trung vào việc làm thế nào để các thành phần (đơn vị) làm việc với nhau.
• Kiểm thử tích hợp nhằm:
• Phát hiện lỗi xảy ra trong giao diện giữa các thành phần đơn vị.
• Lắp ráp các đơn vị riêng rẽ vào một hệ thống con và vào một hệ thống hoàn chỉnh cuối cùng.

Kiểm thử hệ thống

• Kiểm thử hệ thống nhằm kiểm tra thiết kế và hệ thống thỏa mãn đặc tả
• Kiểm thử hệ thống được thực hiện sau khi hoàn tất kiểm thử đơn vị và kiểm thử tích hợp.

Kiểm thử chấp nhận

• Kiểm thử chấp nhận
• Nhằm để cho người dùng đánh giá phần mềm theo mục đích và kỳ vọng của họ.
• Là bước quan trọng để người dùng xác định mức độ thỏa mãn các yêu cầu.
• Thực hiện sau khi hoàn tất kiểm thử hệ thống.
• Phần mềm phải được thực thi trong thế giới thực của nó (phần mềm, phần cứng)
• Nếu phần mềm phát triển cho một thị trường lớn thì kiểm thử chấp nhận gồm hai bước:
• Alpha test: trên máy của nhà phát triển.
• Beta test: người dùng install và dùng thử trong thế giới thực.

Mô hình kiểm thử hình chử V

Kiểm thử hồi qui (Regression testing )

• Kiểm thử lại trên một phiên bản mới
• Kiểm tra tính đúng đắn sau khi thực hiện một số thay đổi trên phần mềm (đã kiểm thử thành công)
• Đảm bảo code mới thêm/sửa không đưa ra lỗi mới.

Kiểm thử xác nhận

• Validation testing
• Để chỉ cho người phát triển và khách hàng rằng phần mềm đúng, thỏa yêu cầu
• Một test thành công chỉ ra rằng hệ thống vận hành như mong đợi.
• Defect testing
• Để tìm lỗi trong phần mềm mà hành vi nó không đúng hoặc không thỏa mãn đặc tả;
• Một test thành công là test chỉ ra rằng hệ thống không hoạt động đúng và làm xuất hiện lỗi trong hệ thống.

Chính sách kiểm thử

• Vét cạn các trường hợp có thể chỉ ra chương trình sạch lỗi. Tuy nhiên vét cạn là không thể
• Chính sách kiểm thử xác định cách thức tiếp cận để kiểm thử có hệ thống và bao quát, cần test :
• Tất cả các chức năng truy cập được từ menu
• Tổ hợp các chức năng truy cập được trên cùng menu
• Khi có input từ người dùng, phải test với dữ liệu đúng và với dữ liệu sai

Case study

• A student in Scotland is studying American History and has been asked to write a paper on ‘Frontier mentality in the American West from 1840 to 1880’. To do this, she needs to find sources from a range of libraries. She logs on to the LIBSYS system and uses the search facility to discover if she can access original documents from that time. She discovers sources in various US university libraries and downloads copies of some of these. However, for one document, she needs to have confirmation from her university that she is a genuine student and that use is for non-commercial purposes. The student then uses the facility in LIBSYS that can request such permission and registers her request. If granted, the document will be downloaded to the registered library’s server and printed for her. She receives a message from LIBSYS telling her that she will receive an e-mail message when the printed document is available for collection.

Các chiến lược…

• Test the login mechanism using correct and incorrect logins to check that valid users are accepted and invalid users are rejected.
• Test the search facility using different queries against known sources to check that the search mechanism is actually finding documents.
• Test the system presentation facility to check that information about documents is displayed properly.
• Test the mechanism to request permission for downloading.
• Test the e-mail response indicating that the downloaded document is available.

Nguyên tắc (Testing guidelines)

• Chọn các dữ liệu test để lộ ra lỗi
• Chọn đầu vào làm cho hệ thống sinh ra các thông báo lỗi
• Thiết kế input sao cho tràn buffer, tràn số,…
• Lặp lại cùng input vài lần
• Chọn dữ liệu vào làm sinh ra output sai
• Chọn dữ liệu vào làm sinh tính toán quá lớn hoặc quá nhỏ

Loại kiểm thử (Testing types)

• Kiểm thử chuần mực (Benchmark test)
• so sánh hiệu năng của một đối tượng cần test với một chuẩn mực đã biết.
• Kiểm thử cấu hình (Configuration test)
• Kiểm tra đối tượng cần test với các cấu hình phần mềm/cứng khác nhau
• Kiểm thử chức năng (Functional test)
• Kiểm tra đối tượng cần test với hoạt động đúng như mong đợi
• Kiểm thử cài đặt (Installation test)
• Kiểm tra đối tượng cần test được cài đặt thành công với các cấu hình khác nhau, trong môi trường khác nhau và trong các điều kiện khác nhau (ví dụ thiếu không gian đĩa)

Loại kiểm thử (tt)

• Kiểm thử tính toàn vẹn (Integrity test)
• Kiểm tra tính tin cậy, chắc chắn và sức chịu đựng lỗi trong khi thực thi
• Kiểm thử tải (Load test)
• Kiểm tra khả năng chấp nhận của đối tượng cần test trong các điều kiện vận hành khác nhau như: số user, số transaction với cùng một cấu hình.
• Kiểm thử hiệu năng (Performance test)
• Kiểm tra khả năng chấp nhận của đối tượng cần test với các cấu hình khác nhau với cùng điểu kiện vận hành
• Stress test
• Kiểm tra khả năng chấp nhận của đối tượng cần test trong các điều kiện bình thường và bất thường (ví dụ không đủ nguồn lực, số user cực kỳ cao)

Loại kiểm thử (tt)

• Các loại test khác
• Security testing
• Recovery testing
• Usability testing
• Compatibility testing
• Các kiểu kiểm thử đòi hỏi trong một project dựa trên:
• Nhu cầu của project
• Nhu cầu của khách hàng
• Các cải tiến cho tương lai

Kiểm thử hộp đen

• Kiểm thử hộp đen
• functional, data-driven, input/output driven testing
• Dựa trên đặc tả
• Nó chỉ ra trạng thái của thành phần được test với các input, output và một đặc tả.
• Dùng để xác định rằng chương trình hoạt động đúng (hoặc sai) đặc tả

Chương trình

(black box)

inputs

outputs

specifications

events

Kiểm thử hộp trắng

• Kiểm thử hộp trắng:
• Khảo sát cấu trúc điều khiển /logic chương trình
• Thường dùng với kiểm thử đơn vị
• Thực hiện bởi người phát triển kiêm tester
• Mục tiêu là kiểm tra thành phần (đơn vị) bằng cách khảo sát tất cả các đường đi/nhánh chương trình.

​

Ví dụ về control graph

• Procedure sort(var x:array; n:integer);
• Var i,j,save:integer;
• Begin
• for i:=2 to n do
• for j:=1 to i do
• if x[i]<x[j] then begin
• save:=x[i];
• x[i]:=x[j];
• x[j]:=save
• end
• End;

​

Số đường đi độc lập: V(G)=4

• 1-2-3-4-11
• 1-2-3-4-5-6-7-8-9-10-4-11
• 1-2-3-4-5-6-10-4-11
• 1-2-3-4-5-4-11

​

• Mảng x  mảng được sắp thứ tự
• Test cases
• Nhánh 1: [1]  [1]
• Nhánh 2: [1,4,3,2,0]  [0,1,2,3,4]
• Nhánh 3: [1,2,3,4]  [1,2,3,4]
• ​

Verification vs Validation

• Kiểm tra (Verification) đảm bảo hệ thống thỏa các chuẩn, các qui trình, qui định của tổ chức dựa trên xét duyệt hoặc các phương pháp không thực thi (non-executable)
• Verification trả lời “Did we build the system right?”
• Ví dụ : xét duyệt đặc tả, thiết kế, code (Walkthrough hoặc Inspection)
• Kiểm tra xác nhận (Validation) đảm bảo hệ thống vận hành đúng như mong đợi dựa vào chuỗi các test.
• Validation trả lời: “Did we build the right system ?”
• Ví dụ: Unit Testing, Integrated testing, System testing, User acceptance testing

Chu trình kiểm thử (Testing cycle)

• Phần tích yêu cầu: kiểm thử phải bắt đầu từ giai đoạn đặc tả phần mềm.
• Phân tích thiết kế : trong giai đoạn thiết kế, tester làm việc với developper để xác định các đặc trưng cần test và test được cùng với các tham số cần thiết.
• Lập kế hoạch test: chọn chiến lược, lập kế hoạch, tạo ra các yêu cầu test.
• Phát triển test: qui trình test, kịch bản test, Test Cases, Test Scripts dùng để test.
• Thực hiện test: thực hiện test theo kế hoạch ghi nhận và báo cáo lỗi cho bộ phận phát triển.
• Báo cáo test: sau khi hoàn tất test, tester làm các độ đo cần thiết và làm báo cáo tổng kết về công việc test đồng thời xác định phần mềm có thề release được hay không (dựa vào chuẩn) .
• Test lại sau khi sửa đổi

Lưu đồ công việc kiểm thử

Kế hoạch kiểm thử

• Xác định phạm vi công việc cần làm (test)
• Qui trình test: tài liệu xác định cách thức tiến hành mọi test.
• Báo cáo Test (Report): tài liệu ghi nhận trạng thái của test khi thực hiện

Ước lượng công việc

• Cần trả lời các câu hỏi:
• Cần bao nhiêu test?
• Phát triển các test bao lâu?
• Thực hiện các test bao lâu?
• Cần bao nhiêu thời gian/người?

Chủ điểm cần đề cập trong KH test

• Ước lượng về test
• Cách phát triển test và kiểm chứng, chứng thực (không hình thức)
• Xét duyệt và chứng thực hình thức
• Tiêu chí hoàn thành test

Ví dụ về ước lượng

Ví dụ về ước lượng (tt)

Estimated Number of Tests: 165

Average Test Development Time: 3.5

(person-hours/test)

Estimated Test Development Time: 577.5

(person-hours)

Validation Test Plan�IEEE – Standard 1012-1998

• Overview
• Organization
• Tasks and Schedules
• Responsibilities
• Tools, Techniques, Methods
• Processes
• Management
• Acquisition
• Supply
• Development
• Operation
• Maintenance

Validation Test Plan (cont)�IEEE – Standard 1012-1998

• Reporting Requirements
• Administrative Requirements
• Documentation Requirements
• Resource Requirements
• Completion Criteria

Fault, error and failure

• Software Fault : một sai sót (defect) tĩnh trong phần mềm
• Ví dụ: quên cấp phát ô nhớ cho con trỏ
• Software Error : một trạng thái sai (bên trong) thể hiện một sai sót nào đó trong phần mềm.
• Ví dụ: truy xuất con trỏ chưa được cấp phát bộ nhớ
• Software Failure : một hành vi không đúng, không mong đợi thể hiện ra bên ngoài
• Ví dụ: chương trình bị treo (do truy xuất con trỏ không được cấp phát bộ nhớ)

Testing Activities

Test tự động

• Các Test được thực thi tự động
• Bốn bước cho test tự động
• Phân tích các trường hợp test và thiết kế test
• Viết tập lệnh test (Test Scripts)
• Kiểm tra tập lệnh test
• Đóng gói và giao cho khách hàng
• Test tự động dùng chủ yếu:
• Test hồi qui mỗi khi dịch và tích hợp hệ thống (build)
• Hướng dữ liệu: dùng nhiều giá trị dữ liệu test cùng một hoạt động
• Test hiệu năng
• test Stress
• Load testing
• Special test, or customer required
• Tests required detailed information from application internals (e.g., SQL, GUI attributes)
• Ví dụ: Junit trợ giúp test các chương trình Java.

Ví dụ một test script với Junit

/** Test of setName() method, of class Value */

​

@Test

public void createAndSetName()

{

Value v1 = new Value( );

​

v1.setName( "Y" );

​

String expected = "Y";

String actual = v1.getName( );

​

Assert.assertEquals( expected, actual );

}

​

Test and test again

Hết chương