對任何軟體產品來說，軟體上線永遠是一件大事，完全確保所有功能生效以及發布高質量軟體給用戶非常重要，
不好的、不成熟的、不穩定的、難以使用的產品會引發重大經濟損失，還會讓用戶對品牌本身失去信任，
我們通常聽到當軟體符合上線標準時，測驗就應該結束了，我們也聽到軟體缺陷必須被修復以達到軟體上線標準，
然而，這些都是偉大的冠冕堂皇的準則，太模糊了，
更確切地說：
· 多少比例的軟體缺陷對軟體上線來說是可接受的？
· 你如何決定哪些已知軟體缺陷不影響軟體上線？
· 哪種軟體缺陷更緊急更嚴重？
你曾聽到過這些問題嗎？那么這篇文章將幫助你揭曉答案，
復雜的軟體不是沒有軟體缺陷，相對于可運行的軟體來說，關掉缺陷是一個雞和蛋的故事，
修復的缺陷越多，修復缺陷時產生的新缺陷的可能性越大，那么，
· 你如何決定軟體上線時可附帶的缺陷程度以及缺陷型別？
· 你如何確定軟體上線時的部署基準？
· UAT測驗人員如何決定軟體是否上線？
· 哪些引數應該用于評判軟體質量？
· 如何回答-軟體是否適用并會為利益相關者帶來價值？
上線到生產環境對客戶方和合同方來說都是一個大的里程碑，因為這關系著付款里程碑，雙方對確保大型轉型專案的成功都有著同等的責任，
我的經驗表明客戶想要高性價比并且提供了UAT上線標準，
· 功能
· 性能和負載
· 可用性
· 安全性
· 與外部系統的互動性
· 報表
· 資料遷移
我堅信每一個這些型別的軟體缺陷都需要被進一步解釋，而且，那是我們現在的確要做的事情：
功能缺陷
如果軟體是根據客戶提供的需求開發的，那么它必須滿足需求，功能的任何偏離被錄為功能缺陷， 根據嚴重性和優先級功能缺陷被分類，
如下是重要的考慮因素：
高嚴重性和高優先級的軟體缺陷通常會影響軟體的日常使用，這些型別的軟體缺陷必須在軟體上線前被修復，沒有例外，
有時候功能缺陷由于不是原始需求的一部分被劃分為需求變更，這些需求變更在軟體上線后對業務運作是必須的，因此必須被實作，
軟體缺陷的劃分和功能缺陷的優先級劃分是由UAT協調人員和用戶以及需求分析人員共同完成的，通常，客戶有一個關于多少比例的軟體缺陷可以存在的上線標準
性能以及負載缺陷：
性能缺陷是軟體上線的重要考慮因素，尤其是軟體被外部用戶使用，
如果用戶量達到一定數目時，軟體運行很慢，用戶會因為加載耗時而避免使用軟體，如果軟體太慢會導致業務流失，用戶會轉而使用競爭對手的軟體，
有時候，非客戶面對的部分程式也會影響軟體性能，
比如: 如果每天結束時要運行一個批處理任務，程式的回應時間因此而受到影響，那么批處理的性能也是一個考慮因素，
· 軟體性能通常用螢屏回應時間來衡量，當特定數量的并發用戶使用系統時性能對用戶而言就必須考慮，
· 性能測驗用工具來完成，比如LoadRunner，WebLoad，Neoload等
· 特定負載和未來預測負載的軟體性能通常記錄在合同里，在軟體上線前必須要證明，
· 用戶很少用到的部分程式頁面延遲到系統上線后再評估，
· 軟體性能也依賴于部署軟體的硬體型別和網路條件，
· 性能測驗在特定硬體里使用性能測驗工具在UAT階段完成，性能缺陷以類似于功能測驗的方式來追溯，性能缺陷也會被劃分優先級，達成一致以符合上線標準，
· 通常在UAT階段的性能和負載測驗在用戶做完功能測驗并且達到功能缺陷交付標準后完成
可用性缺陷:
軟體開發應該易于終端用戶使用，比如用不同的快捷鍵、快捷方式，最少的螢屏切換、換頁，軟體必須靈活并且直觀，
如果在移到合適的螢屏之前有太多頁面切換，用戶通常會對使用這個軟體失去信心，
· 軟體構建前可用性準則被創建，軟體必須遵循這些準則，
· 軟體開發時也可能有工具限制，在軟體被終端用戶使用前必須克服這個問題，
· 用高可用性軟體，一個終端用戶可以輸入常規軟體5倍的資料，
· 軟體的外觀和感受必須是新鮮的，同時法律問題必須在軟體上線前被列出來，
· 很多時候軟體可用性顧問被任命來確保用戶可以流暢地使用軟體，
· 必須和軟體程式一起交付的檔案也必須盡可能合法使用且嚴格遵循可用性準則，
· UAT/外部測驗人員錄入的可用性缺陷像功能缺陷和性能缺陷一樣也被劃分了優先級，必須符合上線準則
安全性缺陷:
軟體的安全性是一個熱點問題，因為軟體程式可能被黑客攻擊，客戶敏感資料可能被竊取，
因此，可信賴的軟體不應該允許甚至一個非常專業的黑客以不合適的權限進入程式，
· 安全性測驗是在UAT階段以特定輸入來確保軟體不被攻擊，
· 安全性測驗由合法黑客來嘗試攻擊軟體以檢查軟體是否脆弱，
· 所有安全性缺陷必須在系統上線前被修復，
· 安全性也意味著登錄、不同權限的用戶（內部和外部）使用程式的不同部分，以及創建和批準資料
與外部軟體系統互動性缺陷:
通常，一個要在客戶方部署的軟體程式必須與任何已有軟體互動，
比如:
列印系統，他們已經在使用中或者可能是一個外部系統比如賬單程式或者資料熒屏系統，將要部署的軟體程式應該與這些外部系統無縫互動，對這些系統的所有輸入和輸出應該同步作業，當前技術包含了移動應用程式和必須與之兼容的不同軟體平臺，
檢查外部系統的互動性應該在系統測驗階段和UAT階段被廣泛執行，必須有一個滿意的上線準則
報表缺陷:
來自軟體程式的報表是表明程式內部資料統計的一種關鍵方式，
比如:所有賬單相關資料必須符合借貸額度，
· 軟體中所有資料必須協調，軟體里的這種資料協調通過報表來展現，必須達到期望，
· 如果資料從舊系統遷移到新系統是當前版本發布的主要目的，那么更要關注報表資料
資料遷移缺陷:
如果一個舊系統要被新系統取代，舊系統里的資料要移到新系統，新系統應該如需求定義的一樣支持遷移過來的資料，
所有舊資料可能在新系統里不可用；然而舊資料的截圖會在新系統中可用，按約定，這個資料應該可用，
注意:上述串列并不詳盡，根據程式型別，可能有更多的東西需要驗證或者并不是上述所有都適用，因此，對軟體的全面理解，業務目的，用戶期望以及架構或硬體依賴對創建綜合的上線準則是必須的，
軟體上線標準示例:
這只是一個例子，具體情況因專案不同而不同，
· 優先級為1的軟體缺陷要100%關掉（嚴重性為嚴重且優先級為1）
· 90%的優先級為2的軟體缺陷（嚴重性為高且優先級為2）要被修復，對剩余10%的缺陷必須有變通方案，并且對關掉剩余10%的缺陷要有一個可行計劃，
· 生產環境部署清單以及可用性檢查清單已經準備好，
· 生產環境支持團隊已成立并準備好解決問題，
· 70%的優先級為3的缺陷被解決并且有一個取代計劃來解決剩余30%的低優先級缺陷，
值得注意的幾點:
· 所有嚴重性以及優先級定義是在專案開始時客戶方和合同方在業務會議上決定的，
· 在所有UAT缺陷被記錄并且所有其他缺陷被解決后，UAT協調人員和業務發起人碰頭對未解決的缺陷進行評估
總結
我們希望這篇文章對創建穩固的上線標準以防止軟體在生產環境里受到潛在缺陷影響的一些重要思考已經給了你一些見解
最后感謝每一個認真閱讀我文章的人，看著粉絲一路的上漲和關注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：
這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你!
在我的QQ技術交流群里（技術交流和資源共享，廣告勿擾）
可以自助拿走，群號：310357728群里的免費資料都是筆者十多年測驗生涯的精華，還有同行大神一起交流技術哦
如果對你有一點點幫助，各位的「點贊」就是小編創作的最大動力，我們下篇文章見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/298933.html
標籤：其他
上一篇：??Python實用工具之制作證件照（有界面、附原始碼、贊關藏）??
下一篇：[leetcode篇]重排鏈表