Bài giảng Kiểm thử phần mềm - Chương 1: Tổng quát về kiểm thử phần mềm - Nguyễn Văn Hiệp

 Chương 1
 Tổng quát về kiểm thử phần mềm
1.1 Qui trình phát triển phần mềm RUP 
 P h a s e s
C o r e W o r k f l o w s 
 I n ce p ti on Elaboration Construction T r a n s ition
 Requirements 
 An iteration i n th e 
 elaboration p h a s e 
 Analysis 
 Design 
 Implementation 
 Test 
 Preliminary iter. iter. iter. iter. iter. iter. iter.
 Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
 Iter a tio n s 
 Chu kỳ phần mềm ₫ược tính từ lúc có yêu cầu (mới hoặc nâng 
cấp) ₫ến lúc phần mềm ₫áp ứng ₫úng yêu cầu ₫ược phân phối. 
 Trong mỗi chu kỳ, người ta tiến hành nhiều công ₫oạn : khởi 
₫ộng, chi tiết hóa, hiện thực và chuyển giao. 
 Mỗi công ₫oạn thường ₫ược thực hiện theo cơ chế lặp nhiều 
lần ₫ể kết quả ngày càng hoàn hảo hơn. 
 Trong từng bước lặp, chúng ta thường thực hiện nhiều 
workflows ₫ồng thời (₫ể tận dụng nguồn nhân lực hiệu quả nhất) : 
nắm bắt yêu cầu, phân tích chức năng, thiết kế, hiện thực và kiểm 
thử. 
 Sau mỗi lần lặp thực hiện 1 công việc nào ₫ó, ta phải tạo ra 
kết quả (artifacts), kết quả của bước/công việc này là dữ liệu ₫ầu 
vào của bước/công việc khác. Nếu thông tin không tốt sẽ ảnh 
hưởng nghiêm trọng ₫ến kết quả của các bước/hoạt ₫ộng sau ₫ó. 
 Một số vấn ₫ề thường gặp trong phát triển phần mềm : 
 ƒ tính toán không ₫úng, hiệu chỉnh sai dữ liệu. 
 ƒ trộn dữ liệu không ₫úng. 
 ƒ Tìm kiếm dữ liệu sai yêu cầu. 
 ƒ Xử lý sai mối quan hệ giữa các dữ liệu. 
 ƒ Coding/hiện thực sai các qui luật nghiệp vụ. 
 ƒ Hiệu suất của phần mềm còn thấp. 
 ƒ Kết quả hoặc hiệu suất phần mềm không tin cậy. 
 ƒ Hỗ trợ chưa ₫ủ các nhu cầu nghiệp vụ. 
 ƒ Giao tiếp với hệ thống khác chưa ₫úng hay chưa ₫ủ. 
 ƒ Kiểm soát an ninh phần mềm chưa ₫ủ. 
1.2 Vài ₫ịnh nghĩa về kiểm thử phần mềm 
 ƒ Kiểm thử phần mềm là qui trình chứng minh phần mềm 
 không có lỗi. 
 ƒ Mục ₫ích của kiểm thử phần mềm là chỉ ra rằng phần 
 mềm thực hiện ₫úng các chức năng mong muốn. 
 ƒ Kiểm thử phần mềm là qui trình thiết lập sự tin tưởng về 
 việc phần mềm hay hệ thống thực hiện ₫ược ₫iều mà nó 
 hỗ trợ. 
 ƒ Kiểm thử phần mềm là qui trình thi hành phần mềm với ý 
 ₫ịnh tìm kiếm các lỗi của nó. 
 ƒ Kiểm thử phần mềm ₫ược xem là qui trình cố gắng tìm 
 kiếm các lỗi của phần mềm theo tinh thần "hủy diệt". 
 Các mục tiêu chính của kiểm thử phần mềm : 
 ƒ Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử 
 xác ₫ịnh trước. 
 ƒ Chứng minh rằng sản phẩm phần mềm phù hợp với các 
 ₫ặc tả yêu cầu của nó. 
 ƒ Xác thực chất lượng kiểm thử phần mềm ₫ã dùng chi phí 
 và nỗ lực tối thiểu. 
 ƒ Tạo các testcase chất lượng cao, thực hiện kiểm thử hiệu 
 quả và tạo ra các báo cáo vấn ₫ề ₫úng và hữu dụng. 
 Kiểm thử phần mềm là 1 thành phần trong lĩnh vực rộng hơn, 
