文章目錄

• 第1章 軟件測試概述&需求分析
• 課程內容
• 本課目標
• 軟件的概念
• 軟件的特點
• 軟件的本質
• 軟件的分類
• 軟件項目團隊構成
• • **項目經理**
  • 需求分析員
  • **UI設計師**
  • **軟件開發工程師**
  • 實施工程師
  • **運維工程師**
• 什么是軟件測試
• 正確理解軟件測試
• 錯誤理解軟件測試
• 軟件測試的歷史發展
• 軟件測試的重要性
• • • 事故1：阿麗亞娜 5 型運載火箭
    • 事故2：奔騰的長除法
    • 事故3：1987 年的華爾街崩盤
    • 事故4：千禧危機
    • 事故5：癌癥治療與致死性放射治療
    • 事故6：愛國者導彈
    • 事故7：洛杉磯國際機場的航班停飛
    • 事故8：Bug 葬送了日本 18 億元的最新衛星
    • 事故9：溫州7.23 動車事故
    • 事故10：12306連現故障：上午近乎癱瘓下午爆串號門
    • 事故11：男子趁ATM機出錯惡意提款171次被判無期
• 軟件測試的目的
• 軟件測試的原則
• 測試人員應具備的素質
• • 必備技能
  • 輔助素質
• 當工匠精神遇到公司快速發展、激烈的競爭，測試該如何破局？
• • 工匠精神
  • 如何破局？
• 常見軟件系統架構
• • B/S架構
  • • 優點
    • 缺點
    • B/S架構的幾種形式
    • • **第一種：客戶端-服務器-數據庫**
      • **第二種：客戶端－web服務器－應用服務器－數據庫**
      • **第三種方法：客戶端－負載均衡器(Nginx)－中間服務器(Node)－應用服務器－數據庫**
  • C/S架構
  • • 特點
    • 優點
    • 缺點
    • C/S架構的類型
    • • 一層架構
      • 兩層架構
      • 三層架構
  • B/S 與 C/S對比
  • 發展前景
• 常見面試題
• 軟件測試的分類
• • 按開發階段劃分
  • 按是否查看代碼劃分
  • 按是否運行劃分
  • 按是否手工測試劃分
  • 按其他劃分
• 軟件測試流程
• • 軟件測試流程圖
  • 軟件測試過程主要工作內容
  • 測試小組的運行
• 軟件生命周期模型
• • 一 什么是模型
  • 二 軟件開發模型
  • • Ⅰ 瀑布模型（waterfull）
    • • A 定義
    • Ⅱ 快速原型模型
    • • 定義
    • Ⅲ 螺旋開發模型
    • • A 定義
      • B 優點
      • C 缺點
    • Ⅳ 軟件開發增量模型
    • • A 定義
      • B 增量模型的優點
      • C 增量模型的缺陷
      • D 增量模型的要求
  • 軟件測試模型
  • • Ⅰ V模型
    • Ⅱ W模型
    • Ⅲ H模型
  • 敏捷開發模型（Agile software development)
  • • • 敏捷開發原則
      • A 定義
      • B 專有名詞解釋
      • • Product Owner
        • Scrum Master
        • Sprint
        • 迭代過程（Iterative process）
        • 用戶故事（User stories）
        • 任務（Tasks）
        • 站立會議（Stand-up meeting）
        • 持續集成（Continuous integration）
        • 最簡方案（Simplest solutions）
        • 重構（Re-factoring）
      • C 優點
      • D 缺點
  • 敏捷開發中的測試
  • • 1、傳統測試VS敏捷測試
    • 2、敏捷人員需要做到
    • 3、敏捷開發團隊介紹
    • 4、測試人員需要具備的素質
    • 5、 測試人員的主要職責
    • 6、測試人員的主要工作
    • • 對各階段相應的測試活動作詳細的介紹和分析
  • DevOPS
  • • • DevOps的起源
      • DevOps到底是什么
      • 舉例說明什么是devOPS
      • 部門之間關系
      • DevOps的發展現狀
      • DevOps與虛擬化、容器、微服務
• 面試題
• 需求分析
• • 軟件需求
  • • 軟件需求的重要性
    • **客戶項目統計數據**
  • 需求分類
  • 測試需求
  • 需求分析對于開發和測試的影響
  • 測試需求分析
  • 需求挖掘
• 軟件開發文檔評審
• • 什么是評審？
  • 測試文檔評審
• 文檔評審的形式（理解，不需要記憶）
• • 擴展（了解）
  • • 代碼走查
    • 代碼審查
• 練習
• 代理商項目安裝
• • • 代理商（AgentSysment）系統
    • • LINUX上系統安裝
      • • 訪問地址：
      • Windows上系統安裝
      • • 訪問地址

第1章 軟件測試概述&需求分析

課程內容

• stage1（階段1）

  • testTheory

    • 測試概述，需求分析，用例，測試方法，缺陷，通用技術，計劃，總結等
    • 通過上課提問，作業和筆記的把握來讓學生們理解和記住面試相關問答，培養學生測試角度的思維

  • linux

    • linux命令精講，目錄和文件管理，安裝和程序管理，賬號和權限管理
    • 通過虛擬機演示，讓學生了解linux的基本知識，能夠掌握基本的shell命令。為后面搭建虛擬機環境做準備。

  • projectManagement

    • Mantis，TestLink，SVN，GIT，等

  • 將AgentSystem項目項目融入到項目管理相關工具里，包括Mantis，TestLink，禪道，SVN，GIT），讓學生了解在windows和linux上怎么搭建環境，了解項目全流程中測試參與的相關內容。并掌握navicat，xshell，xftp配套工具的使用。

• stage2（階段2）

  • 01 Web&HTML
    • 走進HTML，css美化，html5新增元素和屬性，javascript基礎，javascript BOM，javascript表單驗證
    • 掌握前端基礎頁面知識，為UI自動化打基礎。
  • 02 Python
    • 初識Python，流程控制語句，常用數據結構，函數與模塊，項目實訓-在線投票系統
    • 掌握python的基本代碼編寫，為后期學習自動化做鋪墊
  • 03 InterfaceTesting
    • 第1章 接口測試基礎，第2章 使用Postman進行接口測試，第3章 Fiddler基本使用，第4章 Fiddler高級使用，第5章 抓包工具Charles的使用，第6章 接口自動化測試實戰
    • 理解接口測試，掌握接口相關工具（postman，fidder，charles，jmeter）等工具
  • 04 Database
    • 第1章 初識MySQL數據庫，第2章 創建MySQL數據庫和表，第3章 MySQL數據庫數據管理，第4章 使用DQL查詢數據，第5章 安裝操作MongoDB
    • 掌握sql語句。了解mysql之外的其他常用數據庫。

• stage3（階段3）

  • 01 JavaBase
    • 第1章 初識Java，第2章 變量和數據類型，第3章 選擇結構，第4章 循環結構，第5章 雙重循環與跳轉，第6章 數組，第7章 方法，第8章 封裝&異常
    • 和python語言對比，學會java語言的基本編寫。為自動化做鋪墊。
  • 02 Docker
    • docker基本管理
    • 了解docker技術，理解docker項目部署分離技術
  • 03 PerformanceTesting
    • 第1章 軟件性能測試基礎，第2章 JMeter入門及腳本錄制，第3章 JMeter常用測試元件，第4章 JMeter性能測試腳本開發，第5章 性能測試項目實戰，第6章 LoadRunner入門，第7章 LoadRunner腳本增強，第8章 LoadRunner場景設計及監控，第9章 LoadRunner結果分析
    • 掌握jmeter和loadrunner，結合實戰，可以進行基本的性能測試
  • 04 UIAutomatedTesting
    • 第1章 軟件自動化測試基礎，第2章 TestNG框架介紹，第3章 Selenium基礎，第4章 Web自動化測試實戰，第5章 Robot Framework基礎，第6章 Robot Framework Web自動化測試，第7章 持續集成自動化測試
    • 理解何為自動化，自動化的selenium技術，TESTNG框架，uittest框架，Robot Framework框架等目前自動化領域流行的技術
  • 05 MobileTesting
    • 第1章 移動端測試入門，第2章 Appium自動化介紹和環境搭建，第3章 Appium常用操作，第4章 移動端自動化測試項目實戰
    • 掌握appium的安裝，結合appium+selenium+python編寫自動化代碼
  • 06 SecurityTesting
    • 第1章 安全性測試基礎，第2章 安全性測試工具的使用
    • 了解安全測試的攻防技術，可以使用AppScan進行安全測試掃描

本課目標

記憶測試理論中可能要面試的概念

? 什么是軟件測試？軟件測試的原則有哪些？

理解各角度的軟件測試分類劃分和具體使用場景

了解項目內各職位所負責的工作，和測試工作的配合關系

理解常見系統架構

記憶軟件測試的流程

理解軟件生命周期模型，了解敏捷測試，理解devOPS。

可以使用《需求分析跟蹤矩陣》來分析挖掘測試需求，可以使用xmind來理解挖掘測試需求

軟件的概念

軟件=程序+文檔

• 程序：指能夠實現某種功能的指令集合
• 文檔：指軟件在開發、使用和維護過程中產生的圖文集合

軟件測試=程序測試+文檔測試

軟件的特點

1.軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。（代碼+數據等邏輯組成的集合，實現各種功能，解決各種問題）
2.軟件的生產與硬件不同，它沒有明顯的制造過程。要提高軟件的質量，必須在開發方面下功夫。
3.在軟件的運行和使用期間，不會出現硬件中所出現的硬件老化和磨損問題，因而它存在退化功能，必須要對其進行多次修改與維護，直至其“退役”。
4.計算機的開發與運行常常受到計算機系統的制約，它對計算機系統有著不同程度的依賴性。
5.軟件的開發至今尚未完全擺脫人工的開發方式。
6.軟件本身是復雜的。軟件的復雜性可能來自它所反映的實際問題的復雜性，也可能來自程序邏輯結構的復雜性。
7.軟件成本相當昂貴。軟件的研制工作需要大量的、復雜的、高強度的腦力勞動，它的成本是比較高的。
8.相當多的軟件工作涉及社會因素。許多軟件的開發和運行涉及機構、體制及管理方式等問題，它們直接決定項目的成敗。

軟件的本質

如果把軟件和硬件分開理解，軟件就是一種“邏輯”，不同的軟件就代表各種不同的邏輯，而各種不同邏輯的背后其實就是一種解決問題的方式。

軟件的本質是信息處理，以及對信息處理的自動化。在軟件系統中，數據是信息的載體，是對客觀事物所蘊含信息的抽象描述。軟件對數據的處理包括：Define（定義），Transfer（傳遞），Transform（轉換），Store（存儲），Retirval（檢索），Show（展示）。

人-軟件-硬件-驅動機器做人想做的事情。

軟件的分類

• 系統軟件
  • 如windows、Linux、UNIX等，還包括操作系統的補丁程序及硬件驅動程序，都是系統軟件類
• 應用軟件
  • 工具軟件、游戲軟件、管理軟件

軟件項目團隊構成

項目經理

項目經理負責分配資源，確定優先級，協調與客戶和用戶之間的交往。總而言之，就是盡量使項目團隊一直集中于正確的目標。項目經理還要建立一套工作方法，以確保項目工件的完整性和質量。
構架設計師
構架設計師負責在整個項目中對技術活動和工件進行領導和協調。構架設計師要為各構架視圖確立整體結構：視圖的詳細組織結構、元素的分組以及這些主要元素組之間的接口。因此，與其它角色相比，構架設計師的見解重在廣度，而不是深度。

需求分析員

業務分析員通過概括和界定作為建模對象的組織來領導和協調業務用例建模。例如，確定存在哪些業務主角和業務用例，他們之間如何交互。通過描述一個或幾個用例的需求狀況以及其他支持軟件的需求來獲取系統功能某一部分的規約。還要負責用例包并維護該用例包的完整性。
軟件設計師
設計員定義一個或幾個類的職責、操作、屬性及關系，并確定應如何根據實施環境對它們加以調整。此外，設計師可能要負責一個或多個設計包或設計子系統，其中包括設計包或子系統所擁有的所有類。 編寫部分模塊設計文檔和代碼，檢查軟件工程師編寫的模塊代碼。

