1. Trang chủ
  2. » Công Nghệ Thông Tin

Phân tích khả năng kiểm thử chương trình hướng đối tượng Java

5 27 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 5
Dung lượng 676,12 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Bài viết tập trung nghiên cứu và phân tích các độ đo KNKT hướng đối tượng đề xuất việc áp dụng các độ đo phân tích khả năng kiểm thử chương trình hướng đối tượng Java.

Trang 1

ISSN 1859-1531 - TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG, SỐ 12(97).2015, QUYỂN 2 25

PHÂN TÍCH KHẢ NĂNG KIỂM THỬ CHƯƠNG TRÌNH

HƯỚNG ĐỐI TƯỢNG JAVA

TESTABILITY ANALYSIS OF JAVA OBJECT - ORIENTED PROGRAMS

Nguyễn Thị Thúy Hoài 1 , Nguyễn Thanh Bình 2

1 Trường Cao đẳng Công nghệ, Đại học Đà Nẵng; thuy.hoai@yahoo.com

2Trường Đại học Bách khoa, Đại học Đà Nẵng; ntbinh@dut.udn.vn

Tóm tắt - Kiểm thử phần mềm là hoạt động nhằm đảm bảo chất

lượng phần mềm Tuy nhiên, đối với những phần mềm lớn và

phức tạp, các hoạt động kiểm thử đòi hỏi nhiều thời gian và công

sức Vì vậy, việc sớm có thông tin về chương trình rất cần thiết

cho quá trình kiểm thử nhằm nâng cao chất lượng sản phẩm

phần mềm Việc phân tích khả năng kiểm thử (PTKNKT) phần

mềm giúp đánh giá sớm chi phí kiểm thử, nghĩa là thông tin phần

mềm dễ dàng hay khó khăn khi kiểm thử Khi phương pháp phát

triển hướng đối tượng ra đời thì các phương pháp phân tích

truyền thống không còn phù hợp do những đặc thù riêng của

phương pháp này Trong bài báo này, chúng tôi tập trung nghiên

cứu và phân tích các độ đo KNKT hướng đối tượng Từ đó,

chúng tôi đề xuất việc áp dụng các độ đo PTKNKT chương trình

hướng đối tượng Java Các độ đo được tích hợp vào công cụ

Eclipse, được tính một cách tự động, thử nghiệm cho một số

chương trình thực tế và mang lại thông tin hữu ích

Abstract - Testing software is one of the activities which plays an

important role in the process of software development and is used

to measure the quality of software However, with large and complex software, testing requires a lot of time and effort Therefore, getting information from early software testing is necessary to improve the quality of software Testability analysis can help the programmers measure the cost of testing earlier and getting more testing information whether it will be easy or complex when testing Currently, after the method of object-oriented programming was introduced, the old ones are no longer appropriate due to their own characteristics of In this article, we focus on studying the testability analysis that is based on metrics and we propose the application of the metrics into analyzing testability of Java object-oriented programs The measures are integrated into Eclipse tool and automatically calculated These metrics are applied to some Java applications and the results may help designers get useful information

Từ khóa - chất lượng phần mềm; phân tích khả năng kiểm thử;

độ đo; phần mềm hướng đối tượng; chương trình hướng đối

tượng Java

Key words - quality of software; testability; metrics;

object-oriented software, Java object-object-oriented program s

1 Đặt vấn đề

Kiểm thử phần mềm là một hoạt động rất quan

trọng trong tiến trình phát triển phần mềm nhằm mục

đích giải đáp thắc mắc liệu chương trình có lỗi hay

không?

Với những phần mềm lớn và phức tạp thì việc thực

hiện các thủ tục kiểm thử đòi hỏi nhiều thời gian và công

sức Việc sớm có thông tin về hệ thống chương trình,

nghĩa là thông tin phần mềm dễ dàng hay phức tạp khi

kiểm thử, là công việc đặt lên hàng đầu nhằm giảm những

