hp惠普軟件測(cè)試講義(ppt)

1、Software Product Testing Framework-Zeng,qi(AMS-ATS)1Software Product Testing ActivityAuthor: Department: AMS-ATS軟件產(chǎn)品的定義書(shū)寫(xiě)或其他手段記錄信息、概念、事物或程序組成的產(chǎn)品 平臺(tái)軟件：平臺(tái)軟件是一種以業(yè)務(wù)為導(dǎo)向，可快速構(gòu)建應(yīng)用軟件的平臺(tái)，典型如操作系統(tǒng)類(lèi)軟件及其他可供二次開(kāi)發(fā)的軟件。應(yīng)用軟件：為實(shí)現(xiàn)特定應(yīng)用功能或目的而開(kāi)發(fā)的應(yīng)用程序,應(yīng)用程序可運(yùn)行于平臺(tái)軟件之上。軟件測(cè)試的定義 軟件測(cè)試就是在受控制的條件下對(duì)系統(tǒng)或應(yīng)用程序進(jìn)行操作并評(píng)價(jià)操作結(jié)果的過(guò)程,所謂控制條件應(yīng)包括正常條件與

2、非正常條件 1.程序測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程 G.J.Myers 2.評(píng)價(jià)一個(gè)程序和系統(tǒng)的特性或能力，并確定它是否達(dá)到預(yù)期的結(jié)果。軟件測(cè)試就是以此為目的的任何行為 -Dr. Bill Hetzel 3.就是在既定的狀況條件下，運(yùn)行一個(gè)系統(tǒng)或組建，觀察記錄結(jié)果，并對(duì)其某些方面進(jìn)行評(píng)價(jià)的過(guò)程 -IEEE/ANSI標(biāo)準(zhǔn) 1990.軟件測(cè)試的目的 軟件測(cè)試的目的是為了保證軟件產(chǎn)品的最終質(zhì)量，在軟件開(kāi)發(fā)的過(guò)程中，對(duì)軟件產(chǎn)品進(jìn)行 質(zhì)量控制。軟件測(cè)試應(yīng)由獨(dú)立的評(píng)測(cè)部門(mén)負(fù)責(zé)，嚴(yán)格按照軟件測(cè)試流程，制定測(cè)試計(jì)劃、測(cè)試方案、測(cè)試規(guī)范，實(shí)施測(cè)試，對(duì)測(cè)試記錄進(jìn)行分析，并根據(jù)回歸測(cè)試情況撰寫(xiě)測(cè)試報(bào)告。 測(cè)試是

3、為了證明程序有錯(cuò)，而不能保證程序沒(méi)有錯(cuò)誤 Software Product Testing Framework-Zeng,qi(AMS-ATS)5軟件測(cè)試方法依照測(cè)試手法分為白盒測(cè)試 (White-box or Glass-box)黑盒測(cè)試 (Black-box)灰盒測(cè)試 (Gray-box)有效用例 (Valid-Case)邊界條件 (Boundary-Case)等價(jià)類(lèi) (Equivalent-Classes)依照測(cè)試目的分為功能測(cè)試性能測(cè)試依照測(cè)試階段分為UATRegressionUnit .白盒測(cè)試 白箱測(cè)試或白盒測(cè)試(White-box testing 或glass-box testi

4、ng)是通過(guò)程序的源代碼進(jìn)行測(cè)試而不使用用戶界面。這種類(lèi)型的測(cè)試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點(diǎn)或者錯(cuò)誤，進(jìn)而加以修正。 黑盒測(cè)試 黑箱測(cè)試或黑盒測(cè)試(Black-box testing)是通過(guò)使用整個(gè)軟件或某種軟件功能來(lái)嚴(yán)格地測(cè)試, 而并沒(méi)有通過(guò)檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的。測(cè)試人員通過(guò)輸入他們的數(shù)據(jù)然后看輸出的結(jié)果從而了解軟件怎樣工作。通常測(cè)試人員在進(jìn)行測(cè)試時(shí)不僅使用肯定出正確結(jié)果的輸入數(shù)據(jù)，而且還會(huì)使用有挑戰(zhàn)性的輸入數(shù)據(jù)以及可能結(jié)果會(huì)出錯(cuò)的輸入數(shù)據(jù)以便了解軟件怎樣處理各種類(lèi)型的數(shù)據(jù)?；液袦y(cè)試 灰箱測(cè)試或灰盒

