zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Công Nghệ Thông Tin

» Kỹ thuật lập trình

phần mềm IBM Rational Funtional Tester V7.0 Ứng dụng 2

Chia sẻ: Cao Tt | Ngày: | Loại File: PDF | Số trang:11

Báo xấu

217
lượt xem 82
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân Kiểm thử unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng phương pháp kiểm thử hộp trắng . Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự án. 2.1 Tiến trình kiểm thử Unit 2.1.1 Kế hoạch kiểm thử Unit Lập kế hoạch cho kiểm thử khác nhau (như kiểm thử hệ thống, kiểm thử tích hợp). Quyết...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: phần mềm IBM Rational Funtional Tester V7.0 Ứng dụng 2

Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân Kiểm thử unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng phương pháp kiểm thử hộp trắng . Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự án. 2.1 Tiến trình kiểm thử Unit 2.1.1 Kế hoạch kiểm thử Unit Lập kế hoạch cho kiểm thử khác nhau (như kiểm thử hệ thống, kiểm thử tích hợp). Quyết định xem đặc điểm nào cần phải kiểm thử. Các hướng tiếp cận để kiểm thử unit  Phương thức phân tích kiểm thử.  Kĩ thuật kiểm thử (hộp đen hay hộp trắng).  Các công cụ dùng trong kiểm thử. 2.1.2 Thiết kế kiểm thử  Tạo các trường hợp kiểm thử  Thiết kế các thủ tục kiểm thử:  Thủ tục làm thế nào để thực thi một trường hợp kiểm thử  Một thủ tục có thể áp dụng cho một vài trường hợp kiểm thử khác  Triển khai chương trình kiểm thử:  Kiểm thử gốc(stub): Kiểm thử lần l ượt từ gốc của chương trình, sau khi xong thì tiếp tục kiểm thử Stub tiếp theo ở bên dưới.  Kiểm thử driver : Driver là một trình điều khiển kiểm thử unit. 2.1.3 Thực hiện và đánh giá kiểm thử unit  Chuẩn bị kiểm thử môi trường.  Thực hiện kiểm thử unit.
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Phát hiện ra lỗi trong kiểm thử unit.  Làm báo cáo ghi lại toàn bộ sự thành công hay thất bại trong từng unit một dựa theo các kết quả yêu cầu. 2.2 Kế hoạch kiểm thử unit Để thực hiện một kiểm thử có hiệu quả, thì cần thiết phải có một kế hoạch kiểm thử có hiệu quả. Cần phải lập kế hoạch thật chi tiết, c àng chi tiết càng tốt. Kế hoạch kiểm thử unit cần phải đ ưa ra các tài liệu chỉ dẫn việc thực hiện kiểm thử trên từng môđun như thế nào. Mục tiêu là mỗi môđun sau khi được kiểm thử thì phải thoả mãn tất các yêu cầu đặt ra về chức năng Kế hoạch kiểm thử cần phải đ ưa ra một danh sách các đầu vào cho môđun và một danh sách các đầu ra phù hợp với các mô đun đó. Một môđun được gọi là đạt nếu tất cả các đầu vào đều có đầu ra tương ứng. Mỗi một sự sai trệch nào của đầu ra đều phải cần xem xét cụ thể. Danh sách các đầu vào phải thoả mãn yêu cầu của phần mềm, tối thiểu là lần đầu tiên. Kế hoạch kiểm thử giúp cho các nhà phát triển có thể đảm bảo chắc chắn rằng mỗi dòng mà, và mỗi câu lệnh điều kiện đều phải thực hiện được tối thiểu một lần 2.3 Kiểm thử hộp đen  Hướng vào các đặc tả bên ngoài  Chủ yếu là kiểm tra giao diện của các hàm vào ra  Các kĩ thuật thường dùng:  Lược đồ nguyên nhân kết quả.  Phân đoạn tương đương.  Phân tích giá trị biên. 2.4 Kiểm thử hộp trắng  Thực hiện bên trong chương trình.  Sử dụng các đặc tả chi tiết.
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Bao gồm các thứ sau:. Các chỉ dẫn bao quát. Bao quát toàn bộ các câu lệnh điều kiện đơn. Các điều kiện, đa điều kiện. Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúc của thiết kế chi tiêt. Sử dụng thiết kế chi tiết người sử dụng có thể đảm bảo rằng:  Bảo đảm rằng tất cả các đường dẫn độc lập ở bên trong môđun đều được thử tối thiểu một lần.  Thử nghiệm tất các các trường hợp lôgic trong các câu lệnh điều kiện.  Thực hiện tất cá các vòng lặp tới giá trị biên của chúng.  Thử nghiệm tất cả các giá trị biên bên trong đảm bảo chúng hợp lệ. 2.4.1 KIểm thử nhánh cơ bản (Basis Path Testing) Là một cách kiểm thử hộp trắng. Trường hợp kiểm thử bắt nguồn từ các đặc tả yêu cầu độc lập. Một tập các trường hợp kiểm thử có thể được phát sinh bởi các tập kiể m thử cơ bản. Đây là một cái tên đến từ thực tế rằng các kiểm thử nầy đều kiểm thử từ tất cả các hướng có thể thông qua chương trình. Tóm tắt Basis Path Testing Bước 1 Vẽ biểu đồ luồng chương tình cho một đoạn mã được lựa chọn nào đó
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân If -then - else loop - while case - of  Thực hiện từng câu lệnh một.  Bỏ qua các dòng lệnh liên tục.  Thêm một nút cho mỗi một nhánh hay câu lệnh quyết định.  Triển khai các nút phù hợp với sự thể hiện của nó. Bước 2 Độ phức tạp tính toán từ lưu đồ luồng tính như sau C = # Edges - # Nodes + 1 Bước 3 Tìm C cho mỗi trường hợp kiểm thử  -Chọn một trường hợp kiểm thử để bắt đầu.  -Trường hợp sau giống cái đầu chỉ thay đổi một số thông số cho phù hợp thôi.  -Tiếp tục cho đên 'C' xuất phát. Bước 4 Thu được các kết quả dự đoán cho mỗi trường hợp kiểm thử  Sử dụng các đặc tả của chương trình dể quyết định xem loại dữ liệu nào nên làm(tốt nhất là việc này nên làm bởi các nhà phân tích) Bước 5 Confirm that actual results match expected results
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân So sánh kết quả giữa thực tế và lí thuyết  Thực hiện đi bộ qua chương trình Hiệu quả của kiểm thử nhánh cơ bản ( Basis Path Testing ) Hiệu quả  Bao phủ hầu hết toàn bộ các vấn đề.  Sẽ phát hiện ra hầu hết các lỗi.  Hầu hết các loại lỗi.  Là một phương tiện hay để xem lại toàn bộ mã nguồn và đi bộ qua giải thuật.  Có thể ứng dụng cho các mức lôgic cao hơn hay các đoạn mã giả. Hiệu lực  Là một qui trình xác định tốt.  Hiệu quả trong việc sử dụng tài nguyên máy và thời gian thiết kế.  Phát sinh đơn giản và dễ thực thi các trường hợp kiểm thử.  Giá cả thì chấp nhận được trong thương mại.  2.5 Các trường hợp kiểm thử và dữ liệu kiểm thử  Kiểm tra các toán tử ở mức giá trị thông thường.  Kiểm tra với các giá trị giới hạn.  Kiểm tra ngoài vùng giá trị.  Kiểm tra các lỗi ở trong vòng lặp.  Kiểm tra các kết thúc không bình thường trong vòng lặp.  Kiểm tra các kết thúc không bình thường trong đệ quy.  Kiểm tra tất các các cấu trúc dữ liệu được truy nhập bởi hàm.  Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên.  Kiểm tra tất cả các lỗi điều kiện.  Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết.  Đảm bảo rằng mọi câu lệnh đều được thực hiện.
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả các nhánh.  3. Kiểm thử tích hợp 3.1 Tạo dữ liệu và file kiểm thử Các hoạt động chính:  Xác định nội dung của kiểm thử dữ liệu và file.  Tạo dữ liệu kiểm thử, dữ liệu kiểm thử có thể tạo ra bằng một trong các phương pháp luận sau.  Vào thủ công.  Phần mềm sinh dữ liệu kiểm thử.  Giúp ra từ cơ sở dữ liệu sống.  Điền đầy các dữ liệu kiểm thử với sự giúp đỡ của các ch ương trình quản lí cơ sở dữ liệu.  Kiểm tra xem có khớp với các yêu cầu đặt ra không 3.2 Các chiến thuật và kĩ nghệ kiểm thử 3.2.1 Kiểm thử tích hợp không tăng tiến Big Bang là một kiểm thử tích hợp không tăng tiến.Tất cả các mô đun đều được phối hợp ngay từ đầu. Phần mềm được kiểm thử toàn bộ - kết quả ban đầu thường là lộn xộn. Để đúng được là rất khó vì một dãy các lỗi gặp phải. Khi một lỗi được sữa thì lại bắt gặp một lỗi khác chỉ cho tới khi nào vòng lặp dừng thì thôi.Cho nên phương pháp này không được đề nghị 3.2.2 Kiểm thử tích hợp tăng tiến Là một kiểm thử trái ngược lại với kiểm thử Big Bang Phần mềm được xây dựng và kiểm thử từng đoạn một. Lỗi dễ bị cô lập và xử lí. Giao diện dễ kiểm thử hơn và có thể áp dụng kiểm thử hệ thống.
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân Kiểm thử hệ thống bao gồm các phương pháp luận sau: 1. Kiểm thử tích hợp Top-Down. 2. Kiểm thử tích hợp Bottom-up. 3. Kiểm thử Sandwich. 1. Kiểm thử tích hợp Top-Down  Hàm Main là nút gốc còn tất cả cá môđun ở bên dưới là các gốc con(bới vì sau khi kiểm thử xong nút gốc này thì tất cả cá nút gốc con sẽ được kiểm thử). Nút gốc sẽ được thay thế bằng các môđun cụ thể, phụ thuộc vào hướng kiểm thử tích hợp được lựa chọn. Cứ tiếp tục quá trình như vậy cho đến khi nào kết thúc chương trình thì thôi.  Thuận tiện  Không cần có driver kiểm thử.  Lỗi giao diện được phát hiện sớm. Bất tiện  Cần gốc (stubs).  Làm chậm tiến trình kiểm thử.  Lỗi ở trong các môđun ở mức thấp khó tìm ra. Chú thích  Chương trình làm việc đầu tiên nâng lên tinh thần.  Rất khó để có thế duy trì thuần top-down trong thực tế. Tích hợp Bottom-Up  Mô đun ở mức thấp nhất sẽ được kiểm thử đầu tiên  Mỗi một driver được viết để theo dõi các đầu vào và đầu ra  Kiểm thử từng khối
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Driver sẽ bị xoá đi và các cụm sẽ được kết hợp lại, sau đó di chuyển nên trên trong cấu trúc chương trình Thuận tiện  Không cần đến gốc  Rất dễ điều chỉnh số lượng người cần thiết  Lỗi quyết định sớm được tìm thấy Sự bất tiện  Các driver kiểm thử là cần thiết  Rất nhiều môđun phải được tích hợp trước khi làm việc  Lỗi giao diện khám phá muộn Chú thích  Phải kiểm tra nhiều các đoạn mã hơn là so với Top-Down  Bottom-up là một cách mang tính trực giác nhiều hơn  2.Kiểm thử Sandwich  Là một phương pháp kiểm thử kết hợp cả top-down và bottom-up  Tất cả các môđun và giao diện đều phải kiểm thử bằng phương pháp Top-Down  Cả driver và stub đều được sử dụng khi cần thiết  Tất cả các môđun đều được xây dựng và kiểm thử unit bắt đầu từ mức thấp nhất, sử dụng chiến thuật Bottom-Up 3.2.3 Tiêu chí để hoàn thành Một tester phải biết khi nào kiểm thử là đủ. Kiểm thử có thể dừng khi:  Nó không phát sinh lỗi  Nó đã bao phủ gần như hoàn toàn  Nó phát hiện ra một số lượng lỗi  Kế hoạch kiểm thử kết thúc 3.2.4 Các lời bình về kiểm thử môđun
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Đúng với các yêu cầu phần mềm  Có mức điều khiển cao  Có phức tạp hay ẩn chứa lỗi hay không  Có các yêu cầu hiệu năng xác định hay không Các bình luận nên càng sớm càng tốt 3.2.5 Đề nghị phương pháp luận kiểm thử tích hợp  Lựa chọn một nhóm các môđun không quá ph ức tạp để kiểm thử.  Kết nối các nhóm môđun vào chương trình.  Kiểm thử tích hợp trên bộ khung của hệ thống.  Thử nghiệm tất cả các môđun.  Thử nghiệm tất cả các lựa chọn của chương trình với các tiện ích của nó.  Thực thi kiểm thử trên bộ khung của chương trình.  Nạp kiểm thử.  Kiểm thử hiệu năng của chương trình.  Cố gắng phá vỡ bộ khung.  Lặp lại bốn bước trên nhiều lầm nếu thấy cần thiết để xây dựng một mức hoàn chỉnh. 4 Kiểm thử hệ thống Mỗi lần kiểm thử thủ tục hỗ trợ kiểm thử hệ thống được thực hiện, đội kiểm thử so sánh kết quả mong đợi của mỗi kiểm thử thủ tục với kết quả thực tế. Nếu kết quả thực tế khác so với kết quả mong đợi, sự khác nhau này phải được xem xét lại kỹ hơn. Kiểm thử hệ thống thường thực hiện sau tất cả các môđun, kiểm thử tích hợp và kiểm thử unit được chấp nhận một cách thành công. Đội kiểm thử cần có thể tái tạo lại vấn đề và phải chắc chắn là vấn đề này không phải gây ra do lỗi kiểm thử, lỗi thiết lập môi trường, lỗi thủ tục kiểm thử, hay lỗi kiểm thử kịch bản. Nếu báo cáo lỗi bởi vì những lỗi được xác định trong
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân lỗi kiểm thử, lỗi thiết lập môi trường, lỗi kiểm thử thủ tục, hay lỗi kiểm thử kịch bản, hành động thích hợp để hiệu chỉnh nên được thực hiện và thực hiện lại kiểm thử. Nhược điểm của sản phẩm nên được ghi lại trong DMS. 5 Kiểm thử xác nhận Kiểm thử kiểm nhận chứng minh cho khách hàng rằng tiêu chuẩn kiểm nhận xác định trước đã được xác định bởi hệ thống. Điển hình nó được sử dụng như một kỹ thuật để bàn giao hệ thống. 6 Kiểm thử hồi quy Thực hiện kiểm thử hồi quy thông thường mất rất nhiều nỗ lực cố gắng. V ì thế, kiểm thử hồi quy có thể được thực hiện sau một giai đoạn. Tuy nhiên, kiểm thử hồi quy phải được thực hiện khi:  Tổng số những yêu cầu thay đổi xảy ra từ bản cơ sở cuối cùng với kiểm thử hồi quy lớn hơn 10% tổng số những yêu cầu trong cơ sở đó.  Tỉ lệ tổng số lỗi được phát hiện sau kiểm thử kiểm nhận hay trong trong thao tác chia tổng số man-months của dự án lớn hơn 1. Với những dự án bảo trì, khởi động cho kiểm thử hồi quy phải được xác định trong kế hoạch kiểm thử. Leader kiểm thử phải xác định khi nào đội dự án kiểm soát kiểm thử hồi quy và phạm vi kiểm thử hồi quy. Lập biểu của kiểm thử hồi quy phải được xác định trong lập biểu của dự án. 7 Lỗi dữ liệu 7.1 Vòng đời của lỗi Một lỗi trong phần mềm là một cái gì đó mà gây ra cho phần mềm chạy theo cách mà nó không nhất quán với những yêu cầu hay sự cần thiết của khách hàng hay những chuẩn liên quan. Để có phần mềm chất lượng cao, sản phẩm cuối cùng nên có vài lỗi có thể.
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0 Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân  Một lỗi được tìm thấy và phải được ghi lại trong DMS bởi một nhân viên. Lỗi được vào trong DMS với trạng thái “Error” và thông tin khác.  Lãnh đạo dự án phải xem lại dữ liệu của một lỗi (như là dạng lỗi, nguồn gốc,tính nguy hại,..), sửa nó và giao cho người sửa lỗi. Thông thường thành viên được giao là tác giả của văn bản hay đoạn mã nguồn mà lỗi được tìm thấy trong đó. Trạng thái của lỗi được thay đổi thành “Assigned”.  Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành “Pending”  Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhật trạng thái thành “Tested” nếu lỗi được sửa một cách hài lòng, hay thành “Error”.  Nếu một lỗi với trạng thái “Error” có thể được chấp nhận mà không có một hành động hiệu chỉnh nào, lãnh đạo dự án cần đổi trạng thái thành “Accepted”. Vòng đời của lỗi được mô hình hoá trong flowchart sau đây:

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.