如果給一個可以做自動化的專案，你要怎么做自動化？
專案-8大模塊-2000左右用例數
1.熟悉業務==需求檔案/手工測驗/產品聊，了解模塊之間的關系/測驗人員
專案目前的一個階段、棘手的問題（不僅寫自動化代碼，能幫別人用代碼解決繁瑣的問題），
2.分析----系統中哪些模塊比較適合做自動化、哪些模塊不適合
- 歷史穩定性，功能的復雜性（功能太過于復雜就不適合做自動化，從相對簡單的模塊入手）
- 核心模塊（每個系統都有自己非常核心的模塊）
- 使用頻率模塊，哪一個模塊bug率目前偏高（這個模塊經常出歷史功能的問題）
- 測驗團隊、產品團隊中與用戶接觸的比較高的人開個會交流下，看下哪個模塊需要做比較高的維護作業
- 篩選了2個模塊 400個測驗用例
- 如果是介面，就看介面有多少個，每個介面要設計多少個用例
- 介面自動化用例需達到80-100%
「先分析在哪一個模塊來做，能夠得到最快的產出比，能夠最快的看到效果，」
分析之后，預估先做1個或者某2個模塊的自動化測驗，
3.功能測驗===400個==從功能測驗用例中去篩選自動化用例==核心模塊的核心功能、主流程、主功能點==140個用例==用例評審（產品、測驗、測驗經理開會交流進行決定）
先對模塊做用例設計，如果你參與了手工測驗程序，就了解這個專案的模塊，
因為目前不知道專案要做多久的時間，人員安排，階段安排怎么算，具體也不了解這2個模塊的具體情況，也不知道這2個模塊大概有多少用例要做自動化測驗，不知道用什么框架去做自動化測驗，所以測驗計劃和方案可以放后，
web自動化最大的目的就是負責主流程，例外流程分情況，如果它容易實作沒有太大難度就可以做，如果例外場景比較極端，條件準備比較復雜，就可以不去實作它的自動化，先把主流程實作，后期酌情增加例外場景，
做自動化測驗需要領導支持的，不然他給你大量的功能測驗的作業，如果就你一個測驗，就根據上面的3點，自己進行篩選，做完和上級領導匯報一下，告訴他為什么這么選，選出來的結果是什么，領導肯定會問自動化測驗計劃，
4.自動化計劃
「自動化型別：web/api」
1.寫清楚前提，為什么選擇了這2個模塊，為什么選擇了這140個用例，
2.告訴領導，還要花1-2周時間進行「框架選型：」 如果是自己一個人，自己寫代碼順手就寫代碼實作，如果熟悉其它的框架就用其它的框架，如果團隊有其他人，別人的水平不如你的時候，就要考慮成本代價，如果都用寫代碼，例如我很懂寫代碼實作自動化，他們卻不懂，他們做不起來怎么辦呢？「框架選型主要考慮的是團隊人員的水平，」 如果比你差太多了就不要選代碼了，就選個容易上手的框架，
「團隊人員」是多少：如果就自己，就寫1，如果還有人輔助你，就寫2
「1-2周時間里需要搭建框架」（準備好整體的一個結構，什么層放什么東西），定規范（在哪寫測驗用例，怎么設計測驗用例，斷言里面要怎么設計，有些全域框架方面的內容，其他自動化測驗人員發現了可以告訴我，我來優化，其他自動化測驗人員只改他們能改的部分就可以）
「時間規劃:」 用例撰寫，2個半月，
「效果：」 評估下覆寫率是多少-用例通過率（如果通過率只有40%，那么就沒必要去做自動化了）-跟專案測驗進度結合
自動化計劃在正式做之前，應該做個PPT或者excel檔案，找個機會跟領導講大概的計劃，這是初期的計劃，后期根據情況肯定有變動，就是讓領導知道你有自己的計劃，
可以寫完一個模塊先用一個，發一次測驗報告，不可能全部的自動化測驗用例寫完再發測驗報告，
140功能用例數/平均每天做的web自動化用例數=天數
介面功能用例數/每天做的功能自動化用例數=天數
每個人寫的測驗用例，用例粗細度是不一樣的，所以導致每個人每天寫的自動化用例數不一樣，
以上4點，介面自動化和web自動化前期準備作業是一樣的，具體根據業務場景復雜度，公司專案規模等情況而定，
怎么搭建公司自動化框架？
我們平時做專案，大體框架都是一樣的（常用的組態檔，日志檔案等都封裝成模塊），需要套不同的業務場景，進行優化細化，如果換了專案，就把原來的業務上的case洗掉，可以做新的業務，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/248929.html
標籤：其他
上一篇：【簡潔明了】怎么做介面測驗？