Generating Software Tests (Security Testing) Andreas Zeller + Rahul Gopinath


Project 2 - Summary of What Was Discussed Today

Written: 10.12.2019 22:12 Written By: Michael Mera

Dear Students,

I want to summarize the main points that were discussed during the lecture today regarding part II of project 2, to make it (hopefully) clear for everyone what you are allowed to do or not.

The fragments mutator:

  • uses fragments. A fragment can be anything you want: tag names, tags, attributes, CSS properties, ... It is defined more generally as a part of the seed.
  • cannot insert any new things, only recombine and reorder fragments
  • can use an external parser (lxml, ...) rather than a grammar + Earley parser to gather the fragments from the seeds.
  • can store fragments internally in any format you want (e.g. lists, etrees, ...)

The characters/bytes mutator:

  • cannot insert structured elements into the seeds (e.g. NO TAGS: no '<a></a>')
  • can use static dictionaries of keywords to insert interesting values: html tag names (e.g. 'html', 'body', 'table'), CSS property names ('border', ...), CSS property values ('auto', ...)
  • is not allowed to parse the structure of the seed. To give a more precise idea of what is allowed, I will consider it OK to look for single characters ('<', '>', '{', ...) to locate interesting insertion or deletion points in the seed. The consequence is that you can find start/end of tags but you cannot, for example, look for matching tags (e.g. find the pair <a>...</a> as you would need to match more than one character for that).

Obviously, in terms of style points, projects that give a general solution will be preferred over the ones only clustering a huge list of tags and CSS properties together from a dictionary of static keywords. If you already have a solution covering the minimum number of lines and it does not rely on a static dictionary of keywords, it is better for you in terms of grades to submit that rather than adding such dictionaries and gain a few hundred lines of code coverage.

Of course if you think you have a wonderful idea leveraging a static dictionary of keywords, you can also go for that. In that case, do not forget to include an explanation of why you think this is a great idea. In each part of the project you have the opportunity to explain in a paragraph (or a bit more) why you think your approach is interesting!

If after this it is still not clear for you if you can do something or not, do not hesitate to ask questions.

Privacy Policy | Legal Notice
If you encounter technical problems, please contact the administrators