Tối Ưu Hóa Hiệu Suất Kiểm Thử Phần Mềm Hướng Đối Tượng Qua Các Mẫu Thiết Kế

Luận án tiến sĩ nghiên cứu exploiting design patterns for improved efficiency in the testing of object oriented software, phân tích chuyên sâu, xây dựng mô hình lý thuyết, đề xuất

• Tác giả: Kenneth Michael Araujo
• Người hướng dẫn: John Bowles
• Trường học: University South Carolina
• Chuyên ngành: Computer Science and Engineering
• Đề tài: Tối Ưu Hóa Hiệu Suất Kiểm Thử Phần Mềm Hướng Đối Tượng Qua Các Mẫu Thiết Kế
• Loại tài liệu: thesis
• Năm xuất bản: 2006
• Địa điểm: Columbia

Tóm tắt

I. Tổng Quan Kiểm Thử Phần Mềm Hướng Đối Tượng Hiệu Quả

Quá trình kiểm thử phần mềm là một phần không thể thiếu trong quá trình phát triển. Nó đảm bảo chất lượng và độ tin cậy của sản phẩm. Tuy nhiên, kiểm thử phần mềm hướng đối tượng mang đến những thách thức riêng. Do tính chất phức tạp và sự kết hợp giữa các đối tượng, việc kiểm thử toàn diện trở nên khó khăn hơn. Bài viết này tập trung vào việc tối ưu hiệu suất kiểm thử trong môi trường hướng đối tượng. Chúng ta sẽ khám phá cách sử dụng các mẫu thiết kế để cải thiện độ bao phủ kiểm thử, giảm thời gian kiểm thử và chi phí kiểm thử, đồng thời nâng cao chất lượng phần mềm. Theo Kenneth Michael Araujo, “khi một phần mềm được thiết kế từ một tập hợp các mẫu thiết kế tiêu chuẩn, chúng ta nên kiểm thử phần mềm dựa trên thiết kế của nhà thiết kế đã nắm bắt được những thứ đó”.

1.1. Giới Thiệu Về Phương Pháp Kiểm Thử Phần Mềm OOP

Kiểm thử phần mềm hướng đối tượng (OOP) đòi hỏi cách tiếp cận khác so với kiểm thử phần mềm truyền thống. Các khái niệm như tính đóng gói, kế thừa và đa hình đặt ra những thách thức mới. Phương pháp kiểm thử cần tập trung vào việc kiểm tra tương tác giữa các đối tượng, trạng thái của đối tượng và luồng thông điệp giữa chúng. Việc sử dụng các kỹ thuật như Unit testing, Integration testing và System testing là cần thiết để đảm bảo chất lượng. Việc hiểu rõ các nguyên tắc SOLID principles cũng rất quan trọng trong quá trình kiểm thử.

1.2. Mẫu Thiết Kế Design Patterns Ảnh Hưởng Đến Hiệu Quả Kiểm Thử

Mẫu thiết kế (Design Patterns) là các giải pháp đã được chứng minh cho các vấn đề thiết kế phần mềm thường gặp. Việc sử dụng chúng có thể ảnh hưởng đáng kể đến hiệu quả kiểm thử. Một số mẫu thiết kế làm cho mã dễ kiểm thử hơn bằng cách giảm độ phức tạp của mã và tăng tính liên kết. Ví dụ, mẫu Dependency Injection giúp dễ dàng thay thế các phụ thuộc bằng các đối tượng giả trong quá trình Unit testing. Việc áp dụng mẫu thiết kế một cách hợp lý có thể giúp giảm thời gian kiểm thử và tăng độ bao phủ kiểm thử.

II. Thách Thức Tối Ưu Kiểm Thử OOP và Các Vấn Đề Phát Sinh

Kiểm thử phần mềm hướng đối tượng (OOP) mang lại nhiều lợi ích, nhưng cũng đi kèm với những thách thức đáng kể trong việc tối ưu hiệu suất kiểm thử. Độ phức tạp của mã, sự tương tác giữa các đối tượng, và số lượng lớn các trạng thái có thể làm cho quá trình kiểm thử trở nên tốn kém và mất thời gian. Việc đảm bảo độ bao phủ kiểm thử đầy đủ là một thách thức lớn. Ngoài ra, việc Refactoring mã có thể làm thay đổi cấu trúc và hành vi của phần mềm, đòi hỏi phải cập nhật các trường hợp kiểm thử. Việc phát triển phần mềm hướng đối tượng đòi hỏi sự hiểu biết sâu sắc về các nguyên tắc và kỹ thuật kiểm thử.

