소프트웨어 回歸 ( software regression )는 以前에는 作動했던 機能이 作動을 멈추는 소프트웨어 버그 의 一種이다. 이는 새로운 機能 의 追加 및 버그 修正을 包含하여 소프트웨어의 소스 코드 에 變更 事項이 適用된 後에 發生할 수 있다. ^[1] 또한 시스템 업그레이드, 시스템 패치 또는 日光 節約 時間制 變更과 같은 소프트웨어가 實行 中인 環境의 變更으로 인해 發生할 수도 있다. ^[2] 소프트웨어 性能 回歸 ( software performance regression ) 는 소프트웨어가 如前히 올바르게 作動하지만 以前보다 더 느리게 遂行되거나 더 많은 메모리나 資源을 使用하는 狀況을 말한다. ^[3] 實際로 다음과 같은 다양한 類型의 소프트웨어 回歸가 確認되었다: ^[4]

• 로컬 ? 變更된 모듈 또는 構成 要素에 새로운 버그가 發生한다.
• 遠隔 ? 소프트웨어의 한 部分이 變更되면 다른 모듈이나 構成 要素의 機能이 損傷된다.

回歸는 種種 소프트웨어 패치 에 包含된 包括的인 버그 修正 으로 인해 發生한다. 이러한 種類의 問題를 防止하는 方法 中 하나는 回歸 테스트 이다. 適切히 設計된 테스트 計劃 은 소프트웨어를 出市하기 前에 이러한 可能性을 防止하는 것을 目標로 한다. ^[5] 自動化된 테스트 와 잘 作成된 테스트 케이스 를 통해 回歸의 可能性을 줄일 수 있다.

豫防과 感知 [ 編輯 ]

다음과 같이 다양한 開發 段階에서 回歸가 소프트웨어에 發生하는 것을 防止하기 위한 技術이 提案되었다.

出市 以前 [ 編輯 ]

 이 部分의 本文은 回歸 테스트 입니다.

最終 使用者 에게 릴리스 後 回歸가 나타나는 것을 防止하기 위해 開發者는 소프트웨어에 變更 事項이 適用된 後 回歸 테스트 를 定期的으로 實行한다. 이러한 테스트에는 로컬 回歸를 捕捉하기 위한 單位 테스트 와 遠隔 回歸를 捕捉하기 위한 統合 테스트 가 包含된다. ^[6] 回歸 테스트 技術은 種種 旣存 테스트 케이스를 活用하여 만드는 데 隨伴되는 努力을 最少化한다. ^[7] 그러나 이러한 旣存 테스트의 量으로 因해 테스트 케이스 優先 順位 指定 과 같은 技術을 使用하여 代表的인 下位 集合을 選擇해야 하는 境遇가 많다.

性能 回歸를 感知하기 위해 소프트웨어 性能 테스트 를 定期的으로 實行하여 後續 變更 後 소프트웨어의 應答 時間 및 資源 使用量 메트릭을 모니터링한다. ^[8] 機能 回歸 테스트와 달리 性能 테스트의 結果는 分散 의 影響을 받는다. 卽, 性能 測定의 分散으로 인해 테스트 間에 結果가 다를 수 있다. 性能 수치의 變化와 最終 使用者의 要求에 따라 回歸에 該當하는지 與否를 決定해야 한다. 이 決定을 돕기 爲해 統計的 假說 檢定 과 變更點 感知 와 같은 接近 方式이 使用되기도 한다. ^[9]

커밋 移轉 [ 編輯 ]