5、測(cè)試(Gray-box testing):灰箱測(cè)試就像黑箱測(cè)試一樣是通過(guò)用戶界面測(cè)試，但是測(cè)試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的。甚至于還讀過(guò)部分源代碼。 因此測(cè)試人員可以有的放矢地進(jìn)行某種確定的條件/功能的測(cè)試。這樣做的意義在于:如果你知道產(chǎn)品內(nèi)部的設(shè)計(jì)和對(duì)產(chǎn)品有透過(guò)用戶界面的深入了解，你就能夠更有效和深入地從用戶界面來(lái)測(cè)試它的各項(xiàng)性能。有效用例 有效用例(Valid case)或者叫合法輸入用例:是那些已知軟件程序能正確地處理的測(cè)試用例。一般是指軟件輸入的測(cè)試用例。比如說(shuō)，在 Microsoft Excel 中，用鍵盤(pán)輸入“=1+1”, 看到的結(jié)果是“2”。

6、這里輸入的有效用例是“=1+1”。無(wú)效用例(Invalid case有人叫不合法輸入用例)或者出錯(cuò)用例(error case):是那些事先就知道軟件程序不支持處理的測(cè)試用例。比如說(shuō)在 Microsoft Excel 中，用鍵盤(pán)輸入“=a+1”, 看到的結(jié)果是“#NAME?”。這里輸入的“=a+1”既是無(wú)效用例同時(shí)也是出錯(cuò)用例。 邊界條件 邊界條件(Boundary Cases):環(huán)繞邊界值的測(cè)試。通常意味著最大值，最小值或者所設(shè)計(jì)軟件能夠處理的最長(zhǎng)的字符串等等。比如說(shuō)某軟件字體的字號(hào)支持范圍是:從8到72。那么邊界測(cè)試用例應(yīng)該包括:小于8, 等于8, 等于72 和大于72。有效性 等價(jià)類(lèi)(eq

7、uivalent classes):等價(jià)類(lèi)測(cè)試用例指的是如果有很多測(cè)試用例執(zhí)行再多也不會(huì)找到新的缺陷。因?yàn)殡m然輸入和輸出結(jié)果有所不同，但是它們都通過(guò)同樣的軟件的源代碼路徑。通常只要一個(gè)源代碼程序的路徑是用于處理一定數(shù)值范圍內(nèi)的所有數(shù)值，那么除了邊界值以外，在邊界值范圍以內(nèi)的所有數(shù)值一般都屬于等價(jià)類(lèi)。因?yàn)槿绻浖绦蚰苷_處理一個(gè)值，也就意味著該程序能正確處理在這個(gè)范圍內(nèi)的除了邊界值以外的其他任何有效輸入值。我們來(lái)用以上軟件字體的字號(hào)來(lái)舉例說(shuō)明。軟件支持的字號(hào)范圍是:從8到72。那么8和72之間的所有支持的字號(hào)都可以被認(rèn)為是等價(jià)類(lèi)的測(cè)試用例。再比如:測(cè)試超鏈接時(shí)兩個(gè)用例http:/ 和 http

8、:/ 也是等價(jià)類(lèi)的測(cè)試用例。軟件測(cè)試方法沒(méi)有完全標(biāo)準(zhǔn)化和統(tǒng)一化 Software Product Testing Framework-Zeng,qi(AMS-ATS)13Testing is to establish confidence that a program does what it is supposed to do. http:/ Activity In ATS Software Product Testing Framework-Zeng,qi(AMS-ATS)14Traditional Testing Model in SDLCValidationVerificationLL

9、DHLDSystem testplanningIntegration testplanningUnit test planningUnit testingIntegrationTestingSystem TestingCodingDeliveryproductiondeploymentMaintenanceand enhancementURSUATplanningSRS User AcceptanceTestingWhy not make testing an independent lifecycle?Software Product Testing Framework-Zeng,qi(AM

10、S-ATS)15Comprehensive Capability ManagmentToolProcessPeopleSoftware Product Testing Framework-Zeng,qi(AMS-ATS)16ATS Automated Testing life cycle ManagmentToolProcessPeopleSoftware Product Testing Framework-Zeng,qi(AMS-ATS)17Operating Model (Integrated)CustomerRequirementsPrioritizationAcceptance Cri