2.1. Độ Phức Tạp Của Mã Ảnh Hưởng Đến Quá Trình Kiểm Thử

Độ phức tạp của mã là một trong những yếu tố chính ảnh hưởng đến hiệu suất kiểm thử. Mã nguồn phức tạp hơn có xu hướng chứa nhiều lỗi hơn và khó kiểm thử hơn. Các lớp với độ kết dính thấp và tính liên kết cao thường khó kiểm thử hơn. Việc sử dụng các công cụ phân tích mã để đo lường độ phức tạp của mã có thể giúp xác định các khu vực cần được kiểm thử kỹ lưỡng hơn. Việc Refactoring mã để giảm độ phức tạp có thể cải thiện đáng kể hiệu quả kiểm thử.

2.2. Khó Khăn Trong Việc Đảm Bảo Độ Bao Phủ Kiểm Thử Toàn Diện

Đảm bảo độ bao phủ kiểm thử đầy đủ trong kiểm thử phần mềm hướng đối tượng là một thách thức lớn. Việc kiểm tra tất cả các đường dẫn thực thi, trạng thái đối tượng và tương tác giữa các đối tượng đòi hỏi một lượng lớn thời gian và nguồn lực. Các kỹ thuật như Kiểm thử hộp trắng (White box testing) và Kiểm thử hộp đen (Black box testing) có thể được sử dụng để cải thiện độ bao phủ kiểm thử. Tuy nhiên, việc xác định các trường hợp kiểm thử hiệu quả nhất vẫn là một vấn đề khó khăn. Việc sử dụng các công cụ kiểm thử tự động có thể giúp tăng độ bao phủ kiểm thử và giảm thời gian kiểm thử.

III. Giải Pháp Áp Dụng Mẫu Thiết Kế Để Tối Ưu Hiệu Suất Kiểm Thử

Một trong những cách hiệu quả nhất để tối ưu hiệu suất kiểm thử trong phát triển phần mềm hướng đối tượng là áp dụng mẫu thiết kế. Mẫu thiết kế cung cấp các giải pháp đã được chứng minh cho các vấn đề thiết kế thường gặp và có thể giúp làm cho mã dễ kiểm thử hơn. Ví dụ, mẫu Factory có thể giúp tạo ra các đối tượng kiểm thử một cách dễ dàng hơn, trong khi mẫu Observer có thể giúp kiểm tra các sự kiện và thông báo. Việc sử dụng các mẫu thiết kế một cách chiến lược có thể giảm độ phức tạp của mã, tăng tính liên kết và cải thiện độ bao phủ kiểm thử.

3.1. Sử Dụng Mẫu Dependency Injection Trong Unit Testing

Mẫu Dependency Injection là một kỹ thuật mạnh mẽ để tối ưu hóa Unit Testing. Nó cho phép bạn dễ dàng thay thế các phụ thuộc của một lớp bằng các đối tượng giả hoặc mocks trong quá trình kiểm thử. Điều này giúp cô lập lớp đang được kiểm thử và kiểm tra hành vi của nó một cách độc lập. Bằng cách sử dụng Dependency Injection, bạn có thể kiểm tra các trường hợp biên và lỗi một cách dễ dàng hơn và đảm bảo rằng lớp của bạn hoạt động chính xác trong mọi tình huống.

3.2. Mẫu Factory và Abstract Factory Trong Tạo Dữ Liệu Kiểm Thử

Mẫu Factory và Abstract Factory là những mẫu thiết kế hữu ích để tạo ra các đối tượng kiểm thử một cách linh hoạt và dễ bảo trì. Thay vì tạo trực tiếp các đối tượng trong các trường hợp kiểm thử, bạn có thể sử dụng các Factory để tạo ra chúng. Điều này giúp giảm sự trùng lặp mã và làm cho các trường hợp kiểm thử dễ đọc và dễ bảo trì hơn. Abstract Factory đặc biệt hữu ích khi bạn cần tạo ra các họ đối tượng liên quan.

3.3. Ứng dụng Strategy Pattern trong kiểm thử các thuật toán

