問：對教材與參考資料閱讀後關於軟體質量保障你的體會是什麼？

軟體測試在整個軟體生命週期中的重要性使其存在於整個專案週期，這個環節在整個專案中佔了很大的比重，能主導整個軟體專案的走向。質量這個關鍵詞對於企業來說究竟有多重要自然不必多說，輕則關乎到軟體的最終執行狀態和結果，重則直接影響到企業形象，不會有任何人相信一家質量不過關的企業，那樣做無異於自尋死路。

軟體測試如果能存在軟體開發的整個週期中，可對軟體開發過程中存在的風險作出及時規避，減少工程在時間和金錢上的消耗，還能讓團隊認識自己身的不足之處，並加以改進，避免在同一個坑中掉進去兩次，更能挽回不少企業的損失。

引用書中關於軟體質量的一句話：

Capability of software product to satisfy stated and implied needs under specified conditions.

谷歌翻譯為：

軟體產品在指定條件下滿足陳述和隱含需求的能力。

而“程式的質量”和“軟體工程的質量”如何影響軟體的質量，就像這樣一條公式：

軟體_質量 = 程式_質量 + 軟體工程_質量

1） 軟體在開發過程中通常有三個特性：“好”，“快”，“便宜”。

結合現時軟體工程可理解為“在實現軟體需求者需求的全部軟體功能並將功能做到足夠好後，在軟體在正是執行時，存在最少的軟體問題等的前提下，控制成本和時間達到最小的消耗，將這幾項控制在一個相對最好的平衡的點上”。

以上這些就引出來一個問題——軟體質量：

什麼是質量，如何來衡量？

比如衡量一個搜尋引擎的質量，業界通用準確度和覆蓋率的綜合指標來表示。網站查詢結果的速率，訂票網站能併發處理業務的吞吐量，支援同時線上人數的數量。等等許多衡量標準。

2） 軟體工程的質量體現在以下方面：

• 軟體開發過程的可見性（Visibility）
• 軟體開發過程的風險控制（Risk Management）
• 軟體內部模組，專案中間階段的交付質量，專案管理工具的因素
• 軟體開發成本的控制（Cost Control）
• 內部質量指標的完成情況（Internal Benchmarks）

3） 軟體工程的質量如何衡量：

這裡引入一套比較成熟的理論——CMMI（Capacity Maturity Model Integrated，能力成熟度模型整合）。

• 第一級：初始級。
• 第二級：管理級。
• 第三級：明確級。
• 第四級：量化管理級。
• 第五級：優化級。

4）軟體質量的成本：

SWEBOK特別定義了軟體質量成本（Cost of Software Quality，CoSQQ）的組成部分。

• 預防（Prevention）
• 評審（Appraisal）
• 內部故障（Internal Failure）
• 外部故障（External Failure）
• 流程分析改進（Process Enhancement）
• 提高職業技能（Enhance Professional Skills）
• 技術投資（Invest in Technology）

問：如果你是一個專案的QA，那麼你認為你的工作職責範圍是什麼？

1）什麼是QA：

QA（QUALITY ASSURANCE，中文意思是“質量保證”），其在ISO8402：1994中的定義是“為了提供足夠的信任表明實體能夠滿足質量要求，而在質量管理體系中實施並根據需要進行證實的全部有計劃和有系統的活動”。有些推行ISO9000的組織會設定這樣的部門或崗位，負責ISO9000標準所要求的有關質量保證的職能，擔任這類工作的人員就叫做QA人員 。（來自百度百科詞條解釋）

2）工作職責範圍：

QA的重要工作是預防、檢查與改進來保證軟體質量。QA的工作是軟體生命週期的管理以及驗證軟體是否滿足規定的質量和使用者的需求。

綜上如此，QA需要很多對應其專業的能力，這也是成為一名合格QA所要做的職責範圍，不然絕不是一個合格的專業人員。

• 必須懂開發：軟體是由各種語言的程式碼編寫而來，如果一個對軟體開發甚至連基本軟體開發工程的知識都不懂的QA，其只能做黑盒測試，而有些BUG是黑盒測試所無法發現的，只能是內行人看門道，外行人看熱鬧，更無法與程式設計師很好的溝通。如果QA能夠很好理解程式程式碼和工程，在測試過程中能夠針對某一點制定測試方法，對症下藥。而測試中一旦出現質量問題，可以很快找到問題所在的大致位置，減少盲目尋找問題所在而浪費的時間，更好的與開發部門配合協調。