11、teriaSchedulesReviews & ApprovalsDevelopment TeamDev &Testing SkillsDelivery MgmtTools & FrameworksDomain KnowledgeProcess EnablersSoftware Requirement AnalysisDesign (HLD & LLD etc.,)Development & Unit TestingIntegration & Defect FixingTest Requirement AnalysisTest Plan, Env

12、., and Automation)Test Design, Development & Base liningTest Execution, Defect Reporting & TrackingChange Mgmt, Configuration Mgmt, Risk Mgmt, Defect Mgmt and Release Mgmt etc Project Life CycleATS PracticeSoftware Product Testing Framework-Zeng,qi(AMS-ATS)18Operating Model (Dedicated)Custom

13、erRequirements & DocsPrioritizationAcceptance CriteriaSchedulesReviews & ApprovalsTest Requirement AnalysisTest Plan, Env., and Automation)Test Design, Development & Base liningTest Execution, Defect Reporting & TrackingChange Mgmt, Configuration Mgmt, Risk Mgmt, Defect Mgmt and Rele

14、ase Mgmt etc DevelopmentTeamIndependent Testing Life CycleATS PracticeTesting SkillsDelivery MgmtTools & FrameworksDomain KnowledgeProcess EnablersSoftware Product Testing Framework-Zeng,qi(AMS-ATS)19Operating Model (Managed)Quality of DeliverablesOptimizing productivityOptimizing resource utili

15、zation Optimizing turnaround timeTestRequirementsATS ProgramManagement Group Project plan (ITLC) Resource requirementsStrategyOperating model ScheduleProcess DeliverablesResource Loading PlanRelease planConfig planAssignmentsTest Bed PreparationTest Design/ scriptingTest ExecutionDefect ManagementAU

16、T 1AUT 2AUT 3AUT AUT nTest Lead 1Test Lead 2Test Lead 3Test Lead .Test Lead nSOP and Test Tools CMM/ISO based HP IQMS Processesand ProceduresBest Practices of ATS PracticeProven Methodologies & Customized Test StrategiesReview & ApprovalsPrioritizationSchedulesAcceptance CriteriaRequirements

17、 & DocsCustomerSoftware Product Testing Framework-Zeng,qi(AMS-ATS)20Practice In Software Product TestingSoftware Product Testing Framework-Zeng,qi(AMS-ATS)21軟件產(chǎn)品開(kāi)發(fā)模型Software Product Testing Framework-Zeng,qi(AMS-ATS)22軟件產(chǎn)品開(kāi)發(fā)Software Product Testing Framework-Zeng,qi(AMS-ATS)23軟件產(chǎn)品的特點(diǎn)1.周期延續(xù)性:軟件產(chǎn)品

18、開(kāi)發(fā)周期長(zhǎng) 測(cè)試切入點(diǎn)早2.功能穩(wěn)定性:軟件產(chǎn)品發(fā)布后對(duì)穩(wěn)定性要求更高 一旦發(fā)生招回成本無(wú)法估量3.功能擴(kuò)展性:便捷的接口 便于功能拓展和二次開(kāi)發(fā)4.環(huán)境兼容性:對(duì)使用環(huán)境的軟硬件要求較好的兼容性5.需求市場(chǎng)+主觀導(dǎo)向且相對(duì)穩(wěn)定6.客戶群體多樣行 面向行業(yè)多樣性:產(chǎn)品的易用性和廣泛適用性7.安全性:加密 知識(shí)產(chǎn)權(quán) 防破解防盜版8.主動(dòng)Software Product Testing Framework-Zeng,qi(AMS-ATS)24軟件項(xiàng)目的特點(diǎn)（相較于軟件產(chǎn)品）周期延續(xù)性:項(xiàng)目開(kāi)發(fā)時(shí)間短 測(cè)試切入點(diǎn)晚功能擴(kuò)展性:通常無(wú)須考慮功能拓展和二次開(kāi)發(fā)集成特性:多種軟件產(chǎn)品的集成 在已知環(huán)境下配