rủi ro và đánh giá sớm chi phí khi thực hiện kiểm thử

Những thông tin này có được nhờ hoạt động PTKNKT

phần mềm PTKNKT phần mềm là hoạt động đánh giá

những khó khăn khi thực hiện kiểm thử, tập trung tìm xác

suất phát hiện lỗi trong chương trình

Trước đây, nhiều độ đo như McCabe, Halstead [2]…

đã được sử dụng để đánh giá độ phức tạp và khả năng

kiểm thử (KNKT) đối với các hàm hoặc thủ tục theo

phương pháp phát triển hướng chức năng Tuy nhiên, khi

phương pháp phát triển hướng đối tượng (HĐT) ra đời thì

các phép đo đó không còn phù hợp do tính đặc thù riêng

của phương pháp này Vì vậy, thực tiễn đòi hỏi phải có

phép đo mới phù hợp hơn để có thể đánh giá khả năng

kiểm thử phần mềm phát triển HĐT một cách chính xác

hơn Việc ra đời của các độ đo sử dụng cho các chương

trình phát triển HĐT dựa vào mã nguồn, số lượng các lớp,

các phương thức, các lớp con và mối quan hệ giữa các lớp

giúp công việc đánh giá KNKT phần mềm hướng đối

tượng chính xác và hiệu quả hơn

2 Phân tích KNKT phần mềm

2.1 Khái niệm

PTKNKT phần mềm là hoạt động đánh giá những khó khăn khi thực hiện kiểm thử, tập trung tìm xác suất phát hiện lỗi trong chương trình KNKT phần mềm là khả năng phần mềm có thể dễ dàng hay phức tạp khi thực hiện kiểm thử không Hoạt động này nhằm đánh giá chất lượng bên trong của phần mềm và giúp người thiết kế cải tiến chất lượng mã nguồn hay kiểm thử viên lập kế hoạch và phân bố nguồn tài nguyên kiểm thử một cách hợp lý Kết quả của hoạt động PTKNKT cho biết phần mềm có dễ dàng hay phức tạp khi kiểm thử

2.2 Các phương pháp PTKNKT phần mềm

Để giảm bớt thời gian và chi phí cho giai đoạn kiểm thử, công việc PTKNKT được thực hiện nhằm trả lời câu hỏi kiểm thử viên có nên thực hiện kiểm thử phần mềm hay yêu cầu cải tiến chất lượng phần mềm Do

đó, hoạt động này cần phải có phương pháp đánh giá phần mềm chính xác và hiệu quả Trong phần này, chúng tôi trình bày một số phương pháp đánh giá KNKT phần mềm

2.2.1 Phương pháp PTKNKT miền

Chương trình có KNKT theo miền [3] sẽ không tồn tại tính không nhất quán đầu vào-ra, hay nói cách khác là có khả năng kiểm thử dễ dàng KNKT miền liên quan đến khả năng quan sát và khả năng điều khiển Một thủ tục có KNKT miền nếu nó có khả năng quan sát và khả năng điều khiển Các chương trình không có KNKT sẽ gây khó

Trang 2

26 Nguyễn Thị Thúy Hoài, Nguyễn Thanh Bình

khăn cho quá trình kiểm thử KNKT miền được định

nghĩa là khả năng dễ dàng chỉnh sửa chương trình để nó

tăng khả năng quan sát và điều khiển

2.2.2 Phương pháp PTKNKT dựa trên độ nhạy

Để đo KNKT, một khái niệm mới là độ nhạy được định

nghĩa [4]: độ nhạy tại một vị trí S là dự đoán xác suất lỗi tại

vị trí S sẽ gây ra sự cố cho phần mềm với miền đầu vào chỉ

định Phương pháp phân tích độ nhạy hay còn gọi là phương

pháp phân tích PIE gồm phân tích sự thực thi, phân tích các

ảnh hưởng và phân tích sự lan truyền PIE có tính chất động