UI設計師

界面設計人員通過以下方法來領導和協調 Web 界面的原型設計和正式設計：獲取對 Web 界面的需求（包括可用性需求），構建 Web 頁面原型，使 Web 界面的其他涉眾（如最終用戶）參與可用性復審和使用測試會議，復審并提供對 Web 界面最終實施方案（由其他開發人員員創建，如設計師和實施工程師）的適當反饋。

軟件開發工程師

軟件工程師負責完成設計師的設計意圖， 根據設計文檔編寫代碼； 根據設計文檔編寫單元測試代碼，根據測試報告 BUG 記錄修訂 BUG ，完成包或子系統的開發。
測試工程師
測試工程師負責執行測試，其中包括設置和執行測試，評估測試執行過程并修改錯誤，以及評估測試結果并記錄所發現的缺陷。

實施工程師

負責軟件產品安裝調試和部署，完成項目相關系統工程工作，負責客戶技術支持，負責編寫系統部署方案和使用手冊、維護手冊，負責系統實施計劃和規劃。

運維工程師

無論做什么運維，運維工程師最基本的職責都是負責服務的穩定性，確保服務可以7*24H不間斷地為用戶提供服務。在此之上運維工程師的主要工作職責如下：

質量：保障并不斷提升服務的可用性，確保用戶數據安全，提升用戶體驗。

效率：用自動化的工具/平臺提升軟件在研發生命周期中的工程效率。

成本：通過技術手段優化服務架構、性能調優；通過資源優化組合降低成本、提升ROI。

從產品的生命周期來看：

產品發布前：負責參與并審核架構設計的合理性和可運維性，以確保在產品發布之后能高效穩定的運行。

產品發布階段：負責用自動化的技術或者平臺確保產品可以高效的發布上線，之后可以快速穩定迭代。

產品運行維護階段：負責保障產品7*24H穩定運行，在此期間對出現的各種問題可以快速定位并解決；在日常工作中不斷優化系統架構和部署的合理性，以提升系統服務的穩定性。

什么是軟件測試

使用人工操作或軟件自動運行的方式來檢驗它是否滿足規定的需求
弄清預期結果與實際結果之間差別的過程

• 預期結果
  • 指用戶的預期結果
• 實際結果
  • 指的是軟件的實際運行結果
• 軟件缺陷
  • 預期結果與實際結果之間的差別

正確理解軟件測試

測試是為了發現程序中的錯誤
成功的測試是發現了至今為止尚未發現的錯誤
測試并不僅僅是為了找出錯誤
沒有發現錯誤的測試也是有價值的

錯誤理解軟件測試

測試是為了證明程序沒有錯誤

軟件開發完成后進行軟件測試

軟件發布后如果發現質量問題，那是軟件測試人員的錯

軟件測試要求不高，隨便找個人多都行

軟件測試是測試人員的事情，與程序員無關

項目進度吃緊時少做些測試，時間富裕時多做測試

軟件測試是沒有前途的工作，只有程序員才是軟件高手

通過測試達到零缺陷率

軟件測試的歷史發展

60年代以前

• 軟件測試跟“調試”（Debug）關聯在一起，由開發人員執行。沒有單純意義上的軟件測試，軟件測試還沒有形成概念

• 隨著軟件工程的發展，軟件測試的概念出現在20世紀60年代

70年代初期

• Bill Hetzel提出軟件測試是為了證明程序是正確的，建立一種信心。

70年代末期

• 1972年，在北卡羅來納大學舉行了首屆軟件測試正式會議。
• 1979年，Glenford Myers 在《軟件測試藝術》中，對測試做了定義：測試是為發現錯誤而執行的一個程序或者系統的過程。

80年代

• 20世紀80年代早期，“質量”的號角開始吹響。軟件測試定義發生了改變，測試不單純是一個發現錯誤的過程，而且包含軟件質量評價的內容，制定了各類標準。
• 提出了一系列各種復雜而精密的軟件開發設計流程和管理方法，例如CMM、CMMI軟件測試也有了行業標準IEEE/ANSI，V模型和其他模型的逐漸形成
• 1983年，Bill Hetzel 在《軟件測試完全指南》中指出：測試是以評價一個程序或者系統屬性為目標的任何一種活動，測試是對軟件質量的度量。

90年代

• 手工測試（Manual Test）到測試工具的發展。測試工具盛行起來

現在

• 軟件測試管理工具的大量應用，測試是為了度量和提高被測軟件的質量。

  ---

  我國的軟件測試發展

  • 1978年-1988年，中國軟件蹣跚起步，軟件英雄厲兵秣馬。1980年，在中關村建立了“北京等離子體學會先進技術發展服務部”

  • 1988年-1998年，軟件市場內憂外患，最初繁榮后的低谷。隨著盜版的日益猖獗以及國外軟件巨頭的入侵，國產軟件失去了最初的輝煌。從1994年中國正式接入國際互聯網，到作為網絡時代標志的瀛海威時空的成立，再到中國計算機公用互聯網CHINANET建成

  • 1998年-2008年，互聯網蓬勃發展，中國軟件迎來復興。2001年，中國成功加入WTO，自此中國正式獲得和國際市場對話的權利;2002年，全面建設小康社會成為改革的核心，同年博客進入中國，互聯網春天來臨;2000年左右以新浪、騰訊、網易等代表的互聯網公司先后在國際市場上市，以中國概念股的姿態奪得了資本市場的認可;同樣在2000年，金山創辦了電子商務網站卓越網，電子商務成為互聯網主流商業模式。

  • 隨著快速占領市場，敏捷開發，快速迭代的需求，2012年自動化火了起來

    小結：軟件定義世界，智能化的影響越來越影響中國的發展。

軟件測試的重要性

事故1：阿麗亞娜 5 型運載火箭

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-QmPDoGRK-1645522648127)(.image/image-20220220202813351.png)]

1996 年，阿麗亞娜 5 型運載火箭首次飛行，搭載發射星群航天器（歐洲航天局的四大航天器之一的星座）。然而由于運載火箭無法到達指定軌道，任務以失敗告終。

損失：3.7 億美元，故障原因：阿麗亞娜5型運載火箭基于前一代4型火箭開發。在4型火箭系統中，對一個水平速率的測量值使用了16位的變量及內存，因為在4型火箭系統中反復驗證過，這一值不會超過16位的變量，而5型火箭的開發人員簡單復制了這部分程序，而沒有對新火箭進行數值的驗證，結果發生了致命的數值溢出。因此，飛行器在發射后 37 秒便從原始路徑偏移。最終不得不啟動了火箭自毀程序。

事故2：奔騰的長除法

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tq1cmwjS-1645522648130)(.image/image-20220220202947580.png)]

1994 年，英特爾的奔騰微處理器芯片的浮點計算單元出現了一個 Bug。對于精確計算，處理器將返回不正確的十進制值。當時有大概 500 萬個缺陷芯片在流通，英特爾最終決定為所有投訴的人更換芯片。這之后，英特爾把他們的故障處理器做成了鑰匙鏈。
　　損失：4.75 億美元 + 品牌名譽受損，故障原因：在奔騰浮點單元的分頻器中有一個有缺陷的除法表，在約一千個條目中丟失了五條紀錄。然而，這個錯誤在 90 億隨機浮點小數的除法中僅可能出現一次。例如，將 4195835.0 除以 3145727.0 得出 1.333739068902037589，而不是 1.333820449136241002，有 0.006% 的誤差。

事故3：1987 年的華爾街崩盤

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-J5ZIy9Hn-1645522648131)(.image/image-20220220203244445.png)]

1987 年 10 月 19 日（也被稱為黑色星期一），道瓊斯工業平均指數（DJIA）下跌了 508 個點，損失了總價值的 22.61%，且標準普爾 500 指數下跌了 20.4%。這是華爾街一天之內見過的最大損失。
　　損失：一天 5000 億美元，故障原因：問題出在交易程序和估價程序。在交易程序中，計算機基于外部輸入執行快速股票交易，如相關證券的價格。該交易程序理應實施投資組合保險策略，并試圖從事套利。

1987 年初，美國證券交易委員會針對內幕交易開始了一系列的調查。直到 10 月，投資者決定搬出華爾街。隨著人們開始大規模外流，計算機交易程序出現了大量的銷售訂單至 DOT（訂單轉送及成交回報系統），于是系統超出負載、市場崩潰以及所有的投資者懵逼了。

事故4：千禧危機

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-aBxH19hC-1645522648132)(.image/image-20220220203419291.png)]

千年蟲（千年問題）是計算機系統的編碼問題，在從 1999年 12 月 31 號過渡到 2000 年 1 月 1 號時，這個錯誤將在計算機網絡和軟件中引發一場浩劫。
　　損失：5000 億美元，故障原因：為了節省計算機存儲空間，大多數傳統軟件使用兩位數字來存儲日期中的年份，例如，用“97”來代表 1997 年。這導致了 2000 年 1 月之后日期相關程序的錯誤操作。

此外，有些程序沒有考慮到 2000 年是閏年。甚至在 2000 年到來之前，人們都在擔心一些軟件可能在 1999 年 9 月 9 號（表示為 9/9/99）無法工作，因為早期的開發人員常使用一系列的 9 來表示一段程序代碼的結束。

事故5：癌癥治療與致死性放射治療

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-l2nNYBEI-1645522648133)(.image/image-20220220203547047.png)]

1985 年到 1987 年期間，Therac-25 醫療放射治療裝置讓成百上千的患者暴露在大量過量的輻射之中，少數患者接受了高達預期 100 倍的放射劑量。2000 年，巴拿馬城也發生了同樣的輻射劑量誤差。

損失：10 余人死亡，20 人重傷，故障原因：基于輸入數據的順序，治療計劃軟件計算出并提供雙倍劑量的輻射。

事故6：愛國者導彈

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-19ivQtU5-1645522648134)(.image/image-20220220203706950.png)]

1991 年 2 月第一次海灣戰爭期間，部署在沙特宰赫蘭的美國愛國者導彈系統未能成功追蹤和攔截來襲的伊拉克飛毛腿導彈。結果飛毛腿導彈擊中美國軍營。
　　損失：28 名士兵死亡，100 多人受傷，故障原因：時間計算不精確以及計算機算術錯誤導致了系統故障。從技術角度來講，這是一個小的截斷誤差。當時，負責防衛該基地的愛國者反導彈系統已經連續工作了100個小時，每工作一個小時，系統內的時鐘會有一個微小的毫秒級延遲，這就是這個失效悲劇的根源。愛國者反導彈系統的時鐘寄存器設計為24位，因而時間的精度也只限于24位的精度。在長時間的工作后，這個微小的精度誤差被漸漸放大。在工作了100小時后，系統時間的延遲是三分之一秒。

0.33 秒對常人來說微不足道。但是對一個需要跟蹤并摧毀一枚空中飛彈的雷達系統來說，這是災難性的。飛毛腿導彈空速達4.2馬赫（每秒1.5公里），這個”微不足道的”0.33秒相當于大約 600 米的誤差。在宰赫蘭導彈事件中，雷達在空中發現了導彈，但由于時鐘誤差沒能精確跟蹤，反導導彈因而沒有發射攔截。

事故7：洛杉磯國際機場的航班停飛

2007 年，美國邊境和海關控制網絡發送了大量錯誤數據。這導致洛杉磯整個機場關閉了 8 個小時，在問題解決之前，超過 17000 架飛機不能起飛。這件事的罪魁禍首是一段有 Bug 的嵌入式軟件。

事故8：Bug 葬送了日本 18 億元的最新衛星

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-MVVq6CLn-1645522648142)(.image/image-20220220203934919.png)]

