Nghiên cứu công cụ kiểm thử phần mềm IBM Rational funtional tester 7.0

Tài liệu tham khảo công nghệ thông tin Nghiên cứu công cụ kiểm thử phần mềm IBM Rational funtional tester 7.0

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC HÌNH VẼ 4

DANH MỤC CÁC KÍ HIỆU VÀ TỪ VIẾT TẮT 5

MỞ ĐẦU 6

1 Lý do chọn đề tài 6

2 Mục tiêu 7

3 Phạm vi nghiên cứu 7

4 Bố cục của đề tài 7

CHƯƠNG I CƠ SỞ LÝ THUYẾT 9

I TỔNG QUAN VỀ QUÁ TRÌNH KIỂM THỬ 9

I.1 Một số định nghĩa về quá trình kiểm thử phần mềm 9

I.2 Những khái niệm liên quan đến kiểm thử 10

I.3 Mô hình khái niệm của quá trình kiểm thử 11

I.4 Mục tiêu của kiểm thử 11

I.5 Vai trò 11

II NHỮNG VẤN ĐỀ LIÊN QUAN ĐẾN KIỂM THỬ 12

II.1 Vòng đời kiểm thử 12

II.2 Tiến trình kiểm thử 12

II.3 Những thành phần của một kế hoạch kiểm thử 13

II.4 Những điểm cần tập trung kiểm thử trước nhất nếu không có đủ thời gian 13

II.5 Các chỉ tiêu đánh giá kiểm thử 14

III MỘT SỐ LOẠI KIỂM THỬ THÔNG DỤNG 14

1.Mô hình phát triển chữ V 14

2 Kiểm thử unit 15

2.1 Tiến trình kiểm thử Unit 16

2.2 Kế hoạch kiểm thử unit 17

2.3 Kiểm thử hộp đen 17

2.4 Kiểm thử hộp trắng 17

2.5 Các trường hợp kiểm thử và dữ liệu kiểm thử 20

3 Kiểm thử tích hợp 21

3.1 Tạo dữ liệu và file kiểm thử 21

3.2 Các chiến thuật và kĩ nghệ kiểm thử 21

4 Kiểm thử hệ thống 24

5 Kiểm thử xác nhận 25

6 Kiểm thử hồi quy 25

7 Lỗi dữ liệu 25

CHƯƠNG II NGHIÊN CỨU PHẦN MỀM SEK CỦA IBM 34

CHƯƠNG III NGHIÊN CỨU CÔNG CỤ KIỂM THỬ RATIONAL

FUNTIONAL TESTER 36

III.1 GIỚI THIỆU VỀ CÔNG CỤ IBM RATIONAL FUNTIONAL TESTER V7.0 36

III.2 NHỮNG LỢI ÍCH KHI SỬ DỤNG CÔNG CỤ IBM RATIONAL FUNTIONAL TESTER 37

III.3 NHỮNG CHIẾN LƯỢC ĐỂ SỬ DỤNG LẠI STATEMENT 39

III.4 RATIONAL FUNTIONAL TESTER VỚI ĐỘI PHÁT TRIỂN 41

III.5 COMPLIANCE(quy trình nghiệp vụ) 42

III.6 ĐIỀU KIỆN ĐỂ SỬ DỤNG CÔNG CỤ 42

CHƯƠNG IV THỰC HIỆN KIỂM THỬ 44

IV.1 TẠO USECASE KIỂM THỬ, ĐIỀU KIỆN ĐẦU VÀO VÀ KẾT QUẢ MONG ĐỢI 44

1.Chức năng Login 44

2.Chức năng tra cứu 45

3 Chức năng cập nhật 48

4.Chức năng xuất hàng 50

IV.2 THỰC HIỆN KIỂM THỬ VỚI CÔNG CỤ IBM RFT 51

1.Chức năng Login 51

2.Chức năng tra cứu 52

3.Chức năng cập nhật 58

4.Chức năng xuất hàng 61

5.Viết báo cáo 64

KẾT LUẬN 65

NHỮNG VẤN ĐỀ ĐẠT ĐƯỢC 65

ƯU ĐIỂM VÀ NHƯỢC ĐIỂM CỦA CÔNG CỤ 65

HƯỚNG PHÁT TRIỂN 67

PHỤ LỤC A 68

HƯỚNG DẤN CÀI ĐẶT IBM RATIONAL FUTIONAL TESTER 68

PHỤ LỤC B 86

THỰC HIỆN QUÁ TRÌNH KIỂM THỬ VỚI RATIONAL FUNTIONAL TESTER 86

TÀI LIỆU THAM KHẢO 108

DANH MỤC CÁC HÌNH VẼ

H I.1: Mô hình khái niệm của quá trình kiểm thử

15

H II.1 The Software Development

14

H II.2 Quá trình bắt lỗi

26

DANH MỤC CÁC KÍ HIỆU VÀ TỪ VIẾT TẮT

Management

Evaluation Kit

MỞ ĐẦU

1 Lý do chọn đề tài