do nó yêu cầu sự thực thi của mã nguồn Các dữ liệu đầu vào

được lựa chọn ngẫu nhiên từ miền dữ liệu vào Trạng thái

tính toán của mã nguồn đối với các dữ liệu vào này được so

sánh ngược với trạng thái của mã nguồn tương tự

3 Phân tích KNKT phần mềm HĐT

Có rất nhiều phương pháp PTKNKT phần mềm phát

triển theo phương pháp HĐT Mỗi phương pháp đều có

ưu và nhược điểm riêng Mục này trình bày tổng quan về

các phương pháp phân tích KNKT phần mềm HĐT

3.1 Các phương pháp PTKNKT sử dụng độ đo và mã nguồn

Tính thừa kế và che dấu dữ liệu là hai đặc điểm chính

đem đến cơ chế thiết kế mạnh mẽ cho phương pháp phát

triển phần mềm HĐT Vì vậy, phương pháp PTKNKT sử

dụng độ đo và mã nguồn ra đời dựa trên các đặc điểm của

phương pháp phát triển phần mềm HĐT

3.1.1 Phương pháp sử dụng độ đo dựa trên các đặc tính

phần mềm HĐT

Kết quả mỗi độ đo có thể đánh giá KNKT cũng như

dễ dàng nhận ra những lỗi còn tồn tại trong giai đoạn thiết

kế và lập trình trước đó Từ các đặc thù riêng của phương

pháp phát triển phần mềm HĐT, sáu độ đo được đề xuất

để đánh giá KNKT của phần mềm HĐT [8]:

+ Độ đo 1: tính độ rộng của các phương thức trong lớp;

+ Độ đo 2: tính độ sâu của cây thừa kế;

+ Độ đo 3: tính số lớp con;

+ Độ đo 4: tính số lượng liên kết giữa các lớp đối tượng;

+ Độ đo 5: tính số lần phản hồi của lớp;

+ Độ đo 6: tính sự liên kết yếu giữa các phương thức

3.1.2 Phương pháp down- calling

Down-calling [6] là kỹ thuật dùng để đảm bảo tính

nhất quán giữa các lớp Hầu hết các ngôn ngữ lập trình

chỉ quan tâm đến cú pháp của phương thức, không quan

tâm đến ngữ nghĩa và không cung cấp phương pháp đánh

giá chúng một cách thống nhất Down-calling cũng là cơ

chế dùng để bảo đảm mặt cú pháp và ngữ nghĩa đều nhất

quán giữa các phương thức không đa hình và phương thức

đa hình trong tất cả các lớp dẫn xuất và được dùng khi các

thể hiện của lớp dẫn xuất thay thế cho thể hiện của lớp cơ

sở Do đó, các dẫn xuất của lớp đó sẽ thừa kế các phương

thức không đa hình và các thực thi

4 Các độ đo sử dụng phân tích KNKT chương trình

HĐT Java

Ngôn ngữ lập trình Java đã nhanh chóng trở thành một

ngôn ngữ lập trình của các lập trình viên chuyên nghiệp

Java được xây dựng dựa trên nền tảng của C và C++ và là ngôn ngữ vừa biên dịch vừa thông dịch Mục tiêu của các nhà thiết kế Java là cho phép người lập trình viết chương trình một lần nhưng có thể chạy trên các nền phần cứng khác nhau Ngôn ngữ Java có 3 đặc điểm quan trọng là tính đóng gói, tính thừa kế và tính đa hình

Từ các phương pháp PTKNKT phần mềm HĐT và các đặc điểm của ngôn ngữ Java, chúng tôi đề xuất áp dụng một số độ đo PTKNKT phần mềm phát triển theo phương pháp HĐT Java trong Bảng 1 [7] [8]

Bảng 1 Các độ đo sử dụng đánh giá KNKT phần mềm HĐT