2016年2月17日，被日本寄予厚望的 X 射線天文衛星“瞳”成功發射升空，但僅僅一個月后，“瞳”與地面的通信出現嚴重故障，經地面光學望遠鏡測控發現其運行軌跡出現多塊太空碎片。4月28日，日本宇宙航空研究開發機構（JAXA）正式宣布，無法恢復對X射線衛星“瞳”的操控，事故原因經初步調查源自底層軟件錯誤。衛星的控制系統在發現飛行姿態失控時，采取了錯誤的調整，推進器點火時朝向了錯誤的反方向，導致自身旋轉更加嚴重，最終徹底失控。

事故9：溫州7.23 動車事故

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-f7MrX1vm-1645522648143)(.image/image-20220220204218407.png)]

2011年7月23日20時30分05秒，甬溫線浙江省溫州市境內，由北京南站開往福州站的D301次列車與杭州站開往福州南站的D3115次列車發生動車組列車追尾事故，造成40人死亡、172人受傷，中斷行車32小時35分，直接經濟損失19371.65萬元。上海鐵路局局長安路生28日說，根據初步掌握的情況分析，“7·23”動車事故是由于溫州南站信號設備在設計上存在嚴重缺陷，遭雷擊發生故障后，導致本應顯示為紅燈的區間信號機錯誤顯示為綠燈。

事故10：12306連現故障：上午近乎癱瘓下午爆串號門

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-2HAWrPHE-1645522648145)(.image/image-20220220204601035.png)]

2014年春運圖定列車售票首日，上午12306網站的響應速度逐漸變慢，刷新網頁經常需要超過20秒，也有網友表示網頁根本刷不出來。下午3時左右，正當搶票大戰激烈進行時，以自己的用戶名登錄后，出現的確是別人的名字。
搶票插件作者倪超分析稱，上線不久的12306新版，反應速度和穩定性比起舊版都有所下降，面對大量用戶就顯得力不從心。

事故11：男子趁ATM機出錯惡意提款171次被判無期

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-mXugxII8-1645522648146)(.image/image-20220220213434968.png)]

2006年4月21日晚10時，被告人許霆來到廣州天河區黃埔大道某銀行的ATM取款機取款。結果取出1000元后，銀行卡賬戶里只被扣1元，許霆先后取款171筆，合計17.5萬元。許霆潛逃一年后被抓獲，一審以盜竊罪被判無期徒刑。

3月31日下午，備受關注的許霆案一審重審結果宣布，廣州中院以盜竊罪判處許霆有期徒刑五年，罰金兩萬，追討其取出的17萬3千8百26元。許霆當庭表示不上訴，而許霆父親許彩亮對于這個判決不滿意，表示還會上訴。

自許霆案浮出水面且一審判處無期徒刑間，網民的關注焦點僅集中于銀行的強權霸道與法院的量刑標準，并口誅筆伐；而二審結果宣判后，網民則對于法律的信任產生了動搖。在很多人的心中，銀行成了高危地帶，法律也不再那么堅強。備受關注的許霆案落幕，留下了“一地雞毛”。

軟件測試的目的

• 把盡可能多的問題在產品交給用戶之前發現并改正
• 確保最終交給用戶的產品功能符合用戶的需求
  • 確保產品完成了所承諾或公布的功能
  • 確保產品滿足性能和效率的要求
  • 確保產品健壯和適應用戶環境
• 建立軟件質量的信心，度量和提高被測軟件的質量。

---

立場不同，測試目的不同

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-vtcbCtgn-1645522648147)(.image/image-20220221083339116.png)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-fzcXwjxY-1645522648148)(.image/image-20220221083410773.png)]

軟件測試的原則

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-cQFXlJ3N-1645522648149)(.image/無標題.png)]

測試人員應具備的素質

必備技能

軟件測試知識：測試計劃、測試方案、編寫用例、提交bug、跟蹤bug，編寫測試報告

測試工具的使用

操作系統

編寫代碼的能力

數據庫知識

業務知識、網絡知識

輔助素質

主動溝通，清晰了解掌握需求邏輯，和專業的問題反饋。

膽大心細；相信自己，自己是專業的

不被別人綁架；要有職業標準，也要有自己的態度

對一切都要有懷疑的態度

責任心；站在公司和用戶的角度考慮問題

當工匠精神遇到公司快速發展、激烈的競爭，測試該如何破局？

工匠精神

"工匠們喜歡不斷雕琢自己的產品，不斷改善自己的工藝，享受著產品在雙手中升華的過程。

工匠們對細節有很高要求，追求完美和極致，對精品有著執著的堅持和追求，把品質從0提高到1，其利雖微，卻長久造福于世。"

如何破局？

• 一般就是加人、加班；提高測試人員素質。

• 為了速度稍微對質量進行瘦身，當然瘦身的前提還是要保證產品的健康。

• 還需要保證產品的健壯性，不至于在壓力大的時候就會被壓垮；在遭受病毒攻擊時，就被隨意攻破；換個環境，就不能適應。

• 要有專業的業務測試團隊，對所負責系統及業務非常精通；

• 要有專業的質量團隊，通過流程控制，保證任何項目都能臨危不亂；

• 通過組建自動化實施專家團、白盒測試專家團、性能測試、安全測試、用戶體驗測試等專家團隊，保證項目的每一種質量指標都能夠有特種部隊的支持；這樣就可以保證緊急的戰略項目可以在短時間內得到專業的質量保障。

常見軟件系統架構

B/S架構

（Browser/Server，瀏覽器/服務器模式），是WEB興起后的一種網絡結構模式，WEB瀏覽器是客戶端最主要的應用軟件。該模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用成本。

BS分布性強、維護方便、開發簡單且共享性強、總體擁有成本低。但數據安全性比C/S低、對服務器要求過高、數據傳輸速度慢、軟件的個性化特點明顯降低，難以實現傳統模式下的特殊功能要求。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-xVwMFKU2-1645522648149)(.image/image-20220221090035201.png)]

優點

分布性強，客戶端零維護。只要有網絡、瀏覽器，可以隨時隨地進行查詢、瀏覽等 業務處理。
業務擴展簡單方便，通過增加網頁即可增加服務器功能。

維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。
開發簡單，共享性強。

缺點

個性化特點明顯降低，無法實現具有個性化的功能要求。
在跨瀏覽器上，BS架構不盡如人意。
客戶端服務器端的交互是請求-響應模式，通常動態刷新頁面，響應速度明顯降低（Ajax可以一定程度上解決這個問題）。無法實現分頁顯示，給數據庫訪問造成較大的壓力。
在速度和安全性上需要花費巨大的設計成本。
功能弱化，難以實現傳統模式下的特殊功能要求。

B/S架構的幾種形式

第一種：客戶端-服務器-數據庫

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6cwttVB7-1645522648150)(.image/image-20220221101818525.png)]

這個應該是我們平時比較常用的一種模式：

1、客戶端向服務器發起Http請求

2、服務器中的web服務層能夠處理Http請求

3、服務器中的應用層部分調用業務邏輯，調用業務邏輯上的方法

4、如果有必要，服務器會和數據庫進行數據交換. 然后將模版＋數據渲染成最終的Html, 返送給客戶端

第二種：客戶端－web服務器－應用服務器－數據庫

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-jpbeMSE0-1645522648150)(.image/image-20220221101914438.png)]

類似于第一種方法，只是將web服務和應用服務解耦

1 客戶端向web服務器發起Http請求

2 web服務能夠處理Http請求，并且調用應用服務器暴露在外的RESTFUL接口

3 應用服務器的RESTFUL接口被調用，會執行對應的暴露方法.如果有必要和數據庫進行數據交互，應用服務器會和數據庫進行交互后，將json數據返回給web服務器

4 web服務器將模版＋數據組合渲染成html返回給客戶端

第三種方法：客戶端－負載均衡器(Nginx)－中間服務器(Node)－應用服務器－數據庫

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-vyDLwRQh-1645522648151)(.image/image-20220221102002860.png)]

這種模式一般用在有大量的用戶，高并發的應用中。

1、整正暴露在外的不是真正web服務器的地址，而是負載均衡器器的地址

2、客戶向負載均衡器發起Http請求

3、負載均衡器能夠將客戶端的Http請求均勻的轉發給Node服務器集群

4、Node服務器接收到Http請求之后，能夠對其進行解析，并且能夠調用應用服務器暴露在外的RESTFUL接口

5、應用服務器的RESTFUL接口被調用，會執行對應的暴露方法.如果有必要和數據庫進行數據交互，應用服務器會和數據庫進行交互后，將json數據返回給Node

6、Node層將模版＋數據組合渲染成html返回反向代理服務器

7、反向代理服務器將對應html返回給客戶端

C/S架構

C/S架構全稱為客戶端/服務器體系結構，它是一種網絡體系結構，其中客戶端是用戶運行應用程序的PC端或者工作站，客戶端要依靠服務器來獲取資源。C/S架構是通過提供查詢響應而不是總文件傳輸來減少了網絡流量。它允許多用戶通過GUI前端更新到共享數據庫，在客戶端和服務器之間通信一般采用遠程調用（RPC）或標準查詢語言（SQL）語句。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-pVRSNTRw-1645522648151)(.image/image-20220221093043581.png)]

特點

• 客戶端進程包含特定于解決方案的邏輯，并提供用戶與應用程序系統其余部分之間的接口。服務器進程充當管理共享資源（如數據庫，打印機，調制解調器或高性能處理器）的軟件引擎。
• C/S結構在技術上很成熟，它的主要特點是交互性強、具有安全的存取模式、網絡通信量低、響應速度快、利于處理大量數據。因為客戶端要負責絕大多數的業務邏輯和UI展示，又稱為胖客戶端。它充分利用兩端硬件，將任務分配到Client 和Server兩端，降低了系統的通訊開銷
• C/S結構的軟件需要針對不同的操作系統開發不同版本的軟件，加之產品的更新換代十分快，更新的代價高，效率低，很難適應百臺電腦以上局域網用戶同時使用。
• 客戶端和服務器進程通過一組明確定義的標準應用程序接口（API）和RPC進行通信。

優點

• 能充分發揮客戶端PC的處理能力，很多工作可以在客戶端處理后再提交給服務器，所以CS客戶端響應速度快。
• 操作界面漂亮、形式多樣，可以充分滿足客戶自身的個性化要求。
• C/S結構的管理信息系統具有較強的事務處理能力，能實現復雜的業務流程。
• 安全性能可以很容易保證，C/S一般面向相對固定的用戶群，程序更加注重流程，它可以對權限進行多層次校驗，提供了更安全的
• 存取模式，對信息安全的控制能力很強。一般高度機密的信息系統采用C/S結構適宜。

缺點

• 需要專門的客戶端安裝程序，分布功能弱，針對點多面廣且不具備網絡條件的用戶群體，不能夠實現快速部署安裝和配置。
• 兼容性差，對于不同的開發工具，具有較大的局限性。若采用不同工具，需要重新改寫程序。
• 開發、維護成本較高，需要具有一定專業水準的技術人員才能完成，發生一次升級，則所有客戶端的程序都需要改變。
• 用戶群固定。由于程序需要安裝才可使用，因此不適合面向一些不可知的用戶，所以適用面窄，通常用于局域網中。

C/S架構的類型

一層架構

在此類型C/S架構設置中，用戶界面，營銷邏輯和數據邏輯存在于同一系統中。但是由于數據差異導致難以管理。例MP3播放器，MS Office都屬于單層應用程序。

兩層架構

在這種類型中，用戶界面存儲在客戶端機上，數據庫存儲在服務器上。數據庫邏輯和業務邏輯在客戶端或服務器上歸檔，但需要進行維護。如果在客戶端收集業務邏輯和數據邏輯，則將其命名為胖客戶端瘦服務器體系結構。如果在服務器上處理業務邏輯和數據邏輯，則稱為瘦客戶端胖服務器體系結構。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-xvHslNC8-1645522648151)(.image/image-20220221093926268.png)]

三層架構

在三層架構中，需要使用到額外的中間件，這意味著客戶端請求需要通過該中間層進入服務器，服務器的響應首先由中間件接收，然后再接收到客戶端。中間件存儲所有業務邏輯和數據通道邏輯，中間件提高了靈活性并提供了最佳性能。

