請(qǐng)問it行業(yè)平時(shí)說的p4,p5級(jí)別的工程師需要達(dá)到什么標(biāo)準(zhǔn)？

請(qǐng)問it行業(yè)平時(shí)說的p4,p5級(jí)別的工程師需要達(dá)到什么標(biāo)準(zhǔn)？

IT行業(yè)說的p4,p5級(jí)別的工程師要根據(jù)不同公司的級(jí)別來看，比如阿里巴巴，p4,p5是屬于初級(jí)工程師，大概就是本科剛畢業(yè)就能到p5左右。

IT工程師是一個(gè)認(rèn)證考試，具體地說是從事軟件職業(yè)的人員的一種職業(yè)能力的認(rèn)證，通過它說明具備了工程師的資格。

IT工程師的技術(shù)要求是比較全面的，除了最基礎(chǔ)的編程語(yǔ)言（C語(yǔ)言/C++/JAVA等）、數(shù)據(jù)庫(kù)技術(shù)（SQL/ORACLE/DB2等）等，還有諸多如JAVA script、AJAX、HIBERNATE、SPRING等前沿技術(shù)。此外，關(guān)于網(wǎng)絡(luò)工程和軟件測(cè)試的其他技術(shù)也要有所涉獵。

擴(kuò)展資料：

IT工程師的職業(yè)需求

1、外包開發(fā)行業(yè)快速發(fā)展，對(duì)“人才”在代碼和文檔方面的規(guī)范性、技能和工具的熟練程度要求越來越高；

2、Java和.NET技術(shù)在市場(chǎng)上平分秋色，都有大量的崗位需求，同時(shí)值得慶幸的是二者在應(yīng)用層面上的技術(shù)差異越來越少；

3、軟件開發(fā)企業(yè)對(duì)開發(fā)人員的基本技術(shù)素養(yǎng)強(qiáng)調(diào)得越來越多，例如：面向?qū)ο蟮某绦蛟O(shè)計(jì)思想和代碼組織方法、HTML/CSS/Javascript客戶端技術(shù)；

4、為了保證質(zhì)量和工期，企業(yè)中大量使用各種框架技術(shù)，要求開發(fā)人員至少熟悉一種框架技術(shù)。

軟件缺陷管理

The First “Computer Bug” | 首個(gè)“計(jì)算機(jī)Bug”

1947年9月9日，哈佛大學(xué)測(cè)試馬克II型艾肯中繼器計(jì)算機(jī)，操作員在電板編號(hào)為70的中繼器觸點(diǎn)旁發(fā)現(xiàn)了一只飛蛾。然后操作員把飛蛾貼在計(jì)算機(jī)日志上了，并寫下了“首個(gè)發(fā)現(xiàn)bug的實(shí)際案例”。他們提出了一個(gè)詞，“debug（調(diào)試）”了機(jī)器，從而引入新術(shù)語(yǔ)“debugging a computer program（調(diào)試計(jì)算機(jī)程序）”。

In 1988,the log,with the moth still taped by the entry,was in the Naval Surface Warfare Center Computer Museum at Dahlgren,Virginia.

1988年，這個(gè)仍然貼著飛蛾的日志，保存于弗吉尼亞州達(dá)爾格倫的海軍水面作戰(zhàn)中心計(jì)算機(jī)博物館。

以下的兩句話明確了缺陷的產(chǎn)生。

軟件缺陷的產(chǎn)生主要有軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的。比如需求不夠清晰，頻繁變更等；或者軟件由于競(jìng)爭(zhēng)非常激烈，技術(shù)日新月異，使用新技術(shù)也容易產(chǎn)生問題。大致有以下幾種主要原因：

軟件測(cè)試就是為了更早、更快的發(fā)現(xiàn)缺陷。換句話說，缺陷的發(fā)現(xiàn)可以看作是測(cè)試工作的主要成果之一。軟件缺陷管理的實(shí)施，至少有如下三個(gè)基本目的：

軟件缺陷（Defect），常常又被叫做Bug。所謂軟件缺陷，即為計(jì)算機(jī)軟件或程序中存在的某種破壞正常運(yùn)行能力的問題、錯(cuò)誤，或者隱藏的功能缺陷。缺陷的存在會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。