Kiểm thử phần mềm là một thành phần quan trọng trong qui trình phát triểnphần mềm Nó đóng một vai trò quan trọng trong việc kiểm định chất lượng củaphần mềm, đảm bảo rằng phần mềm tạo ra có chạy đúng với yêu cầu của kháchhàng hay không, có xảy ra những sai sót mà nó khác với bảng phân tích thiết kếban đầu không Vì vây, năm 2006 IBM cho ra đời sản phẩm The 2007developerWorks Software Evaluation Kit (SEK) for Windows, đây là một trong sốnhiều phần mềm dùng cho việc kiểm thử SEK bao gồm 6 Tool và em lựa chọncông cụ Rational Funtional Tester V7.0 để nghiên cứu cho đồ án tốt nghiệp Đây

là công cụ kiểm thử chức năng của phần mềm, một dụng cụ kiểm thử hồi quy tiêntiến, được tự động hóa cho Tester và người phát triển GUI

Bất kỳ một tổ chức nào cũng có một sự tin cậy của riêng mình vào việcphát triển của những trình ứng dụng để phục vụ cho những việc cần thiết như đápứng được những chức năng của khách hàng đưa ra, để cho khách hàng tỏ ra hàilòng về chất lượng của những trình ứng dụng và những đòi hỏi về những chứcnăng, điều kiện được đáp ứng đầy đủ, và không xảy ra sự tuỳ tiện trong sản phẩm.Một thành phần chủ yếu cho sự thành công này là tính hiệu quả, quy trình kiểm traphải có tính kỷ luật tiến tới sự xác minh của những trình ứng dụng đã hoàn thành,quá trình kiểm tra phải có tính kỷ kuật để xem xét những trình ứng dụng đã hoànthành đến mức độ nào, đó là sự phù hợp thích đáng hay là vượt ra khỏi nhữngmong đợi trong đề án Lịch trình làm việc không đúng, thường xuyên thay đổinhững vấn đề chung của trình ứng dụng IBM Rational Funtional Tester được xâydựng dựa trên những vấn đề này

Sau khi nghiên cứu một số tài liệu liên quan, được sự đồng ý của KhoaCông Nghệ Thông Tin – Đại Học Duy Tân Đà Nẵng, em đã thực hiện đề tài khóaluận tốt nghiệp mang tê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ểnphần mềm Đại Học Duy Tân.”

2 Mục tiêu

Đề tài giới thiệu các vấn đề trong kiểm thử và đi sâu nghiên cứu các tínhnăng cơ bản của công cụ IBM Rational Funtional Tester V7.0, đưa ra tài liệuhướng dẫn cài đặt, sử dụng công cụ một cách đơn giản và hiệu quả

Đề tài áp dụng được trong thực tế để kiểm thử phần mềm tại các công ty phầnmềm, đặc biệt là CSE

Nội dung của luận văn được trình bày trong 3 chương

Chương I: Cơ Sở Lý Thuyết

Chương này giới thiệu tổng quan về quá trình kiểm thử, những khái niêm,những thuật ngữ, vấn đề liên quan đến kiểm thử, những mô hình kiểm thử và cácloại kiểm thử thông dụng hiện nay

Chương II:Nghiên cứu về phần mềm SEK của IBM

Trong chương này em tìm hiểu những công cụ có trong bộ The 2007developerWorks® Software Evaluation Kit (SEK) for Windows® của IBM và ứngdụng của nó

Chương III Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0.

Trong chương này em giới thiệu chi tiết về công cụ, IBM RFT làm việcnhư thế nào, những tính năng và lợi ích mà nó mang lại, Thực hiện kiểm thử đểchỉ ra những lợi ích mà nó mang lại đồng thời hướng dẫn cách thức kiểm thử đểngười dùng có thể thực hiện một cách đơn giản

Chương IV Thực hiện kiểm thử trên một phần mềm có sẳn.

Trong chương này em tiến hành kiểm thử trên một phần mềm có sẳn đểkhẳng định và chỉ ra những vấn đề mà em đã nêu ở chương III

Kết thúc luận văn là phần kết luận về những vấn đề đạt được và hướng pháttriển của khóa luận và danh mục các tài liệu tham khảo

CHƯƠNG I CƠ SỞ LÝ THUYẾT

I TỔNG QUAN VỀ QUÁ TRÌNH KIỂM THỬ

I.1 Một số định nghĩa về quá trình kiểm thử phần mềm

Kiểm thử là việc kiểm tra kết quả thực hiện của chương trình máy tính xem

có đúng với các mục tiêu đã đặt ra với nó không thông qua việc thực hiện ở một sốmẫu thử

Kiểm thử là việc tìm ra những lỗi trong bản thân phần mềm, việc kiểm thửnày trong phần mềm sẽ biểu thị ra những thiếu sót mà ta có thể nhận thấy tronghành vi của phần mềm, và tìm ra những phần không tuân theo quy định và đi lệch

ra khỏi những yêu cầu của phần mềm