三層結構被分成三個部分，即表示層（客戶層），應用層（業務層）和數據庫層（數據層）。客戶端系統管理表示層，應用程序服務器負責應用程序層，服務器系統負責監視數據庫層。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-lbzyRnOg-1645522648152)(.image/image-20220221094903824.png)]

B/S 與 C/S對比

1、客戶端要求

• C/S客戶端的計算機電腦配置要求較高。

• B/S客戶端的計算機電腦配置要求較低。

2、軟件安裝

• C/S每一個客戶端都必須安裝和配置專用的軟件。
• B/S最大的優點就是不用安裝任何專門的軟件，只要有一個瀏覽器就可以。

3、軟件升級和維護

• C/S每一個客戶端都要進行升級和維護。
• B/S客戶端不必安裝及維護。

4、安全性

• C/S一般面向相對固定的用戶群，它可以對權限進行多層次校驗，提供了更安全的存取模式，對信息安全的控制能力很強。一般高度機密的信息系統應采用C/S結構。

發展前景

1、 C/S和B/S各有優勢，C/S在圖形的表現能力上以及運行的速度上肯定是強于B/S模式的，不過缺點就是他需要運行專門的客戶端，而且更重要的是它不能跨平臺，用c++在windows下寫的程序肯定是不能在linux下跑的。

2、B/S模式就，它不需要專門的客戶端，只要瀏覽器，而瀏覽器是隨操作系統就有的，方便就是他的優勢了。
而且，B/S是基于網頁語言的、與操作系統無關，所以跨平臺也是它的優勢，而且以后隨著網頁語言以及瀏覽器的進步，
B/S在表現能力上的處理以及運行的速度上會越來越快，它的缺點將會越來越少。尤其是HTML5的普及，在圖形的渲染方面以及音頻、文件的處理上已經非常強大了。
不過，C/S架構也有著不可替代的作用。

常見面試題

什么是軟件測試？

軟件測試的原則是什么？

軟件測試的分類

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-um3KVagZ-1645522648153)(.image/image-20220221152213564.png)]

作業：把上述每個測試的概念和分類搞懂，做好筆記，提交上來

按開發階段劃分

• 單元測試

• 集成測試

• 系統測試

• 驗收測試

按是否查看代碼劃分

• 白盒測試
• 灰盒測試
• 黑盒測試
  • 功能測試
    • 界面測試
    • 業務邏輯測試
    • 兼容性測試
    • 易用性測試
    • 回歸測試
  • 性能測試
    • 性能測試
    • 負載測試
    • 壓力測試
    • 并發測試
    • 配置測試
    • 容量測試
    • 可靠性測試

按是否運行劃分

• 動態測試
• 靜態測試

按是否手工測試劃分

• 手工測試

• 自動化測試

  ?

按其他劃分

• 隨機測試
• 冒煙測試
• 安全測試
  • 安全測試是在軟件產品開發基本完成時，驗證產品是否符合安全需求定義和產品質量標準的過程
  • 安全測試是檢查系統對非法侵入滲透的防范能力
  • 理論上來講，只要有足夠的時間和資源，沒有無法進入的系統。因此，系統安全設計的準則是使非法侵入的代價超過被保護信息的價值
• 探索測試
  • 探索性測試 (ET)是敏捷世界里的一種重要測試方法，作為一個研究性的工具，它是用戶故事測試和自動化回歸集的重要補充
  • 是一種經過深思熟慮的測試方式，沒有測試腳本，可以使你的測試超出各種明顯已經測試過的場景。相對于嚴格的“先設計，后執行”有較大區別， 主要依靠對于業務與技術的深入思考和測試人員的經驗。
• α測試
  • Alpha測試是指把用戶請到開發方的場所來測試，俗稱（內側），Alpha測試的環境是受開發方控制的，用戶的數量相對比較少，時間比較集中 Alpha
  • 王者體驗服是屬于 Alpha測試，屬于開發可控的測試。
• β測試
  • Beta測試是指在一個或多個用戶的場所進行的測試。beta測試的環境是不受開發方控制的，誰也不知道用戶如何折磨軟件，用戶數量相對比較多，時間不集中。
    • 下載版本時的beta版本

軟件測試流程

軟件測試流程圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-GnELnIRw-1645522648153)(.image/image-20220221150157620.png)]

軟件測試過程主要工作內容

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-E6TU9KYY-1645522648154)(.image/image-20220221150255975.png)]

測試小組的運行

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-QeQVnZxJ-1645522648154)(.image/image-20220221151541373.png)]

軟件生命周期模型

一 什么是模型

序

? 不知道為什么，很多軟件開發的新人都是從C或C++的入門書籍開始的。
? 這就好比，要去打仗的人先熟悉兵器一樣。
? 為什么不從戰略戰術層面開始學習呢?如果戰略和戰術出了問題，兵器再熟練又有什么用呢?還不是一樣吃敗仗?
打仗的目的是追求勝利，不是兵器耍得如何漂亮。而軟件開發的目的是解決用戶在處理其業務時遇到的問題。
所以，軟件開發新人更應該先去培養自己了解用戶需求，解決用戶問題的能力。

? 模型被用來描繪人們所關注的現實或想法的某個方面。模型是一種簡化。它是對現實的解釋——把與解決問題密切相關的方面抽象出來，而忽略無關的細節。
? 我們講行軟件開發是為了解決用戶在業務中遇到的問題，而這些用戶的問題領域對于軟件開發團隊來說是一整套龐大的知識體系，軟件開發人員要弄清楚這些問題領域所需知識的廣度可能令人望而生畏，龐大而復雜的信息也可能超乎想象。而模型正是解決此類信息龐大問題的工具。使用模型可以對龐大的知識信息進行了選擇性的簡化和有意的結構化，幫助開發人員理解信息的意義，并專注于用戶問題本身。
? 模型是一種工具，它把龐大、復雜、零亂的信息通過抽象簡化這樣的整理，讓人更容易理解。

二 軟件開發模型

軟件開發模型也叫軟件生命周期模型。是軟件開發全過程。能夠覆蓋軟件生命周期的基本階段。

典型的軟件開發模型有：瀑布模型、快速原型模型、螺旋模型、演化模型

主要的開發方法分類從大方向上包括：

結構化開發
結構化開發方法又稱生命周期法，是迄今為止最傳統、應用最廣泛的一種開發方法
結構化開發方法結構化、模塊化、自頂向下地對軟件系統進行分析與設計
該方法嚴格按照階段性開展工作，每個階段都產生一定的成果（文檔、代碼），通過評估后再進入下一階段開發工作

迭代開發

在迭代開發中，人們從項目的計劃階段開始，通過這些階段進入產品的開發和發布。當產品發布時，來自產品測試和用戶的結果，這些結果被折疊到下一個版本中。“發布”可能是一個誤導性的術語；迭代開發可能涉及到產品在早期階段的內部發布，而不是產品的發布面向公眾的產品。使用這種技術的開發人員假設、接受并實際上期望他們開發的產品不會一次完成。與其試圖預見所有潛在的問題和用戶需求，他們通過一系列的迭代來逐步完善和改進產品，使其變得有用。迭代開發的一個主要優點是，它允許人們對問題和不斷變化的需求做出快速響應，因為重建、回滾和優化都是在開發過程中直接構建的開發通常涉及來自公司不同部門的團隊成員之間的密切合作。通過讓每個人都參與到底層，公司可以降低開發成本，鼓勵創新，并從一開始就開發出綜合多種觀點的產品迭代開發還需要大量的研究和分析，因為人們對市場壓力、來自消費者和客戶的明確需求以及對正在開發的產品的內部反饋作出反應。這個過程是動態的，而且非常迅速。有些公司的周期最短可能只有一周。在每個周期開始時，開發人員開會確定他們希望實現的變更，并將重點放在這些變更上；隨著其他問題的出現，它們可以被添加到以后的開發周期中。這有助于集中精力，幫助公司更容易地滿足期望；隨著迭代開發的產品開始向公眾推出，正在測試產品的用戶可以遵循計劃的更改，可以報告問題，并確保有一個固定的時間框架來解決這些問題

Ⅰ 瀑布模型（waterfull）

A 定義

瀑布模型（Waterfall Model） 是一個項目開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段并進行適當的修改，項目開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來.

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-i4i88l4w-1645522648155)(.image/image-20220221103654566.png)]

Ⅱ 快速原型模型

定義

一般在需求提出初期，用戶迫切需要體驗產品，開發人員根據核心功能需求快速實現的一款可以用來演示的產品，形成demo，可快速挖掘是否是用戶真正想要的產品。但這種模型在整個軟件項目周期內只可能存在于這期間，當用戶了解了demo后決定是拋棄還是繼續采用，拋棄相當于需求雙方沒有達成一致，可以再次采用原型模型輸出給用戶確認，若選擇不拋棄繼續采用，原型模型就會被拋棄，選擇其他模型繼續開發。

優點：克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險。

Ⅲ 螺旋開發模型

A 定義

螺旋開發，1988年，巴利·玻姆(Barry Boehm)正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，并且加入了兩種模型忽略的風險分析，彌補了兩者的不足，特別適合于大型復雜的系統。

“螺旋模型”的每一周期都包括制定計劃、風險分析、實施工程和評審4個階段。剛開始規模很小，開發過程每迭代一次，螺旋線就增加一周，軟件開發又前進一個層次，系統又生成一個新的版本。

“螺旋模型”的核心就在于您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實現它，然后聽取客戶的意見，之后再進入到下一個階段。如此不斷輪回重復，直到得到您滿意的最終產品。

（1）制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；

（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；

（3）實施工程：實施軟件開發和驗證；

（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。

B 優點

1）設計上的靈活性,可以在項目的各個階段進行變更。

2）以小的分段來構建大型系統,使成本計算變得簡單容易。

3）客戶始終參與每個階段的開發,保證了項目不偏離正確方向以及項目的可控性。

4）隨著項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互。

5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。

C 缺點

很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟件技術發展比較快，所以經常出現軟件開發完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。

風險分析師分析的風險不正確的情況下，可能造成大的損失。

Ⅳ 軟件開發增量模型

A 定義

是強調軟件在發布不同的版本時，每次都多發布一點點，是軟件功能數量漸增地發布的過程。

B 增量模型的優點

1.整個項目的資金不會被提前消耗，因為首先開發和交付了主要功能和高風險功能。

2.每個增量交付一個可操作的產品。

3.每次增量交付過程中獲取的經驗，有利于后面的改進，客戶也有機會對建立好的模型作出反應。

4.采用連續增量的方式，可把用戶經驗融入到細化的產品，這比完全重新開發要便宜得多。

5.“分而治之”的策略，使問題分解成可管理的小部分，避免開發團隊由于長時間的需求任務而感到淚喪。

6.通過同一個團隊的工作來交付每個增量，保持所有團隊處于工作狀態，減少了員工的工作量

7.每次增量交付的結果，可以重新修訂成本和進度的風險。

8.便于根據市場作出反應。

9.降低了失敗和更改需求的風險。

10.更易于控制用戶需求，因為每次增量開發的時間很短。

11.由于不是一步跳到未來，所以用戶能逐步適應新技術。

12.切實的項目進展，有利于進度控制。

13.風險分布到幾個更小的增量中，而不是集中于一個大型開發中。

14.由于用戶能夠從早期的增量中了解系統，所以更加理解后面增量中的需求。

C 增量模型的缺陷

1）由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。
　2）在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。
　3）如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化后分別開發的方法較適應于需求經常改變的軟件開發過程。

D 增量模型的要求

1.良好的可擴展性架構設計，是增量開發成功的基礎。

2.由于一些模塊必須在另一個模塊之前完成，所以必須定義良好的接口。

3.與完整的系統相比，增量方式正式的回顧和評審更難于實現，所以必須定義可行的過程。

4.要避免把難題往后推，首先完成的應該是高風險和重要的部分。

5.客戶必須認識到總體成本不會更低。

6.分析階段采用總體目標而不是完整的需求定義，可能不適應管理。