19、置安裝需求客戶導(dǎo)向變更大且頻繁客戶群體固定或已知被動(dòng)Software Product Testing Framework-Zeng,qi(AMS-ATS)25軟件產(chǎn)品測(cè)試的特點(diǎn)1.通常為黑盒 遵循使用說(shuō)明2.站在市場(chǎng)、超用戶超行業(yè)的角度 偏重用戶的視角3.各種軟硬件環(huán)境下的兼容性測(cè)試4.穩(wěn)定性測(cè)試5.需求變更少導(dǎo)致測(cè)試用例可重用性高 Software Product Testing Framework-Zeng,qi(AMS-ATS)26軟件產(chǎn)品測(cè)試的方法兩類(lèi)經(jīng)典的測(cè)試方法驗(yàn)證軟件是工作的 目前的主流和行業(yè)標(biāo)準(zhǔn) 第一類(lèi)測(cè)試可以簡(jiǎn)單抽象地描述為這樣的過(guò)程：在設(shè)計(jì)規(guī)定的環(huán)境下運(yùn)行軟件的功能,將其結(jié)

20、果與用戶需求或設(shè)計(jì)結(jié)果相比較，如果相符則測(cè)試通過(guò)，如果不相符則視為Bug,這一過(guò)程的終極目標(biāo)是將軟件的所有功能在所有設(shè)計(jì)規(guī)定的環(huán)境全部運(yùn)行. 測(cè)試軟件產(chǎn)品前期驗(yàn)證軟件是不工作的一個(gè)成功的測(cè)試必須是發(fā)現(xiàn)Bug的測(cè)試，不然就沒(méi)有價(jià)值。如同一個(gè)病人（假定此人確有?。?，到醫(yī)院做一項(xiàng)醫(yī)療檢查，結(jié)果各項(xiàng)指標(biāo)都正常，那說(shuō)明該項(xiàng)醫(yī)療檢查對(duì)于診斷該病人的病情是沒(méi)有價(jià)值的，是失敗的,沒(méi)有沒(méi)有bug的程序.通過(guò)BUG數(shù)量來(lái)衡量測(cè)試人員的工作量. 測(cè)試軟件產(chǎn)品后期Software Product Testing Framework-Zeng,qi(AMS-ATS)27軟件產(chǎn)品測(cè)試的方法兩類(lèi)經(jīng)典的測(cè)試方法的優(yōu)劣比較雖然

21、軟件測(cè)試總的目的是為了軟件產(chǎn)品的質(zhì)量，這兩類(lèi)測(cè)試方法在具體目標(biāo)、或指導(dǎo)思想上截然相反。由此也決定了它們?cè)谒悸贰⑦^(guò)程和測(cè)重點(diǎn)上有很大的差別，并各有利弊的。一類(lèi)測(cè)試方法以需求和設(shè)計(jì)為本，有利于界定測(cè)試工作的范疇，更便于部署測(cè)試的側(cè)重點(diǎn)，加強(qiáng)針對(duì)性。這一點(diǎn)對(duì)于應(yīng)用程序的測(cè)試，尤其是在有限的時(shí)間和人力資源情況下顯得格外重要。而二類(lèi)測(cè)試方法與需求和設(shè)計(jì)沒(méi)有必然的關(guān)聯(lián)，如果計(jì)劃管理不當(dāng)，測(cè)試活動(dòng)很容易丟失重點(diǎn)。一類(lèi)測(cè)試方法可以與軟件的架構(gòu)和軟件開(kāi)發(fā)的計(jì)劃相配合，使軟件測(cè)試活動(dòng)逐層次的展開(kāi)，從而使軟件的功能和質(zhì)量有計(jì)劃地逐步完善和提高。（二類(lèi)測(cè)試方法不具備這種過(guò)程的漸進(jìn)性）一類(lèi)測(cè)試方法的缺點(diǎn)是缺乏靈活性，不

22、利于測(cè)試人員主觀能動(dòng)性的發(fā)揮，不容易找到軟件的錯(cuò)誤。而這方面正是二類(lèi)測(cè)試方法的長(zhǎng)處。Software Product Testing Framework-Zeng,qi(AMS-ATS)28我們的策略以一類(lèi)測(cè)試方法為基礎(chǔ)和主要線索階段性地運(yùn)用二類(lèi)測(cè)試方法Software Product Testing Framework-Zeng,qi(AMS-ATS)29一類(lèi)測(cè)試流程一、審核需求和設(shè)計(jì)一類(lèi)測(cè)試是以需求和設(shè)計(jì)為本來(lái)驗(yàn)證軟件的正確性。需求和設(shè)計(jì)本身也有正確性的問(wèn)題。依據(jù)不正確的需求和設(shè)計(jì)不可能開(kāi)發(fā)出正確的軟件產(chǎn)品，測(cè)試也將是徒勞的。因此驗(yàn)證需求和設(shè)計(jì)是進(jìn)行一類(lèi)測(cè)試的第一步。這里所說(shuō)的需求和設(shè)計(jì)具

