-
Notifications
You must be signed in to change notification settings - Fork 479
Naming conventions
As described in the "Running tests" section, there are three categories for the tests: framework, plugin and testing_framework. These categories correspond to folders with the same names in the test_cases directory.
- Framework: in this directory there are tests related to the OWTF framework components, such as DB, config, etc.
- Plugin: in this directory there are tests for the OWTF plugins (web, net, aux). Each test type is in its own module. For example, there is a separated module for web tests, net tests, etc.
- Testing_framework: in this directory there are tests for the features of the testing framework itself. Tests for doubles, test cases, servers, etc. are in this folder.
The module names are normally the name of the tested module with the "_tests.py" suffix. The class names are the same as the module names, but in CamelCase format. For example, for the config module, we will name the test module as "config_tests.py" and the test class will be ConfigTests.
The test names begin with the prefix "test_", adding the description of the test, replacing the spaces by the underscore symbol (_). For example, this could be the name of a test: test_that_this_feature_works. If we have to write a test for a plugin, the name should be: test_ + plugin_name + _plugin_type. For example: test_Spiders_Robots_and_Crawlers_passive. In general, try to write method names that describe clearly its purpose.
This wiki and the OWTF README document contains a lot of information, please take your time and read these instructions carefully.
We provide a CHANGELOG that provides details about almost every OWTF release.
Be sure to read the CONTRIBUTING guidelines before reporting a new OWTF issue or opening a pull request.
If you have any questions about the OWTF usage or want to share some information with the community, please go to one of the following places:
- IRC channel
#owtf(irc.freenode.net)
Google Summer of Code 2018 Guide
Installation
Getting Started
- Define where your tools are
- Run OWASP OWTF
- HTTP Auth Configurations
- Simulation mode
- AUX plugins usage
- FAQ
SET usage
Cookbooks (GSoC 2014 Projects UPDATE)
-
Zest Integration:
- Quick Guide to get started with Zest,ZAP and Replay
- Zest and ZAP API Installation
- Zest and ZAP integration Introduction
- Zest Runner module
- Forward HTTP request to ZAP
- Zest script creation from single HTTP transaction
- Zest script creation from multiple HTTP transactions
- Zest Script Creator module
- HTTP Request Editing Window (Replay Function)
- Zest Script Recording Functionality
- Zest scripting console
Development
-
Plugins:
-
Tests:
Contact