測試總結(jié)

在進(jìn)行測試前，首先必須理解業(yè)務(wù)和需求。需求和業(yè)務(wù)理解了，才知道客戶想要系統(tǒng)實(shí)現(xiàn)什么。然后按照需求來進(jìn)行測試，不滿足需求要求的都可以認(rèn)為是BUG。雖然在實(shí)際工作中，拿到一份完整詳細(xì)的需求是很不容易的，但要做好一個(gè)功能測試，前提就是要對需求比較熟悉，各個(gè)業(yè)務(wù)細(xì)節(jié)都很了解，甚至做到比開發(fā)人員還要了解。除此之外，對于現(xiàn)在很多的信息處理相關(guān)的系統(tǒng)，還需要對整個(gè)業(yè)務(wù)中數(shù)據(jù)庫的操作比較清楚。比如哪個(gè)業(yè)務(wù)需要用到哪些表，做怎么樣的操作。了解了這個(gè)就可以不單單從程序前臺(tái)來看程序，看到數(shù)據(jù)庫的過程，更有利于你找到隱藏的BUG。這些是從前臺(tái)看不出來的，但實(shí)際可能會(huì)導(dǎo)致程序出現(xiàn)問題。

　　第二，了解程序的框架結(jié)構(gòu)。比如很多B/S結(jié)構(gòu)的系統(tǒng)中，前臺(tái)是如何和后臺(tái)通信的，之間是什么協(xié)議，什么格式，后臺(tái)是如何處理這些數(shù)據(jù)的。再比如C/S結(jié)構(gòu)的系統(tǒng)，服務(wù)器端和客戶端之間是如何通信的，中間的數(shù)據(jù)包是什么格式，哪些功能由服務(wù)器端實(shí)現(xiàn)，哪些功能由客戶端實(shí)現(xiàn)等等。了解這些有助于你更好的去測試程序以及定位程序錯(cuò)誤。

第三，和開發(fā)人員溝通。這里說的溝通并不僅僅指通過溝通試圖讓開發(fā)人員修改每個(gè)BUG，這個(gè)當(dāng)然需要溝通，但是并不是指所有的BUG都需要修改，這中間涉及到成本、技術(shù)，還有別的問題。除此之外，通過和開發(fā)人員搞好關(guān)系，對于BUG我們可以問他發(fā)生該BUG的原因，修改的大致方法，甚至不修改的原因等等，這有助于以后測試中多注意、多發(fā)現(xiàn)這樣的問題，甚至提出修改建議。

第四，決定BUG嚴(yán)重性的時(shí)候，可以根據(jù)該被測對象在整個(gè)系統(tǒng)中充當(dāng)?shù)慕巧瑢?shí)現(xiàn)的功能來判定如果該對象出現(xiàn)錯(cuò)誤會(huì)對整個(gè)系統(tǒng)產(chǎn)生什么樣的影響，對產(chǎn)生的影響打分，從而定義BUG的嚴(yán)重程度；決定BUG優(yōu)先級(jí)的時(shí)候，可以先假設(shè)不修復(fù)該BUG，出現(xiàn)的這些問題會(huì)產(chǎn)生哪些影響，然后判定這些影響的嚴(yán)重性來判定BUG的優(yōu)先性。

