測試人員找bug是個技術活, 而且bug的回歸同樣也是技術活!
bug回歸到不到位, 關係到發現bug本身有沒有修復好, 同樣也關係的因為修復bug而改動的**對其他功能的影響.
bug回歸的幾點心得:
1. 首先弄清楚bug必現的配置和操作過程.
因為有時候回歸的bug並不是測試人員自己提的, 有可能工作時間的原因,安排你回歸部分別人發現的bug.
對於回歸別人的bug時候,我的建議是首先大概了解bug後,直接去問提bug的測試人員了解情況. 我一直認為, 面對面的溝通比文本來的直接.2. 找開發弄明白bug的產生原因及如何修改對於非必現的bug, 要弄清楚重現概率大的操作步驟.
1) 先搞清楚, **那裡有問題
找開發問清楚, 原來那個地方出了問題導致出bug.
這個有助於測試分析, 從bug產生的原因可以觸類旁通. 其他的軟體模組是不是也可能存在這種問題啊, 或者這種問題是不是典型易犯錯的型別,
以及從bug中得出一些經驗積累, 對缺陷預防的工作有積極作用.
2) 在搞清楚, 怎麼修復這個問題
弄清楚原因後, 進一部搞明白開發是如何修改的.
修復當前的bug往往很簡單, 有些開發只是針對當前的問題進行修改. 這也的話有可能,修改的**會影響到其他模組.
比如說修改的是一些公共的函式, 是乙個"非常危險"的訊號. 極其就會影響到其他功能.3. 注意bug回歸的測試關聯點.
一些新員工在進行bug回歸的時候,往往只是從當前bug的產生操作步驟進行回歸驗證而已, 往往沒有考慮到修復這個bug有可能會影響其他的功能.4. 非必現的bug回歸方法(難重現)回歸bug有2個基本要
素: 首先bug是否已經修復好, 其次就是是否影響其他功能.
當然, 有些修復的bug不好分析對那些模組, 那些子系統造成影響. 這就需要前面第二點要對bug的原因以及修改進行了解, 這個涉及到測試人員對系統的熟悉程度.
這個過程可以找開發協助, 一般開發都會給出一些測試建議, 可能會對那些功能造成影響的. 開發沒有給出的話, 就要找開發溝通啦.
如果發現沒有修復成功的,要重新修改bug的狀態, 並且備註你測試了那些測試點. 如果是影響了其他功能點, 也可以新提乙個bug等, 具體操作看各個公司流程.
有些bug並不是有一定的必現的操作, 或者說我們找不到比較好的必現方法. 因為理論上來說, 沒有重現不了的bug, 只不過我們沒有發現.5. 自動化&&回歸測試對於這種非必現的bug, 可以視bug的重現概率而定. 比如說乙個操作, 操作10次肯定會出現一次, 這種bug基本上可以說是可以重現.
這種概率較高的,回歸的時候, 可以通過多次操作來完成. 比如說, 執行必現的操作30次以上, 均為出現問題. 這個時候可以認為修復啦.
那麼假如說, 出現的概率較小而且很難掌握重現的手段時候, 怎麼回歸呢?
首先這種可能開發也不能100%確定是什麼原因造成的, 只不過發現了一些可疑的**. 猜測是這些可疑**造成的, 進行了修復提交給測試人員回歸.
這種情況下, 可以針對**的改動部分進行部分的驗證. bug的狀態可以先不要關閉. 可以在後續的測試中持續關注.
比如說, 這個bug在經過幾輪的測試後, 都未出現過, 那麼可以認為bug修復啦.
當然這種不能100%保證bug的真正原因修復, 但是起碼可以認為就算有問題也是概率較小的.
有比較全面的自動化用例的話, 回歸bug就是好辦事啦. 把所以用例跑一遍, 如果沒有必要的話, 選擇關聯的用例跑一遍. 自動化在回歸測試中確實發揮著很大的作用,有時候可能自動化跑不出問題, 但是其他有一點作用的是,跑過一遍後可以讓人放心. 起碼可以說基本功能沒有影響.
php cout《的一點看法
即整數與小數的位數之和不應該超過6位，如果小數部分過長，那麼系統將按四捨五入法來近似成6位，如果整數部分過長，那麼也近似成為6位 例如 cout 123.4567 結果是123程式設計客棧.457，cout 123.4564 結果是123.456，cout 123456.1 結果是123456，co...
對需求的一點看法
需求是什麼，如何來做好需求，在cmmi 模型裡都給予了說明。模型將需求分為兩個部分，乙個是二級的需求管理，另乙個是 的需求開發 之後又看了rup 對需求的描述，它沒有明確對需求管理與開發進行劃分，它的工作流包括了以下幾個部分 問題分析，理解涉眾需要，定義系統，管理專案規模，改進系統定義，管理需求變更...
關於積累的一點看法
罈子裡有人討論小公司要不要積累框架的問題，有感而發，寫了點自己的看法，一家之言，歡迎拍磚。我在學習銷售的時候，有個理念對我震動很大。我們在各行各業都看到很多成功人士，大家都很羨慕他們，希望能像他們一樣成功，但是很少有人能做到。有人就分析，發現這些人比別人並不聰明多少，但基本上就有乙個特點，他們很善於...