23、體說(shuō)來(lái)它一般包括：（1）由項(xiàng)目經(jīng)理根據(jù)用戶要求（信息來(lái)源于市場(chǎng)部門(mén)，用戶支持部門(mén)等等）而編寫(xiě)的需求文本（Requirement Specification）；（2）由項(xiàng)目經(jīng)理根據(jù)需求文本而編寫(xiě)的功能設(shè)計(jì)文本（Functional Design Specification）；（3）由開(kāi)發(fā)人員根據(jù)功能文本而編寫(xiě)的實(shí)施設(shè)計(jì)文本（Implementation Design Specification）。測(cè)試人員要參與所有這些文本的審核。作為測(cè)試人員，審核重點(diǎn)是檢查文本對(duì)需求定義的完整性、嚴(yán)密性和功能設(shè)計(jì)的可測(cè)性。同時(shí)這種審核對(duì)于測(cè)試人員也是一種熱身活動(dòng)，使他們盡早地進(jìn)入技術(shù)和業(yè)務(wù)狀態(tài)。Software

24、 Product Testing Framework-Zeng,qi(AMS-ATS)30一類(lèi)測(cè)試流程二、設(shè)計(jì)測(cè)試測(cè)試人員根據(jù)已審核通過(guò)的需求和設(shè)計(jì)編制測(cè)試計(jì)劃，設(shè)計(jì)測(cè)試用例。在前面提到的三種文本中，功能設(shè)計(jì)文本是主要依據(jù)。這類(lèi)測(cè)試關(guān)心的是軟件是否能正確地實(shí)現(xiàn)功能，而不是這些功能如何被具體實(shí)施的。這是典型的“黑盒測(cè)試”。軟件產(chǎn)品的測(cè)試主要是從用戶角度進(jìn)行的黑盒測(cè)試。這一步的完成就意味著“測(cè)試計(jì)劃”和“測(cè)試用例設(shè)計(jì)”兩個(gè)文本的完成?！皽y(cè)試計(jì)劃” 文本主要闡述測(cè)試的范疇、領(lǐng)域、方法、工具、資源和計(jì)劃時(shí)間表等等?！皽y(cè)試用例設(shè)計(jì)”文本要列出測(cè)試用例、每個(gè)用例的設(shè)置、執(zhí)行步驟和預(yù)期結(jié)果。測(cè)試的這兩個(gè)文本

25、也要被項(xiàng)目經(jīng)理和開(kāi)發(fā)人員審核。這樣經(jīng)過(guò)各種相互的審核，大家對(duì)項(xiàng)目形成了基本的共識(shí)。 Software Product Testing Framework-Zeng,qi(AMS-ATS)31一類(lèi)測(cè)試流程三、實(shí)施運(yùn)行測(cè)試 實(shí)施運(yùn)行測(cè)試是整個(gè)開(kāi)發(fā)過(guò)程中最長(zhǎng)最復(fù)雜的階段。從總體上說(shuō)就是將上一步設(shè)計(jì)的測(cè)試用例按計(jì)劃付諸實(shí)施的過(guò)程。 這包括編寫(xiě)自動(dòng)化測(cè)試程序、反復(fù)運(yùn)行自動(dòng)化測(cè)試程序，也包括階段性執(zhí)行手動(dòng)測(cè)試用例。這一階段的測(cè)試必須在周密的計(jì)劃下進(jìn)行，這正是第一類(lèi)測(cè)試的特點(diǎn)和長(zhǎng)處。這種計(jì)劃性首先體現(xiàn)在開(kāi)發(fā)和測(cè)試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴(lài)關(guān)系，按照項(xiàng)目的總體計(jì)劃共同推進(jìn)。從測(cè)試的過(guò)程來(lái)看

