Scope of the Dissertation

Web  applications  are  accessed  by  navigation  mechanisms  implemented  by  hyper‐links.  Focusing  in  the  client‐side  of  a  web  application,  the  interaction  is  reduced  on  web  browser  using  HTTP  to  a  remote  server.  Thus,  focusing  on  the  navigational  nature  of  the  Web,  such  applications can be seen as a set of web states: 

(II) , , … ,  

Each  web  state  is  composed  by  a  set  of  elements   that  can  be  accessed  with  the  API  Document  Object  Model  (DOM).  The  nature  of  such  elements  is  heterogeneous,  and  it  is  identified  by  its  Internet  media  type,  originally  called  MIME  (Multipurpose  Internet  Mail  Extensions)  type.  A  complete  list  of  the  different  kinds  of  MIME  types  can  be  found  on  the  W3Schools  web  site13.  IANA  (Internet  Assigned  Numbers  Authority)  manages  a  registry  of  these types. The list of such types is available on its web site14, and it is summarized as follows:  ‐ Application:  For  multipurpose  elements,  for  example:  application/javascript, 

application/json, application/zip, and so on.  ‐ Text: For example, text/html, text/css, and so on.  ‐ Image: For example, image/gif, image/jpg, and so on.  ‐ Audio: For example, audio/mpeg, audio/ogg, and so on.  ‐ Video: For example, video/mpeg, video/mp4, and so on.  ‐ Message: For example, message/http, message/rfc822, and so on.  ‐ Model: For 3D model, such as model/vrml, model/iges, and so on. 

‐ Multipart:  For  archives  and  other  objects  made  of  more  than  one  part.  For  example,  multipart/mixed, multipart/encrypted, and so on. 

‐ Vnd: For vender‐specific files, for example application/msword.  ‐ X: For non‐standard file, such as application/x-latex. 

‐ X‐PKCS:  For  PKCS  (Public‐Key  Cryptography  Standards)  files,  for  example  application/x-pkcs7-mime. 

The following equation represented a state composed by a set of elements:  

(III) , , … ,  

The most important kind of elements will be those based on text, since in this kind of elements  are  contained  the  HTML  elements.  HTML  elements  can  contains  web  forms,  which  are  the  elements which contains data to be submitted to server. 

13 _{http://www.w3schools.com/media/media_mimeref.asp} 14 _{http://www.iana.org/assignments/media‐types/index.html}

Given a web application, its navigation always has an entry state. This state is identified by its  URL,  and  the  following  states  are  connected  by  means  of  transitions.  Therefore,  in  order  to  know a navigation of a web application, it should be known the entry point (an URL) and the  sequence of transitions among the following states. In other words, it is not necessary to know  each URL of the states after the first one to model the navigation of a web application. Each  web  transition  is  composed  by  a  sequence  of  atomic  actions ∝ .  Examples  of  atomic  actions  could  be  clicking  a  link,  moving  the  mouse  over  some  HTML  element,  and  so  on.  The  factor  that  distinguishes  a  transition  is  the  fact  that  when  the  set  of  atomic  actions  in   is  performed,  as  a  result  a  HTTP  request  from  the  client  to  the  server  is  triggered.  This  HTTP  request will result in a HTTP response that will change the state to . All this information is  summarized in the following equation: 

(IV) ∝ , ∝ , … , ∝ |  

These  actions  are  based  on  the  DOM  event  specified  by  the  W3C15.  The  following  table  summarized such events:  Table 7. Literals for Actions in Web Transitions  Literal  Description  blur _{An element loses focus}  change _{The content of a field changes}  click _{Mouse clicks an object}  dblclik _{Mouse double‐clicks an object}  error An error occurs when loading a document or an image  focus An element gets focus  keypress _{A keyboard key is pressed}  keydown _{A keyboard key is pressed or held down}  keyup _{A keyboard key is released}  load _{A page or image is finished loading}  mousedown A mouse button is pressed  mousemove The mouse is moved  mouseout The mouse is moved off an element  mouseover The mouse is moved over an element  mouseup _{A mouse button is released}  resize _{A window or frame is resized}  select _{Text is selected}  unload _{The user exits the page}  All in all, in this dissertation I am going to employ the following metamodel to represent web  applications. This metamodel implements the concepts depicted in equations II, III, and IV:         15 _{http://www.w3.org/TR/DOM‐Level‐2‐Events/events.html}

5.2. Approach

The approach I propose to automate the functional testing for web applications can be seen as  an aggregation of the following automated methods (depicted in the state‐of‐the‐art in section  2.5): 

‐ R&P.  Linear  scripts  using  a  record  and  playback  method  is  used.  This  approach  is  considered the 1st generation of AST frameworks. 

‐ Data‐driven approach (2nd generation). This testing approach means that using a single test  case driving the test with input and expected values from an external data source instead  of using the same hard‐coded values each time the test runs. 

‐ MBT (3rd generation). UML (use cases, activity, and presentation diagram) and XML models  from  analysis  and  design  phases  in  the  SDLC  will  be  reused  in  order  to  guide  the  automation.  

In order to achieve the data‐driven approach, the automation will mean the separation of the  test  case  and  test  data/expected  outcome  generation.  Test  cases  will  be  generated  using  a  programming language to be defined in section 7. In order to store the test data and expected  outcome a tabular data file will be used. The template of this file will be as follows: 

Table 8. Test Data and Expected Outcuome Template 

Test data (input)  Expected outcome (output) 

_   _   …  _ _ _ …  _

data1_1  data2_1  …  datan_1  outcome1_1  outcome2_1  …  outcomem_1 

data2_1  data2_2  …  datan_2  outcome2_1  outcome2_2  …  outcomem_2 

…  …  …  … 

This  template  can  be  seen  as  the  implementation  of  a  decision  table,  which  is  one  of  the  methods described in the state‐of‐the‐art section regarding automated test oracles (see Table  3 on section 2.5.3). Each input and output element ( _  and  _ ) is located in  the web pages using the pseudocode depicted in Snippet 2. Each file of data of the table will be  automatically filled during the process of test case generation.  

All in all, the method I propose to perform automated functional testing for web applications  has one strong prerequisite:  there should be a model of the navigation behaviour of the web  under test.  As depicted before, this navigational model is one of these three notations:  UML  (using  NDT),  or  XML,  or  R&P.  This  requisite  is  illustrated  in  the  red  box  labelled  as  pre‐ automation in Figure 23. 

Once test cases for the navigation paths are generated, additional input and output data can  be  manually  added  to  drive  more  test  cases  with  the  same  test  logic.  These  data  (input  and  output)  can  be  stored  as  new  files  in  the  tabular  file  as  depicted  in  Table  8.  This  process  is  shown schematically in the yellow box labelled as post‐automation in Figure 23. 

Regarding test case generation, the automation is done within the test implementation level of  the  testing  process  depicted  in  the  methodology  (see  chapter  4,  Figure  16).  Therefore,  the 

  automatic test case generation implies three different stages: i) Test logic generation; ii) Test  data generation; iii) Test oracle generation.   Test logic generation is illustrated in the green box (labelled as “logic”) in Figure 23. This step  takes as input the model from the pre‐automation stage, i.e. a model in UML, or XML or R&P.  This logic generation pass through the following steps: 

