檢測代碼的方法

Ⅰ 如何對一段代碼進行測試

如果90行的代碼是一段完整的程序，中間沒有調用之類的話，其實用路徑覆蓋也是很方便的，或者你可以用語句塊覆蓋。
如果相互的調用比較多的話，建議你就拆分一下，把調用的程序單拿出來，當作一個小的程序段進行測試

Ⅱ 有什麼工具可以檢測 C++ 代碼抄襲嗎

本文淺談一下C++內存泄漏的檢測，首先我們需要知道程序有沒有內存泄露，然後定位到底是哪行代碼出現內存泄露了，這樣才能將其修復。最簡單的方法當然是藉助於專業的檢測工具，比較有名如BoundsCheck工具,功能非常強大，相信做C++開發的人都離不開它。此外就是不使用任何工具，而是自己來實現對內存泄露的監控，分如下兩種情況：一.在MFC中檢測內存泄漏假如是用MFC的程序的話，很簡單。默認的就有內存泄露檢測的功能。我們用VS2005生成了一個MFC的對話框的程序,發現他可以自動的檢測內存泄露.不用我們做任何特殊的操作.仔細觀察,發現在每個CPP文件中,都有下面的代碼:#ifdef_DEBUG#definenewDEBUG_NEW#endifDEBUG_NEW這個宏定義在afx.h文件中，就是它幫助我們定位內存泄漏。在含有以上代碼的cpp文件中分配內存後假如沒有刪除，那麼停止程序的時候，VisualStudio的Output窗口就會顯示如下的信息了：Detectedmemoryleaks!Dumpingobjects->d:\code\mfctest\mfctest.cpp(80):{157}normalblockat0x003AF170,4byteslong.Data:00000000Objectmpcomplete.在Output窗口雙擊粗體字那一行，那麼IDE就會打開該文件，定位到該行，很容易看出是哪出現了內存泄露。二．檢測純C++的程序內存泄露我試了下用VisualStudio建立的Win32ConsoleApplication和Win32Project項目，結果都不能檢測出內存泄露。下面一步一步來把程序的內存泄露檢測的機制建立起來。首先，我們需要知道C運行庫的Debug版本提供了許多檢測功能，使得我們更容易的Debug程序。在MSDN中有專門的章節講這個，叫做DebugRoutines，建議大家先看看裡面的內容吧。我們會用到裡面很重要的幾個函數。

Ⅲ iphone硬體檢測代碼是什麼

iphone沒有硬體檢測代碼，只能每一項逐個檢測。

9、藍牙是否正常：iPhone僅能匹配其他藍牙設備但是並不能搜索其他 iPhone，拿個藍牙耳機重新匹配連接，一試便知。

10、麥克風是否正常：打開系統自帶的語音備忘錄程序，一錄音便知

11、震動功能是否正常：輕撥手機側面的靜音鍵，一試便知。

12、有無網路鎖：關掉蜂窩數據里的數據漫遊，內置卡貼機關閉後可能無法上網。

13、有無拆機：這個需要拆機判斷，主要還是要看內部的試水紙是否完好，有沒有明顯的主板維修或者「飛線」焊接痕跡等。

Ⅳ 有了java代碼,如何測試

你這說的太籠統了，應該具體些。
有了Java代碼之後
1、可以在代碼中寫些測試的方法，把你想要驗證的東西，輸出看一下。
2、可以用Debug的形式，跟蹤代碼執行，驗證程序的邏輯是否正確。
3、利用JUnit寫斷言，測試結果

Ⅳ 實際開發中，我怎麼測我寫的代碼是否對