Theo một số nhà nghiên cứu thì kiểm thử phần mềm được định nghĩa nhưsau:

 Dijkstra: Kiểm thử sẽ hiện thị những lỗi hiện có, nhưng khônghiển thị lỗi chưa thấy

 Beizer:

Định luật 1: Mọi phương pháp bạn sử dụng để ngăn ngừahoặc tìm thấy lỗi bỏ đi một phần lỗi rắc rối, cái mà những phươngthức cần

Định luật 2: Phần mềm phức tạp lớn hơn những giới hạn khảnăng quản lý

Những người kiểm thử không tốt hơn trong thiết kế lỗi

so với những lập trình viên kiểm thử trong thiết kế mã

 IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành phầndưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả vàđưa ra đánh giá về hệ thống hoặc thành phần đó

 Myers: Kiểm thử là tiến trình thực thi chương trình với mục đíchtìm thấy lỗi.(The art of software testing)

Giữa kiểm thử và gỡ rối có sự khác biệt: Kiểm thử nhằm phát hiện ra lỗitrong khi đó gỡ rối là việc xác định bản chất lỗi và định lỗi trong chương trình, sau

đó tiến hành sữa lỗi

I.2 Những khái niệm liên quan đến kiểm thử

 Một sai sót(Error): Là một sự nhầm lẫn hay một sự hiểu sai trong

quá trình phát triển phần mềm của người phát triển

 Một lỗi(fault, defect): Xuất hiện trong phần mềm như là kết qủa

của một sai sót

 Một hỏng hóc(failure):là kết quả của một lỗi xuất hiện làm cho

chương trình không hoạt động được hoặc hoạt động được nhưngkhông cho kết quả như mong muốn

 Kiểm thử viên(tester): Người thực hiện kiểm thử

 Ca kiểm thử(test case):Tập dữ liệu kiểm thử, điều kiện kiểm thử,

để đưa ra kết quả mong đợi

I.3 Mô hình khái niệm của quá trình kiểm thử

H I 1: Mô hình khái niệm của quá trình kiểm thử

I.4 Mục tiêu của kiểm thử

Việc kiểm thử nhằm thực hiện hai mục tiêu:

 Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm(Myers,1979)và thiết lập chất lượng của phần mềm(Hetzel,1988)

 Việc kiểm thử thành công khi bạn tìm được ít nhất một lỗi, vàđưa ra sự đánh giá với độ tin cậy lớn

II NHỮNG VẤN ĐỀ LIÊN QUAN ĐẾN KIỂM THỬ

II.1 Vòng đời kiểm thử

Vòng đời của kiểm thử bắt đầu từ việc lập kế hoạch kiểm thử Sau đó là ghi

ra các ý tưởng các trường hợp kiểm thử Từ các trường hợp kiểm thử này đưa ratất cả các trường hợp kiểm thử và các kịch bản kiểm thử Sử dụng các thủ tục haykịch bản kiểm thử này, người kiểm thử có thể phát họa toàn bộ kiểm thử hệ thốnghay kiểm thử tích hợp Kết quả kiểm thử sẽ được đánh giá bởi các tiêu chí kiểmthử đặt ra ban đầu Mô hình kiểm thử là một dãy các kế hoạch, các trường hợpkiểm thử và các thủ tục kiểm thử Trong tiến trình bảo trì và nâng cấp dự án, thìkiểm thử đóng vai trò quan trọng

II.2 Tiến trình kiểm thử

Tiến trình kiểm thử thông thường bao gồm những bước sau:

 Thiết kế các ca kiểm thử

 Tạo dữ liệu kiểm thử: trong bước này chúng ta kiểm thử tất cảcác dữ liệu vào là cần thiết mà không thể thực hiện kiểm thử”vétcạn” và chọn tập các dữ liệu thử đại diện từ miền dữ liệu vào dựatrên các tiêu chuẩn chọn dữ liệu thử

 Thực thi chương trình trên dữ liệu thử:

II.3 Những thành phần của một kế hoạch kiểm thử

 Đầu vào để lập lên kế hoạch kiểm thử:Kế hoạch của dự án, đặc tảyêu cầu của phần mềm, người lập kế hoạch Test, người tham giaTest, thời gian kiểm thử, phạm vi Test, kinh phí giành cho việcTest, công cụ Test

 Người lập kế hoạch kiểm thử thường là trưởng nhóm Test cókinh nghiệm dựa vào các yêu cầu của phần mềm mà đưa ra phạm

vi Test cho phù hợp với trình độ người Test, thời gian, chi phí.Khi đưa ra phạm vi rồi thì làm tốt phạm vi đó thì coi như đạt yêucầu theo kế hoạch Test đưa ra

 Các công việc cần thực hiện là đầu ra của kế hoạch kiểm thử:

o Nghiên cứu tài liêu dự án(phân tích, thiết kế), tìm hiểucông cụ Test cho kiểu Test đã đặt ra

o Thiết kế Test Case theo phạm vi Test

o Thực hiện kiểm tra phần mềm theo nội dung Test Case

o Báo lỗi khi phát hiện được

o Viết báo cáo kết quả Test sau khi thực hiện xong