Mẫu Strategy Pattern cho phép bạn xác định một họ các thuật toán, đóng gói từng thuật toán và làm cho chúng có thể thay thế cho nhau. Điều này đặc biệt hữu ích trong kiểm thử phần mềm, khi bạn muốn kiểm tra các thuật toán khác nhau với các bộ dữ liệu đầu vào khác nhau. Bạn có thể dễ dàng tạo ra các Strategy khác nhau, mỗi Strategy đại diện cho một thuật toán khác nhau, và sau đó kiểm tra chúng một cách độc lập. Điều này giúp cải thiện khả năng bảo trì và mở rộng của hệ thống kiểm thử.

IV. Phân Tích Hiệu Quả Kiểm Thử Tăng Cường Nhờ Mô Hình Kiểm Thử

Việc xây dựng một mô hình kiểm thử phù hợp đóng vai trò quan trọng trong việc nâng cao hiệu quả kiểm thử phần mềm. Mô hình kiểm thử giúp định hướng và quản lý quá trình kiểm thử một cách có hệ thống, từ việc xác định mục tiêu kiểm thử, lựa chọn kỹ thuật kiểm thử, đến việc theo dõi và đánh giá kết quả. Một mô hình kiểm thử tốt cần đảm bảo độ bao phủ kiểm thử đầy đủ, giảm thiểu rủi ro và tối ưu hóa thời gian kiểm thử và chi phí kiểm thử. Việc sử dụng các mô hình kiểm thử phù hợp có thể giúp giảm thiểu sai sót và đảm bảo chất lượng phần mềm.

4.1. Chọn Mô Hình Kiểm Thử Thích Hợp V Model Agile Testing...

Có nhiều mô hình kiểm thử khác nhau, mỗi mô hình phù hợp với các dự án và môi trường phát triển khác nhau. V-Model là một mô hình tuần tự, trong đó mỗi giai đoạn phát triển tương ứng với một giai đoạn kiểm thử. Agile Testing là một mô hình lặp đi lặp lại, trong đó kiểm thử được thực hiện liên tục trong suốt quá trình phát triển. Việc lựa chọn mô hình kiểm thử thích hợp phụ thuộc vào nhiều yếu tố, bao gồm quy mô dự án, độ phức tạp của phần mềm, và phương pháp phát triển được sử dụng.

4.2. Kiểm Thử Tự Động và Tích Hợp Liên Tục CI CD

Kiểm thử tự động là một phần quan trọng của CI/CD (Continuous Integration/Continuous Delivery). Nó cho phép bạn tự động hóa các trường hợp kiểm thử và chạy chúng mỗi khi có thay đổi mã. Điều này giúp phát hiện lỗi sớm và giảm thời gian kiểm thử. Việc tích hợp kiểm thử tự động vào quy trình CI/CD giúp đảm bảo rằng phần mềm luôn ở trạng thái có thể triển khai được.

V. Nghiên Cứu Mẫu Thiết Kế Ảnh Hưởng Đến Độ Bao Phủ Kiểm Thử Thực Tế

Nghiên cứu của Kenneth Michael Araujo cho thấy rằng việc sử dụng mẫu thiết kế có thể cải thiện độ bao phủ kiểm thử và hiệu quả kiểm thử. Nghiên cứu này đã sử dụng metric method coverage để đánh giá hiệu quả đạt được khi sử dụng mẫu thiết kế trong hai quy trình, các thí nghiệm thiết kế và sơ đồ khối. Quá trình này đã phát triển một sơ đồ hệ thống phần mềm mới, Pattern Block Diagram. Dưới các điều kiện được kiểm soát, sự hiện diện của mẫu thiết kế được tìm thấy cung cấp một mức độ method coverage tương đương với độ phức tạp thấp hơn đáng kể.

5.1. Phương Pháp Đánh Giá Hiệu Quả Kiểm Thử Bằng Method Coverage

Method Coverage là một metric được sử dụng để đo lường độ bao phủ kiểm thử. Nó cho biết tỷ lệ phần trăm các phương thức trong mã nguồn đã được thực thi trong quá trình kiểm thử. Method Coverage là một cách đơn giản để đánh giá hiệu quả kiểm thử, nhưng nó không thể thay thế cho các phương pháp kiểm thử khác. Điều quan trọng là phải kết hợp Method Coverage với các kỹ thuật kiểm thử khác để đảm bảo độ bao phủ kiểm thử đầy đủ.

5.2. Pattern Block Diagram Công Cụ Phân Tích Hiệu Suất Kiểm Thử

