小時候對測試不很重視,好比讓你作一件事,你會考慮其風險,別的因素嗎。當你埋頭只顧本身寫軟件代碼,發佈軟件,就完事啦。但事實並不是如此,對方說你的網站有漏洞,或者軟件註冊碼容易破解,這些你並不知道。跟客戶打交道,客戶不是說作完項目就完事啦,每每要一個月維護。或者測試一下。意外的狀況也不少,這些你絕對沒想到。軟件的bug如何產生的,在你寫以前就產生。人的思惟並不是絕對的。每每是相對的,人們總喜歡自覺得是,"I,M GOOD......"但測試離不開實踐,不犯錯誤是不可能的。 javascript
軟件測試的過程其實很像給人看病的過程 java
而且最好把全身都檢查一遍,以確保沒有影響到整我的 linux
軟件測試就像是向上帝禱告 程序員
你究竟有罪沒有,牧師有時會問你有沒有罪,求上帝寬恕 web
按照上帝說:「世人皆有罪,惟有上帝是潔淨的」 面試
軟件產品代碼bug,是存在的。 sql
軟件測試就像測試人生 shell
如,一個故事----我爲何沒升職 數據庫
「老闆,我有過遲到、早退或亂章違紀的現象嗎?」我問。 編程
老闆乾脆地回答「沒有」。
那是公司對我有偏見嗎?」老闆先是一怔,繼而說「固然沒有。」
「爲何比我資歷淺的人均可以獲得重用、而我卻一直在微不足道的崗位上?」
老闆一時語塞,而後笑笑說:「你的事我們等會再說,我手頭上有個急事,要不你先幫我處理一下?」
一家客戶準備到公司來考察產品情況,老闆叫我聯繫他們,問問什麼時候過來。
「這真是個重要的任務。」臨出門前,我不忘調侃一句。
一刻鐘後,我回到老闆辦公室。
「聯繫到了嗎?」老闆問。
「聯繫到了,他們說可能下週過來。」
「具體是下週幾?」老闆問。
「這個我沒細問。」
「他們一行多少人。」
「啊!您沒問我這個啊!」
「那他們是坐火車仍是飛機?」
「這個您也沒叫我問呀!」
老闆再也不說什麼了,他打電話叫朱政過來。
朱政比我晚到公司一年,如今已經是一個部門的負責人了,他接到了與我剛纔相同的任務。
一下子功夫,朱政回來了。
「哦,是這樣的一一」
朱政答道:「他們是乘下週五下午3點的飛機,大約晚上6點鐘到,他們一行5人,由採購部王經理帶隊,我跟他們說了,我公司會派人到機場迎接。另外,他們計劃考察兩天時間,具體行程到了之後雙方再商榷。爲了方便工做,我建議把他們安置在附近的國際**,若是您贊成,房間明天我就提早預訂。還有,下週天氣預報有雨,我會隨時和他們保持聯繫,一旦狀況有變,我將隨時向您彙報。」
朱政出去後,老闆拍了我一下說:「如今咱們來談談你提的問題。」
「不用了,我已經知道緣由,打攪您了。」
我忽然明白,沒有誰生來就擔當大任,都是從簡單、平凡的小事作起,今天你爲本身貼上什麼樣的標籤,或許就決定了明天你是否會被委以重任。
能力的差距直接影響到辦事的效率,任何一個公司都迫切須要那些工做積極主動負責的員工。
優秀的員工每每不是被動地等待別人安排工做,而是主動去了解本身應該作什麼,而後盡心盡力地去完成。
下面談談對軟件,網站的項目測試
Drop table. Guess table name and drop it, note the next flowing SQL language
Select * from A where A.a = ‘testdata’; drop table A---’; |
2. 2. If a field only allow number, give it a String or others
3. Use ‘OR 1=1’, get all records in query function
Select * from A where A.a = ‘testdata’ OR ‘1’=’1’; |
4. 3. In login function, give user name field like ‘username’--’, 「--’ and A.password = ‘’」 is commented
Select * from user A where A.username = ‘username’--’ and A.password = ‘’; |
5. 4. Adding records function, if there is 4 fields in this table, add 5 fields, eg.
Normal: Insert into table A values(‘’,’’,’’,’’); Test Data: Insert into table A values(‘’,’testdata’,’’,’’,’’); |
6. 5. Input test data in or out of this field data
7. 6. Add single quotation marks and semicolon, and break off string splicing, this is similar with point 4
Update table A set A.a = ‘testdata’;--’ |
Yellow partis test data we input
web測試--安全性:
(1)表單驗證
(2)sql注入
(3)跨站點攻擊
(1)表單驗證
對所輸入的用戶名 密碼 郵箱@ 手機號(11位)進行驗證
(2)sql 注入
若是攻擊者的登陸的用戶名和密碼分別是: 空格or 1=1# 密碼是 空
select * from users where username=' or 1=1#’ and password=md5('')
在sql中#是註釋語
等價與
select * from users where username=' or 1=1
1=1是 true
簡單說來就是
select * from users
這樣就能夠從數據庫中提出全部的用戶的信息
(3)跨站點攻擊
XSS跨站腳本攻擊的分類
反射型XSS跨站腳本攻擊
源碼變成了「<p>歡迎您, <script>alert(/個人名字是張三/)</script>!</p>」,從源代碼中咱們發現,用戶輸入 的數據中,<script>與</script>標籤中的代碼被瀏覽器執行了,而這並非網頁腳本程序想要的結果。這個例子正是 最簡單的一種XSS跨站腳本攻擊的形式,稱之爲反射型XSS。
存儲型XSS跨站腳本攻擊
存儲型XSS腳本攻擊最爲常見的場景就是在博客或新聞發佈系統中,黑客將包含有惡意代碼的數據信息直接寫入文章或文章評論中,全部瀏覽文章或評論的用戶, 都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。如流行的Bo-Blog程序的早期版本中存在對用戶提交評論數據過濾不嚴致使的XSS跨站腳本攻擊漏 洞,黑客能夠在文章評論中提交插入惡意數據的UBB代碼,提交後,Bo-Blog程序會將數據保存至數據庫中,當用戶瀏覽該日誌時,就會執行插入的惡意代 碼,
基於DOM的XSS跨站腳本攻擊。
/**
* Android Application Testing Guide
*/
package com.example.aatg.test;
import JUnit.framework.TestCase;
/**
*
@author diego
*/
public class MyUnitTests extends TestCase {
private int mFixture;
/**
*
@param name test name
*/
public MyUnitTests(String name) {
super(name);
}
/* (non-Javadoc)
*
@see JUnit.framework.TestCase#setUp()
*/
protected void setUp() throws Exception {
super.setUp();
mFixture = 1234;
}
/* (non-Javadoc)
*
@see JUnit.framework.TestCase#tearDown()
*/
protected void tearDown() throws Exception {
super.tearDown();
}
/**
* Preconditions
*/
public void testPreconditions() {
}
/**
* Test method
*/
public void testSomething() {
fail("Not implemented yet");
}
}
|
所以,在Android應用中,你若測試使用了額外的、有限的資源,好比Services服務或者contentProvides,那麼,你應該注意要及時釋放掉。在tearDown方法中,嚴格遵照將對象設置成null的規則,以便及時回收,避免一直佔用資源,一直到全部用例跑完才釋放。
滲透測試
銀行網站測試
銀行是網絡信息技術應用最密集、應用水平最高的行業之一,基於計算機網絡的各種銀行信息系統已經成爲銀行產品的開發推廣、銀行業務的展開、銀行平常管理和決策的所依賴的關鍵組成部分。這種依賴性使得銀行面臨着因爲網絡信息系統自己所帶來的銀行信息技術風險。
銀行信息技術風險的主要挑戰來自於基礎網絡信息技術的複雜性和變化,其中面對互聯網主要有如下幾個方面風險:
基於網絡的電子銀行,須要有完善的安全體系架構;
面向Internet的銀行業務面臨着各類各樣的互聯網威脅;
遠程移動用戶接入和內部用戶接入Internet,均可能引入不一樣類型的威脅源;
釣魚網站對於銀行網上業務和企業信譽的損害。
伴隨銀行業務的發展,原有的網上銀行、門戶網站等都進行了不一樣程度的功能更新和系統投產,同時,行內系統安全要求愈來愈高,可能受到的惡意攻擊包括:信息篡改與重放、信息銷燬、信息欺詐與抵賴、非受權訪問、網絡間諜、「黑客」入侵、病毒傳播、特洛伊木馬、蠕蟲程序、邏輯炸彈等。這些攻擊徹底能形成信息系統癱瘓、重要信息流失。
2、滲透測試的目標
本項目經過滲透測試的方式,模擬黑客的攻擊思路與技術手段,達到如下目標:
從攻擊者角度,發現網銀系統、信用卡網站、門戶網站和中間業務等應用系統及網關入口設備存在的安全隱患;
檢測對外提供服務的業務系統(如網銀系統、信用卡網站、門戶網站等)以及行內重要業務系統的威脅防護能力。
深度挖掘滲透測試範圍內應用系統各個層面(應用層、網絡層、系統層)的安全漏洞;
檢驗當前安全控制措施的有效性,針對發現的安全風險及時進行整改,加強系統自身防護能力,提高安全保障體系的總體健壯性。
3、滲透測試原則與風險控制原則
遵循規範
滲透測試經過可控的安全測試技術對限定範圍內的應用系統進行滲透測試,同時結合如下業界著名的測試框架組合成最佳實踐進行操做:
ISECOM制定的開源安全測試方法OSSTMM-v2.2
開放Web應用安全項目OWASP-v3
風險控制
滲透測試過程最大的風險在於測試過程當中對業務產生影響,爲此咱們在實施滲透測試中採起如下措施來減少風險:
● 雙方確認
進行每一階段的滲透測試前,必須得到客戶方的書面贊成和受權。對於任何滲透測試的對象的變動和測試條件的變動也都必須得到雙方的贊成並達成一致意見,方可執行。
● 工具選擇
爲防止形成真正的攻擊,在滲透性測試項目中,啓明星辰會嚴格選擇測試工具,杜絕因工具選擇不當形成的將病毒和木馬植入的狀況發生。
● 時間選擇
爲減輕滲透性測試對用戶網絡和系統的影響,安排在不影響正常業務運做的時間段進行,具體時間主要限制雙方協調和商定的時間範圍內。
● 範圍控制
啓明星辰承諾不會對受權範圍以外的網絡設備、主機和系統進行漏洞檢測、攻擊測試,嚴格按照滲透測試範圍內限定的應用系統進行測試。
● 策略選擇
爲防止滲透性測試形成用戶網絡和系統的服務中斷,啓明星辰在滲透性測試中不使用含有拒絕服務的測試策略,不使用未經許可的方式進行滲透測試。
● 操做過程審計
爲保證測試過程可審計,啓明星辰將在測試過程當中開啓測試工具的審計日誌功能,階段性測試目標測試結束後,會將審計日誌提交用戶,以便用戶監控測試過程。
● 項目溝通
啓明星辰建議:在項目實施過程當中,除了肯定不一樣階段的測試人員之外,還要肯定各階段的客戶方配合人員,創建雙方直接溝通的渠道;項目實施過程當中須要客戶方人員同時在場配合工做,並保持及時、充分、合理的溝通。
● 系統備份和恢復措施
爲避免實際滲透測試過程當中可能會發生不可預知的風險,所以在滲透測試前相關管理人員應對系統或關鍵數據進行備份、確保相關的日誌審計功能正常開啓,一旦在出現問題時,能夠及時的恢復運轉。
黑客測試工具
好比 有一個登錄頁面, (假如上面有2個textbox, 一個提交按鈕。 請針對這個頁面設計30個以上的testcase.)
最後的測試,老闆會檢測你對公司的忠誠度,會不會給你重任,你確定面臨這一測試,不然你幹不下去啦。
test,test
其實測試無處不在,好比進入婚姻聖殿前,妻子會對你進行婚姻忠誠度測試,還有牧師的表白。。。。。
你也將又面臨一項測試。
好累呀。
I don't know who hold tomorrow
耳邊響起徐志摩的詩《再別康橋》
悄悄的來我又悄悄的走了。
adiOS