bug 和 defect

飛蛾或者蟲子爬進(jìn)主機(jī)引起短路，造成計(jì)算機(jī)失效的事件中，我們可以看到bug就是蟲子或者是蟲子引發(fā)失效這樣的事件。那么defect又是什么呢？

真正的Defect是計(jì)算機(jī)維護(hù)工程師提出來的那個(gè)問題：在主機(jī)的散熱孔那里可以加裝一層更加細(xì)密的金屬網(wǎng)，即不影響散熱，又可以防止蟲子爬到主機(jī)里。這是計(jì)算機(jī)設(shè)計(jì)人員疏忽的地方，是產(chǎn)品真正的Defect。而蟲子引發(fā)的那個(gè)故障只是這個(gè)Defect導(dǎo)致的故障的其中一種表現(xiàn)形式。也就是說，Bug是Defect的一種表現(xiàn)形式，而一個(gè)Defect是可以引起多種Bug的。

軟件測(cè)試使用各種術(shù)語(yǔ)描述軟件出現(xiàn)的問題，通用的術(shù)語(yǔ)如下：

在可以預(yù)見的時(shí)期內(nèi)，軟件仍將由人來開發(fā)。在整個(gè)軟件生存期的各個(gè)階段，都貫穿者人的直接或間接的干預(yù)。然而，人難免犯錯(cuò)誤，這必然給軟件留下不良的痕跡。軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不可接受的人為錯(cuò)誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生?？梢?，軟件錯(cuò)誤是一種人為過程，相對(duì)于軟件本身，是一種外部行為。

軟件缺陷是存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望或不可接受的偏差，如少一個(gè)逗號(hào)、多一語(yǔ)句等。其結(jié)果是軟件運(yùn)行于某一特定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷被激活。

軟件故障是指軟件運(yùn)行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。譬如，軟件處于執(zhí)行一個(gè)多余循環(huán)過程時(shí)，我們說軟件出現(xiàn)故障。此時(shí)若無(wú)時(shí)當(dāng)?shù)拇胧ㄈ蒎e(cuò)）加以及時(shí)處理，便產(chǎn)生軟件失效。顯然，軟件故障是一種動(dòng)態(tài)行為。

軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生 的一種不希望或不可接受的外部行為結(jié)果。失效是指功能部件執(zhí)行其規(guī)定功能的能力喪失。軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可接受的外部行為。

軟件錯(cuò)誤是一種人為錯(cuò)誤。一個(gè)軟件錯(cuò)誤必定產(chǎn)生一個(gè)或多個(gè)軟件缺陷。當(dāng)一個(gè)軟件缺陷被激活時(shí)，便產(chǎn)生一個(gè)軟件故障；同一個(gè)軟件缺陷在不同條件下被激活，可能產(chǎn)生不同的軟件故障。軟件故障如果沒有集市的容錯(cuò)措施加以處理，便不可避免地導(dǎo)致軟件失效；同一個(gè)軟件故障在不同條件下可能產(chǎn)生不同的軟件失效。

測(cè)試執(zhí)行過程中，發(fā)現(xiàn)軟件失效后，提出書面的報(bào)告，提供給開發(fā)人員或者其他負(fù)責(zé)人員作為定位缺陷的依據(jù)，也作為日后缺陷度量的數(shù)據(jù)依據(jù)。

軟件缺陷的描述是軟件缺陷報(bào)告的基礎(chǔ)部分，也是測(cè)試人員就一個(gè)軟件問題與開發(fā)小組交流的最初并且最好的機(jī)會(huì)。一個(gè)好的描述，需要使用簡(jiǎn)單、準(zhǔn)確、專業(yè)的語(yǔ)言來抓住缺陷的本質(zhì)。否則，它就會(huì)使信息含糊不清，可能會(huì)誤導(dǎo)開發(fā)人員。因此，準(zhǔn)確的報(bào)告軟件缺陷是非常重要的。

軟件缺陷的屬性從大的方面包括以下幾部分：

綜上所述，一個(gè)完整的缺陷報(bào)告需要包括以下內(nèi)容。

| 缺陷的狀態(tài) | 描述 |

| ---------------------------- | ----------------------- |

