qc缺陷腳本

A. 請分別用一兩句話概括一下QC，QTP，LoadRunner這三個軟體的功能和作用

QTP:自動化測試工具 - 通過VBS腳本自動實現對網頁或客戶端的操作。
LoadRunner:性能測試工具 - 通過對網頁進行測試得到網頁伺服器的性能（例如同時在線人數）。
QC:缺陷管理工具 - 提交BUG到此工具，對BUG及項目還有QTP,Loadrunner的腳本進行管理。
三者可以聯調，都是MERCURY公司開發的產品，現被HP收購。

B. 關於TD、QTP、LoadRunner

這三個東東都是Mecruy公司開發的，現在被HP收購了
名字也改了，叫做quality center = QC
是使用C語言開發的。三個同出一門，腳本支持的語言有：java、c、Visual Basic、vbscript
默認的腳本生成語言為 C。
各種腳本語言的自動選擇：
1、對於 FTP、COM/DCOM 和郵件協議（IMAP、POP3 和 SMTP），VuGen 還可以使用 Visual Basic、VB Script 和Javascript 來生成腳本。
2、C 語言 - 用於那些使用復雜的 COM 構造和 C++ 對象的錄制應用程序，Web/http協議的腳本也默認使用C語言，並且不可更改。
3、Visual Basic - 用於基於 VB 的應用程序。
4、vb Script - 用於基於 VBscript 的應用程序，例如 ASP。
5、Java Scripting - 用於基於 Javascript 的應用程序，例如 js 文件和動態 HTML 應用程序。
更改腳本語言：
Tools---Recording Options 菜單選項，選擇General--Script選項，就可以看見可選的語言。

C. QC的腳本編輯器裡面以下代碼是什麼意思

On Error Resume Next意思是說當代碼發生錯誤時跳過這一行代碼並不彈出錯誤提示。

On Error GoTo 0 的意思是，發生錯誤時當做沒發生過。（不彈出提示且不做處理）

Project_DefaultRes這一句……我也看不懂。

我就知道這些了

D. 軟體缺陷的有效管理

本文首發於【 林子的空間 】

「這次發布之前怎麼這么多的缺陷，是不是需要分析一下啊？」 

答案是肯定的，可是這個時候才想起要分析已經有點晚了，有可能這些缺陷很難分析了。這是發生過的一個真實場景，所記錄的缺陷包含信息很有限，很難有效的做好分析！本文就來聊聊如何有效的管理和分析缺陷。

缺陷是一項非常有價值的資產，軟體缺陷的管理分為兩個部分：缺陷信息收集和缺陷分析。

無效的缺陷記錄

信息繁冗

有的項目團隊要求詳細記錄缺陷的多個維度信息，而且大部分都是必填欄位，比如詳細的重現步驟，對於有些特別簡單的缺陷來講是沒必要的，關鍵是信息能夠說明缺陷即可，過分詳細的要求會帶來更大的浪費。

曾經有個項目是在QC(Quality Center)里記錄缺陷，需要填寫很多必填屬性欄位，沒有辦法靈活根據具體缺陷調整，加上QC伺服器在國外，訪問速度非常的慢，每次記錄缺陷成為了大家極其痛苦的一件事情。

信息缺失

也有的項目對缺陷的格式和屬性沒有嚴格要求，記錄的時候很簡單也很自由，這樣記錄的缺陷由於很多必要信息的缺失，對後續的跟蹤和分析也是極為不利。

比如前面提到的在QC里記錄缺陷的那個項目，由於太痛了，很多時候，QA發現了缺陷也不願意往QC里填，而是直接寫個紙條簡單記錄下，驗證完了它的生命周期就結束了，這樣後面就沒辦法去很好的跟蹤和分析了。（題外話：當時採用腳本往QC里記錄缺陷，稍微減輕了點痛苦。）

無效信息

還有一種情況就是記錄缺陷時同樣有一些屬性要求填寫，但是這些屬性值可能不是那麼有意義，導致存儲的信息不僅沒用，反而添加混亂，也是不利於跟蹤和分析的。

比如，其中的「根因（root cause）」屬性的值如下表所示，這些值根本就不是根因，這是一個沒有意義的搗亂屬性。

缺陷信息收集的正確做法

缺陷信息收集應該做到盡量簡單，且包含必要的信息。

- 標題：言簡意賅，總結性的語句描述是什麼缺陷

- 詳情：包括重現步驟、實際行為、期望結果等，根據具體情況確定其詳細程度，必要時可以添加截圖、日誌信息等附加說明。

- 重要屬性：優先順序、嚴重性、所屬功能模塊/產品、平台（OS、Web瀏覽器、移動設備的不同型號等）、環境、根因等，這些屬性對應的值需要根據不同項目的情況自己定義，其中「根因」是相當關鍵的一個屬性，後面有示例可以參考該屬性對應的值有哪些。

- 其他：每個項目對應的還會有其他信息需要記錄的，自行定義就好。

缺陷報告時機

在敏捷開發環境中，測試人員可能隨時在測試、隨時都會發現缺陷，包括還在開發手裡沒有完成的功能。什麼時候發現的缺陷需要記錄呢？通常情況下，有以下幾種情況：

- 開發還沒完成的用戶故事（story），測試人員發現缺陷只需要告訴開發修了，在該故事驗收的時候一起檢查就好了，無需單獨記錄；

- 在開發已經完成，交到測試人員手裡正式測試的故事，再發現缺陷就需要記錄來跟蹤了；

- 後續的所有階段發現的缺陷都需要記錄。

比較推薦的一種缺陷分析方法是魚骨圖分析法，可以將跟缺陷相關的各個因素填寫到魚骨圖里，對缺陷進行分析，如下圖2示：

缺陷相關的各屬性拿到了，就可以用表格、曲線圖、餅圖等統計各個屬性對應的缺陷數量，分析缺陷的趨勢和原因。下面是我在項目上做過的分析報告圖：

分析完得到統計的結果就要採取對應的措施，從而防範更多的缺陷產生。比如：

- 修缺陷（上面示例中的「bug fixing」）引入的新缺陷比較多，可以在修復缺陷後添加對應的自動化測試；

- 瀏覽器兼容性問題相關的缺陷較多的話，可以在開發完成驗收的時候在各個主流瀏覽器上驗收等等。

什麼時候該進行缺陷的分析也是需要搞清楚的一個問題。通常，推薦每個迭代周期分析一次，並且跟以往各個迭代進行對比，進行趨勢對比。當然，有時候可能一個迭代發現的缺陷非常少，分析的周期可以適當延長，兩個迭代合並分析一次也是可以的。還可能某個迭代突發緊急缺陷，那就可能需要立馬分析。

缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目都把缺陷分析作為常規實踐開展起來。

缺陷記錄是為更好的跟蹤和分析缺陷做准備的，而缺陷分析是軟體質量保證的重要環節，對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值，建議各項目定期都要做做缺陷分析。