Coupling Factor (CF) Độ đo sự phụ thuộc Lack of Cohension of Methods Độ đo sự gắn kết yếu của các phương thức Cyclomatic Complexity Độ phức tạp vòng Attribute Hiding Factor (AHF) Độ đo thuộc tính ẩn Method Hiding Factor (MHF) Độ đo phương thức ẩn Depth of Inheritance Tree (DIT) Độ sâu của cây thừa kế Number of Children (NOC) Số lượng lớp con Weighted Methods Per Class

(WMC) Độ phức tạp của các phương thức trong các lớp Method Inheritance Factor (MIF) Độ đo phương thức thừa kế Attribute Inheritance Factor (AIF) Độ đo thuộc tính thừa kế Nested Block Depth (NBT) Độ đo tính độ sâu các khối mã nguồn lồng nhau Number of Classes Số lượng lớp con

Lines of Code Số dòng lệnh

4.1 Độ đo khả năng liên kết yếu các phương thức

Độ đo LCOM được tính bằng cách đếm số cặp phương thức cùng gọi đến các biến thành phần giống nhau trong lớp trừ đi số cặp phương thức không gọi đến một biến thành phần nào giống với các phương thức còn lại

4.2 Các độ đo liên quan đến tính đóng gói

4.2.1 Độ đo khả năng che dấu thuộc tính

 

1 1

TC

TC

A C AHF

A C

 Trong đó:

TCtổng các lớp;

A CA CA C  các thuộc tính được định nghĩa trong Ci;

 

v i

A C  các thuộc tính thấy được trong lớp Ci;

 

h i

A C  các thuộc tính ẩn trong lớp Ci;

4.2.2 Độ đo khả năng che dấu phương thức

 

1 1

TC

TC

MHF

 Trong đó:

TCtổng các lớp;

Trang 3

ISSN 1859-1531 - TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG, SỐ 12(97).2015, QUYỂN 2 27

định nghĩa trong C ; i

 

v i

M C các phương thức thấy được trong lớp C ; i

 

h i

M C các phương thức ẩn trong lớp C i

4.3 Các độ đo liên quan đến tính thừa kế

4.3.1 Độ sâu của cây thừa kế

Công thức như sau:

DIT cAncestors c

Trong đó, Ancestors c là tập các lớp mà lớp c được  

thừa kế trực tiếp hoặc gián tiếp

4.3.2 Số lượng các lớp con

Công thức như sau:

   

NOC cChildren c

Trong đó, Children c là tập các lớp được thừa kế  

trực tiếp từ lớp c

4.3.3 Độ đo khả năng thừa kế thuộc tính (AIF)

 

1 1

TC

TC

A C AIF

A C

 Trong đó:

TC tổng các lớp;

A CA CA C  các thuộc tính thấy được

trong C ; i

A CA CA C các thuộc tính trong C ; i

 

n i

A C các thuộc tính mới trong lớp C ; i

 

o i

A C các thuộc tính overriding trong lớp C ; i

 

i i

A C các thuộc tính được thừa kế trong lớp C i

4.3.4 Độ đo khả năng thừa kế phương thức (MIF)

 

1 1

TC

TC

M C MIF

 Trong đó:

TC tổng các lớp;

i

C ;

trong C ; i

 

n i

M C các phương thức mới trong lớp C ; i

 

o i

M C các phương thức overiding trong lớp C ; i

 

i i

M C các phương thức được thừa kế trong lớp C i

4.4 Công thức tính độ phức tạp các phương thức trong lớp

Công thức như sau:

  Im

m M c

Trong đó:

 

Im c

M là số lượng các phương thức được thực thi

trong lớp c

 

VG m được tính bằng độ đo phức tạp vòng cho mỗi

phương thức m Công thức của độ đo độ phức tạp vòng:

M  E N  với M là kết quả độ đo McCabe, E là số P

các cạnh trong đồ thị của chương trình, N là số các nút của đồ thị và P là số các đường được kết nối Ngoài ra, McCabe có thể tính bằng công thức 1MD với D là các nút quyết định trong đồ thị

