針對(duì)你的問題，給你一些建議
做網(wǎng)站、網(wǎng)站建設(shè)的開發(fā)，更需要了解用戶，從用戶角度來建設(shè)網(wǎng)站，獲得較好的用戶體驗(yàn)。創(chuàng)新互聯(lián)建站多年互聯(lián)網(wǎng)經(jīng)驗(yàn)，見的多，溝通容易、能幫助客戶提出的運(yùn)營建議。作為成都一家網(wǎng)絡(luò)公司，打造的就是網(wǎng)站建設(shè)產(chǎn)品直銷的概念。選擇創(chuàng)新互聯(lián)建站，不只是建站，我們把建站作為產(chǎn)品，不斷的更新、完善，讓每位來訪用戶感受到浩方產(chǎn)品的價(jià)值服務(wù)。
1、在數(shù)據(jù)庫設(shè)計(jì)方面，
應(yīng)針對(duì)已給出的問題，進(jìn)行設(shè)計(jì)，我認(rèn)為應(yīng)設(shè)計(jì)兩張表
首先a、登錄表，比如命名為
logintbl
id varchar2
username varchar2
password varchar2
答案統(tǒng)計(jì)表
answertbl
id varchar2 /／這里與登錄表中的id也就是學(xué)好相對(duì)應(yīng)
anone varchar2(1)
......
point int
具體的表中字段長度設(shè)置你可以自行根據(jù)你的要求進(jìn)行設(shè)置
2、在頁面設(shè)計(jì)方面
網(wǎng)上有很多類似的界面可以做參考，唯一需要注意的是
a、在答題時(shí)間上，讀取的是服務(wù)器時(shí)間，如果讀取的為本地時(shí)間那么在刷新后，js代碼會(huì)重新計(jì)算倒計(jì)時(shí)時(shí)間
b、當(dāng)對(duì)已答畢的題目修改時(shí)需要點(diǎn)擊上一頁時(shí)，需要讀取信息，如果將已答完的結(jié)果存入數(shù)據(jù)庫，在對(duì)其進(jìn)行修改，這是最簡(jiǎn)單的方法，但是這樣勢(shì)必將使與數(shù)據(jù)庫交互頻率增加，為數(shù)據(jù)庫增添壓力，建議將已答完的問題答案，保存到一個(gè)數(shù)組中，每次點(diǎn)擊下一頁的時(shí)候，將其存入數(shù)組，再點(diǎn)擊上一頁的時(shí)候，可以讀取數(shù)組中的內(nèi)容，最后點(diǎn)擊保存的時(shí)候，整體對(duì)數(shù)組中的答案進(jìn)行保存
給了你一點(diǎn)建議，另外這個(gè)應(yīng)該編寫不難，所以建議你自行編寫
使用框架來用于單元測(cè)試
Java提供了若干用于單元測(cè)試的框架。TestNG和JUnit是最流行的測(cè)試框架。JUnit和TestNG的一些重要功能：
易于設(shè)置和運(yùn)行。
支持注釋
允許忽略或分組并一起執(zhí)行某些測(cè)試。
支持參數(shù)化測(cè)試，即通過在運(yùn)行時(shí)指定不同的值來運(yùn)行單元測(cè)試。
通過與構(gòu)建工具，如Ant，Maven和Gradle集成來支持自動(dòng)化的測(cè)試執(zhí)行。
EasyMock是一個(gè)模擬框架，是單元測(cè)試框架，如JUnit和TestNG的補(bǔ)充。EasyMock本身不是一個(gè)完整的框架。它只是添加了創(chuàng)建模擬對(duì)象以便于測(cè)試的能力。例如，我們想要測(cè)試的一個(gè)方法可以調(diào)用從數(shù)據(jù)庫獲取數(shù)據(jù)的DAO類。在這種情況下，EasyMock可用于創(chuàng)建返回硬編碼數(shù)據(jù)的MockDAO。這使我們能夠輕松地測(cè)試我們意向的方法，而不必?fù)?dān)心數(shù)據(jù)庫訪問。
謹(jǐn)慎使用測(cè)試驅(qū)動(dòng)開發(fā)！
測(cè)試驅(qū)動(dòng)開發(fā)（TDD）是一個(gè)軟件開發(fā)過程，在這過程中，在開始任何編碼之前，我們基于需求來編寫測(cè)試。由于還沒有編碼，測(cè)試最初會(huì)失敗。然后寫入最小量的代碼以通過測(cè)試。然后重構(gòu)代碼，直到被優(yōu)化。
目標(biāo)是編寫覆蓋所有需求的測(cè)試，而不是一開始就寫代碼，卻可能甚至都不能滿足需求。TDD是偉大的，因?yàn)樗鼘?dǎo)致簡(jiǎn)單的模塊化代碼，且易于維護(hù)?？傮w開發(fā)速度加快，容易發(fā)現(xiàn)缺陷。此外，單元測(cè)試被創(chuàng)建作為TDD方法的副產(chǎn)品。
然而，TDD可能不適合所有的情況。在設(shè)計(jì)復(fù)雜的項(xiàng)目中，專注于最簡(jiǎn)單的設(shè)計(jì)以便于通過測(cè)試用例，而不提前思考可能會(huì)導(dǎo)致巨大的代碼更改。此外，TDD方法難以用于與遺留系統(tǒng)，GUI應(yīng)用程序或與數(shù)據(jù)庫一起工作的應(yīng)用程序交互的系統(tǒng)。另外，測(cè)試需要隨著代碼的改變而更新。
因此，在決定采用TDD方法之前，應(yīng)考慮上述因素，并應(yīng)根據(jù)項(xiàng)目的性質(zhì)采取措施。
測(cè)量代碼覆蓋率
代碼覆蓋率衡量（以百分比表示）了在運(yùn)行單元測(cè)試時(shí)執(zhí)行的代碼量。通常，高覆蓋率的代碼包含未檢測(cè)到的錯(cuò)誤的幾率要低，因?yàn)槠涓嗟脑创a在測(cè)試過程中被執(zhí)行。測(cè)量代碼覆蓋率的一些最佳做法包括：
使用代碼覆蓋工具，如Clover，Corbetura，JaCoCo或Sonar。使用工具可以提高測(cè)試質(zhì)量，因?yàn)檫@些工具可以指出未經(jīng)測(cè)試的代碼區(qū)域，讓你能夠開發(fā)開發(fā)額外的測(cè)試來覆蓋這些領(lǐng)域。
每當(dāng)寫入新功能時(shí)，立即寫新的測(cè)試覆蓋。
確保有測(cè)試用例覆蓋代碼的所有分支，即if / else語句。
高代碼覆蓋不能保證測(cè)試是完美的，所以要小心！
盡可能將測(cè)試數(shù)據(jù)外部化
在JUnit4之前，測(cè)試用例要運(yùn)行的數(shù)據(jù)必須硬編碼到測(cè)試用例中。這導(dǎo)致了限制，為了使用不同的數(shù)據(jù)運(yùn)行測(cè)試，測(cè)試用例代碼必須修改。但是，JUnit4以及TestNG支持外部化測(cè)試數(shù)據(jù)，以便可以針對(duì)不同的數(shù)據(jù)集運(yùn)行測(cè)試用例，而無需更改源代碼。
使用斷言而不是Print語句
許多新手開發(fā)人員習(xí)慣于在每行代碼之后編寫System.out.println語句來驗(yàn)證代碼是否正確執(zhí)行。這種做法常常擴(kuò)展到單元測(cè)試，從而導(dǎo)致測(cè)試代碼變得雜亂。除了混亂，這需要開發(fā)人員手動(dòng)干預(yù)去驗(yàn)證控制臺(tái)上打印的輸出，以檢查測(cè)試是否成功運(yùn)行。更好的方法是使用自動(dòng)指示測(cè)試結(jié)果的斷言。
構(gòu)建具有確定性結(jié)果的測(cè)試
一些方法不具有確定性結(jié)果，即該方法的輸出不是預(yù)先知道的，并且每一次都可以改變
除了正面情景外，還要測(cè)試負(fù)面情景和邊緣情況
通常，開發(fā)人員會(huì)花費(fèi)大量的時(shí)間和精力編寫測(cè)試用例，以確保應(yīng)用程序按預(yù)期工作。然而，測(cè)試負(fù)面測(cè)試用例也很重要。負(fù)面測(cè)試用例指的是測(cè)試系統(tǒng)是否可以處理無效數(shù)據(jù)的測(cè)試用例。例如，考慮一個(gè)簡(jiǎn)單的函數(shù)，它能讀取長度為8的字母數(shù)字值，由用戶鍵入。除了字母數(shù)字值，應(yīng)測(cè)試以下負(fù)面測(cè)試用例：
用戶指定非字母數(shù)字值，如特殊字符。
用戶指定空值。
用戶指定大于或小于8個(gè)字符的值。
類似地，邊界測(cè)試用例測(cè)試系統(tǒng)是否適用于極端值。例如，如果用戶希望輸入從1到100的數(shù)字值，則1和100是邊界值，對(duì)這些值進(jìn)行測(cè)試系統(tǒng)是非常重要的。
你這說的太籠統(tǒng)了，應(yīng)該具體些。
有了Java代碼之后
1、可以在代碼中寫些測(cè)試的方法，把你想要驗(yàn)證的東西，輸出看一下。
2、可以用Debug的形式，跟蹤代碼執(zhí)行，驗(yàn)證程序的邏輯是否正確。
3、利用JUnit寫斷言，測(cè)試結(jié)果
可以用main函數(shù)和JUnit來寫測(cè)試代碼。main是最早使用的，但是現(xiàn)在更流行的測(cè)試工具是JUnit。
JUnit是一個(gè)Java語言的單元測(cè)試框架。它由Kent Beck和Erich Gamma建立，逐漸成為源于Kent Beck的sUnit的xUnit家族中最為成功的一個(gè)。 JUnit有它自己的JUnit擴(kuò)展生態(tài)圈。多數(shù)Java的開發(fā)環(huán)境都已經(jīng)集成了JUnit作為單元測(cè)試的工具。
下面是一些具體的編寫測(cè)試代碼的技巧或較好的實(shí)踐方法：
1. 不要用TestCase的構(gòu)造函數(shù)初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依賴或假定測(cè)試運(yùn)行的順序，因?yàn)镴Unit利用Vector保存測(cè)試方法。所以不同的平臺(tái)會(huì)按不同的順序從Vector中取出測(cè)試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨后的測(cè)試依賴于某些特定的交易數(shù)據(jù)，就不要提交交易數(shù)據(jù)。簡(jiǎn)單的回滾就可以了。
4. 當(dāng)繼承一個(gè)測(cè)試類時(shí)，記得調(diào)用父類的setUp()和tearDown()方法。
5. 將測(cè)試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）
6. 測(cè)試類和測(cè)試方法應(yīng)該有一致的命名方案。如在工作類名前加上test從而形成測(cè)試類名。
7. 確保測(cè)試與時(shí)間無關(guān)，不要依賴使用過期的數(shù)據(jù)進(jìn)行測(cè)試。導(dǎo)致在隨后的維護(hù)過程中很難重現(xiàn)測(cè)試。
8. 如果你編寫的軟件面向國際市場(chǎng)，編寫測(cè)試時(shí)要考慮國際化的因素。不要僅用母語的Locale進(jìn)行測(cè)試。
9. 盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡(jiǎn)潔。
10.測(cè)試要盡可能地小，執(zhí)行速度快。
11.不要硬性規(guī)定數(shù)據(jù)文件的路徑。
12.利用Junit 的自動(dòng)異常處理書寫簡(jiǎn)潔的測(cè)試代碼
事實(shí)上在Junit 中使用try-catch 來捕獲異常是沒有必要的，Junit 會(huì)自動(dòng)捕獲異常。那些沒有被捕獲的異常就被當(dāng)成錯(cuò)誤處理。
13. 充分利用Junit 的assert/fail 方法
assertSame()用來測(cè)試兩個(gè)引用是否指向同一個(gè)對(duì)象
assertEquals()用來測(cè)試兩個(gè)對(duì)象是否相等
14. 確保測(cè)試代碼與時(shí)間無關(guān)
15. 使用文檔生成器做測(cè)試文檔。
重慶分公司
重慶分公司
