EuroSTAR ’97, 24-28 November 1997,

EuroSTAR ’97, 24-28 November 1997, Edinburgh UK.


Testing GUI Applications

Paul Gerrard
Systeme Evolutif Limited
9 Cavendish Place
London W1M 0QD
Tel: [phone]
Fax: [phone]
[e-mail]
http://www.evolutif.co.uk

Abstract
Most clients in client/server systems deliver system functionality using a graphical user interface (GUI). When testing complete systems, the tester must grapple with the additional functionality provided by the GUI. GUIs make testing systems more difficult for many reasons: the event-driven nature of GUIs, unsolicited events, many ways in/many ways out and the infinite input domain problems make it likely that the programmer has introduced errors because he could not test every path.
Available literature on testing GUIs tends to focus on tools as the solution to the GUI testing problem. With few exceptions, papers on this topic that have been presented at EuroSTAR and STAR (in the US) over the last few years have paid little attention to GUI test design but have concentrated on how automated regression-test suites can be built and maintained. Our intention is to attempt to formulate a GUI test strategy to detect errors and use tools to assist this process. If we achieve this, the task of building regression test suites will be made much easier.
This paper describes the GUI testability ‘problem’ and offers guidelines on testing these sticky objects manually and with automated tools. We present a summary of the types of error that occur most often in GUI applications and propose an approach to designing GUI tests that focus on these errors. The approach consists of a series of test types that are described in turn. These techniques are assembled into a GUI specific test process that can be mapped onto organisations’ existing staged test process.
This is an interim paper based on ongoing research and work on client projects.