II.4 Những điểm cần tập trung kiểm thử trước nhất nếu không

có đủ thời gian.

 Những chức năng quan trọng nhất(mục đích) của dự án

 Những chức năng được người dùng xem nhiều nhất

 Những chức năng có thể ảnh hưởng nhiều nhất đến độ án toàn

 Những chức năng có thể ảnh hưởng nhiều nhất đến tài chính

 Những phần quan trọng nhất đối với người dùng

 Những phần có thể kiểm thử sớm nhất trong chu trình phát triểnứng dụng

 Những phần có Code phức tạp nhất

 Những phần được Code vội vả hoặc áp lực nhất

 Những phần tương tự hoặc liên quan những dự án trước và đãgây lỗi

 Những phần tương tự hoặc liên quan những dự án trước và tốnnhiều chi phí bảo trì

 Những phần mà yêu cầu và thiết kế không rõ ràng

 Những phần mà Coder xem là rủi ro nhất

II.5 Các chỉ tiêu đánh giá kiểm thử

Tiêu chí đánh giá kiểm thử là đo độ bao phủ và chất lượng của kiểm thử

 Sự bao phủ của kiểm thử là một tiêu chí quan trọng trong tiếntrình kiểm thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử

và các trường hợp kiểm thử hay toàn bộ đoạn chương trình

 Chất lượng của kiểm thử là một tiêu chí quan trọng để đánh giá

độ tin cậy, tính hiệu năng, sự ổn định của chương trình Chấtlượng của kiểm thử phụ thuộc vào việc đánh giá, phân tích đểphát hiện ra lỗi của chương trình trong suốt tiến trình kiểm thử

III MỘT SỐ LOẠI KIỂM THỬ THÔNG DỤNG

1.Mô hình phát triển chữ V

Kiểm thử và bảo trì là một pha quan trọng trong quá trình phát triểnphần mềm Sau đây là mô hình chữ V trong kiểm thử:

H II 1: The Software Development V-Model

Bên trái chữ V là quá trình phát triển phần mềm, và bên phải là kiểm thử.Tại mỗi một mức trong tiến trình phát triển thì có một pha kiểm thử tương ứng

Các mức kiểm thử có thể được lập kế hoạch và thiết kế song song Sau đóchúng ta thực hiện kiểm thử từ đáy tháp chữ V nên tương ứng với từng mức pháttriển

Kế hoạch kiểm thử hệ thống cần phải thực hiện sớm hơn trước khi phakiểm thử bắt đầu:

 Kế hoạch kiểm thử hệ thống là phải khớp với các yêu cầu phần mềm

 Các trường hợp kiểm thử cần phải hoàn thành khi mà các thiết kế chi tiết đãxong

 Kiểm thử hệ thống bắt đầu từ ngay sau khi lập trình

2 Kiểm thử unit

Kiểm thử unit ứng dụng ở mức môđun Thường là được thực hiện bởi nhàphát triển trước khi các môđun được tích hợp với các mô đun khác

Kiểm thử unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụngphươ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ỗicủ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ểmthử 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ếpcậ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ử

 Kiểm thử gốc(stub): Kiểm thử lần lượt từ gốc của chươngtrình, sau khi xong thì tiếp tục kiểm thử Stub tiếp theo ở bêndướ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.

 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 trongtừ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 chitiế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ựchiệ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 chomôđun và một danh sách các đầu ra phù hợp với các mô đun đó Mộtmôđun được gọi là đạt nếu tất cả các đầu vào đều có đầu ra tương ứng Mỗimộ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ằngmỗ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ểumộ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

 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ềukiệ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ắtnguồn từ các đặc tả yêu cầu độc lập Một tập các trường hợp kiểmthử 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 đềukiể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 đó

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ố chophù 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ântích)

Bước 5

Confirm that actual results match expected results

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

 Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả cácnhá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 trongcá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ìnhquả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ặpdừ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

Kiểm thử hệ thống bao gồm các phương pháp luận sau:

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ươngtrì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

 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

 Driver sẽ bị xoá đi và các cụm sẽ được kết hợp lại, sau đó dichuyể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ươngphá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

 Đú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ôngCá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

Kiểm thử hệ thống thường thực hiện sau tất cả các môđun, kiểm thử tíchhợ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àykhô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 tronglỗ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ịchbả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ểmthử.

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ểmnhậ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ểmthử 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ớikiể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 trongtrong 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 địnhtrong kế hoạch kiểm thử Leader kiểm thử phải xác định khi nào đội dự án kiểmsoá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ồiquy 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ềmchạ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ượngcao, sản phẩm cuối cùng nên có vài lỗi có thể.

 Một lỗi được tìm thấy và phải được ghi lại trong DMS bởi một nhânviên Lỗi được vào trong DMS với trạng thái “Error” và thông tinkhá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ôngthườ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 đổithà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áithà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:

Defect status: PENDING

Defect status:

Defect status:

7.2 Lỗi dữ liệu

Thông tin quan trọng của lỗi bao gồm:

Tuỳ chọn

lỗi