7.需要更加良好的計劃和設計，管理必須注意動態分配工作，技術人員必須注意相關因素的變化。

軟件測試模型

Ⅰ V模型

V模型大體可以劃分為以下幾個不同的階段步驟:需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。

一般來講:單元測試所對應的是詳細設計環節，也就是說，單元測試的測試用例是和詳細設計一起出現的，在研發人員做詳細設計的時候，相應的測試人員也就把測試用例寫了出來;集成測試對應概要設計，在做模塊功能分析及模塊接口，數據傳輸方法的時候，就把集成測試用例根據概要設計中模塊功能及接口等實現方法編寫出來，以備以后作集成測試的時候可以直接引用;而系統測試，就是根據需求分析而來，在系統分析人員作系統分析，編寫需求說明書的時候測試人員就根據客戶需求說明書，把最后能實現系統功能的各種測試用例寫出來，為做最后系統測試作準備。

適用范圍

V模式是一種傳統軟件開發模型，一般適用于一些傳統信息系統應用的開發，而一些高性能高風險的系統、互聯網軟件，或一個系統難以被具體模塊化的時候，就比較難做成V模式所需的各種構件，需要更強調迭代的開發模型或者敏捷開發模型。

Ⅱ W模型

測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等開發輸出的文檔同樣要測試(這里針對設計文檔，一般可以劃分為需求設計文檔、概要設計文檔、詳細設計文檔和代碼文檔)， 也就是說，測試與開發是同步進行的。

從這個角度來說，一個完整合格的測試人員對軟件各方面把握程度應該比開發人員更高，一個測試人員要能勝任軟件研究任何一個崗位。

W模型有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求文檔的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。

V模型和W模型的區別

一、指代不同

1、v模型：是軟件開發過程中的一個重要模型，由于其模型構圖形似字母V，所以又稱軟件測試的V模型。

2、w模型：由兩個V字型模型組成，分別代表測試與開發過程。

二、特點不同

1、v模型：僅僅把測試過程作為在需求分析、系統設計及編碼之后的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的滿足情況一直到后期的驗收測試才被驗證。

2、w模型：測試的活動與軟件開發同步進行，測試的對象不僅僅是程序，還包括需求和設計，盡早發現軟件缺陷可降低軟件開發的成本。

三、適用不同

1、v模型：是一種傳統軟件開發模型，適用于一些傳統信息系統應用的開發。

2、w模型：有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求文檔的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。

V模型和W模型的局限性

?串行活動，無法更好適應變更：把軟件的開發視為需求、設計、編碼等一系列的串行活動，無法解決需求變更等變更調整。

?線性的前后關系，無法有效支持迭代：開發和測試保持線性的前后關系，上一階段完成才能開始下一階段，無法有效，快速支持產品迭代。

?測試完整性不足：順序模型中沒有很好體現測試流程的完整性。

Ⅲ H模型

這個示意圖僅僅演示了在整個生產周期中某個層次上的一次測試"微循環"。圖中標注的其他流程可以是任意的開發流程。例如，設計流程或編碼流程。也就是說，只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以(或者說需要)進行了。

H模型揭示了一個原理:軟件測試是一個獨立的流程，以獨立完整"微循環"流程，參與產品生命周期的各個階段，與其他流程并發地進行。H模型指出軟件測試要盡早準備，盡早執行，只要某個測試達到準備就緒點，測試執行活動就可以開展，并且不同的測試活動可按照某個次序先后進行，但也可以是反復進行的。

敏捷開發模型（Agile software development)

敏捷開發(Agile Development)
以用戶的需求進化為核心、迭代、循序漸進的開發方法

軟件項目的構建被切分成多個子項目
各個子項目的成果都經過測試
具備集成和可運行的特征

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-C2SaVAEo-1645522648158)(.image/image-20220221141157242.png)]

敏捷開發原則

通過盡早、持續交付有價值的軟件來使客戶滿意
即使在開發的后期，需求變更也是允許的
經常交付可工作軟件
項目開發期間，業務人員和開發人員在一起工作
強化激勵機制，為受激勵的個人單獨構建項目
在團隊內部，最富有效果和效率的信息傳遞方法是面對面交談

可工作軟件是進度的首要度量標準
敏捷過程提倡可持續的開發速度
不斷關注優秀的技能和好的設計，增強敏捷能力
盡量簡化所要做的工作
好的架構、需求和設計出自于組織團隊自身
團隊要定期反省如何更有效地工作，并相應地調整自己的行為

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-k7Q1Zh4u-1645522648159)(.image/image-20220221111254616.png)]

A 定義

敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。

敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

1、詳細的產品需求列表，排定優先級，這些便需要產品經理來完成的工作，同時一般會有研發、UI、運營等人的配合;

2、工作量的評估：這一項需要技術人員的支持，同時也需要產品經理，內容就是溝通各方面的資源、權衡技術難度，制定詳細的規劃;

3、計劃會議：這里是迭代的目標以及時間，同時把每一個大的任務細化到每個小任務——2、3天完成;

4、站立會議：每日開站立會議，每個人說明自己昨天完成了什么任務，今天要做什么，把已經完成的任務從未完成區域放在燃盡圖的已完成區域;

5、做到每日集成，每天都有一個成功編譯、并且可以演示的版本;

6、當一次迭代完成的時候，組織演示會議，也叫評審會議，邀請部門經理等管理者參加;

7、總結：輪流發言、討論需要改進的地方，放入下一輪產品的需求中。

B 專有名詞解釋

Product Owner

Product Owner ，以下簡稱“PO”，國內經常翻譯為“產品負責人”或者“產品擁有者”

PO主要是Built the right thing,即做對的事情。通過開發團隊，最大化地實現產品的價值。

Product Backlog

Product Backlog，簡稱“PB”，中文翻譯是“產品待辦事項”，就是要實現產品價值，需要做的事情。這里包括業務功能和非業物功能。產品待辦事項中的功能由Product Owner（PO）決定其內容（即要做什么），PO決定優先級（即先做哪個功能），因為PO是對產品的價值負責的，而且他是和客戶/用戶溝通最多的。

Product Owner 職責

PO最重要的一個職責就是管理好Product Backlog(PB)：

1、首先能夠向團隊清楚地傳達Product Backlog的內容。

2、確保團隊能夠理解Product Backlog中的內容。

3、為了達到產品的目標和任務，PO對Product Backlog中的內容進行最優排序。

4、確保Product Backlog中的內容是可視化的，透明的，對任何人都是清晰的。同時要告知團隊接下來做什么。

5、優化團隊工作的價值。

Scrum Master

敏捷開發中的SM即Scrum Master，字面意思是敏捷專家或者敏捷大師，即熟悉敏捷開發模式及敏捷實施流程的人員。一般可由敏捷團隊當中的開發負責人擔任，部分能力很強且懂技術的產品經理也可擔任這個角色，因涉及到工作量評估和分派等工作，最好都是由技術能力較強的人員擔任。

角色定義

Scrum Master是團隊的導師和組織者，與Product Owner緊密合作，及時為團隊成員提供幫助。促使team按照scrum方式運行，為Scrum過程負責的人。

Scrum Master并非團隊的領導（因為團隊是自我組織的），而是一個負責屏蔽外界對開發團隊干擾的角色。 Scrum Master是規則的執行者，他是Scrum團隊中的服務型領導。

工作職責

確保scrum被理解和正確使用并使得Scrum的收益最大化。主要職責如下：

1、保證團隊資源合理利用；

2、保證各個角色及職責良好協作；

3、解決團隊開發中的障礙；

4、作為團隊和團隊外部的接口，協調解決溝通中的問題；

5、保證開發過程按計劃進行，組織Scrum Planning Meetings（Sprint計劃會議）, Daily Stand-up Meeting（每日站會）, Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）

總結SM角色就是：教整個團隊怎么做，如何估時，跟進每天進度，風險控制，定期總結，計劃排定。

Sprint

Sprint（沖刺）：Scrum guide中把固定時間盒周期稱為sprint（沖刺）

Sprint 說的是類似橄欖球比賽中的沖刺：大家團結一致，為了完成該Sprint的目標瘋狂向前沖。

sprint強調盡快（run as fast as you can）

迭代強調重復（again and again）

Sprint包含計劃會議、每日例會、開發工作、評審會議、回顧會議。
在一個Sprint中，開發團隊成員、Sprint目標不應該改變。
一個Sprint的時間應控制在兩周左右。合適的時間可以確保Sprint目標不隨便變化，把風險限制在一個月的成本上。
如果某個Sprint目標過時了，產品負責人可以提前取消Sprint。

1）Sprint計劃會議
計劃會議確定Sprint中要完成的工作，有整個Scrum團隊一起完成。

會議輸入：產品待辦事項列表（Product Backlog）、團隊對這個Sprint的接受程度以及以往的表現
注意事項：首先需要明確回答兩個問題：1、這個Sprint最終完成后要交付的結果 2、為此需要做的具體工作

會議結果：根據產品待辦事項，開發團隊對每個待辦事項預估工作量，并開發團隊成員認領待辦事項。
注意事項：產品負責人需要對待辦事項做出說明，協助開發團隊做出取舍；開發團隊需要明確sprint最初幾天的工作內容，分解為少于一天的量。

2）每日例會
目標：評估Sprint進度。同步成員的活動，并創建一天的計劃。提前暴露問題，降低風險。
開發團隊中的每個成員應說明：已完成的工作，準備完成的工作，遇到的障礙、可能的風險
注意事項：Scrum Master確保會議正常舉行，控制時間應該確保每個成員都了解目前的進度以及每個成員各自的工作；應該強調交流溝通，提前暴露可能的問題，

3）Sprint評審會議
會議內容：

產品負責人確定哪些已完成，哪些未完成
開發團隊討論在Sprint中哪些進度順利、遇到了什么問題，如何解決的
開發團隊演示完成的工作
整個團隊就下一步的工作進行探討，根據完成的事項，最終輸出一份修訂的產品代辦列表

4）Sprint回顧會議
Scrum團隊檢驗自身，并列出要改進的點
對前一個Sprint周期中的人、過程、工具進行檢驗，列出 better 和 to be better，列出要改進的點

迭代過程（Iterative process）

用戶故事（User stories）

任務（Tasks）

站立會議（Stand-up meeting）

持續集成（Continuous integration）

最簡方案（Simplest solutions）

重構（Re-factoring）

敏捷開發任務看板：

團隊會在開放式辦公區域放置一塊白板，上面粘貼著所有的Story Card，按當前的開發狀態貼在4個區域中，分別是：未開發，開發中，預測試中，測試中。Story Card的開發人員和測試人員根據開發進度在Story Wall上移動Story Card，更新Story Card的狀態。這種方式可以對項目開發進度有一個非常直觀的了解。

燃盡圖

C 優點

? 1、迭代快，開發周期短;

2、不再耗費大量的時間來寫文檔，而是人與人面對面交流，只寫一些必要的文檔;

3、分工詳細，每天都輸出成果，客戶能夠看得到，會信任項目團隊;

4、溝通多，容易發現問題，同時能夠激起團隊的協作、奮斗精神;

D 缺點

1、人與人之間的信任是非常重要的環節，但是這個比較難完成，技術團隊的成員可能技術能力差別大，同時也有互相競爭，又或者是項目團隊的成員有所保留，不愿意這樣的溝通;

2、團隊在開發期間的任務多、壓力大，需要時刻保持“興奮”，一般很難做到。

E 敏捷開發里的關鍵概念

敏捷開發中的測試

1、傳統測試VS敏捷測試

按照規格說明書來進行測試 VS 根據客戶實際的需求和業務價值來進行測試
正確地做事 VS 做正確的事情

測試人員是提出建議者而非守門員

不僅進行確認測試，也可以發現需求缺失發現風險并與團隊及客戶溝通
及時向團隊提供關于產品質量的反饋，便于調整在產品和版本的發布計劃中提出建議
知識分享:協助整個團隊參與到測試活動中來
協助團隊從內部提升質量，讓質量融入到產品開發中來

2、敏捷人員需要做到

