1.參與需求制定評審，根據需求編寫測試計劃，設計測試用例？
（1）參與需求制定評審？
評審原因：
由於軟件系統的複雜性，在需求分析階段可能存在着開發方對委託方業務需求理解不全面、不準確的情況。在這種情況下，如果不進行相關的質量控制，往往會造成開發結果與用戶需求不一致的後果。需求測試的目的就在於保證軟件設計最大可能地滿足有關用戶的所有需求，降低額外風險和未預料的成本。
評審人員：
需求評審必須要有用戶或用戶代表參與，同時還需要包括項目的管理者、系統工程師、相關開發人員、測試人員、市場人員、維護人員等。在項目開始階段就應當確定不同級別、不同類型的評審必須要有哪些人員的參與，否則，評審可能會遺漏部分人員的意見，導致需求的缺失。
評審需求：
完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。正確性：每一項需求都必須準確地陳述其要開發的功能。
一致性：一致性是指與其它軟件需求或相關標準規定不相矛盾。
可行性：每一項需求都必須是在已知系統和環境的限制範圍內可以實施的。
無二義性：對所有需求說明都只能有一個明確統一的解釋，由於自然語言極易導致二義性，所以儘量把每項需求用簡潔明瞭的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，並且對這些異常進行了容錯處理。
必要性：每項需求的制定都是必要的且能夠追溯的。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求只應在軟件需求說明書中出現一次，這樣更改時易於保持一致性。
可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接，這種可跟蹤性要求每項需求以一種結構化的方式編寫並單獨標明。
https://blog.csdn.net/qq_27495157/article/details/79740518
（2）編寫測試計劃？
編寫測試計劃的原因：
1）領導能夠根據測試計劃做宏觀調空，進行相應資源配置等；2）測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等；3）便於其他人員瞭解測試人員的工作內容，進行有關配合工作。
測試計劃包含內容：
1）why——爲什麼要進行這些測試； 2）what—測試哪些方面，不同階段的工作內容； 3） when—測試不同階段的起止時間；4）where—相應文檔，缺陷的存放位置，測試環境等； 5） who—項目有關人員組成，安排哪些測試人員進行測試； 6） how—如何去做，使用哪些測試工具以及測試方法進行測試。
（3）設計測試用例？
設計測試用例的原因：
測試用例（Test Case）是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求，通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。理清思路，避免遺漏----跟蹤測試進度進展----迴歸測試----歷史參考。
編寫用例：
- 測試需求分析，得到測試點
在測試需求分析階段，只有需求文檔，所以編寫測試用例的唯一依據就是需求文檔，因此在進行用例編寫之前一定要進行需求分析，需求分析的主要工作就是：瞭解需求的整個實現背景；分析需求的合理性；明確需求的範圍，挖掘需求文檔中隱藏的需求；在通過需求交底的過程，確定開發的初步實現思路和方法，隨着測試需求分析的深入，列出需求的框架，包括測試範圍即各個功能點，測試的場景等；確定一些測試可以提前介入的工作等；需要說明的是對於需求中的問題一定要記錄下來，找需求確認，需求漏掉的或者存在問題的地方，開發和測試更容易漏掉，而且遺漏的需求很有可能會使得項目整體業務邏輯發生變化，一定要及時提前確認。 - 分析得到用例優先級
得到了需求的各個測試點後，應該先將這些測試點簡單的分配一下優等級，一般分爲高中低三個優先級，得到優先級後可以讓需求用例的設計更有側重和着重點。
3）細化測試點變成可執行case
根據測試需求分析得到的需求框架，梳理細化測試點，這裏的測試點雖然粗，但是不應該有遺漏，這是進行測試點細化的前提。根據測試點，細化出具體的測試用例，要注意各個點的組合測試的情況，還要注意各個測試點的反向測試的情況。
在細化測試點的時候，可以要參考以前寫好的公共測試用例，甚至可以直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。
另外需要考慮的就是測試點細化到什麼程度的問題，也就是一個度的問題，要把握好測試點細化的一個度的問題，太粗的測試點沒有指導意義，太細的測試點容易糾的太細，忽略整體的測試，反而也起不到一個指導的效果，所以一定要把握好測試點細化的度。
4）及時更新測試用例
需求分析和用例編寫階段，是主要的細化用例時間，這段時間的目標是梳理出可指導執行測試的用例，但是需求會有變動，需求會有維護，用例也一樣，所以用例是需要持續維護的， 所以在需求變動的同時，我們也要及時維護測試用例，否則的話，測試用例很可能成爲一個錯誤的指導。
另外測試用例完成後就會進入一個用例評審的階段，在用例評審階段，會有用例評審人，針對你的用例作出的評審，主要檢查你的用例是否有測試點遺漏，場景遺漏，測試case描述模糊，測試結果輸出模糊等問題，針對用例評審人提出的問題，我們也要及時的更改我們的用例。
5）及時維護通用測試用例
項目中或者跨項目中很多的公用業務，固化模塊，這些功能基本上是趨於穩定不變的，因此可以梳理出通用的比較全面的測試點，作爲指導和規範業務和模塊的規範，這些生成的規範即通用的測試用例。當我們針對某一模塊或者業務持續維護時，就發現我們需要持續維護這的用例，就會發現有些用例業務類似、執行步驟一致、驗證項屬性一致等等，這個時候通過梳理業務的通用屬性，通用用例梳理梳理成章。所以說，通用的測試用例是一個對用例不斷維護的產出，因此我們在測試軟件維護的過程中一定要及時的更新通用測試用例，對後面的測試和用例維護有一個很大的指導作用。
https://www.cnblogs.com/hanxiaomin/p/6132811.html
2.測試執行、過程跟蹤和進展彙報？
bug的質量：所謂質量，是指測試人員錄入bug描述的清晰度，越容易理解的bug，質量越高。開發跟測試之間也不用花費大量時間去理解該bug如何修改合適。
如何錄入一個合格的bug
1）發現問題的版本
一般來說，在不同版本發現同一個Bug,有可能是由於不同原因產生的。所以如果在版本1.1修改完該Bug後，在版本1.2又發現了該bug，不應該把版本1.1的bug激活，而應該重新錄入一個bug，版本改爲1.2。因爲這是一個新增的Bug,測試人員需要重新驗證，統計。如果激活上一個bug也可能造成質量統計時的漏算。
2）問題出現的環境
問題出現的環境包括操作系統環境、軟件配置環境，有時候還需要包括系統資源的情況，因爲有些錯誤只有在資源不足時纔出現。由於開發環境與測試環境存在差異，往往導致有些問題只有在測試環境下才能出現。例如開發環境中使用的某些第三方組件在測試環境沒有註冊。這時測試人員應該把這些差異寫清楚，以便開發人員在重新問題和進入調試之前把環境設置好。
3）問題重現步驟
描述問題出現的操作步驟。要儘量把操作步驟縮減到必須執行才能重新錯誤的幾個步驟。別浪費步驟在無關問題上面，影響重現進度。
4）預期行爲的描述
需要讓開發人員知道什麼纔是正確的。有些描述不清的，如“編輯單據時，列表中不出現日期信息”，那麼你是希望他出現日期呢，還是不出現日期呢？一般描述就加上XX應該XX或者SS不應該SS。
5）錯誤行爲的描述
描述問題的現象。例如“程序拋出異常信息如下。。。”，如實反映，不要誇大。
除了以上，還有嚴重程度，優先級別，出現模塊，缺陷類型，發現日期等等，一般在缺陷管理系統中都會提示填寫。
https://www.cnblogs.com/xiaoqingSister/p/5471156.html
3.軟件發佈、版本管理以及相關文檔維護？
1）創建和維護髮布/項目信息/組件的信息；2）創建和維護測試每個特定版本的組件、週期，需求，測試用例等。3）建立測試資產之間的可跟蹤性和覆蓋率。4）測試執行的支持-創建測試用例集，捕獲測試的執狀態等。5）度量收集/報告-圖表之間的分析；6）Bug跟蹤/缺陷管理。
7）公司發佈正式版本給客戶時，會連續幾天頻繁發佈正式版本，且每個版本改動特別小，不影響別的模塊，每天都有小的改動併發布版本時：保證修改東西正常且修改東西所相關所有東西都正常。保證此項目的所有主功能流程正常。保證此項目的主模塊流程正常，比如直播軟件，每次發版本必須對直播多測幾遍。
8）有以下幾個特點的項目比較適合自動化測試： 項目變動少，週期長，項目資源足夠（自動化不是一個人完成的，需要一幫人長期維護）
4.服務器、svn、gitlab的日常維護？
（1）服務器日常維護：定期更換密碼，不要隨意開啓遠程端口，不下載東西至服務器，定期備份。
安裝和設置防火牆，定期對服務器進行備份，及時安裝系統補丁，關閉不需要的服務和端口，賬號和密碼保護，安裝網絡殺毒軟件，監測系統日誌。
(2）SVN(Subversion)：
使用SVN的原因：程序員編寫程序的過程中,每個程序都會生成很多不同的版本，需要程序員能有效的管理代碼,在需要的時候可以迅速準確取出相應的版本。
SVN日常維護：
- 創建版本庫，並定期備份
- 確定存儲目錄結構，並定期檢查
- 分配和維護用戶權限
- 對基線進行管理
- 對變更進行管理
- 對發佈進行管理
使用SVN做這些事情，上述前三項是基本操作。第4項是通過在tags文件夾做標記實現的；第5項嚴格來說需要其他輔助工具，簡單做的話可以通過在branches文件夾拉分支出來再合併回trunk實現；第6項也是通過在tags文件夾做標記實現。
(3) gitlab的日常維護
GitLab是一個自託管的Git項目倉庫，可以自己搭建個人代碼管理的倉庫，功能與github類似。
1)創建項目;2)添加分支;3)默認分支設置;4)項目分組（權限控制);5)保護master分支，不允許被push;6)上傳、下載、分支、更新、回滾。