Prerequisite Key Words: none
Topic Descriptors: Testing, GUI, Graphical User Interfaces
1 Introduction
1.1 GUIs as universal client
GUIs have become the established alternative to traditional forms-based user interfaces. GUIs are the assumed user interface for virtually all systems development using modern technologies. There are several reasons why GUIs have become so popular:
• GUIs provide the standard look and feel of a client operating system.
• GUIs are so flexible that they can be used in most application areas.
• The GUI provides seamless integration of custom and package applications.
• The user has a choice of using the keyboard or a mouse device.
• The user has a more natural interface to applications: multiple windows can be visible simultaneously, so user understanding is improved.
• The user is in control: screens can be accessed in the sequence the user wants at will.
1.2 GUIs v forms
Lets look at the differences between GUIs and forms based interfaces.
Forms Based Applications
In forms-based applications, the forms are arranged in a hierarchical order. Most often, a top-level menu is displayed which offers a selection of options and when one option is chosen, the selected screen is displayed. Often, one menu calls another lower level menu to provide a further level of selection. In large applications or packages, there might be three levels of menus to be navigated, before the required functionality is presented to the user. A two level menu system containing fifteen options per menu can provide rapid access to over two hundred screens.
With forms displayed on a screen, we can only display and therefore interact with one form at a time. Usually, when a new form is displayed, it fills the screen and functionality on the old form is now unavailable. The one-at-a-time mode is the main characteristic of forms-based systems. In some applications navigation is achieved form-to form, by providing command-driven interfaces. In this way, the user avoids having to navigate using the menu system.
Typically, expert users use such command-driven methods, while occasional users adopt the menu-driven approach. In a sophisticated application, expert users may navigate to virtually any system feature from any other, as long as they know what commands are available, wherever they are. Occasional users are left with the problem of always having to navigate through menus. In large, complex systems, this can be a major headache.
In application forms, the fields on the form have a predefined and unchangeable ‘tabbing order’. That is, the user may only access the fields in a certain order, regardless of whether any data has been entered into the form fields. Navigation is normally achieved through use of the tab key to move forwards and the backspace key to go backwards.
GUIs
The most obvious characteristic of GUI applications is the fact that the GUI allows multiple windows to be displayed at the same time. Displayed windows are ‘owned’ by applications and of course, there may be more than one application active at the same time.
Access to features of the systems is provided via three mechanisms. Menu bars provide almost continuous availability of the various features of the systems; buttons and keyboard shortcuts enable the user to navigate and access the various functions of their application.
Windows provide forms-like functionality with fields in which text or numeric data can be entered. But GUIs introduce additional objects such as radio buttons, scrolling lists, check boxes and other graphics that may be displayed or directly manipulated.
The GUI itself manages the simultaneous presentation of multiple applications and windows. Hidden windows in the same or different applications may be brought forward and used. There are few, if any, constraints on the order in which users access GUI windows so users are free to use the features of the system in the way they prefer, rather than the way the developers architected it.
Fields within windows have a tabbing order, but the user is free to use the mouse to change the focus of the application to any field on screen. There are no constraints on the order in which a user may enter data on a screen. To the user, there are advantages in being able to access fields directly (perhaps to avoid tabbing through many fields that will not change).
In short, GUIs free the user to access system functionality in their preferred way. They have permanent access to all features and may use the mouse, the keyboard or a combination of both to have a more natural dialogue with the system.
1.3 Some testing difficulties
GUIs have brought considerable benefits to developers. They release the developer from the concerns of interface design – in most environments, GUI design standards impose conventions which make one application look very much like another on the same platform.
However, the sophistication and simplicity of a GUI hides the complexity from the user and where development frameworks are used, the programmers too. When testers are presented with a GUI application to test, the hidden complexities become all too obvious. Consequently, testing GUIs is made considerably more difficult. What are the reasons for this?
Event-driven software
The event-driven nature of GUIs presents the first serious testing difficulty. Because users many click on any pixel on the screen, there are many, many more possible user inputs that can occur. The user has an extremely wide choice of actions. At any point in the application, the users may click on any field or object within a window. They may bring another window in the same application to the front and access that. The window may be owned by another application. The user may choose to access an operating system component directly e.g. a system configuration control panel.
The large number of available options mean that the application code must at all times deal with the next event, whatever it may be. In the more advanced development environments, where sophisticated frameworks are being used, many of these events are handled ‘behind the scenes’. With less advanced toolkits, the programmer must write code to handle these events explicitly. Many errors occur because the programmer cannot anticipate every context in which their event handlers are invoked.
Many events such as button clicks cause the focus of the application to move from one feature to another completely unrelated feature. Not only does the selected feature have to deal with a potentially unknown context, the previous feature may be ‘left hanging’ in a partially completed state. The number of potential paths from feature to feature within the application is so high that the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem also makes it extremely unlikely that they will all be tested.
Unsolicited events
Unsolicited events cause problems for programmers and testers. A trivial example would be when a local printer goes off-line, and the operating system puts up a dialog box inviting the user to feed more paper into the printer. A more complicated situation arises where message-oriented middleware might dispatch a message (an event) to remind the client application to redraw a diagram on screen, or refresh a display of records from a database that has changed.
Unsolicited events may occur at any time, so again, the number of different situations that the code must accommodate is extremely high. Testing of unsolicited events is difficult because of the number of test cases may be high but also special test drivers may be necessary to generate such events within the operating systems.
Object oriented
GUIs map very well to the object-oriented paradigm. The desktop, windows and other graphical elements are usually organised into a hierarchy of objects that deal with GUI events. Every object has its own methods (event handlers) and attributes. Typical attributes define the object’s state and usually include:
• Is the object active or inactive

Kết quả (Việt) 1:

EuroSTAR ’97, 24-28 November 1997, Edinburgh UK. Testing GUI Applications Paul GerrardSysteme Evolutif Limited9 Cavendish PlaceLondon W1M 0QDTel: [phone]Fax: [phone] [e-mail]://www.evolutif.co.uk AbstractMost clients in client/server systems deliver system functionality using a graphical user interface (GUI). When testing complete systems, the tester must grapple with the additional functionality provided by the GUI. GUIs make testing systems more difficult for many reasons: the event-driven nature of GUIs, unsolicited events, many ways in/many ways out and the infinite input domain problems make it likely that the programmer has introduced errors because he could not test every path.Available literature on testing GUIs tends to focus on tools as the solution to the GUI testing problem. With few exceptions, papers on this topic that have been presented at EuroSTAR and STAR (in the US) over the last few years have paid little attention to GUI test design but have concentrated on how automated regression-test suites can be built and maintained. Our intention is to attempt to formulate a GUI test strategy to detect errors and use tools to assist this process. If we achieve this, the task of building regression test suites will be made much easier.Bài báo này mô tả GUI testability 'vấn đề' và cung cấp hướng dẫn về các đối tượng dính bằng tay và với công cụ tự động thử nghiệm. Chúng tôi trình bày một bản tóm tắt của các loại lỗi mà xảy ra thường xuyên nhất trong các ứng dụng GUI và đề xuất một cách tiếp cận để thiết kế GUI bài kiểm tra tập trung vào các lỗi này. Các phương pháp bao gồm một loạt các loại thử nghiệm được mô tả lần lượt. Các kỹ thuật này được lắp ráp vào một quá trình thử nghiệm cụ thể GUI có thể được ánh xạ lên quá trình theo giai đoạn thử nghiệm hiện tại của tổ chức.Đây là một giấy tạm thời dựa trên nghiên cứu liên tục và làm việc về các dự án khách hàng. Từ khóa điều kiện tiên quyết: không cóBộ mô tả chủ đề: Thử nghiệm, giao diện, giao diện người dùng đồ họa1 giới thiệu1.1 GUIs là phổ quát khách hàngGraphical đã trở thành thay thế được thành lập cho giao diện người dùng dựa trên hình thức truyền thống. Graphical là giao diện người dùng giả định cho hầu như tất cả phát triển hệ thống bằng cách sử dụng công nghệ hiện đại. Có rất nhiều lý do tại sao GUIs đã trở nên phổ biến:• GUIs cung cấp tiêu chuẩn giao diện của một hệ thống điều hành khách hàng. • GUIs linh hoạt như vậy rằng họ có thể được sử dụng trong hầu hết các khu vực ứng dụng. • GUI cung cấp tích hợp liền mạch của các tùy chỉnh và các gói ứng dụng. • Người dùng có thể lựa chọn bằng cách sử dụng bàn phím hoặc một thiết bị con chuột. • Người sử dụng có một giao diện tự nhiên hơn cho các ứng dụng: nhiều cửa sổ có thể được nhìn thấy cùng một lúc, do đó, sự hiểu biết của người sử dụng được cải thiện. • The user is in control: screens can be accessed in the sequence the user wants at will. 1.2 GUIs v formsLets look at the differences between GUIs and forms based interfaces.Forms Based ApplicationsIn forms-based applications, the forms are arranged in a hierarchical order. Most often, a top-level menu is displayed which offers a selection of options and when one option is chosen, the selected screen is displayed. Often, one menu calls another lower level menu to provide a further level of selection. In large applications or packages, there might be three levels of menus to be navigated, before the required functionality is presented to the user. A two level menu system containing fifteen options per menu can provide rapid access to over two hundred screens.With forms displayed on a screen, we can only display and therefore interact with one form at a time. Usually, when a new form is displayed, it fills the screen and functionality on the old form is now unavailable. The one-at-a-time mode is the main characteristic of forms-based systems. In some applications navigation is achieved form-to form, by providing command-driven interfaces. In this way, the user avoids having to navigate using the menu system.Typically, expert users use such command-driven methods, while occasional users adopt the menu-driven approach. In a sophisticated application, expert users may navigate to virtually any system feature from any other, as long as they know what commands are available, wherever they are. Occasional users are left with the problem of always having to navigate through menus. In large, complex systems, this can be a major headache.In application forms, the fields on the form have a predefined and unchangeable ‘tabbing order’. That is, the user may only access the fields in a certain order, regardless of whether any data has been entered into the form fields. Navigation is normally achieved through use of the tab key to move forwards and the backspace key to go backwards.GUIsThe most obvious characteristic of GUI applications is the fact that the GUI allows multiple windows to be displayed at the same time. Displayed windows are ‘owned’ by applications and of course, there may be more than one application active at the same time.Access to features of the systems is provided via three mechanisms. Menu bars provide almost continuous availability of the various features of the systems; buttons and keyboard shortcuts enable the user to navigate and access the various functions of their application.Windows provide forms-like functionality with fields in which text or numeric data can be entered. But GUIs introduce additional objects such as radio buttons, scrolling lists, check boxes and other graphics that may be displayed or directly manipulated. The GUI itself manages the simultaneous presentation of multiple applications and windows. Hidden windows in the same or different applications may be brought forward and used. There are few, if any, constraints on the order in which users access GUI windows so users are free to use the features of the system in the way they prefer, rather than the way the developers architected it.
Fields within windows have a tabbing order, but the user is free to use the mouse to change the focus of the application to any field on screen. There are no constraints on the order in which a user may enter data on a screen. To the user, there are advantages in being able to access fields directly (perhaps to avoid tabbing through many fields that will not change).
In short, GUIs free the user to access system functionality in their preferred way. They have permanent access to all features and may use the mouse, the keyboard or a combination of both to have a more natural dialogue with the system.
1.3 Some testing difficulties
GUIs have brought considerable benefits to developers. They release the developer from the concerns of interface design – in most environments, GUI design standards impose conventions which make one application look very much like another on the same platform.
However, the sophistication and simplicity of a GUI hides the complexity from the user and where development frameworks are used, the programmers too. When testers are presented with a GUI application to test, the hidden complexities become all too obvious. Consequently, testing GUIs is made considerably more difficult. What are the reasons for this?
Event-driven software
The event-driven nature of GUIs presents the first serious testing difficulty. Because users many click on any pixel on the screen, there are many, many more possible user inputs that can occur. The user has an extremely wide choice of actions. At any point in the application, the users may click on any field or object within a window. They may bring another window in the same application to the front and access that. The window may be owned by another application. The user may choose to access an operating system component directly e.g. a system configuration control panel.
The large number of available options mean that the application code must at all times deal with the next event, whatever it may be. In the more advanced development environments, where sophisticated frameworks are being used, many of these events are handled ‘behind the scenes’. With less advanced toolkits, the programmer must write code to handle these events explicitly. Many errors occur because the programmer cannot anticipate every context in which their event handlers are invoked.
Many events such as button clicks cause the focus of the application to move from one feature to another completely unrelated feature. Not only does the selected feature have to deal with a potentially unknown context, the previous feature may be ‘left hanging’ in a partially completed state. The number of potential paths from feature to feature within the application is so high that the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem also makes it extremely unlikely that they will all be tested.
Unsolicited events
Unsolicited events cause problems for programmers and testers. A trivial example would be when a local printer goes off-line, and the operating system puts up a dialog box inviting the user to feed more paper into the printer. A more complicated situation arises where message-oriented middleware might dispatch a message (an event) to remind the client application to redraw a diagram on screen, or refresh a display of records from a database that has changed.
Unsolicited events may occur at any time, so again, the number of different situations that the code must accommodate is extremely high. Testing of unsolicited events is difficult because of the number of test cases may be high but also special test drivers may be necessary to generate such events within the operating systems.
Object oriented
GUIs map very well to the object-oriented paradigm. The desktop, windows and other graphical elements are usually organised into a hierarchy of objects that deal with GUI events. Every object has its own methods (event handlers) and attributes. Typical attributes define the object’s state and usually include:
• Is the object active or inactive