具有豐富的產品知識，和對用戶業務目標的準確了解，對不同系統和數據庫等所用到的技術知識的了解，和不同角色以及客戶進行有效溝通
主動驗證質量目標并及時說出自己的想法
編寫測試計劃，列出需要執行的活動并進行估算自動化測試的能力和對測試工具的掌握
知識分享
持續反饋

3、敏捷開發團隊介紹

我們的敏捷開發團隊由四位開發人員、兩位測試人員、一位產品設計，一位項目經理和一位產品經理組成（參見圖 每天早上十點，在固定的時間和會議室里面，團隊會舉行站立會議。這時候，團隊成員按照既定的順序向項目經理匯報各自前一天完成的任務，所遇到的困難和當天要完成的任務。同時，項目經理更新 Sprint Backlog（一張制作精良的 Excel 表格），并及時解決每個人所提出的問題。

敏捷開發團隊成員

由于敏捷開發要求參與人能夠快速而高效得應對變化，所以無形中對測試人員提出很高的要求。

4、測試人員需要具備的素質

測試是軟件開發中不可或缺的一部分。在敏捷軟件開發中亦是如此。不同的組織給測試人員以不同的稱號：測試開發 (Test Developer)、質量分析員 (Quality Analyst)、軟件質量工程師 (Software Quality Engineer) 等。

每個稱號隱含有不同的職能。以上的稱號分別對應以下的能力要求：

具有質量檢測和編寫代碼的能力–> 測試開發
具有防止缺陷 (Quality Assurance) 和質量控制 (Quality Control) 的能力–> 質量分析員
具有開發和執行測試程序的能力 -> 軟件質量工程師
總結而言，有三方面的基本素質要求：代碼編寫（Coding）、測試 (Testing) 和分析 (Analysis)。

在很多其他的開發流程中，各個測試階段對測試人員的能力有所不同；有時候側重分析（比如系統配置測試），有時候側重代碼編寫 ( 比如自動化測試 )。但是，在敏捷開發流程中，測試人員需要結合這三方面來開展工作，只有這樣才能真正反映敏捷測試的本質：簡單而高效得應對變化。

5、 測試人員的主要職責

在敏捷軟件開發中，測試人員的職責有三個主要方面：

定義質量 (Define Quality)：這應該是軟件測試人員的基本職責。敏捷方法鼓勵測試人員在 Sprint 計劃的時候直接與客戶交流，從自己的經驗出發，共同為產品功能制定質量要求。
交流缺陷（Communication）：敏捷過程強調團隊中的交流。開發人員經常會專注于重要而新奇的功能，測試人員應該抓住細節，尋找設計中的“missing door”；另外，開發人員使用單元測試來保證產品的基本質量，測試人員可以使用驗收測試（Acceptance Test）來鑒定客戶需求與實際成果之間的不一致性。
及時反饋 (Feedback): 敏捷過程強調簡單而高效。測試人員需要及時反饋產品目前的質量問題。這樣一來，團隊才可以立刻著手解決。如果傳統的流程是一周匯總一次狀態的話，敏捷流程要求每天匯總質量問題。在我們的項目中，內部的測試報告會以網頁的形式顯示在內部站點上。每個團隊成員能夠隨時獲取。另外，我們的測試框架提供自助測試 (Self-assistant Test)：通過點擊測試用例列表中的某個具體用例，開發人員不需要中斷測試人員的工作就可以重現缺陷。

6、測試人員的主要工作

典型的敏捷開發和測試活動主要由三部分構成，從最初的用戶故事設計和發布計劃，到幾次 Sprint 周期的迭代開發和測試，以及最后的產品發布階段。每個時間段都有相應的測試活動。通常 Sprint 周期被分成兩類：特征周期（Feature Sprint）和發布周期（Release Sprint）。特征周期主要涉及新功能的開發和各類測試。發布周期則會結合計劃，確定新版本功能，然后對最新的功能進行測試。

對各階段相應的測試活動作詳細的介紹和分析

①用戶故事設計和發布計劃階段

在用戶故事和發布計劃階段，項目經理和產品經理會根據客戶的需求，制定概要的產品發布日程計劃。此時，測試人員可以和開發人員一起學習新的功能，了解客戶的需求。其中，有兩個主要活動：尋找隱藏的假設和設計概要的驗收測試用例。

尋找隱藏的假設

正如前文所述，開發人員通常關注一些重要的系統功能而忽視細節。此外，敏捷開發倡導簡單的實現方案，每個開發 Sprint 周期不可能將功能完美得實現；相反，每個 Sprint 都會增量得開發一些功能。所以，測試人員在最初就需要從各種角度來尋找系統需求，探索隱藏的假設。

設計概要的驗收測試用例

定義完一系列用戶故事后，測試人員就可以著手設計概要的驗收測試用例。正如我們在前文論述，不同于單元測試，驗收測試檢查系統是否滿足客戶的預期，也就是用戶故事是否能夠實現。于是，測試人員可以根據每條用戶故事來擴展，尋找其中的“動作”，然后為每條“動作”制定正例和反例。

②迭代 Sprint 階段

當一個 Sprint 周期正式開始時，項目經理將制定該周期的具體開發和測試任務。在定期的 Sprint 計劃會議（Planning Meeting）上，每位團隊成員都要提供自己在未來一個 Sprint 周期中的休假和培訓計劃。另外，每個團隊可以根據各自團隊成員的能力和工作經驗，適當設定一個工作負載值（Load Factor）。比如，我們團隊的工作負載值為 75%，也就是說每個人平均每天工作 6 小時（以 8 小時計算）。接著，大家就可以開始分配任務。

當開發團隊開始編碼和單元測試時，測試人員的工作重點包括：估算驗收測試的時間、估算測試框架的搭建、詳細設計驗收測試和編寫驗收測試代碼。第兩個主要活動一般在項目初期的 Sprint 周期中完成。其他的三個主要活動將在接下來的多個 Sprint 周期中視情況迭代進行。下面我們將具體介紹每個主要活動。

估算測試框架的搭建

測試框架是自動測試必不可少的一部分工作。由于敏捷開發流程倡導快速而高效得完成任務，這就要求一定的自動測試率。一個完善的測試框架可以大大提高測試效率，及時反饋產品的質量。

在敏捷開發流程中，在第一個 Sprint 周期里，需要增加一項建立測試框架的任務。在隨后的迭代過程中，只有當測試框架需要大幅度調整時，測試團隊才需要考慮將其單獨作為任務，否則可以不用作為主要任務羅列出來。

詳細設計驗收測試用例

完成對測試任務的估算，接著就可以著手詳細設計驗收測試用例。我們可以對概要設計中的測試用例進行細化，根據不同的測試環境、測試數據以及測試結果，編寫更詳細的測試用例。另外，可以結合幾個用例，完成一個復雜的測試操作。

由于敏捷開發的流程是不斷迭代的過程，所以很多復雜的功能可能會在未來的 Sprint 周期中被優化。對測試人員而言，一個有效的方法是盡量將一些驗證基本功能的測試用例作為基本驗證測試用例（Basic Verification Test Case）在第一時間實現自動化；而對一些復雜的功能測試用例，可以先采用手工的方法測試，直到在未來 Sprint 周期中該功能達到穩定時候再考慮自動化。此外，對測試中出現的缺陷可以設計回歸測試用例（Regression Test Case），為其編寫自動測試代碼，使得此類問題在發布周期（Release Sprint）時可以順利而高效得進行驗證。

編寫驗收測試用例

敏捷開發不提倡撰寫太多的文檔，提倡直接編寫測試用例。此外，測試人員和客戶應取得良好的溝通，將這些需求總結下來，轉化成驗收測試用例。如果資源充足，最好對驗收測試用例建立版本控制機制。

考慮到需求在每一輪 Sprint 周期中會不斷得變化，測試團隊要控制測試的自動化率，正確估計未來功能的增減。自動化率過高會導致后期大量測試代碼需要重構，反而增加很多工作量。

③ Sprint 結束和下一個 Sprint 開始

在一個 Sprint 周期結束時，團隊要舉行一個回顧會議（Retrospective Meeting）。團隊成員可以在會議上暢所欲言，指出在過去一個 Sprint 周期中可行的，不可行的和有待改進的地方。待改進之處將在項目經理監督下于未來的 Sprint 周期中實現。

由于敏捷開發倡導增量開發，當新的 Sprint 開始時，測試團隊需要根據新 Sprint 周期的開發進度及時重構驗收測試。如果新 Sprint 周期沒有具體的新功能開發，測試團隊可以將精力集中在執行驗收測試和尋找缺陷上。

如果下一個 Sprint 周期是發布周期，那么測試人員需要準備執行回歸測試。下面我們來詳細了解每個測試活動。

重構驗收測試

敏捷開發是以迭代方式進行的，功能在每次迭代中推陳出新。于是，驗收測試用例經常需要修改或者添加，相應的驗收測試代碼也需要刪減。這部分工作如果時間花銷很大，最好在估算的時候一并提出。

在下一個 Sprint 周期中，我們需要實現之前沒有實現的“模糊查找”功能。測試人員要在新的 Sprint 周期中更新原來的驗收測試用例，在測試“搜索”模塊中添加模糊查找測試。重新估算的測試任務參加下表：

任務，估計時間
設計測試用例，準備測試數據（模糊搜索數據集）
加載數據集
編寫自動測試代碼
執行測試和匯報結果
總結
執行驗收測試

驗收測試可以分為兩大類，基本驗證測試和功能測試。如果是基本驗證測試，推薦開發人員在運行完單元測試和提交代碼前直接運行自動測試腳本。如果是功能測試，可以在每個 Sprint 后期，新功能代碼提交后，由測試人員單獨執行。

敏捷開發的開發和測試是相輔相成的。一旦基本驗證測試出現問題，那就說明開發人員的實現違反了最初客戶定義的需求，所以不能夠提交。如果功能測試出現問題，那么測試人員要及時與開發人員溝通。如果是缺陷，需及時上報給項目經理，并在每天站立會議中提出；如果不是，那么繼續下一項任務。這個過程充分體現了敏捷開發所提倡的團隊交流機制。

執行回歸測試

在發布周期中，測試人員所肩負的任務非常重要，因為這是產品發布前的最后質量檢驗。

首先，要建立一套自動生成 build、運行自動測試代碼、手工執行測試用例并匯總測試結果的框架。

其次，定期執行各類測試，包括功能和系統測試。

最后，要整理之前在每個特征測試周期中出現的問題。如果已經整理并歸類為回歸測試用例，那么只要定時執行就可以了；否則，需一一添加。如果用例已經被自動化，可以直接運行；如果是手工測試，測試人員需要按照測試用例進行操作，最后匯總測試結果。這部分測試就是所謂的回歸測試。

DevOPS

DevOps是什么

有人說它是一種方法，也有人說它是一種工具，還有人說它是一種思想。更有甚者，說它是一種哲學。

DevOps的起源

這個故事有點長，從頭開始講起吧。

上個世紀40年代，世界上第一臺計算機誕生。從誕生之日起，它就離不開程序（Program）的驅動。而負責編寫程序的人，就被稱為“程序員”（Programmer）。

程序員是計算機的駕馭者，也是極其稀缺的人才。那個時候，只有高學歷、名校出身的人，才有資格成為程序員，操控計算機。

隨著人類科技的不斷發展，PC和Internet陸續問世，我們進入了全民擁抱信息化的時代。越來越多的企業開始將計算機作為辦公用的工具，用以提升生產力。而普通個人用戶也開始將計算機作為娛樂工具，用以改善生活品質。

于是，計算機的程序，開始變成了一門生意。程序，逐步演進為“軟件（software）”，變成了最賺錢的產品之一。

在軟件產業里，程序員有了更專業的稱謂，叫做“軟件開發工程師（Software Development Engineer）”，也就是我們常說的“碼農”。

我們知道，一個軟件從零開始到最終交付，大概包括以下幾個階段：規劃、編碼、構建、測試、發布、部署和維護。

最初，程序比較簡單，工作量不大，程序員一個人可以完成所有階段的工作。

