本文目錄一覽：
- 1、測試工程師學Python有什麼用？
- 2、如何使用python 語言來實現測試開發
- 3、Python自動化測試框架有哪些？
- 4、後端編程Python3-調試、測試和性能剖析(下)
- 5、python自動化測試框架有哪些
測試工程師學Python有什麼用？
軟件測試人員能用python做的事情很多，最常見的就是下面四項：1）做自動化測試【web自動化，app自動化，接口自動化】；2）做性能測試；3）開發小工具；4）搭建測試平台。
軟件測試工程師是被遺忘的技術人。主要是因為軟件測試入門門檻比較低，一大批人加入到軟件測試行業大軍中。但大部分都是一直在做點點點的功能測試，可替代性很強。行業高速發展，單純功能測試已無法滿足企業需求。如果你想增強自身競爭力，就需要有豐富的自動化項目經驗，可以根據公司項目靈活的打造一套自動化測試框架。這，都需要從熟練掌握Python編程開始。其實，不管你從事的是什麼工作，數據都會是其中的一部分。IT，軟件開發，市場等，它們都深度地關乎數據且對於智慧求之若渴。很快數據分析技能就會像編碼技能一樣的重要，掌握Python編程對你的工作有着極大的提升。千鋒教育多年辦學，課程大綱緊跟企業需求，更科學更嚴謹，每年培養泛IT人才近2萬人。不論你是零基礎還是想提升，都可以找到適合的班型，是一家性價比極高的教育機構
如何使用python 語言來實現測試開發
對於各種驅動接口，Python來編寫測試用例的好處是：由於Python不需要編譯，你所執行的也就是你所編寫的，當發生異常的時候，你無須打開集成開發環境，加載測試工程、並調試，你能夠很方便的看到python測試腳本的內容，什麼地方出了異常可以立刻發現，例如：
from ctypes import *
rc =c_int(-12345);
dll = windll.LoadLibrary(“dmodbc.dll”);#加載被測試組件
#=================#
SQLHANDLE_env = pointer(c_long(0));
SQLHANDLE_cnn = pointer(c_long(0));
SQLHANDLE_stmt = pointer(c_long(0));
pdns = c_char_p(“FASTDB”);
puid = c_char_p(“SYSDBA”);
ppwd = c_char_p(“SYSDBA”);
#env handle
rc = dll.SQLAllocHandle(1,None,byref(SQLHANDLE_env));
print “result of henv handle alloc :%d” %rc;
#cnn handle
rc = dll.SQLAllocHandle(2,SQLHANDLE_env,byref(SQLHANDLE_cnn));
print “result of cnn handle alloc :%d” %rc;
#connect!
rc = dll.SQLConnect(SQLHANDLE_cnn,pdns,-3,puid,-3,ppwd,-3)
print “result of connect :%d” %rc;
#stmt handle
rc = dll.SQLAllocHandle(3,SQLHANDLE_cnn,byref(SQLHANDLE_stmt));
print “result of stmt handle alloc:%d” %rc;
#exec
rc = dll.SQLExecDirect(SQLHANDLE_stmt,”insert into t values(1)”,-3);
print “result of exec:%d” %rc;
#free========================
rc = dll.SQLFreeHandle(3, SQLHANDLE_stmt);
print rc;
rc = dll.SQLDisconnect(SQLHANDLE_cnn);
print rc;
rc = dll.SQLFreeHandle(2, SQLHANDLE_cnn);
print rc;
rc = dll.SQLFreeHandle(1, SQLHANDLE_env);
print rc;
在上面我們可以看到，Python調用c/c++接口是十分容易的，只需要把動態庫加載進來，然後把這個動態庫當作一個對象實例來使用就可以了。下面將是一個使用ado.net接口的例子：
import System;
from Dm import *#Dm是DMDBMS提供的ado.Net的DataProvider
#print dir(Dm.DmCommand);
i =0;
cnn = Dm.DmConnection(“server = 127.0.0.1; User ID = SYSDBA; PWD = SYSDBA; Database = SYSTEM; port = 12345”);
cmd = Dm.DmCommand();
cmd.Connection = cnn;
cmd.CommandText = “insert into t values(1);”;
cnn.Open();
i=cmd.ExecuteNonQuery();
print i;
cmd.Dispose();
cnn.Close();
可以看到，.net對象的使用與在VisualStdio上進行開發幾乎沒有任何區別。
通過使用Python進行測試用例的開發，最大的好處莫過於：學習成本非常低，測試工程師只需要學習Python，對於其他語言稍有了解就可以了。同時只需要少量的測試開發工程師對Python測試框架進行維護。
這樣的好處就是便於測試人員將精力專精在一個方向，免於“什麼都會一點，但什麼都不精”的情況。當然測試人員具備廣闊的知識面，會使用各種常見的開發工具與平台是好事情，並且也是必要的，不過在短時間內要求迅速能夠勝任大多數任務也是企業在人才培養上的期望目標。
Python自動化測試框架有哪些？
第一種：Robot Framework
作為最重要的python測試框架之一，Robot Framework主要被用在測試驅動類型的開發與驗收中。雖然由python開發而來，但是它也可以在基於.net的Ironpython和基於Java的Jython上運行。同時，作為一個python框架，Robot還能夠兼容諸如Windows、MacOS、Linux等平台。
在使用Robot Framework之前，需要先安裝python2.7.14及以上版本，在這裡推薦大家使用python3.6.4，以確保適當的註解能夠被添加到代碼段中，並能夠跟蹤程序的更改，同時，您還需要安裝python包管理器–pip。
第二種：Pytest
適用於多種軟件測試的Pytest，是另一個python類型的自動化測試框架。憑藉著開源和易學的特點，該工具經常被QA團體、開發團體、個人團體以及各種開源項目所使用。鑒於Pytest具有斷言重寫之類的實用功能，許多大型互聯網應用，如Dropbox、Mozilla，都已經從下面將要提到的unittest切換到了Pytest之上。
除了基本的python知識，用戶並不需要更多的技術儲備。另外，用戶只需要有一台帶有命令行界面的測試設備，並且安裝好了python包管理器以及可用於開發的IDE工具。
第三種：UnitTest/PyUnit
受到Junit啟發的UnitTest/PyUnit，也是一種標準化的針對單元測試的python類自動化測試框架。它的基類TestCase提供了各種斷言方法、以及所有清理和設置的例程。因此，TestCase子類中的每一種方法都是以test作為名詞點綴，以標識它們能夠被作為測試用例所運行。用戶可以使用load方法和TestSuite類來分組、並加載各種測試。當然，也可以通過聯合使用，來構建自定義的測試運行器。正如我們使用Junit去測試Selenium那樣，UnitTest也會用到unittest-sml-reporting，並能生成各種XML類型的報告。
第四種：Behave
行為驅動開發是一種基於敏捷軟件開發的方法。它能夠鼓勵開發人員、業務參與者和QA人員，三者之間的協作。python測試框架Behave允許團隊避開各種複雜的情況，去執行BDD測試。從本質上說該框架與SpecFlow和Cucumber相似，常被用於執行自動化測試。用戶可以通過簡單易讀的語言來編寫測試用例，並能夠在其執行期間粘貼到代碼之中。而且，那些被設定的行為規範與步驟，也可以被重用到其他的測試方案中。
第五種：Lettuce
Lettuce是另一種基於Cucumber和python的行為驅動類自動化工具。Lettuce主要專註於那些具有行為驅動開發特性的普通任務。它不但簡單易用，而且能夠使得整個測試過程更流暢、甚至更有趣。
您需要安裝帶有IDE的python2.7.14及以上版本。當然，您也可以使用pycharm或任何其他IDE工具。同時，您還需要安裝python包管理器。
後端編程Python3-調試、測試和性能剖析(下)
單元測試（Unit Testing）
為程序編寫測試——如果做的到位——有助於減少bug的出現，並可以提高我們對程序按預期目標運行的信心。通常，測試並不能保證正確性，因為對大多數程序而言， 可能的輸入範圍以及可能的計算範圍是如此之大，只有其中最小的一部分能被實際地進 行測試。儘管如此，通過仔細地選擇測試的方法和目標，可以提高代碼的質量。
大量不同類型的測試都可以進行，比如可用性測試、功能測試以及整合測試等。這裡, 我們只講單元測試一對單獨的函數、類與方法進行測試，確保其符合預期的行為。
TDD的一個關鍵點是，當我們想添加一個功能時——比如為類添加一個方法—— 我們首次為其編寫一個測試用例。當然，測試將失敗，因為我們還沒有實際編寫該方法。現在，我們編寫該方法，一旦方法通過了測試，就可以返回所有測試，確保我們新添加的代碼沒有任何預期外的副作用。一旦所有測試運行完畢（包括我們為新功能編寫的測試），就可以對我們的代碼進行檢查，並有理有據地相信程序行為符合我們的期望——當然，前提是我們的測試是適當的。
比如，我們編寫了一個函數，該函數在特定的索引位置插入一個字符串，可以像下面這樣開始我們的TDD：
def insert_at（string, position, insert）:
“””Returns a copy of string with insert inserted at the position
string = “ABCDE”
result =[]
for i in range(-2, len(string) + 2):
… result.append(insert_at(string, i,“-”))
result[:5]
[‘ABC-DE’, ‘ABCD-E’, ‘-ABCDE’,’A-BCDE’, ‘AB-CDE’]
result[5:]
[‘ABC-DE’, ‘ABCD-E’, ‘ABCDE-‘, ‘ABCDE-‘]
“””
return string
對不返回任何參數的函數或方法（通常返回None）,我們通常賦予其由pass構成的一個suite,對那些返回值被試用的，我們或者返回一個常數（比如0）,或者某個不變的參數——這也是我們這裡所做的。（在更複雜的情況下，返回fake對象可能更有用一一對這樣的類，提供mock對象的第三方模塊是可用的。）
運行doctest時會失敗，並列出每個預期內的字符串（’ABCD-EF’、’ABCDE-F’ 等），及其實際獲取的字符串（所有的都是’ABCD-EF’）。一旦確定doctest是充分的和正確的，就可以編寫該函數的主體部分，在本例中只是簡單的return string[:position] + insert+string[position:]。（如果我們編寫的是 return string[:position] + insert,之後複製 string [:position]並將其粘貼在末尾以便減少一些輸入操作，那麼doctest會立即提示錯誤。）
Python的標準庫提供了兩個單元測試模塊，一個是doctest,這裡和前面都簡單地提到過，另一個是unittest。此外，還有一些可用於Python的第三方測試工具。其中最著名的兩個是nose (code.google.com/p/python-nose)與py.test (codespeak.net/py/dist/test/test.html), nose 致力於提供比標準的unittest 模塊更廣泛的功能，同時保持與該模塊的兼容性，py.test則採用了與unittest有些不同的方法，試圖儘可能消除樣板測試代碼。這兩個第三方模塊都支持測試發現，因此沒必要寫一個總體的測試程序——因為模塊將自己搜索測試程序。這使得測試整個代碼樹或某一部分 (比如那些已經起作用的模塊)變得很容易。那些對測試嚴重關切的人，在決定使用哪個測試工具之前，對這兩個(以及任何其他有吸引力的)第三方模塊進行研究都是值 得的。
創建doctest是直截了當的：我們在模塊中編寫測試、函數、類與方法的docstrings。 對於模塊，我們簡單地在末尾添加了 3行：
if __name__ ==”__main__”:
import doctest
doctest.testmod()
在程序內部使用doctest也是可能的。比如，blocks.py程序(其模塊在後面)有自己函數的doctest，但以如下代碼結尾：
if __name__== “__main__”:
main()
這裡簡單地調用了程序的main()函數，並且沒有執行程序的doctest。要實驗程序的 doctest,有兩種方法。一種是導入doctest模塊，之後運行程序—比如，在控制台中輸 入 python3 -m doctest blocks.py (在 Wndows 平台上，使用類似於 C:Python3 lpython.exe 這樣的形式替代python3)。如果所有測試運行良好，就沒有輸出，因此，我們可能寧願執行python3-m doctest blocks.py-v,因為這會列出每個執行的doctest,並在最後給出結果摘要。
另一種執行doctest的方法是使用unittest模塊創建單獨的測試程序。在概念上， unittest模塊是根據Java的JUnit單元測試庫進行建模的，並用於創建包含測試用例的測試套件。unittest模塊可以基於doctests創建測試用例，而不需要知道程序或模塊包含的任何事物——只要知道其包含doctest即可。因此，為給blocks.py程序製作一個測試套件，我們可以創建如下的簡單程序(將其稱為test_blocks.py)：
import doctest
import unittest
import blocks
suite = unittest.TestSuite()
suite.addTest(doctest.DocTestSuite(blocks))
runner = unittest.TextTestRunner()
print(runner.run(suite))
注意，如果釆用這種方法，程序的名稱上會有一個隱含的約束：程序名必須是有效的模塊名。因此，名為convert-incidents.py的程序的測試不能寫成這樣。因為import convert-incidents不是有效的，在Python標識符中，連接符是無效的（避開這一約束是可能的，但最簡單的解決方案是使用總是有效模塊名的程序文件名，比如，使用下劃線替換連接符）。這裡展示的結構（創建一個測試套件，添加一個或多個測試用例或測試套件，運行總體的測試套件，輸出結果）是典型的機遇unittest的測試。運行時，這一特定實例產生如下結果：
…
……………………………………………………………………………………………….
Ran 3 tests in 0.244s
OK
每次執行一個測試用例時，都會輸出一個句點（因此上面的輸出最前面有3個句點），之後是一行連接符，再之後是測試摘要（如果有任何一個測試失敗，就會有更多的輸出信息）。
如果我們嘗試將測試分離開（典型情況下是要測試的每個程序和模塊都有一個測試用例），就不要再使用doctests,而是直接使用unittest模塊的功能——尤其是我們習慣於使用JUnit方法進行測試時ounittest模塊會將測試分離於代碼——對大型項目（測試編寫人員與開發人員可能不一致）而言，這種方法特別有用。此外，unittest單元測試編寫為獨立的Python模塊，因此，不會像在docstring內部編寫測試用例時受到兼容性和明智性的限制。
unittest模塊定義了 4個關鍵概念。測試夾具是一個用於描述創建測試（以及用完之後將其清理）所必需的代碼的術語，典型實例是創建測試所用的一個輸入文件，最後刪除輸入文件與結果輸出文件。測試套件是一組測試用例的組合。測試用例是測試的基本單元—我們很快就會看到實例。測試運行者是執行一個或多個測試套件的對象。
典型情況下，測試套件是通過創建unittest.TestCase的子類實現的，其中每個名稱 以“test”開頭的方法都是一個測試用例。如果我們需要完成任何創建操作，就可以在一個名為setUp()的方法中實現；類似地，對任何清理操作，也可以實現一個名為 tearDown()的方法。在測試內部，有大量可供我們使用的unittest.TestCase方法，包括 assertTrue()、assertEqual()、assertAlmostEqual()（對於測試浮點數很有用）、assertRaises() 以及更多，還包括很多對應的逆方法，比如assertFalse()、assertNotEqual()、failIfEqual()、 failUnlessEqual ()等。
unittest模塊進行了很好的歸檔，並且提供了大量功能，但在這裡我們只是通過一 個非常簡單的測試套件來感受一下該模塊的使用。這裡將要使用的實例,該練習要求創建一個Atomic模塊，該模塊可以用作一 個上下文管理器，以確保或者所有改變都應用於某個列表、集合或字典，或者所有改變都不應用。作為解決方案提供的Atomic.py模塊使用30行代碼來實現Atomic類， 並提供了 100行左右的模塊doctest。這裡，我們將創建test_Atomic.py模塊，並使用 unittest測試替換doctest,以便可以刪除doctest。
在編寫測試模塊之前，我們需要思考都需要哪些測試。我們需要測試3種不同的數據類型：列表、集合與字典。對於列表，需要測試的是插入項、刪除項或修改項的值。對於集合，我們必須測試向其中添加或刪除一個項。對於字典，我們必須測試的是插入一個項、修改一個項的值、刪除一個項。此外，還必須要測試的是在失敗的情況下，不會有任何改變實際生效。
結構上看，測試不同數據類型實質上是一樣的，因此，我們將只為測試列表編寫測試用例，而將其他的留作練習。test_Atomic.py模塊必須導入unittest模塊與要進行測試的Atomic模塊。
創建unittest文件時，我們通常創建的是模塊而非程序。在每個模塊內部，我們定義一個或多個unittest.TestCase子類。比如，test_Atomic.py模塊中僅一個單獨的 unittest-TestCase子類，也就是TestAtomic (稍後將對其進行講解)，並以如下兩行結束:
if name == “__main__”:
unittest.main()
這兩行使得該模塊可以單獨運行。當然，該模塊也可以被導入並從其他測試程序中運行——如果這只是多個測試套件中的一個，這一點是有意義的。
如果想要從其他測試程序中運行test_Atomic.py模塊，那麼可以編寫一個與此類似的程序。我們習慣於使用unittest模塊執行doctests,比如：
import unittest
import test_Atomic
suite = unittest.TestLoader().loadTestsFromTestCase(test_Atomic.TestAtomic)
runner = unittest.TextTestRunner()
pnnt(runner.run(suite))
這裡，我們已經創建了一個單獨的套件，這是通過讓unittest模塊讀取test_Atomic 模塊實現的，並且使用其每一個test*()方法(本實例中是test_list_success()、test_list_fail()，稍後很快就會看到)作為測試用例。
我們現在將查看TestAtomic類的實現。對通常的子類(不包括unittest.TestCase 子類)，不怎麼常見的是，沒有必要實現初始化程序。在這一案例中，我們將需要建立 一個方法，但不需要清理方法，並且我們將實現兩個測試用例。
def setUp(self)：
self.original_list = list(range(10))
我們已經使用了 unittest.TestCase.setUp()方法來創建單獨的測試數據片段。
def test_list_succeed(self):
items = self.original_list[:]
with Atomic.Atomic(items) as atomic:
atomic.append(1999)
atomic.insert(2, -915)
del atomic[5]
atomic[4]= -782
atomic.insert(0, -9)
self.assertEqual(items,
[-9, 0, 1, -915, 2, -782, 5, 6, 7, 8, 9, 1999])
def test_list_fail(self):
items = self.original_list[:]
with self.assertRaises(AttributeError):
with Atomic.Atomic(items) as atomic:
atomic.append(1999)
atomic.insert(2, -915)
del atomic[5]
atomic[4] = -782
atomic.poop() # Typo
self.assertListEqual(items, self.original_list)
這裡，我們直接在測試方法中編寫了測試代碼，而不需要一個內部函數，也不再使用unittest.TestCase.assertRaised()作為上下文管理器(期望代碼產生AttributeError)。 最後我們也使用了 Python 3.1 的 unittest.TestCase.assertListEqual()方法。
正如我們已經看到的，Python的測試模塊易於使用，並且極為有用，在我們使用 TDD的情況下更是如此。它們還有比這裡展示的要多得多的大量功能與特徵——比如，跳過測試的能力，這有助於理解平台差別——並且這些都有很好的文檔支持。缺失的一個功能——但nose與py.test提供了——是測試發現，儘管這一特徵被期望在後續的Python版本(或許與Python 3.2—起)中出現。
性能剖析（Profiling）
如果程序運行很慢，或者消耗了比預期內要多得多的內存，那麼問題通常是選擇的算法或數據結構不合適，或者是以低效的方式進行實現。不管問題的原因是什麼， 最好的方法都是準確地找到問題發生的地方,而不只是檢査代碼並試圖對其進行優化。 隨機優化會導致引入bug,或者對程序中本來對程序整體性能並沒有實際影響的部分進行提速，而這並非解釋器耗費大部分時間的地方。
在深入討論profiling之前，注意一些易於學習和使用的Python程序設計習慣是有意義的，並且對提高程序性能不無裨益。這些技術都不是特定於某個Python版本的， 而是合理的Python程序設計風格。第一，在需要只讀序列時，最好使用元組而非列表； 第二，使用生成器，而不是創建大的元組和列表並在其上進行迭代處理；第三，盡量使用Python內置的數據結構 dicts、lists、tuples 而不實現自己的自定義結構，因為內置的數據結構都是經過了高度優化的；第四，從小字符串中產生大字符串時， 不要對小字符串進行連接，而是在列表中累積，最後將字符串列表結合成為一個單獨的字符串；第五，也是最後一點，如果某個對象(包括函數或方法)需要多次使用屬性進行訪問(比如訪問模塊中的某個函數)，或從某個數據結構中進行訪問，那麼較好的做法是創建並使用一個局部變量來訪問該對象，以便提供更快的訪問速度。
Python標準庫提供了兩個特別有用的模塊，可以輔助調査代碼的性能問題。一個是timeit模塊——該模塊可用於對一小段Python代碼進行計時，並可用於諸如對兩個或多個特定函數或方法的性能進行比較等場合。另一個是cProfile模塊，可用於profile 程序的性能——該模塊對調用計數與次數進行了詳細分解，以便發現性能瓶頸所在。
為了解timeit模塊，我們將查看一些小實例。假定有3個函數function_a()、 function_b()、function_c(), 3個函數執行同樣的計算，但分別使用不同的算法。如果將這些函數放於同一個模塊中(或分別導入)，就可以使用timeit模塊對其進行運行和比較。下面給出的是模塊最後使用的代碼：
if __name__ == “__main__”:
repeats = 1000
for function in (“function_a”, “function_b”, “function_c”):
t = timeit.Timer(“{0}(X, Y)”.format(function),”from __main__ import {0}, X, Y”.format(function))
sec = t.timeit(repeats) / repeats
print(“{function}() {sec:.6f} sec”.format(**locals()))
賦予timeit.Timer()構造子的第一個參數是我們想要執行並計時的代碼，其形式是字符串。這裡，該字符串是“function_a(X,Y)”；第二個參數是可選的，還是一個待執行的字符串，這一次是在待計時的代碼之前，以便提供一些建立工作。這裡，我們從 __main__ (即this)模塊導入了待測試的函數，還有兩個作為輸入數據傳入的變量(X 與Y),這兩個變量在該模塊中是作為全局變量提供的。我們也可以很輕易地像從其他模塊中導入數據一樣來進行導入操作。
調用timeit.Timer對象的timeit()方法時，首先將執行構造子的第二個參數(如果有)， 之後執行構造子的第一個參數並對其執行時間進行計時。timeit.Timer.timeit()方法的返回值是以秒計數的時間，類型是float。默認情況下，timeit()方法重複100萬次，並返回所 有這些執行的總秒數，但在這一特定案例中，只需要1000次反覆就可以給出有用的結果, 因此對重複計數次數進行了顯式指定。在對每個函數進行計時後，使用重複次數對總數進行除法操作，就得到了平均執行時間，並在控制台中打印出函數名與執行時間。
function_a() 0.001618 sec
function_b() 0.012786 sec
function_c() 0.003248 sec
在這一實例中，function_a()顯然是最快的——至少對於這裡使用的輸入數據而言。 在有些情況下一一比如輸入數據不同會對性能產生巨大影響——可能需要使用多組輸入數據對每個函數進行測試，以便覆蓋有代表性的測試用例，並對總執行時間或平均執行時間進行比較。
有時監控自己的代碼進行計時並不是很方便，因此timeit模塊提供了一種在命令行中對代碼執行時間進行計時的途徑。比如，要對MyModule.py模塊中的函數function_a()進行計時，可以在控制台中輸入如下命令：python3 -m timeit -n 1000 -s “from MyModule import function_a, X, Y” “function_a(X, Y)”(與通常所做的一樣，對 Windows 環境，我們必須使用類似於C:Python3lpython.exe這樣的內容來替換python3)。-m選項用於Python 解釋器，使其可以加載指定的模塊(這裡是timeit),其他選項則由timeit模塊進行處理。 -n選項指定了循環計數次數，-s選項指定了要建立，最後一個參數是要執行和計時的代碼。命令完成後，會向控制台中打印運行結果，比如：
1000 loops, best of 3: 1.41 msec per loop
之後我們可以輕易地對其他兩個函數進行計時，以便對其進行整體的比較。
cProfile模塊(或者profile模塊，這裡統稱為cProfile模塊)也可以用於比較函數 與方法的性能。與只是提供原始計時的timeit模塊不同的是，cProfile模塊精確地展示 了有什麼被調用以及每個調用耗費了多少時間。下面是用於比較與前面一樣的3個函數的代碼：
if __name__ == “__main__”:
for function in (“function_a”, “function_b”, “function_c”):
cProfile.run(“for i in ranged 1000): {0}(X, Y)”.format(function))
我們必須將重複的次數放置在要傳遞給cProfile.run()函數的代碼內部，但不需要做任何創建，因為模塊函數會使用內省來尋找需要使用的函數與變量。這裡沒有使用顯式的print()語句，因為默認情況下，cProfile.run()函數會在控制台中打印其輸出。下面給出的是所有函數的相關結果(有些無關行被省略，格式也進行了稍許調整，以便與頁面適應)：
1003 function calls in 1.661 CPU seconds
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.003 0.003 1.661 1.661 :1 ( )
1000 1.658 0.002 1.658 0.002 MyModule.py:21 (function_a)
1 0.000 0.000 1.661 1.661 {built-in method exec}
5132003 function calls in 22.700 CPU seconds
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.487 0.487 22.700 22.700 : 1 ( )
1000 0.011 0.000 22.213 0.022 MyModule.py:28(function_b)
5128000 7.048 0.000 7.048 0.000 MyModule.py:29( )
1000 0.00 50.000 0.005 0.000 {built-in method bisectjeft}
1 0.000 0.000 22.700 22.700 {built-in method exec}
1000 0.001 0.000 0.001 0.000 {built-in method len}
1000 15.149 0.015 22.196 0.022 {built-in method sorted}
5129003 function calls in 12.987 CPU seconds
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.205 0.205 12.987 12.987 :l ( )
1000 6.472 0.006 12.782 0.013 MyModule.py:36(function_c)
5128000 6.311 0.000 6.311 0.000 MyModule.py:37( )
1 0.000 0.000 12.987 12.987 {built-in method exec}
ncalls (“調用的次數”)列列出了對指定函數(在filename:lineno(function)中列出) 的調用次數。回想一下我們重複了 1000次調用，因此必須將這個次數記住。tottime (“總的時間”)列列出了某個函數中耗費的總時間，但是排除了函數調用的其他函數內部花費的時間。第一個percall列列出了對函數的每次調用的平均時間(tottime // ncalls)。 cumtime (“累積時間”)列出了在函數中耗費的時間，並且包含了函數調用的其他函數內部花費的時間。第二個percall列列出了對函數的每次調用的平均時間，包括其調用的函數耗費的時間。
這種輸出信息要比timeit模塊的原始計時信息富有啟發意義的多。我們立即可以發現，function_b()與function_c()使用了被調用5000次以上的生成器，使得它們的速度至少要比function_a()慢10倍以上。並且，function_b()調用了更多通常意義上的函數，包括調用內置的sorted()函數，這使得其幾乎比function_c()還要慢兩倍。當然,timeit() 模塊提供了足夠的信息來查看計時上存在的這些差別，但cProfile模塊允許我們了解為什麼會存在這些差別。正如timeit模塊允許對代碼進行計時而又不需要對其監控一樣，cProfile模塊也可以做到這一點。然而，從命令行使用cProfile模塊時，我們不能精確地指定要執行的 是什麼——而只是執行給定的程序或模塊，並報告所有這些的計時結果。需要使用的 命令行是python3 -m cProfile programOrModule.py,產生的輸出信息與前面看到的一 樣，下面給出的是輸出信息樣例，格式上進行了一些調整，並忽略了大多數行：
10272458 function calls (10272457 primitive calls) in 37.718 CPU secs
ncalls tottime percall cumtime percall filename:lineno(function)
10.000 0.000 37.718 37.718 :1 ( )
10.719 0.719 37.717 37.717 :12( )
1000 1.569 0.002 1.569 0.002 :20(function_a)
1000 0.011 0.000 22.560 0.023 :27(function_b)
5128000 7.078 0.000 7.078 0.000 :28( )
1000 6.510 0.007 12.825 0.013 :35(function_c)
5128000 6.316 0.000 6.316 0.000 :36( )
在cProfile術語學中，原始調用指的就是非遞歸的函數調用。
以這種方式使用cProfile模塊對於識別值得進一步研究的區域是有用的。比如，這裡 我們可以清晰地看到function_b()需要耗費更長的時間，但是我們怎樣獲取進一步的詳細資料？我們可以使用cProfile.run(“function_b()”)來替換對function_b()的調用。或者可以保存完全的profile數據並使用pstats模塊對其進行分析。要保存profile,就必須對命令行進行稍許修改:python3 -m cProfile -o profileDataFile programOrModule.py。 之後可以對 profile 數據進行分析，比如啟動IDLE,導入pstats模塊，賦予其已保存的profileDataFile,或者也可以在控制台中交互式地使用pstats。
下面給出的是一個非常短的控制台會話實例，為使其適合頁面展示，進行了適當調整，我們自己的輸入則以粗體展示：
$ python3 -m cProfile -o profile.dat MyModule.py
$ python3 -m pstats
Welcome to the profile statistics browser.
% read profile.dat
profile.dat% callers function_b
Random listing order was used
List reduced from 44 to 1 due to restriction
Function was called by…
ncalls tottime cumtime
:27(function_b) – 1000 0.011 22.251 :12( )
profile.dat% callees function_b
Random listing order was used
List reduced from 44 to 1 due to restriction
Function called…
ncalls tottime cumtime
:27(function_b)-
1000 0.005 0.005 built-in method bisectJeft
1000 0.001 0.001 built-in method len
1000 1 5.297 22.234 built-in method sorted
profile.dat% quit
輸入help可以獲取命令列表，help後面跟隨命令名可以獲取該命令的更多信息。比如, help stats將列出可以賦予stats命令的參數。還有其他一些可用的工具，可以提供profile數據的圖形化展示形式，比如 RunSnakeRun (), 該工具需要依賴於wxPython GUI庫。
使用timeit與cProfile模塊，我們可以識別出我們自己代碼中哪些區域會耗費超過預期的時間；使用cProfile模塊，還可以準確算岀時間消耗在哪裡。
以上內容部分摘自視頻課程 05後端編程Python-19調試、測試和性能調優(下) ，更多實操示例請參照視頻講解。跟着張員外講編程，學習更輕鬆，不花錢還能學習真本領。
python自動化測試框架有哪些
第一種：Robot Framework
作為最重要的python測試框架之一，Robot Framework主要被用在測試驅動類型的開發與驗收中。雖然由python開發而來，但是它也可以在基於.net的Ironpython和基於Java的Jython上運行。同時，作為一個python框架，Robot還能夠兼容諸如Windows、MacOS、Linux等平台。
在使用Robot Framework之前，需要先安裝python2.7.14及以上版本，在這裡推薦大家使用python3.6.4，以確保適當的註解能夠被添加到代碼段中，並能夠跟蹤程序的更改，同時，您還需要安裝python包管理器–pip。
第二種：Pytest
適用於多種軟件測試的Pytest，是另一個python類型的自動化測試框架。憑藉著開源和易學的特點，該工具經常被QA團體、開發團體、個人團體以及各種開源項目所使用。鑒於Pytest具有斷言重寫之類的實用功能，許多大型互聯網應用，如Dropbox、Mozilla，都已經從下面將要提到的unittest切換到了Pytest之上。
除了基本的python知識，用戶並不需要更多的技術儲備。另外，用戶只需要有一台帶有命令行界面的測試設備，並且安裝好了python包管理器以及可用於開發的IDE工具。
第三種：UnitTest/PyUnit
受到Junit啟發的UnitTest/PyUnit，也是一種標準化的針對單元測試的python類自動化測試框架。它的基類TestCase提供了各種斷言方法、以及所有清理和設置的例程。因此，TestCase子類中的每一種方法都是以test作為名詞點綴，以標識它們能夠被作為測試用例所運行。用戶可以使用load方法和TestSuite類來分組、並加載各種測試。當然，也可以通過聯合使用，來構建自定義的測試運行器。正如我們使用Junit去測試Selenium那樣，UnitTest也會用到unittest-sml-reporting，並能生成各種XML類型的報告。
第四種：Behave
行為驅動開發是一種基於敏捷軟件開發的方法。它能夠鼓勵開發人員、業務參與者和QA人員，三者之間的協作。python測試框架Behave允許團隊避開各種複雜的情況，去執行BDD測試。從本質上說該框架與SpecFlow和Cucumber相似，常被用於執行自動化測試。用戶可以通過簡單易讀的語言來編寫測試用例，並能夠在其執行期間粘貼到代碼之中。而且，那些被設定的行為規範與步驟，也可以被重用到其他的測試方案中。
第五種：Lettuce
Lettuce是另一種基於Cucumber和python的行為驅動類自動化工具。Lettuce主要專註於那些具有行為驅動開發特性的普通任務。它不但簡單易用，而且能夠使得整個測試過程更流暢、甚至更有趣。
您需要安裝帶有IDE的python2.7.14及以上版本。當然，您也可以使用pycharm或任何其他IDE工具。同時，您還需要安裝python包管理器。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/197927.html
微信掃一掃 
支付寶掃一掃 