Running NF Test Cases Using ATS

4 Running NF Test Cases Using ATS

This section describes how to run NF test cases using ATS. It includes:

4.1 Running BSF Test Cases using ATS

This section describes how to run BSF test cases using ATS.

Note:

Restart the NRF-client pod of BSF for UDR and CHF discovery as part of each test case.

4.1.1 Prerequisites

To run Binding Support Function test cases, ensure that the following prerequisites are met:

Deploy BSF 25.2.200 with default helm configurations using helm charts to run all test cases. The ATS version must be compatible with BSF 25.2.200.
For more information on how to install BSF, see Oracle Communications Cloud Native Core, Binding Support Function Installation, Upgrade, and Fault Recovery Guide.
Go-STUB must be installed in the same namespace where ocbsf is installed.

Add the following to Kubernetes namespace to grant role access:


PolicyRule:
  Resources               Non-Resource URLs  Resource Names  Verbs
  ---------               -----------------  --------------  -----
  pods/log                []                 []              [get list]
  configmaps              []                 []              [watch get list delete update create]
  pods                    []                 []              [watch get list delete update create]
  secrets                 []                 []              [watch get list delete update create]
  services                []                 []              [watch get list delete update create]
  deployments.apps        []                 []              [watch get list update]
  replicasets.apps        []                 []              [watch get list update]
  deployments.extensions  []                 []              [watch get list update]
  replicasets.extensions  []                 []              [watch get list update]

ATS Prometheus metrics validation works only when:
- the metrics suffixes are not configured
- installation has a single pod for each microservice in the BSF deployment
You can customize test cases in the custom test case folders (cust_newfeatures, cust_regression and cust_performance). You can add new test cases, remove unwanted test cases and modify existing test cases. It does not impact the original product packaged test cases available in the newfeatures, regression and performance folders respectively. For more details about custom test case folders, see Custom Folder Implementation.
Install Prometheus server in the cluster.
Database cluster is in the running state with all required tables. Verify that there are no previous entries in the database before running test cases.
Do not initiate a job in two different pipelines at the same time.
For running ATS features, ensure to update the following mandatory parameters in ocbsf_custom_values_25.2.200.yaml file only when you are not using the minimal custom values.yaml file.
```
logging:
  burst:
    rate: 500
    max: 3000
    onMismatch: DENY
    logLevel: DEBUG
```
Note:
Please ensure that you use the latest version of the Custom Values file when installing BSF initially.
For using Controlled Shutdown feature, ensure that enableControlledShutdown parameter is enabled on BSF during installation. If this parameter is not enabled, the test case for this feature will fail.
In the application-config configmap, configure the following parameters with the respective values:
- primaryNrfApiRoot=nf1stub.<namespace_gostubs_are_deployed_in>.svc:8080
  
  For example:
  
  primaryNrfApiRoot=nf1stub.ocats.svc:8080
- secondaryNrfApiRoot=nf11stub.<namespace_gostubs_are_deployed_in>.svc:8080
  
  For example:
  
  secondaryNrfApiRoot=nf11stub.ocats.svc:8080
- virtualNrfFqdn = nf1stub.<namespace_gostubs_are_deployed_in>.svc
  
  For example:
  
  virtualNrfFqdn=nf1stub.ocats.svc
- retryAfterTime=PT30S

To enable ATS BSF GUI with the HTTPS protocol, the above mentioned application-config configmap related following parameters should be configured with the respective values:


# Please edit the object below. Lines beginning with '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  profile: | -
    [appcfg]
    primaryNrfApiRoot=nf1stub.ocats.svc:8443
    secondaryNrfApiRoot=nf11stub.ocats.svc:8443
    nrfScheme=https
    virtualNrfPort=8443
    virtualNrfScheme=https

Before running ATS Test suite, restart nrf-client-nfdiscovery and nrf-client-nfmanagement pods.
- Run the following command to get all the configmaps in your namespace.
```
kubectl get configmaps -n <BSF_namespace>
```
- Edit the alternate route service deployment pointing towards DNS Stub.
  
  Run the following command to get searches information from dns-bind pod to enable communication between Alternate Route and dns-bind service.
```
kubectl exec -it <dns-bind pod> -n <NAMESPACE> -- /bin/bash -c 'cat /etc/resolv.conf' | grep search | tr ' ' '\n' | grep -v 'search'
```
  Example:
  
  Figure 4-1 Editing Alternate Route Service deployment pointing towards DNS Stub
  
  By default, Alternate Route Service points to CoreDNS.
  
  Figure 4-2 Alternate Route Service settings in deployment file
  
  Change the deployment file to add following content in alternate service to query DNS stub.
```
kubectl edit deployment ocbsf-occnp-alternate-route -n ocbsf
```
  - Add the nameservers IPaddress.
  - Add all the search information.
  - Set dnsPolicy to None.
```
dnsConfig:
  nameservers:
   - <dns_stub_cluster_ip_address>
   searches:
   - dns-bind search
   - dns-bind search
   - dns-bind search
   dnsPolicy: None
```
    Figure 4-3 dnsConfig
- If Service Mesh check is enabled, create a destination rule to fetch the metrics from the Prometheus. For destination rule to communicate between TLS enabled entity (ATS) and non-TLS entity (Prometheus), Prometheus is kept outside of the service mesh. The rule can be created as follows:
```
kubectl apply -f - <<EOF
 
apiVersion:networking.istio.io/v1alpha3
kind:DestinationRule
metadata:
  name:prometheus-dr
  namespace:ocats
spec:
  host:oso-prometheus-server.ocbsf.svc.cluster.local
  trafficPolicy:
    tls:
      mode:DISABLE
EOF
 
```
  - name: indicates the name of destination rule.
  - namespace: indicates where the ATS is deployed.
  - host: indicates the hostname of the prometheus server.
For Bsf_To_Nrf_Late_Arrival feature file to be executed, nfInstanceId should be configured in Bsf_To_Nrf_Late_Arrival.yaml parameterization file. This nfInstanceId must be the same as the one under BSF nfInstanceId, that is configured during BSF installation. The nfInstanceId must to be configured in ATS UI under pipeline configuration (BSF_NFINSTANCE_ID).
To ensure consistent functioning of ATS related to the audit service, modify the Audit deployment by reducing the value of AUDIT_NOTIFY_SCHEDULER_POLLING_INTERVAL_MILLISEC from 30000 to 1000 (changing from 30 seconds to 1 second).
```
$ kubectl get deploy -n ocbsf | grep 'audit' ocbsf-ocpm-audit-service     1/1     1      1     10h
```
```
$ kubectl edit deploy ocbsf-ocpm-audit-service -n ocbsf
```
The deployment will open. Scroll down until below fields are seen
```
- name:  AUDIT_NOTIFY_SCHEDULER_POLLING_INTERVAL_MILLISEC value: "30000"
```
Update the value of AUDIT_NOTIFY_SCHEDULER_POLLING_INTERVAL_MILLISEC to 1000 if it isn't already.

