工作中一些體會
工作中總是遇到一些問題，比如一些bug在當前版本中已經發現或者解決，可是在下個版本中又出現了。很頭疼，你可以說，當然新版本出來的時候，你在檢查一下啊？是很好的辦法，可以在功能測試的時候，往往，開發組會給你乙個模組來測試，測試完成後又給你另乙個模組，中間你基本上沒有時間來檢查以前的bug。
我想最好的辦法就是引用自動化測試工具，或者優化自己的測試用例。
現在自動化測試工具以及非常成熟了，幾乎可以應用各種各樣結構的軟體產品中去，這裡對測試人員有乙個要求就是能熟練使用這些自動化測試工具，用的好，可以提高整體的工作效率，用的不好，反而會耽擱測試過程，就我所熟悉的自動化測試工具，確無法應用到現在的軟體測試中去，所以，很鬱悶。很多時候，我都覺得是個人能力的問題，只能停留在手動測試上。能做到的事，只有優化測試用例，最大可能的通過用例來發現問題。
一直想找一些適合自己目前情況的自動化測試工具，從學習到使用，需要乙個時間段，可悲的是，估計到自己能熟練使用這個自動化測試工具的時候，工作專案可能都已經完成了。
完善的測試用例或許可以彌補這一點的不足，前人留下的各種各樣測試方法也給了我們很多幫組，用到最多的可能是等價類劃分測試法。
以下是一些等價類劃分測試概念
等價類劃分是把所有可能的輸入資料,即程式的輸入域劃分成若干部分（子集）,然後從每乙個子集中選取少數具有代表性的資料作為測試用例。
1) 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程式中的錯誤都是等效的.
並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入資料合理劃分為若干等價類,在每乙個等價類中取乙個資料作為測試的輸入條件,就可以用少量代表性的測試資料.
取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
有效等價類:是指對於程式的規格說明來說是合理的,有意義的輸入資料構成的集合.利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能.
無效等價類:與有效等價類的定義恰巧相反.
設計測試用例時,要同時考慮這兩種等價類.因為,軟體不僅要能接收合理的資料,也要能經受意外的考驗.這樣的測試才能確保軟體具有更高的可靠性.
2）劃分等價類的方法:下面給出六條確定等價類的原則.
①在輸入條件規定了取值範圍或值的個數的情況下,則可以確立乙個有效等價類和兩個無效等價類.
②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的情況下,可確立乙個有效等價類和乙個無效等價類.
③在輸入條件是乙個布林量的情況下,可確定乙個有效等價類和乙個無效等價類.
④在規定了輸入資料的一組值（假定n個）,並且程式要對每乙個輸入值分別處理的情況下,可確立n個有效等價類和乙個無效等價類.
⑤在規定了輸入資料必須遵守的規則的情況下,可確立乙個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）.
⑥在確知已劃分的等價類中各元素在程式處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.
3）設計測試用例:在確立了等價類後,可建立等價類表,列出所有劃分出的等價類:
輸入條件有效等價類無效等價類
然後從劃分出的等價類中按以下三個原則設計測試用例:
①為每乙個等價類規定乙個唯一的編號.
②設計乙個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重複這一步.直到所有的有效等價類都被覆蓋為止.
③設計乙個新的測試用例,使其僅覆蓋乙個尚未被覆蓋的無效等價類,重複這一步.直到所有的無效等價類都被覆蓋為止.
在很多地方都用到這種方法，或許在工作用大家都一直在用，有過一些模糊的概念，只是不知到這就是等價類劃分測試法。乙個有經驗的測試人員，對這些方法應該是很熟練的，能更好的應用到平時的測試活動中，這就需要一些經驗了，可以在平時的工作中多多體會，多動動腦筋，要提高自己的水平，不能只用眼睛去測試，要用大腦去測試，有目的的去做一件事，這樣才不會抱怨自己什麼都沒學到，學習應該是自己努力的乙個過程吧，不是別人來教你該怎麼做怎麼做才是學習。
測試工作最大的問題是如何提高工作的效率，提高效率是在保證質量的前提下進行的，雖然你看起來很忙，每天都不停的在做事，可是沒有效率，有很多總可能與原有影響了你的效率，用例中重複部分了太多，導致很多東西重複工作，不但耽誤時間，還影響心情。如果你會用因果圖來生成測試用例，或許會有很大的幫助，以下為因果圖的一些概念
因果圖方法最終生成的就是判定表. 它適合於檢查程式輸入條件的各種組合情況.
利用因果圖生成測試用例的基本步驟:
(1) 分析軟體規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予乙個識別符號.
(2) 分析軟體規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關係. 根據這些關係,畫出因果圖.
(3) 由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.
(4) 把因果圖轉換為判定表.
(5) 把判定表的每一列拿出來作為依據,設計測試用例.
從因果圖生成的測試用例（區域性,組合關係下的）包括了所有輸入資料的取true與取false的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入資料數目的增加而線性地增加.
前面因果圖方法中已經用到了判定表.判定表（decision table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程式設計發展的初期,判定表就已被當作編寫程式的輔助工具了.
由於它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確.
判定表通常由四個部分組成.
條件樁（condition stub）:列出了問題得所有條件.通常認為列出得條件的次序無關緊要.
動作樁（action stub）:列出了問題規定可能採取的操作.這些操作的排列順序沒有約束.
條件項（condition entry）:列出針對它左列條件的取值.在所有可能情況下的真假值.
動作項（action entry）:列出在條件項的各種取值情況下應該採取的動作.
規則:任何乙個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.
顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.
判定表的建立步驟:（根據軟體規格說明）
①確定規則的個數.假如有n個條件.每個條件有兩個取值（0,1）,故有種規則.
②列出所有的條件樁和動作樁.
③填入條件項.
④填入動作項.等到初始判定表.
⑤簡化.合併相似規則（相同動作）.
b. beizer 指出了適合使用判定表設計測試用例的條件:
①規格說明以判定表形式給出,或很容易轉換成判定表.
②條件的排列順序不會也不影響執行哪些操作.
③規則的排列順序不會也不影響執行哪些操作.
④每當某一規則的條件已經滿足,並確定要執行的操作後,不必檢驗別的規則.
⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.
熟悉這個東西後我想能對你的工作產生很大的影響，不僅僅是因果圖，你要考慮在測試活動中如果覆蓋你的測試步驟，最優化你的測試步驟，即對某一些功能的測試不重複，又保證覆蓋率，雖然因果圖只是乙個軟體功能測試的方法，但是他確給我們乙個啟示，把它應用到你的工作中去吧。怎麼用？這就需要我們自己去思考。
軟體測試測試方案
測試方案 目錄1 概述 3 2 測試資源和環境 3 2.1 硬體配置 3 2.2 軟體配置 3 2.3 測試資料 3 3 測試策略 3 3.1.1 功能測試 3 3.1.2 使用者介面 ui 測試 43.1.3 效能測試 4 3.1.4 安全性測試 5 3.1.5 相容性測試 5 3.1.6 回歸測...
軟體專案測試管理經驗談
51軟體測試網 一 軟體測試員自身素質培養 1 首先，應對軟體測試感興趣和對自己有自信，如果具備了這兩點，那麼在開發過程中不管遇到什麼樣的困難，我相信你一定能克服。2 善於懷疑，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生。別人認為是對的，我卻認為不是...
軟體測試方案
文件版本控制 軟體的錯誤是不可避免的，所以必須經過嚴格的測試。通過對本軟體的測試，盡可能的發現軟體中的錯誤，藉以減少系統內部各模組的邏輯，功能上的缺陷和錯誤，保證每個單元能正確地實現其預期的功能。檢測和排除子系統 或系統 結構或相應程式結構上的錯誤，使所有的系統單元配合合適，整體的效能和功能完整。並...