• 必須瞭解需求：有使用者需求，才出現對應的軟體，如果一個QA不瞭解使用者需求，很難理解軟體每個功能的實現。如果真的這樣，那就只剩瞎指揮，致使軟體在偏離最初目標的道路上越走越遠。瞭解使用者需求，可在測試時更準確的收集資料，尋找缺點和問題所在，最快最準確的處理問題。對專案需求文件進行評估，規則文件，設計文件測試用例，

• 善於總結和發現缺點：任何開發團隊都不可能不存在問題，在開發工程中和完成後，QA要善於找出團隊中存在的問題，與團隊隊員交流，更好的改正缺點，避免更多錯誤的發生。

• 必須瞭解專案的上下游的結構：不瞭解上游，必然無法確定dev對上游的呼叫是否可靠。不瞭解下游，必然無法確定專案的實現是否符合下游的呼叫場景，介面的QPS是否滿足要求，專案對下游影響的範圍有多大。

• 為整個工程負責：在專案中QA不是為找bug而存在，專案中找到的bug越多，說名專案的質量越接近需求的質量，但也並不代表是真正的質量。QA需要監督和保證從需求一直到專案上線的質量。也就是說，QA不是證明專案實現的錯誤性，而是確認實現的正確性。

• 監督：在開發過程中，各小組按組內規範進行工作，有組間互動的任務需按組間互動規範去完成。檢查設計文件是否與程式原始碼一致，這些期間QA按工作流程規範監督各項工作任務的進行。及時溝通共同推動專案的進行。

問：如果你是一個專案經理，那麼你認為這你的專案中需要專職的QA麼？還是隻需有Test即可？如果一旦出現問題，你如何界定由誰擔責？

需要根據企業實際情況出發分析QA是否需要，而相應的技術人才又從何而來。

有這麼一說，測試團隊是否真的有存在的必要，這要看情況。如果從事的工程太小，可能就是自己給自己做的。無知，對軟體工程幾乎一竅不通的團隊，採用一窩蜂的開發方式。人手不夠，一人幹兩件事情甚至更過事情，恨不得長出來三頭六臂。

還有其他一種與上面相對立的情況出現，前面時比較弱的小企業，甚至是不到十人的小工作室。但是如果是大神或者是擁有強大雄厚資金的帝國企業，那麼情況就另一種情況。

人太牛：高德納認為排班軟體不如他意，所以自己動手寫一款自己的專屬軟體，他對其中的程式碼和原理了如指掌，哪裡出錯會第一時間更改。然而有多少這樣的神級人物存在？即使存在，他們在大型團隊中也能運籌帷幄，不用擔心大問題的出現。

工程太小：前前後後程式碼加起來不超過千行，而且和前面大神相同，我只自己私用，管理起來更加輕鬆。但有侷限性，軟體只能自己這一個小圈子使用，出不去。

還有類似於Facebook的成熟經驗

公司的員工都在頻繁使用他們自己開發的軟體，相當於我們每個人都是測試人員，每一次操作之後還有LOG日誌檔案作為記錄。平臺還提供BUG反饋入口，千萬億使用者自動成為了測試一員。

Facebook作為一個平臺，自然後又第三方廠家想要以此為基礎開發自己的程式，他們更加專業，更容易找到問題。

群眾力量的作用之下更容易找到問題所在，這樣一來，測試部門的作用自然減少了。

可這僅僅只針對特殊企業，這種成功是很難被複制的。那麼針對普通的企業或是團隊，他們還是需要QA的。可不能誰都能當這個QA，門外漢自然是首先拒之門外的，讓一個不懂軟體工程的人測試，最高也就黑盒測試，可這又是沒有多少技術含量的職業。

最好是從本團隊中提拔，在團隊中工作有段時間的員工最好。他們更容易理解團隊程式碼風格，能第一時間找到問題所在，與開發團隊有很強的默契性。然而團隊還需要一個並不是本團隊提拔上來的專業QA，這名QA對程式碼自然有一定基礎和經驗。因為當代碼風格確定後，團隊內部的人員會產生我這樣寫是正確的的迷惑性想法，造成錯誤不斷累加。

這個時候團隊分工體現出來，細分每個團隊下每個部門的職責，在保持自身獨立執行不受外界干擾的前提下，與周圍團隊密切交流，不斷取長補短，實現一個統一的流水線一樣的開發環境。一旦哪裡出錯，可以很快找到問題根源，及時作出更