| 激活的或打開的（Active or Open） | 缺陷的起始狀態(tài)，問題還沒有解決，等待修復(fù) |

| 已修正的或已修復(fù)的（Fixed or Resolved） | 已被開發(fā)人員檢查和修復(fù)，等待驗(yàn)證人員驗(yàn)證 |

| 關(guān)閉的或非激活的（Close or Inactive） | 驗(yàn)證通過，確認(rèn)缺陷已經(jīng)可以關(guān)閉 |

| 重新打開 （Reopen） | 驗(yàn)證不通過，需要 |

| 推遲 （Deferred） | 缺陷不嚴(yán)重，在下一個(gè)版本中解決 |

| 保留 （On hold） | 由于技術(shù)原因或者其他原因，暫時(shí)無(wú)法解決 |

| 功能增強(qiáng) | 發(fā)現(xiàn)的缺陷符合當(dāng)前說明書。是一個(gè)有待改進(jìn)的問題 |

| 不是缺陷 | |

| 不能重現(xiàn) | |

| 需要更多信息 | |

| 缺陷的嚴(yán)重級(jí)別 | 描述 |

| ------------ | -------------------------------- |

| 致命（Fatal） | 系統(tǒng)的主要功能完全失效，用戶利益受到損失、系統(tǒng)崩潰、死機(jī)等 |

| 嚴(yán)重（Critical） | 系統(tǒng)的主要功能部分失效，數(shù)據(jù)無(wú)法保存、提供的服務(wù)受到影響 |

| 一般（Major） | 系統(tǒng)的次要功能沒有完全實(shí)現(xiàn)，不影響用戶的正常使用，如提示不準(zhǔn)確等 |

| 較?。∕inor） | 用戶體驗(yàn)不好，不影響功能實(shí)現(xiàn) |

| 缺陷的優(yōu)先級(jí) | 描述 |

| -------- | ----------------------- |

| 立即解決（P1） | 缺陷導(dǎo)致系統(tǒng)不可使用，無(wú)法測(cè)試或者測(cè)試無(wú)法繼續(xù) |

| 高優(yōu)先級(jí)（P2） | 缺陷嚴(yán)重，影響測(cè)試，需要優(yōu)先考慮 |

| 正常排隊(duì)（P3） | 缺陷需要正常排隊(duì)等待修復(fù) |

| 低優(yōu)先級(jí)（P4） | 缺陷可以在開發(fā)人員有時(shí)間的時(shí)候被修正 |

缺陷的嚴(yán)重性和優(yōu)先級(jí)是含義不同但相互聯(lián)系密切的兩個(gè)概念。它們都從不同的側(cè)面描述了軟件缺陷對(duì)軟件質(zhì)量和最終用戶的影響程度和處理方式。

一般地，嚴(yán)重性程度高的軟件缺陷具有較高的優(yōu)先級(jí)。嚴(yán)重性高說明缺陷對(duì)軟件造成的質(zhì)量危害性大，需要優(yōu)先處理，而嚴(yán)重性低的缺陷可能只是軟件不太盡善盡美，可以稍后處理。

但是，嚴(yán)重性和優(yōu)先級(jí)并不總是一一對(duì)應(yīng)。有時(shí)候嚴(yán)重性高的軟件缺陷，優(yōu)先級(jí)不一定高，甚至不需要處理，而一些嚴(yán)重性低的缺陷卻需要及時(shí)處理，具有較高的優(yōu)先級(jí)。

生命周期的概念是從誕生到消亡所經(jīng)歷的過程。軟件缺陷經(jīng)歷了從被發(fā)現(xiàn)、報(bào)告、到其被修復(fù)、驗(yàn)證、直至最后關(guān)閉的過程。為了完整的描述這個(gè)過程，設(shè)定了不同階段的缺陷狀態(tài)來體現(xiàn)缺陷不同的生命階段。對(duì)于測(cè)試人員來說，需要關(guān)注軟件缺陷狀態(tài)的變化，并和開發(fā)人員保持良好的溝通，使缺陷能夠及時(shí)得到處理和修正。

缺陷狀態(tài)的跟蹤

缺陷趨勢(shì)的分析

缺陷分布分析

累計(jì)缺陷趨勢(shì)分析

