基本上我想知道如果有人有任何提示，以確保您的代碼經過良好測試，沒有得到任何人在有限的時間框架內的任何幫助？自我檢測技巧？
在過去，我一直都能夠找到別人做我的代碼測試或有專門的質量保證團隊去了一切，發現的所有錯誤。
我平時很小心，但我總是覺得有一個事情我想，當我測試他們我只是不想看到他們。
然而，在我目前的工作我已經給出了兩個PHP Web應用程序在非常有限的時間框架來寫，我已經告訴我需要做的一切，儘管我的反饋，測試自己，這是不是一個好理念。
我想知道如果有人之前有過這個問題，並可以提供一些見解？
我想也許這將是很好的編碼各區域之前編寫一個快速的測試計劃，並仔細檢查，在做測試前的要求。
當然單元測試，測試優先與否，是否應該是你的第一道防線，確保每一件你的應用程序的工作你認爲它應該的方式。然而，你所談論的測試類型，它可能有助於獲得另一副眼睛，這在驗收測試領域更爲重要 - 整個應用程序是否按照它應該的方式工作;它適用於各種奇怪的場景或行爲等。
一個有用的方法是想象角色：首先測試應用程序爲自己，然後再測試一次，想象你已經85歲了，看不到非常好的，並且不要使用鼠標。你可能傾向於點擊最亮或最大的東西，假設它是你應該做的，而不是它應該做的。現在想象你是12歲，並且匆匆忙忙。你沒有辦法閱讀說明。它仍然有效嗎？
對於任何給定的字段，什麼是一個人可能鍵入的邊緣情況？如果只輸入空格會發生什麼？只有數字進入文本字段？如果你輸入HTML會發生什麼？ JavaScript的？非西方字母表中的東西？如果你輸入真的非常長的東西會怎麼樣？
關鍵是不要只是爲了測試「幸福路」，當用戶經過申請，你心目中的方式。以任何人都不應該的方式瀏覽應用程序。因爲......他們會的。
另一件重要的事情是永遠不要忽視任何事情。很容易有一個奇怪的屏幕出現，並對自己說：「哦，這只是一個僥倖。」你必須讓自己注意並追蹤所有不是應有的事情。
我認爲TDD正是你想要的。 首先編寫測試，然後編寫通過測試的代碼。除了你之外，你不需要其他任何人（儘管有人會建議你使用一些測試幫助），並且即使在開始編碼之前，你也會對該工具應該做什麼有更清楚的瞭解。
你的僱主顯然並不認爲測試是非常重要的。你應該退出並找到適當的工作。
我真的覺得告訴人們完成他們的工作是不明智的。 – 2009-09-28 00:22:41
我討厭這麼說，但我認爲在你的情況下Alex Tingle的權利。這是一個不可能的情況。
JacobM和Santi在提及單元測試，驗收測試和測試驅動開發方面是正確的。我會將代碼覆蓋率和靜態分析工具添加到該列表中。但是雖然TDD或基本單元測試通常會在減少測試時間，降低缺陷率和易於維護方面得到回報，但它們不會幫助您在死亡時間內準時交付。如果您沒有編寫自動化測試的經驗，尤其如此。
有禮貌地說，你的老闆要求你承擔技術債務。正確表達，他要求你忽視職業道德。
微笑，說「是的，先生，」在分配的時間內竭盡全力，並更新您的簡歷。
我同意並確實讓他們意識到了這個問題，但不幸的是，BAs和其他資源缺乏，項目的時間限制很有限，所以我只能盡我所能。 – Jai 2009-09-28 00:23:10
我同意上一篇關於測試驅動開發和單元測試的價值和有效性的答案。如果正確完成，在編寫生產/可交付代碼之前編寫單元測試的TDD過程將有助於保持您的專注並幫助驗證您的設計和接口。此外，其他開發人員將能夠以一種非常簡單明瞭的方式，從如何使用和使用您的代碼開始工作。請記住單元測試是不一樣的，不能替代完整的集成測試。在這種方法中，您可能仍然需要編寫完整的集成測試計劃。
我在.NET中工作原型，在使用NUnit時只有很好的結果。
我以前沒有在PHP中工作過，但從我所看到的，您可能要考慮SimpleTest或PHPUnit。
對於您可以做多少測試總是有限制的。在約束內，你顯然需要構造測試。很明顯，您希望首先爲最關鍵的領域構建測試（安全性，損壞可能性，數據丟失，功能性）。
除了功能規格說明之外，您不太可能通過手動幫助來決定要測試什麼。但是您可以通過測試覆蓋工具的形式獲得自動化幫助。這些工具會告訴你你測試了哪些代碼，以及你沒有測試過哪些代碼。通過檢查未經測試的代碼，您可以確定它是否或多或少是關鍵的，因此在發佈前或多或少值得爲其編寫測試代碼。測試覆蓋率工具還會告訴您測試代碼與總代碼的比率，以及確保此比例達到70％或以上的行業最佳實踐。您可以使用這些數據，通過一個簡單的技巧與老闆談判更多的時間：「我們只有15％的測試覆蓋率，敢於釋放它？」
的測試覆蓋工具與PHP的作品可以在這裏找到： Semantic Designs PHP Test Coverage Tool
鑑於你的老闆的要求，你必須尊重，而你爲他工作，直到你可以改變他的想法，你給問題中的正確答案。
有一點需要記住的是開發人員有自然的傾向來測試他們的代碼的「最佳路徑」。換句話說，你寫了它，所以你知道你應該點擊某些地方，輸入某些東西，然後測試它。這當然很重要。
這裏有一些很好的建議，但大多數（但不是全部）似乎都錯過了一個是負面測試。基本上，你需要測試邊界，你需要測試惡意。如上所述，在以下字段中輸入腳本代碼：
<script>alert('abc')</script>
如果您收到警報，則無法正確編碼就變得非常明顯！另一件要做的事是：
abc' or 'a' = 'a'
這可能會顯示SQL注入問題，如身份驗證。您還可以測試SQL注入的東西，如：
abc'; drop table users; select * from dual where 'a' = '
如果你的表只是走了，你有一個問題！有很多例子，但是至少你需要花一些時間來測試OWASP top 10.
你想測試的其他地方就是非常大的數字，特別是當期待整數輸入時32位平臺，負值，無值等。基本上，測試所需的流量工作，然後盡你所能地打破它。
我喜歡這個答案帶來了一些想法，我沒有想到，讓我多思考一些。我想我也會把幾個常見的配置放在一起，比如I.E.和Firefox和沒有Javascript。此外，我認爲在我放下並測試自己的代碼之前，我會運行一些其他隨機互聯網站點的快速測試，以便讓我的頭腦進入測試框架。 – Jai 2009-09-28 00:21:12