QA 업무 중 자료 구조?

업무 중에 자료 구조를 쓸일이 있을까? 라는 생각을 QA 활동을 하다보니 하게되었고

따로 혼자서 공부를 하려다보니까 그것도 잘되지 않더군요 ( 그시간에 html css, js 를 !)

이라고 하였으나

머릿속엔 일하면서 어떻게 하면??

어떻게 하면 자동화 하는 구조를 좀더 이쁘게 할수 있을까는 고민했습니다.

어느정도 자동화 프로세스는 갖추어졌는데 중앙 관리자 (Redux에서는 Store라고 표현하던데)

의 상태관리를 어떻게 하면 좋을까 라는 생각을 매번하다가 나온 구조가 

var obj = {
   "widget":{
      "api":{
         "setFocus":{
            "contents":"setFocus 입니다.",
            "tc":"WIDGET_API_SETFOCUS",
            "result":"fail"
            }
        },
      "attr":{
         "page-length":{
            "contents":"page-length 확인 ",
            "tc":"WIDGET_ATTR_PAGE_LENGTH",
            "result":"fail"
            },
         "length-change":{
            "contents":"length-change  확인",
            "tc":"WIDGET_ATTR_LENGTH_CHANGE",
            "result":"fail"
            }
        },
      "event":{
         "onclick":{
            "callback":{
                    "contents":"onclick 콜백 테스트 ",
                    "tc":"WIDGET_ONCLICK_CALLBACK",
                    "result":"fail"
               },
            "event":{
                  "contents":"wiget_event 파라미터 테스트",
                    "tc":"WIDGET_ROWCLICK_EVENT_PARAM",
                    "result":"block"
                },
            "widget":{
                  "contents":"내용222",
                    "tc":"WIDGET_ONCLICK_WIDGET_PARAM",
                    "result":"block"
                }
            },
         "ondblclick":{
            "callback":{
                    "contents":"내용333333",
                    "tc":"TC",
                    "result":"나온다"
               },
            "event":{
                  "contents":"내용333333",
                    "tc":"TC",
                    "result":"나온다"
                },
            "widget":{
                  "contents":"내용222",
                    "tc":"TC",
                    "result":"나온다"
                }
            },
        }
      
    },
   "widget2":{
      "api":{}
    }

}

와 같은 구조로 나왔습니다. 필요한 케이스는 맨 마지막 leaf에 존재하게 되는데

해당 길이를 잡고 Iterator를 하게되면  TC(TestCase) , TS(Test Suite) 가 추가 됐을때 그에 따른 순환하는 로직을 다시 

수정해주어야 하는 불상사가 발생하게 됩니다.

해당 의 구조를 그림으로 그려보게 된다면

다른 부분들은 생략 하고 위와같은 그림의 형태가 되는 것으로 보입니다.

1. 전체 테스트 케이스 

제가 필요한 Object (contents와 tc , result)  내용과 정형화된 TC(TestCase) , 결과 를 가지고있는 객체를 반환하여야 합니다.

위젯의 종류는 70개가 넘고 그에 따른 속성은 30여개 이벤트는 20개  정도가 됩니다.

그럼 위와같은 형태의 obj 의 수가 엄청나게 나올게 될것으로 보이는데

일단 순회하기 위해서는 tree구조에서 level-순회 의 형태가 되어야 합니다.

자료구조 - 이진트리 레벨순회 관련 포스팅 

https://m.blog.naver.com/PostView.nhn?blogId=4717010&logNo=60210351999&proxyReferer=https%3A%2F%2Fwww.google.com%2F

레벨순회의 특징이라 함은 트리 순회시에 현재  레벨에 있는 Root노드를

Queue 에 넣어 놓고 꺼내서 자식노드를 순서대로 순회하는 형태입니다. 

해당의 순회 방법으로 leaf노드를 가져오게된다면 전체 테스트케이스를 가져올수 있습니다. 해당 내용은 따로 포스팅

2. 필요한 테스트 케이스 

특정 위젯의 특정 속성 특정 내용

button 위젯의 icon 속성 에 대한 내용

Repo.button.attr.icon 와 같은 형태로 접근이 가능하기 때문에 위의 구조는 현재 제가 생각 하기에 최적의 구조라고 

생각이 됩니다. 전체 순회만 level - 순회로 해결을 하면 ( 사이드 이슈없이 )

특정 케이스를 가져오는 방법은 JavaScript의 Object 접근자를 통해서 그대로 접근하여 값을 가져올수 있기 때문에

문제가 될것이 전혀 없어 보이며 다른 QA가 해당 케이스를 추가 한다고 하게된다면 

순회는 재귀 형태로 되면 문제가 되지 않을 거라 생각 되며 접근자 형태는 문제 될점이 없어 보입니다.

후 같이 의논할수 있는 분이 있으면 참 좋겠지만 ㅜㅜ 아직은 없군용..

ETC

현재 구조를 짜는 형태를 가지고있는데 구조가 완료되면 Prototype이든 모듈패턴이든  모듈형태로 만들어서 사용할 

예정입니다. 단순히 걱정되는건 해당 Repo를 setter , getter를 통해서 제어를 하게 될텐데

퍼포먼스 문제가 있냐 없냐 입니다. 실제 서비스는 아니지만 그래도 적응 양은 아니며 자동화를 진행하게된다면 

웹드라이버가 진행하면서 setter , getter가 이 속도를 따라 올수 있냐의 유무를 실제 적용해보지 않고서는 

확증이 서진 않는 상황이지만 일단은 자동화 구조가 있어야 도니.. 일단은 해당 구조로 진행 해야겠네용