Bảng 2 Số liệu so sánh giữa McCabe và độ phức tạp mã nguồn

Độ phức tạp

1-10 Chương trình đơn giản, không chứa nhiều rủi ro 11-20 Chương trình phức tạp hơn, tính rủi ro trung bình 21-50 Chương trình phức tạp, tính rủi ro cao

>50 Không có khả năng kiểm thử, tính rủi ro rất cao

4.5 Độ đo tính sự phụ thuộc giữa các đối tượng

 

2

1

2

TC TC

TC

is client C C COF

Trong đó:

TCtổng các lớp;

2

TC TC

thống của lớp T và C;

  1

iDC C i

  số cặp phụ thuộc lớn nhất do thừa kế

is client C C

Bảng 3 Ý nghĩa của các độ đo

Độ đo sự phụ thuộc Giá trị càng lớn, độ phức tạp cànglớn và rất khó bảo trì phần mềm

Độ đo sự liên kết yếu của các phương thức Sự gắn kết thấp sẽ làm tăng độphức tạp

Độ phức tạp vòng Giá trị càng nhỏ thì phần mềmcàng ít rủi hơn

Độ đo thuộc tính ẩn Giá trị này thể hiện tính đóng góicho thuộc tính hợp lý chưa?

Độ đo phương thức ẩn Giá trị này thể hiện tính đóng góicho phương thức hợp lý chưa?

Độ sâu của cây thừa kế Lớp càng nằm ở sâu trong cây thừakế thì càng tăng độ phức tạp

Số lượng lớp con Giá trị càng lớn sẽ càng tăng khảnăng thừa kế

Độ phức tạp của cácphương thức trong các lớp Giá trị càng lớn sẽ càng giảm khảnăng thừa kế

Độ đo phương thức thừa

kế

Giá trị này thể hiện tính thừa kế cho phương thức hợp lý chưa?

Độ đo thuộc tính thừa kế Giá trị này thể hiện tính thừa kếcho thuộc tính hợp lý chưa?

Độ đo tính độ sâu các khối mã nguồn lồng nhau Giá trị càng lớn sẽ rất khó để đọchiểu mã nguồn

1: nếu và chỉ nếu tồn tại mối quan hệ giữa lớp khách với lớp chủ và lớp khách phải khác với lớp chủ

0: trong trường hợp còn lại

Trang 4

28 Nguyễn Thị Thúy Hoài, Nguyễn Thanh Bình

Bảng 4 So sánh giá trị độ đo với độ phức tạp phần mềm

Độ đo sự phụ thuộc giữa các đối tượng Tăng Tăng

Độ đo sự liên kết yếu của các phương thức Giảm Tăng

Độ sâu của cây thừa kế Tăng Tăng

Độ phức tạp vòng Tăng Tăng

Bảng 5 So sánh giá trị độ đo với KNKT phần mềm

Độ đo sự phụ thuộc giữa các đối tượng Tăng Giảm

Độ đo sự gắn kết yếu của các phương thức Tăng Giảm

Số lượng lớp con Tăng Giảm

Độ phức tạp của các phương thức trong các lớp Tăng Giảm

Độ đo khả năng thừa kế của phương thức Tăng Tăng

Độ đo khả năng thừa kế của thuộc tính Tăng Tăng

5 Ứng dụng PTKNKT các phần mềm HĐT Java với

công cụ tính độ đo

Để có thể tính các độ đo như đã trình bày ở Mục 4,

chúng tôi đề xuất sử dụng phần mềm Metrics Phần mềm

này đã được tích hợp các độ đo để PTKNKT và nó sẽ là

công cụ hữu ích cho các kiểm thử viên khi đánh giá

KNKT các phần mềm phát triển theo phương pháp HĐT

5.1 Quy trình sử dụng độ đo

Trong quy trình phát triển phần mềm, các độ đo được

sử dụng ở giai đoạn sau khi viết code và trước khi thực