₫ó là Verification & Validation (V &V), ta tạm dịch là Thanh kiểm 
tra và Kiểm ₫ịnh phần mềm. 
 Thanh kiểm tra phần mềm là qui trình xác ₫ịnh xem sản phẩm 
của 1 công ₫oạn trong qui trình phát triền phần mềm có thoả mãn 
các yêu cầu ₫ặt ra trong công ₫oạn trước không (Ta có ₫ang xây 
dựng ₫úng ₫ắn sản phẩm không ?) 
 Thanh kiểm tra phần mềm thường là hoạt ₫ộng kỹ thuật vì nó 
dùng các kiến thức về các artifacts, các yêu cầu, các ₫ặc tả rời rạc 
của phần mềm. 
 Các hoạt ₫ộng Thanh kiểm tra phần mềm bao gồm kiểm thử 
(testing) và xem lại (reviews). 
 Kiểm ₫ịnh phần mềm là qui trình ₫ánh giá phần mềm ở cuối 
chu kỳ phát triển ₫ể ₫ảm bảo sự bằng lòng sử dụng của khách 
hàng (Ta có xây dựng phần mềm ₫úng theo yêu cầu khách hàng 
?). 
 Các hoạt ₫ộng kiểm ₫ịnh ₫ược dùng ₫ể ₫ánh giá xem các tính 
chất ₫ược hiện thực trong phần mềm có thỏa mãn các yêu cầu 
khách hàng và có thể theo dõi với các yêu cầu khách hàng không 
? 
 Kiểm ₫ịnh phần mềm thường phụ thuộc vào kiến thức của lĩnh 
vực mà phần mềm xử lý. 
1.3 Kiểm thử : các worker và qui trình 
 Test Component Integration System 
 Engineer Engineer Tester Tester 
 chịutrach nhimv̀ chịutrach nhimv̀
 chịutrach nhimv̀
 Test 
 Test Model Test Plan Test case Test Test Test 
 Evaluation defect 
 Procedure Component 
 Kỹ sư kiểm thử : 
 ƒ người chuyên về IT, chịu trách nhiệm về nhiều hoạt 
 ₫ộng kỹ thuật liên quan ₫ến kiểm thử. 
 ƒ ₫ịnh nghĩa các testcase, viết các ₫ặc tả và thủ tục 
 kiểm thử. 
 ƒ phân tích kết quả, báo cáo kết quả cho các người phát 
 triển và quản lý biết. 
 ƒ ... 
 Người quản lý kiểm thử : 
 ƒ Thiết lập chiến lược và qui trình kiểm thử, tương tác với 
 các người quản lý về các hoạt ₫ộng khác trong project, 
 giúp ₫ỡ kỹ sư kiểm thử thực hiện công việc của họ. 
 Plan test Evaluate test
 Test Engineer Design test
 Perform Integration 
 Integration tester Test 
 Perform System 
 System 
 Test 
 Tester 
 Component Implement Test
 Engineer
Tự ₫ộng 1 số hoạt ₫ộng kiểm thử 
 Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian. 
Trong 1 số dự án, kiểm thử phần mềm tiêu hao trên 50% tổng giá 
phát triển phần mềm. Nếu cần ứng dụng an toàn hơn, chi phí kiểm 
thử còn cao hơn nữa. 
 Do ₫ó 1 trong các mục tiêu của kiểm thử là tự ₫ộng hóa nhiều 
như có thể, nhờ ₫ó mà giảm thiểu chi phí rất nhiều, tối thiểu hóa 
các lỗi do người gây ra, ₫ặc biệt giúp việc kiểm thử hồi qui dễ dàng 
và nhanh chóng hơn. 
 Tự ₫ộng hóa việc kiểm thử là dùng phần mềm ₫iều khiển việc 
thi hành kiểm thử, so sánh kết quả có ₫ược với kết quả kỳ vọng, 
thiết lập các ₫iều kiện ₫ầu vào, các kiểm soát kiểm thử và các 
chức năng báo cáo kết quả... 
 Thí dụ các tiện ích phục vụ tự ₫ộng kiểm thử như : Stress Test, 