第五，容易產(chǎn)生BUG的情況：雖然在開發(fā)過程中，軟件需求通常都會(huì)發(fā)生改動(dòng)，所以如果某一部分的軟件需求頻繁發(fā)生變動(dòng)，那么就會(huì)導(dǎo)致和這部分相關(guān)的編碼和設(shè)計(jì)會(huì)相應(yīng)的頻繁變動(dòng)，那么在測試中，這部分編碼設(shè)計(jì)實(shí)現(xiàn)的部分出現(xiàn)BUG的可能性就很大。

        如果根據(jù)測試需求設(shè)計(jì)的某個(gè)測試用例描述的業(yè)務(wù)非常復(fù)雜，并且和其他的業(yè)務(wù)之間也有非常復(fù)雜的關(guān)系，那么可以判定設(shè)計(jì)和編碼實(shí)現(xiàn)也會(huì)非常復(fù)雜，那么該部分出現(xiàn)BUG的可能性也非常大

          如果在開發(fā)的過程中，大量使用了第三方的組件，或者從別的軟件中移植了大量的代碼，那么和這些第三方的組件和代碼相關(guān)部分出現(xiàn)BUG的可能性就很大，尤其是這些第三方組件使用者很少而且沒有通過嚴(yán)格的認(rèn)證的情況下。

     第六，如何根據(jù)頻頻變更的軟件需求確定測試需求：測試內(nèi)部肯定有個(gè)需求管理的負(fù)責(zé)人，對于當(dāng)前產(chǎn)品的需求動(dòng)向有很明確的掌控，那么他的責(zé)任不僅僅是在負(fù)責(zé)需求這塊了，他必須去獲取最新的需求，明確開發(fā)對這些變更需求的操作，同時(shí)將這些變更的信息告之相關(guān)的測試人員，明確測試任務(wù)；當(dāng)然需求的變更也不僅僅是需求人員的責(zé)任，作為項(xiàng)目的測試人員，在確認(rèn)新版本中包含的需求后，然后和上次的測試版本進(jìn)行比較，哪些內(nèi)熱哦那個(gè)是新增的，哪些內(nèi)容是被調(diào)整過的，哪些內(nèi)容是在新版本中取消的等等，然后在根據(jù)獲取的這些信息，確認(rèn)測試需求，在進(jìn)行測試過程中，對這些新增的模塊和關(guān)聯(lián)性的模塊進(jìn)行測試。

第七，需求變更/測試缺陷的跟蹤，這兩個(gè)項(xiàng)任務(wù)的跟蹤是很重要的；需求變更不及時(shí)跟蹤會(huì)導(dǎo)致這個(gè)測試計(jì)劃的延后，會(huì)延伸出很多需求不明確的問題，同樣由于需求不明確出現(xiàn)的BUG變相的會(huì)導(dǎo)致開發(fā)和測試之間出現(xiàn)矛盾；測試缺陷的跟蹤，可以間接提高測試的進(jìn)度，也可以提醒開發(fā)對缺陷進(jìn)行修改。

第八，描述BUG主題時(shí)，應(yīng)當(dāng)根據(jù)實(shí)際情況，簡要的描述出自己的操作和希望被重視的現(xiàn)象，不應(yīng)該包含自己對異常表現(xiàn)出現(xiàn)的原因的推測和猜想。BUG的描述要簡潔易懂，作為測試人員，也要盡可能的分析出造成此缺陷的原因，尤其是在業(yè)務(wù)流程上出現(xiàn)的BUG，不能只簡單描述整個(gè)流程操作下來后出現(xiàn)某個(gè)BUG，應(yīng)該具體把在這個(gè)流程上導(dǎo)致這個(gè)BUG出現(xiàn)的點(diǎn)分析出來。出現(xiàn)缺陷的時(shí)候，應(yīng)該能夠通過自身對系統(tǒng)的了解，判斷出造成這種情況的可能性原因，之后進(jìn)行判定；

第九，不能假設(shè)開發(fā)人員對他們開發(fā)的程序和業(yè)務(wù)需求都十分熟悉，在提交BUG的時(shí)候，一定要說明白是哪個(gè)模塊的哪個(gè)功能，出現(xiàn)了哪種類型的錯(cuò)誤，并且，如果需要，應(yīng)該把這部分相應(yīng)的需求都描述出來。

第十，對基礎(chǔ)操作進(jìn)行測試【增刪改】，不僅僅測試他的基本功能，還要根據(jù)系統(tǒng)本上的業(yè)務(wù)狀況來判定功能點(diǎn)是否實(shí)現(xiàn)正常。相關(guān)的模塊，相關(guān)的頁面，隨著增刪改的相應(yīng)操作，相關(guān)頁面會(huì)不會(huì)及時(shí)更新；實(shí)際測試過程中很多次遇到這樣的情況，比如，當(dāng)前頁面刪除功能是實(shí)現(xiàn)了，但是相關(guān)頁面信息還是存在，沒有及時(shí)刪除；所有基本的功能測試要和業(yè)務(wù)需求點(diǎn)結(jié)合起來一起進(jìn)行測試，不然會(huì)遺留很多問題，測試會(huì)不全面。