隨著軟件產業的日益發展壯大，軟件的規模也在逐漸變得龐大。軟件的復雜度不斷攀升。一個人已經hold不住了，就開始出現了精細化分工。

碼農的隊伍擴大，工種增加。除了軟件開發工程師之外，又有了軟件測試工程師，軟件運維工程師。

分工之后，傳統的軟件開發流程是這樣的：

軟件開發人員花費數周和數月編寫代碼，然后將代碼交給QA（質量保障）團隊進行測試，然后將最終的發布版交給運維團隊去布署。所有的這三個階段，即開發，測試，布署。

早期所采用的軟件交付模型，稱之為“瀑布（Waterfall）模型”。

瀑布模型，簡而言之，就是等一個階段所有工作完成之后，再進入下一個階段。

這種模型適合條件比較理想化（用戶需求非常明確、開發時間非常充足）的項目。大家按部就班，輪流執行自己的職責即可。

但是，項目不可能是單向運作的。客戶也是有需求的。產品也是會有問題的，需要改進的。

隨著時間推移，用戶對系統的需求不斷增加，與此同時，用戶給的時間周期卻越來越少。在這個情況下，大家發現，笨重遲緩的瀑布式開發已經不合時宜了。

于是，軟件開發團隊引入了一個新的概念，那就是大名鼎鼎的——“敏捷開發（Agile Development）”。

敏捷開發在2000年左右開始被世人所關注，是一種能應對快速變化需求的軟件開發能力。其實簡單來說，就是把大項目變成小項目，把大時間點變成小時間點，然后這樣：

有兩個詞經常會伴隨著DevOps出現，那就是CI和CD。CI是Continuous Integration（持續集成），而CD對應多個英文，Continuous Delivery（持續交付）或Continuous Deployment（持續部署）。

美其名曰：“持續（Continuous）”，其實就是“加速——反復——加速——反復……”，這樣子。

畫個圖大家可能更明白一點：

敏捷開發大幅提高了開發團隊的工作效率，讓版本的更新速度變得更快。

很多人可能會覺得，“更新版本的速度快了，風險不是更大了嗎？”

其實，事實并非如此。

敏捷開發可以幫助更快地發現問題，產品被更快地交付到用戶手中，團隊可以更快地得到用戶的反饋，從而進行更快地響應。而且，DevOps小步快跑的形式帶來的版本變化是比較小的，風險會更小（如下圖所示）。即使出現問題，修復起來也會相對容易一些。

雖然敏捷開發大幅提升了軟件開發的效率和版本更新的速度，但是它的效果僅限于開發環節。研發們發現，運維那邊，依舊是鐵板一塊，成為了新的瓶頸。

![img]

運維工程師，和開發工程師有著完全不同的思維邏輯。運維團隊的座右銘，很簡單，就是“穩定壓倒一切”。運維的核心訴求，就是不出問題。

什么情況下最容易出問題？發生改變的時候最容易出問題。所以說，運維非常排斥“改變”。

于是乎，矛盾就在兩者之間集中爆發了。

這個時候，我們的DevOps，隆重登場了。

DevOps到底是什么

DevOps這個詞，其實就是Development和Operations兩個詞的組合。它的英文發音是 /de’v?ps/，類似于“迪沃普斯”。

DevOps的維基百科定義是這樣的：

DevOps是一組過程、方法與系統的統稱，用于促進開發、技術運營和質量保障（QA）部門之間的溝通、協作與整合。

這個定位稍微有點抽象，但是并不難理解。反正它不是某一個特定軟件、工具或平臺的名字。

從目標來看，DevOps就是讓開發人員和運維人員更好地溝通合作，通過自動化流程來使得軟件整體過程更加快捷和可靠。

舉例說明什么是devOPS

為什么要合并這兩個領域？原因很多，但首要原因是：我們目前的工作流程是脫節的。絕對的脫節。很多公司的開發部門和運維部門之間存在的深刻矛盾，其實就是這個“脫節”造成的。

下面是一個大家都基本熟悉的例子：部署軟件產品。

開發部門要開發一款新產品。這款產品要使用最新最炫的技術，來保證客戶的所有花俏的需求，從而給公司帶來百萬美元的利潤。這款產品被要求使用最新的技術和運行平臺，還得馬上交付。于是開發部門沒日沒夜的加班、趕代碼（cuts code like crazy），終于如期完成了任務。然后他們把自己的“杰作”一股腦的甩給了運維部門，后者還沒能完全接手，前者已經迫不及待的開始了慶功會。

接到產品后，運維部門每個人的心中都充滿了恐懼。

下面就是運維部門的恐懼之源：（{A.B.C}表示A或B或C之一）

• 這款優秀的產品在目前的底層平臺上無法運行，因為這個平臺{太古老了，空間不足，不支持某某版本}
• 這款產品的體系結構跟我們的{存儲，網絡，部署，安全}模型不匹配。
• 這款產品的{ 報告，安全，監視，備份，服務提供} 我們搞不懂 ，所以沒法把它做成實際可用的產品。

盡管伴隨著不絕于耳的抱怨和咒罵，運維部門最終還是把這款產品安裝好了。不幸的是，由于做了很多蹩腳的修改和不合理的強迫式運行，這款產品的性能最后被歸結為：終極失敗（Epic Fail）。

于是非常沮喪的運維部門開始記錄各種問題，源源不斷的給開發部門提Issue。而開發部門的回應基本上都是：

• 這不是我們的錯 —— 我們的代碼非常完美——而是（運維部門的）部署做的太差勁了。
• 運維部門比較笨，他們不懂新技術—— 為什么他們沒法實現最新的技術呢？為什么他們這么落伍呢？
• 在我的機器上運行的沒問題啊……

兩個部門之間的交流很快變成了一場暴風驟雨。客戶（以及股東、投資方和管理層）則成了蒙受損失的失敗方。最終公司損失了無數的金錢，大家也都失業了。終極的失敗。

DevOps 又有啥不同？它有什么好處？

DevOps 就是想方設法的避免這種“終極失敗”，同時讓大家用更聰明更有效的方式去工作。它是一種框架，包含了很多優秀想法和原則，它鼓勵開發部門和運維部門通力合作。在DevOps環境中，開發人員和系統管理員會構建一些關系、流程和工具，從而更好的與客戶互動，最終提供更好的服務。

DevOps 也不僅僅是一種軟件的部署方法。它通過一種全新的方式，來思考如何讓軟件的作者（開發部門）和運營者（運營部門）進行合作與協同。使用了DevOps模型之后，會使兩個部門更好的交互，使兩者的關系得到改善，從而讓很多領域從中受益，例如：自動化、監視、能力規劃和性能、備份與恢復、安全、網絡以及服務提供（provisioning）等等。

部門之間關系

早參與，多參與。對于開發人員，要讓運維人員常駐到開發部門，全程參與開發流程。邀請運維人員參與你的Scrum或者開發會議，與他們分享項目計劃、分享新技術的點子和心得。搜集功能性需求（指開發人員用到的需求）的同時也要搜集運維方面的需求。把對于“發布、備份、監控、安全、配置管理和系統功能”的測試作為一項獨立的項目流程。軟件產品在開發時解決的問題越多，那么在使用時暴露給用戶的問題就越少。給運維人員做培訓，讓他們弄清楚項目的體系結構和核心代碼。如果運維人員在反饋bug時提供的信息越多，那么你花在排查問題（trouble-shooting) 的時間就越少，這個bug也就會更快的被解決掉。

對于運維人員，在遇到問題時需要把開發人員加進來，大家一起解決問題。邀請開發人員參與你們的會議，分享項目進度（roadmaps），并且共同修訂工作計劃。運維人員一定要了解開發部門下一步的工作方向，從而確保產品運行的底層平臺能夠良好的支持最新技術。開發人員也會帶來相關的技術、知識和工作，幫助你們改善產品的運行環境，使其更加易于維護、簡潔有效。

有一些開發領域的概念，例如：“要根據API而非封閉的interface來構建工具”，分布式版本控制，驅動測試開發，以及諸如敏捷開發、看板管理（Kanban）和Scrum等方法論。如果把這些概念應用在運維領域，同樣會產生革命性的變革。

不要懼怕新點子和新技術。我們可以隨時隨地的向他人學習，哪怕是一句“我們再也不要那樣做了！”也會讓我們從中獲益。盡管處于不同的部門，但是我們要共同學習、共同成長，這樣才能協同工作的更好！

按照從高到低的順序，有效的溝通方式應該是：面對面交流 、視頻會議、電話、即時通訊軟件、Email。

目前支持DevOps的軟件實在是太多了。話說回來，現在DevOps之所以被吹得天花亂墜，也有這些軟件和平臺的功勞，可以趁機賣錢啊。

DevOps生態圈中令人眼花繚亂的工具

上述這些關鍵要素里面，技術（工具和平臺）是最容易實現的，流程次之，思維轉變反而最困難。

換言之，DevOps考驗的不僅是一家企業的技術，更是管理水平和企業文化。

對比前面所說的瀑布式開發和敏捷開發，我們可以明顯看出，DevOps貫穿了軟件全生命周期，而不僅限于開發階段。

下面這張圖，更明顯地說明了DevOps所處的位置，還有它的價值：

DevOps的發展現狀

DevOps這個詞來源于2009年在比利時根特市舉辦的首屆DevOpsDays大會，為了在Twitter上更方便的傳播，由DevOpsDays縮寫為DevOps。

目前，DevOps處于高速增長的階段。尤其是在大企業中，DevOps受到了廣泛的歡迎。

根據2018年的調查發現，74%的受訪者已經接受了DevOps，而前一年這一比例為66%。

越大的企業，越喜歡DevOps。包括Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、linkedIn、Netflix、NASA、Starbucks、Walmart、Sony等公司，都在采用DevOps。

如今，DevOps幾乎已經成為了軟件工程的代名詞。

DevOps迅猛發展，相關專業人才的薪資待遇也跟著水漲船高。

根據調研，DevOps工程師在美國的平均年薪為130000美金，在中國平均年薪也在40萬-50萬區間，能力強者年薪百萬也是比比皆是。

薪資的猛漲，又帶動了IT工程師們學習和認證的熱潮。

DevOps的認證目前最受歡迎的就是EXIN DevOps Master和EXIN DevOps Professional。這些認證的培訓費用不低，但是仍然吸引了很多人踴躍報名。

![img]

EXIN DevOps認證體系

DevOps與虛擬化、容器、微服務

這幾年云計算技術突飛猛進，大家應該對虛擬化、容器、微服務這些概念并不陌生。當我們提到這些概念的時候，也會偶爾提及DevOps。

它們之間有什么聯系呢？

其實很簡單。

大家可以設想一下，如果要對一項工作進行精細化分工，我們是對一個大鐵疙瘩進行加工方便？還是拆成一塊一塊進行加工更加方便？

顯然是拆分之后會更加方便。

所謂“微服務”，就是將原來黑盒化的一個整體產品進行拆分（解耦），從一個提供多種服務的整體，拆成各自提供不同服務的多個個體。如下圖所示：

體式架構（Monolithic）→ 微服務架構（Microservices）

微服務架構下，不同的工程師可以對各自負責的模塊進行處理，例如開發、測試、部署、迭代。

而虛擬化，其實就是一種敏捷的云計算服務。它從硬件上，將一個系統“劃分”為多個系統，系統之間相互隔離，為微服務提供便利。

容器就更徹底了，不是劃分為不同的操作系統，而是在操作系統上劃分為不同的“運行環境”（Container），占用資源更少，部署速度更快。

虛擬化和容器，其實為DevOps提供了很好的前提條件。開發環境和部署環境都可以更好地隔離了，減小了相互之間的影響。

這也是DevOps為什么2009年時不火，現在越來越火的一個主要原因之一。

天下武功，唯快不破。

時代發展到現在，客戶的需求瞬息萬變，市場的風向也難以預測。作為企業，想要生存下去，只有讓自己變得更快。作為員工，必須讓自己眼光更加長遠，內心更加包容。

面試題

軟件測試模型？

軟件測試流程？

