軟件測(cè)試實(shí)習(xí)筆記1

PAGEPAGE11***************************學(xué)習(xí)性能測(cè)試，掌握課程內(nèi)容性能測(cè)試知識(shí)點(diǎn)總結(jié)：--典型性能指標(biāo)虛擬并發(fā)用戶數(shù)（TotalVirtualUsers）單位:個(gè)交易響應(yīng)時(shí)間（ResponseTime）單位:second/millisecond并發(fā)用戶/響應(yīng)時(shí)間圖負(fù)載圖每分鐘交易數(shù)（TransRate）吞吐量圖（ThroughOut）--服務(wù)器負(fù)載壓力指標(biāo)操作系統(tǒng)CPU內(nèi)存硬盤數(shù)據(jù)庫(kù)*UserConnections：用戶連接數(shù)，也就是數(shù)據(jù)庫(kù)的連接數(shù)量；

*Numberofdeadlocks：數(shù)據(jù)庫(kù)死鎖；

*ButterCachehit：數(shù)據(jù)庫(kù)Cache的命中情況--應(yīng)用系統(tǒng)的指標(biāo)應(yīng)用系統(tǒng)根據(jù)自身功能性能要求確定的指標(biāo):比如支持的畫面數(shù)量TAG點(diǎn)的數(shù)量一幅畫面中支持的最多控件數(shù)量檢控更新周期能夠管理的IP數(shù)量--性能測(cè)試系統(tǒng)的性能是一個(gè)很大的概念，覆蓋面非常廣泛，對(duì)一個(gè)軟件系統(tǒng)而言包括執(zhí)行效率、資源占用、穩(wěn)定性、安全性、兼容性、可擴(kuò)展性、可靠性等等，我們這里重點(diǎn)討論的負(fù)載壓力是系統(tǒng)性能的一個(gè)重要方面。性能測(cè)試用來(lái)保證產(chǎn)品發(fā)布后系統(tǒng)的性能滿足用戶需求。性能測(cè)試在軟件質(zhì)量保證中起重要作用。--負(fù)載測(cè)試負(fù)載測(cè)試是確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測(cè)試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)組成部分的相應(yīng)輸出項(xiàng)，例如通過(guò)量、響應(yīng)時(shí)間、CPU負(fù)載、內(nèi)存使用等如何決定系統(tǒng)的性能，

例如穩(wěn)定性和響應(yīng)等。負(fù)載測(cè)試通常描述一種特定類型的壓力測(cè)試，即增加用戶數(shù)量以對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。--壓力測(cè)試壓力測(cè)試通過(guò)確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來(lái)獲得系統(tǒng)能提供的最大的服務(wù)級(jí)別的測(cè)試。通俗地講，壓力測(cè)試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會(huì)變得不可接受。--負(fù)載壓力測(cè)試負(fù)載壓力測(cè)試是性能測(cè)試的重要組成部分，負(fù)載壓力測(cè)試包括：并發(fā)性能測(cè)試（重點(diǎn)）疲勞強(qiáng)度測(cè)試大數(shù)據(jù)量測(cè)試--并發(fā)性能測(cè)試