B

8 Stage detected Phạm vi hoạt động của dự án xác

định vòng đời khi lỗi được pháthiện

T

10 QC activity type Dạng của hoạt động QC như là

xem lại, kiểm tra

B

11 Stage injected Phạm vi hoạt động trong dự án

xác định vòng đời mà từ đó lỗiđược gây ra

T

12 Process origin Tên hay mã nguồn của đoạn phần

mềm mà trong đó lỗi là nguồngốc

B

thử hay người xem lại

B

15 Create date Ngày ghi lại lỗi trong dữ liệu lỗi B

16 Assigned to Người chịu trách nhiệm sửa lỗi,

thường là tác giả

T

17 Due date Hạn chót mà việc sửa lỗi phải T

22 Reference Tài liệu tham khảo hay miêu tả về

lỗi

T

23 History Thông tin về lỗi Tất cả những

phần như hiệu chỉnh, của lỗiđược thể hiện

hay những lý do khác không được xácđịnh như là vấn đề viết code

Business logic Không theo luồng công việc

2 User Interface Lỗi trong giao diện, bố cục

3 Performance tôc độ xử lý chậm hay lỗi hệ thống do

cấu hình; vấn đề bộ nhớ

4 Design issue Thiết kế được chỉ rõ liên quan vấn đề

5 Coding standard Vấn đề với chuẩn viết mã nguồn

6 Document Lỗi phát hiện trong khi xem lại văn

bản: Kế hoạch dự án, SRS, Kế hoạchkiểm thử,… liên quan tới chuẩn vănbản (mẫu, phiên bản, header/footer, )

7 Data and Database Integrity Vấn đề với xử lý dữ liệu hay luồng dữ

liệu: vào/ra

8 Security and Access Control Vấn đề với đặc quyền người dùng, vấn

đề bảo mật

9 Portability Mã nguồn không độc lập với platform

7.4 Lỗi nguy hại

# Dạng nguy hại Giải thích

dụng hệ thống, có lẽ hệ thống bị tấn công

nhưng gây ra sự bất tiện

đến hiệu năng của sản phẩm Nó có lẽ làmột lỗi ngữ pháp

được hài lòng như mong muốn

2 ASSIGNED Lỗi được xem lại và được giao sửa nó

3 PENDING Lỗi được sửa xong và được kiểm thử lại

muốn

5 ACCEPTED Lỗi không được sửa một cách hài lòng như

mong muốn, nhưng nó được chấp nhận bởi

sự nhượng bộ của tác giả hay khách hàng

6 CANCELLED Nó không là một lỗi hay lỗi được loại bỏ

bởi những hành động khác với sửa lỗi

7.6 Xử lý nguồn gốc

Xử lý nguồn gốc: là xử lý mà trong nó bị nhiễm lỗi Xác định rằng

những phân tích yêu cầu của xử lý này là của một lỗi Nó được đánh giá từ

độ tự nhiên của lỗi và những thông tin khác về lỗi

1 Contract Management 01-QT Những thủ tục không thích hợp;

những thông tin khách hàng thiếu;những yêu cầu khách hàng khônghiểu; quản lý thay đổi yêu cầukhách hàng không chặt chẽ

2 Requirements 02-QT Giả định không đúng; đặc tả giao

diện không hoàn hảo; luồng xử lýkhông rõ ràng; yêu cầu không cóđặc tả, nhập nhằng, không hoàn hảo

đủ; lôgic vấn đề; vấn đề liên quạnđến chuẩn

dữ liệu, vào/ra

5 Deployment 05-QT Sự triển khai kế hoạch không thích

hợp, giải pháp; những vấn đề môitrường

6 Customer support 06-QT Kế hoạch hỗ trợ không rõ ràng

7 Test 07-QT Sự cố gắng không thích hợp hay

lịch biểu cho kiểm thử; sự khônghoàn hảo của yêu cầu kiểm thử hayvạch kế hoạch; kiểm thử case sai;kiểm thử dữ liệu thích hợp khôngxác định; tiêu chuẩn kiểm thửkhông thích hợp

8 Configuration

management

08-QT cấu trúc quản lý cấu hình không

thích hợp; những vấn đề trong đặttên và quản lý cấu trúc; quản lýthay đổi trong kế hoạch CM cònthiếu

9 Project management 09-QT Nỗ lực hay đánh giá lập biểu không

thích hợp; những vấn đề trong đánhgiá rủi ro; sự không hoàn hảo của

kế hoạch dự án

10 Subcontract

Management

10-QT Lựa chọn nhà thầu phụ không thích

hợp; quản lý chất lượng nhà thầuphụ không chặt chẽ

7.7 Ưu tiên lỗi

PL hay tác giả có thể dựa vào ưu tiên lỗi để sửa nó

1 Immediately Lỗi phải được sửa ngay lập tức

2 High priority Lỗi nên được đưa lên mức chú ý cao hơn

3 Normal priority

4 Low priority

CHƯƠNG II NGHIÊN CỨU PHẦN MỀM SEK CỦA IBM.

