提高測試效率的方法

1、精選優(yōu)質(zhì)文檔-傾情為你奉上1. 存儲過程和數(shù)據(jù)訂正腳本如何測試？2.軟件測試的目的到底是發(fā)現(xiàn)軟件的錯誤還是檢驗軟件是否符合用戶規(guī)定的需求或是弄清預(yù)期結(jié)果和實際結(jié)果之間的差距?3.如何設(shè)計或者挑選有效的回歸測試用例？隨著系統(tǒng)的逐步成熟，每個版本包含的新特性越來越少，但是新功能對原系統(tǒng)的影響有多大是我們在測試時需要重點考慮的問題。此時，就勢必要進行回歸測試。而 且系統(tǒng)越成熟，回歸測試的比重也會越大。這將會對測試工作帶來不小的挑戰(zhàn)。在實際工作中，經(jīng)常是一方面求全，希望覆蓋面盡量廣，避免漏測。另一方面求產(chǎn) 出，大量的回歸測試用例，可能只發(fā)現(xiàn)很少的問題，投入與產(chǎn)出不太匹配，會影響測試人員的士氣，甚至測試

2、管理者也會對這種投入產(chǎn)出有所質(zhì)疑。并且，設(shè)計大量 的自動化測試腳本，會占用大量的時間。4. 如果在測試過程中遭遇到需求變更，怎么做，才能最好完成對變更后的軟件測試任務(wù)？1）一般公司的解決方法是改變一下原有的流程，測試計劃的工作可以跳出細節(jié),只描述框架。然后十分細的測試用例等待開發(fā)過程中在同步編寫。關(guān)于這種風險,真正要治理,需求階段，大公司就要多評審,小公司就要勤開會確定和交流需求了。需求變更申請確定后，一定要把它記錄下來，歸在需求變更文檔中，以備日后追查。2）限定開發(fā)人員提交測試版本的周期。不要一有修改，就提交給測試一個新版本，使測試人員做過多的重復(fù)工作。3）按照公司制定好的制度來按部就班的規(guī)

3、范項目，項目經(jīng)理的管理風格（如項目組召開例會，各方人員充分參與需求溝通會議，需求變更后更新的文檔及時發(fā)送），測試人員主動性4） 在設(shè)計自動測試劇本時，試圖使其有一些靈活性。在對應(yīng)用軟件進行自動測試時，要把注意力集中在看來不大會改變的部分。對變更進行適當?shù)娘L險分析，以減少回歸測試的要求。5）對于測試人員來說，最為重要的一點其實就是心理的適度調(diào)整。需求的變更導(dǎo)致自己的很多工作都成了無用功，很多東西要從頭做起。但是一定不要抱怨，因為那樣解決不了問題，事實就是事實。已經(jīng)無法更改。要有積極地心態(tài)，全新的去面對新的需求。分析，設(shè)計，一切重來。5.如何根據(jù)不同的項目制定不同的測試流程？6. 如何發(fā)現(xiàn)客戶端軟

4、件中的內(nèi)存泄露？C/S模式下的軟件的話,使用一些專業(yè)的內(nèi)存檢測工具, purify、boundchecker都可以B/S模式下的軟件,可以使用LR,在LR運行的時候,查看操作系統(tǒng)性能計數(shù)器中的Private Bytes(Windows)和Resident size(KB)(UNIX/Linux).要測試客戶端是否存在內(nèi)存泄露,其實原理都一樣.我們要換位思考,把服務(wù)端當成客戶端來發(fā)送請求,客戶端做為服務(wù)端來接受請求.我們要多做一個工作就是除了要監(jiān)控服務(wù)器端還要監(jiān)控客戶端的計數(shù)器信息.以下是簡單的步驟:step1:場景設(shè)計step2:腳本錄制和完善step3:計數(shù)器的選擇(特別是客戶端計數(shù)器選擇:

5、在windows自帶的性能監(jiān)控器里一般選擇監(jiān)控某個process 的private byte & virtual byte2個計數(shù)器)step4:運行場景step5:監(jiān)控測試最后關(guān)于場景的運行時間,在適當?shù)膲毫ο?我們一般選擇運行72小時.從之前的測試經(jīng)驗來看,我們發(fā)現(xiàn)內(nèi)存泄露一般都發(fā)生在場景運行的前10個小時之內(nèi).有的甚至在一個小時之內(nèi)就發(fā)生了內(nèi)存泄露.客戶端內(nèi)存泄漏，公司一個用VC+開發(fā)的產(chǎn)品遇到過此類問題。1.BoundsChecker；2.調(diào)試工具包Debugging Tools for Windows (x86)下的 windbg.exe和Gflags.exe；3.Pageh