Kết quả (Việt) 2:

. Eurostar '97, ngày 24-ngày 28 tháng mười một năm 1997, Edinburgh Anh Thử nghiệm ứng dụng GUI Paul Gerrard Systeme Evolutif TNHH 9 Cavendish Nơi London W1M 0QD Tel: [phone] Fax: [phone] paulg @ evolutif .co.uk http://www.evolutif.co.uk Tóm tắt Hầu hết các khách hàng trong hệ thống client / server cung cấp chức năng hệ thống bằng cách sử dụng một giao diện người dùng đồ họa (GUI). Khi thử nghiệm hệ thống hoàn chỉnh, các thử nghiệm phải vật lộn với các chức năng bổ sung được cung cấp bởi các GUI. Ảnh minh hoạ cho các hệ thống thử nghiệm khó khăn hơn vì nhiều lý do: bản chất sự kiện định hướng của ảnh minh hoạ, sự kiện không mong muốn, nhiều cách thức / nhiều cách ra và các vấn đề miền đầu vào vô hạn làm cho nó có khả năng là các lập trình viên đã giới thiệu sai lầm vì anh không thể kiểm tra mọi con đường . văn học có sẵn trên thử nghiệm GUIs có xu hướng tập trung vào các công cụ như là giải pháp cho vấn đề giao diện thử nghiệm. Với vài ngoại lệ, giấy tờ về chủ đề này đã được trình bày tại Eurostar và STAR (ở Mỹ) trong vài năm qua đã ít quan tâm đến thiết kế giao diện thử nghiệm nhưng đã tập trung vào dãy hồi quy kiểm tra như thế nào tự động có thể được xây dựng và duy trì. Mục đích của chúng tôi là cố gắng để xây dựng một chiến lược kiểm thử giao diện để phát hiện lỗi và sử dụng các công cụ để hỗ trợ quá trình này. Nếu chúng ta đạt được điều này, các nhiệm vụ xây dựng dãy phòng thử nghiệm hồi quy sẽ được thực hiện dễ dàng hơn nhiều. Bài viết này mô tả các GUI testability 'vấn đề' và cung cấp hướng dẫn về kiểm tra các đối tượng dính tay và với các công cụ tự động. Chúng tôi trình bày một bản tóm tắt của các loại lỗi xảy ra thường xuyên nhất trong các ứng dụng giao diện đồ họa và đề xuất một cách tiếp cận để thiết kế thử nghiệm giao diện mà tập trung vào các lỗi này. Cách tiếp cận này bao gồm một loạt các loại thử nghiệm được mô tả lần lượt. Những kỹ thuật này được lắp ráp thành một quá trình thử nghiệm cụ GUI có thể được ánh xạ vào các tổ chức hiện có tổ chức quá trình thử nghiệm. Đây là một giấy tạm thời dựa trên những nghiên cứu liên tục và làm việc trên các dự án của khách hàng. Điều kiện tiên quyết Từ khóa: none Descriptors Topic: Thử nghiệm, giao diện, đồ họa Giao diện người dùng 1 Giới thiệu 1.1 minh hoạ như client phổ GUIs đã trở thành thay thế được thành lập với các hình thức dựa trên giao diện người dùng truyền thống. Ảnh minh hoạ là giao diện người dùng được giả thiết cho hầu như tất cả các hệ thống phát triển bằng cách sử dụng các công nghệ hiện đại. Có nhiều lý do tại sao ảnh minh hoạ đã trở nên quá phổ biến: • GUI cung cấp cái nhìn tiêu chuẩn và cảm nhận của một hệ thống điều hành máy khách. • ảnh minh hoạ rất linh hoạt mà họ có thể được sử dụng trong hầu hết các lĩnh vực ứng dụng. • Các giao diện tích hợp khả năng tùy chỉnh và gói ứng dụng. • Người sử dụng có thể lựa chọn bằng cách sử dụng bàn phím hoặc một thiết bị chuột. • Người sử dụng có một giao diện tự nhiên hơn cho các ứng dụng: nhiều cửa sổ có thể được hiển thị cùng một lúc, vì vậy người sử dụng hiểu được cải thiện. • Người sử dụng có kiểm soát: màn hình có thể được truy cập trong trình tự người dùng muốn theo ý muốn. 1.2 minh hoạ các hình thức v Cho phép xem xét sự khác biệt giữa ảnh minh hoạ và các hình thức giao diện dựa trên. Ứng dụng Forms Dựa Trong các ứng dụng dựa trên biểu mẫu, các mẫu này được sắp xếp theo một trật tự thứ bậc. Thông thường, một menu cấp cao sẽ được hiển thị trong đó cung cấp một lựa chọn các tùy chọn và khi một tùy chọn được chọn, màn hình lựa chọn được hiển thị. Thông thường, một menu các cuộc gọi một menu cấp thấp hơn để cung cấp một cấp độ cao hơn của sự lựa chọn. Trong các ứng dụng lớn hoặc gói, có thể có ba cấp độ của menu để điều hướng, trước khi các chức năng cần được trình bày cho người dùng. Một hệ thống menu hai cấp độ có chứa mười lăm tùy chọn mỗi đơn có thể cung cấp truy cập nhanh đến hơn hai trăm màn hình. Với các hình thức hiển thị trên một màn hình, chúng ta chỉ có thể hiển thị và do đó tương tác với một mẫu đơn tại một thời điểm. Thông thường, khi một hình thức mới được hiển thị, nó lấp đầy màn hình và chức năng trên các hình thức cũ bây giờ là không có. Các chế độ một-at-a-thời gian là đặc điểm chính của hệ thống dựa trên các hình thức. Trong một số ứng dụng dẫn đường đạt được hình thức để tạo, bằng cách cung cấp các giao diện lệnh điều khiển. Bằng cách này, người sử dụng tránh được việc phải điều hướng bằng cách sử dụng hệ thống menu. Thông thường, người sử dụng chuyên gia sử dụng phương pháp lệnh theo định hướng như vậy, trong khi người sử dụng không thường xuyên áp dụng phương pháp điều khiển theo menu. Trong một ứng dụng phức tạp, người dùng có thể điều hướng đến chuyên gia hầu như bất kỳ tính năng hệ thống từ bất kỳ khác, miễn là họ biết những gì các lệnh có sẵn, bất cứ nơi nào họ đang có. Người sử dụng không thường xuyên là trái với các vấn đề luôn luôn phải điều hướng qua các menu. Trong lớn, hệ thống phức tạp, điều này có thể là một trở ngại lớn. Trong các hình thức ứng dụng, các lĩnh vực trên biểu mẫu có một 'tabbing thứ tự được xác định trước và không thể thay đổi. Đó là, người dùng chỉ có thể truy cập vào các lĩnh vực theo một thứ tự nhất định, cho dù bất kỳ dữ liệu đã được nhập vào các ô. Navigation thường đạt được thông qua việc sử dụng các phím tab để di chuyển về phía trước và phím xóa để đi ngược trở lại. GUIs Các đặc trưng rõ ràng nhất của các ứng dụng GUI là một thực tế rằng GUI cho phép nhiều cửa sổ sẽ được hiển thị cùng một lúc. Cửa sổ hiển thị được 'sở hữu' của các ứng dụng và tất nhiên, có thể có nhiều hơn một ứng dụng hoạt động cùng một lúc. Truy cập vào các tính năng của hệ thống được cung cấp thông qua ba cơ chế. Menu bar cung cấp sẵn có gần như liên tục của các tính năng khác nhau của hệ thống; các nút và phím tắt cho phép người dùng điều hướng và truy cập các chức năng khác nhau của ứng dụng của họ. Windows cung cấp các chức năng hình thức giống như với các lĩnh vực, trong đó văn bản hoặc số dữ liệu có thể được nhập vào. Nhưng GUIs giới thiệu đối tượng bổ sung như các nút radio, danh sách cuộn, hộp kiểm tra và đồ họa khác có thể được hiển thị hoặc thao tác trực tiếp. Các giao diện chính nó quản lý trình bày đồng thời nhiều ứng dụng và các cửa sổ. Cửa sổ bị ẩn trong các ứng dụng giống và khác nhau có thể được đưa về phía trước và sử dụng. Có rất ít, nếu có, những hạn chế về trình tự, trong đó người sử dụng truy cập vào giao diện cửa sổ để người dùng có thể tự do sử dụng các tính năng của hệ thống trong cách mà họ thích, chứ không phải là cách làm việc của các nhà phát triển thiết kế nó. Fields trong cửa sổ có một trật tự tabbing , nhưng người dùng có thể tự do sử dụng chuột để thay đổi trọng tâm của các ứng dụng cho bất kỳ lĩnh vực trên màn hình. Không có hạn chế về trình tự, trong đó người dùng có thể nhập dữ liệu trên màn hình. Để người sử dụng, có lợi thế trong việc có thể truy cập vào các lĩnh vực trực tiếp (có lẽ để tránh tabbing thông qua nhiều lĩnh vực đó sẽ không thay đổi). Trong ngắn hạn, ảnh minh hoạ phóng người sử dụng để truy cập vào hệ thống chức năng trong cách ưa thích của họ. Họ có quyền truy cập vĩnh viễn cho tất cả các tính năng và có thể sử dụng chuột, bàn phím hoặc một sự kết hợp của cả hai để có một cuộc đối thoại tự nhiên hơn với hệ thống. 1.3 Một số khó khăn thử nghiệm GUIs đã mang lại lợi ích đáng kể cho các nhà phát triển. Chúng giải phóng các nhà phát triển từ những mối quan tâm của thiết kế giao diện - trong hầu hết các môi trường, tiêu chuẩn thiết kế GUI áp đặt quy ước mà làm cho một ứng dụng trông rất giống nhau trên cùng một nền tảng. Tuy nhiên, sự tinh tế và đơn giản của một giao diện ẩn sự phức tạp từ người sử dụng và nơi khung phát triển được sử dụng, các lập trình quá. Khi thử nghiệm được trình bày với một ứng dụng GUI để kiểm tra, sự phức tạp ẩn trở nên quá rõ ràng. Do đó, kiểm tra ảnh minh hoạ được thực hiện khá khó khăn. Những lý do cho điều này là gì? Event-driven phần mềm Bản chất sự kiện định hướng của ảnh minh hoạ trình bày những khó khăn thử nghiệm nghiêm trọng đầu tiên. Bởi vì nhiều người dùng nhấp chuột vào bất kỳ điểm ảnh trên màn hình, có rất nhiều, nhiều người sử dụng đầu vào có thể hơn có thể xảy ra. Người sử dụng có một sự lựa chọn rất rộng của các hành động. Tại bất kỳ điểm nào trong các ứng dụng, người dùng có thể nhấp vào bất kỳ lĩnh vực hoặc đối tượng bên trong một cửa sổ. Họ có thể mang lại một cửa sổ khác trong cùng một ứng dụng cho mặt trước và truy cập vào đó. Các cửa sổ có thể được sở hữu bởi một ứng dụng khác. Người dùng có thể chọn để truy cập vào một thành phần hệ điều hành trực tiếp, ví dụ như một bảng điều khiển cấu hình hệ thống. Số lượng lớn các tùy chọn sẵn có nghĩa là mã ứng dụng phải ở tất cả các lần đối phó với những sự kiện tiếp theo, bất kể nó có thể được. Trong môi trường phát triển tiên tiến hơn, nơi các khuôn khổ phức tạp đang được sử dụng, nhiều người trong số những sự kiện này được xử lý 'đằng sau hậu trường'. Với bộ công cụ ít tiên tiến, các lập trình viên phải viết code để xử lý các sự kiện này một cách rõ ràng. Nhiều lỗi xảy ra bởi vì các lập trình viên không thể lường trước mọi hoàn cảnh, trong đó xử lý sự kiện của họ được viện dẫn. Nhiều sự kiện như nút bấm gây ra sự tập trung của các ứng dụng để di chuyển từ một trong những tính năng khác tính năng hoàn toàn không liên quan. Không chỉ các tính năng được lựa chọn phải đối phó với một bối cảnh tiềm năng chưa được biết, các tính năng trước đó có thể "treo lại" trong một nhà nước hoàn thành một phần. Số lượng các con đường tiềm năng từ tính năng đến tính năng trong ứng dụng là quá cao mà phạm vi cho các lập trình để thực hiện các lỗi được tăng lên đáng kể. Vấn đề 'con đường vô hạn' cũng làm cho nó khó tin rằng chúng tất cả sẽ được kiểm tra. Sự kiện Unsolicited sự kiện Unsolicited gây ra vấn đề cho các lập trình và kiểm thử. Một ví dụ nhỏ là khi một máy in địa phương đi off-line, và hệ điều hành đã đưa ra một hộp thoại mời người sử dụng để nuôi thêm giấy vào máy in. Một tình huống phức tạp hơn phát sinh mà tin theo định hướng middleware có thể gửi một tin nhắn (một sự kiện) để nhắc nhở các ứng dụng client để vẽ lại một sơ đồ trên màn hình, hoặc làm mới một màn hình hiển thị các bản ghi từ một cơ sở dữ liệu đó đã thay đổi. Sự kiện Unsolicited có thể xảy ra bất cứ lúc nào , vì vậy một lần nữa, số lượng các tình huống khác nhau mà các mã phải chứa là rất cao. Thử nghiệm các sự kiện không mong muốn là rất khó khăn vì số lượng các trường hợp thử nghiệm có thể cao nhưng cũng điều khiển kiểm tra đặc biệt có thể cần thiết để tạo ra các sự kiện như trong các hệ điều hành. Object hướng GUIs bản đồ rất tốt cho các mô hình hướng đối tượng. Các máy tính để bàn, cửa sổ và các yếu tố đồ họa khác thường được tổ chức thành một hệ thống các đối tượng mà đối phó với các sự kiện GUI. Mỗi đối tượng có phương pháp riêng của mình (xử lý sự kiện) và các thuộc tính. Các thuộc tính điển hình xác định trạng thái của đối tượng và thường bao gồm: • Là các đối tượng hoạt động hoặc không hoạt động