The 2007 developerWorks® Software Evaluation Kit (SEK) for Windows®

là một trong trong số nhiều phần mềm có sẵn từ IBM SEK bao gồm hai DVD vớihơn 15 GB là những sản phẩm mới ra gần đây nhất của IBM Đây là công cụ pháttriển và kiểm thử, cũng như hệ thống thời gian thực từ IBM® InformationManagement, Lotus®, Rational®, Tivoli®, and WebSphere® software

Những sản phẩm đang được thiết kế cho những người muốn phát triển vàkiểm thử ứng dụng của họ sử dụng những công cụ trên nền Windows từWebSphere và Rational Và sau đó triển khai những ứng dụng của họ trênWindows, Linux, và được hỗ trợ platform middleware từ IBM InformationManagement, Lotus, Tivoli, and WebSphere

Bộ tool gồm 6 Tool nhỏ:

IBM Rational Functional Tester V7.0

IBM Rational Functional Tester là một dụng cụ thử nghiệm hồi quy tiên tiến, được sử dụng tự động hóa cho tester và người phát triển GUI Là những người cầnkiểm soát cấp cao hơn cho việc kiểm thử với công nghệ java, Microsoft® Visual Studio NET, và ứng dụng Web-based

IBM Rational Manual Tester V7.0

IBM Rational Manual Tester là công cụ kiểm thử bằng tay, và sự thực hiện đó đẩy mạnh sử dụng lại những bước kiểm thử để giảm bớt tác động (của) phần mềmthay đổi trên những tester và những người phân tích doanh nghiệp(business

analysts)

IBM Rational Method Composer V7.1

Rational Method Composer là một nền tảng của những quá trình linh hoạt chứađựng những quá trình và những công cụ sử dụng suốt (IT Lifecycle Management)Quản lý Vòng đời IT (ITLM) Rational Method Composer giúp đỡ bạn chuyển sựchỉ đạo quá trình tùy chắc chắn tới những đội dự án của các bạn và tổ chức IT,bao gồm phiên bản gần đây nhất (của)IBM Rational Unified Process® (RUP®))

IBM Rational Performance Tester V7.0

IBM Rational Performance là một sự nạp và sự thực hiện kiểm tra giải pháp cho những đội được liên quan ứng dụng Web-based của họ

IBM Rational Software Architect V7.0

IBM Rational Software Architect một công cụ thiết kế và phát triển tổng hợp với

mô hình model-driven với UML để tạo ra những ứng dụng well-architected và services (dịch vụ)

IBM Rational Systems Developer V7.0

IBM Rational Systems Developer là một công cụ thiết kế và phát triển cho phép những kiến trúc sư phần mềm and model-driven developers để tạo ra well-architected C/C++, Java™ J2SE, and ứng dụng CORBA-based cái mà bị ảnh hưởng bởi Unified Modeling Language (UML 2)

CHƯƠNG III NGHIÊN CỨU CÔNG CỤ KIỂM THỬ RATIONAL

Bất kỳ một tổ chức nào cũng có một sự tin cậy của riêng mình vào việcphát triển của những trình ứng dụng để phục vụ cho những việc cần thiết như đápứng được những chức năng của khách hàng đưa ra, để cho khách hàng tỏ ra hàilòng về chất lượng của những trình ứng dụng và những đòi hỏi về những chứcnăng, điều kiện được đáp ứng đầy đủ, và không xảy ra sự tuỳ tiện trong sản phẩm.Một thành phần chủ yếu cho sự thành công này là tính hiệu quả, quy trình kiểm traphải có tính kỷ luật tiến tới sự xác minh của những trình ứng dụng đã hoàn thành,quá trình kiểm tra phải có tính kỷ kuật để xem xét những trình ứng dụng đã hoànthành đến mức độ nào, đó là sự phù hợp thích đáng hay là vượt ra khỏi nhữngmong đợi trong đề án Lịch trình làm việc không đúng, thường xuyên thay đổinhững vấn đề chung của trình ứng dụng IBM Rational Funtional Tester được xâydựng dựa trên những vấn đề này

IBM Rational Funtional Tester làm việc như thế nào?

Rational Funtional Tester ghi lại sự tương tác trong lịch trình của nhữngngười làm việc với Java, Web, Visual Studio.Net, trên trình ứng dụng Win Form,

và Web- Form tạo ra cho việc kiểm thử một kịch bản, bằng cách mô phỏng trở lạinhững thao tác đã được thực hiện Trong lúc đó hình ảnh sẽ được ghi lại, người sửdụng có thể lồng vào thời gian xác định trong những trích đoạn theo lý thuyết mà