6、eap.exe；4.Windows自帶的性能監(jiān)控器perfmon；5.C+ Test；6.Rational PurifyPlus；以上這些工具更多是調(diào)試用的，需要源代碼，對開發(fā)人員可能用處更大些7.和開發(fā)人員溝通，獲得最有可能發(fā)生內(nèi)存泄漏的模塊或功能點，再執(zhí)行測試；8.分析系統(tǒng)特性，制定計劃。如果是用C語言編寫的話，在開發(fā)的時候需要代碼走讀或者用purify來檢查1、用malloc或new申請內(nèi)存之后，應(yīng)該立即檢查指針值是否為NULL。防治使用指針值為NULL的內(nèi)存。2、動態(tài)內(nèi)存的申請與釋放必須配對，以防止內(nèi)存泄漏。3、用free和delete釋放了內(nèi)存之后，立即將指針設(shè)置為NULL,防止產(chǎn)生

7、“野指針”。4、不要忘記為數(shù)組和動態(tài)內(nèi)存賦值。5、避免數(shù)組或指針的下標越界，特別要當心發(fā)生“多1”或者“少1”的操作7. 如何衡量測試效率？1）發(fā)現(xiàn)缺陷的質(zhì)量； 2）測試的有效性； 3）測試組員交叉測試，發(fā)現(xiàn)漏測問題數(shù)量；4）遺漏到客戶缺陷的比例； 5）遞交的缺陷數(shù)量； 6）執(zhí)行用例的數(shù)量；7）編寫測試文檔的速度和質(zhì)量； 8）評審發(fā)現(xiàn)問題的效率； 9）測試工具使用的熟練程度； 10）測試結(jié)果的分析水平；8. 如何提高測試效率1）首先要有一個合理的詳細的測試計劃，測試任務(wù)盡量能細化到測試的功能和測試的case這個級別去監(jiān)控進度；2）測試盡早介入項目詳細了解項目的業(yè)務(wù)需求，做好測試的前期準備、了解

8、產(chǎn)品屬性和準備測試數(shù)據(jù)；3）對測試項目前景充滿信心，調(diào)整最佳心態(tài)，保持愉悅的工作心情；4）提高測試接受的標準，減少測試版本送測次數(shù)，一旦發(fā)現(xiàn)有重大問題，立即拒絕測試，送回開發(fā)人員修改?？梢詼p少很多次反復(fù)測試，重復(fù)測試；5）測試負責人認真做好測試文檔的評審，盡量使用較少的測試用例，發(fā)現(xiàn)較多的Bug；6）加強項目組成員的相互溝通工作和項目信息收集工作，測試工作是一項溝通要求比較高的工作，一般需要同項目經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)人員、業(yè)務(wù)人員、客戶溝通；7）積極配合開發(fā)人員工作，努力贏得開發(fā)人員的尊重和支持，首先需要正視自己、改進自己，通過自身的不斷努力讓開發(fā)人員，真正體會到測試的價值；8）按照項目的大小

9、不同，必要的情況下引入自動化測試工具；9）測試部門內(nèi)部成員的工作業(yè)績數(shù)據(jù)化，每天給每個人分配的任務(wù)非常具體，并且隨時關(guān)注他們的進展情況，完成百分比，不斷督促他們。并且，把每個人每天的工作成果（發(fā)現(xiàn)缺陷的數(shù)量和工作的質(zhì)量） 數(shù)據(jù)化，通過郵件的形式發(fā)給組內(nèi)的成員，讓大家有個比較。大家都有自尊心，看到自己落后，后面就加油趕工，形成一種良好的測試氛圍；10）提高測試人員的專業(yè)技能和工作能力，不斷的給自己充電，補充測試理論知識，讓自己工作技術(shù)能力去彌補專業(yè)技能的不足9.如何做好系統(tǒng)測試?10. 如何使自動化測試與手工測試達到最優(yōu)的結(jié)合？11. 沒有需求文檔的時候如何來設(shè)計測試用例？沒有需求文檔，最頭疼的