Application Config map changes for BSF registrations over TLS

To enable TLS communication make the following changes by editing the config map of application-config:

NRF port from 8080 to 8443
nrfScheme to https

Sample:


apiVersion: v1
data:
  profile: |-
    [appcfg]
    primaryNrfApiRoot=nf1stub.ocats.svc:8443
    secondaryNrfApiRoot=nf11stub.ocats.svc:8443
    nrfScheme=https
    virtualNrfPort=8443
    virtualNrfScheme=https

Note:

In the config map of application-config, delete the lines which has supportedDataSetId or secondaryNrfApiRoot strings.

4.1.2 Logging into ATS

Before logging into ATS GUI, it is important to get the worker node external IP and node port of the service, 'ocats-bsf'.

Run the following command to get the external IP for the worker node:

Example:

kubectl get nodes -owide

The output of the command is:

ocbsf-k8s-node-1        Ready    <none>   111d   v1.16.7   192.168.200.26   10.75.152.111   Oracle Linux Server 7.8   4.14.35-1902.303.5.3.el7uek.x86_64   containerd://1.2.10

Run the following command to get the nodeport:

kubectl get svc -n <BSF_namespace>

Example:

kubectl get svc -n ocbsf

The output of the command is:

ocbsf-ocats-ocats-bsf     LoadBalancer   10.233.53.144   10.75.225.49     8080:31944/TCP      19h

To log in to ATS, open the web browser and type the following URL:

http://<Worker-Node-IP>:<Node-Port-of-ATS>

If the 'ocats-bsf' Service has an external IP available, <SVC external IP> can also be used to log in to ATS.

http://<External IP of ATS Service>:8080

Example:

http://10.75.225.49:8080

Running ATS

To run ATS test cases, perform the following steps:

Enter the username as bsfuser and Password as bsfpasswd.
Click Sign in.

Note:
To modify default login password, see Modifying Login Password.

Figure 4-4 Pre-configured Pipelines

On successful log in, users should see the following pipelines:
- BSF-NewFeatures: This pipeline has all the new test cases delivered for BSF 25.2.200.
- BSF-Performance: This pipeline is not operational as of now. It is reserved for future releases of ATS.
- BSF-HealthCheck: This pipeline checks if BSF and ATS are deployed correctly. This shows only when the user has enabled this feature at the time of installing BSF ATS.
- BSF-Regression: This pipeline has all the test cases delivered in BSF ATS - 25.2.100.

4.1.3 Running BSF_NewFeatures Pipeline

BSF_NewFeatures Pipeline

This is a pre-configured pipeline where users can run all the BSF new test cases. To configure its parameters, which is a one time activity, perform the following steps:

Click BSF_NewFeatures in the Name column and then, click Configure in the left navigation pane as shown below:

Figure 4-5 BSF New Feature Pipeline
The BSF_NewFeatures, General tab appears. Make sure that the screen loads completely.
Scroll-down to the end. The control moves from General tab to the Pipeline tab as shown below:

Figure 4-6 BSF New Features Pipeline Configuration
You can change the parameter values from "a" - to - "x" as per user requirement. The parameter details are available as comments from line number 2 - to - 7. In the Script area of the Pipeline section, you can change the values of the following parameters:
- a: Name of the NF to be tested in capital (BSF)
- b: Change this parameter to update the namespace where BSF was deployed in your bastion.
- c: Name of Prometheus service namespace (occne-prometheus-server)
- d: Change this parameter to update the namespace where your gostubs are deployed in your bastion.
- e: Set this parameter as 'unsecure', if you intend to run ATS in TLS disabled mode. Else, set this parameter as 'secure'.
- f: Configure this parameter to set BSF_NFINSTANCE_ID.
- g: Set a value more than 45 seconds for this parameter. The default wait time for the pod to come up is 45 seconds. Every TC requires restart of the nrf-client-management pod.
- h: Set a value more than 60 seconds for this parameter. The default wait time to add a configurations to the database is 60 secs.
- i: Set this parameter to more than 140 secs. The default wait time for Nf_Notification Test Cases is given as 140 secs.
- k: Use this parameter to set the waiting time to initialize Test Suite.
- l: Use this parameter to set the waiting time to get response from Stub.
- m: Use this parameter to set the waiting time after adding BSF Configuration.
- n: Use this parameter to set the waiting time for Peer connection establishment.
- o: Use this parameter to set the waiting time before sending next message.
- p: Use this parameter to set Prometheus Server IP.
- q: Use this parameter to set Prometheus Server Port.
  
  Note:
  If PrometheusAuthEnabled is set to true during ATS installation, then set p and q accordingly.
- r: Use this parameter to set the interval after which the POD status is checked when it is down.
- s: Use this parameter to set number of retry attempt in which will check the pod down status
- t: Use this parameter to set the interval after which we check the POD status if its UP.
- u: Use this parameter to set number of retry attempt in which will check the pod up status.
- v: Use this parameter to set Wait time to connect to Elastic Search.
- w: Use this parameter to set Elastic Search HostName.
- x: Use this parameter to set Elastic Search Port.
- y: Use this parameter to set To Enable/Disable Stub logs collection.
- z: Use this parameter to set Log collection endpoint either Elasticsearch or Kubernetes.
- A: Use this parameter to set Timer to wait for importing service configurations.
- B: Use bulk_import_to_complete to add custom time in Jenkins post bulk imports.
- C: Use this parameter to set TLS version (1.2 or 1.3). The default value is 1.2.
(Optional)To collect application logs per failed scenario, user can configure the values for the following parameters:
- z: If you want log collection to happen through Elastic search, set the value for this parameter as Elasticsearch. If not, specify the value as Kubernetes.
  If you want to collect logs through Elastic search, it is required to configure the values for the following parameters:
  - v: Specifies the wait time to connect to Elastic search (ELK_WAIT_TIME).
  - w: Specifies the host name of Elastic search (ELK_HOST). For example, occne-elastic-elasticsearch-master.occne-infra/
  - x: Specifies the port for Elastic search (ELK_PORT). For example, 9200.
- y: If you want to collect stub logs, set the value for this parameter as yes. If not, specify the value as no.
Click Save after updating the parameter values. The BSF_NewFeatures Pipeline page appears.

Note:
It is recommended to save a copy of the pipeline script in your local machine that you may refer while restarting ATS pods.

Attention:
Do not modify anything other than the parameter values described in this section.

Running BSF Test Cases

To run BSF test cases, perform the following steps:

Click the Build with Parameters link available in the left navigation pane of the BSF_NewFeatures Pipeline screen. The following page appears.

Figure 4-7 BSF New Features Build with Parameters

Note:

Make sure that the value of FilterWithTags and Include_NewFeatures is selected as NO.
If you want to collect logs for any given build, select YES from the drop-down menu of Fetch_Log_Upon_Failure.
Click Build and select Console Output to view the test results. The following is a sample test result ouput:

