Chuong3_CacKyThuatCoBanVeKiemSoatCLPM

(1)

ĐẢM BẢO VÀ KIỂ

ĐẢM BẢO VÀ KIỂ M SOÁTM SOÁT CHẤT LƯỢNG CHẤT LƯỢNG HCM HCM –– 10/2012 10/2012

Chương

3: 3:

Các kỹ thuật cơ bản về

kiểm soát chất lượng

phần mềm

(2)

Nội dung

 Những mô hình phát triểnNhững mô hình phát triển phầnphần mềmmềm   Mô hình tháp nướcMô hình tháp nước   MôMô hình chữ Vhình chữ V 

 Mô hình phátMô hình phát triểntriển lặplặp gia gia tăngtăng



CácCác mứcmức kiểmkiểm tra tra



(3)

Testing và Mô hình chu kỳ phát

triển phần mềm

 Testing:Testing:   Không tồn tại độc lậpKhông tồn tại độc lập 

 Liên quan đến những hoạt động trong quáLiên quan đến những hoạt động trong quá trình phát triển phần mềm

trình phát triển phần mềm



Đối với những mô hình phát triển phầnĐối với những mô hình phát triển phần mềm khác nhau => những giải pháp mềm khác nhau => những giải pháp

Testing khác nhau Testing khác nhau



Nó sẽ xác định Cái gì (What), Ở đâuNó sẽ xác định Cái gì (What), Ở đâu (Where) và Khi nào (When) của

(Where) và Khi nào (When) của kếkế hoạch test

(4)

Mô hình tháp nước

Giai

Giai đoạn xác định nhữngđoạn xác định những

“đòi hỏi” (“What”)

“đòi hỏi” (“What”) liên quanliên quan

đến chức năng và phi chức đến chức năng và phi chức năng mà hệ thống phần năng mà hệ thống phần mềm cần có mềm cần có Giai

Giai đoạn định ra “làm thếđoạn định ra “làm thế

nào” (“How”) để hệ thống

phần mềm đáp ứng những

“đòi hỏi” (“Wh

“đòi hỏi” (“What”) màat”) mà

khách hàng yêu cầu trong

SRS SRS

Giai

Giai đoạn hiện thực “làmđoạn hiện thực “làm

thế nào” (“How”) được chỉ

ra trong giai đoạn “Phân

tích hệ thống và thiết kế”

Giai

Giai đoạn này sẽđoạn này sẽ

tiến hành kiểm tiến hành kiểm thử mã (code) đã thử mã (code) đã được hiện thực được hiện thực Giai

Giai đoạn càiđoạn cài

đặt, cấu hình đặt, cấu hình và huấn luyện và huấn luyện khách hàng khách hàng

(5)

Mô hình tháp nước



Điểm yếu:Điểm yếu:



 Không thể quay lại bước trước đó; Nếu cóKhông thể quay lại bước trước đó; Nếu có bất kỳ lỗi trong giai đoạn thiết kế hay yêu

bất kỳ lỗi trong giai đoạn thiết kế hay yêu

cầu từ phía khách hàng thì sẽ gây

cầu từ phía khách hàng thì sẽ gây rất nhiềurất nhiều

rắc rối trong giai đoạn

rắc rối trong giai đoạn hiện thựchiện thực



 Rất khó có thể thực hiện nhiều vòng lặp choRất khó có thể thực hiện nhiều vòng lặp cho các giai đoạn

(6)

Mô hình chữ V



 ƒƒCácCác hoạt động hiệnhoạt động hiện

thực và các hoạt động

Testing

Testing được tách biệtđược tách biệt

nhưng độ quan trọng

là như nhau.



 Tinh thần chủ đạo củaTinh thần chủ đạo của

V-V-model là các hoạtmodel là các hoạt

động kiểm thử phải động kiểm thử phải được tiến hành song được tiến hành song song (theo khả năng song (theo khả năng có thể) ngay từ đầu có thể) ngay từ đầu chu trình cùng với các chu trình cùng với các hoạt động phát triển hoạt động phát triển 

 Chữ V minh họa cácChữ V minh họa các

