系統測試
測試質量保證
這條思路只是瀑布模型，如果是需求不確定的情況下不適用，應該採用類似於h模型的螺旋式，個人見解若存在問題，歡迎指正。
對程式中的最小可測試單元進行檢查和驗證，一般是開發自測通過後，提測到測試部門。如同乙個積木城堡，單元測試就是對每一塊積木的檢驗，看看是不是有問題。
模組間的整合，一般側重介面功能及介面效能。就比如這是2塊以上的積木拼接看看鏈結有沒有問題。
對程式主功能或流程進行冒煙，不通過可打回開發時間。
乙個簡單的例子就是聊天視窗必需可以傳送訊息出去，傳送訊息『a』，報後台錯誤則冒煙不通過；傳送『a』聊天窗出現的『b』可以算通過，資訊準確性可以在全量測試中檢查。
在測試時間內按照用例對系統需求進行全量確認。
按照測試用例執行全量測試，測試用例是以需求為基礎的，根據輸入，輸出對比來確保程式功能點的正確性。值得一提的是測試並不是為了證明軟體沒有問題，而是為了證明它還存在問題，即使全量測試也不能窮盡所有的問題。
考慮範圍增加到實際場景：網路，硬體…等
看公司情況可能會涉及到安全，滲透，相容，效能…
一般來說測試部門不會是質量保證的最後一道防線，會有qa部門從需求設計到開發測試這整個過程做質量保證，部分沒有qa部門就由產品，專案經理協同控制，只是效果會差一些。下圖只是簡略說明，僅作參考。
php面試題簡略整理
假如某 要秒殺一定量的小公尺手機，我們要怎麼做一些高併發的處理 這裡我們可以看到秒殺成功的第乙個使用者的id是208522,秒殺成功的最後乙個使用者是176260,參與秒殺人數總共 是20w。讓大家注意這些的原因是為了驗證下面的準確性 接下來我們依次從佇列中把秒殺成功的500個使用者取出來並觀察第乙...
如何測試乙個紙杯 利用引導詞整理測試思路
測試專家 請測試乙個紙杯？測試菜鳥 什麼？測試專家 如果給你乙個喝水的一次性一次紙杯，你將如何測試它？測試菜鳥 我想想啊。幾分鐘後。測試菜鳥 倒滿水看看漏不漏。嗯。測試專家 還有麼？測試菜鳥 能不能倒出水來。會不會變形？乙個紙杯怎麼測啊？腦子全亂了？哦，對了！你有需求麼？測試專家 嗯，不錯的問題，你...
整理最新的思路
最新想著看幾類書，將思路統一起來。這段時間工作也必要緊張，長時間這樣工作，也需要做一些積累。將實踐中遇到的問題總結一下，感覺主要是圍著專案在轉，長時間沒有技術積累，還是有點空虛，如何找回以前的感覺，暫著如下打算。看一些典型的原始碼 tomcat apache，力求精通，不要蜻蜓點水似的，主要有如下目...