Scheduling Tests for Mobile Application Targets¶
The next page is where you specify information such as the date on which the test will begin to run and any files necessary for running the test.
The Main Schedule Page Controls¶
An asterisk (*) indicates a required field.
Deployment Type* : Choose one of the following:
- **Production**
- **Staging/Testing**
- **Staging - Connected to Production**
If you choose **Production** or **Staging - Connected to Production**, you must specify at least one point of contact in the Point of Contact Information section, later on this same page.
Type of Test* : Choose one of the following:
- **Intrusive** \(for DAST\) or **Intrusive - Comprehensive Coverage** \(for PT\)
An *intrusive* test covers an optimal set of test cases and increases the risk \(compared to a non-intrusive test\) of adverse effects on your data or application.
If you choose an intrusive test for a production system, we *strongly recommend* that you take preventative measures to mitigate any business risk from the adverse effects of your data or application.
- **Non-Intrusive - Limited Coverage** \(for PT\)
A *non-intrusive* test covers the same set of test cases as an intrusive test. However, if a vulnerability is found, the test will not execute an attack. This is because the test might be too risky to run on a live production environment.
Is Fixed Test* : Marking a test as Fixed ensures that the scheduled date for this test is not affected by the rescheduling of other tests due to Gantt or Calendar operations.
You *can* change the scheduled date of a fixed test by using the **TEST > Test Info** page.
Schedule Date* : Use the pop-up calendar to choose a start date for the test.
For a 3D service, the calendar does not let you choose dates that are reserved for another scheduled test \(3D services only support one test at a time\).
For any type of service, 3D \(unlimited\) or limited, the calendar does not let you choose dates that do not allow a 2-day lead time for testing Production deployments. On the calendar, available dates are outlined, while unavailable dates are grayed out.
Based on the start date, the calendar automatically reserves the number of business days required to complete the test for the selected assessment type. For example, the Mobile Application Testing Standard \(Mobile-S\) assessment type requires 7 business days and the Mobile Application Testing Comprehensive \(Mobile-C\) assessment type requires 12 business days.
Calendar pop-up for choosing a test date
Test Window : (Optional) Although typically it is not necessary, if you want to you can specify a test window. A test window restricts the time in which the test can take place.
A test window can be useful for certain testing scenarios on Production environments; for example, if you want to restrict the time during which testing generates network traffic.
The first drop-down menu sets the start time \(that is, the time the test will trigger\). This overrides the default trigger time of 09:00 A.M.
The second drop-down menu sets the duration of the test window, which can be from 8 to 23 hours.
For example, choosing a start time of 10:00 A.M. and a duration of 8 hours results in a test window from 10:00 A.M. to 6:00 P.M.
Demo Call : A Demo Call date is set before a scan's Schedule Date, so that demos and scoping forms are reviewed before a test is run.
Demo call dates should be set to later than the current date and before the test's **Schedule Date**.
Labels : (Optional) In this field, you can add labels to identify your tests. These labels are searchable.
Application Type* : Auto-filled. Shows the operating system for this target: Displays either ANDROID or IOS.
\(While an app can be available for both platforms, a target tests only one of them at a time.\)
Target Description : (Optional) Provide a description of the application (1,000 character maximum).
Device Type* : (iOS only) For an iOS app, choose either iPhone or iPad.
UDID Details* : (iOS only) This field is auto-filled with a Unique Device Identifier (UDID) for the selected device.
Test Comments : (Optional) If you wish, you can enter comments here about the deployment and schedule for the test.
Please provide .apk|.ipa file details : (An APK file is an Android Application Package. An IPA file is an iOS App Archive.)
Leave UPLOAD FILE chosen to use the **File Set** controls to upload your source code. Choose PASTE FILE URL FOR DOWNLOAD to provide the address of a page that contains the app source. \(The **File Set** controls remain active so you can upload supporting documents.\)
When you choose PASTE FILE URL FOR DOWNLOAD, a field appears where you can type in the URL.
File Set : (Optional) Click the +Upload files button to upload supporting documents or information that might be relevant to the test.
After you upload a file, choose its Asset Type: either **Binary** or **Supporting Documents**. Every file in the set of uploads that has an Asset Type of **Binary** will be tested.
**Important:** IPA or APK binary files must be uploaded individually, and *not* as part of a ZIP or JAR archive.
These file formats are supported:
- Archive formats, such as `.zip` and `.jar`
- `.ipa` or `.apk`
- Any kind of file type if it is provided within an archive
The maximum file size is 300 megabytes per file. A maximum of ten files can be uploaded per test. There are no restrictions on the number of files that can be included within each archive file.
Note: After you schedule a test, you can change the uploaded file set at any time before the test completes.
When you click +Upload files, this page displays a dialog for uploading one or more files.
Click Choose Files to choose a file to upload, then click Upload to upload the file, and then click Close when you are done.
Important: Be sure to click Upload before you click Close. If you choose a file but then immediately click Close, the file is not uploaded.
Remote End Points¶
These controls do not appear unless you have chosen either Mobile–C testing that uses a 3D service, or Mobile-C testing that uses a Mobile Application Test (One Time) service.
Does your application have Remote End Point(s)?* : For a Mobile–C test that uses a 3D service, this answer is always YES and cannot be changed.
For a Mobile test that uses a one-time service, you can choose either YES or NO. If you choose YES, and the Type of Test and Deployment Type entries were not visible before, they appear now at the top of the form, and you must fill them in.
Q1: Do you want to test Remote End Point(s)?* : For a Mobile–C test that uses a 3D service, this answer is always YES and cannot be changed.
For a Mobile test that uses a one-time service, you can choose either YES or NO.
Remote End Point* : Provide a remote end point domain or IP port.
Here are some sample formats:
```
172.121.11.4:8798
example.net/vod/mp4:BigBuckBunny_115k.mov
```
Protocol Used* : Choose HTTP, HTTPS, or OTHERS.
Others:* : (Required if you responded OTHERS to the Protocol Used question.)
Specify the protocols that your app uses. If there is more than one, enter a list with entries separated by commas; for example, `"FTP,SMTP"`.
Add Remote End Point : Important: After you fill in the End Point domain name or port value, and specify the protocol, you must click this button to add the end point information to the list above.
If your app uses more than one end point, you can fill in the End Point and Protocol fields and then click this button to add the next end point to the list.
Point of Contact Information¶
Specify a point of contact (POC) who will approve the running of your test. For more information about this section of the form, see "Point of Contact Information on the Schedule Page" in the Managed Services Platform Guide.
Parent topic:Scheduling Tests for Mobile Application Targets
Related information