26、，總是先運(yùn)行或執(zhí)行簡(jiǎn)單用例，然后再?gòu)?fù)雜用例；先驗(yàn)證單一的基本功能，再綜合的端到端的功能；先發(fā)現(xiàn)解決表面的，影響面大的Bug，再深層的，不容易重現(xiàn)的Bug。因此隨著項(xiàng)目開(kāi)發(fā)和測(cè)試的進(jìn)程，產(chǎn)品的功能不斷完善，質(zhì)量不斷提高。這里有一點(diǎn)要特別指出，有很多測(cè)試用例是要反復(fù)運(yùn)行的，特別是基本的自動(dòng)化測(cè)試每一天，每一個(gè)Build上都要運(yùn)行。盡管這些測(cè)試大多數(shù)情況下都是通過(guò)的，很少再發(fā)現(xiàn)新的Bug，但其價(jià)值是顯而易見(jiàn)的，就是為了防止質(zhì)量回歸。這一階段測(cè)試人員還有一項(xiàng)繁瑣但卻很重要的工作，就是對(duì)已有的測(cè)試用例的維護(hù)。比如通常以下兩種情況下要新增一些測(cè)試用例，一是對(duì)于當(dāng)初測(cè)試設(shè)計(jì)不周全的領(lǐng)域，二是對(duì)于外部的Bug

27、（比如從Beta客戶報(bào)告來(lái)的），沒(méi)有被現(xiàn)有測(cè)試用例所覆蓋。當(dāng)產(chǎn)品的功能設(shè)計(jì)出現(xiàn)更改時(shí),所涉及的測(cè)試用例當(dāng)然也要相應(yīng)地修改。 Software Product Testing Framework-Zeng,qi(AMS-ATS)32二類(lèi)測(cè)試流程階段性測(cè)試根據(jù)需要而帶有隨機(jī)性和突擊性。對(duì)于這類(lèi)測(cè)試，有一個(gè)專(zhuān)門(mén)的名稱(chēng)：“Bug Bash（Bug大掃除）”。Bug Bash通常發(fā)生在產(chǎn)品開(kāi)發(fā)各階段（里程碑）的末期，比如Beta版發(fā)布前，劃出一個(gè)專(zhuān)門(mén)的時(shí)間段（通常1-3天），在這期間所有參與項(xiàng)目的人員，集中全部精力，運(yùn)用各方面的知識(shí)來(lái)搜尋項(xiàng)目的Bug。一般有以下要點(diǎn)：1）盡管這是一個(gè)測(cè)試活動(dòng)，但參與者并

28、不僅限于測(cè)試人員。項(xiàng)目經(jīng)理，開(kāi)發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動(dòng)員。目的是要集思廣益； 2）鼓勵(lì)各部門(mén)，領(lǐng)域交叉搜索，新的思路和視角通常有助于發(fā)現(xiàn)更多的Bug； 3）分專(zhuān)題展開(kāi)，比如安全性、用戶界面可用性、國(guó)際化和本地化等等。4) 專(zhuān)業(yè)性的測(cè)試，如針對(duì)安全性攻擊測(cè)試。可邀請(qǐng)公司內(nèi)部，或業(yè)界的專(zhuān)家來(lái)搜尋產(chǎn)品的漏洞。Software Product Testing Framework-Zeng,qi(AMS-ATS)33測(cè)試與開(kāi)發(fā)的融合Software Product Testing Framework-Zeng,qi(AMS-ATS)34測(cè)試與開(kāi)發(fā)流程融合趨勢(shì)有意整合測(cè)試和開(kāi)發(fā)融合的手

29、段1、測(cè)試活動(dòng)的早期展開(kāi)，讓測(cè)試人員參與用戶需求的驗(yàn)證，參加功能設(shè)計(jì)和實(shí)施設(shè)計(jì)的審核。2、如測(cè)試人員與開(kāi)發(fā)人員的密切合作，隨著開(kāi)發(fā)進(jìn)展而逐步實(shí)施單元測(cè)試、模塊功能測(cè)試和系統(tǒng)整合測(cè)試。以上都是測(cè)試與開(kāi)發(fā)融合的表現(xiàn)形式，而且初期的融合也只反映在這個(gè)層次上。90年代以后，軟件的規(guī)模和復(fù)雜程度迅速提高，這種形式上的融合也迅速走向更深層次，更具實(shí)際意義。具體地說(shuō)這種融合就是整個(gè)軟件開(kāi)發(fā)活動(dòng)對(duì)測(cè)試的依賴(lài)性。傳統(tǒng)上認(rèn)為，只有軟件的質(zhì)量控制依賴(lài)于測(cè)試，但是現(xiàn)代軟件開(kāi)發(fā)的實(shí)踐證明，不僅軟件的質(zhì)量控制依賴(lài)于測(cè)試，開(kāi)發(fā)本身離開(kāi)測(cè)試也將無(wú)法推進(jìn)，項(xiàng)目管理離開(kāi)了測(cè)試也從根本上失去了依據(jù)。Software Product