高分求軟件測(cè)試的測(cè)試計(jì)劃與測(cè)試用例,(詳情如下)

Boffice軟件系統(tǒng)測(cè)試計(jì)劃
Windows計(jì)算器的測(cè)試計(jì)劃
修訂歷史記錄
版本 日期 添加/修改/刪除 修訂者 說明
2009-5-5 張XX
目錄
1.簡(jiǎn)介
1. 1目的
Windows計(jì)算器的測(cè)試計(jì)劃文檔有助于實(shí)現(xiàn)以下目標(biāo)：
1.確定現(xiàn)有項(xiàng)目的信息和應(yīng)測(cè)試的軟件構(gòu)件
2.列出推薦的測(cè)試需求
3．推薦可采用的測(cè)試策略，并對(duì)這些策略加以說明
4.確定所需的資源，并對(duì)測(cè)試的工作量進(jìn)行估計(jì)
5.對(duì)整個(gè)測(cè)試工作的工作量進(jìn)行估計(jì)
6.對(duì)測(cè)試活動(dòng)的進(jìn)程進(jìn)行有計(jì)劃的實(shí)施
7.列出測(cè)試項(xiàng)目的可交付元素
1. 2背景
項(xiàng)目名稱：計(jì)算器
任務(wù)提出者：
開發(fā)者：
用 戶：個(gè)人
項(xiàng)目背景：windows自帶軟件????????
1. 3范圍
測(cè)試的各個(gè)階段：
測(cè)試設(shè)計(jì)：根據(jù)軟件行業(yè)標(biāo)準(zhǔn),制定測(cè)試計(jì)劃、測(cè)試方案，包括收集測(cè)試方法、測(cè)試用例及可能的測(cè)試工具等。
系統(tǒng)測(cè)試：主要針對(duì)功能、界面、安裝、版本驗(yàn)證進(jìn)行測(cè)試，對(duì)經(jīng)常使用的模塊進(jìn)行重點(diǎn)測(cè)試。
2.測(cè)試參考文檔和測(cè)試提交文檔
2.1. 測(cè)試參考文檔
無(wú)
2.2. 將要用到文檔
測(cè)試時(shí)間表、人員安排、測(cè)試總體計(jì)劃、測(cè)試方案、測(cè)試分析報(bào)告、測(cè)試用例模版、測(cè)試報(bào)告單模版、測(cè)試用例通過情況統(tǒng)計(jì)表、各個(gè)模塊的測(cè)試用例。
2.3. 測(cè)試提交文檔
測(cè)試報(bào)告、測(cè)試記錄、測(cè)試總結(jié)、工作日志。
2.4. 測(cè)試項(xiàng)目里程碑
里程碑任務(wù) 工作量 開始日期 結(jié)束日期
制訂測(cè)試計(jì)劃 X人/1.0天
設(shè)計(jì)測(cè)試用例 X人/0.5天
系統(tǒng)測(cè)試 X人/0.5天
測(cè)試總結(jié) X人/0.5天
2.5. 各測(cè)試階段資源要求及時(shí)間安排
人員 設(shè)備 時(shí)間安排
測(cè)試計(jì)劃 5臺(tái)計(jì)算機(jī)
測(cè)試設(shè)計(jì) 5臺(tái)計(jì)算機(jī)
系統(tǒng)測(cè)試 5臺(tái)計(jì)算機(jī)
測(cè)試總結(jié) 5臺(tái)計(jì)算機(jī)
2.6. 問題優(yōu)先級(jí)描述
嚴(yán)重程度：
Blocker 阻礙開發(fā)和/或測(cè)試工作
Critical 死機(jī)，數(shù)據(jù)丟失，內(nèi)存溢出
Major 較大的功能缺陷
Normal 普通的功能缺陷
Minor 較輕的功能缺陷
Trivial 產(chǎn)品外觀的問題或不影響使用的小毛病
Enhancement 建議或意見
優(yōu)先級(jí)：
描述 響應(yīng)時(shí)間
P1 用戶使用頻率高 督促開發(fā)發(fā)現(xiàn)問題后立即修改
P2 Minor輕微的缺陷 督促1-2個(gè)工作日修改
P3 Normal用戶經(jīng)常使用的功能 發(fā)布之前
P4 Trivial用戶很少使用的功能 可以在發(fā)布后修改的問題
2.7. 備注
3.術(shù)語(yǔ)和定義