khía cạnh của hoạt

động Verification và

Validation.

(7)

Kiểm chứng (Verification) và

chứng thực (Validation)



 KiểmKiểm chứngchứng (Verificati(Verification)on)



 Tìm cácTìm các lỗilỗi trong trong từngtừng giai giai đoạnđoạn 

 CácCác hành động để đảmhành động để đảm bảobảo cho phầncho phần

mềm được

mềm được hiệnhiện thực đúng theo mộtthực đúng theo một

chức

chức năng cụ thể nào đónăng cụ thể nào đó 

 ““ Are we building the Are we building the system rightsystem right?”?”



 Chứng thựcChứng thực (Validati(Validation)on)



 ‰‰TìmTìm lỗi trong hệ thống, phần chuyểnlỗi trong hệ thống, phần chuyển giao

giao 

 CácCác hành động để đảmhành động để đảm bảobảo cho phầncho phần

mềm được

mềm được xây xây dựng theo đúng yêudựng theo đúng yêu

cầu

cầu củacủa khách hàngkhách hàng 

 ““ Are we building the Are we building the right systemright system?? 

 V&V = V&V = VerificatiVerification and on and ValidatiValidationon



 MMụcục tiêu là phát tiêu là phát hiệnhiện và và sửasửa lỗilỗi PM, PM,

đánh giá tính

đánh giá tính dùngdùng đượcđược củacủa PM PM 

 Thứ tự thực hiệnThứ tự thực hiện: Verification ->: Verification -> Validation

(8)

Mô hình chữ V



Có rất nhiều biến thể của mô hình chữCó rất nhiều biến thể của mô hình chữ V, nhưng điểm chung là nó gồm có 4 V, nhưng điểm chung là nó gồm có 4 cấp độ Test

cấp độ Test



 Kiểm nghiệm bộ phận (Module testing):Kiểm nghiệm bộ phận (Module testing): kiểm nhiệm một bộ phận riêng rẽ

kiểm nhiệm một bộ phận riêng rẽ..



 Kiểm nghiệm tích hợp (Itegration testing):Kiểm nghiệm tích hợp (Itegration testing): tích hợp các bộ phận và hệ thống

tích hợp các bộ phận và hệ thống con.con.



 Kiểm nghiệm hệ thống (System testing):Kiểm nghiệm hệ thống (System testing): kiểm nghiệm toàn bộ hệ thống.

