From 17de7b05fd6f4af79da1bdbe854bfc90c744a66a Mon Sep 17 00:00:00 2001 From: mhorst00 <36167515+mhorst00@users.noreply.github.com> Date: Fri, 22 Apr 2022 10:57:14 +0200 Subject: [PATCH] added first changes from STP.docx --- 4.-Systemtestplan.md | 600 +++++++++++++------------------------------ 1 file changed, 178 insertions(+), 422 deletions(-) diff --git a/4.-Systemtestplan.md b/4.-Systemtestplan.md index 1f769ed..c8a0917 100644 --- a/4.-Systemtestplan.md +++ b/4.-Systemtestplan.md @@ -14,140 +14,116 @@

1Scope Scope 

2Definitions Definitions 

3Test Objects Test Objects 

4Features Features 

5Test Preparation Strategy Test Preparation Strategy 

6Test Execution Strategy Test Execution Strategy 

7Test Equipment Test Equipment

8Test Schedule and Budget Test Schedule and Budget

9Test Planning Test Planning 

10Reference/ +text-decoration:none'> Reference/ Standards 

11Testcases Testcases 

11.1Test suite <TS-001 Basic -functionality>

+text-decoration:none'> Test suite <TS-001 File operations>

11.1.1Testcase -<TC-001-001> (Create device) Testcase +<TC-001-001> (Loading of a valid file with validation)

11.1.2Testcase -<TC-001-002> (Open device, save changes) Testcase +<TC-001-002> (Loading of an invalid file with validation)

11.1.3Testcase -<TC-001-003> (Load standard libraries) Testcase +<TC-001-003> (Export of a valid device to file with validation)

+

11.1.4 Testcase +<TC-001-004> (Export of an invalid device to file with validation)

+ +

11.2Test suite <TS-002 Generic data> Test suite <TS-002 GUI> 

11.2.1Testcase -<TC-002-001> (Create device with attributes) Testcase +<TC-002-001> (GUI input field verification)

11.2.2Testcase -<TC-002-002> (Create device with role classes) Testcase +<TC-002-002> (GUI load file via file explorer)

11.2.3Testcase -<TC-002-003> (Open device, delete data) Testcase +<TC-002-003> (GUI Creation and editing of a new device)

-

11.3Test suite <TS-003 Interfaces> 

- -

11.3.1Testcase -<TC-003-001> (Create device with interfaces)

- -

11.3.2Testcase -<TC-003-002> (Open device, delete interfaces)

- -

11.4Test suite <TS-004 Attachments> 

- -

11.4.1Testcase -<TC-004-001> (Create device with attachments)

- -

11.4.2Testcase -<TC-004-002> (Open device, delete Attachments) Testcase +<TC-002-004> (GUI Export of a loaded device)

@@ -192,12 +168,12 @@ clear=all style='page-break-before:always'> -

22.10.2020

+

22.04.2022

-

Jakob Schmidt

+

Malte Horst

Created

- - -

0.2

- - -

08.04.2021

- - -

Jakob Schmidt

- - -

First draft

- - - - -

0.3

- - -

20.04.2021

- - -

Jakob Schmidt

- - -

Second draft

- - - - -

1.0

- - -

22.04.2021

- - -

Jakob Schmidt

- - -

Added more tests and test data

- - - - -

1.1

- - -

27.04.2021

- - -

Jakob Schmidt

- - -

Added delete tests

- - - - -

1.2

- - -

05.05.2021

- - -

Jakob Schmidt

- - -

Final Version

- -
test strategy and test planning.

It contains the tests required to check -whether the requirements specified in the SRS (System Requirements Specification) [1] have been implemented in a functional manner.

+whether the requirements specified in the SRS (System Requirements Specification) have been implemented in a functional manner.

The document derived from the STP is the -STR (System Test Report) [2], which additionally specifies the test results.

+STR (System Test Report), which additionally specifies the test results.

 

@@ -339,9 +208,9 @@ STR (System Test Report) [2], which additionally specifies the test results.AML AutomationML
TS    Testsuite
-TC    Testcase

- -

GUI  Graphical User Interface

+TC    Testcase
+GUI Graphical User Interface
+

 

@@ -380,17 +249,17 @@ TC    Testcase

-

Version 2.0

+

Build v1.0

-

Modelling Wizard

+

Standalone Modelling Wizard for Devices GUI

-

Plugin for AutomationML to create devices

+

Windows standalone application with a GUI

@@ -407,14 +276,12 @@ ideograph-numeric ideograph-other'> 

4        Features

-

The following requirements must be verified -if they are not classified as “not to be tested”. This table shows the test -coverage between functionality and test suites or test cases.

+

The following requirements must be verified, as long as they are not classified as “not to be tested”. This table shows the test coverage between functionality and test suites or test cases.

- + + + + + + + + + + + + + + + + + + + + + + + +

Reg.-ID.

@@ -436,13 +303,12 @@ coverage between functionality and test suites or test cases.

-

LF10

+

LF10: Import

-

Basic tests. Validation of input and - output.

+

Imports file by absolute path

-

LF20

+

LF20: File validation

-

Checks if generic data are added - correctly.

+

Checks whether input file is in a valid format

-

A

+

B

-

TS-002

+

TS-001

-

LF30

+

LF30: Error handling

-

Checks if interfaces are added correctly.

+

Application throws errors on expected shutdowns and wrong formatting

-

A

+

B

-

TS-003

+

TS-002

-

LF40

+

LF40: GUI

-

Checks if attachments are added correctly

+

Draws GUI for user

-

TS-004

+