考察客戶端應(yīng)用的性能，測(cè)試的入口是客戶端并發(fā)性能測(cè)試的過(guò)程，是一個(gè)負(fù)載測(cè)試和壓力測(cè)試的過(guò)程。即逐漸增加并發(fā)虛擬用戶數(shù)負(fù)載，直到系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，通過(guò)綜合分析交易執(zhí)行指標(biāo)、資源監(jiān)控指標(biāo)等來(lái)確定系統(tǒng)并發(fā)性能的過(guò)程。并發(fā)性能測(cè)試是負(fù)載壓力測(cè)試中的重要內(nèi)容。--疲勞強(qiáng)度測(cè)試通常是采用系統(tǒng)穩(wěn)定運(yùn)行情況下能夠支持的最大并發(fā)用戶數(shù)或者日常運(yùn)行用戶數(shù)，持續(xù)執(zhí)行一段時(shí)間業(yè)務(wù)，通過(guò)綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來(lái)確定系統(tǒng)處理最大工作量強(qiáng)度性能的過(guò)程。--大數(shù)據(jù)量測(cè)試大數(shù)據(jù)量測(cè)試的兩種類型獨(dú)立的數(shù)據(jù)量測(cè)試針對(duì)某些系統(tǒng)存儲(chǔ)、傳輸、統(tǒng)計(jì)、查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量測(cè)試綜合數(shù)據(jù)量測(cè)試和壓力性能測(cè)試、負(fù)載性能測(cè)試、疲勞性能測(cè)試相結(jié)合的綜合測(cè)試方案--考察系統(tǒng)配置連接到系統(tǒng)的用戶數(shù)應(yīng)用程序客戶端計(jì)算機(jī)的配置情況（硬件、內(nèi)存、操作系統(tǒng)、軟件、開(kāi)發(fā)工具等）使用的數(shù)據(jù)庫(kù)和Web服務(wù)器的類型（硬件、數(shù)據(jù)庫(kù)類型、操作系統(tǒng)、文件服務(wù)器等）服務(wù)器與應(yīng)用程序客戶端之間的通信方式前端客戶端與后端服務(wù)器之間的中間件配置和應(yīng)用程序服務(wù)器可能影響響應(yīng)時(shí)間的其他網(wǎng)絡(luò)組件（調(diào)制解調(diào)器等）--分析使用模型考慮哪些用戶使用系統(tǒng)每種類型用戶的數(shù)量每個(gè)用戶的典型任務(wù)確定活動(dòng)峰值期的發(fā)生時(shí)間負(fù)載峰值期間的典型活動(dòng)--并發(fā)用戶估算結(jié)合某類軟件高峰期，范圍，做一個(gè)推論形的方案，比如30:1,前指在線用戶，后指并發(fā)用戶。用得頻繁，比率就變?yōu)槿?5:1最大200:1最小15:1--選擇測(cè)試工具的策略自動(dòng)負(fù)載測(cè)試開(kāi)放資源（OpenSource）測(cè)試自主開(kāi)發(fā)代碼測(cè)試--開(kāi)放資源（OpenSource）測(cè)試開(kāi)放系統(tǒng)測(cè)試體系－OpenSTA/）TestMaker（/）ApacheJMeter(/jmeter/)--性能測(cè)試成功標(biāo)志系統(tǒng)運(yùn)行正常重復(fù)三次，每次結(jié)果在誤差允許之內(nèi)。如目標(biāo)值的上下20%之內(nèi)。資源監(jiān)控指標(biāo)能夠獲取有效值。--WEB測(cè)試注意點(diǎn)***************************掌握用戶驗(yàn)收測(cè)試課程內(nèi)容--定義用戶驗(yàn)收測(cè)試是軟件開(kāi)發(fā)結(jié)束后，用戶對(duì)軟件產(chǎn)品投入實(shí)際應(yīng)用以前進(jìn)行的最后一次質(zhì)量檢驗(yàn)活動(dòng)。它要回答開(kāi)發(fā)的軟件產(chǎn)品是否符合預(yù)期的各項(xiàng)要求，以及用戶能否接受的問(wèn)題

。由于它不只是檢驗(yàn)軟件某個(gè)方面的質(zhì)量，而是要進(jìn)行全面的質(zhì)量檢驗(yàn)，并且要決定軟件是否合格，因此驗(yàn)收測(cè)試是一項(xiàng)嚴(yán)格的正式測(cè)試活動(dòng)。需要根據(jù)事先制訂的計(jì)劃，進(jìn)行軟