Figure 4-8 Sample: Test Result Output in Console

Note:

For more details on consolidated test report, see Managing Final Summary Report, Build Color, and Application Log.

Queuing Jenkins Jobs

Using this feature, you can queue a second job even when current job is still running. The second job can be triggered either from the same or a different pipeline.

The following table lists various scenarios on how queuing works:

Table 4-1 Queuing Jenkins Jobs

Concurrent Builds	New FeaturesCurrent Build	New FeaturesNew Build	RegressionCurrent Build	RegressionNew Build Build	Result
Enabled	Running	Triggered	NA	NA	New-Build of New-Features is added to queue.
Enabled	Running	NA	NA	Triggered	New-Build of Regression is added to queue.
Disabled	NA	NA	Running	Triggered	New-Build of Regression is added to queue.
Disabled	NA	Triggered	Running	NA	New-Build of New-Features is added to queue.

Extracting Application Logs

If any scenarios fail after running the pipeline job, perform the following steps:

kubectl exec -it pod/ocats-bsf-6f6dfc76b5-jbgzt -n ocbsf bash

Go to Jenkins build directory:

cd $JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER/

For example:

cd /var/lib/jenkins/.jenkins/jobs/BSF_Regression/builds/2

Extract the applogs.zip file:
```
unzip applogs.zip
```

After successfully unzipping the file, open the applog folder to view the pod logs for failed scenarios:

(env) [jenkins@ocats-bsf-6f6dfc76b5-jbgzt applog]$ pwd
/var/lib/jenkins/.jenkins/jobs/BSF_Regression/builds/2/applog
(env) [jenkins@ocats-bsf-6f6dfc76b5-jbgzt applog]$ ls -ltrh
total 760K
-rw-r--r--. 1 jenkins jenkins 250K Nov 19 11:08 Initial_Run-Register_BSF_With_NFSetIDList.log
-rw-r--r--. 1 jenkins jenkins 249K Nov 19 11:08 1st_Rerun-Register_BSF_With_NFSetIDList.log
-rw-r--r--. 1 jenkins jenkins 255K Nov 19 11:09 2nd_Rerun-Register_BSF_With_NFSetIDList.log

4.1.4 BSF_NewFeatures Documentation

To view BSF functionalities, go to BSF_NewFeatures pipeline and click Documentation link in the left navigation pane.

Figure 4-9 BSF_NewFeatures Feature List Documentation

Click any functionality to view its test cases and scenarios of each test case. For example, when you click FEATURE - BSF_Error_Response_Enhancements, the following test description appears:

Figure 4-10 Test Cases and Scenarios of Feature - BSF_Error_Response_Enhancements

Based on the functionalities covered under Documentation, the Build Requires Parameters screen displays test cases. To navigate back to the pipeline BSF-NewFeatures screen, click Back to BSF_NewFeatures link available on top left corner of the screen.

Test Result Analyzer

Using the Test Result Analyzer plug-in available in ATS, user can view consolidated and detailed reports. For more information, see Test Results Analyzer section.

Test Case Mapping to Features and Display Total Counts

With this feature, users can view Total Count of Features, TestCases/Scenarios and TestCase mapping to each Feature of BSF in ATS View. For more information, see Support for Test Case Mapping and Count section.

Stub Predefined_priming Support

Stub Predefined_priming configuration in ATS enables ATS to respond back with the payload message instead of default message when prime configuration does not match with the feature level priming or when the sub is not primed.

When the Predefined_priming is not configured and when a request is received at the stub that mimics NRF:

Stub checks against the feature level prime configuration.
If a match is found in feature level prime, stub replies with the payload message.

If there is no match found, stub replies with the default response.

stub_log: No match found in prime configuration for sending the response. Sending default - 200
ATS log: {default_response}

When the Predefined_priming is configured and when a request is received at the stub that mimics NRF:

Stub checks against the feature level prime configuration.
If a match is found in feature level prime, feature level prime is used for responding to the request.
If a match is not found in the feature level prime, but found in the pre-configured prime, pre-configured prime is used for responding to the request.
If a match is found in both pre-primed as well as feature level prime, feature level prime configuration is given priority and the same is used for responding to the request.
If a match is not found in both pre-primed as well as feature level prime, stub sends a default response.

4.1.5 Running BSF Regression Pipeline

This section describes how to run test cases for Binding Support Function (BSF) Regression pipeline.

The BSF_Regression pipeline is a pre-configured pipeline where all the test cases of previous releases are available. For example, for BSF 25.2.200, this pipeline has all the test cases released till BSF 25.2.100.

To view BSF_Regression pipeline details, perform the following steps:

Click BSF_Regression in the Name column.
Click Build with Parameters in the left navigation pane.
Copy the required test cases that are available in the BSF folder and place them appropriately within the custom folder for BSF_Regression.
Reload the page to view the test cases available in the custom Regression folder.
Click Build.

Figure 4-11 BSF_Regression Pipeline

Note:

The Regression pipeline does not have any sanity option. However, users must perform all the steps performed in the BSF_NewFeatures pipeline. Ensure that the pipeline script is configured according to the environment variables.

4.1.6 BSF_Regression Documentation

This section describes the documentation for BSF_Regression pipeline.

To view the documentation for any of the BSF features, on the ATS home page, click BSF_Regression. Then, click Documentation in the left navigation pane.

This page shows features of only those test cases that are released in previous releases.

Figure 4-12 BSF_Regression Features Documentation

4.1.7 Running BSF_HealthCheck Pipeline

This is a pre-configured pipeline where ATS performs a test probe with SUT. It triggers helm test and provides the results in Jenkins Console Logs.

You can run BSF_HealthCheck pipeline to check if all BSF pods are up and running. If yes, it provides the status as successful. If any pod is down due to any reason, then the pipeline fails.

To configure the parameters for BSF_HealthCheck pipeline, perform the following steps:

Click BSF_HealthCheck in the Name column.
Click Configure in the left navigation pane.
When you scroll-down, the General tab becomes active. Be sure that the screen loads completely.
Continue scrolling down until the Pipeline tab becomes active. The following is a screen capture that shows the Pipeline script:

Figure 4-13 Helm Test Script
In the Script area under the Pipeline section, users may customize the values for the following parameters:

Attention:
Do not modify values of parameters other than the ones described in this section.
- a: Change this parameter to update the helm release name where BSF is deployed in your bastion.
- b: Change this parameter to update the namespace where BSF is deployed in your bastion.
Click Save to update the values.

Running Helm Test

To run BSF test cases, click Build Now.

4.2 Running NSSF Test Cases using ATS

This section describes how to run NSSF test cases using ATS.

4.2.1 Prerequisites

The prerequisites to run NSSF Test Cases using NSSF ATS 25.2.200 are:

Deploy NSSF 25.2.200 with default helm configurations using helm charts.
All NSSF microservices must be up and running.
Both NSSF ATS and ATS Deployment needs to be same namespace.
For NSSF ATS 25.2.200, deploy one stub server and the service name should be "amf-stubserver". It is required to run AMF-subscription Notification functionality test cases.
For NSSF ATS 25.2.200, deploy one stub server and the service name should be "nrf-stubserver". It is required to run NRF-subscription Notification functionality test cases.
For NSSF ATS 25.2.200, deploy one stub server and the service name should be "nrf-stubserver1". It is required to run NRF-selection based on DNS SRV.
For NSSF ATS 25.2.200, deploy one stub server and the service name should be "nrf-stubserver2". It is required to run NRF-selection based on DNS SRV.
For NSSF 25.2.200, deploy one DNS stub server and the service name should be "ocdns-bind". It is required to run NRF-selection based on DNS SRV.

4.2.2 Logging into ATS

Before logging into ATS, deploy ATS using HELM charts as shown below:

Verify ATS deployment


[opc@ocnssf-oci-phx-einstein-bastion-01 ~]$ helm status ocats

NAME: ocats
LAST DEPLOYED: Thu May 30 10:21:40 2024
NAMESPACE: cicdnssf-240530102024
STATUS: deployed
REVISION: 1
TEST SUITE: None

There are two ways to log in to ATS GUI.

When an external load balancer (metalLB in case of OCCNE) is available and you provide an external IP to the ATS service, the user can log in to ATS GUI using <External-IP>:8080.
When you do not provide an external IP to the ATS service, open the browser and enter the external IP of the worker node and nodeport of the ATS service to log in to the ATS GUI.
<Worker-Node-IP>:<Node-Port-of-ATS>

Note:
In the Verifying ATS Deployment screenshot, the ATS nodeport is highlighted in red as 32013. For more details on ATS deployment, refer to NSSF ATS Installation Procedure.

Open a browser and enter the IP Address and port details as <Worker-Node-IP>:<NodePort-of-ATS> (In the above example, the Worker-Node-IP and NodePort-of-ATS are 10.98.101.177:32013, which are shown as highlighted in the screenshot above).

The ATS login screen appears.

To run ATS:

Enter the username as 'nssfuser' and password as 'nssfpasswd'. Click Sign in. A page with preconfigured pipelines appears.

Note:
To modify the default login password, refer to Modifying Login Password.
A page with preconfigured pipelines appears.
- NSSF-New-Features: This pipeline has all the test cases delivered as part of NSSF ATS - 25.2.200.
- NSSF-Regression: This pipeline has the test cases of all the previous releases.

4.2.3 NSSF-NewFeatures Pipeline

In this pipeline, you can configure ATS, which is a one-time activity as per System Under Test (SUT) deployment. You can also run all the new NSSF test cases using the pipeline. To configure its parameters:

Click NSSF-NewFeatures in the Name column. The following screen appears:
In the above screen:
1. Click Configure to access the configuration screen.
2. Click Documentation to view the documented test cases.
3. Click blue dots inside the Build History box to view the success console logs of the "All" and "Sanity" respectively.
4. The Stage View represents the already run pipeline for customer reference.
Click Configure. Users MUST wait for the page to load completely. Once the page loads completely, click the Pipeline tab to reach the Pipeline configuration as shown below:

WARNING:

Make sure that the screen shown above loads completely before you perform any action on it. Also, do not modify any configuration other than that discussed below.

You can modify script pipeline parameters from "a" to "B" on the basis of your deployment environment and click Save. The content of the pipeline script is as follows:

node ('built-in'){
    //a = SELECTED_NF           b = NF_NAMESPACE    c = INGRESS_GATEWAY_IP     d = EGRESS_GATEWAY_IP
    //e = PROMETHEUS_SVC_IP     f = STUB_IP         g = PROMETHEUS_PORT        h = RERUN_COUNT
    //i = NF_DB                 j = NF_DB_SECRET    k = NSCONFIG_IP            l = NRF_STUB_IP
    //m = HELM_RELEASE_NAME     n = ATS_RELEASE_NAME             o = NSSF_INGRESS_GATEWAY_PORT
    //p = NSSF_EGW_PORT         q = NSSF_CONFIG_PORT             r = NSSF_SELECTION_SVC_NAME
    //s = NSSF_AUDITOR_SVC      t = NSSF_AVAILABILITY_SVC_NAME   u = NSSF_SUBSCRIPTION_SVC_NAME
    //v = NSSF_APP_INFO_SVC     w = NSSF_PERFINFO_SVC            x = NSSF_INSTANCEID
    //y = NRF_STUB_1_SVC_NAME   z = NRF_STUB_2_SVC_NAME          A = NSSF_NRF_CLIENT_SVC_NAME
    //B = SUPPORTED_PLMN_LIST_MCC_MNC
    withEnv([
 
    ]){
    sh '''
        sh /var/lib/jenkins/ocnssf_tests/preTestConfig.sh \
        -a NSSF \
        -b ocnssf \
        -c ocnssf-ingress-gateway.ocnssf \
        -d ocnssf-egress-gateway.ocnssf \
        -e occne-prometheus-server.occne-infra \
        -f amf-stubserver.ocnssf \
        -g 80 \
        -h 2 \
        -i ocnssf-nsdb.ocnssf \
        -j ocnssf-db-creds \
        -k ocnssf-nsconfig.ocnssf \
        -l nrf-stubserver.ocnssf \
        -m ocnssf \
        -n ocats \
        -o 8081 \
        -p 8080 \
        -q 8080 \
        -r ocnssf-nsselection.ocnssf \
        -s ocnssf-nsauditor.ocnssf \
        -t ocnssf-nsavailability.ocnssf \
        -u ocnssf-nssubscription.ocnssf \
        -v ocnssf-ocnssf-app-info.ocnssf \
        -w ocnssf-ocnssf-perf-info.ocnssf \
        -x 9faf1bbc-6e4a-4454-a507-aef01a101a01 \
        -y nrf-stubserver1.ocnssf \
        -z nrf-stubserver2.ocnssf \
        -A ocnssf-ocnssf-nrf-client-nfmanagement.ocnssf \
        -B 311 480 \
    '''
    if(env.Include_Regression && "${Include_Regression}" == "YES"){
        sh '''sh /var/lib/jenkins/common_scripts/merge_jenkinsfile.sh'''
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Merged"
    }
    else{
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-NewFeatures"
    }
    }
}

Note:

The User MUST NOT change any other value apart from these parameters.

The description of these parameters is as follows:

a: Name of the NF to be tested in capital (NSSF).
b: Namespace in which the NSSF is deployed (default is ocnssf)
c: Ingress Gateway IP address (default is ocnssf-ingress-gateway.ocnssf)
d: Egress Gateway IP address (default is ocnssf-egress-gateway.ocnssf)
e: Prometheus service IP address (default is prometheus.cne-infra)
f: Stub service IP address (default is ocats-amf-stubserver.ocnssf)
g: Port of Prometheus service (default is 80)
h: Number of times the re-run of failed case is allowed (default is 2).
i: Database name (default is ocnssf-nsdb.ocnssf)
j Database secrets (default ocnssf-db-creds)
k: NSSF config ip address (ocnssf-nsconfig.ocnssf)
l: NRF stub server IP address (ocats-nrf-stubserver.ocnssf)
m: NSSF release name (ocnssf)
n: ATS release name (ocats)
o: NSSF Ingress Gateway Port
p: NSSF Egress Gateway Port
q: NSSF Config Port
r: NSSF Selection Service Name
s: NSSF Auditor Service Name
t: NSSF Availability Service Name
u: NSSF Subscription Service Name
v: APP Info Service Name
w:Perf info Service Name
x: NSSF Supported PLMN
A: NRF Client Managment Service Name (ocnssf-ocnssf-nrf-client-nfmanagement.ocnssf)
B: NSSF PLMN List (311 480 )

Note:

Do not change any value if the OCCNE cluster is used and NSSF, ATS, and STUB are deployed in the ocnssf namespace.
In the above image NSSF Helm release name is "ocnssf", ATS Helm Release Name is "ocats" and namespace is "ocnssf". If any change in helm release name of NSSF, ATS and namespace needs to be updated accordingly.
For example, NSSF Helm release name is "ocnssfats" and ATS Helm release name is "ocatsnssf" and namespace is "ocnssf2510", then above Pipeline Configuration should be edited as shown below.
NSSF Helm release name should be updated in "c d i k m r s t u v w" if any change in NSSF helm release name apart from "ocnssf".

The NSSF Instance ID needs to be updated in the ATS Jenkins pipeline parameters if there are any changes in the NSSF custom values (CV) file. By default, the NSSF Instance ID is set to "9faf1bbc-6e4a-4454-a507-aef01a101a01". If the Instance ID is modified in the NSSF CV file, the same changes must be reflected in the Jenkins pipeline parameters.

By default, NSSF Instance ID in NSSF custom values file as below:


#InstanceId of NSSF used in case of GR
nfInstanceId: &nfInstanceId "9faf1bbc-6e4a-4454-a507-aef01a101a01"

For example, if the nfInstanceId in the NSSF custom values file is modified from "9faf1bbc-6e4a-4454-a507-aef01a101a01" to "9faf1bbc-6e4a-4454-a507-aef01a101a20", the same change must be updated in the "x" Jenkins pipeline parameters as shown below:

node ('built-in'){
    //a = SELECTED_NF           b = NF_NAMESPACE    c = INGRESS_GATEWAY_IP     d = EGRESS_GATEWAY_IP
    //e = PROMETHEUS_SVC_IP     f = STUB_IP         g = PROMETHEUS_PORT        h = RERUN_COUNT
    //i = NF_DB                 j = NF_DB_SECRET    k = NSCONFIG_IP            l = NRF_STUB_IP
    //m = HELM_RELEASE_NAME     n = ATS_RELEASE_NAME             o = NSSF_INGRESS_GATEWAY_PORT
    //p = NSSF_EGW_PORT         q = NSSF_CONFIG_PORT             r = NSSF_SELECTION_SVC_NAME
    //s = NSSF_AUDITOR_SVC      t = NSSF_AVAILABILITY_SVC_NAME   u = NSSF_SUBSCRIPTION_SVC_NAME
    //v = NSSF_APP_INFO_SVC     w = NSSF_PERFINFO_SVC            x = NSSF_INSTANCEID
    //y = NRF_STUB_1_SVC_NAME   z = NRF_STUB_2_SVC_NAME          A = NSSF_NRF_CLIENT_SVC_NAME
    //B = SUPPORTED_PLMN_LIST_MCC_MNC
    withEnv([
 
    ]){
    sh '''
        sh /var/lib/jenkins/ocnssf_tests/preTestConfig.sh \
        -a NSSF \
        -b ocnssf2510 \
        -c ocnssfats-ingress-gateway.ocnssf2510 \
        -d ocnssfats-egress-gateway.ocnssf2510 \
        -e occne-prometheus-server.occne-infra \
        -f amf-stubserver.ocnssf2510 \
        -g 80 \
        -h 2 \
        -i ocnssf-nsdb.ocnssf \
        -j ocnssf-db-creds \
        -k ocnssfats-nsconfig.ocnssf2510 \
        -l nrf-stubserver.ocnssf2510 \
        -m ocnssfats \
        -n ocats \
        -o 8081 \
        -p 8080 \
        -q 8080 \
        -r ocnssfats-nsselection.ocnssf2510 \
        -s ocnssfats-nsauditor.ocnssf2510 \
        -t ocnssfats-nsavailability.ocnssf2510 \
        -u ocnssfats-nssubscription.ocnssf2510 \
        -v ocnssfats-ocnssf-app-info.ocnssf2510 \
        -w ocnssfats-ocnssf-perf-info.ocnssf2510 \
        -x 9faf1bbc-6e4a-4454-a507-aef01a101a20 \
        -y nrf-stubserver1.ocnssf2510 \
        -z nrf-stubserver2.ocnssf2510 \
        -A ocnssfats-ocnssf-nrf-client-nfmanagement.ocnssf2510 \
        -B 311 480 \
    '''
    if(env.Include_Regression && "${Include_Regression}" == "YES"){
        sh '''sh /var/lib/jenkins/common_scripts/merge_jenkinsfile.sh'''
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Merged"
    }
    else{
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-NewFeatures"
    }
    }
}

Click Save after making necessary changes. The Pipeline NSSF-NewFeatures screen appears.

Running NSSF New Features Test Cases

To run NSSF New Features test cases:

Go back to new features and Click Build with Parameters present on the NSSF-NewFeatures screen in the extreme left column corresponding to NSSF-NewFeatures row as shown below:
The following screen appears:

In the above screen, there are three Select_Option(s), which are:
- By default, features 'ALL', configuration type 'Product_config', include regression 'NO' will be selected, and all test cases will be executed once clicked on BUILD, as shown above.
- Features: ALL. Once you click on ALL, a dropdown 'Select' option will appear. After selecting 'Select,' options will appear to choose feature files. To run the selected feature files, click on 'Build,' as shown below.
Select one of the following configuration types:
- Product_Config: On selecting this option, test cases from product folders are populated on ATS UI and product configuration is applied to them via the keyvalue pair and yaml files defined or present in the "Product Config" folder.
- Custom_Config: On selecting this option, test cases from custom folders are populated on ATS UI and custom configuration is applied to them via the keyvalue pair and yaml files defined or present in the "Custom Config" folder. To use the Parameterization feature, always select the Custom_Config option. User can copy, add, or delete the required test cases that are available for the NSSF and place them appropriately within the custom folder for NSSF-NewFeatures. Reload the page to view the test cases available in the custom NewFeatures folder. For more information, see Parameterized approach for SUT custom configuration.
The NSSF test cases are divided into NSSF Service operations as follows:
- NSSF_204NoContent_NsAvailability_PATCH_REMOVE- This feature file contains test cases related to PATCH or PUT request for deleting all slices.
- Virtual_Host_NRF_Resolution_By_NSSF_Using_DNSSRV- This feature file contains test cases related to DNS SRV based selection of NRF in NSSF.
If you want to run custom_config, select below parameter as custom_config, where the framework automatically points out to custom_config and cust_data.
```
7 features passed, 0 failed, 0 skipped
99 scenarios passed, 0 failed, 0 skipped
3079 steps passed, 0 failed, 0 skipped, 0 undefined
Took 21m10.088s
```

Parameterized approach for SUT custom configuration

Using this feature, user can make the following customizations to custom folders:

Add new test cases by adding datafiles
Remove test cases
Modify the parameters and their values in the key-value pair or <feature>.yaml files

To run ATS test cases, user can maintain as many versions of Custom_Config folder by using the following naming convention:

Cust ConfigN

where N can be any number

At the time of execution, ensure to rename the required folder to Custom Config folder as Jenkins always retrieves data from this folder when user selects Custom_Config.

Updating Global Parameters

To use Custom_Config, it is required to change the value of cust_folder from data to cust_data in global.yaml file. In addition, you can customize the parameters and their respective values in the global.yaml as per the requirements.

Updating Feature Parameters

Consider the following points when customizing <feature>.yaml files for parameterized feature:

In addition to global.yaml parameters, feature files may also contain parameters for which user can update values at the time of running pipelines.
Changing the values of parameters tagged as "Feature Specific Value" may cause failures at the time of running pipelines.
Values for parameters tagged with #START_GLOBAL and #END_GLOBAL tags take values from global.yaml.

Note:

For NSSF-ATS release 25.2.200, parameterization is supported for NSSF NewFeatures pipeline only.

4.2.4 NSSF-NewFeatures Documentation

To view NSSF functionalities, go to NSSF-NewFeatures pipeline latest build and click the Documentation link in the left navigation pane. The following screen appears. Click any functionality to view its test cases and scenarios of each test case as shown in the sample screenshot below:

A sample of a few documentation features are as follows:

Once the run of new features done successfully, click on the build number whose logs are to be viewed and then click on Console Output on left side navigation.

Wait till the page is loaded completely, then click Download to download the new features logs.

4.2.5 NSSF-Regression Pipeline

This pipeline contains test cases from the previous versions.

Some of the test cases are updated as per the new implementation of NSSF.

The configuration method and parameters are the same as the NewFeatures pipeline.

The NSSF test cases are divided into NSSF Service operations. The classification is as follows:

NSSF_Sending_Notification_via_ARS_SCP: Tests NSSF's ability to route and send notifications to SCP(s) via ARS, including single/multiple SCPs, priorities, virtual hosts, alternate routes, and related error handling.
NSSF_User_Agent_Header: Validates the User-Agent headers based on whether the feature is enabled or disabled.
oauth_signValidationServiceMeshEnabled_false: Validates CRUD operations performed on OAuth in NSSF’s Ingress Gateway configuration.
NSSF_OAuth_Response_Header: Ensures NSSF sends correct OAuth2-related HTTP error codes and headers for invalid, expired, or insufficient-scope OAuth2 tokens.
NSSF_Server_Header: Validates the Server Header feature.
NSSF_SCP_Monitoring_OPTIONS: Tests NSSF SCP peer monitoring and routing logic, including configuration, healthPath enforcement, priorities, and error handling for SBI and indirect routing scenarios.
Nnssf_NSSelection_PDU_Miscellaneous_AutoConfiguration_ON: Tests NSSelection with auto-configuration ON for PDU session flows, configuration changes, and error scenarios.
Nnssf_NSSelection_UE_CU_Invalid_Query_Parameters: Tests invalid query parameter scenarios for UE/CU NSSelection requests.
Nnssf_NSSelection_Initial_Reg_AutoConfiguration_ON_EnhancedNssai_ON: Validates NSSelection behavior when both autoAuthorizeNssaiAvailabilityDataEnable and enhancedAllowedNssaiEnable are True.
Nnssf_NSSelection_PDU_AutoConfiguration_ON: Validates NSSelection PDU auto-configuration ON scenarios.
Nnssf_NSSelection_PDU_AutoConfiguration_OFF: Validates NSSelection PDU auto-configuration OFF scenarios.
Nnssf_NSSelection_PDU_Miscellaneous_AutoConfiguration_OFF: Tests NSSelection PDU miscellaneous cases with auto-configuration OFF, including PDU session establishment and error handling.
Nnssf_NSSelection_UE_CU_AutoConfiguration_OFF_EnhancedNssai_OFF: Validates NSSelection when both autoAuthorizeNssaiAvailabilityDataEnable and enhancedAllowedNssaiEnable are False.
Nnssf_NSSelection_Invalid_Accept_ContentType_Header: Tests rejection of NSSelection GET requests with invalid or missing Accept/Content-Type headers.
Nnssf_NSSelection_Initial_Reg_AutoConfiguration_OFF_EnhancedNssai_OFF: Validates NSSelection for initial registration with auto-configuration OFF and enhancedNssai OFF.
Nnssf_NSSelection_UE_CU_AutoConfiguration_ON_EnhancedNssai_OFF: Validates NSSelection when auto-configuration is ON and enhancedNssai is OFF.
Nnssf_NSSelection_PDU_Session_Invalid_Query_Parameters: Validates invalid query parameters for PDU session NSSelection.
NSSF_Unknown_URI_Unsupported_Method: Validates CRUD behavior for unknown URIs and unsupported HTTP methods.
Nnssf_NSSelection_Initial_Reg_AutoConfiguration_OFF_EnhancedNssai_ON: Validates initial registration NSSelection with auto-configuration OFF and enhancedNssai ON.
Nnssf_NSSelection_Initial_Reg_Invalid_Query_Parameters: Validates invalid query parameter handling for initial registration NSSelection.
Nnssf_NSSelection_UE_CU_AutoConfiguration_OFF_EnhancedNssai_ON: Validates NSSelection when auto-configuration is OFF and enhancedNssai is ON.
Nnssf_NSSelection_UE_CU_AutoConfiguration_ON_EnhancedNssai_ON: Validates NSSelection when both auto-configuration and enhancedNssai are ON.
Nnssf_NSSelection_Initial_Reg_AutoConfiguration_ON_EnhancedNssai_OFF: Validates initial registration NSSelection with auto-configuration ON and enhancedNssai OFF.
NSSF_NSAvailability_OPTIONS: Tests NSSF responses to OPTIONS requests for supported communication methods.
Nnssf_Nssai_Availability_patch_with_autoconfiguration: Validates PATCH operations on NS availability with auto-configuration enabled.
Nnssf_Nssai_Availability_put_patch_with_supported_features: Validates PUT and PATCH operations in NS availability with supported features.
Nnssf_Nssai_Availability_put_delete_with_autoconfiguration: Validates PUT and DELETE operations on NS availability with auto-configuration enabled.
Nnssf_NSAvailability_Invalid_Accept_ContentType_Header: Validates rejection of NSAvailability requests with invalid or missing Accept/Content-Type headers.
Nnssf_Nssai_Availability_patch_remove_204_NoContent: Validates PATCH operations with and without auto-configuration and enhanced patch behavior, ensuring correct 204 responses.
Nnssf_Nssai_Availability_put_delete_without_autoconfiguration: Validates PUT and DELETE NS availability operations with auto-configuration disabled.
Nnssf_Nssai_Availability_patch_without_autoconfiguration: Validates PATCH operations on NS availability without auto-configuration.
Nnssf_Nssai_Availability_put_patch_delete_error_scenarios: Validates error scenarios for PUT, PATCH, and DELETE operations in NSAvailability with auto-configuration enabled/disabled.
NSSF_Sanity: Validates NSSF sanity test cases.
Nnssf_NSSubscription_Notification_Response_Handling: Validates NSSF subscription notification behavior based on various AMF stub responses.
Nnssf_NSSubscription_Notification_Auto_Config_OFF: Validates notification behavior when auto-configuration is OFF.
Nnssf_NSSubscription_Invalid_Accept_ContentType_Header: Validates subscription request handling with invalid Accept/Content-Type headers.
NSSF_Subscription_Delete: Validates deletion operations and error handling for NSSubscription resources.
Nnssf_NSSubscription_Indirect_Communication_Negative: Validates negative scenarios for indirect communication with incorrect 3gpp-Sbi-Binding headers.
Nnssf_NSSubscription_Subscription_Invalid_Params: Validates CRUD operations and parameter validation for NSSubscription requests.
Nnssf_NSSubscription_Indirect_Communication: Validates indirect communication for the NSSubscription service.
Nnssf_NSSubscription_Subscription_Update: Validates CRUD operations and input validations for NSSubscription updates.
Nnssf_NSSubscription_Notification_Auto_Config_ON: Validates notification behavior when auto-configuration is ON.
Nnssf_NSSubscription_Post: Validates CRUD operations and request handling for NSSubscription POST requests.
Virtual_Host_NRF_Resolution_By_NSSF_Using_DNSSRV: Validates virtual host NRF resolution by NSSF using DNS SRV.
Multiple_PLMN: Validates multiple PLMN:

In the above screen:
- Click Configure to access the configuration screen.
- Click Documentation to view the documented test cases.
- Click blue dots inside the Build History box to view the success console logs of the "All" and "Sanity" respectively.
- The Stage View represents the already run pipeline for customer reference.
Click Configure. Users MUST wait for the page to load completely. Once the page loads completely, click the Pipeline tab to reach the Pipeline configuration as shown below:

WARNING:

Make sure that the screen shown above loads completely before you perform any action on it. Also, do not modify any configuration other than that discussed below.

You can modify script pipeline parameters from "a" to "B" on the basis of your deployment environment and click Save. The content of the pipeline script is as follows:

node ('built-in'){
    //a = SELECTED_NF           b = NF_NAMESPACE    c = INGRESS_GATEWAY_IP     d = EGRESS_GATEWAY_IP
    //e = PROMETHEUS_SVC_IP     f = STUB_IP         g = PROMETHEUS_PORT        h = RERUN_COUNT
    //i = NF_DB                 j = NF_DB_SECRET    k = NSCONFIG_IP            l = NRF_STUB_IP
    //m = HELM_RELEASE_NAME     n = ATS_RELEASE_NAME             o = NSSF_INGRESS_GATEWAY_PORT
    //p = NSSF_EGW_PORT         q = NSSF_CONFIG_PORT             r = NSSF_SELECTION_SVC_NAME
    //s = NSSF_AUDITOR_SVC      t = NSSF_AVAILABILITY_SVC_NAME   u = NSSF_SUBSCRIPTION_SVC_NAME
    //v = NSSF_APP_INFO_SVC     w = NSSF_PERFINFO_SVC            x = NSSF_INSTANCEID
    //y = NRF_STUB_1_SVC_NAME   z = NRF_STUB_2_SVC_NAME          A = NSSF_NRF_CLIENT_SVC_NAME
    //B = SUPPORTED_PLMN_LIST_MCC_MNC
 
    withEnv([
         
    ]){
    sh '''
        sh /var/lib/jenkins/ocnssf_tests/preTestConfig.sh \
        -a NSSF \
        -b ocnssf \
        -c ocnssf-ingress-gateway.ocnssf \
        -d ocnssf-egress-gateway.ocnssf \
        -e occne-prometheus-server.occne-infra \
        -f amf-stubserver.ocnssf \
        -g 80 \
        -h 2 \
        -i ocnssf-nsdb.ocnssf \
        -j ocnssf-db-creds \
        -k ocnssf-nsconfig.ocnssf \
        -l nrf-stubserver.ocnssf \
        -m ocnssf \
        -n ocats \
        -o 8081 \
        -p 8080 \
        -q 8080 \
        -r ocnssf-nsselection.ocnssf \
        -s ocnssf-nsauditor.ocnssf \
        -t ocnssf-nsavailability.ocnssf \
        -u ocnssf-nssubscription.ocnssf \
        -v ocnssf-ocnssf-app-info.ocnssf \
        -w ocnssf-ocnssf-perf-info.ocnssf \
        -x 9faf1bbc-6e4a-4454-a507-aef01a101a01 \
        -y nrf-stubserver1.ocnssf \
        -z nrf-stubserver2.ocnssf \
        -A ocnssf-ocnssf-nrf-client-nfmanagement.ocnssf \
        -B 311 480 \
    '''
    if(env.Include_NewFeatures && "${Include_NewFeatures}" == "YES"){
        sh '''sh /var/lib/jenkins/common_scripts/merge_jenkinsfile.sh'''
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Merged"
    }
    else{
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Regression"
    }
    }
}

Note:

The User MUST NOT change any other value apart from these parameters.

The description of these parameters is as follows:

a: Name of the NF to be tested in capital (NSSF).
b: Namespace in which the NSSF is deployed (default is ocnssf)
c: Ingress Gateway IP address (default is ocnssf-ingress-gateway.ocnssf)
d: Egress Gateway IP address (default is ocnssf-egress-gateway.ocnssf)
e: Prometheus service IP address (default is prometheus.cne-infra)
f: Stub service IP address (default is ocats-amf-stubserver.ocnssf)
g: Port of Prometheus service (default is 80)
h: Number of times the re-run of failed case is allowed (default is 2).
i: Database name (default is ocnssf-nsdb.ocnssf)
j Database secrets (default ocnssf-db-creds)
k: NSSF config ip address (ocnssf-nsconfig.ocnssf)
l: NRF stub server IP address (ocats-nrf-stubserver.ocnssf)
m: NSSF release name (ocnssf)
n: ATS release name (ocats)
o: NSSF Ingress Gateway Port
p: NSSF Egress Gateway Port
q: NSSF Config Port
r: NSSF Selection Service Name
s: NSSF Auditor Service Name
t: NSSF Availability Service Name
u: NSSF Subscription Service Name
v: APP Info Service Name
w:Perf info Service Name
x: NSSF NF Instance ID
y: NRF stub Server Service name(nrf-stubserver1.ocnssf)
z: NRF stub Server Service name(nrf-stubserver1.ocnssf)
A: NRF Client Managment Service Name (ocnssf-ocnssf-nrf-client-nfmanagement.ocnssf)
B: NSSF PLMN List (311 480 )

Note:

Do not change any value if the OCCNE cluster is used, and NSSF, ATS, and STUB are deployed in the ocnssf namespace.
In the above image, the NSSF Helm Release Name is "ocnssf", ATS Helm Release Name is "ocats", and Namespace is "ocnssf". If any change in the helm release name of NSSF, ATS, and namespace needs to be updated accordingly.
For example, if the NSSF Helm Release Name is "ocnssfats" and ATS Helm Release Name is "ocatsnssf", and Namespace is "ocnssf2510", then the above Pipeline Configuration should be edited as shown below:
- NSSF Helm Release Name should be updated in "c d i k m r s t u v w" if any change in NSSF helm release name apart from "ocnssf".
The NSSF Instance ID needs to be updated in the ATS Jenkins pipeline parameters if there are any changes in the NSSF custom values (CV) file. By default, the NSSF Instance ID is set to "9faf1bbc-6e4a-4454-a507-aef01a101a01". If the Instance ID is modified in the NSSF CV file, the same changes must be reflected in the Jenkins pipeline parameters.
By default NSSF Instance ID in NSSF custom values file as below:
```
#InstanceId of NSSF used in case of GR
nfInstanceId: &nfInstanceId "9faf1bbc-6e4a-4454-a507-aef01a101a01"
```
For example, if the nfInstanceId in the NSSF custom values file is modified from "9faf1bbc-6e4a-4454-a507-aef01a101a01" to "9faf1bbc-6e4a-4454-a507-aef01a101a20", the same change must be updated in the "x" Jenkins pipeline parameters as shown below.

node ('built-in'){
    //a = SELECTED_NF           b = NF_NAMESPACE    c = INGRESS_GATEWAY_IP     d = EGRESS_GATEWAY_IP
    //e = PROMETHEUS_SVC_IP     f = STUB_IP         g = PROMETHEUS_PORT        h = RERUN_COUNT
    //i = NF_DB                 j = NF_DB_SECRET    k = NSCONFIG_IP            l = NRF_STUB_IP
    //m = HELM_RELEASE_NAME     n = ATS_RELEASE_NAME             o = NSSF_INGRESS_GATEWAY_PORT
    //p = NSSF_EGW_PORT         q = NSSF_CONFIG_PORT             r = NSSF_SELECTION_SVC_NAME
    //s = NSSF_AUDITOR_SVC      t = NSSF_AVAILABILITY_SVC_NAME   u = NSSF_SUBSCRIPTION_SVC_NAME
    //v = NSSF_APP_INFO_SVC     w = NSSF_PERFINFO_SVC            x = NSSF_INSTANCEID
    //y = NRF_STUB_1_SVC_NAME   z = NRF_STUB_2_SVC_NAME          A = NSSF_NRF_CLIENT_SVC_NAME
    //B = SUPPORTED_PLMN_LIST_MCC_MNC
    withEnv([
 
    ]){
    sh '''
        sh /var/lib/jenkins/ocnssf_tests/preTestConfig.sh \
        -a NSSF \
        -b ocnssf2510 \
        -c ocnssfats-ingress-gateway.ocnssf2510 \
        -d ocnssfats-egress-gateway.ocnssf2510 \
        -e occne-prometheus-server.occne-infra \
        -f amf-stubserver.ocnssf2510 \
        -g 80 \
        -h 2 \
        -i ocnssf-nsdb.ocnssf \
        -j ocnssf-db-creds \
        -k ocnssfats-nsconfig.ocnssf2510 \
        -l nrf-stubserver.ocnssf2510 \
        -m ocnssfats \
        -n ocats \
        -o 8081 \
        -p 8080 \
        -q 8080 \
        -r ocnssfats-nsselection.ocnssf2510 \
        -s ocnssfats-nsauditor.ocnssf2510 \
        -t ocnssfats-nsavailability.ocnssf2510 \
        -u ocnssfats-nssubscription.ocnssf2510 \
        -v ocnssfats-ocnssf-app-info.ocnssf2510 \
        -w ocnssfats-ocnssf-perf-info.ocnssf2510 \
        -x 9faf1bbc-6e4a-4454-a507-aef01a101a20 \
        -y nrf-stubserver1.ocnssf2510 \
        -z nrf-stubserver2.ocnssf2510 \
        -A ocnssfats-ocnssf-nrf-client-nfmanagement.ocnssf2510 \
        -B 311 480 \
    '''
    if(env.Include_Regression && "${Include_Regression}" == "YES"){
        sh '''sh /var/lib/jenkins/common_scripts/merge_jenkinsfile.sh'''
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Merged"
    }
    else{
        load "/var/lib/jenkins/ocnssf_tests/jenkinsData/Jenkinsfile-Regression"
    }
    }
    }
}

Click Save after making necessary changes. The Pipeline NSSF-Regression screen appears.

NSSF-Regression - Build with Parameters

By default, features "ALL," configuration type "Product_config," and include new features "NO" will be selected. All test cases will be executed once you click on BUILD, as shown above.
Features: ALL. Once you click on ALL, a dropdown "Select" option will appear. After selecting the "Select" option, as shown below, options will appear to select feature files. To run the selected feature files, click on "Build," as shown below.

45 features passed, 0 failed, 0 skipped
784 scenarios passed, 0 failed, 0 skipped
14570 steps passed, 0 failed, 0 skipped, 0 undefined
Took 196m23.264s

4.2.6 NSSF-Regression Documentation

To view NSSF Regression cases, go to NSSF-Regression latest pipeline build and click the Documentation link in the left navigation pane. The following screen appears. Click any functionality to view its test cases and scenarios of each test case as shown below:

A sample of a few documentation features are as follows:

Once the run of regression features is done successfully, click on the build number whose logs are to be viewed and then click on Console Output on left side navigation.

Wait till the page is loaded completely, then click Download to download the regression features logs.