hiện kiểm thử Kết quả của các độ đo sẽ là cơ sở giúp

người lập trình đưa ra những đánh giá KNKT về phần

mềm cũng như cải thiện những phần mềm chưa đạt yêu

cầu Việc sử dụng các độ đo để đánh giá KNKT phần

mềm được thực hiện ba bước:

Bước 1: Thực hiện tính toán các độ đo và ghi lại kết quả

đo Dựa vào kết quả đo để thực hiện các lớp chưa đạt yêu cầu

Bước 2: Những lớp chưa đạt yêu cầu được thay đổi

trước khi tính toán lại các độ đo

Bước 3: So sánh độ đo trước và sau khi thực hiện công

việc cải thiện phần mềm để đánh giá tổng quan về KNKT

phần mềm

5.2 Quy trình tích hợp phần mềm Metrics vào công cụ

Eclipse

Eclipse là môi trường phát triển tích hợp cho Java, được

phát triển ban đầu bởi Java Kiểm thử viên có thể tích hợp

phần mềm Metrics vào công cụ soạn thảo Eclipse để tính

kết quả các độ đo mã nguồn Kết quả các độ đo giúp người

kiểm thử đánh giá KNKT phần mềm cao hay thấp

5.3 Thử nghiệm

Trong phần này, chúng tôi chọn mã nguồn JDK

1.7.0_80 là mã nguồn chuẩn của Java để thực hiện tính

các độ đo thông qua phần mềm Metrics Kết quả các độ

đo được tính từ mã nguồn JDK (Bảng 6) sẽ là giá trị

mong đợi (giá trị độ đo chuẩn) để đánh giá KNKT cho

các thử nghiệm: chương trình giao dịch ngân hàng ATM

và phần mềm bán hàng điện tử Đây là những phần mềm

phức tạp, các giao dịch tương tác giữa người dùng và ứng

dụng đòi hỏi độ chính xác cao

Bảng 6 Kết quả mong đợi của các độ đo khi sử dụng

phần mềm Metrics

Độ đo sự liên kết yếu của các phương thức 0,409

Độ sâu của cây thừa kế 2,786

Độ phức tạp của các phương thức trong các lớp 17,214

Độ đo tính độ sâu các khối mã nguồn lồng nhau 1,467

Độ đo tính các tham số của phương thức 1,322

5.3.1 Thử nghiệm 1: chương trình giao dịch ngân hàng ATM

Chương trình Giao dịch ngân hàng ATM có các tác vụ đăng ký khách hàng, đăng ký tài khoản, đăng nhập tài khoản, rút tiền, gửi tiền, chuyển tiền, xem thông tin tài khoản, xem thông tin giao dịch Chương trình này gồm 3 lớp với 532 dòng lệnh Sau khi sử dụng phần mềm Metrics, chúng tôi có được kết quả trong Bảng 7

Bảng 7 Kết quả các độ đo của chương trình máy ATM

Độ đo sự liên kết yếu của các phương thức 0,602

Độ sâu của cây thừa kế 1

Độ phức tạp của các phương thức trong các lớp 117

Độ đo tính độ sâu các khối mã nguồn lồng nhau 1,957

Độ đo tính các tham số của phương thức 0,804

Hầu hết các kết quả của các độ đo được tính toán bằng phần mềm tính độ đo đều nằm trong vùng cho phép Tuy nhiên, riêng kết quả độ đo độ phức tạp của các phương thức trong các lớp quá cao (dựa vào kết quả của các độ đo ở Bảng 7) Chúng tôi đánh giá phần mềm ATM cần cải thiện lại mã nguồn trước khi thực hiện giai đoạn kiểm thử tiếp theo

5.3.2 Thử nghiệm 2: phần mềm bán hàng thiết bị điện tử

Chương trình bán hàng các thiết bị điện tử gồm giao diện giới thiệu các sản phẩm, đặt hàng, tính tiền các đơn đặt hàng