Pattern Block Diagram là một sơ đồ hệ thống phần mềm mới được phát triển trong nghiên cứu của Araujo. Sơ đồ này được sử dụng để phân tích hiệu suất kiểm thử và độ bao phủ kiểm thử trong các hệ thống sử dụng mẫu thiết kế. Pattern Block Diagram cho phép các nhà phát triển hiểu rõ hơn về cấu trúc và hành vi của phần mềm và xác định các khu vực cần được kiểm thử kỹ lưỡng hơn.

VI. Kết Luận Tiềm Năng Của Mẫu Thiết Kế Trong Kiểm Thử OOP

Việc sử dụng mẫu thiết kế có tiềm năng lớn trong việc tối ưu hóa hiệu suất kiểm thử trong kiểm thử phần mềm hướng đối tượng. Mẫu thiết kế giúp làm cho mã dễ kiểm thử hơn, giảm độ phức tạp của mã, tăng tính liên kết và cải thiện độ bao phủ kiểm thử. Tuy nhiên, việc áp dụng mẫu thiết kế cần được thực hiện một cách cẩn thận và có chọn lọc. Việc sử dụng quá nhiều mẫu thiết kế hoặc sử dụng chúng không đúng cách có thể làm cho mã trở nên phức tạp hơn và khó bảo trì hơn. Trong tương lai, cần có thêm nhiều nghiên cứu để khám phá tiềm năng của mẫu thiết kế trong kiểm thử phần mềm.

6.1. Hướng Nghiên Cứu Tương Lai Về Tối Ưu Kiểm Thử

Các hướng nghiên cứu tương lai về tối ưu hóa kiểm thử bao gồm việc phát triển các kỹ thuật mới để kiểm thử phần mềm hướng đối tượng phức tạp, nghiên cứu về tác động của các mẫu thiết kế khác nhau đến hiệu suất kiểm thử, và phát triển các công cụ tự động để hỗ trợ quá trình kiểm thử. Ngoài ra, việc nghiên cứu về các kỹ thuật Kiểm thử hiệu năng (Performance Testing), Kiểm thử tải (Load Testing), Kiểm thử bảo mật (Security Testing) cho các ứng dụng OOP cũng rất quan trọng.

6.2. Kiểm Thử Liên Tục và Vai Trò Của DevOps Trong Tương Lai

Kiểm thử liên tục sẽ trở thành một phần không thể thiếu của quy trình phát triển phần mềm trong tương lai. DevOps, với sự tập trung vào tự động hóa và cộng tác, sẽ đóng vai trò quan trọng trong việc thúc đẩy kiểm thử liên tục. Bằng cách tự động hóa các quy trình kiểm thử và tích hợp chúng vào quy trình phát triển, DevOps giúp đảm bảo rằng phần mềm luôn ở trạng thái có thể triển khai được và đáp ứng được các yêu cầu về chất lượng và hiệu suất.

Trích đoạn nội dung tài liệu