dữ liệu đưa ra hoặc những đặc tính mà trình ứng dụng chưa đạt đến sẽ kiểm trađược trong quá trình kiểm thử Trong quá trình quay lại, có những thời điểm xácminh các vấn đề đã thực hiện và sẽ so sánh với những thông tin được ghi chépđảm bảo theo đúng những thông tin được ghi chép Sau đó việc kiểm thử sẽ đượcghi hình một cách linh hoạt, những người kiểm thử có thể xác định được sự lựachọn ngôn ngữ để viết cho khách hàng dựa vào kịch bản, tới những việc đã vượtquá nhiệm vụ cần thực hiện, bao gồm những dữ liệu thao tác bằng tay và nhữngyêu cầu về cấu hình máy tính, những vấn đề này bảo đảm cho việc kiểm thử đượcthực hiện đúng đắn và có thể vận hành được sự kiểm thử Sau khi thực hiện xongquá trình kiểm thử

Rational Funtional Tester sẽ phát sinh ra một bảng báo cáo về những kếtquả đạt được trong quá trình kiểm thử và nó dùng để so sánh với những thời điểmxác định Với việc sử dụng Rational Funtional Tester đội dự án có nhiều điều chắcchắn về những vấn đề nó được bộc lộ một cách hiệu quả trong nhiều trình ứngdụng phức tạp, làm tăng dần cơ hội cho việc bắt được những khuyết điểm và đượcphục hồi trước khi những sản phẩm được đưa ra

III.2 NHỮNG LỢI ÍCH KHI SỬ DỤNG CÔNG CỤ IBM RATIONAL

FUNTIONAL TESTER

 Tạo sự tin cậy cho chúng ta trong việc kiểm thử các phần mềm dùng cácngôn ngữ như Java, Wed, Visual Studio.Net trên trình ứng dụng Win-Form

và Web-Form

 Là sự lựa chọn cho các phần mềm dùng ngôn ngữ Java hoặc VisualBasic.Net, nó giúp tạo ra được những kịch bản kiểm thử để so sánh vớibảng phân tích, xem có đúng theo yêu cầu của khách hàng không.

 Nơi Java, Visual Basic.Net được biên tập và gỡ rối bởi những người kiểmthử tiên tiến

 Những kịch bản bằng công nghệ cung cấp thường xuyên sự thay đổi củagiao diện người dùng

 Sự tương quan của dữ liệu một cách tự động và những dữ liệu kiểm thử cầnloại trừ sẽ tốt hơn nhiều so với việc kiểm thử bằng tay

 Những mốc kiểm tra phù hợp với những khuôn mẫu đã đưa ra

 Sự tiên tiến của năng lực được duy trì trong sơ đồ các đối tượng

 Là nơi tin cậy của việc kiểm thử và thi hành trên nền Linux

Về những tính năng chính: (About this release)

Những phần chính của IBM Rational Funtional Tester V7.0 bao gồm nhữngchức năng sau:

 Mở rộng chức năng kiểm thử cho những trình điều khiển SAP UI- Chophép bạn kiểm thử những chức năng bên ngoài của những trình điều khiểnđược xây dựng trên nền SAP frameword Kiểm thử cho tất cả các phiênbảng của hệ thống SAP R/3 được hổ trợ chạy trên nền Window Nhữngphiên bảng hiện nay được hổ trợ của SAP GUI đó là: 6.20 với mức 52 hoặcmức cao nhất là 6.40

 Mở rộng chức năng kiểm thử hổ trợ cho điều khiển Siebel 7.8

 Quy trình với Rational Process Advisor (RPA)-Giúp cho những người chưabiết và đang sử dụng những tiến trình quanh những thao tác đặt trưng sẽ thihành được

 Hổ trợ cho kiểm thử những ứng dụng trong Mozilla Firefox 1.5

 Sự tích hợp với ClearQuest Test Manager V7.0.0.1- Cho phép bạn chạy lạikịch bảng kiểm thử chức năng từ ClearQuest Test Manager, theo một nhịp

độ tự động, và kiểm tra được những lỗi Với sự tích hợp ClearQuest TestManager, bạn có thể tích hợp kịch bảng kiểm thử chức năng Test Case vàCofigured Test Case và thi hành chúng ClearQuest Test Manager cho phépbạn thi hành việc phân tích những kết quả và ghi lại những kết quả cho việcbáo cáo và phân tích.

 IBM Interllation Manager – cung cấp nhanh và đơn giản những phươngthức cài đặt, sửa đổi, cập nhật, và tháo bỏ gói cài đặt

 Hổ trợ cho Net Frameword 2.0 bao gồm hổ trợ cho những bản ghi và kiểmthử những trình ứng dụng chứa DataGridWiew và MaskeDTestBox

 Hổ trợ cho TPTP- cho phép làm theo một nhịp độ tự động sử dụng TPTP

 Hổ trợ cho việc điều khiển Eclipse 3.0

 Hổ trợ cho việc kiểm thử trên môi trường Citrix

 Hổ trợ cho việc xác minh những điểm tạm thời

Những chức năng chính này sẽ được trình bày kỷ trong phần demo của chươngtrình

III.3 NHỮNG CHIẾN LƯỢC ĐỂ SỬ DỤNG LẠI STATEMENT

Rational Funtional Tester được thiết kế tài liệu testing của bạn dưới dạngstreamline, tiết kiệm thời gian và tiền bạc Với test đúng chiến lược, giúp bạn cóthể tăng tối đa năng xuất của những tester và tiêu điểm test tài nguyên trên vùnggăng(critical)