可以用main函數和JUnit來寫測試代碼。main是最早使用的，但是現在更流行的測試工具是JUnit。
JUnit是一個Java語言的單元測試框架。它由Kent Beck和Erich Gamma建立，逐漸成為源於Kent Beck的sUnit的xUnit家族中最為成功的一個。 JUnit有它自己的JUnit擴展生態圈。多數Java的開發環境都已經集成了JUnit作為單元測試的工具。
下面是一些具體的編寫測試代碼的技巧或較好的實踐方法：
1. 不要用TestCase的構造函數初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依賴或假定測試運行的順序，因為JUnit利用Vector保存測試方法。所以不同的平台會按不同的順序從Vector中取出測試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨後的測試依賴於某些特定的交易數據，就不要提交交易數據。簡單的回滾就可以了。
4. 當繼承一個測試類時，記得調用父類的setUp()和tearDown()方法。
5. 將測試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）
6. 測試類和測試方法應該有一致的命名方案。如在工作類名前加上test從而形成測試類名。
7. 確保測試與時間無關，不要依賴使用過期的數據進行測試。導致在隨後的維護過程中很難重現測試。
8. 如果你編寫的軟體面向國際市場，編寫測試時要考慮國際化的因素。不要僅用母語的Locale進行測試。
9. 盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡潔。
10.測試要盡可能地小，執行速度快。
11.不要硬性規定數據文件的路徑。
12.利用Junit 的自動異常處理書寫簡潔的測試代碼
事實上在Junit 中使用try-catch 來捕獲異常是沒有必要的，Junit 會自動捕獲異常。那些沒有被捕獲的異常就被當成錯誤處理。
13. 充分利用Junit 的assert/fail 方法
assertSame()用來測試兩個引用是否指向同一個對象
assertEquals()用來測試兩個對象是否相等
14. 確保測試代碼與時間無關
15. 使用文檔生成器做測試文檔。
對人體會造成危害，甚至毀壞機械建築等。

Ⅵ 如何自己寫代碼去測試別人的代碼

單元測試的基本方法是調用被測代碼的函數，輸入函數的參數值，獲取返回結果，然後與預期測試結果進行比較，如果相等則認為測試通過，否則認為測試不通過。
1、

Ⅶ html如何檢驗代碼規范

代碼規范性有兩種方法：
1、在線檢查：http://validator.w3.org/；
2、工具檢查，例如：Html Validator。
Html Validator是Firefox的一個附加組件，以前看《精通CSS》提到的一些工具都因為不方便而沒使用，每次都是在W3C在線驗證查看代碼是否規范。雖說過於追求標准有時沒必要，但可能就因為有這種「標准癖」，沒通過驗證總覺得代碼還是有問題。這個擴展真是解決了我不少問題。
Html Validator驗證起來很方便。本地驗證速度比W3C的在線網頁要快很多，頁面打開就能查看存在多少個問題，幾處錯誤幾處警告都一目瞭然。
它的驗證方式有3種：HTML 、Tidy、SGML解析器和連續。前兩種分別適合HTML和XHTML的驗證，第三種為兩種模式各驗證一遍。

Ⅷ 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(8)檢測代碼的方法擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具

Ⅸ 用python單元測試怎麼測一段代碼

單元測試是用來對一個模塊、一個函數或者一個類來進行正確性檢驗的測試工作。

比如對函數abs()，我們可以編寫出以下幾個測試用例：

輸入正數，比如1、1.2、0.99，期待返回值與輸入相同；
輸入負數，比如-1、-1.2、-0.99，期待返回值與輸入相反；
輸入0，期待返回0；
輸入非數值類型，比如None、[]、{}，期待拋出TypeError。

把上面的測試用例放到一個測試模塊里，就是一個完整的單元測試。

如果單元測試通過，說明我們測試的這個函數能夠正常工作。如果單元測試不通過，要麼函數有bug，要麼測試條件輸入不正確，總之，需要修復使單元測試能夠通過。

單元測試通過後有什麼意義呢？如果我們對abs()函數代碼做了修改，只需要再跑一遍單元測試，如果通過，說明我們的修改不會對abs()函數原有的行為造成影響，如果測試不通過，說明我們的修改與原有行為不一致，要麼修改代碼，要麼修改測試。