10、問題就是不知道開發(fā)的產(chǎn)品應(yīng)該是個什么樣，要完成哪些功能，達到什么指標。在條件允許的情況下，可以通過與各方面的溝通，得到盡可能多的信息，總之一句話，有什么要什么，過程中我們要盡量避免想當然的思維方式。然后廣納建議結(jié)合QA對產(chǎn)品熟悉的基礎(chǔ)上來確定一個比較粗的框架需求。在需求沒有得到進一步確認之前，千萬記住此時QA的主要工作應(yīng)該只是寫框架，而不是寫具體到哪個button放在哪個位置。辦法一：由開發(fā)部門補充文檔，可以不要求太正規(guī)，只要讓測試員想得清楚：什么輸入應(yīng)該產(chǎn)生什么輸出就OK了。查找其他相關(guān)文檔。比如產(chǎn)品策劃書、Feature List。辦法二：盡量多參加該項目組內(nèi)的會議。比如需求討論、設(shè)計討論

11、、計劃討論等會議，在對產(chǎn)品有了初步了解后，才有針對性的去咨詢相關(guān)人員。辦法三：由開發(fā)部門做基本功能測試，測試部門補充用例；由于已有基本用例，測試員根據(jù)現(xiàn)有用例就可以判斷程序功能?；蛘咴诔绦騿T編碼時，邊開發(fā)邊測試代碼的基本功能，測試部門只是補充用例；與前者的區(qū)別是：前者是事后測試，后者是測試驅(qū)動開發(fā)。辦法四： 如果當前開發(fā)的產(chǎn)品是以前做過產(chǎn)品的升級版，或者和以前某個項目類似，這樣就有個“demo”給你用，理解也更深入。辦法五：召集相關(guān)人員，對你整理的結(jié)果進行討論。將測試需求點總結(jié)成文檔，發(fā)給相關(guān)人員，包括項目負責人、市場部代表、開發(fā)人員等，讓他們幫助評審check，根據(jù)意見對文檔不斷進行補充完善

12、。當最后通過評審后，文檔就可當作依據(jù)來設(shè)計你的測試用例了。12. 我覺得測試人員應(yīng)做好以下幾點：  1、掌握測試理論知識如測試概念、流程、目的、原則、策略、方法等等；  2、掌握html，了解css；  3、掌握c/c#/java語言的編程基礎(chǔ)知識；  4、掌握測試文檔如測試計劃、用例、報告、使用手冊等的編寫；  5、掌握至少一個自動化測試工具及bug管理工具的使用；  6、掌握SQL Server/Oracle/Sybase數(shù)據(jù)庫系統(tǒng)的使用；  7、掌握

13、設(shè)計測試用例最常用的幾種方法；  8、掌握與專業(yè)相關(guān)的英文術(shù)語，當然越多越好；  9、多上網(wǎng)或到圖書館查資料課外補充學習。13. 如何對測試過程進行可見的有效的管理？14. 如何對Bug進行清晰的描述？需要進行哪些方面的描述，即需要哪些關(guān)鍵的字段？15. 在網(wǎng)站測試中如何做好安全性測試？問題的題目： 在網(wǎng)站測試中如何做好安全性測試？該從哪些方面入手？問題的描述：隨著網(wǎng)絡(luò)發(fā)展的趨勢，對于網(wǎng)站的安全性的要求也越來越高，很多網(wǎng)站都存在被黑客攻擊的漏洞，你在網(wǎng)站測試中有做到安全性測試嗎？你覺得安全測試應(yīng)該從哪些方面來檢查？16. B/S和C/S的架構(gòu)測試有哪些測

14、試點？兩者的區(qū)別有什么？在測試B/S架構(gòu)和C/S架構(gòu)的時候，有一些可以歸納的通用的測試點，比如UI測試，功能測試，異常情況下測試，不同ie，操作系統(tǒng)下測試，文檔測試，安 全測試等等，我想請同仁們總結(jié)一下一個比較全面的測試點list，也可以稍微再細化些，這樣大家在設(shè)計測試用例的時候，就可以在這個list上在不同的應(yīng) 用上再做細分，避免一些遺漏，同時提高工作效率，另外測試B/S架構(gòu)和C/S架構(gòu)還是有一些區(qū)別和差異，比如C/S就要考慮安裝測試，17. 要清晰描述bug我覺得應(yīng)寫明以下4點：1）bug發(fā)生的地方即在系統(tǒng)的哪個模塊；2）bug的優(yōu)先/嚴重性級別；3）bug產(chǎn)生的前提及后果，包括環(huán)境條件、

