Testcase similarity - jjin-choi/study_note GitHub Wiki

Abstract

SoC 크기가 커짐에 따라 검증 자동화 / 효율화가 필수적이다.
- Regression automation 을 진행. 테스트들의 log, environments, 테스트들과 관련된 파일들에 대한 정보를 DB 화.
- 빠른 시간 내에 정확한 검증을 위해서는 경제적 (license) 및 시간적 효율화가 필요함을 느낌.
효율화 방안 중 하나로, 테스트 이름을 분석하는 시도를 하였다. (ref : 지천님 논문)
- 테스트 이름이 유사할 경우, 해당 테스트의 결과가 유사할 것이라고 가정하였고, 실제로 어느정도 효과가 있었다.
- 한계점은 이름만으로는 테스트 결과를 유추해내기가 어려울 뿐더러, 이름이 유사하더라도 전혀 다른 결과가 나오기도 하였다.
- 그러나 이 방식을 통해 테스트 간의 유사도를 분석함으로써 regression 효율화를 할 수 있을 것이라는 생각을 갖게 되었다.
따라서 우리는, 더 효과적인 방법을 모색하기 위해 DB에 쌓인 로그 데이터를 이용하여 테스트의 구성 요소를 파악해내고, 구성요소 간의 similarity 를 분석.
- 또한, big data 분석하기 위해 Spark, MongoDB 를 이용한 pipeline 구축하여 여러 측면에서 효율화.

가정
- 구성요소란 ? Task Class Function Sequence
- 로그 분석을 통해 에러가 발생한 구성 요소를 파악할 수 있다.
Phase 1 : 테스트 로그 파일에서 테스트 구성 요소 파악. 구성요소를 vectorize 하여 cosine distance 계산
- Phase 1 을 통해서 비슷한 동작을 하는 테스트들을 파악해 낼 수 있다.
- Phase 1 결과로 Testcase clustering 을 하여 대표 testcase (centroid) 를 추출해 낼 수 있다.
- 각 cluster 의 centroid 테스트들을 수행한다. (전체 중 10~20%, license 상황에 맞게 조절 가능)
Phase 2 : 로그 파일에서 나타난 Error를 분석하여, 해당 error 가 발생한 구성 요소에 대해서 기존 distance 의 weight 조정하여 similarity 다시 계산
- Phase 2 를 통해서 에러가 발생한 구성요소를 파악하고 cluster 를 다시 생성한다.
- Phase 2 에서 재생성된 cluster 내에 존재하는 테스트들도 동일한 Failure 가 발생할 지 예측할 수 있다.
해당 테스트의 디버깅이 완료되어 pass 되면, 그 cluster 에 속한 테스트들도 수행하도록 자동화 가능.

추후 ML Training 을 통해 Failure prediction 예측 성능 향상 (Proposed method 에 포함시켜도 되고...)
Similarity 가 매우 높은 테스트는 pruning 할 수도 있음
Version 변경으로 로그 데이터가 없을 경우에는 기존 분석 결과에서 difference 가 발생한 것을 기반으로 clustering 할 수 있음