件配置評(píng)審、功能測(cè)試、性能測(cè)試等多方面檢測(cè)。--用戶驗(yàn)收測(cè)試的準(zhǔn)入條件在真正進(jìn)行用戶驗(yàn)收測(cè)試之前一般應(yīng)該已經(jīng)完成了以下工作（也可以根據(jù)實(shí)際情況有選擇地采用或增加）：

軟件開(kāi)發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。

驗(yàn)收測(cè)試計(jì)劃已經(jīng)過(guò)評(píng)審并批準(zhǔn)，并且置于文檔控制之下。

對(duì)軟件需求說(shuō)明書的審查已經(jīng)完成。

對(duì)概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)的審查已經(jīng)完成。

對(duì)所有關(guān)鍵模塊的代碼審查已經(jīng)完成。

對(duì)單元、集成、系統(tǒng)測(cè)試計(jì)劃和報(bào)告的審查已經(jīng)完成。

所有的測(cè)試腳本已完成，并至少執(zhí)行過(guò)一次，且通過(guò)評(píng)審。

使用配置管理工具且代碼置于配置控制之下。

軟件問(wèn)題處理流程已經(jīng)就緒。

已經(jīng)制定、評(píng)審并批準(zhǔn)驗(yàn)收測(cè)試完成標(biāo)準(zhǔn)。--用戶驗(yàn)收測(cè)試（UAT）的目的：從最終用戶的角度，驗(yàn)證軟件系統(tǒng)符合需求定義的各種功能和技術(shù)需求，驗(yàn)證各業(yè)務(wù)流程執(zhí)行情況，為用戶是否接受軟件系統(tǒng)提供決策依據(jù)。***************************了解測(cè)試自動(dòng)化，JUnit，TDDJunitJUnit是由ErichGamma和KentBeck編寫的一個(gè)回歸測(cè)試框架（regressiontestingframework）。Junit測(cè)試是程序員測(cè)試，即所謂白盒測(cè)試，因?yàn)槌绦騿T知道被測(cè)試的軟件如何（How）完成功能和完成什么樣（What）的功能。Junit是一套框架，繼承TestCase類，就可以用Junit進(jìn)行自動(dòng)測(cè)試了。JUnit是一個(gè)開(kāi)放源代碼的Java測(cè)試框架，用于編寫和運(yùn)行可重復(fù)的測(cè)試。他是用于單元測(cè)試框架體系xUnit的一個(gè)實(shí)例（用于java語(yǔ)言）。它包括以下特性：1、用于測(cè)試期望結(jié)果的斷言（Assertion）2、用于共享共同測(cè)試數(shù)據(jù)的測(cè)試工具3、用于方便的組織和運(yùn)行測(cè)試的測(cè)試套件4、圖形和文本的測(cè)試運(yùn)行器另外junit是在xp編程和重構(gòu)（refactor）中被極力推薦使用的工具，因?yàn)樵趯?shí)現(xiàn)自動(dòng)單元測(cè)試的情況下可以大大的提高開(kāi)發(fā)的效率，但是實(shí)際上編寫測(cè)試代碼也是需要耗費(fèi)很多的時(shí)間和精力的，那么使用這個(gè)東東好處到底在哪里呢？筆者認(rèn)為是這樣的：1、對(duì)于xp編程而言，要求在編寫代碼之前先寫測(cè)試，這樣可以強(qiáng)制你在寫代碼之前好好的思考代碼（方法）的功能和邏輯，否則編寫的代碼很不穩(wěn)定，那么你需要同時(shí)維護(hù)測(cè)試代碼和實(shí)際代碼，這個(gè)工作量就會(huì)大大增加。因此在xp編程中，基本過(guò)程是這樣的：構(gòu)思－》編寫測(cè)試代碼－》編寫代碼－》測(cè)試，而且編寫測(cè)試和編寫代碼都是增量式的，寫一點(diǎn)測(cè)一點(diǎn)，在編寫以后的代碼中如果發(fā)現(xiàn)問(wèn)題可以較塊的追蹤到問(wèn)題的原因，減小回歸錯(cuò)誤的糾錯(cuò)難度。2、對(duì)于重構(gòu)而言，其好處和xp編程中是類似的，因?yàn)橹貥?gòu)也是要求改一點(diǎn)測(cè)一點(diǎn)，減少回歸錯(cuò)誤造成的時(shí)間消耗。3、對(duì)于非以上兩種情況，我們?cè)陂_(kāi)發(fā)的時(shí)候使用junit寫一些適當(dāng)?shù)臏y(cè)試也是有必要的，因?yàn)橐话阄覀円彩切枰帉憸y(cè)試的代碼的，可能原來(lái)不是使用的junit，如果使用junit，而且針對(duì)接口（方法）編寫測(cè)試代碼會(huì)減少以后的維護(hù)工作，例如以后對(duì)方法內(nèi)部的修改（這個(gè)就是相當(dāng)于重構(gòu)的工作了）。另外就是因?yàn)閖unit有斷言功能，如果測(cè)試結(jié)果不通過(guò)會(huì)告訴我們那個(gè)測(cè)試不通過(guò)，為什么，而如果是想以前的一般做法是寫一些測(cè)試代碼看其輸出結(jié)果，然后再由自己來(lái)判斷結(jié)果使用正確，使用junit的好處就是這個(gè)結(jié)果是否正確的判斷是它來(lái)完成的，我們只需要看看它告訴我們結(jié)果是否正確就可以了，在一般情況下會(huì)大大提高效率。安裝JUnit安裝很簡(jiǎn)單，先到以下地址下載一個(gè)最新的zip包：/junit/下載完以后解壓縮到你喜歡的目錄下，假設(shè)是JUNIT_HOME，然后將JUNIT_HOME下的junit.jar包加到你的系統(tǒng)的CLASSPATH環(huán)境變量中，對(duì)于IDE環(huán)境，對(duì)于需要用到的junit的項(xiàng)目增加到lib中，其設(shè)置不同的IDE有不同的設(shè)置，這里不多講。如何使用JUnit寫測(cè)試？最簡(jiǎn)單的范例如下：1、創(chuàng)建一個(gè)TestCase的子類packagejunitfaq;importjava.util.*;importjunit.framework.*;publicclassSimpleTestextendsTestCase{publicSimpleTest(Stringname){super(name);}2、寫一個(gè)測(cè)試方法斷言期望的結(jié)果publicvoidtestEmptyCollection(){Collectioncollection=newArrayList();assertTrue(collection.isEmpty());}注意：JUnit推薦的做法是以test作為待測(cè)試的方法的開(kāi)頭，這樣這些方法可以被自動(dòng)找到并被測(cè)試。3、寫一個(gè)suite()方法，它會(huì)使用反射動(dòng)態(tài)的創(chuàng)建一個(gè)包含所有的testXxxx方法的測(cè)試套件publicstaticTestsuite(){returnnewTestSuite(SimpleTest.class);}4、寫一個(gè)main()方法以文本運(yùn)行器的方式方便的運(yùn)行測(cè)試publicstaticvoidmain(Stringargs[]){junit.textui.TestRunner.run(suite());}}5、運(yùn)行測(cè)試以文本方式運(yùn)行：javajunitfaq.SimpleTest通過(guò)的測(cè)試結(jié)果是：.Time:0OK(1tests)Time上的小點(diǎn)表示測(cè)試個(gè)數(shù)，如果測(cè)試通過(guò)則顯示OK。否則在小點(diǎn)的后邊標(biāo)上F，表示該測(cè)試失敗。每次的測(cè)試結(jié)果都應(yīng)該是OK的，這樣才能說(shuō)明測(cè)試是成功的，如果不成功就要馬上根據(jù)提示信息進(jìn)行修正了。如果JUnit報(bào)告了測(cè)試沒(méi)有成功，它會(huì)區(qū)分失?。╢ailures）和錯(cuò)誤（errors）。失敗是你的代碼中的assert方法失敗引起的；而錯(cuò)誤則是代碼異常引起的，例如ArrayIndexOutOfBoundsException。以圖形方式運(yùn)行：javajunit.swingui.TestRunnerjunitfaq.SimpleTest通過(guò)的測(cè)試結(jié)果在圖形界面的綠色條部分。以上是最簡(jiǎn)單的測(cè)試樣例，在實(shí)際的測(cè)試中我們測(cè)試某個(gè)類的功能是常常需要執(zhí)行一些共同的操作，完成以后需要銷毀所占用的資源（例如網(wǎng)絡(luò)連接、數(shù)據(jù)庫(kù)連接，關(guān)閉打開(kāi)的文件等），TestCase類給我們提供了setUp方法和tearDown方法，setUp方法的內(nèi)容在測(cè)試你編寫的TestCase子類的每個(gè)testXxxx方法之前都會(huì)運(yùn)行，而tearDown方法的內(nèi)容在每個(gè)testXxxx方法結(jié)束以后都會(huì)執(zhí)行。這個(gè)既共享了初始化代碼，又消除了各個(gè)測(cè)試代碼之間可能產(chǎn)生的相互影響。JUnit最佳實(shí)踐MartinFowler說(shuō)過(guò)：“當(dāng)你試圖打印輸出一些信息或調(diào)試一個(gè)表達(dá)式時(shí)，寫一些測(cè)試代碼來(lái)替代那些傳統(tǒng)的方法?！币婚_(kāi)始，你會(huì)發(fā)現(xiàn)你總是要?jiǎng)?chuàng)建一些新的Fixture，而且測(cè)試似乎使你的編程速度慢了下來(lái)。然而不久之后，你會(huì)發(fā)現(xiàn)你重復(fù)使用相同的Fixture，而且新的測(cè)試通常只涉及添加一個(gè)新的測(cè)試方法。你可能會(huì)寫許多測(cè)試代碼，但你很快就會(huì)發(fā)現(xiàn)你設(shè)想出的測(cè)試只有一小部分是真正有用的。你所需要的測(cè)試是那些會(huì)失敗的測(cè)試，即那些你認(rèn)為不會(huì)失敗的測(cè)試，或你認(rèn)為應(yīng)該失敗卻成功的測(cè)試。我們前面提到過(guò)測(cè)試是一個(gè)不會(huì)中斷的過(guò)程。一旦你有了一個(gè)測(cè)試，你就要一直確保其正常工作，以檢驗(yàn)?zāi)闼尤氲男碌墓ぷ鞔a。不要每隔幾天或最后才運(yùn)行測(cè)試，每天你都應(yīng)該運(yùn)行一下測(cè)試代碼。這種投資很小，但可以確保你得到可以信賴的工作代碼。你的返工率降低了，你會(huì)有更多的時(shí)間編寫工作代碼。不要認(rèn)為壓力大，就不寫測(cè)試代碼。相反編寫測(cè)試代碼會(huì)使你的壓力逐漸減輕，應(yīng)為通過(guò)編寫測(cè)試代碼，你對(duì)類的行為有了確切的認(rèn)識(shí)。你會(huì)更快地編寫出有效率地工作代碼。下面是一些具體的編寫測(cè)試代碼的技巧或較好的實(shí)踐方法：1.不要用TestCase的構(gòu)造函數(shù)初始化Fixture，而要用setUp()和tearDown()方法。2.不要依賴或假定測(cè)試運(yùn)行的順序，因?yàn)镴Unit利用Vector保存測(cè)試方法。所以不同的平臺(tái)會(huì)按不同的順序從Vector中取出測(cè)試方法。3.避免編寫有副作用的TestCase。例如：如果隨后的測(cè)試依賴于某些特定的交易數(shù)據(jù)，就不要提交交易數(shù)據(jù)。簡(jiǎn)單的會(huì)滾就可以了。4.當(dāng)繼承一個(gè)測(cè)試類時(shí)，記得調(diào)用父類的setUp()和tearDown()方法。5.將測(cè)試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）6.測(cè)試類和測(cè)試方法應(yīng)該有一致的命名方案。如在工作類名前加上test從而形成測(cè)試類名。7.確保測(cè)試與時(shí)間無(wú)關(guān)，不要依賴使用過(guò)期的數(shù)據(jù)進(jìn)行測(cè)試。導(dǎo)致在隨后的維護(hù)過(guò)程中很難重現(xiàn)測(cè)試。8.如果你編寫的軟件面向國(guó)際市場(chǎng)，編寫測(cè)試時(shí)要考慮國(guó)際化的因素。不要僅用母語(yǔ)的Locale進(jìn)行測(cè)試。9.盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡(jiǎn)潔。10.測(cè)試要盡可能地小，執(zhí)行速度快。JUnit和ant結(jié)合ant提供了兩個(gè)target：junit和junitreport運(yùn)行所有測(cè)試用例，并生成html格式的報(bào)表具體操作如下：1.將junit.jar放在ANT_HOMElib目錄下2.修改build.xml，加入如下內(nèi)容：Oneormoretestsfailed,checkthereportfordetail...運(yùn)行這個(gè)target，ant會(huì)運(yùn)行每個(gè)TestCase，在report目錄下就有了很多TEST*.xml和一些網(wǎng)頁(yè)打開(kāi)report目錄下的index.html就可以看到很直觀的測(cè)試運(yùn)行報(bào)告，一目了然。在Eclipse中開(kāi)發(fā)、運(yùn)行JUnit測(cè)試相當(dāng)簡(jiǎn)單。因?yàn)镋clipse本身集成了JUnit相關(guān)組件，并對(duì)JUnit的運(yùn)行提成了無(wú)縫的支持。TDD(Test-DrivenDevelopment)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)是敏捷開(kāi)發(fā)中的一項(xiàng)核心實(shí)踐和技術(shù)，也是一種設(shè)計(jì)方法論。TDD的原理是在開(kāi)發(fā)功能代碼之前，先編寫單元測(cè)試用例代碼，測(cè)試代碼確定需要編寫什么產(chǎn)品代碼。TDD雖是敏捷方法的核心實(shí)踐，但不只適用于XP（ExtremeProgramming），同樣可以適用于其他開(kāi)發(fā)方法和過(guò)程。TDD的基本思路就是通過(guò)測(cè)試來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行，但測(cè)試驅(qū)動(dòng)開(kāi)發(fā)并不只是單純的測(cè)試工作，而是把需求分析，設(shè)計(jì)，質(zhì)量控制量化的過(guò)程。TDD的重要目的不僅僅是測(cè)試軟件，測(cè)試工作保證代碼質(zhì)量?jī)H僅是其中一部分，而且是在開(kāi)發(fā)過(guò)程中幫助客戶和程序員去除模棱兩可的需求。TDD首先考慮使用需求（對(duì)象、功能、過(guò)程、接口等），主要是編寫測(cè)試用例框架對(duì)功能的過(guò)程和接口進(jìn)行設(shè)計(jì)，而測(cè)試框架可以持續(xù)進(jìn)行驗(yàn)證。優(yōu)點(diǎn)：在任意一個(gè)開(kāi)發(fā)節(jié)點(diǎn)都可以拿出一個(gè)可以使用，含少量bug并具一定功能的產(chǎn)品。缺點(diǎn)：增加代碼量。測(cè)試代碼是系統(tǒng)代碼的兩倍或更多。TDD=TFD+Refactoring(TFD--TestFirstDevelopment)計(jì)算機(jī)領(lǐng)域：TestDrivedDevelop測(cè)試驅(qū)動(dòng)開(kāi)發(fā)是一種開(kāi)發(fā)方法，是開(kāi)發(fā)人員參與的活動(dòng)。其效果是以可執(zhí)行的形式文檔化需求，迫使你分清職責(zé)隔離依賴以驅(qū)動(dòng)你的設(shè)計(jì)，編織安全網(wǎng)以便將Bug扼殺在在搖籃狀態(tài)，防止其逃逸。可傳統(tǒng)測(cè)試人員的活動(dòng)是試圖找到已經(jīng)逃逸的Bug。這兩種活動(dòng)都是必要的，而且毫不沖突，互為補(bǔ)充。那么測(cè)試人員在新的特性還沒(méi)開(kāi)發(fā)完成之前做什么呢?除了提前寫測(cè)試用例，無(wú)論是自動(dòng)化的還是非自動(dòng)化的，而需要測(cè)試人員參加的一項(xiàng)重要活動(dòng)，就是參與特性驗(yàn)收條件的制定。之前經(jīng)常發(fā)生開(kāi)發(fā)人員按照自己的理解去編碼，測(cè)試人員按照自己的理解去測(cè)試，直到開(kāi)發(fā)完成，測(cè)試過(guò)程中才發(fā)現(xiàn)理解的不一致，開(kāi)始產(chǎn)生爭(zhēng)執(zhí)并阻塞等待業(yè)務(wù)分析人員(如果幸運(yùn)的話)或者行政主管(如果開(kāi)發(fā)過(guò)程混亂的話)的仲裁。解決辦法就是，在開(kāi)始開(kāi)發(fā)新特性前的一剎那，由業(yè)務(wù)分析人員，測(cè)試人員，開(kāi)發(fā)人員進(jìn)行一次討論，就驗(yàn)收條件達(dá)成一致并形成記錄，然后測(cè)試人員和開(kāi)發(fā)人員分頭去寫測(cè)試和實(shí)現(xiàn)。***************************測(cè)試規(guī)范與細(xì)則培訓(xùn)軟件測(cè)試簡(jiǎn)介從軟件工程的角度出發(fā)，軟件生命周期過(guò)程包括需求分析，分析設(shè)計(jì)，代碼實(shí)現(xiàn)，測(cè)試，及應(yīng)用。然而僅測(cè)試階段就又一次完全體現(xiàn)了軟件生命周期的全過(guò)程，這里涉及測(cè)試需求的定制，各類測(cè)試計(jì)劃、測(cè)試過(guò)程的建立，測(cè)試的開(kāi)發(fā)，測(cè)試的執(zhí)行和測(cè)試結(jié)果的評(píng)估。綜合的說(shuō)軟件測(cè)試就是根據(jù)軟件開(kāi)發(fā)各階段的規(guī)則說(shuō)明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測(cè)試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測(cè)試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。目的：通過(guò)測(cè)試來(lái)發(fā)現(xiàn)軟件中的存在的各類錯(cuò)誤驗(yàn)證軟件是否滿足軟件設(shè)計(jì)和任務(wù)書所規(guī)定的技術(shù)和要求。為軟件可靠性和安全性評(píng)估提供依據(jù)有效定義和實(shí)現(xiàn)軟件成分由低層到高層的組裝過(guò)程現(xiàn)階段軟件質(zhì)量的主要手段原則：所有的測(cè)試都應(yīng)追溯到用戶需求；在測(cè)試工作真正開(kāi)始前的較長(zhǎng)時(shí)間就進(jìn)行測(cè)試計(jì)劃測(cè)試應(yīng)以“小規(guī)?！遍_(kāi)始逐步轉(zhuǎn)向“大規(guī)模”想要做到窮舉測(cè)試不可能測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)及與之對(duì)應(yīng)的預(yù)期輸出這兩個(gè)部分組成程序員避免檢查自己的程序在設(shè)計(jì)測(cè)試用例