kiểm nghiệm toàn bộ hệ thống.



 Kiểm nghiệm chấp nhận (AcceptanceKiểm nghiệm chấp nhận (Acceptance testing): thực hiện bởi khách

(9)

Mô hình chữ V



 Điểm yếu:Điểm yếu:



 Rất là cứng rắn và ít Rất là cứng rắn và ít uyển chuyểnuyển chuyển

•

• Tất cả Tất cả những những yêu yêu cầu pcầu phải hải được được xác xác định định rõ ràrõ ràngng ngay từ bắt đầu dự án

ngay từ bắt đầu dự án •

• Không Không dễ ddễ dàng đàng để xử ể xử lý vlý việc tiệc thay hay đổi cđổi của yủa yêu cầêu cầuu

–

– Nếu có bắt kỳ thay đổi trong giai đoạn Nếu có bắt kỳ thay đổi trong giai đoạn giữa, không chỉgiữa, không chỉ

tài liệu về yêu cầu mà cả những tài liệu về Testing cũng

cần được cập nhật



 Không thể thực hiện nhiều vòng Không thể thực hiện nhiều vòng lặp cho cáclặp cho các

giai đoạn



 Người sử dụng không có cơ hội tham giaNgười sử dụng không có cơ hội tham gia

trong giai đoạn giữa từ thiết kế đển Testing

•

• Có thCó thể làm sảể làm sản phẩn phẩm cuốm cuối cùni cùng khôg không thng thỏa yêỏa yêuu cầu của khách hàng

(10)

Mô hình phát

triển

lặp

gia

tăng



 Trở thành cách tiếpTrở thành cách tiếp cậncận phổphổ

biến



 Việc chuyển giao sản phẩmViệc chuyển giao sản phẩm

được chia làm nhiều giai

được chia làm nhiều giai đoạn,đoạn,

giai đoạn sau sẽ nhiều

giai đoạn sau sẽ nhiều chứcchức

năng hơn giai đoạn trước



 Trong mỗi giai đoạn chuyểnTrong mỗi giai đoạn chuyển

giao sau cần 3 loại Test:



 Test chức năng mớiTest chức năng mới



 Test hồi quy (regression test)Test hồi quy (regression test)

chức năng cũ



 Test tích hợp (integration test)Test tích hợp (integration test)

chức năng mới và cũ chức năng mới và cũ   Sản phẩm sẽ được sớm đưaSản phẩm sẽ được sớm đưa vào thị trường vào thị trường 

 Prototype, ExtremePrototype, Extreme

Programming , RAD (Rapid Programming , RAD (Rapid Application Development ) , Application Development ) , RUP (Rational Unified Process) RUP (Rational Unified Process)

(11)

Kiểm tra trong mô hình vòng

đời

phần

mềm



Đặc tính chung củaĐặc tính chung của mộtmột kiểmkiểm thử tốtthử tốt::



 KiểmKiểm thửthử chocho mỗimỗi giai giai đọan/phần phát triểnđọan/phần phát triển



 Các mứcCác mức kiểmkiểm tra tra nhấnnhấn mạnhmạnh vàovào mụcmục tiêu tiêu

phối

phối hợp liên tục, không trùng lắphợp liên tục, không trùng lắp



 Phân tích,Phân tích, thiếtthiết kế bắt đầukế bắt đầu sớmsớm,, ngănngăn

ngừa

ngừa lỗilỗi

10/15/20

(12)

Phân loại kiểm nghiệm

(13)

Nội dung

 Những mô hình phát triểnNhững mô hình phát triển phầnphần mềmmềm   Mô hình tháp nướcMô hình tháp nước   Mô hình chữ VMô hình chữ V 

 Mô hình phát triểnMô hình phát triển lặplặp gia gia tăngtăng



CácCác mứcmức kiểmkiểm tra tra



(14)

Kiểm tra thành phần/đơn

vị

Component (Unit) Test



Kiểm thử đơn vị tập trung vào việc xácKiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết kế minh trên đơn vị nhỏ nhất của thiết kế phần mềm –

phần mềm – thành phần phần mềm,thành phần phần mềm, module hoặc lớp

module hoặc lớp



NgườiNgười tiếntiến hành:hành: lậplập trình viên trình viên



Sử dụng các stubs vàSử dụng các stubs và driversdrivers



TThường hướng hộp trắng, và các bướchường hướng hộp trắng, và các bước có thể được thực hiện song

có thể được thực hiện song song trênsong trên nhiều module.

(15)

Kiểm tra thành phần/đơn

vị

Component (Unit) Test



 Giao diện (Interface):Giao diện (Interface): 

 Đảm bảo thông tin vào, ra Đảm bảo thông tin vào, ra

hợp lệ của đơn vị chương

trình

trình 

 Cấu trúc dữ liệu:Cấu trúc dữ liệu: 

 LàLà nguồn lỗi phổ biếnnguồn lỗi phổ biến 

 Được kiểm tra để đảm bảo Được kiểm tra để đảm bảo

rằng dữ liệu được lưu trữ rằng dữ liệu được lưu trữ tạm thời đảm bảo tính tạm thời đảm bảo tính nguyên vẹn trong tất cả các nguyên vẹn trong tất cả các

bước thực hiện của thuật

toán



 Điều kiệnĐiều kiện biênbiên 

 Đường điĐường đi độc lậpđộc lập:: 

 Đảm bảo Đảm bảo rằng rằng tất cả các câutất cả các câu

lệnh

lệnh trong trong module module đã đã đượcđược

thực

thực hiện hiện ít nhít nhất một ất một lầnlần



 XửXử lýlý lỗilỗi 

 Một thiết kế tốt sẽ cho biếtMột thiết kế tốt sẽ cho biết

các điề

các điều kiện u kiện lỗi đưlỗi được biếợc biếtt

trước



 VàVà các các đường đường dẫn dẫn xử xử lý lý lỗilỗi

được

được thiết thiết lập lập để để gửi gửi lại lại hoặchoặc

kết thúc xử lý dễ

kết thúc xử lý dễ dàngdàng khi mộtkhi một

lỗi xuất hiện

(16)

Demo

(17)

Stubs & Drivers



 Driver là module gọi thực thiDriver là module gọi thực thi

làm cho module cần kiểm tra

hoạt động, nó giả lập

hoạt động, nó giả lập cáccác

module khác sẽ sử dụng

module này. Các tập dữ liệu

chia sẻ mà các module khác

thiết lập trong thực tế cũng

được thiết lập ở

được thiết lập ở drivedrive



 StubStub là module giả lập cáclà module giả lập các

module được

module được modulemodule đangđang

kiểm tra sử dụng

(18)

Kiểm tra tích hợp

Intergratio

Intergration n TestTest



KiểmKiểm thử tích hợp cácthử tích hợp các ModuleModule



NgườiNgười tiếntiến hành:hành: lập trìnhlập trình viên viên, người, người thiết

thiết kế kế ...



Mục đíchMục đích::



 KKiểmiểm tra giaotra giao diệndiện giữagiữa các Modulecác Module



 KKiểmiểm tra tính tra tính đúng đắnđúng đắn so so với đặcvới đặc tảtả



 KKiểmiểm tra tínhtra tính hiệuhiệu quảquả



(19)

Kiểm tra tích hợp

Intergratio



Câu hỏi được đặtCâu hỏi được đặt ra ra



 NênNên kiểmkiểm thử chương trình bằng cáchthử chương trình bằng cách

kiểm

kiểm thửthử từng module độctừng module độc lậplập rồirồi kếtkết hợphợp

các

các module thành chương trìnhmodule thành chương trình

•

• Cách tiCách tiếpếp cậncận này này gọigọi là là kiểmkiểm thử/tích hợpthử/tích hợp không gia

không gia tăng hoặctăng hoặc còn còn gọi là biggọi là big-bang;-bang;



 HayHay kếtkết hợp thêm các module “mới” vớihợp thêm các module “mới” với

các

các module đã đượcmodule đã được kiểmkiểm thử trước đó.thử trước đó.

•

• „Cách„Cách tiếptiếp cậncận sau đượcsau được biếtbiết như là kiểmnhư là kiểm

thử/tích hợp

(20)

Top Down testing

  Các mô đun mứcCác mô đun mức trên trên được được kiểmkiểm thử trướcthử trước   CácCác mô đunmô đun mứcmức thấpthấp được

được tạmtạm thời phát triểnthời phát triển với với các các chứcchức năng hạnnăng hạn chế chế và và được thay bằngđược thay bằng bằng bằng các môcác mô đun tạmđun tạm thời(stub

thời(stub function)function)



 Có cùng tênCó cùng tên vớivới mô mô đunđun

thật



 CóCó cùng giao diệncùng giao diện



 TTrả lạirả lại kếtkết quả vớiquả với mộtmột

hoặc

hoặc mộtmột vài vài bộ dữ liệubộ dữ liệu

chuẩn chuẩn a a b b cc d e f g d e f g h h i i j j k k l l mm n n oo a a b b cc d e f g d e f g h h i i jj

(21)

Top down testing



 Ưu điểmƯu điểm::



 Phát hiệnPhát hiện sớmsớm các các lỗilỗi thiếtthiết kế (lỗikế (lỗi cấucấu trúc) trúc) •

• KKiểmiểm thử trên xuống kếtthử trên xuống kết hợphợp vớivới phátphát triểntriển trên trên

xuống sẽ giúp phát hiện

xuống sẽ giúp phát hiện sớmsớm các các lỗilỗi thiếtthiết kế vàkế và làm làm

giảm giá thành sửa đổi giảm giá thành sửa đổi



 Có sớm phiên bảnCó sớm phiên bản thựcthực hiện đượchiện được

•

• PPhiên bảnhiên bản thựcthực hiệnhiện vớivới các các chứcchức năngnăng chính cóchính có

sớm sớm • • CóCó thể thẩm định tính dùng đượcthể thẩm định tính dùng được củacủa sảnsản phẩmphẩm sớm sớm   Nhược điểmNhược điểm:: 

 NhiềuNhiều mô mô đun cấpđun cấp thấpthấp rất khó mô phỏngrất khó mô phỏng



 Thao tácThao tác vớivới cấucấu trúc trúc dữ liệudữ liệu phứcphức tạptạp



(22)

Bottom Up Testing

  Các mô đun cấpCác mô đun cấp thấp đượcthấp được kiểm kiểm thử trướcthử trước 

 Mô đun mứcMô đun mức trên trên được thayđược thay

thế bằng mô đun

thế bằng mô đun điềuđiều khiểnkhiển

(test driver), có

(test driver), có chứcchức năngnăng



 GGọiọi mô mô đun cầnđun cần thử nghiệmthử nghiệm 

 TTruyềnruyền dữ liệudữ liệu 

 HHiểniển thị kếtthị kết quảquả 

 Thay thế dầnThay thế dần các driver các driver



 Có thể cũng cần Stub trong vàiCó thể cũng cần Stub trong vài

trường hợp



 Thông thường người ta khôngThông thường người ta không

thuần

thuần túy túy kiểmkiểm thử thử tấttất cả cáccả các

mô đun ở tầng dưới cùng mà

nhóm các

nhóm các mô đun này thànhmô đun này thành

các nhóm chức

các nhóm chức năng, tích hợpnăng, tích hợp

và

và kiểmkiểm thử chúng theo từngthử chúng theo từng

nhóm nhóm a a b b cc e f g e f g k k l l mm d d ii n n oo h h jj b b d d ii n n oo h h jj

(23)

Bottom Up Testing



Ưu điểmƯu điểm



 TránhTránh xây dựng các mô đun tạmxây dựng các mô đun tạm thời(stubthời(stub))

phức

phức tạptạp



 Tránh sinh cácTránh sinh các kếtkết quảquả nhânnhân tạo(tạo(VD:VD: nhậpnhập

từ

từ bàn phím bàn phím, click chuột…, click chuột…))



 ThuậnThuận tiệntiện cho phátcho phát triểntriển các mô các mô đun đểđun để

dùng lại



Nhược điểmNhược điểm



 ChậmChậm phátphát hiệnhiện các các lỗilỗi kiếnkiến trúc trúc



(24)

Top down vs. Bottom up



MỗiMỗi chiếnchiến lược đềulược đều có ưucó ưu nhược điểmnhược điểm riêng

riêng



ChiếnChiến lượclược kiểmkiểm thử phải phù hợpthử phải phù hợp vớivới chiến

chiến lược phát triểnlược phát triển



 − phát triển top− phát triển top-down = top-down testing-down = top-down testing



 − phát triển bottom− phát triển bottom-up = bottom-up testing-up = bottom-up testing



Có thể phốiCó thể phối hợphợp các các chiếnchiến lượclược::



(25)

Kiểm tra tích hợp

Intergratio



 NhiềuNhiều hơnhơn 1 mức1 mức kiểmkiểm tra tíchtra tích hợphợp trong trong

dự dự ánán   ‰‰TíchTích hợp thành phần:hợp thành phần: • • Tìm lỗiTìm lỗi tương tác các thành phầntương tác các thành phần   Tích hợpTích hợp hệ thống:hệ thống: •

• Tìm lỗiTìm lỗi tương tác trên toàn hệ thốngtương tác trên toàn hệ thống



 PhứcPhức tạptạp



 NhiềuNhiều tổ chứctổ chức



 TiếnTiến trìnhtrình nghiệpnghiệp vụvụ



 Độ tương thích Độ tương thích Hardware/systemHardware/system



 Kiểm tra tích hợp nên có kế hoạch rõ ràngKiểm tra tích hợp nên có kế hoạch rõ ràng

trong giai đoạn thiết kế hệ thống trong giai đoạn thiết kế hệ thống 

(26)

Kiểm tra hệ thống

System Test



Bao gồm một loạt các kiểm nghiệmBao gồm một loạt các kiểm nghiệm

nhằm xác minh toàn bộ các thành phần nhằm xác minh toàn bộ các thành phần của hệ thống được tích hợp một cách của hệ thống được tích hợp một cách đúng đắn đúng đắn.. 

Mục đích của kiểm nghiệm hệ thống làMục đích của kiểm nghiệm hệ thống là để đảm bảo toàn bộ hệ thống hoạt

để đảm bảo toàn bộ hệ thống hoạt động như ý mà

động như ý mà khách hàng mongkhách hàng mong muốn

muốn..



Môi trường Test càng giống môi trườngMôi trường Test càng giống môi trường thực càng nhiều càng tốt để giảm thiếu thực càng nhiều càng tốt để giảm thiếu những rủi ro hay hay những lỗi do sự những rủi ro hay hay những lỗi do sự khác biệt môi trường gây ra

(27)

Kiểm tra hệ thống

System Test



 BaoBao gồm các loại kiểm nghiệmgồm các loại kiểm nghiệm sau:sau:



 Kiểm nghiệm chức năng (Function testingKiểm nghiệm chức năng (Function testing))



 Kiểm nghiệmKiểm nghiệm phiphi chức năngchức năng (Non-Function(Non-Function testing)

testing) •

• KiểKiểm nghim nghiệm hiệệm hiệu suấu suất (Pert (Perfomfomanance testce testinging))

•

• KiểKiểm nghm nghiệm miệm mức độ đức độ đáp ứnáp ứng (stg (stresress tests testinging))

•

• KiểKiểm nghm nghiệm hiệm hồi phồi phục (rục (recoecoververy testy testinging))

•

• KiểKiểm nghm nghiệm iệm quá quá tải (tải (oveoverlorload tead testistingng))

•

• KiểKiểm nghim nghiệm càệm cài đặt (Ii đặt (Instnstallallatiation teon testistingng))

• • ……



(28)

Kiểm tra chấp nhận

Acceptance Test



CóCó sự tham gia của khách hàng/ngườisự tham gia của khách hàng/người sử sử d dụngụng  DùngDùng kiểmkiểm thử chứcthử chức năngnăng  Mục đíchMục đích:: thẩm định (validation) phầnthẩm định (validation) phần mềm

mềm để xác định cácđể xác định các sai sót, sai sót, thiếuthiếu sót sót so với

so với yêu yêu cầucầu ngườingười dùng dùng



Sử dụng các dữ liệuSử dụng các dữ liệu thựcthực do user cungdo user cung cấp

(29)

Kiểm tra chấp nhận

Acceptance Test



 KiểmKiểm tra tra chấpchấp nhậnnhận vớivới người sử dụngngười sử dụng::



 NgườiNgười sử dụng nghiệpsử dụng nghiệp vụvụ xácxác nhậnnhận mứcmức phùphù hợphợp cho

cho chứcchức năngnăng



 KiểmKiểm tra tác tra tác vụvụ (Operational testing):(Operational testing):



 ChấpChấp nhậnnhận bởibởi ngườingười quảnquản trịtrị



 Hợp đồng và kiểmHợp đồng và kiểm tra quy tra quy tắctắc (regulation (regulation

testing): testing):



 KiểmKiểm chứngchứng xácxác nhậnnhận hợphợp lệ theo hợp đồng.lệ theo hợp đồng.



 Kiểm tra Alpha, Beta, và lĩnh vực(fieldKiểm tra Alpha, Beta, và lĩnh vực(field

testing): testing):



 KiểmKiểm thử và xây dựng tin cậythử và xây dựng tin cậy bởibởi các khách hàngcác khách hàng

đã

đã có có hay tiềmhay tiềm năngnăng



 KiểmKiểm thử Beta và lĩnh vực đượcthử Beta và lĩnh vực được thựcthực hiệnhiện trongtrong

môi trường thực

(30)

Nội dung

 Những mô hình phát triểnNhững mô hình phát triển phầnphần mềmmềm   Mô hình tháp nướcMô hình tháp nước   Mô hình chữ VMô hình chữ V 

 Mô hình phát triểnMô hình phát triển lặplặp gia gia tăngtăng



Các mứcCác mức kiểmkiểm tra tra



(31)

Các

kiểu kiểm thử

Testing Type



Kiểm thử ChứcKiểm thử Chức năngnăng - Function Test - Function Test



Kiểm thử Phi chứcKiểm thử Phi chức năngnăng - Non- - Non-Functional Test

Functional Test



(32)

Kiểm thử chức

năng

Function Test Function Test   Chức năng là những gì mà chương trình có thể đápChức năng là những gì mà chương trình có thể đáp

ứng được mô tả rõ ràng trong các tài liệu:



 Trường hợp sử dụng (Use case)Trường hợp sử dụng (Use case)



 Yêu cầu chức năngYêu cầu chức năng



 Có thể thực hiện tại tất cả các cấp độ TestCó thể thực hiện tại tất cả các cấp độ Test



 Không quan tâm đến các Không quan tâm đến các khía cạnh khác như giaokhía cạnh khác như giao

diện đẹp, xấu, dễ sử dụng hay không, thời gian xử

lý nhanh hay chậm,...



 Test chức năng có thể được hoàn thành tử 2Test chức năng có thể được hoàn thành tử 2

hướng:



 Dựa trên yêu cầu (Requirement)Dựa trên yêu cầu (Requirement)

•

• Bản mBản mô tả tóô tả tóm lượm lược nhữc những chng chức năức năng cầng cần Tesn Test hay t hay khôkhôngng

cần Test



 Dựa trên quy trình nghiệp vụDựa trên quy trình nghiệp vụ

•

• DựDựa tra trên nên nhữhững nng nghghiệp việp vụ hằụ hằng nng ngàgàyy

•

(33)

Kiểm tra Phi chức năng

Non-Function

Non-Functional al TestTest

 Test những chức năng làm hệ thống tốtTest những chức năng làm hệ thống tốt hơn, không có những chức năng này hệ hơn, không có những chức năng này hệ thống vẫn hoạt động được nhưng rất thống vẫn hoạt động được nhưng rất khó được sự chấp nhận của người sử khó được sự chấp nhận của người sử dụng dụng 

Có thể thực hiện tại tất cả các cấp độCó thể thực hiện tại tất cả các cấp độ Test

Test



ISO/IEC 9126,ISO/IEC 9126, 2001 đã định nghĩa rất2001 đã định nghĩa rất nhiều tiêu chí chất lượng

nhiều tiêu chí chất lượng về Phi chứcvề Phi chức năng

(34)

ISO/IEC 9126, 2001

  Tính năng (FunctionalityTính năng (Functionality))   Tính phù hợp (Suitability)Tính phù hợp (Suitability)   Tính chính xác (Accuracy)Tính chính xác (Accuracy)   Khả năng tương tácKhả năng tương tác (Interoperability) (Interoperability) 

 Tính bảo mật/an toàn (Security)Tính bảo mật/an toàn (Security)



 Tính tin cậy (ReabilityTính tin cậy (Reability)) 

 Tính hoàn thiện (Maturity)Tính hoàn thiện (Maturity)



 Khả năng chịu lỗi (Fault tolerant)Khả năng chịu lỗi (Fault tolerant)



 Khả năng phục hồi Khả năng phục hồi (Recoverability(Recoverability)) 

 Tính khả dụng Tính khả dụng (Usability(Usability)) 

 Dễ hiểu Dễ hiểu (Understandabil(Understandability)ity)

  Dễ học Dễ học (Learnability(Learnability))   Khả năng vận hành Khả năng vận hành (Operability)(Operability)   Tính hấp dẫn (Attractiveness)Tính hấp dẫn (Attractiveness) 

 Tính hiệu quả (EfficiencyTính hiệu quả (Efficiency))



 Thời gian xử lý (Time behavior)Thời gian xử lý (Time behavior) 

 Sử dụng tài nguyên (UtilizationSử dụng tài nguyên (Utilization))

  Khả năng bảo trìKhả năng bảo trì (Maintainability) (Maintainability)   Khả năng phân tích (Analysability)Khả năng phân tích (Analysability) 

 Khả năng thay đổi đượcKhả năng thay đổi được

(Changeability) (Changeability)



 Tính ổn định Tính ổn định (Stability)(Stability) 

 Khả năng kiểm thử được (TestabilityKhả năng kiểm thử được (Testability))



 Tính khả chuyển (PortabilityTính khả chuyển (Portability))



 Khả năng thích nghi (Adaptability)Khả năng thích nghi (Adaptability) 

 Khả năng cài đặt (Installability)Khả năng cài đặt (Installability) 

 Khả năng chung sống (CoKhả năng chung sống (Co-existence)-existence)



 Khả năng thay thế đượcKhả năng thay thế được

(Replaceability) (Replaceability)

(35)

Kiểm thử hồi quy

Regression Test



 Mỗi lần một module mới được thêm vàoMỗi lần một module mới được thêm vào

như một phần của kiểm thử

như một phần của kiểm thử tích hợp, phầntích hợp, phần mềm sẽ thay đổi.

mềm sẽ thay đổi. 

 CácCác đường dẫn luồng dữ liệu mới được thiếtđường dẫn luồng dữ liệu mới được thiết

lập, vào ra I/O mới có thể xuất hiện, và logic

điều khiển mới được yêu cầu.



 CácCác thay đổi có thể gâythay đổi có thể gây nênnên các vấn đề vớicác vấn đề với

các chức năng đã làm việc hoàn hảo trước

đó

đó..



 KKiểm thử hồi qui là việc thực hiện iểm thử hồi qui là việc thực hiện lại mộtlại một

số tập con

số tập con cáccác kiểm thử đã được kiểm thử đã được thực hiệnthực hiện

trước đó để đảm bảo rằng các thay

trước đó để đảm bảo rằng các thay đổiđổi

không sinh ra

không sinh ra những hiệu ứng không mongnhững hiệu ứng không mong

muốn muốn

(36)

Kiểm thử hồi quy

Regression Test



 Kiểm thử hồi quy có thể thực hiện thủ công,Kiểm thử hồi quy có thể thực hiện thủ công,

bằng cách thực hiện lại tập con tất cả

bằng cách thực hiện lại tập con tất cả cáccác

trường

trường hợp hợp kiểm kiểm thử thử hoặc hoặc sử sử dụng dụng các các côngcông

cụ

cụ thu thu phát phát tự tự độngđộng



 Bộ Bộ kiểm kiểm thử thử hồi hồi quy quy (tập (tập con con các các kiểmkiểm

thử sẽ được thực thi) gồm ba lớp các

trường

trường hợp hợp kiểm kiểm thử thử kháckhác nhau:nhau:



 Một mẫu đại diện của các kiểm thử sẽ thựcMột mẫu đại diện của các kiểm thử sẽ thực

hiện tất cả các chức năng của phần mềm



 Các trường hợp kiểm thử bổ Các trường hợp kiểm thử bổ sung tập trung vàosung tập trung vào

các chức năng phần mềm có khả năng bị tác

động khi có sự thay đổi



 CácCác kiểm thử tập trung vào các kiểm thử tập trung vào các thành phần phầnthành phần phần

mềm vừa bị thay đổi

(37)

ĐẢM BẢO VÀ KIỂ

ĐẢM BẢO VÀ KIỂ M SOÁTM SOÁT CHẤT LƯỢNG

(38)

Chương tiếp theo



Kỹ thuậtKỹ thuật tĩnhtĩnh - Rà soát và quá trình- Rà soát và quá trình kiểm

kiểm tra tra



Quy trình rà soát chươngQuy trình rà soát chương trìnhtrình



Các kỹ thuật kiểm tra tĩnhCác kỹ thuật kiểm tra tĩnh