소프트웨어 回歸의 根本 原因을 디버깅 하고 局所化하는 것은 費用이 많이 들 수 있기 때문에, ^{[10] [11]} 애初에 回歸가 코드 貯藏所 에 커밋되지 않도록 하는 몇 가지 方法들도 存在한다. 例를 들어 깃 훅을 使用하면 開發者가 코드 變更 事項을 커밋하거나 코드 리포지토리에 푸시하기 前에 테스트 스크립트를 實行할 수 있다. ^[12] 또한, 코드 變更이 프로그램의 다양한 構成 要素에 미치는 影響을 豫測하고, 테스트 케이스 選擇 및 優先 順位 指定을 補完하기 위해 變更 影響 分析 이 소프트웨어에 適用되었다. ^{[13] [14]} 또한 소프트웨어 린터 는 一貫된 코딩 스타일을 保障하기 위해 커밋 훅에 追加되는 境遇가 많아 소프트웨어가 回歸하기 쉬운 스타일 問題를 最少化한다. ^[15]

局所化 [ 編輯 ]

非回歸 소프트웨어 버그의 根本 原因을 찾는 데 使用되는 많은 技術들인 브레이크포인트 디버깅 , 프린트 디버깅, 프로그램 슬라이싱 等은 소프트웨어 回歸 디버깅에도 使用할 수 있다. 아래에 說明된 技術은 種種 소프트웨어 回歸를 디버그하는 데에도 使用된다.

機能的 回歸 [ 編輯 ]

機能 回歸를 局所化하는 데 使用되는 一般的인 技術은 버그가 있는 커밋과 以前에 作業한 커밋을 모두 入力으로 使用하고 그 사이의 커밋에 對해 李瑱 檢索을 遂行하여 根本 原因을 찾으려 하는 二分法 이다. ^[16] 깃과 머큐리얼 과 같은 버전 管理 시스템은 주어진 커밋 雙에 對해 二分法을 遂行할 수 있는 基本 提供 方法을 提供한다. ^{[17] [18]}

다른 옵션으로는 回歸 테스트 結果를 코드 變更과 直接 聯關시키는 것, ^[19] 分期 中斷點을 設定하는 것, ^[20] 코드 變更과 關聯된 테스트 케이스(失敗한 것을 包含)를 識別하는 增分 데이터 흐름 分析 을 使用하는 것 ^[21] 等이 있다.

性能 回歸 [ 編輯 ]

프로파일링 은 프로그램의 다양한 構成 要素의 性能과 自願 使用量을 測定하며 性能 問題를 디버깅하는 데 有用한 데이터를 生成하는 데 使用된다. 소프트웨어 性能 回歸의 脈絡에서 開發者는 버그가 있는 버전과 以前에 作動하던 버전 모두에 對해 프로파일러에서 生成된 呼出 트리 ("타임라인"이라고도 函)를 種種 比較하며 이러한 比較를 單純化하는 메커니즘이 있다. ^[22] 웹 開發 道具 는 一般的으로 開發者에게 이러한 性能 프로필을 記錄할 수 있는 機能을 提供한다. ^{[23] [24]}

로깅은 또한 性能 回歸 局所化에 도움이 되며 呼出 트리와 類似하게 開發者는 同一한 소프트웨어의 여러 버전에 對해 體系的으로 配置된 性能 로그를 比較할 수 있다. ^[25]

이러한 性能 로그를 追加할 때 折衷點이 存在하는데, 많은 로그를 追加하면 開發者가 소프트웨어의 어느 部分이 더 작은 單位에서 回歸하는지 正確히 찾아내는 데 도움이 될 수 있지만 몇 個의 로그만 追加하면 프로그램 實行 時 오버헤드가 減少할 수 있기 때문이다. ^[26] 追加的인 接近 方式에는 局所化에 도움이 되는 性能 認識 單位 테스트 作成 ^[27] 및 性能 카운터 偏差를 基準으로 下位 시스템 順位 指定 等이 있다. ^[28] 또한 二分法은 性能 回歸를 위해 特定 基準 값 以下(또는 그 以上)를 遂行하는 커밋을 버그가 많은 것으로 看做하고 이 比較 結果에 기초하여 커밋의 왼쪽 또는 오른쪽을 取하는 것으로 使用할 수도 있다.

같이 보기 [ 編輯 ]

• 소프트웨어 腐敗
• 소프트웨어 老化

各州 [ 編輯 ]