Selenium, TestComplete, IBM Rational Functional Tester. 
1.4 Các mức ₫ộ kiểm thử phần mềm 
 ƒ Kiểm thử ₫ơn vị (Unit Testing) : kiểm thử sự hiện thực chi 
 tiết của từng ₫ơn vị nhỏ (hàm, class,...) có hoạt ₫ộng ₫úng 
 không ? 
 ƒ Kiểm thử module (Module Testing) : kiểm thử các dịch vụ 
 của module có phù hợp với ₫ặc tả của module ₫ó không ? 
 ƒ Kiểm thử tích hợp (Integration Testing) : kiểm thử xem từng 
 phân hệ của phần mềm có ₫ảm bảo với ₫ặc tả thiết kế của 
 phân hệ ₫ó không ? 
 ƒ Kiểm thử hệ thống (System Testing) : kiểm thử các yêu 
 cầu không chức năng của phần mềm như hiệu suất, bảo 
 mật, làm việc trong môi trường căng thẳng,... 
 ƒ Kiểm thử ₫ộ chấp nhận của người dùng (Acceptance 
 Testing) : kiểm tra xem người dùng có chấp thuận sử dụng 
 phần mềm không ? 
 ƒ Kiểm thử hồi qui : ₫ược làm mỗi khi có sự hiệu chỉnh, nâng 
 cấp phần mềm với mục ₫ích xem phần mềm mới có ₫ảm 
 bảo thực hiện ₫úng các chức năng trước khi hiệu chỉnh 
 không ? 
1.5 Testcase 
 Mỗi testcase chứa các thông tin cần thiết ₫ể kiểm thử thành 
phần phần mềm theo 1 mục tiêu xác ₫ịnh. Thường testcase gồm 
bộ 3 thông tin {tập dữ liệu ₫ầu vào, trạng thái của thành phần 
phầm mềm, tập kết quả kỳ vọng} 
 Tập dữ liệu ₫ầu vào (Input): gồm các giá trị dữ liệu cần thiết ₫ể 
thành phần phầm mềm dùng và xử lý. 
 Tập kết quả kỳ vọng : kết quả mong muốn sau khi thành phần 
phần mềm xử lý dữ liệu nhập. 
 Trạng thái thành phần phần mềm : ₫ược tạo ra bởi các giá trị 
prefix và postfix. 
 Tập các testcase : tập hợp các testcase mà ta có ý ₫ịnh dùng 
₫ể kiểm thử thành phần phần mềm ₫ể minh chứng rằng TPPM có 
₫úng các hành vi mong muốn. 
Các phương pháp thiết kế testcase 
 Bất kỳ sản phẩm kỹ thuật nào (phần mềm không phải là ngoại 
lệ) ₫ều có thể ₫ược kiểm thử bởi 1 trong 2 cách : 
 ƒ Kiểm thử hộp ₫en (Black box testing) : theo góc nhìn sử 
 dụng 
 à Không cần kiến thức về chi tiết thiết kế và hiện thực 
 bên trong. 
 à Kiểm thử dựa trên các yêu cầu và ₫ặc tả sử dụng 
 TPPM. 
 ƒ Kiểm thử hộp trắng (White box testing) : theo góc nhìn 
 hiện thực 
 à cần kiến thức về chi tiết thiết kế và hiện thực bên 
 trong. 
 à Kiểm thử dựa vào phủ các lệnh, phủ các nhánh, phủ 
 các ₫iều kiện con,... 
 Kiểu kiểm thử Kỹ thuật kiểm thử ₫ược dùng 
 Unit Testing White Box, Black Box 
 Integration Testing Black Box, White Box 
 Functional Testing Black Box 
 System Testing Black Box 
 Accceptance Testing Black Box 
1.6 Các nguyên tắc cơ bản về kiểm thử 
 Thông tin thiết yếu của mỗi testcase là kết quả hay dữ liệu 
xuất kỳ vọng. 
 Nếu kết quả kỳ vọng của testcase không ₫ược ₫ịnh nghĩa rõ 
ràng, người ta sẽ giải thích kết quả sai (plausible) thành kết quả 
₫úng bởi vì hiện tượng “the eye seeing what it wants to see.” 
 => 1 test case phải chứa 2 thành phần thiết yếu : 
 ƒ ₫ặc tả về ₫iều kiện dữ liệu nhập. 
 ƒ ₫ặc tả chính xác về kết quả ₫úng của chương trình tương 
 ứng với dữ liệu nhập. 
 Việc kiểm thử ₫òi hỏi tính ₫ộc lập : lập trình viên nên tránh việc 