TS-002

+
+

LF50: Display device in a readable way

+
+

Displays loaded device in GUI in a readable way for user

+
+

A

+
+

TS-002

+
+

LF60: Edit device

+
+

Every attribute of devices should be editable

+
+

A

+
+

TS-002

+
+

LF70: Create device

+
+

Creates a new and empty device

+
+

A

+
+

TS-002

+
+

LF80: Export device

+
+

Loaded device is saved as to file

+
+

A

+
+

TS-001, TS-002

@@ -527,54 +476,25 @@ coverage between functionality and test suites or test cases.

5        Test Preparation Strategy

-

Since the Modelling Wizard does not have -any Modules, the testing will be split into four parts. One for the basic -functionality testing

+

The creation of tests will be application case based. Two main application cases can be identified, the file operations and the GUI. -

1.    Basic functionality

+File operations represent the first main application case. Device files need to be loaded, validated and saved to ensure full functionality of the application for the user. -

And three for the different types of data -the Modelling Wizard can store.

- -

2.    generic data

- -

3.    interfaces

- -

4.    attachments

- -

 

+The GUI is the second main application case. Unlike the previous plugin for the AML Editor, the GUI provides a view of the loaded device with input fields in which the respective device data is displayed. These fields must be checked and features to edit and save device must be validated. +

6        Test Execution Strategy

-

Because this is a further development of -an already existing software, only the functionalities that have been changed or -implemented by the programmers will be tested. This includes the functional -requirements specified in the SRS [1] and the functionalities that were affected -during bug fixing.

+

Since it is a re-implementation of an already existing software, a complete test is not necessary, but it is still useful. The test should be divided into the following phases: -

Since large parts of the program have -been changed or optimized mainly because of the extensive bug fixes, it is -worthwhile to start with testing the basic functionality to verify the correct -functionality program.

+1) File operations +2) Graphical User Interface -

After that the generic data, interfaces and -attachments will be tested, to verify the different features.

+Since the file operations are needed for the application to work, these have to be tested first. -
-
- -

 

+Then the GUI functionality can be tested. This includes the start of the program and the execution of the main features of the application in the GUI. +

7        Test Equipment

@@ -582,97 +502,22 @@ ideograph-numeric ideograph-other'> 

The following equipment must be available for testing:

-

 

+

•  A computer with Windows 10 or higher

-

•  A computer with Windows 7 or higher

+

•  The standalone Device Modelling Wizard software

-

•  Installed AutomationML Editor (Downloadlink)

- -

•  Installed Modelling Wizard software

- -

 

- -

The “Test Data” folder from the git -repository [3]

+

• The “Test Data” folder from the git +repository

 

8        Test Schedule and Budget

-

Hours scheduled

+

The testing of the application begins as soon as the application is completed. This makes it possible to make the necessary corrections quickly. The conversion library can only be tested once the rules for one input format, but preferably both input formats, have been established. Since only minimal changes are made in the GUI, the GUI can be tested as soon as all adjustments intended for the GUI have been made. - - - - - - - - - - - -
-

 

-
-

Phillip Tran (LE)

-
-

Jakob Schmidt (TM)

-
-

Test

-
-

20h

-
-

70h

-
- -

 

- -

Planned budget

- - - - - - - - - - -
-

 

-
-

Budget

-
-

Test

-
-

3.700€

-
- -

 

+No budget is needed for the tests, as they are all performed by hand. +

9        Test Planning

@@ -711,22 +556,22 @@ repository [3]

-

Basic functionality

+

File operations

-

Jakob Schmidt

+

Linus Eickhoff

-

Phillip Tran

+

Florian Kaiser

-

Jakob Schmidt

+

Linus Eickhoff

@@ -737,131 +582,43 @@ repository [3]

-

Generic data

+

Graphical User Interface

-

Jakob Schmidt

+

Linus Eickhoff

-

Phillip Tran

+

Florain Kaiser

-

Jakob Schmidt

- - - - -

TS-003

- - -

Interfaces

- - -

Jakob Schmidt

- - -

Phillip Tran

- - -

Jakob Schmidt

- - - - -

TS-004

- - -

Attachments

- - -

Jakob Schmidt

- - -

Phillip Tran

- - -

Jakob Schmidt

+

Linus Eickhoff

 

-

10   -Reference/ Standards

+

10   +References

-

+

[1] SRS TINF20C Device Modelling Wizard

- - - - - - - - - - - - - -
-

[1]

-
-

„SRS,“ [Online]. Available: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/1.-Software-Requirements--Specification.

-
-

[2]

-
-

„STR,“ [Online]. Available: https://github.com/DekaAthlos/TINF19C-ModellingWizard/wiki/5.-Systemtestreport.

-
-

[3]

-
-

„Test Data,“ [Online]. Available: - https://github.com/DekaAthlos/TINF19C-ModellingWizard/tree/master/PROJECT/Test%20Data.

-
- -

 

- -
-
- -

 

+

 

11   Testcases

11.1 -Test suite <TS-001 Basic functionality>

+Test suite <TS-001 File operations>

11.1.1  -Testcase <TC-001-001> (Create device)

+Testcase <TC-001-001> (Loading of a valid file with validation) @@ -884,7 +641,7 @@ color:black'>
@@ -895,7 +652,7 @@ color:black'>
@@ -906,8 +663,7 @@ color:black'>
-

Create device

+

Loading of a valid file with validation

-

LF10

+

LF10, LF20, LF30

-

This testcase - verifies that a device can be created and saved.

+

The test case verifies that it recognizes if a valid file has been loaded.