4.測(cè)試策略
4. 1．功能測(cè)試
測(cè)試目標(biāo)： 系統(tǒng)提供的功能正常實(shí)現(xiàn)
方法： 測(cè)試開始階段主要針對(duì)的功能實(shí)現(xiàn)進(jìn)行測(cè)試。重要的功能應(yīng)投入更多的精力進(jìn)行測(cè)試，并及時(shí)小結(jié)
開始標(biāo)準(zhǔn)： 各個(gè)模塊集成一起，即可開始
需考慮的特殊事項(xiàng)： 注意其中一些重要功能與實(shí)際效果相關(guān)，并不是簡(jiǎn)單的功能實(shí)現(xiàn)
4.2．界面測(cè)試：
測(cè)試目標(biāo) 程序界面符合相關(guān)的規(guī)范
方法 按照規(guī)定逐項(xiàng)檢查，包括菜單項(xiàng)，按鈕，提示信息檢查提示信息中的文字和標(biāo)點(diǎn)符號(hào)，圖標(biāo)等
完成標(biāo)準(zhǔn) 程序界面與相關(guān)規(guī)定的要求統(tǒng)一
需考慮的特殊事項(xiàng) 注意啟動(dòng)畫面和安裝程序的版權(quán)信息注意版本信息
4.4.兼容性測(cè)試（資源不足，無(wú)法測(cè)試）
測(cè)試目標(biāo)： 測(cè)試軟件在當(dāng)前微軟系列操作系統(tǒng)中的運(yùn)行情況，以及和同類文字處理軟件的兼容性問題
方法： 1，在Microsoft Windows 98,ME,NT(Service Pack 6 之上),2000 及 XP中安裝軟件并能夠正常運(yùn)行，
2，測(cè)試軟件與同類軟件word97,word2000,word2003，WPS之間的兼容性問題。
3，與其它相關(guān)軟件web瀏覽器，繪圖程序等進(jìn)行兼容性測(cè)試。
完成標(biāo)準(zhǔn)： 能夠在微軟系列操作系統(tǒng)中正常安裝并且運(yùn)行，可以識(shí)別和處理其它廠商同類軟件生成的文件，同時(shí)產(chǎn)生的文件可以被其它廠商同類軟件所正確識(shí)別和處理，對(duì)于其它相關(guān)軟件如web瀏覽器，繪圖軟件等可以兼容運(yùn)行。
需考慮的特殊事項(xiàng)： 無(wú)

如何看待軟件測(cè)試在保證產(chǎn)品質(zhì)量中所起的作用？