kiểm thử các TPPM do mình viết. 
 Các issues tâm lý : 
 ƒ Chương trình có thể chứa các lỗi do lập trình viên hiểu sai 
 về ₫ặc tả/phát biểu vấn ₫ề. 
 ƒ Tổ chức lập trình không nên kiểm thử các chương trình của 
 tổ chức mình viết. 
 ƒ Thanh tra 1 cách xuyên suốt các kết quả kiểm thử. 
 Phải thiết kế ₫ủ các test case cho cả 2 trường hợp : dữ liệu 
₫ầu vào hợp lệ và dữ liệu ₫ầu vào không hợp lệ và chờ ₫ợi. 
 Xem xét chương trình xem nó không thực hiện những ₫iều 
mong muốn, xem nó có làm những ₫iều không mong muốn ? 
 Tránh các testcase "throwaway" trừ phi chương trình thật sự là 
"throwaway". 
 Không nên lập kế hoạch nỗ lực kiểm thử dựa trên giả ₫ịnh 
ngầm rằng phần mềm không có lỗi. 
 Xác xuất xuất hiện nhiều lỗi hơn trong 1 section phần mềm tỉ 
lệ thuận với số lỗi ₫ã phát hiện ₫ược trong section ₫ó. 
 Kiểm thử là 1 tác vụ rất thách thức ₫òi hỏi sự sáng tạo và trí 
tuệ. 
 Kiểm thử phần mềm nên bắt ₫ầu từ các thành phần nhỏ ₫ơn 
giản rồi ₫ến các thành phần ngày càng lớn hơn. 
 Kiểm thử theo kiểu vét cạn là không thể. 
 Nên hoạch ₫ịnh qui trình kiểm thử trước khi bắt ₫ầu thực hiện 
kiểm thử. 
1.7 Các ý tưởng không ₫úng về kiểm thử 
 ƒ Ta có thể kiểm thử phần mềm ₫ầy ₫ủ, nghĩa là ₫ã vét cạn 
 mọi hoạt ₫ộng kiểm thử cần thiết. 
 ƒ Ta có thể tìm tất cả lỗi nếu kỹ sư kiểm thử làm tốt công 
 việc của mình. 
 ƒ Tập các testcase tốt phải chứa rất nhiều testcase ₫ể bao 
 phủ rất nhiều tình huống. 
 ƒ Testcase tốt luôn là testcase có ₫ộ phức tạp cao. 
 ƒ Tự ₫ộng kiểm thử có thể thay thế kỹ sư kiểm thử ₫ể kiểm 
 thử phần mềm 1 cách tốt ₫ẹp. 
 ƒ Kiểm thử phần mềm thì ₫ơn giản và dễ dàng. Ai cũng có 
 thể làm, không cần phải qua huấn luyện. 
1.8 Các hạn chế của việc kiểm thử 
 ƒ Ta không thể chắc là các ₫ặc tả phần mềm ₫ều ₫úng 
 100%. 
 ƒ Ta không thể chắc rằng hệ thống hay tool kiểm thử là 
 ₫úng. 
 ƒ Không có tool kiểm thử nào thích hợp cho mọi phần mềm. 
 ƒ Kỹ sư kiểm thử không chắc rằng họ hiểu ₫ầy ₫ủ về sản 
 phẩm phần mềm. 
 ƒ Ta không bao giờ có ₫ủ tài nguyên ₫ể thực hiệm kiểm thử 
 ₫ầy ₫ủ phần mềm. 
 ƒ Ta không bao giờ chắc rằng ta ₫ạt ₫ủ 100% hoạt ₫ộng 
 kiểm thử phần mềm. 
1.9 Kết chương 
 Chương này ₫ã ôn lại qui trình phát triển phần mềm ₫ược dùng 
phổ biến nhất hiện nay, ₫ó là qui trình RUP (Rational Unified 
Process), từ ₫ó giới thiệu các lý do cần phải kiểm thử phần mềm, 
các thuật ngữ cơ bản trong hoạt ₫ộng kiểm thử phần mềm. 
 Chương này cũng ₫ã giới thiệu vai trò của các worker trong qui 
trình kiểm thử phần mềm, các mức ₫ộ kiểm thử phần mềm khác 
nhau, các nguyên tắc cơ bản của kiểm thử phần mềm. 
 Chương này cũng ₫ã giới thiệu 1 số ý tưởng không ₫úng ₫ắn 
về kiểm thử phần mềm, những hạn chế của hoạt ₫ộng kiểm thử 
phần mềm.