需求梳理2
1.2.1 需求梳理
根據需求文件、需求規格說明書來對需要測試的功能點進行梳理，而且通過需求文件能夠更加了解專案的業務場景，一般情況下，在專案中需求文件有3種現狀：
1. 有詳細的需求文件：
比較嚴謹負責的團隊專案的實施是有詳細的需求文件的，我們就可以詳閱需求文件來進行測試點的梳理工作，對於需求中你認為不明確的地方可以找專案領導人進行溝通，做到對需求整體把握和理解，利於測試更好的進行。
2. 需求文件不明確即有文件但是文件很粗糙：
一般有兩種辦法，如果開發團隊很配合，可以要求開發或者需求分析人員完善需求文件，如果因為各種原因比如時間緊張或者開發就是不願意，那麼就需要自己去溝通對於文件中不明確的點問清楚，切記不要含糊不清的測試，於人於己都沒有好處。
3. 沒有需求文件：
如果你運氣很不好遇到了，雖然我很同情你，但是貌似同情沒啥用，我們知道做測試很重要的一點是：我有乙個預期，我要把軟體執行的實際值跟我的預期去比對，如果達到了預期，那麼就沒問題，如果跟預期不一致那就是有問題。那麼如果沒有需求，我們該怎麼辦： 第一
種靠嘴去問，大家去協調，協商溝通，然後大家都回答沒問題了，我會自己寫乙個概要的需求描述，然後讓他去確認，他說可以，那咱們就這樣測，有問題就不斷的口頭溝通；
第二種要基於使用者使用的場景和行業的經驗來去做判斷它是不是合理的。
測試計畫3
1.3.1 測試工具選取
測試工具說明：
以上列出了自己在測試過程中所用過的一些工具，每種都有自己的利弊和自適應的測試場景，可以進行參考和根據實際需求來進行分析選取。
1.3.2 測試人員分配
測試場景敲定以後，對於大業務量的測試工作或者團隊合作測試的任務需要分配好各自的任務，讓大家各司其職，如：測試環境梳理和搭建人員、測試資料準備人員、測試指令碼編寫人員、測試執行人員、測試日誌收集人員、測試結果彙總分析人員，每個人可以負責乙個模組或者多個模組，更甚者有的專案任務量不多，乙個人搞定這麼多部分也是大有人在，即乙個人搭建環境、乙個人準備資料寫測試用例準備測試、收集日誌進行分析，這對測試人員的要求比較高才能更好保證產品的輸出質量。
1.3.3 測試業務場景選取
根據需求說明文件，梳理需要測試的業務點和場景，比如應用系統的效能測試，需測試nginx負載節點的效能情況，是否可支撐1000/s的業務能力，極限環境下支撐2萬/s併發，節點接收報文常規為幾byte，大報文可達到8k，節點支援分布式部署。則我們根據這些資訊可以梳理我們需要測試的場景有：直接壓測一台節點觀察效能峰值、nginx負載一台節點的效能、nginx負載兩台節點的效能、nginx負載三颱節點的效能、報文場景為500位元組、1kb、8kb、併發數為依次遞增至1500併發(保證1000/s併發是否可以)，看是否滿足常規業務處理能力，極限測試下併發數為2萬，測試7*24小時，觀察極限處理能力。
1.3.4 測試環境梳理
根據測試場景以及梳理的被測系統、壓力系統、壓力機情況、給定的伺服器數量，繪製測試環境搭建圖譜即每個應用系統搭建數量、各節點所在機器，如下圖梳理了整個系統部署的流程及每個應用、監控工具、測試工具應該部署的機器情況，讓人一目了然。
1.3.5 測試資料梳理
這裡的測試資料內容很廣，可包括測試準備和測試執行階段所需要的一切資料**，如：測試指令碼、測試引數化檔案、測試賬號、輔助性測試程式等，即讓測試工作更加有條不紊的進行，而不是等到測試時才發現這個東西要去找，那個東西又沒有弄得自己手忙腳亂，降低測試效率。比如，下面是一段造資料的儲存過程指令碼：
（待續）
產品經理之路（二）
本文簡述產品經理基礎階段及產品思維 商業模式畫布。一 概念 1 畫布 2 商業模式 二 要素 1 使用者細分 1 以使用者為核心 2 我們正在為誰創造價值？3 誰是我們最重要的客戶？2 價值主張 用來描繪為特定使用者細分創造價值的系列產品和服務。1 我們應該向客戶傳遞什麼樣的價值 2 我們正在幫助我...
單元測試之路（二）
引入測試集，testsuite，用於存放測試用例的容器 testsuite方法 init self,tests 初始化，直接新增測試用例 addtest self,test 新增乙個測試用例 addtest self,tests 新增多個測試用例 texttestrunner執行測試集 countt...
軟體測試 學習之路 CSS 二）
一 元素展示型別 html中本身定義許多元素有自己預設在網頁中顯示的樣式，如有些元素預設情況下，你設定的寬高屬性不起作用，有些元素獨佔一行。這種現象我們稱為元素展示型別，為了方便記憶將元素展現型別分為三種 1.塊元素 2.行內元素 3.行內塊元素 塊元素 當時存在多個塊元素時，每乙個塊元素都會獨佔一...