1. 軟件測(cè)試基礎(chǔ)（P1-3）
測(cè)試基礎(chǔ)知識(shí)的學(xué)習(xí)目標(biāo)
本章的學(xué)習(xí)目標(biāo)：完成下面模塊(module)的學(xué)習(xí)后，將明確能做什么。
1.1測(cè)試的必要性
? 通過具體的例子，來描述軟件中的缺陷(defect)會(huì)以什么樣的方式損害個(gè)人、損害環(huán)境或者損害公司利益。
? 區(qū)分引起缺陷的根本原因及其影響之間的區(qū)別。
? 通過舉例的方式說明為什么需要測(cè)試。
? 描述為什么測(cè)試是質(zhì)量保證(quality assurance)的一部分，通過舉例說明測(cè)試是如何來提高軟件質(zhì)量的。
? 理解術(shù)語(yǔ)錯(cuò)誤(mistake)、缺陷、失效(failure)以及相應(yīng)的術(shù)語(yǔ)錯(cuò)誤(error)和bug之間的區(qū)別。
1.2 什么是測(cè)試 (K2)
? 認(rèn)識(shí)測(cè)試的共同目標(biāo)。
? 描述測(cè)試作為發(fā)現(xiàn)缺陷的一種手段，測(cè)試在軟件開發(fā)、維護(hù)和運(yùn)行中的目的，同時(shí)通過測(cè)試，可以增強(qiáng)對(duì)被測(cè)軟件的信心并獲得一些相關(guān)的信息，從而用來預(yù)防缺陷。
1.3 測(cè)試的基本原則
? 說明測(cè)試的基本原則。
1.4 基本的測(cè)試過程
再次認(rèn)識(shí)從計(jì)劃到測(cè)試結(jié)束過程中測(cè)試的基本活動(dòng)，以及在每個(gè)活動(dòng)中的主要任務(wù)（K1）。
1.5 測(cè)試的心理學(xué)
? 認(rèn)識(shí)測(cè)試的成功與否，會(huì)受測(cè)試心理因素的影響：
? 清楚的目標(biāo)；
? 自己測(cè)試和獨(dú)立測(cè)試之間的平衡；
? 認(rèn)識(shí)到謙恭的溝通和缺陷反饋在測(cè)試中的作用。
? 對(duì)比測(cè)試員(tester)和開發(fā)員(developer)的心理差異。
1.1 為什么需要測(cè)試 （P4-5）
術(shù)語(yǔ)
缺陷(bug)、缺陷(defect)、錯(cuò)誤(error)、失效(failure)、故障（fault）、錯(cuò)誤(mistake)、質(zhì)量（quality）、風(fēng)險(xiǎn)(risk)、軟件(software)、測(cè)試(testing)。
1.1.1 軟件系統(tǒng)的狀況
在當(dāng)今社會(huì)，軟件系統(tǒng)(system)越來越成為生活中不可或缺的一部分，包括從商業(yè)應(yīng)用（比如銀行系統(tǒng)）到消費(fèi)產(chǎn)品（比如汽車）各個(gè)領(lǐng)域。然而，很多人都有這樣的經(jīng)歷：軟件并沒有按照預(yù)期進(jìn)行工作。軟件的不正確執(zhí)行可能會(huì)導(dǎo)致許多問題，包括經(jīng)濟(jì)的損失、時(shí)間的浪費(fèi)和商業(yè)信譽(yù)的丟失等等，甚至導(dǎo)致人身傷害和死亡。
1.1.2 引起軟件缺陷的原因
所有的人都會(huì)犯錯(cuò)誤。該錯(cuò)誤error會(huì)成為設(shè)計(jì)的代碼、軟件、系統(tǒng)和文檔中的缺陷。當(dāng)存在缺陷的代碼被執(zhí)行時(shí)，系統(tǒng)就可能無(wú)法執(zhí)行期望的指令（或者做了不應(yīng)該執(zhí)行的指令），從而引起軟件失效（故障）。雖然軟件、系統(tǒng)和文檔中的缺陷可能會(huì)引起失效，但并不是所有的缺陷都會(huì)這樣。
產(chǎn)生缺陷的原因是多種多樣的：人們本身容易犯錯(cuò)誤、時(shí)間的壓力、復(fù)雜的代碼、復(fù)雜的系統(tǒng)架構(gòu)、技術(shù)的革新、或者系統(tǒng)之間的配合工作等。
失效也可能是由于環(huán)境條件引起的：放射、電磁輻射和污染等都有可能引起硬件的故障，或者由于硬件條件的改變而影響軟件的執(zhí)行。
※ error（錯(cuò)誤） → 缺陷（fault，bug） → 故障
1.1.3 在軟件開發(fā)、維護(hù)和運(yùn)行中測(cè)試的角色
對(duì)軟件系統(tǒng)和文檔進(jìn)行嚴(yán)格的測(cè)試,可以減少軟件系統(tǒng)在運(yùn)行環(huán)境中的風(fēng)險(xiǎn)，假如在軟件正式發(fā)布之前發(fā)現(xiàn)和修正了缺陷，就可以提高軟件系統(tǒng)的質(zhì)量。
進(jìn)行軟件測(cè)試也可能是為了滿足合同和法律法規(guī)的需求，或者是為了滿足行業(yè)標(biāo)準(zhǔn)。
1.1.4 測(cè)試和質(zhì)量
通過測(cè)試，根據(jù)發(fā)現(xiàn)的缺陷，就可能發(fā)現(xiàn)軟件系統(tǒng)在功能(functional)和非功能(non-functional)需求方面的缺陷，對(duì)軟件質(zhì)量(software quality)進(jìn)行評(píng)判。飛功能需求包括：可靠性(reliability)、可用性(usability）、效率(efficiency)和可維護(hù)性(maintainability)等方面，關(guān)于非功能測(cè)試方面的更多信息，可以參考第二章。更多關(guān)于軟件特征的信息，可以參考[ Software Engineering - Software Product Quality (ISO9126) ]?！鵌SO9126對(duì)應(yīng)與國(guó)內(nèi)規(guī)格：JIS-X0129。
當(dāng)測(cè)試發(fā)現(xiàn)很少或者沒有發(fā)現(xiàn)缺陷的時(shí)候，就會(huì)對(duì)軟件的質(zhì)量充滿信心。一個(gè)設(shè)計(jì)正確、合理的測(cè)試過程完成并順利通過，可以降低整個(gè)系統(tǒng)存在問題的風(fēng)險(xiǎn)。而對(duì)測(cè)試過程中發(fā)現(xiàn)的缺陷進(jìn)行了修正，則軟件系統(tǒng)的質(zhì)量就會(huì)提高。
我們應(yīng)該從以前的項(xiàng)目中總結(jié)經(jīng)驗(yàn)教訓(xùn)。通過分析在其他項(xiàng)目中發(fā)現(xiàn)的缺陷和引起缺陷的根本原因，我們就可以改進(jìn)測(cè)試過程(process)。相繼地，過程的改進(jìn)又可以預(yù)防相同的缺陷再次發(fā)生，從而提高以后系統(tǒng)的質(zhì)量。
測(cè)試應(yīng)該作為質(zhì)量保證的各種作業(yè)中（例如：開發(fā)標(biāo)準(zhǔn)、教育、缺陷分析）的不可或缺的一部分。
1.1.5 測(cè)試是否充分
測(cè)試應(yīng)該進(jìn)行到哪種程度，取決于技術(shù)、產(chǎn)品、項(xiàng)目風(fēng)險(xiǎn)的水平，以及在時(shí)間和預(yù)算等方面項(xiàng)目上的限制。（風(fēng)險(xiǎn)將在第5章進(jìn)行詳細(xì)描述）
測(cè)試需要給利益相關(guān)者提供足夠的信息，幫助他們決定是否發(fā)布被測(cè)的軟件或系統(tǒng)，是否繼續(xù)進(jìn)行下階段的開發(fā)或直接將產(chǎn)品交給用戶。
追求完全的品質(zhì)，從成本的角度來看沒有效果

缺陷成本：為了修正而產(chǎn)生的成本、產(chǎn)生不良結(jié)果的成本
Joseph M. Juran 1.テストの必要性（3/3
1.2 什么是測(cè)試（P7-8）
術(shù)語(yǔ)
代碼(code)、調(diào)試(debugging)、（軟件）開發(fā)(development)、需求(requirement)、評(píng)審(review)、測(cè)試依據(jù)(test basis)、測(cè)試用例(test case)、測(cè)試(testing)、測(cè)試目標(biāo)(test objectives)。
背景
在一般人的理解當(dāng)中，測(cè)試活動(dòng)只包含了運(yùn)行測(cè)試，也就是執(zhí)行軟件。但實(shí)際上這只是測(cè)試的一部分，而不是測(cè)試的所有活動(dòng)。
測(cè)試的活動(dòng)包含了測(cè)試執(zhí)行之前和之后的一些活動(dòng)，包括計(jì)劃(planning)和控制(control)、選擇測(cè)試條件(test condition)、設(shè)計(jì)測(cè)試用例(test case)、檢查測(cè)試結(jié)果(result)、評(píng)估完成準(zhǔn)則(completion criteria)、報(bào)告測(cè)試過程(test process)及被測(cè)系統(tǒng)、測(cè)試結(jié)束或總結(jié)。測(cè)試同時(shí)也包括文檔的評(píng)審(review)（包括代碼）和靜態(tài)分析(static analysis)。
動(dòng)態(tài)測(cè)試(dynamic testing)和靜態(tài)測(cè)試這兩種手段都可以達(dá)到相似的目標(biāo)，即以提供信息來改進(jìn)被測(cè)試軟件系統(tǒng)的質(zhì)量，以及改善開發(fā)和測(cè)試的過程。

985大學(xué) 211大學(xué) 全國(guó)院校對(duì)比 專升本