15、操作步驟、非常影響等等；4）是否可重現(xiàn)另外再加上bug截圖就會更讓人一目了然了！18. 如何在有限的時間內(nèi)編寫完整有效的測試用例？19. 性能測試和壓力測試的要點和常用方法？20. 請問常用的缺陷統(tǒng)計分析的常用方法有那些？每個方法的作用?21. 如何編寫有效的測試報告？測試報告是QA進行監(jiān)督的重要依據(jù)，為項目負責人提供軟件質(zhì)量信息的報告。22. 如何在QC的管理下實現(xiàn)自動化測試腳本之間的參數(shù)傳遞在QC管理工具中，有一項功能叫做Test Lab（測試實驗室），通過該實驗室，我們可以將一個業(yè)務(wù)流程中存在的多個基本功能的測試腳本組合起來，對整個業(yè)務(wù)流程的實現(xiàn)進行檢測。而在測試過程中， 有可能會在測試

16、腳本之間實現(xiàn)參數(shù)的傳遞。例如：A腳本申請了一個基本客戶采購服務(wù)，系統(tǒng)內(nèi)部根據(jù)已有規(guī)則產(chǎn)生相應(yīng)的一個采購服務(wù)單據(jù)編號。而在B腳本中， 將會調(diào)用該編號對采購服務(wù)單進行查詢和其他操作。該編號能否利用QC測試管理工具在A、B兩個腳本之間傳遞，如何進行？23. 常用軟件缺陷預(yù)防技術(shù)和缺陷分析技術(shù)有哪些？24. 如何衡量測試效率？一是利用客觀數(shù)據(jù)，比如每天跑多少case，每天報多少bug，編寫case的速度數(shù)量及質(zhì)量.這些都體現(xiàn)一個測試人員的素質(zhì)，基本上測試經(jīng)理都通過這些基本方法觀察團隊成員的工作。有了數(shù)據(jù)就有了比較，你跑得case比人家快，報得bug比人家多，確實能令人感到些許自豪感。 但是就像樓上幾位

17、說的確實有漏洞導(dǎo)致衡量方法不是很全面很合理，不過目前這還是評估一個測試人員效率的主要手段。第二就是加入主觀評判。我們經(jīng)理就經(jīng)常說要多報bug而且要報好bug.好bug意味著什么？首先是bug report的質(zhì)量，bug的信息描述得很準確，很簡潔很清楚，有時甚至要求測試人員很準確的找到導(dǎo)致bug的根本原因，要求你對項目很深的理解。有時項目進度很緊張，所以在這種時間敏感的條件下更要求要寫great bug report。另外有時需要你很快的了解項目，很快的閱讀test plan，test spec，并能夠很快地寫出test case盡可能多地覆蓋spec嗯簡而言之就是學習、領(lǐng)悟及創(chuàng)新創(chuàng)造的能力。

18、關(guān)于提高效率.管理好測試數(shù)據(jù)，可能你會參與到多個項目中，每個項目又有區(qū)別，甚至每次測試都有區(qū)別，一大堆的測試準備數(shù)據(jù)，測試文檔，甚至與測試相關(guān)的其他信息，比如郵件，聊天記錄等等。這就要求你將日常工作中的分類、記錄以及有效的存放管理，以便用時很快的找到。團隊協(xié)作，有時你苦想三天的問題其實早就有人知道怎么解決了結(jié)果你沒提出來，白白浪費時間。 還有就是也不能什么問題都拿來問，容易讓人覺得很傻很天真，而且有時也會打斷別人的思路，影響別人的效率，所以還是自己先找找答案吧先。有一公司老總跟我 說他們公司新來一女員工，什么都問，什么都得教，最后教完了還是什么都不會，有一次吃飯的時候甚至還問他是用勺還是用筷子吃. 有時要求你對t