Chương trình này gồm 8 lớp với tổng cộng 587 dòng lệnh

Bảng 8 Kết quả các độ đo phần mềm bán hàng các thiết bị điện tử

Độ đo sự liên kết yếu của các phương thức 0,404

Độ sâu của cây thừa kế 3,111

Độ phức tạp của các phương thức trong các lớp 11

Độ đo tính độ sâu các khối mã nguồn lồng nhau 1,343

Độ đo tính các tham số của phương thức 0,761

Dựa vào Bảng 8, đối với phần mềm này, chỉ có kết quả độ đo của độ sâu cây thừa kế có giá trị cao hơn phần mềm chuẩn Các kết quả của tất cả các độ đo còn lại đều được chấp nhận (nghĩa là nhỏ hơn độ đo chuẩn) Chúng tôi đánh giá phần mềm này có độ phức tạp thấp và khả năng kiểm thử cao Tuy nhiên, phần mềm này cần phải cải tiến mã nguồn ở cây thừa kế

6 Kết luận

Bài báo đã trình bày về hoạt động PTKNKT và một số phương pháp PTKNKT như phương pháp phân tích mật

Trang 5

ISSN 1859-1531 - TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ ĐẠI HỌC ĐÀ NẴNG, SỐ 12(97).2015, QUYỂN 2 29

độ động, phương pháp sử dụng các câu xác nhận, phương

pháp chọn dữ liệu đảm bảo tính nhất quán Những thông

tin có được từ hoạt động PTKNKT phần mềm thực sự rất

cần thiết cho hoạt động kiểm thử tiếp theo Từ các đặc

điểm của phương pháp phát triển HĐT (cụ thể là ngôn

ngữ lập trình Java), nhóm tác giả đề xuất ứng dụng các độ

đo để PTKNKT sớm trong giai đoạn thiết kế Độ đo

KNKT có thể giúp cho người kiểm thử xác định phần

mềm khó hay dễ khi kiểm thử, từ đó thiết kế cải tiến thiết

kế đạt KNKT cao hơn Các độ đo được tích hợp vào công

cụ Eclipse và tiến hành thử nghiệm thành công ứng dụng

các độ đo này để đánh giá KNKT một số ứng dụng Java

Giải pháp này có thể được triển khai cho các đơn vị

phát triển phần mềm hay dự án phần mềm

TÀI LIỆU THAM KHẢO

[1] Nguyễn Thanh Bình, “Phân tích khả năng kiểm thử đơn vị phần mềm”,

Tạp chí Khoa học và Công nghệ, Đại học Đà Nẵng, Số 14, 2006

[2] H Waton, Thomas J McCcabe, Structures Testing, A Testing Methodology Using the Cyclomatic Complexity Metrics, NIST Special Publication 500-235, 1996

[3] Roy S Freedman, Testability of Sofware Components, IEEE

Transactions on Software, Eng., Vol.17, No.6, 1991

[4] Jeffrey M Voas, Larry Morell, Keith Miller, Using Dynamic Sensitivity Analysis, National Research Council Resident Research Associateship, 1991

[5] Jeffrey M Voas, A Dynamic Failure-Based Technique,

Transactions on Software Engineering, vol 18, pp 717 -727, 1992

[6] J E Payne, R T Alexander and C D Hutchinson, Design for

Testability for Object-Oriented Software, Object Magazine, vol 7,

No 5, 1997, pp 34-43

[7] Magiel Bruntink, Predicting Class Teatability Using Object-Oriented Metrics, 4th IEEE International Workshop on Source Code Analysis and Manipulation (SCAM’04), 2004

[8] S R Chidamber, C.F Kemerer, A Metrics Suite for Object

Oriented Design, IEEE Transactions on Software English, vol 20,

No 6, 1994

(BBT nhận bài: 26/07/2015, phản biện xong: 27/08/2015)

Ngày đăng: 08/01/2021, 08:44

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w