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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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