4. Ý nghĩa lý luận và thực tiễn của đề tài
3.2.5. Bao phủ nhiều điều kiện
Bao phủ nhiều điều kiện (multiple condition coverage) là bao phủ sự xảy ra đồng thời các biểu thức Boolean con trong một biểu thức. Giống với bao phủ điều kiện, các biểu thức con được liên kết bằng các phép logic-and và logic-or.
int proc(int a, int b, int x) { if ( (a>1) && (b==0) ) { x = x/a; } if ( (a==2) || (x>1) ) { x = x+1; } return x; }
Bao phủ đa điều kiện đảm bảo phủ được tất cả nhánh và tất cả câu lệnh tại điểm phân nhánh.
1. a > 1 is true and b = 0 is true 2. a > 1 is true and b = 0 is false 3. a > 1 is false and b = 0 is true 4. a > 1 is false and b = 0 is false 5. a = 2 is true and x > 1 is true 6. a = 2 is true and x > 1 is false 7. a = 2 is false and x > 1 is true 8. a = 2 is false and x > 1 is false
a = 2, b = 0, x = 2 a = 2, b = 1, x = 0 a = 0, b = 0, x = 2 a = 0, b = 1, x = 0
Các đường đi sẽ được thực thi: 1 – 3 – 4 – 5 – 7
1 – 2 – 4 – 5 – 7 1 – 2 – 4 – 5 – 7 1 – 2 – 4 – 6 – 7
3.3. Bao phủ phần mềm hƣớng đối tƣợng
Việc dùng độ đo bao phủ cấu trúc để đo mức hoàn thiện của một tập các ca kiểm thử là một kỹ thuật được xem là tốt. Tuy nhiên, áp dụng kỹ thuật này cho phần mềm hướng đối tượng hiện nay còn nhiều thách thức. Việc đo mức độ bao phủ cấu trúc truyền thống như là: Bao phủ câu lệnh, bao phủ nhánh và bao phủ điều kiện. Làm thế nào để đo được các độ bao phủ này với mỗi phương thức. Đáng tiếc là các độ đo truyền thống không thể đưa vào áp dụng trực tiếp cho kiểm thử phần mềm hướng đối tượng. Đặc biệt, kiểm thử tính đa hình và tính đóng gói đây là những đặc tính tiêu biểu của thiết kế phần mềm hướng đối tượng.
3.3.1. Một cách mới đo mức độ bao phủ
Bao phủ phạm vi (Context coverage) là cách thức tập trung vào dữ liệu của phần mềm được thực thi. Cách tiếp cận bao phủ phạm vi có thể áp dụng cho cả kiểm thử tính đa hình và hành vi phụ thuộc vào trạng thái. Cách tiếp cận này cũng có thể được mở rộng để hỗ trợ trong việc kiểm thử các ứng dụng đa luồng. Bằng cách sử dụng thêm các độ đo bao phủ phạm vi hướng đối tượng kết hợp với các độ đo bao phủ phạm vi truyền thống, chúng ta có thể đảm bảo rằng cấu trúc của mã đã được thực hiện đầy đủ và do đó có thể tin tưởng vào chất lượng
3 a > 1 AND b = 0 a == 2 OR x>1 x←x/a x ←x+1 false true true false 1 2 5 4 6 7
được xác định đó là:
Các độ đo bao phủ phạm vi kế thừa (Inheritance context coverage metrics):
được thiết kế để giúp đo các cuộc gọi đa hình trong hệ thống đã được kiểm thử làm thế nào cho tốt.
Các độ đo bao phủ phạm vi dựa trên trạng thái (State-based context coverage metrics) được thiết kế để cải thiện việc kiểm thử các lớp với hành vi phụ thuộc trạng thái.
Các độ đo bao phủ phạm vi được người dùng xác định (User-defined context coverage metrics) cũng được hỗ trợ, cho phép áp dụng cách tiếp cận bao phủ phạm vi với các trường hợp khác, mà ở đó các độ đo bao phủ cấu trúc truyền thống không đầy đủ, chẳng hạn như các ứng dụng đa luồng.
3.3.2. Bao phủ phạm vi kế thừa
3.3.2.1. Định nghĩa bao phủ phạm vi kế thừa
Bao phủ phạm vi kế thừa không phải là một độ đo duy nhất, mà là một sự mở rộng của các độ đo bao phủ cấu trúc truyền thống khi để ý tới sự thêm vào các tương tác xảy ra với các phương thức được kế thừa.
Bao phủ phạm vi kế thừa cung cấp lựa chọn định nghĩa về độ đo mà cho rằng các mức của bao phủ đạt được trong phạm vi của mỗi lớp như là các độ đo riêng biệt. Các định nghĩa phạm vi kế thừa về bối cảnh coi thực hiện của chương trình trong phạm vi của lớp cơ sở là tách biệt với các thực hiện của chương trình trong phạm vi của lớp kế thừa. Tương tự như vậy, chúng ta xem việc thực hiện của chương trình trong phạm vi của một lớp kế thừa là khác với thực hiện trong phạm vi của một lớp kế thừa khác.
Để đạt được 100% bao phủ phạm vi kế thừa, mã lệnh phải được thực hiện đầy đủ trong từng phạm vi thích hợp.
Bao phủ phạm vi kế thừa là biến thể của bao phủ quyết định cho một chương trình trong một phạm vi đặc biệt đơn giản là số các nhánh quyết định được thực hiện trong phạm vi chia cho tổng số nhánh quyết định trong một chương trình.
nghĩa là tỷ lệ trung bình của bao phủ quyết định phạm vi kế thừa trong mỗi phạm vi thích hợp. Với mỗi chương trình, xác định một lớp cơ sở các phạm vi thích hợp là phạm vi mà tương ứng với mỗi lớp cơ sở song song với các tương ứng mỗi lớp kế thừa mà chương trình không thay đổi. Lưu ý rằng, chương trình không cần phải kiểm thử trong phạm vi của các lớp kế thừa.
3.3.2.2. Bao phủ kế thừa là dễ dàng đạt được
Trong kiểm thử đơn vị, sự cố gắng đạt được bao phủ phạm vi kế thừa là không hơn đáng kể so với những yêu cầu phải đạt được sự bao phủ theo độ đo truyền thống. Điển hình là không cần thêm các ca kiểm thử mới đối với các ca kiểm thử đã được sử dụng cho lớp cơ sở để kiểm thử lại các phương thức kế thừa trong các lớp kế thừa. Ngay với dạng hệ thống có kế thừa song song thì cho phép sử dụng lại các ca kiểm thử cho lớp cơ sở trở để kiểm thử các lớp kế thừa.
Việc sử dụng lại các ca kiểm thử lớp cơ sở còn cho thêm thuận lợi để tiến hành kiểm thử tự động.
3.3.3. Kiểm thử phạm vi dựa trên trạng thái
Phần lớn các hệ thống hướng đối tượng có tồn tại một số các lớp mà có thể được mô tả như là “máy trạng thái”. Các đối tượng của các lớp này có thể tồn tại như một số các trạng thái khác nhau, và hành vi của mỗi lớp có chất lượng khác nhau trong mỗi trạng thái có thể – Hành vi của lớp là các trạng thái phụ thuộc.
Kiểm thử phạm vi dựa vào trạng thái được thiết kế để làm thế nào đo được các hành vi này đã được kiểm thử đầy đủ. Xem xét một lớp cụ thể với trạng thái phụ thuộc hành vi như: Một ngăn xếp bị chặn (hình 3.4) có thể có ba trạng thái: „rỗng‟, „không đầy‟ hoặc „đầy‟. Hành vi của trạng thái có chất lượng khác nhau trong mỗi trạng thái. Ví dụ, pop() thực hiện thao tác di chuyển và trở về phần tử đầu đến ngăn xếp trong trạng thái „không đầy‟ hoặc „đầy‟. Giao diện lớp cho lớp ngăn xếp bị chặn được chỉ ra dưới đây:
Class BoundedStack { Public:
Void push ( int ); Int Pop ( );
Struct underflow: std::exception { }; Struct overflow: std::exception { }; };
Chúng ta có thể sử dụng bao phủ điểm để chắc chắn rằng các ca kiểm thử thực hiện trong mỗi phương thức của lớp. Các ca kiểm thử đạt được 100% bao phủ điểm.
Hình 3.4: Lược đồ chuyển trạng thái cho “ngăn xếp bị chặn”
3.3.3.1. Sử dụng các độ đo bao phủ hộp trắng
Nếu bao phủ điểm vào (entry-point) không đảm bảo kiểm thử kỹ lưỡng, có thể chúng ta nên sử dụng một yêu cầu bao phủ mạnh hơn, là 100% bao phủ quyết định. Thật không may là có các bất lợi khi thông qua các yêu cầu như vậy. Một nhân tố mà có thể được quyết định trong mã mà không tương ứng với các tính năng của giao diện chung. Ví dụ điển hình bao gồm mã điều khiển lỗi
phủ quyết định có thể là khó đạt được.
Một vấn đề quan trọng hơn là sự bất lực của các độ đo bao phủ cấu trúc truyền thống để xác định bao phủ mã khi chúng hoàn toàn vắng mặt. Ví dụ, hãy xem xét những gì sẽ xảy ra nếu ngăn xếp bị chặn quên kiểm tra điều kiện ngăn xếp rỗng trong pop (). Yêu cầu bao phủ quyết định 100% sẽ không giúp tìm lỗi này – các điều kiện thiếu là không có để được bao phủ.
3.3.3.2. Những cách có thể làm tốt hơn
Trên thực tế, chúng ta có thể viết một tập các ca tekiểm thử tốt hơn so với bất kỳ độ đo bao phủ cấu trúc truyền thống nào và không có bất kỳ kiến thức của các chi tiết bên trong lớp. Sơ đồ chuyển trạng thái UML chỉ ra rằng hành vi của lớp thay đổi phụ thuộc vào trạng thái hiện thời. Loại lược đồ này thông thường sử dụng để mô tả trạng thái phụ thuộc hành vi của các lớp
Chúng ta có thể sử dụng thêm thông tin bổ sung của sơ đồ chuyển trạng thái (hình 3.4) để thiết kế một tập các kiểm thử được thực hiện cho các lớp ngăn xếp bị chặn hoàn toàn .
3.3.3.3. Bao phủ nội dung dựa vào trạng thái
Bao phủ phạm vi dựa vào trạng thái là tương tự với bao phủ phạm vi kế thừa: nó cung cấp các định nghĩa khác nhau của các độ đo bao phủ cấu trúc truyền thống. Với bao phủ phạm vi kế thừa các phạm vi phụ thuộc cấu trúc kế thừa của phần mềm được kiểm thử. Tương tự, với bao phủ phạm vi dựa vào trạng thái, phạm vi tương ứng với các trạng thái tiềm năng của đối tượng của lớp kiểm thử. Do đó, các độ đo bao phủ phạm vi dựa vào trạng thái thực hiện một chương trình trong phạm vi của một trạng thái như cách thực hiện của chương trình tương tự trong trạng thái khác
Bao phủ phạm vi dựa vào trạng thái là biến thể của bao phủ điểm cho một lớp (tại phạm vi tương ứng với một trạng thái cụ thể) được cho bởi số lượng các phương thức được gọi vào các đối tượng trong trạng thái chia cho tổng số các phương thức trong lớp.
bình của bao phủ điểm phạm vi dựa vào trạng thái trong mỗi trạng thái phù hợp với lớp.
3.4. Các công cụ phân tích kiểm thử bao phủ
Hiện nay có mộ số công cụ kiểm thử trợ giúp việc kiểm thủ bao phủ. Trong số đó có thể kể đến:
- GCOV: Là một chương trình kiểm thử bao phủ được thiết kế để làm việc riêng với GCC để phân tích chương trình, giúp khởi tạo hiệu quả, giúp mã chạy nhanh hơn. Nó có thể được sử dụng phối hợp với GPROF- một ứng dụng để đánh giá phần của mã, để thời gian tính toán mang số lượng lớn nhất.
- EclEmma: tạo ra các báo cáo và cung cấp phạm vi bao phủ mã để theo dõi thông tin về các ca kiểm thử. Chúng ta sử dụng EclEmma chủ yếu như một công cụ báo cáo mức độ bao phủ. Đối với chương trình nhỏ, bao phủ dễ dàng tính toán bằng tay. Tuy nhiên, đối với các chương trình lớn hơn, công việc gặp nhiều khó khăn hơn cần sự trợ giúp của công cụ. Các công cụ bao phủ, như EclEmma, giúp tự động hoá quá trình đo bao phủ và cung cấp các báo cáo có thể đọc được. EclEmma là công cụ mã nguồn mở, hơn nữa EclEmma có thể được cập nhật tại trang http://update.eclemma.org.
- Cobertura: là một công cụ mã nguồn mở để đo mức độ bao phủ phần mềm dựa vào mã và theo dõi các dòng mã được hay không được thực thi bởi một bộ các kiểm thử. Ngoài việc xác định mã lỗi chưa được kiểm tra và định vị chúng, Cobertura có thể tối ưu hóa mã, mặc dù mã không được đưa ra, nhưng có thể cung cấp cái nhìn sâu xắc như một API hoạt động như thế nào trong thực tế (Download Cobertura từ http://cobertura.sourceforge.net/.)
CHƢƠNG 4: MÁY TRẠNG THÁI VÀ THỬ NGHIỆM KIỂM THỬ BAO PHỦ MÁY TRẠNG THÁI
4.1. Máy trạng thái hữu hạn
Trong các phương pháp phát triển phần mềm, máy tráng thái hữu hạn là một phương pháp được dùng để đặc tả phần mềm dành cho lớp các bài toán mà các đối tượng cấu thành hệ thống có các trạng thái khác nhau trong quá trình vận hành, như cầu thang máy, lò vi sóng, máy giặt,… Do đặc trưng của bài toán này, mà hệ thống phần mềm phát triển cho nó được lập trình theo hướng đối tượng. Kiểm thử những chương trình loại này có thể áp dụng kiểm thử bao phủ hướng đối tượng. Tuy nhiên, cũng do đặc thù của phương pháp máy trạng thái hữu hạn, tiêu chí kiểm thử phủ có thể là toàn bộ các trạng thái của hệ thống, các chuyển dịch, các sự kiện và các hành động. Do đó có thể sử dụng phương pháp kiểm thử tự động để vét cạn các trạng thái cần kiểm thử.
4.1.1. Khái niệm về máy trạng thái hữu hạn
Để hiểu về máy trạng thái, ta xét một ví dụ do đội M202 của một đại học mở của Anh [Brad77]. đưa ra và được Kampen [Kampen, 1987] mở rộng: Một bộ khóa an toàn có một khóa tổ hợp với ba vị trí 1, 2 và 3. Kim điều khiển ở mỗi ví trí có thể quay sang phải (R) hay sang trái (L). Ở tại một thời điểm bất kỳ, sự di chuyển của kim điểu khiển có thể có sáu khả năng: 1R, 1L, 2R, 2L, 3R, 3L. Một tổ hợp các chuyển dịch cho sự an toàn là: 1L, 2R, 3L. Bất kỳ một tổ hợp chuyển dịch nào khác đều gây ra báo động và kết thúc tiến trình. Tình huống trên đây được mô tả ở hình 4.1, trong đó có một trạng thái bắt đầu (1), và hai trạng thái cuối cùng là (4) và (5). 1.bộ an toàn bị khóa 2.trạng thái A 3 trạng thái B 4.bộ an toàn không khóa 5.báo động trạng thái bắt đầu trạng thái cuối cùng
Hình 4.1 Máy trạng thái hữu hạn biểu diễn bộ khóa an toàn tổ hợp
2R 3L
1R 2L
1L
chuyển dịch điều khiển khác đều dẫn đến trạng thái báo động. Khi một tổ hợp đúng (1L, 2R, 3L) được chọn thì một dãy các chuyển trạng thái từ (1) đến (2), đến (3) và đến (4) được thực hiện.
Hình 4.1 là một biểu đồ chuyển trạng thái (state transition diagram – STD) của một máy trạng thái hữu hạn (finite state machine – FSM). Không nhất thiết phải vẽ ra biểu đồ chuyển trạng thái, thay vào đó ta có thể đặc tả cho bài toán đặt ra bằng cách lập một bảng chuyển trạng thái cho ở hình 4.2
Hình 4.2: Bảng chuyển trạng thái đối với một máy trạng thái hữu hạn trạng thái hiện
thời bộ an toàn bị khóa trạng thái A trạng thái B
di chuyển Các trạng thái tiếp theo
1L trạng thái A báo động báo động
1R báo động báo động báo động
2L báo động báo động báo động
2R báo động trạng thái B báo động
3L báo động báo động bộ an toàn không
khóa
3R báo động báo động báo động
4.1.2. Mô hình máy trạng thái
Một máy trạng thái được đặc tả với năm thành phần: một tập các trạng thái (states) J, một tập các cái vào (inputs) K và hàm chuyển dịch T (transition function) xác định trạng thái tiếp theo khi đã cho trạng thái hiện thời và cái vào, một tập các trạng thái bắt đầu (initial) S, một tập các trạng thái cuối cùng (final states) F. Phát biểu một cách hình thức hơn: một máy trạng thái được xác định bởi một bộ (J,K,T,S,F), trong đó:
J- là tập hữu hạn, khác trống các trạng thái {(1),(2), (3), (4), (5)}
K- là tập hữu hạn, khác trống các cái vào (1R, 1L, 2R, 2L, 3R, 3L)
F J là tập các trạng thái cuối cùng (báo động, bộ an toàn không khóa) Cách tiếp cận máy trạng thái được sử dụng rất rộng rãi trong lĩnh vực ứng dụng công nghệ thông tin: Mỗi giao diện người dùng điều khiển bằng thực đơn là sự triển khai một máy trạng thái hữu hạn. Hiện một thực đơn là tương ứng với
một trạng thái, và đưa vào một thông tin từ bàn phím hay lựa chọn một biểu tượng bằng chuột là một sự kiện gây ra việc chuyển sang trạng thái khác. Trong trường hợp này mỗi sự chuyển trạng thái đều có dạng:
(Trạng thái hiện thời) [thực đơn] và (sự kiện) [tuỳ chọn được chọn]
trạng thái sau
Để đặc tả một sản phẩm phần mềm, người ta mở rộng FSM bằng cách thêm vào một thành phần thứ sáu gọi là tập tiền định P, mà trong đó mỗi phần tử của nó là một hàm của trạng thái tổng thể Y của sản phẩm (Kampen, 1987[10]). Khi đó, hàm chuyển đổi T là hàm từ (J~F)x KxP vào J. Quy tắc chuyển trạng