【正文】 右鍵單擊的操作）、托盤區(qū)、任務管理器操作一般客戶端軟件，開著窗口在桌面上移動的時候，cpu占用都比較高，這個性能需要控制在某個合適的范圍內。鑒于縮略圖的影響以及為了圖紙的安全，我們建議服務器上的文件不能加密，明文保存，這就需要對PDM系統(tǒng)的訪問進行限制，比如不裝加密客戶端的不能訪問PDM系統(tǒng)。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。80%的缺陷出現(xiàn)在20%的代碼中。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。黑盒測試：又被稱為功能測試、數(shù)據(jù)驅動測試或基于規(guī)格說明的測試，是通過使用整個軟件或某種軟件功能來嚴格地測試, 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件的源代碼程序具體是怎樣設計的。⑧ bug 附件中能給出相關的日志和截圖。測試用例設計方法：（1）逐級細分法（2）輸入域測試法（3）輸出域分析法（4）正交試驗設計法（5）業(yè)務流程分析法（6）狀態(tài)遷移法（7）因果圖法（8）判定表法（9）錯誤猜測法(10)等價類劃分法（11）邊界值分析法}。主要著眼于程序外部的用戶界面，關注軟件的輸入和輸出，關注用戶的需求，從用戶的角度來驗證軟件的功能。黑盒測試也稱之為功能測試和數(shù)據(jù)驅動測試。：① 和 bug 產生對應的軟件版本。：配置測試環(huán)境是測試實施的一個重要階段，測試環(huán)境適合與否會嚴重影響測試結果的重要性和真實性。測試人員通過輸入他們的數(shù)據(jù)然后看輸出的結果從而了解軟件怎樣工作。因果圖法即因果分析圖，又叫特性要因圖、石川圖或魚翅圖，它是由日本東京大學教授石川馨提出的一種通過帶箭頭的線，將質量問題與原因之間的關系表示出來，是分析影響產品質量的諸因素之間關系的一種工具。也即80%的bug多發(fā)生在軟件的20%的模塊。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。因果圖法是一種適合于描述對于多種輸入條件組合的測試方法，根據(jù)輸入條件的組合、約束關系和輸出條件的因果關系，分析輸入條件的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件涉及的各種組合情況。山麗防水墻目前還不能實現(xiàn)該功能，億賽通廠家說有專用網關設備來實現(xiàn)認證訪問，準備下周帶來進行測試，IPGuard目前就能實現(xiàn)不裝客戶端不能訪問PDM服務器的功能。需要考慮窗口的模態(tài)性問題，比如有模態(tài)窗口的時候，進行其他的操作，以及模態(tài)窗口的重繪等。1對任務欄的考慮，要考慮任務欄在下方以及在屏幕上下左右側的情況 兼容性在中英文系統(tǒng)上使用的區(qū)別，在控制面板的區(qū)域和語言選項里面進行設置，管理選項卡里更改系統(tǒng)區(qū)域設置。瑞星、卡巴、360等殺毒軟件對一些文件類型、端口等有監(jiān)控，需要考慮。另外，發(fā)現(xiàn)附件可以直接拖動到正文區(qū)進行顯示的（新發(fā)現(xiàn)的功能，應該是編輯區(qū)的控件本身就支持吧，呵呵，驚訝了一把，居然還有這個功能，似乎很方便）。（例如，點擊某個鏈接，文字顏色是 否變化，點擊某個按鈕，按鈕顏色或者屬性是否變化等）使用軟件的過程中，多關注cpu、內存、句柄占用等方面的情況。寧可多花時間少寫內容，少報bug，也不要報上去的bug，給別人看的總結出現(xiàn)過多紕漏，沒有發(fā)現(xiàn)的bug可能是工作失誤，但是發(fā)現(xiàn)了，但是卻有不描述好，或者自己描述的不確定后事后自己都解釋不清楚的話，那就更糟糕了，更上級看的總結也是如此，及時發(fā)現(xiàn)的bug再多，總結卻是評價你這次測試的一個方面，如果總結寫的很差，必然給領導留下很差的印象，或者總是在受到領導的批評。1可用性用戶體驗跟網絡有關系的，對網絡錯誤的提示，有的需要及時，有的不需要頻繁提示網絡錯誤，應該多提供幾次重連，比如三次，如果重連三次都發(fā)現(xiàn)網絡錯誤連接失敗，就提示用戶，否則太頻繁會有騷擾和降低用戶對產品的信賴給用戶提供的操作，用戶可以用，也可以選擇不用，所以界面上需要提供取消類的入口，否則強制性的使用體驗上不是很好，比如提供上一步類的入口也類似。我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。當然如果這些模塊如果問題較多，不應該進行演示。“缺陷一個連著一個”不是一個客觀規(guī)律，只是一個常見的現(xiàn)象。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：質量要求不同。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：根據(jù)內部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發(fā)中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；報告上面的內容盡量要真實可靠；整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。1957–1978－證明為主 當時計算機應用的數(shù)量，成本和復雜性都大幅度提升，隨之而來的經濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。③對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。不同階段的開發(fā)人員相互理解不一致。項目管理的問題：缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。單元測試按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。根據(jù)集成測試計劃，一邊將模塊或其他軟件單位組合成系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。開發(fā)周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；周期短，還給各類開發(fā)人員造成太大的壓力，引起一些人為的錯誤。項目組成員技術水平參差不齊技術問題。⑤沒有考慮系統(tǒng)崩潰后的自我恢復或數(shù)據(jù)的異地備份、災難性恢復等問題，從而存在系統(tǒng)安全性、可靠性的隱患。1983–1987－評估為主 人們提出了在軟件生命周期中使用分析，評審，測試來評估產品的理論。二、論述2*12’，并列舉歷史上2~3個著名軟件測試（缺陷）案例，說明測試重要性軟件測試的目的,第一是確認軟件的質量，其一方面是確認軟件做了你所期望做的事情（，另一方面是確認軟件以正確的方式來做了這個事情。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求