Bài giảng Kiểm thử phần mềm (Software testing)

Software testing Kiểm thử phần mềm Nội dung  Kiểm thử hệ thống (system testing)  Kiểm thử thành phần (component testing)  Thiết kế test case (test case design)  Kiểm thử tự động (test automation) Tiến trình Kiểm thử  Kiểm thử thành phần  Kiểm thử các thành phần riêng biệt của chương trình  Thường là trách nhiệm của người phát triển phần mềm  Kiểm thử xuất phát từ kinh nghiệm của người phát triển phần mềm. Kiểm thử hệ thống - Kiểm thử các nhóm thành phần tích hợp để tạo ra 1 hệ thống hoặc 1 hệ thống phụ - Là trách nhiệm của nhóm kiểm thử độc lập - Kiểm thử dựa trên đặc tả hệ thống Giai đoạn kiểm thử Component testing System testing Software developer Independent testing team Kiểm tra lỗi  Mục tiêu của việc kiểm tra lỗi là để phát hiện ra những lỗi trong chương trình  Kiểm tra thành công là làm cho chương trình chạy 1 cách bất thường Mục tiêu của tiến trình kiểm tra  Kiểm thử xác nhận - Để giải thích cho người phát triển phần mềm và khách hàng thấy được các yêu cầu mà hệ thống có. - kiểm thử thành công là cho thấy hệ thống hoạt động như dự định  Defect testing - Để phát hiện lỗi hoặc khiếm khuyết trong hệ thống mà hoạt động của nó không đúng hoặc không phù hợp với đặc tả. - Một kiểm thử thành công là làm cho hệ thống thực hiện không chính xác và để lộ một khiếm khuyết trong hệ thống. Quy trình kiểm thử phần mềm Test case Test data Test results Test reports Design test cases Prepare test data Run program with test data Compare results to test cases Chính sách kiểm thử  Chỉ có kiểm thử đầy đủ mới có thể cho thấy 1 chương trình luôn có khiếm khuyết. Tuy nhiên, kiểm thử đầy đủ là việc không thể.  Chính sách kiểm thử xác định các phương pháp được sử dụng trong việc chọn lựa kiểm thử hệ thống. - Tất cả các chức năng truy cập trong trình đơn nên được kiểm thử - Sự kết hợp các chức năng trong cùng 1 trình đơn cần được kiểm thử. - Trường hợp đầu vào là từ phía người dùng thì tất cả các chức năng đều phải được kiểm thử với cả đầu vào đúng và sai. Kiểm thử hệ thống  Bao gồm các thành phần tích hợp để tạo ra 1 hệ thống hoặc 1 hệ thống phụ.  Có thể bao gồm việc kiểm thử 1 increment được giao cho khách hàng.  Hai giai đoạn: - Kiểm thử tích hợp: nhóm kiểm thử có thể truy cập vào mã nguồn của hệ thống. Hệ thống được kiểm thử là các thành phần được tích hợp. - Kiểm thử phát hành(release testing): nhóm kiểm thử kiểm thử hệ thống hoàn chỉnh sẽ được chuyển giao như một black-box. Kiểm thử tích hợp  Bao gồm việc xây dựng 1 hệ thống từ các thành phần và kiểm thử để phát hiện vấn đề phát sinh từ các tương tác thành phần.  Tích hợp đầu-cuối: Phát triển khung sườn hệ thống và populate nó với các thành phần.  Tịch hợp trên-dưới:  Để đơn giản hóa các lỗi cục bộ, hệ thống nên được tích hợp từng bước một. Incremental integration testing A B A B C A B C D T1 T2 T3 T1 T2 T3 T1 T2 T3 T4 T4 T5 Tiếp cận kiểm thử  Xác nhận kiến trúc: Kiểm thử tích hợp Top- Down để phát hiện ra sai sót trong kiến trúc của hệ thống. Black-box testing Nguyên tắc kiểm thử  Nguyên tắc kiểm thừ là các gợi ý cho nhóm kiểm thử để giúp họ chọn cách kiểm thử mà sẽ làm bộc lộ các khuyết điểm trong hệ thống.  Chọn các đầu vào tác động đến hệ thống để tạo ra tất cả các thông báo lỗi.  Thiết kế đầu vào để gây ra lỗi tràn bộ đệm  Lặp lại các đầu vào giống nhau hoặc hàng loạt đầu vào trong 1 vài lần.  Lượng kết quả tính toán là quá nhiều hay quá ít. Kịch bản kiểm thử A student in Scotland is studying American History and has been asked to write a paper on ‘Frontier mentality in the American West from 1840 to 1880’. To do this, she needs to find sources from a range of libraries. She logs on to the LIBSYS system and uses the search facility to discover if she can access riginal documents from that time. She discovers sources in various US university libraries and downloads copies of some of these. However, for one document, she needs to have confirmation from her university that she is a genuine student and that use is for non-commercial purposes. The student then uses the facility in LIBSYS that can request such permission and registers her request. If granted, the document will be downloaded to the registered library’s server and printed for her. She receives a message from LIBSYS telling her that she will receive an e-mail message when the printed document is available for collection. Các kiểm thử hệ thống  Kiểm tra cơ chế đăng nhập bằng cách sử dụng thông tin đăng nhập chính xác và không chính xác để kiểm tra rằng người dùng hợp lệ được chấp nhận và người sử dụng không hợp lệ bị từ chối.  Kiểm tra các tìm kiếm cơ sở bằng cách sử dụng các truy vấn khác nhau đối với nguồn đã biết đê kiểm tra xem cơ chế tìm kiếm có thực sự tìm kiếm các tài liệu.  Kiểm tra hệ thống trình bày cơ sở để kiểm tra xem thông tin về các văn bản có được hiển thị đúng cách.  Kiểm tra các cơ chế để yêu cầu sự cho phép để tải về.  Kiểm tra e-mail phản hồi cho biết rằng các tài liệu được tải về là tồn tại. Use cases  Use cases có thể là các cơ sở để phát sinh các kiểm thử cho hệ thống. Chúng giúp cho việc xác định các hoạt động để kiểm thử và giúp cho việc thiết kế test case.  Từ một lược đồ trình tự liên quan, các đầu vào và đầu ra phải được tạo ra cho các lần kiểm thừ có thể được xác định. Collect weather data sequence chart Kiểm thử hiệu suất  Một phần của release testing có thể bao gồm thử nghiệm sự nổi lên đặc tính của một hệ thống, chẳng hạn như hiệu suất và độ tin cậy.  Hiệu suất kiểm tra thường liên quan đến kế hoạch hàng loạt các bài kiểm tra nơi nạp là ổn định tăng cho đến khi hệ thống hoạt động trở nên không thể chấp nhận. Kiểm thử thành phần  Thành phần test là quá trình thử nghiệm thành phần riêng biệt trong hệ thống. Đây là một quá trình kiểm tra lỗi như vậy mục đích của nó là để lộ những lỗi lầm trong các thành phần. Có nhiều loại khác nhau của thành phần có thể sẽ được thử nghiệm ở giai đoạn này:  chức năng cá nhân hoặc các chức năng trong một đối tượng.  các lớp đối tượng có nhiều thuộc tính và chức năng.  các chức năng của thành phần hỗn hợp được tạo thành từ các đối tượng khác nhau. các thành phần hỗn hợp có một giao diện được định nghĩa được sử dụng để truy cập các chức năng của nó  chức năng cá nhân hoặc các phương pháp cá nhân là loại đơn giản nhất của thành phần, các test của bạn là một tập hợp các đường dẫn đến những thói quen với các thông số đầu vào khác nhau. bạn có thể sử dụng các phương pháp tiếp cận để kiểm tra , thảo luận trong phần tiếp theo, để thiết kế các test chức năng hoặc các chức năng. Giao diện đối tượng trạm thời tiết Trạm thử nghiệm thời tiết  Cần phải xác định trường hợp thử nghiệm cho báo cáo thời tiết, hiệu chỉnh, kiểm tra, khởi động và tắt máy.  Sử dụng một mô hình nhà nước, xác định trình tự của chuyển trạng thái để thử nghiệm và sự kiện trình tự để gây ra những hiệu ứng chuyển tiếp  Ví dụ: Chờ đợi -> đo đạc -> Kiểm tra -> Truyền -> Chờ đợi Kiểm thử giao diện  Mục tiêu là để phát hiện lỗi do Giao diện hoặc giả định không hợp lệ về giao diện.  Đặc biệt quan trọng đối với hướng đối tượng phát triển các đối tượng được xác định bằng các giao diện của nó. Interface testing Các loại giao diện Các thông số giao diện  Dữ liệu truyền từ một thủ tục khác. Chia sẻ bộ nhớ giao diện. _ Block của bộ nhớ được chia sẻ giữa các thủ tục hoặc chức năng. Giao diện thủ tục _ Hệ thống đóng gói là một tập hợp các thủ tục và bởi các hệ thống phụ khác. Thông báo qua giao diện _ Hệ thống yêu cầu dịch vụ từ system.s Lỗi giao diện *Sử dụng sai giao diện Một thành phần giao diện gọi thành phần khác và làm cho một lỗi trong việc sử dụng thành phần đó ví dụ: sai thứ tự các thông số . *Sự hiểu lầm giao diện Những giả định về hành vi của các thành phần không chính xác. *Lỗi thời Các tên gọi của tốc độ hoạt động và các thông tin mới được truy cập về thành phần khác . Hướng dẫn kiểm tra giao diện  Thiết kế các bài kiểm tra để các tham số được gọi là thủ tục tại phạm vi các đầu cực của của nó.  Luôn luôn kiểm tra các tham số con trỏ với con trỏ null.  Thiết kế các bài kiểm tra thành phần gây thất bại.  Sử dụng qua tin nhắn thử nghiệm trong hệ thống.  Trong chia sẻ hệ thống bộ nhớ, thay đổi thứ tự các thành phần được kích hoạt. Trường hợp kiểm tra thiết kế  Liên quan đến việc thiết kế các trường hợp thử nghiệm (đầu vào và kết quả đầu ra) dùng để kiểm tra hệ thống.  Mục tiêu của thiết kế trường hợp thử nghiệm là tạo ra một thiết lập các bài kiểm tra có hiệu quả trong quá trình xác nhận và lỗi thử nghiệm.  Thiết kế phương pháp tiếp cận:  Dựa trên yêu cầu thử nghiệm;  Phân vùng thử nghiệm;  thử nghiệm Kết cấu. Thử nghiệm dựa trên yêu cầu  Một nguyên tắc chung của yêu cầu kỹ thuật này là yêu cầu cần được kiểm chứng.  Yêu cầu dựa trên thử nghiệm là một xác nhận kiểm tra kỹ thuật, nơi bạn xem xét từng yêu cầu và rút ra một tập hợp các yêu cầu kiểm thử. yêu cầu LIBSYS  Người dùng sẽ có thể tìm kiếm hoặc là tất cả các thiết lập ban đầu của cơ sở dữ liệu hoặc chọn một tập con từ đó.  Hệ thống sẽ cung cấp cho người xem thích hợp cho người sử dụng để đọc tài liệu trong tài liệu lưu trữ.  Mỗi đơn hàng được cấp một định danh duy nhất (ORDER_ID) mà người dùng phải có thể sao chép vào khu vực lưu trữ lâu dài của tài khoản. Kiểm thử LIBSYS  Bắt đầu tìm kiếm: cho người sử dụng tìm kiếm cho các hạng mục được biết đến  Bắt đầu dùng tìm kiếm cho các hạng mục đó được biết là có mặt và được biết không có mặt, nơi tập hợp các cơ sở dữ liệu bao gồm 2 cơ sở dữ liệu  Bắt đầu dùng tìm kiếm cho các hạng mục đó được biết là có mặt và được biết không có mặt nơi đặt cơ sở dữ liệu, bao gồm hơn 2 cơ sở dữ liệu.  Chọn một cơ sở dữ liệu từ các thiết lập cơ sở dữ liệu và bắt đầu người dùng tìm kiếm cho các hạng mục được biết là hiện tại và được biết đến không có mặt.  Chọn nhiều hơn một cơ sở dữ liệu từ các thiết lập cơ sở dữ liệu và bắt đầu tìm kiếm cho các hạng mục đó được biết là có mặt và được biết không có mặt. Phân vùng thử nghiệm  Dữ liệu đầu vào và kết quả đầu ra thường rơi vào các lớp học khác nhau mà tất cả các thành viên của một lớp học có liên quan.  Mỗi của các lớp này là tương đương phân vùng, lĩnh vực mà chương trình cư xử một cách tương đương cho mỗi lớp thành viên.  trường hợp kiểm tra nên được lựa chọn từ mỗi phân vùng. phân vùng tương đương search routine - input partitions  Nhập vào những gì phù hợp với điều kiện ban đầu  Nhập vào nơi yếu tố khóa là 1 thành phần của mảng  Nhập vào nơi yếu tố khóa không là 1 thành phần của mảng search routine - input partitions Nguyên tắc kiểm thử( tuần tự)  Kiểm thử phần mềm với trình tự mà chỉ có 1 giá trị đơn  Sử dụng các kích thước khác nhau của trình tự trong những kiểm thử khác nhau  Xuất phát từ việc kiểm thử : phần đầu giữa cuối của trình tự cho phép  Kiểm thử với chiều dài trình tự là 0 Kiểm thử cấu trúc  Thông thường gọi là kiểm thử white-box  Dẫn xuất của trường hợp kiểm thử dựa theo cấu trúc chương trình. Sự nhận biết của chương trình được dùng để xác nhận trường hợp kiểm thử thêm vào  Đối tượng để thi hành tất cả dòng lệnh chương trình( không phải tất cả đường kết hợp) Kiểm thử cấu trúc Tìm kiếm nhị phân- phân vùng tương đương  Thỏa mãn điều kiện ban đầu, yếu tố khóa trong mảng  Thỏa mãn điều kiện ban đầu, yếu tố khóa không ở trong mảng  Không thỏa mãn điều kiện ban đầu, yếu tố khóa trong mảng  Không thỏa mãn điều kiện ban đầu, yếu tố khóa không ở trong mảng  Mảng nhập vào giá trị đơn  Mảng nhập vào giá trị chẵn  Mảng nhập vào giá trị lẻ Tìm kiếm nhị phân- phân vùng tương đương Kiểm thử đường đi  Đối tượng của kiểm thử đường đi là để chắc chắn rằng bộ trường hợp kiểm thử là mỗi đường trong chương trình được thực thi tệ nhất 1 lần  Điểm bắt đầu cho kiểm thử đường đi là chương trình luồng đồ thị, biểu diễn node mô tả sự giải quyết của chương trình và vòng cung biểu thị luồng điều khiển  Những dòng lệnh với các điều kiện là node trong luồng đồ thị Kiểm thử tự động  Kiểm thử là giai đoạn tốn kém.quy trình kiểm thử cung cấp loạt các công cụ để giảm thời gian và chi phí  Hệ thống như là Junit hỗ trợ sự thực thi kiểm thử tự động  Hầu hết quy trình kiểm thử là hệ thống mở vì kiểm thừ cần là đặc tả tổ chức  Chúng thông thường khó để tích hợp vói quy trình thiết kế và phần tích thân thiện A testing workbench Testing workbench adaptation  Các tập lệnh phải được phát triển để thích ứng với giao diện người dùng, kiểu dáng cho bộ sinh dữ liệu thử  Kiểm tra kết quả đầu ra phải được kiểm chứng lại bằng phương pháp thủ công  Đặc biệt có thể so sánh các tập tin để phát triển Key points  Kiểm thử giao diện là tìm ra những lỗi trong việc thiết kế giao diện của những thành phần hỗn hợp cấu thành  Phân tích cấu trúc dựa vào việc phân tích 1 chương trình và kiểm tra những phát sinh từ việc phân tích đó.  Hệ thống kiểm thử tự động làm giảm chi phí kiểm thử bằng cách hỗ trợ trong việc kiểm thử chương trình với 1 loạt các công cụ phần mềm.