내부적으로 열심히 테스트해서 등록하려고 보니 검증툴에의한
1.동작검증
2.소스검증
3.커버리지검증
4.API검증

T스토어 검증요청을 위한 네가지가 산출물이 추가가 되었네요.
동작검증하고, 소스검증에서 취약점이나 패턴수정은 그렇다고 쳐도
커버리지 검증에서 100%을 만족하지 않은 함수에 대해서 일일이
사유서를 작성해야 한다는게 보통 어려운점이 아닌것 같습니다.
주말내내 열심히 툴사용 익히고 하나씩 해보고 있는데..
함수커버리지 검증 부분은 OTL .. T T

소스코드중에는 확장을 고려해서 작성된 기능들이 있을것이고
여러가지 사유에의한 현재 기능에서 사용되지 않은 기능들이 많이 있는데.
단순히 툴에의해서 그함수를 실행했는지 안했는지 비율로만 따져서
이기능을 개발자가 열심히 테스트 했는지 안했는지 함수 호출했는지 
여부의 검증툴의 판단에의해서 100%에 가깝게 커버리지가 나오도록 만들어야 되네요.

공통함수들을 모아놓은 개발자가 모아놓은 공통 라이브러리  파일이나 그외 확장을 고려한 기능에 대한것은
커버리지 비율을 높이기위해서
내가 현재 사용하는 함수만 찾아서 놔두고
안쓰는것들은 다 소스를 삭제해서 정리해야 하는 상황은 너무 힘든 부분이고요.
그에따라서 모든 함수에 사유서까지 일일이 작성까지 해야 하고. 
테스트툴의 사용으로 인해서 승인요청되는 
많은 app들에 대해서 어느정도 개발자에게 테스트를 강제 할수는 있겠지만
그에따른 커버리지 수치로만 판단하기에는 다른 부분의 비용도 많이 들어가겠네요.