工作中遇到的一些問題;
1.時間段任務多，測試用例應該寫不寫？為什麼要寫測試用例？面對這種情況我們應該怎樣寫測試用例？
2.如果一方的測試任務特別多，我們該怎樣調配人手介入配合？面臨的問題是沒參與過這塊的業務，不知道該怎麼入手，熟悉花費的時間太長？
3.**回滾對這個系統的影響？具體看回滾的內容是什麼？
4.回歸測試是什麼？我們回歸測試都測些什麼？場景測試和基礎功能測試的區別是什麼？
5.回歸測試的覆蓋率要達到多少？
1.首先我們需要明白我們需要做些什麼？（1.盡可能的暴露出測試的軟體與 客戶需求不符的地方，也就是我們要非常的清楚軟體是不是客戶想要的那個樣子，也就是軟體的質量是否達到客戶期望水平 2.我們要時時的向本次參與這個專案的所有人時時的反應軟體目前各種問題，離客戶期望的樣子有多遠，也就是讓所有人明白我們現在做的東西質量怎麼樣，那麼其實我們的用例就是乙個很好的讓大家深入知道我們到底測了那些東西的乙個產物，我曾看過一本書，他說與事實為友，我們才能更好的認識自己，看到自己的不足，然後針對這些不足之處一一的解決掉，我也覺得是這樣的）
任務多時間少，我們該怎麼處理用例問題？我個人理解，這種情況屬於特殊時期，那我們應該做一些特殊的措施。1.根據時間多少來定，寫多少，可以抓住產品經理最關注的一些業務場景，也就是重點業務場景，和痛點業務場景，我理解的痛點業務，在評審需求的時候一些複雜的或者容易出錯的場景，我覺得抓住重點和痛點業務也就是解決了大家最關心的問題，至於什麼輸入框限制了什麼的我們可以根據時間多少來定要不要反應在用例裡面 2.用例的步驟詳細程度，也是視時間來定，如果時間段我們可以簡化步驟，因為參與這個專案的同事肯定也是有一定業務基礎的，我們適當的簡化應該也是可以看懂的
2.測試任務多時我們需要應該怎麼樣讓同事快速的接入呢？
首先要明白一下幾個問題：們參與過此專案的人，不懂業務是硬傷，也不知道這個系統的核心和複雜業務層是什麼。
可以讓臨時參與進來的同事參與到此次發版計畫的回歸測試當中，當然需要我們平時盡可能寫一些比較詳細的回歸測試用例，目的就是要拿著你這個用例，他要做的是不需要懂業務，只要能跑通，是你寫的這個用例想要的結果就行、
3.**回滾問題：我們需要和開發同事確認一下我們具體回滾的那些內容，回滾了多少，是前端的，還是後端的，回滾的這些主要對於那些內容有影響，經過這些了解我們應該可以初步的定位我們接下來要主要針對那塊重測多少，測什麼，等，當然我們不提倡**回滾，因為回滾就意味著我們對某些東西要重測，無疑是增加了我們的工作量。
4.回歸測試：我理解回歸測試包括三部分部分（1.常用業務場景可以理解為重點業務和痛點業務回滾 2.主要修改部分和新增部分回歸 3.缺陷回歸）
場景測試和基礎功能測試我理解是：基礎功能冒煙，和場景冒煙，基本上是重合的，但是有時候，一些常用場景冒煙用不上一些功能點，比如:一些常用場景用的最多的就是新增，刪除和修改幾乎不用，所以冒煙場景往往就測個新增就行了，但是在功能點上，我們要保證刪除個修改是可用的，不能一點就報錯，如果純粹的測功能點，可以暫時的不考慮連續的業務場景，也可以在測場景的時候一起測，但是場景沒有測到的功能點，需要單獨，點一下，看看。
5.至於回歸測試的覆蓋率能達到多少這個要根據實際情況來定，反正回歸測試就是最後發版前的我們整體通跑環境，跑重要場景，重要的功能模組，以及比較嚴重的缺陷。
測試工作中redis常用命令
redis常用命令 1 set key1 value1 例 set runoobkey redis 2 del key1 例 del runoobkey 3 get key1 例 get runoobkey 4 lpush key1 value1 例 lpush runoobkey redis 向列...
軟體測試工作中涉及的Linux命令整理
uname a sudo mv firefox tar.gz usr local sudo tar jxvf firefox tar.gz cd firefox firefox 先解壓縮 tar xzvf install flash player 11 linux x86 64.tar gz 再複製...
工作中的問題
工作中的領悟 在工作中，每個人都會遇到這樣那樣的問題，那麼有些年輕的人就會對問題反感，覺得不出現問題最好，很多年前我也這樣，後來慚慚的，我的看法有所轉變，應該積極的心態去看問題，有出現問題，至少說明 水是活的，不是一潭死水 前幾天突然有了更深的領悟，出現問題後解決問題的關鍵是什麼，有些人會說當然是 ...