30、 Testing Framework-Zeng,qi(AMS-ATS)35測(cè)試在產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)中的作用1、協(xié)調(diào)開(kāi)發(fā) 在微軟，這種協(xié)調(diào)是通過(guò)測(cè)試來(lái)實(shí)現(xiàn)的。具體來(lái)說(shuō)就是：每日建造+自動(dòng)化測(cè)試。就是每天都建造一個(gè)新版本，每個(gè)版本都要運(yùn)行通過(guò)一定量的自動(dòng)測(cè)試用例，以檢驗(yàn)當(dāng)天工作的質(zhì)量。這里所說(shuō)的質(zhì)量有一般意義上質(zhì)量的概念，同時(shí)它也反映項(xiàng)目在開(kāi)發(fā)過(guò)程中的整體協(xié)調(diào)性。 自動(dòng)測(cè)試的最大優(yōu)點(diǎn)在于它的高度可重復(fù)性。一個(gè)理想的自動(dòng)測(cè)試系統(tǒng)能夠讓人隨時(shí)、方便和迅速的運(yùn)行大量的測(cè)試用例。因此一個(gè)開(kāi)發(fā)人員可以通過(guò)檢查當(dāng)天的自動(dòng)測(cè)試結(jié)果來(lái)分析前一天代碼的質(zhì)量（事后檢查），也可以在當(dāng)天存入代碼前，先運(yùn)行自動(dòng)測(cè)試以進(jìn)一步確保存

31、入代碼的質(zhì)量（事前檢查）。 在微軟，每日建造都是在午夜開(kāi)始，完成后緊接著就是全面的自動(dòng)測(cè)試，到早晨上班時(shí)間之前就會(huì)把結(jié)果自動(dòng)通過(guò)e-mail等方式發(fā)送出來(lái)。開(kāi)發(fā)人員上班后的第一件事往往就是檢查測(cè)試結(jié)果。如果沒(méi)有問(wèn)題就會(huì)開(kāi)始新的工作。如果有測(cè)試有用例沒(méi)有通過(guò)，開(kāi)發(fā)人員則必須協(xié)同測(cè)試人員一起立刻找出原因，解決后才能開(kāi)始新的代碼。有時(shí)一個(gè)小的失誤會(huì)引起大面積的測(cè)試用例失敗，很大一部分開(kāi)發(fā)團(tuán)隊(duì)會(huì)受到影響。為盡量避免這種情況，要求開(kāi)發(fā)人員在存入代碼之前先在自己的個(gè)人建造版本上運(yùn)行一定量的自動(dòng)測(cè)試，全部通過(guò)后在存入。如開(kāi)發(fā)人員沒(méi)有按照這樣的要求，而擅自存入質(zhì)量不高的代碼而造成大量測(cè)試失敗，這種不負(fù)責(zé)任的行為是要受到嚴(yán)厲批評(píng)的。從這一過(guò)程可以看出，開(kāi)發(fā)人員依賴(lài)測(cè)試來(lái)保證開(kāi)發(fā)工作的質(zhì)量，使開(kāi)發(fā)整體地協(xié)調(diào)地向前推進(jìn)。Software Product Testing Framework-Zeng,qi(AMS-ATS)36測(cè)試在產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)中的作用1、協(xié)調(diào)開(kāi)發(fā) 當(dāng)開(kāi)發(fā)進(jìn)入后期階段，盡管項(xiàng)目已總體成型，開(kāi)發(fā)人員也會(huì)不時(shí)遇到一些技術(shù)上的挑戰(zhàn)。比如一些Bug的解決涉及對(duì)項(xiàng)目深層次結(jié)構(gòu)的調(diào)整；由于客戶反饋的意見(jiàn)造成設(shè)計(jì)的修改。每一次這樣的修改和調(diào)整事實(shí)