需求分析

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JP3lvzF4-1645522648167)(…/.image/image-20220221154002102.png)]

軟件需求

軟件需求的重要性

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-fzQ5Drzm-1645522648168)(…/.image/image-20220222145505995.png)]

客戶項目統計數據

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-AWKXBNnO-1645522648168)(…/.image/image-20220222145632425.png)]

Software Requirements Specification，簡稱SRS

在特定環境下要完成一定功能的軟件產品、程序或一組程序的說明 描述需求規格

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-63YhJiS1-1645522648168)(…/.image/image-20220221154152086.png)]

演示示例： 行政服務中心政務平臺需求文檔

需求分類

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-lc14f25O-1645522648169)(…/.image/image-20220221202651760.png)]

測試需求

• 測試需求概念

  • 可直接形成測試大綱

• 測試需求的重要性

  • 是開發測試用例的依據
  • 是衡量測試覆蓋率的重要指標
  • 有助于保證測試的質量和進度

• 測試需求的特性要求

  • 可核實的
  • 滿足需求的正常的前置條件，不滿足需求時的出錯條件

需求分析對于開發和測試的影響

• 開發

  • 如果需求不明確，系統功能研發不合理，導致軟件包含大量bug
  • 大量bug修改，影響進度和團隊情緒
  • 進度收到影響，可能造成公司產品失去市場先機

• 測試

  • 如果不能很好理解需求，會被開發牽著鼻子走，也會被人懷疑測試能力
  • 不能及時發現開發的bug，沒法保證測試質量

測試需求分析

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-OKBNqW9f-1645522648169)(…/.image/image-20220221203625668.png)]

需求挖掘

• 需求挖掘的過程

  • 是將軟件需求中的那些具有可測試性的需求或特性提取出來，形成原始測試需求

• 需求挖掘的方法

  • 通過列表的形式對軟件需求進行梳理，形成原始測試需求列表

• 功能需求==》》輸入方面

  • 輸入來源是什么？

  • 輸入數據數量是幾個？

  • 如果有錯誤輸入，響應是什么？

  • 什么是非法輸入？什么是無效輸入？

    • 非法就是程序能做，但做了就非法，這種情況也需要報錯
    • 無效輸入是指輸入了有效輸入以外的值。

    如：國名的下拉框不能出現臺灣，臺灣就是非法輸入，卻并不一定是無效輸入。程序需要返回異常提示。

• 功能需求==》》處理方面

  • 輸入數據的有效性檢測的流程是什么？
  • 操作的確切次序，包含各時間的時序是什么
    • 按照特定時間變化的不同情況的測試
  • 對異常情況的回應是什么？例如：溢出、通訊失敗、錯誤處理

• 功能需求==》》結果輸出方面

  • 輸出到何處（如瀏覽器，打印機，文件）？
  • 輸出的數量是多少？
  • 輸出的時序是什么樣的？
    • 按照特定時間變化的不同情況的測試結果
  • 對非法值得處理是什么樣的？

• 功能需求==》》性能需求方面

  • 靜態量化可能包含
    • 支持的終端數目
    • 支持的并發用戶數
    • 處理的文件和記錄的數目，表和文件的大小
  • 動態量化可能包含
    • 在正常或峰值工作情況下一個特定時間段處理事務或任務的數目及數據量
    • 正常或峰值工作量情況下處理某個事務或任務所占用系統資源的數量

• 功能需求==》》用戶接口方面

  • 系統用戶顯示時要求的屏幕格式
  • 頁面規劃及報告或菜單的內容
  • 輸入和輸出的相關時序
  • 一些組合功能鍵的用法

軟件開發文檔評審

什么是評審？

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-MIHHrqnL-1645522648169)(.image/image-20220222150630050.png)]

測試文檔評審

內部評審

• 部門評審（測試部門：部門有相關項目經驗的測試優秀人員）

現場評審

• 項目組評審（開發人員，測試人員，架構設計人員，產品經理，項目經理和客戶方的業務人員）

一般測試計劃和方案，測試用例，測試報告都需要經過評審定版，然后執行。

項目組和客戶比較關注測試計劃的時間安排，測試策略和測試用例業務邏輯的覆蓋

文檔評審的形式（理解，不需要記憶）

• 正式評審：是指通過開評審會的形式，組織多個專家，將涉及到的人員聚集在一起，并定義好參與評審人員的角色和職責，審進行正規的評審。

• 非正式評審：通過非正式的，一般通過郵件、電話、網絡聊天等對需求進行評審。兩種評審各有利弊，在評審時視情況而定。

• 相互評審、交叉評審：甲乙在兩個項目組，處在一個領域，但工作內容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查，相互評審是非正式評審，但是非常有效的方式，在工作中經常使用。

• 輪查：又稱分配審查方法，是一種異步評審方式。作者將需要評審的內容發給各個評審員，并收集他們的評審意見，這是一種非正式評審。

• 走查：產品的作者將產品在現場向同事介紹，描述產品要有怎樣的功能、結構，從頭到尾走一遍，以收集大家的意見。希望參與評審的同事能發現其中的錯誤，進行現場討論這種方式處于正式和非正式之間，其應用普通。

• 小組評審：通過正式的評審會議完成評審工作，是有計劃和結構化的評審形式。評審定義了評審會議中的各種角色和相應的責任，一般所有參與者在評審會儀的前幾天就能拿到評審材料，并對該材料進行了獨立研究。

• 審查：審查和小組評審很相似，但更為嚴格，是最系統、最嚴密、最系統化的評審形式，包含了制定計劃、準備和組織會議、跟著和分析審查結果等。

擴展（了解）

代碼走查

代碼走查**(code walkthrough)**是一個開發人員與架構師集中討論代碼的過程。代碼走查的目的是交換有關代碼是如何書寫的思路，并建立一個對代碼的標準集體闡述。 在代碼走查的過程中，開發人員都應該有機會向其他人來闡述他們的代碼。 通常地，即便是簡單的代碼闡述也會幫助開發人員識別出錯誤并預想出對以前麻煩問題的新的解決辦法。

代碼審查

代碼審查（英語：Code review）是指對計算機源代碼系統化地審查，常用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提升軟件質量及開發者的技術。代碼審查常以不同的形式進行，例如結對編程、非正式的看過整個代碼，或是正式的軟件檢查。

練習

• 寫協同辦公系統項目測試用例（寫測試用例）
• 寫行政服務中心政務平臺（進行需求分析）
• 一支圓珠筆: 能夠在軟硬紙上書寫;可以在不同溫度下正常使用；筆的材質在安全范圍內；書寫流暢，不易擦拭；筆套和筆桿合適;一只筆能用1年;摔在地上，還能使用；筆芯墨水不會倒流，能夠使用不同型號的筆芯；正常用力寫字不會壞；合適3歲以上小孩使用。
• 朋友圈發送動態編輯界面的測試
• 練習1：聊天工具測試需求
• 練習2：航班訂票系統測試需求

代理商項目安裝

代理商（AgentSysment）系統

LINUX上系統安裝

在虛擬機界面中按CTRL+alt，讓鼠標移出來

再按下win+D，即可切換回原主機的界面

--------------------------------------------------------------------------------

ubuntu

注意，由于xshell遠程連接ubuntu是通過ssh協議的，所以，確保ubuntu安裝ssh服務器：

輸入以下命令進行安裝遠程ssh服務

# sudo apt-get install openssh-server

若沒有ssh，需要執行

# sudo apt-get install ssh

Ubuntu首次安裝設置管理員root密碼

sudo passwd root

--------------------------------------------------------------------------------

Ubuntu在用root賬戶使用xftp連接時提示拒絕連接

一般來說Linux不允許使用root賬戶連接，修改配置

vi /etc/ssh/sshd_config

#Authentication:

LoginGraceTime 120

PermitRootLogin prohibit-password

StrictModes yes

PermitRootLogin參數修改為yes

#Authentication:

LoginGraceTime 120

PermitRootLogin yes

StrictModes yes

修改后重啟ssh服務

sudo /etc/init.d/ssh restart

--------------------------------------------------------------------------------

防火墻

sudo ufw status

sudo ufw disable

sudo ufw enable

1:查看防火狀態

systemctl status firewalld

service iptables status

2:暫時關閉防火墻

systemctl stop firewalld

service iptables stop

3:永久關閉防火墻

systemctl disable firewalld

chkconfig iptables off

4:重啟防火墻

systemctl enable firewalld

service iptables restart

5:永久關閉后重啟

//暫時還沒有試過

chkconfig iptables on

--------------------------------------------------------------------------------

安裝mysql

$ sudo apt-get update #更新軟件源

$ sudo apt-get install mysql-server #安裝mysql

啟動和關閉mysql服務器：

$ service mysql start

$ service mysql stop

確認是否啟動成功，mysql節點處于LISTEN狀態表示啟動成功：

sudo netstat -tap | grep mysql

mysql -u root -proot

select host, user, authentication_string,plugin from user;

update user set host = ‘%’ where user = ‘root’;

二、注釋bind-address = 127.0.0.1

在Ubuntu系統中，MySQL默認只能本地訪問，不能遠程訪問，因為訪問地址被綁定死了為本地127.0.0.1，想要遠程訪問的話，需要去/etc/mysql/mysql.conf.d中找到bind-address = 127.0.0.1，然后注釋掉這一句，也就是在這句前面加上#號。

然后重啟MySQL就可以了。

重啟命令為：service mysql restart

更新密碼的類型

alter user ‘root’@’%’ identified with mysql_native_password by ‘123456’;

flush privileges;

配置jdk的環境變量

vi /etc/profile

大寫的G調到最后

JAVA_HOME=/usr/local/jdk1.8.0_191

JAVA_BIN=$JAVA_HOME/bin

JRE_HOME=$JAVA_HOME/jre

JRE_BIN=$JRE_HOME/bin

PATH=$JAV{A}_{B}IN:$JRE_BIN:$PATH

export JAVA_HOME JRE_HOME PATH

訪問地址：

http://192.168.146.128:8080/login.action

Windows上系統安裝

1.在windows上安裝mysql數據庫

MySQL 官網 https://www.mysql.com/

點擊 DOWNLOADS 進入下載地址，會看到幾個不同的版本：

MySQL Enterprise Edition：企業版（收費）

MySQL Cluster CGE：高級集群版（收費）

MySQL Community Edition：社區版（開源免費，但官方不提供技術支持）

通常我們用的都是社區版。點擊進入社區版，看到一大堆東西，有點愣住了，不用急，其實點第一個 MySQL Community Server 的下載就可以了。

所以真正的下載地址其實是：https://dev.mysql.com/downloads/mysql/

拉到下面，選擇 Windows 系統。

這里提供安裝版和解壓版，安裝版是 32 位的（當然 64 位系統下也能安裝），解壓版是 64 位的。

點擊 Download 后會跳轉到如下頁面，這是叫你注冊/登錄的，不理它，點擊左下角的 No thanks, just start my download. 開始下載。

安裝版是 32 位的，而現在的機器多半是 64 位機，雖然 32 位的程序也可以安裝，但是并不建議。安裝版的安裝也比較容易，所以這里只講解壓版的安裝。

2.msi版本解安裝后配置環境變量

將安裝包解壓到你要安裝的目錄，將 bin 目錄添加至環境變量。

3.開啟mysql服務,啟動對應的端口號

mysq1 -u root - p

-P3308

select host, user , plugin, authentication_string from mysql.user;

注:密碼為authentication_string

plugin若是caching_sha2_password改為mysql_native_password的類型

ALTER USER ’ root '@‘localhost’

IDENTIFIED WITH mysqL_native_password BY

"123456’;

賦權操作:

mysql初始密碼:phZzMO6dBl,e

grant all privileges on . to ‘root’@’%’ identified by 'Root!!2018’with grant option;

開啟關閉防火墻:

systemctl status firewalld.service

systemctl stop firewalld.service

4.連接navicat

導入sql

5.配置jdbc

6.開啟tomcat

訪問地址

總結

以上是生活随笔為你收集整理的第1章 软件测试概述需求分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。