Tạo ra, bảo trì, và nâng cấp những tài liệu kiểm tra những phiên bản có thểmất thời gian và tài nguyên quan trọng Scripts có thể trở nên lỗi thời khi nhữngsản phẩm thay đổi Và những đội testing sẽ bị thách thức để tạo ra những scriptshợp thời Rational Funtional Tester với đặc tính sử dụng lại, có thể giảm mạnhnhiệm vụ chán ngắt của bảo trì nguyên bản(scripts) Để sử dụng đặc tính này cóhiệu quả nhất, phải phát triển một chiến lược sử dụng lại Cái này bao gồm sựđồng nhất hóa và cô lập những test procedures mà được thực hiện thường xuyên

trong đoạn test của bạn và sau đó di chuyển chúng vào trong những scripts chủ màđược sử dụng lại nhiều scripts con bên kia.

Bước đầu tiên trong việc phát triển là một chiến lược sử dụng lại cho độicủa bạn sẽ xác định những ứng cử viên mà bạn muốn sử dụng lại Đây là nhữngthủ tục test dễ làm mà những người testers thực hiện nhiều lần bên trong một testhoặc băng qua một tập test:

 Những điều cần trước và những sự giả thiết

 Thiết lập môi trường hướng dẫn

 Những thủ tục test thừa, chung, hay lặp lại, như công việc đăng nhập chẳnghạn

 Những thủ tục điều khiển bằng dữ liệu mà có lẽ đã được thực hiện nhiềulần

 Thông tin đặc trưng khác được bao gồm trong một test script, như thông tintổng quan, những sự từ chối

Trong khi bạn xác định những thủ tục dùng lại được, phân chia nó vàotrong những hồ sơ riêng lẽ Những file này trở thành cở sở của một thư viện sửdụng lại tăng lên theo thời gian Một thư viện tốt chứa đựng một tập hợp nhữngmodun sử dụng lại được(test script files) Sử dụng một quy ước đặt tên cho files và

tổ chức nó vào folders khi cần Thư viện cần phải cư trú trong một khu vực thườngxuyên trên ổ mạng mà mọi người trong đội có thể truy cập

Là một testers trong đội của bạn , họ có thể mở những hồ sơ thư viện vàcopy và paste-as-reference(ctrl+R) sang scripts mới của họ Cách khác bạn muốnphát triển một file sử dụng lại mà tất cả những thành viên chia sẽ, Files này lànguồn cho Reuse View và nó hiển thị và tổ chức statements sử dụng lại từ nhiềunguồn., giữ nó trong tâm trí dường như file này chỉ đơn thuần là hiển thị thiết bị.Statement thực tế vẫn còn lưu trữ như scripts trong thư viện sử dụng lại

Để chia sẻ một hồ sơ sử dụng lại trong số những thành viên đội, đặt hồ sơtrên ỗ đĩa mạng Việc hỏi những tester điểm trỏ đến file này sử dụng những hộpthoại ưu tiên chính, Testers có còn bảo trì hồ sơ sử dụng lại bí mật Chuyển giữachúng bởi thay khu vực file sử dụng lại trong main Preferences.

III.4 RATIONAL FUNTIONAL TESTER VỚI ĐỘI PHÁT TRIỂN

Đưa vào thực tiễn tốt nhất để sử dụng trong đội của bạn để giúp đỡ hoàn

thiện hiệu quả và năng xuất với Rational Funtional Tester

Ứng dụng Rational Funtional Tester thì được dùng điển hình trong môitrường nhóm, đội, nơi mà một nhóm của tester cộng tác đến một hoặc nhiều ứngdụng phần mềm Những người phát triển, Nhân viên hỗ trợ khách hàng, và cácngười dùng khác đi sử dụng lại trong đội để tetst 1 hoặc nhiều ứng dụng phânmềm Đội phát triển, nhân viên hỗ trợ khách hàng, và những người khác hầu nhưdính dáng đến Rational Funtional Tester , scripts authors, nhà phê bình hoặc ngườinhận từ kết quả test Ở đây có vài mẹo nhỏ để cải thiện khả năng test bằngRational Funtional Tester :

 Thiết kế một chiến lược sử dụng lại(a reuse strategy.), quyết định tổ chứccủa bạn như thế nào với việc sử dụng lại test statements, và chắc chắn rằngmọi thứ theo đúng hợp đồng

 Tùy biến phần mềm phù hợp ứng dụng Rational Funtional Tester bao gồmnhững đặc tính cho việc tạo những thuộc tính và những kết quả tùy biến.Làm theo yêu cầu khách hàng có sẵn tới toàn đội bởi chỉ định một files theoyêu cầu của khách hàng

 Cộng tác với một tổ chức khác, sử dụng import đặc tính để xác nhập testscripts và thông tin khác được viết trong Microsoft® Word hoặc Excel Sửdụng đặc tính phổ biến để lưu test scripts trong html sao cho những ngườikhác có thể nhìn thấy chúng