Testing Web Software Applications
Upcoming SlideShare
Loading in...5
×
 

Testing Web Software Applications

on

  • 575 views

 

Statistics

Views

Total Views
575
Views on SlideShare
575
Embed Views
0

Actions

Likes
1
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Testing Web Software Applications Testing Web Software Applications Document Transcript

  • Testing Web Software Applications Jeff Offutt, PhD Information & Software Engineering George Mason University Fairfax, VA USA www.ise.gmu.edu/~ofut/ ofut@ise.gmu.edu Roger Alexander, Colorado State University Joint work with: Anneliese Andrews, Washington State University Ye Wu George Mason University Supported by NSF and NIST. Outline of Talk 1. Introduction to Web Software Applications 2. Testing Object-oriented Software 3. Difficulties with Analyzing and Testing Web Software 4. Integration Testing of Loosely Coupled Software 5. Testing the Dynamic Flow of Control 6. System Testing Web Software Applications 7. Future Methods and Technologies June 2003 © Offutt 1999-2003. All Rights Reserved. 2
  • Introduction to Web Software Applications Web Engng June 2003 © Offutt 1999-2003. All Rights Reserved. 3 Web Software Engineering • Modern web sites are now too complicated for individuals to manage. • They need to be engineered by teams of people with diverse talents: – Programming skills – Graphics design – Usability – Information layout and engineering – Data communications – Data base We need web site engineering June 2003 © Offutt 1999-2003. All Rights Reserved. 4
  • Web Sites and Software • Web Page : Data that fits in one browser screen • Web Site : A number of connected web pages • Web Site Software : Software that makes web sites dynamic and interactive • Dynamic Web Page : A web page that is generated on demand by a program (such as a servlet or JSP) network Web Client Server Software June 2003 © Offutt 1999-2003. All Rights Reserved. 5 Important Web Software Quality Attributes 1. Reliability 2. Usability Customers have little “site loyalty” 3. Security and will switch quickly, thus time to market is much less important 4. Availability than in other application areas. 5. Scalability (but still important!) 6. Maintainability 7. Performance & Time-to-market Based on an informal survey of about a dozen software development managers, 2000. June 2003 © Offutt 1999-2003. All Rights Reserved. 6
  • Complexities of Web Site Software • Heterogeneous – Diverse hardware platforms – Diverse software platforms – Diverse software languages – Diverse software models (imperative, declarative, functional, …) – Diverse organizations building the software • Concurrent and distributed • High quality requirements • High degree of reuse and third party components • New essential problems June 2003 © Offutt 1999-2003. All Rights Reserved. 7 Multi-tiered Web Software Systems network middleware middleware Client Web Application DB Server Server Server Browser HTML Java Javascripts CGI JSP, etc Client-server … 3-tier … N-tier … June 2003 © Offutt 1999-2003. All Rights Reserved. 8
  • Challenges of N-Tier Architectures • Communication and distribution is usually handled by bought middleware (CORBA, EJB, DCOM, etc) • Software becomes heterogeneous and parallel • Advantages: – More powerful applications – Many services to many clients – Enhanced security, scalability and availability • Disadvantages: – Designing truly reusable objects is difficult – More complicated to design and model – Performance risks – Reliability is more difficult to achieve – More difficult to maintain software – A lot to learn about the new technologies June 2003 © Offutt 1999-2003. All Rights Reserved. 9 Web Software • Client-side – HTML – Scripting languages (Javascript) • Server-side – CGI – Compiled modules (Java servlets, ASP) – Scripted-page modules (JSP, ASP, PHP) – Data storage (beans, DB) – Web servers June 2003 © Offutt 1999-2003. All Rights Reserved. 10
  • Compiled Modules - Servlets • Servlets are small Java classes that perform a service • Servlet container or engine – connects to network – catches requests – produces responses – requests are handled by objects • Servlets receive requests and data • Servlets have full access to the server: – Database – Other software componentsShared memory with other servlets June 2003 © Offutt 1999-2003. All Rights Reserved. 11 Scripted-page Modules - Java Server Pages • JSPs turn servlets "inside-out": – Instead of HTML in Java … – Java in HTML • JSPs are to translated to servlets, compiled, then executed • This encourages separation of tasks: Integration w/ Application Page Layout Writing JSP Development HTML Java, JavaBeans Webby Java Java Graphics designer ? programmer programmer June 2003 © Offutt 1999-2003. All Rights Reserved. 12
  • Session Management & Tracking • HTTP client server communication is connnectionless – Connection is terminated as soon as the request is made and fulfilled (simple and resistant to network problems) • But how can a server keep track of state of different clients? Session: A series of related interactions between a client and a web server (similar to a use case) Request with a Token Client Server C Response with a Token S June 2003 © Offutt 1999-2003. All Rights Reserved. 13 Web Software Technologies • The new technologies were created partly because of the decoupled, networked aspect of the web • But the major motivation has been to support the very high quality requirements of web software June 2003 © Offutt 1999-2003. All Rights Reserved. 14
  • Testing of Web Software Applications • Web software applications are composed of – HTML – Client-side scripts (Javascript) – Client-side Web software components • Compiled modules (servlets) • Scripted page modules (JSPs) • Data abstraction modules (Javabeans) – Traditional object-oriented classes • First we will explore how to test object-oriented classes … June 2003 © Offutt 1999-2003. All Rights Reserved. 15 Testing Object-oriented Software OO Test June 2003 © Offutt 1999-2003. All Rights Reserved. 16
  • Inheritance Declared type: The type given when an object reference is declared Clock w1; // declared type Clock Actual type: The type of the current object w1 = new Watch(); // actual type Watch A In Java, the method that is executed is the lowest version of the method defined B between the actual and root types in the C inheritance hierarchy June 2003 © Offutt 1999-2003. All Rights Reserved. 17 Polymorphism • The same variable can have different types depending on the program execution • If B inherits from A, then an object of type B can be used when an object of type A is expected • If both A and B define the same method M (B overrides A), then the same statement might call either A’s version of M or B’s version June 2003 © Offutt 1999-2003. All Rights Reserved. 18
  • Example DU Pairs and Anomalies Consider what happens when an A overriding method has a different -u def-use -v def-set than the overridden method -w +h() Method Uses Defs +I() +j() A::h () {A::u, A::w} +l() A::i () {A::u} A::j () {A::v} {A::w} B -x A::l() {A::v} DU +h () B::h() {B::x} anomaly +i () B::i() {B::x} C::i() C -y C::j() {C::y} {C::y} +i () C::l() {A::v} +j () +l () def-use DU June 2003 © Offutt 1999-2003. All Rights Reserved. anomaly 19 Polymorphism Headaches (Yo-Yo) A Instantiated implicit implicit implicit implicit +d () A d() g() h() i() j() l() +g () type +h () B h() i() k() +i () +j () C i() j() l() +l () Object is of type A A::d () June 2003 © Offutt 1999-2003. All Rights Reserved. 20
  • Polymorphism Headaches (Yo-Yo) A Instantiated implicit implicit implicit implicit +d () A d() g() h() i() j() l() +g () type +h () B h() i() k() +i () +j () C i() j() l() +l () A d() g() h() i() j() l() B Instantiated implicit +h () B h() i() k() +i () type +k () C i() j() l() Object is of type B B::d () June 2003 © Offutt 1999-2003. All Rights Reserved. 21 Polymorphism Headaches (Yo-Yo) A Instantiated implicit implicit implicit implicit +d () A d() g() h() i() j() l() +g () type +h () B h() i() k() +i () +j () C i() j() l() +l () A d() g() h() i() j() l() B Instantiated implicit +h () B h() i() k() +i () type +k () C i() j() l() A d() g() h() i() j() l() B h() i() k() C Instantiated +i () C i() j() l() +j () type +l () Object is of type C, C::d () June 2003 © Offutt 1999-2003. All Rights Reserved. 22
  • Potential for Faults in OO Programs • Complexity is relocated to the connections among components • Less static determinism – many faults can now only be detected at runtime • Inheritance and Polymorphism yield vertical and dynamic integration • Aggregation and use relationships are more complex • Designers do not carefully consider visibility of data and methods June 2003 © Offutt 1999-2003. All Rights Reserved. 23 Testing OO Software 1) Intra-method testing: Testing individual methods within classes 2) Inter-method testing: Pairs of methods within a class are tested in concert 3) Intra-class testing: Testing a single class, usually using sequences of method calls 4) Inter-class testing: More than one class is tested at the same time (integration) June 2003 © Offutt 1999-2003. All Rights Reserved. 24
  • Coupling-Based Testing • Test data and control connections Caller x = 14 last-def-before-call • Derived from previous F work for non-procedural y = G (x) call site programs print (y) first-use-after-call • Based on insight that Callee integration occurs through G (a) print (a) first-use-in-callee couplings among software b = 42 last-def-before-return artifacts return (b) June 2003 © Offutt 1999-2003. All Rights Reserved. 25 Polymorphic Call Set public void f ( W o ) { … Set of methods that can potentially execute as result of j o.m(); a method call through a … particular instance context pcs(o.m) = {W::m, Y::m, X::m} l o.l(); … k o.n(); } June 2003 © Offutt 1999-2003. All Rights Reserved. 26
  • Coupling Sequences • Pairs of method calls within body of method under test: – Made through a common instance context – With respect to a set of state variables that are commonly referenced by both methods – Consists of at least one coupling path between the two method calls with respect to a particular state variable • Represent potential state space interactions between the called methods with respect to calling method • Used to identify points of integration and testing requirements June 2003 © Offutt 1999-2003. All Rights Reserved. 27 Example Coupling Sequence Client f W o bound to h def (o) -v : m () -u : i o.m() instance of W +m() +n() def (W::v) +l() l () j o.l() X Z -x : def (W::u) +n() +m() +n() n () k o.n() Y Coupling -w : Coupling sequence with use (W::u) +m() +l() sequence with respect to W::u use (W::v) respect to W::v June 2003 © Offutt 1999-2003. All Rights Reserved. 28
  • Example Coupling Sequence (2) Client f W o bound to h def (o) -v : m () -u : i o.m() instance of Z +m() +n() def (Z::x) +l() l () j o.l() X Z -x : -x : def (W::u) +n() +m() +n() n () k o.n() Y -w : Coupling use (Z::x) +m() +l() sequence with use (Z::x) respect to Z::x June 2003 © Offutt 1999-2003. All Rights Reserved. 29 Testing Requirements • Want to test the ways in which f can interact with instance bound to object o: – Interactions occur through the coupling sequences • Need to consider the set of interactions that can occur: – What types can be bound to o? – Which methods can actually execute? (polymorphic call sets) • Test all couplings with all possible type bindings June 2003 © Offutt 1999-2003. All Rights Reserved. 30
  • All-Poly-Coupling-Defs-and-Uses Every coupling path must be executed for every member of the type family defined by the context of a coupling sequence and for every coupling variable in the sequence • Handles inheritance and polymorphism • Takes definitions and uses of variables into account But Web software has much more than inheritance and polymorphism … June 2003 © Offutt 1999-2003. All Rights Reserved. 31 Difficulties with Analyzing and Testing Web Software Web Software June 2003 © Offutt 1999-2003. All Rights Reserved. 32
  • New Essential Problems of Web Site Software 1. Web site software is extremely loosely coupled – Coupled through the Internet – separated by space – Coupled to diverse hardware and software applications – Web services will dynamically couple with other services after deployment – without human intervention! 2. Web software services offer dynamically changing flow of control – Web pages are created by software on user request – The interaction points (forms, buttons, etc.) vary depending on state: the user, previous choices, server-side data, even time of day – Examples: amazon.com, netflix.com, washingtonpost.com June 2003 © Offutt 1999-2003. All Rights Reserved. 33 Problem 1: Loosely Coupled Traditional systems Web-based systems Connected by calls and message passing Connected with network protocols High and moderate coupling Loose and extremely loose coupling How can we ensure the reliability of this type of system? June 2003 © Offutt 1999-2003. All Rights Reserved. 34
  • Problem 2: Dynamic Flow of Control WebPics WebPics Welcome Yong-Rae Kwon! whan young hap ni da Byoung-Ju Choi! Search Search Recommended Movies Recommended Movies X XX XXX A B C D Examine queue (Warning: Queue empty) Examine queue View account View account Frequent customer bonus How can we ensure the reliability of this type of system? June 2003 © Offutt 1999-2003. All Rights Reserved. 35 Problems for Practitioners Fun for Researchers • How to write requirements and specifications for web software services? • How to design and model web software? • How to test loosely coupled software whose control flow is determined dynamically? • How to safely and reliably perform maintenance? • How can existing software development processes be adapted to this new type of software? June 2003 © Offutt 1999-2003. All Rights Reserved. 36
  • Integration Testing of Loosely Coupled Software Integ XML Test June 2003 © Offutt 1999-2003. All Rights Reserved. 37 Testing Loosely Coupled Software • Unit and module may not be affected • Software integration, however, is completely different • Previous integration testing strategies focused on couplings among the software components – Couplings were analyzed by looking at implementation – But source is often not available for web components! • The essential part of integration is how the software components communicate June 2003 © Offutt 1999-2003. All Rights Reserved. 38
  • Communicating in Loosely Coupled Systems • In traditional software, components and component authors negotiate details about structure of data that is exchanged – Types – Formats – Order • This is difficult in extremely loosely coupled software – Authors cannot communicate – Components may not know who they interact with until execution time • XML is a standard that allows data items to be exchanged: – Independent of type – Without regard to format – In arbitrary order • XML tags allow components to infer information about type, format and order June 2003 © Offutt 1999-2003. All Rights Reserved. 39 The Problem Context Web Component A Request XML message from A Web Component B HTTP Response XML message from B • Heterogeneous web software interactions • Components communicate by using an agreed upon standard for data exchange – XML Testing: A technique to check interaction: Interaction Data Diversity (IDD) June 2003 © Offutt 1999-2003. All Rights Reserved. 40
  • Example XML Document and its DTD <?XML version = "1.0"> <AUTHORIZED_USERS> <AUTHORIZED_USER> <USER_ID>steffi</USER_ID> <PASSWORD>sso</PASSWORD> </AUTHORIZED_USER> </AUTHORIZED_USERS> <!ELEMENT AUTHORIZED_USERS (AUTHORIZED_USER) * > <!ELEMENT AUTHORIZED_USER (USER_ID, PASSWORD)> <!ELEMENT USER_ID (#PCDATA)> <!ELEMENT PASSWORD (#PCDATA)> June 2003 © Offutt 1999-2003. All Rights Reserved. 41 Interaction Data Diversity (IDD) Analysis • Traditional mutation analysis: – modifies the program source – is primarily used for unit and module testing – uses test cases that are input values to program units • Interaction data diversity: – modifies the of web service data interactions (the messages) – is used for integration testing of web software components – test cases are XML messages between web software components • IDD creates test cases as XML messages from the XML grammar description (DTDs) June 2003 © Offutt 1999-2003. All Rights Reserved. 42
  • Current Constraints • notMemberOf : Data value not in the valid set of values • relationOf : Data values related with each other through a relational operator (>, <, =, , , ) • mapOf : Data value meet a specific syntax mapping June 2003 © Offutt 1999-2003. All Rights Reserved. 43 IDD Illustration Web request Execute T Web Component Interaction I Component C1 C2 response DD request Interactions Generates Interaction Execute T DD Web DD Interactions Web I1, I2, … Data Diversity Component Interactions I1, I2, … Component System C1 I1, I2, … C2 response (IDDS) Interaction Data Diversity Operators June 2003 © Offutt 1999-2003. All Rights Reserved. 44
  • ISM Example <-- DTD for Computer Accounts --> <!ELEMENT USER_ID (#PCDATA)> <!ELEMENT PASSWORD (#PCDATA)> <!-- Collection of authorized users --> <!ELEMENT AUTHORIZED_USERS (AUTHORIZED_USER) * > <!ELEMENT AUTHORIZED_USER (USER_ID, PASSWORD)> <!-- XML request sent, SignOn A --> <!ELEMENT SIGNON_REQUEST (USER_ID, PASSWORD)> <!-- XML response sent, Authenticate B --> <!ELEMENT SIGNON_RESPONSE (USER_ID)> <!ATTLIST SIGNON_RESPONSE AUTHENTICATION (ALLOW | DENY) #REQUIRED> June 2003 © Offutt 1999-2003. All Rights Reserved. 45 Example: Authentication Web Component A Request XML message from A Web Component B HTTP Response XML message from B • User login authentication for A is provided by B • A sends XML message requesting B to authenticate a user • B responds to A with an XML message Request Message Response Message <SIGNON REQUEST> <SIGNON RESPONSE <USER ID>steffi</USER ID> AUTHENTICATION="ALLOW"> <PASSWORD>sso</PASSWORD> <USER ID>steffi</USER ID> </SIGNON REQUEST> </SIGNON RESPONSE> June 2003 © Offutt 1999-2003. All Rights Reserved. 46
  • Use notMemberOf to Modify Request Message (Joyce, sso) is notMemberOf authorized user database Modified Request Message Response Message <SIGNON REQUEST> <SIGNON RESPONSE <USER ID>Joyce</USER ID> AUTHENTICATION="DENY"> <PASSWORD>sso</PASSWORD> <USER ID>Joyce</USER ID> </SIGNON REQUEST> </SIGNON RESPONSE> Response is different from that of original message, so software succeeds June 2003 © Offutt 1999-2003. All Rights Reserved. 47 Use relationOf to Modify Request Message “sso” != “ysma” Modified Request Message Response Message <SIGNON REQUEST> <SIGNON RESPONSE <USER ID>Steffi</USER ID> AUTHENTICATION="ALLOW"> <PASSWORD>ysma</PASSWORD> <USER ID>Steffi</USER ID> </SIGNON REQUEST> </SIGNON RESPONSE> Response is same as that of original message, so test has found a failure!! June 2003 © Offutt 1999-2003. All Rights Reserved. 48
  • Use mapOf to Modify Request Message USER ID is alphanumeric Modified Request Message Response Message <SIGNON REQUEST> <SIGNON RESPONSE <USER ID>;Steffi&</USER ID> AUTHENTICATION=“DENY"> <PASSWORD>sso</PASSWORD> <USER ID>Steffi</USER ID> </SIGNON REQUEST> </SIGNON RESPONSE> Response is different from that of original message, so software succeeds June 2003 © Offutt 1999-2003. All Rights Reserved. 49 Testing the Dynamic Flow of Control Atomic Sections June 2003 © Offutt 1999-2003. All Rights Reserved. 50
  • Testing Software with Dynamic Flow of Control • Dynamic web pages are created when users make requests • Technologies include servlets: – A request is sent with a list of parameters – The servlet performs some computation, perhaps using other components such as databases and beans – The servlet returns results to the client as a web page – The web page includes Javascript, buttons, and form fields • The program the user interacts with changes dynamically – Javascript, buttons, and fields on the client can change anytime – The software components the servlet interact with can change any time Control flow graphs cannot be created statically June 2003 © Offutt 1999-2003. All Rights Reserved. 51 Variant and Invariant Portions • The web pages can vary • From the users' perspective, each user can interact with a different program • Unlike traditional software, we cannot determine potential flows of control before execution • But all the pieces of the web pages and the programs are all contained in the software • The pieces are invariant, but the way they are combined varies June 2003 © Offutt 1999-2003. All Rights Reserved. 52
  • Atomic Sections A section of HTML including scripts) such that if part of the section is sent to a client, the entire section is (all or nothing property) • A static web page file (HTML and Javascript) or • A piece of a web page file generated by a program – Can be an HTML section or – HTML with a static structure and content variables – A content variable provides data to the web page, but not structure • Can be extracted from code June 2003 © Offutt 1999-2003. All Rights Reserved. 53 Atomic Section Example PrintWriter out = response.getWriter(); P1 = out.println ("<HTML>") out.println ("<HEAD><TITLE>" + title +“ </TITLE></HEAD>)" out.println ("<BODY>") for (int i=0; I < myVector.size(); i++) Atomic if (myVector.elementAt(i).size > 10) sections P2 = out.println("<P><B>" + myVector.elementAt(i) + "</B></P>"); else P3 = out.println ("<P>" + myVector.elementAt(i) + "</P>"); P4 = out.println ("</BODY></HTML>"); out.close(); Content June 2003 © Offutt 1999-2003. All Rights Reserved. variables 54
  • Composite Sections A composite section is composed of atomic sections combined with the following rules: • Basis: p is an atomic section • Sequence (p p1 p2) : p is composed of p1 followed by p2 • Selection (p p1 p2) : p is either p1 or p2, but not both • Iteration (p p 1 *) : server selects repeated copies of p1 • Aggregation (p p1 {p2} ) : p2 is contained inside p1 June 2003 © Offutt 1999-2003. All Rights Reserved. 55 Modeling Web Pages • Web pages are modeled as composite sections combined with the three rules and regular expressions • The previous example produces: p p1 (p2 | p3)* p4 • The composite section models for web software components can be produced automatically • Web software components also communicate with each other, which is modeled with transitions June 2003 © Offutt 1999-2003. All Rights Reserved. 56
  • Transitions Among Web Components There are three types of transitions: 1. Link Transition (p q1 | q2 | … ) : A transition from one composite section to another 2. Composite Transition (s = p1 | p2 | … ) : A transition from a servlet to one of the composite sections it produces 3. Operational Transition (p q) : A transition that the user imposes on the software, using the back button, refresh, or URL rewriting June 2003 © Offutt 1999-2003. All Rights Reserved. 57 Web Service Application Model • A web application is modeled as a quintuple { S, C, T, AS, CS }: – S: Start page – C: Set of composition rules for each component – T: Set of transition rules among the components – AS: Set of atomic sections – CS: Set of composite sections • Tests are created by deriving sequences of transitions among the web software components and composite sections June 2003 © Offutt 1999-2003. All Rights Reserved. 58
  • Example • GradeServlet login reports grades to students – S = { index.html } – C = {GradeServlet = p1 ((p2 p3*) | p4) p5, SendEmail = …} – T = { S GradeServlet, GradeServlet.p4 (SendEmail | GradeServlet) } • Test derivations – S GradeServlet p1 p2 p3 p5 – S GradeServlet p1 p4 p5 – S GradeServlet p1 p4 p5 SendEmail … – S GradeServlet p1 p4 p5 Previous S GradeServlet p1 p4 p5 June 2003 © Offutt 1999-2003. All Rights Reserved. 59 System Testing Web Software Applications System Test June 2003 © Offutt 1999-2003. All Rights Reserved. 60
  • Application Testing • Three aspects need testing: 1. Single functions local to web pages 2. Navigation among web pages 3. State dependent behavior on web pages • Web applications are modeled with finite state machines – FSMs can lead to a state space explosion June 2003 © Offutt 1999-2003. All Rights Reserved. 61 Modeling Web Applications • Partitioning Web Applications – Subsystems – FSM for each subsystem – Major functions • FSMs for each subsystem • Test sequences for combined subsystems June 2003 © Offutt 1999-2003. All Rights Reserved. 62
  • Logical Web Pages • Logical web page (LWP): A portion of a web page that offers a specific service to the users – Login section – Single form – Search box • Individual web pages may contain several LWPs • LWPs are the fundamental element of our model June 2003 © Offutt 1999-2003. All Rights Reserved. 63 Partitioning Web Applications • Components: Sets of web pages that implement a single logical function • Subsystems: Groups of components and individual web pages that together implement a major function • Components and subsystems are derived from: – User level functionalities – Navigation layout – Couplings among components • Clusters: Collections of one or more components that together form a cohesive functional unit June 2003 © Offutt 1999-2003. All Rights Reserved. 64
  • Cluster Finite State Machines • Cluster Finite State Machines (CFSM): A finite state model of the behavior of the cluster • Nodes: derived from subsystems and components • Edges: represent navigation among pages • Result: A collection of independent finite state machines that are: – Small enough to generate test sequences from – Clearly define the information that propagates among CFSMs June 2003 © Offutt 1999-2003. All Rights Reserved. 65 Aggregate Finite State Machines • Aggregate Finite State Machines (AFSM): A finite state model of the high-level aggregate behavior of the web application • Nodes: Each cluster is one node • Edges: navigation points among clusters • Result: A high level abstract FSM that models the overall behavior of the web application June 2003 © Offutt 1999-2003. All Rights Reserved. 66
  • Testing CFSMs & AFSMs • Traditional graph testing criteria are applied: – Transition coverage: Find values that cause each transition in each FSM to be covered – Transition-pair coverage: Find values that cause each pair of transitions to be covered • Applied at both the cluster and aggregate FSM level June 2003 © Offutt 1999-2003. All Rights Reserved. 67 Future Methods and Technologies Future ??? June 2003 © Offutt 1999-2003. All Rights Reserved. 68
  • Technology Predictions for 2010 • 1990: Internet, Command-based email, FTP • 2000: A Web-based world It would be foolish to make 10 year predictions about the web! June 2003 © Offutt 1999-2003. All Rights Reserved. 69 Needs for Modeling & Testing Web Applications • High level design patterns for Web applications – Model-View Controller (MVC) is helpful but more are needed • Modeling languages for describing Web applications – UML is insufficient • Analysis techniques that handle: – Session data – Dynamic integration with web services • Techniques for performing maintenance and regression testing • Best practices for detailed design and implementation • Better education among developers! June 2003 © Offutt 1999-2003. All Rights Reserved. 70
  • Open Issues in Web Testing • Precise criteria for generating transition sequences • Translating sequences to inputs is hard: – User inputs – State on the server • Checking the results requires checking the output web pages and changes to state on the server • Testing session management issues • Interactions among multiple users • Guidelines for developing safe inheritance hierarchies • Guidelines or standards for safe use of polymorphism June 2003 © Offutt 1999-2003. All Rights Reserved. 71 Relevant Papers on My Web Site http://www.ise.gmu.edu/~ofut/ • OO: www.ise.gmu.edu/~ofut/rsrch/abstracts/integ.html • Web: www.ise.gmu.edu/~ofut/rsrch/abstracts/web.html June 2003 © Offutt 1999-2003. All Rights Reserved. 72