‐ White‐Box  Parser.  This  entity  is  in  charge  of  translating  the  different  models  used  for  testers (UML, XML, or R&P) to the internal way of modelling web applications.  ‐ As depicted in the methodology, graph theory is employed to handle the navigation of the  web under by means of multidigraphs.  ‐ Paths. Some algorithm or method (to be depicted in section 5.4) should be used to find the  set of independent paths in the navigation. These paths correspond to a sequence of web  pages that should be exercised against the SUT to ensure the navigation requirements.  Test  data  generation  is  illustrated  in  the  purple  box  (labelled  as  “data”)  on  Figure  23.  This  stage is also fed with the navigation model from the pre‐automation stage. The process is as  follows: 

‐ Black‐Box  Parser.  This  module  extracts  test  data  and  expected  outcome  from  the  input  model. As depicted in section 5.2, XML models can include test data and R&P models can  include test data and expected outcome. Regarding test data (input), this black‐box parser  should extract the value and the data type.   ‐ Data type will feed a test data dictionary. This dictionary contains a collection of data that  can be used as input for test cases. For the selection of specific value, besides the type of  data, a module that generates a random pointer will be used (randomizer).  ‐ Therefore, the data required for the test cases consist on the aggregation of three different  sources: i) Data from the XML and R&P models; ii) Randomly generated data from on a test  data  dictionary;  iii)  Manual  data  included  as  new  rows  in  the  tabulated  file  (post‐ automation). 

Test  oracle generation is illustrated in the green box (labelled as “oracle”) on Figure 23. This  module has the following parts: 

‐ Outcome  analyser.  This  module  collects  data  from  the  response  of  the  SUT  and  extracts  the following information: i) Navigation state; ii) Actual data returned by the application. In  order to find out the real state navigation, the aggregation of data field will be used.   ‐ White‐Box  Oracle.  This  module  will  establish  verdicts  by  comparing  the  expected  to  the 

current state. The expected state is set by the navigation path previously extracted in the  test  logic  module.  The  real  state  is  extracted  from  the  SUT’s  response  by  the  outcome  analyser using the procedure described before (aggregation of data fields). 

‐ Black‐Box  Oracle.  This  module  will  establish  verdicts  by  comparing  expected  with  actual  data.  The  expected  data  comes  from  the  black‐box  parser  of  the  test  data  module.  In  addition,  additional  expected  data  can  be  added  in  the  post‐automation  stage  by  adding  new information in the tabular file depicted in Table 8. 

Figure 23. Automated Functional Testing Schematic Diagram 

The key piece in the presented approach is a block which has been named Browser. This entity  can  be  seen  as  the  conductor  of  the  automation.  It  has  as  input  the  test  data  and  the  information about the paths, i.e. the set of states to be traversed and the transition between  these states. Thus, the browser is in charge of performing the navigation using a real browser  by exercising the client‐side of the web under test using the path information and test data. As  a result, the web under test returns the real value of the navigation in terms of functionality  (output  data)  and  structure  (navigation  states).  Therefore,  the  automated  verification  performed by the browser element is summarized as follows: 

‐ State  verification:  This  verification  is  two‐folded.  On  one  hand,  the  navigation  is  ensured  (white‐box,  i.e.  structural  testing).  To  achieve  that  aim,  each  state  is  validated  as  the  aggregation  of  the  defined  test  data.  For  this  reason,  the  existence  of  each  defined  test  data is ensured. Moreover, as depicted in section 5.1, a web state is composed by a set of  elements  (e.g.  frames,  images,  and  so  on).  Therefore,  each  element  in  the  DOM  of  each  state is checked. On the other hand, the functionality is ensured (black‐box, i.e. functional  testing). Thus, each test oracle is assessed using the expected values against the real data.  ‐ Transition verification: As depicted in section 5.1, each transition is composed by a set of 

actions (e.g. mouse over an element and then click on a link). These actions are composed  by some locators and which are assessed and exercised. In addition, before executing the  transition  there  could  appear  JavaScript  notifications.  These  warnings  are  captured  in  order to complement the report to be generated.