Exploiting Design Patterns for Improved Efficiency In the Testing of Object-Oriented Software by Kenneth Michael Araujo Bachelor of Science Francis Marion College, 1983 Master of Science University of South Carolina, 1986 Bachelor of Science in Engineering University of South Carolina, 1994 Certificate of Graduate Study in Applied Statistics University of South Carolina, 2003 Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in the Department of Computer Science and Engineering College of Engineering and Information Technology University of South Carolina 2006 - 6 6=, )M „J„ 0h, Hi M@or Professor Chairman, Examining Committee Karetl ⁄ “„.Z JIIRSSIIS/2177e: Committee Member Committee Member LZ (he Committee Member uke FeAmW Dean of The Graduate School UMI Number: 3245380 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion.

® UMI UMI Microform 3245380 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.

Box 1346 Ann Arbor, MI 48106-1346 Acknowledgements As my time at Carolina draws to a close, my primary expression of graditude is to my Lord and Saviour, Jesus Christ, who provided the opportunity to seek this degree and the strength to complete the process. A debt of gratitude is owed to my advisor, Dr. John Bowles, for his guidance over the years. I appreciate his patience as he endured many Friday afternoon meetings.

My thanks also go to the members of my committee for their willingness to serve. Finally, { must thank my family for putting up with my constant travels to Columbia and the stacks of books scattered throughout the house. I’m sure they’re just as happy as I am to see this task accomplished. ii Abstract The use of design patterns in software development has become more attractive given the rise in popularity of development tools utilizing a model driven architecture (MDA) philosophy.

If a given piece of software is designed from a collection of standard design patterns, we should be able to test that software based on the designer’s intent as captured by those patterns. In testing object oriented software, we must be aware that the state of an object at any time depends on the sequence of messages received by the object up to that point in time. As these messages are passed by method calls, the number of methods calls and the order in which they occur must be given consideration. A metric based on method coverage is suitable in this context.

This dissertation examines the utility of design patterns in the practice of software testing. We employ a metric of method coverage to gauge the efficiency obtained by the inclusion of design patterns in two traditional test procedures, statistical design of experiments and reliability block diagrams. In the process, a new type of software system diagram, the Pattern Block Diagram, is developed. ili Table of Contents Acknowledgemenfs.

cà ll 110 cece ce cece eer e ene nena teen eee ee entre eee ne ec ea eee teen enes iii List of Tables.- ni nh vệ Vv List Of FiBUF€S. co nh nh in vi [ntroductiOn. HH HH HH ng nh kh ng l Il. ch nh vi re 3 Il.

HH» HH HH nh nh nhe nà 11 IV. ch KÝ nhi, 19 Testing Object-oriented Soffwar€. Design Patterns and the Statistical Design of Experiments in the Testing of Object-oriented Software. Design Patterns and Reliability Block Diagrams.

069/050 018 cece eee ee. 114 iv List of Tables Table Page 1 | TABLE 3.1 — Conditions for Path Traversal in White Box Testing 23 2 | TABLE 3.2 — Multiple Condition Criteria 25 3 | TABLE 3.3 — Comparison of Path Coverage Criteria 26 4 | TABLE 3.4 — Guidelines for Equivalence Classes 27 5 | TABLE 4.1 — Which path to follow ifx = 0? 32 6 | TABLE 4.1 — node/edge classifications of Rapps and Weyuker 36 7 | TABLE 4.2 - def/use graph sets of Rapps and Weyuker 37 8 | TABLE 4.3 — CoinBox def/use pairs 42 9 | TABLE 4.4 - Stack class documentation 43 10 | TABLE 4.5 - Object data type matrix 47 11 | TABLE 4.6 — Stack or self data type 47 12 | TABLE 6.1 — Patterns of the Invoice Application 86 13 | TABLE 6.2 — Sample pattern data 88 14 | TABLE 6.3 — Sample pattern averages 88 15 | TABLE 6.4 — Invoice Application data 88 16 | TABLE 6.5 — Patterns, classes, and method counts for the Invoice 97 Application 17 | TABLE 6.6 — Classes and method counts for the composite and decorator | 98 patterns 18 | TABLE 6.7 — Union of the composite and decorator patterns of the 98 Invoice Application 19 | TABLE 6.8 - Union of the observer, strategy, and iterator patterns of the | 98 Invoice Application 20 | TABLE 6.9 — Driver function method counts for the Invoice Application | 99 21 | TABLE 6.10 — Strategy/Iterator union method counts for the Invoice 99 Application 22 | TABLE 6.12 — Conditional probabilities ( Based on data of Table 6.13 — Reduction of the Pattern Block Diagram 106 List of Figures Figure Pa 1 | FIGURE 1.1 — An Inheritance Hierarchy 5 2 | FIGURE |.2—- A Branch of the Banking Hierarchy 6 3 | FIGURE 1.3 — Dynamic binding hierarchy 7 4 | FIGURE 1.4 - Output of bankTest 7 5 | FIGURE 1.5 — Class Associations and Cardinalities 9 6 | FIGURE 1.6 — Aggregation of Objects 10 7 | FIGURE 3.1 — Flowchart for Path Traversal in White Box Testing 21 8 | FIGURE 3.2 — Breakdown of Compound Decisions 24 9 | FIGURE 3.3 — Pseudocode for locating name ‘Smith’ in list 25 10 | FIGURE 4.2 — def/use graph of Rapps and Weyuker 36 11 | FIGURE 4.3 — CoinBox code 40 12 | FIGURE 4.4 — CoinBox class call graph 40 13 | FIGURE 4.5 — CoinBox class call graph frame 41 14 | FIGURE 4.6 — Stack class flow graph 44 15 | FIGURE 4.7 — State following steps 1,2,3 of Mungara’s algorithm 45 16 | FIGURE 4.8 — Mungara’s completed test case for push( ) method 45 17 | FIGURE 5.1 - Varying one factor at a time 51 18 | FIGURE 5.2 - Interaction of factors A and C 51 19 | FIGURE 5.3 —A,C interaction + B effect 52 20 | FIGURE 5.4 - Full factorial design for 3 factors 53 21 FIGURE 5.5 - Response table for 3 factors 54 22 | FIGURE 5.6 — Factor levels for chemical reaction experiment 55 23 | FIGURE 5.7 — Response table for chemical reaction experiment 55 24 | FIGURE 5.8 — Graphical representation of response table or the chemical | 56 reaction experiment 25 | FIGURE 5.9 — Transaction Processor user interface 57 26 | FIGURE 5.10 — Factor levels for the Transaction Processor 58 27 | FIGURE 5.11 - Orthogonal 4-Factor design 59 28 | FIGURE 5.12 - Response table for 4 factors 59 vi Figure Page 29 | FIGURE 5.13 - Transaction Processor class count 60 30 | FIGURE 5.14 - Transaction Processor error log 61 31 | FIGURE 5.15 — Completed response table for the Transaction Processor | 62 32 | FIGURE 5.16 - Graphical representation of response table for the 63 Transaction Processor 33 | FIGURE 5.17 - Determining the AB interaction levels 64 34 | FIGURE 5.18 — Four Factor Interaction Response Table 65 35 | FIGURE 5.19 - Comparison of main effects and most significant 66 interactions 36 | FIGURE 5.20 - AD interaction graph and response table 66 37 | FIGURE 5.21 — Four Factors at Three Levels 67 38 | FIGURE 5.22 - Taguchi Z, design 68 39 | FIGURE 5.23 - Results of Taguchi Z, experiment 69 40 | FIGURE 5.24 - Transaction Processor error log, Taguchi design 69 41 | FIGURE 5.25 - The Internationalization Wizard user interface 72 42 | FIGURE 5.26 - Internationalization Wizard class 73 43 | FIGURE 5.27 - Classes of the Internationalization Wizard 74 44 | FIGURE 5.28 - Proportion of methods covered per experimental run 74 45 | FIGURE 5.29 - Proportion of methods covered discounting initialization | 76 | Functions 46 | FIGURE 5.30 - Comparison of DOE and Facade pattern 78 coverage results on per-run basis.31- Comparison of DOE coverage results based 78 on the estimated average response.32 — Contact Mediator interface 80 49 | FIGURE 5.33 - Classes of the Contact Mediator 81 50 | FIGURE 5.34 - Comparison of coverage results including the Mediator 81 pattern.1 - The Invoice Application interface 83 52 | FIGURE 6.2 - Pattern Block Diagram 84 53 | FIGURE 6.3 — Number of Methods per Pattern Type 90 54 | FIGURE 6.4 — Lines of Code per Method 90 Vil Figure Page 55 | FIGURE 6.5 — Proportion of Methods Covered 90 56 | FIGURE 6.6 — Pattern overlay diagram for the Invoice Application 92 57 | FIGURE 6.7 - Pattern Coupling through shared class 2 93 58 | FIGURE 6.7 — Revised Pattern Block Diagram showing the expected 101 pattern node, pattern coupling, and class node method coverage 59 | FIGURE 6.8 — Distinct pattern clusters 104 60 | FIGURE 6.9 — Parallel/Series Pattern Block Diagram 105 Vili I. Introduction The process of software testing is challenging and may occur at many stages of design and development, from unit testing to integration testing to acceptance testing. Following delivery, additional modifications may call for regression testing.

At each of these levels we may apply a variety of black-box and white-box tests. Regardless of the method chosen, we cannot test every possible combination of inputs. Instead, we are forced to select a subset of possible test cases. The generation of test cases is a problem in itself.

Hopefully the set of test cases we select maximizes the number of errors we discover. Several coverage criteria have been proposed to insure that we exercise all statements, all branches, all conditions, or some combination of these. Adding to the complexity, programs developed under an object-oriented paradigm have characteristics not present in procedural software. The fundamental unit of an object-oriented program is the class.

When we test a class we are actually testing an instantiation of that class which is an object. In testing object-oriented software, we must be aware that the state of an object at any time depends on the sequence of messages received by the object up to that point in time. As these messages are passed by method calls, the number of methods calls and the order in which they occur are an additional consideration. Two coverage metrics useful in the analysis of method calls among classes are control flow and data flow.

Control flow is primarily concerned with the branch and loop structures of a program while data flow focuses on the bindings between variables and their values and how the variables are to be used. These are often referred to as definition/use or DU pairs. Much research has been done pertaining to path selection criteria which are based on control flow or data flow techniques. Of particular interest to researchers are strategies by which the generation of test cases may be automated.

Several such methods are described in this paper and most involve complex algorithms.