這種以測試為驅動的開發模式最大的好處就是確保一個程序模塊的行為符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行為仍然是正確的。

我們來編寫一個Dict類，這個類的行為和dict一致，但是可以通過屬性來訪問，用起來就像下面這樣：

>>> d = Dict(a=1, b=2)
>>> d['a']
1
>>> d.a
1

mydict.py代碼如下：

class Dict(dict):

def __init__(self, **kw):
super(Dict, self).__init__(**kw)

def __getattr__(self, key):
try:
return self[key]
except KeyError:
raise AttributeError(r"'Dict' object has no attribute '%s'" % key)

def __setattr__(self, key, value):
self[key] = value

為了編寫單元測試，我們需要引入Python自帶的unittest模塊，編寫mydict_test.py如下：

import unittest

from mydict import Dict

class TestDict(unittest.TestCase):

def test_init(self):
d = Dict(a=1, b='test')
self.assertEquals(d.a, 1)
self.assertEquals(d.b, 'test')
self.assertTrue(isinstance(d, dict))

def test_key(self):
d = Dict()
d['key'] = 'value'
self.assertEquals(d.key, 'value')

def test_attr(self):
d = Dict()
d.key = 'value'
self.assertTrue('key' in d)
self.assertEquals(d['key'], 'value')

def test_keyerror(self):
d = Dict()
with self.assertRaises(KeyError):
value = d['empty']

def test_attrerror(self):
d = Dict()
with self.assertRaises(AttributeError):
value = d.empty

編寫單元測試時，我們需要編寫一個測試類，從unittest.TestCase繼承。

以test開頭的方法就是測試方法，不以test開頭的方法不被認為是測試方法，測試的時候不會被執行。

對每一類測試都需要編寫一個test_xxx()方法。由於unittest.TestCase提供了很多內置的條件判斷，我們只需要調用這些方法就可以斷言輸出是否是我們所期望的。最常用的斷言就是assertEquals()：

self.assertEquals(abs(-1), 1) # 斷言函數返回的結果與1相等

另一種重要的斷言就是期待拋出指定類型的Error，比如通過d['empty']訪問不存在的key時，斷言會拋出KeyError：

with self.assertRaises(KeyError):
value = d['empty']

而通過d.empty訪問不存在的key時，我們期待拋出AttributeError：

with self.assertRaises(AttributeError):
value = d.empty

運行單元測試

一旦編寫好單元測試，我們就可以運行單元測試。最簡單的運行方式是在mydict_test.py的最後加上兩行代碼：

if __name__ == '__main__':
unittest.main()

這樣就可以把mydict_test.py當做正常的python腳本運行：

$ python mydict_test.py

另一種更常見的方法是在命令行通過參數-m unittest直接運行單元測試：

$ python -m unittest mydict_test
.....
----------------------------------------------------------------------
Ran 5 tests in 0.000s

OK

這是推薦的做法，因為這樣可以一次批量運行很多單元測試，並且，有很多工具可以自動來運行這些單元測試。
setUp與tearDown

可以在單元測試中編寫兩個特殊的setUp()和tearDown()方法。這兩個方法會分別在每調用一個測試方法的前後分別被執行。

setUp()和tearDown()方法有什麼用呢？設想你的測試需要啟動一個資料庫，這時，就可以在setUp()方法中連接資料庫，在tearDown()方法中關閉資料庫，這樣，不必在每個測試方法中重復相同的代碼：

class TestDict(unittest.TestCase):

def setUp(self):
print 'setUp...'

def tearDown(self):
print 'tearDown...'

可以再次運行測試看看每個測試方法調用前後是否會列印出setUp...和tearDown...。

Ⅹ 汽車電腦故障代碼怎麼檢測

汽車電腦故障代碼需要連接汽車診斷電腦到車輛的OBD介面，連接後診斷電腦將自動彈出車輛的故障代碼，具體操作步驟：

1、打開駕駛員側的車門。