Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng

CÔNG VIỆC CỦA MỘT KIỂM THỬ VIÊN

• Tham gia phân tích yêu cầu của khách hàng;

• Lập kế hoạch test;

• Xây dựng tiêu chuẩn nghiệm thu;

• Xây dựng hướng dẫn test (bản thiết kế test, kịch bản test);

• Thực hiện test;

• Hỗ trợ các vấn đề liên quan đến test;

• Báo cáo và tổng hợp kết quả test;

• Lập và lưu trữ các hồ sơ liên quan đến test;

• Thu thập và kiểm soát các dữ liệu liên quan đến các hoạt động test;

• Tính toán và phân tích các chỉ tiêu liên quan đến các hoạt động test

TEST CASE (TEST CASE DESIGN)

• Khái niệm: Test case là một tình huống kiểm tra được thiết kế để kiểm tra

một đối tượng xem nó có thoả mãn yêu cầu đặt ra hay không.

• Vai trò của test case:

 Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của

phần mềm một cách nhiều nhất;

 Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và

công sức nhất.

• Các thành phần cơ bản của một test case:

 Mô tả: Đặc tả các điều kiện cần có để tiến hành kiểm tra;

 Nhập: Đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu

vào để thực hiện việc kiểm tra;

 Kết quả mong chờ: Kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối

tượng đạt yêu cầu

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 1

Trang 1

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 2

Trang 2

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 3

Trang 3

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 4

Trang 4

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 5

Trang 5

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 6

Trang 6

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 7

Trang 7

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 8

Trang 8

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 9

Trang 9

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng trang 10

Trang 10

Tải về để xem bản đầy đủ

pdf 39 trang duykhanh 4580
Bạn đang xem 10 trang mẫu của tài liệu "Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng

Bài giảng Công cụ kiểm thử phần mềm - Bài 3: Kiểm thử phần mềm trong công nghiệp - Trần Mạnh Thắng
à thực hiện trong quy trình kiểm thử phần mềm.
•Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm 
 bao gồm:
  Các loại kiểm tra;
  Chiến lược kiểm tra;
  Thời gian kiểm tra;
  Phân định lực lượng kiểm tra viên.
 12
v1.1013109225
1.3. LẬP KẾ HOẠCH KIỂM THỬ - TEST PLAN (tiếp theo)
Lập kế hoạch test: 
•Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình phát triển 
 phần mềm (PTPM), ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và
 luồng dữ liệu chính đã được mô tả. 
•Bản kế hoạch này có thể được coi là bản kế hoạch chính (master test plan). Trong đó
 tất cả các kế hoạch chi tiết cho các mức kiểm tra và loại kiểm tra khác nhau đều được 
 đề cập như hình vẽ:
 Kế hoạch kiểm tra Kế hoạch kiểm tra 
 mức đơn vị mức chấp nhận 
 (Unit test plan) (Acceptance test plan)
 Kế hoạch 
 kiểm tra chính
 Kế hoạch kiểm tra (Master test plan) Kế hoạch kiểm tra 
 mức tích hợp mức hệ thống 
 (Integration test plan) (System test plan)
 13
v1.1013109225
1.3. LẬP KẾ HOẠCH KIỂM THỬ - TEST PLAN (tiếp theo)
Các bước lập kế hoạch test:
•Xác định yêu cầu kiểm tra;
•Khảo sát rủi ro;
•Xác định chiến lược kiểm tra;
•Xác định nhân lực,vật lực;
•Lập kế hoạch chi tiết;
•Tổng hợp và tạo các bản kế hoạch kiểm tra;
• Xem xét các kế hoạch kiểm tra.
 14
v1.1013109225
1.4. THIẾT KẾ TEST
•Thiết kế test nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên 
 bản phần mềm; 
• Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm 
 tra “quét” hết tất cả yêu cầu cần kiểm tra;
•Việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm 
 hoặc bớt xuyên suốt chu kỳ PTPM, vào bất cứ lúc nào có sự thay đổi yêu cầu hoặc 
 sau khi phân tích thấy cần được sửa chữa hoặc bổ sung;
•Thời điểm phù hợp để thiết kế test.
 Chuyển giao 
 Dự án bắt đầu Các thời điểm lập kế hoạch kiểm tra cho khách hàng
 Yêu cầu Thiết kế Viết code Kiểm tra Bổ sung
 Kế hoạch kiểm tra chính (Master test plan)
 Kế hoạch kiểm tra mức chấp nhận (Acceptance test plan)
 Kế hoạch kiểm tra mức hệ thống (System test plan)
 Kế hoạch kiểm tra mức tích hợp (Integration test plan)
 Kế hoạch kiểm tra mức đơn vị (Unit test plan)
 15
v1.1013109225
1.4. THIẾT KẾ TEST (tiếp theo)
Các bước thiết kế test:
•Xác định và mô tả Test Case;
•Mô tả các bước chi tiết để kiểm tra;
•Xem xét vàkhảo sát độ bao phủ của việc kiểm tra;
• Xem xét Test Case và các bước kiểm tra.
 16
v1.1013109225
1.5. PHÁT TRIỂN TEST SCRIPT
• Phát triển Test Script thường không bắt buộc trong các loại và mức kiểm tra, 
 chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các Test 
 Script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các 
 bước kiểm tra đã định nghĩa ở bước thiết kế test.
•Các bước phát triển Test Script bao gồm:
  Tạo Test Script; 
  Kiểm tra Test script;
  Thành lập các bộ dữ liệu ngoài dành cho các Test Script; 
  Xem xét và khảo sát độ bao phủ của việc kiểm tra.
 17
v1.1013109225
1.6. ĐÁNH GIÁ KẾT QUẢ TEST
• Đánh giá kết quả test là việc đánh giá toàn bộ quá trình kiểm thử bao gồm 
 xem xét và đánh giá kết quả kiểm thử, liệt kê lỗi, chỉ định các yêu cầu thay 
 đổi và tính toán các số liệu liên quan đến quá trình kiểm thử như số giờ, 
 thời gian kiểm thử, số lượng lỗi, phân loại lỗi, 
•Việc đánh giá kết quả kiểm thử được tiến hành song song với bất kỳ lần 
 kiểm thử nào và chỉ chấm dứt khi quá trình kiểm thử đã hoàn thành.
 18
v1.1013109225
2. MÔ HÌNH KIỂM THỬ PHẦN MỀM TTM
2.1. Giới thiệu;
2.2. Cấu trúc của mức trưởng thành của TMM;
2.3. Ý nghĩa của các mức trưởng thành.
 19
v1.1013109225
2.1. GIỚI THIỆU
• TMM là một mô hình kiểm thử phần mềm;
• TMM được các chuyên gia đánh giá cao;
•Dùng để đáng giá và nâng cao năng lực kiểm thử phần mềm của một số tổ chức;
• Được phát triển từ năm 1996 tại IIT (Illinois Institute of Technology – Viện công nghệ 
 Illinois);
•Không được sử dụng rộng rãi;
•Tài liệu về TMM rất ít;
• Là mô hình chuyên biệt cho lĩnh vực KTPM;
•Các mức trưởng thành của TMM trực tiếp mô tả các mục tiêu trưởng thành của một 
 quy trình KTPM;
•Cóthể dùng riêng hoặc kết hợp với CMM/CMMi;
•Mục đích của TMM là hỗ trợ tổ chức phần mềm đánh giávàcải tiến các quy trình và 
 năng lực phần mềm của mình.
 20
v1.1013109225
2.1. GIỚI THIỆU (tiếp theo)
•Mục tiêu của TMM: Giúp các tổ chức phần mềm có thể:
  Hoàn thành sản phẩm đúng hạn và trong phạm vi ngân sách đã định;
  Tạo ra sản phẩm phần mềm có chất lượng cao hơn;
  Xây dựng nền tảng cho việc cải tiến quy trình ở phạm vi rộng trong một tổ chức.
• Các thành phần chính của TMM:
  Tập hợp 5 mức độ trưởng thành, định nghĩa năng lực KTPM của một tổ chức. Mỗi 
 mức độ bao gồm:
 . Mục tiêu;
 . Hoạt động để hiện thực các mục tiêu;
 . Công việc và phân công trách nhiệm.
  Mô hình đánh giá năng lực KTPM của một tổ chức, bao gồm:
 . Bảng câu hỏi đánh giá;
 . Thủ tục tiến hành đánh giá;
 . Hướng dẫn để chọn lựa và huấn luyện nhóm đánh giá.
 21
v1.1013109225
2.1. GIỚI THIỆU (tiếp theo)
 Mức 5: Tối ưu hóa, phòng ngừa lỗi và kiểm 
 soát chất lượng
05 Mức trưởng thành của TMM
 •Tối ưu hóa quy trình kiểm tra phần mềm;
 •Kiểm soát chất lượng;
 • Phòng ngừa sai sót.
 Mức 4: Quản lý và đo lường
 • Đánh giá chất lượng phần mềm;
 • Đo lường việc kiểm tra phần mềm;
 •Chương trình xem xét xuyên dự án.
 Mức 3: Tích hợp
 •Kiểm soát và giám sát quy trình kiểm tra;
 •Tích hợp kiểm tra phần mềm;
 •Thiết lập chương trình huấn luyện kỹ thuật;
 •Thiết lập tổ chức kiểm tra phần mềm.
 Mức 2: Định nghĩa
 •Kỹ thuật và phương pháp kiểm tra cơ bản;
 • Quy trình cho việc lập kế hoạch kiểm tra;
 •Mục tiêu dò lỗi và kiểm tra phần mềm.
 Mức 1: Khởi đầu 22
v1.1013109225
2.2. CẤU TRÚC CỦA MỘT MỨC TRƯỞNG THÀNH CỦA TTM
 Mức
 trưởng thành
 Biểu thị Bao gồm
 Năng lực Các mục tiêu
 kiểm tra trưởng thành
 Hỗ trợ bằng
 Các mục
 tiêu con
 Đạt được thông qua
 Công việc
 Thể hiện và trách nhiệm
 Thi hành Sự tham gia từ
 và phân công thực hiện Các nhóm
 từ tổ chức tham gia
 Nhóm quản lý Khách hàng,
 người dùng
 Lập trình viên,
 kiểm tra viên
 23
v1.1013109225
2.2. CẤU TRÚC CỦA MỘT MỨC TRƯỞNG THÀNH CỦA TTM (tiếp theo)
Các mức trưởng thành trừ mức độ thấp nhất là 1. Cấu trúc gồm các thành phần sau:
•Mục tiêu trưởng thành: 
  Xác định các mục tiêu cần phải đạt trong việc cải tiến quy trình KTPM;
  Để đạt một mức trưởng thành, tổ chức phải đạt tất cả các mục tiêu của mức 
 trưởng thành đó.
•Mục tiêu con: 
  Các mục tiêu trưởng thành đã nói ở trên có tầm bao quát rộng. Do vậy để làm 
 rõ hơn phạm vi cũng như những công việc cần làm để đạt được một mục tiêu, 
 mỗi mục tiêu lại được mô tả rõ hơn thông qua những mục tiêu con, dễ hiểu và
 cụ thể hơn;
  Nếu ta đạt được tất cả mục tiêu con của một mục tiêu nghĩa là ta đã đạt được 
 mục tiêu đó.
 24
v1.1013109225
2.2. CẤU TRÚC CỦA MỘT MỨC TRƯỞNG THÀNH CỦA TTM (tiếp theo)
•Công việc và trách nhiệm: Mô tả rõ hơn các công việc cần làm, cũng như ai trong 
 dự án (trưởng dự án, lập trình viên, kiểm tra viên) sẽ thực hiện các công việc đó. 
 Nghĩa là, để đạt được một mục tiêu con, ta cần thực hiện tất cả các công việc 
 được đề nghị cho mục tiêu con đó;
•Sự tham gia của các nhóm khác nhau: TMM cho rằng có 3 nhóm người quan trọng 
 với cách nhìn và quan điểm khác nhau ảnh hưởng đến công việc KTPM, đólà 
 người quản lý/quản lý dự án, lập trình viên/kiểm tra viên, và khách hàng/người sử
 dụng. Do vậy mô hình TMM yêu cầu các công việc phải được phân trách nhiệm cho 
 3 nhóm người này.
 25
v1.1013109225
2.3. Ý NGHĨA CỦA CÁC MỨC TRƯỞNG THÀNH
 Mức 5: Tối ưu hóa, phòng ngừa lỗi và kiểm 
 soát chất lượng
05 Mức trưởng thành của TMM
 •Tối ưu hóa quy trình kiểm tra phần mềm;
 •Kiểm soát chất lượng;
 • Phòng ngừa sai sót.
 Mức 4: Quản lý và đo lường
 • Đánh giá chất lượng phần mềm;
 • Đo lường việc kiểm tra phần mềm;
 •Chương trình xem xét xuyên dự án.
 Mức 3: Tích hợp
 •Kiểm soát và giám sát quy trình kiểm tra;
 •Tích hợp kiểm tra phần mềm;
 •Thiết lập chương trình huấn luyện kỹ thuật;
 •Thiết lập tổ chức kiểm tra phần mềm.
 Mức 2: Định nghĩa
 •Kỹ thuật và phương pháp kiểm tra cơ bản;
 • Quy trình cho việc lập kế hoạch kiểm tra;
 •Mục tiêu dò lỗi và kiểm tra phần mềm.
 Mức 1: Khởi đầu 26
v1.1013109225
2.3.1. Ý NGHĨA CỦA MỨC TRƯỞNG THÀNH 1
•Mức khởi đầu của đa số tổ chức phần mềm;
•Không cómục tiêu nào đặt ra cho mức này; 
• Quy trình kiểm thử phần mềm hoàn toàn hỗn độn;
•Kiểm thử phần mềm được thực hiện một cách không dự tính và phi thể thức sau khi 
 code được viết xong; không có kế hoạch, không có quy trình;
• Ở mức này kiểm thử phần mềm đồng nghĩa với tìm lỗi (debugging). Một lập trình viên 
 viết code, sau đótìm lỗi, sửa chữa, dò lỗi cho đến khi đạt yêu cầu;
•Kiểm tra viên không được huấn luyện, tài nguyên cần thiết cũng không đầy đủ;
•Do hầu như chỉ có lập trình viên làm mọi thứ, chi phí kiểm tra hầu như không biết 
 trước hoặc được bao gồm trong chi phí phát triển phần mềm.
 27
v1.1013109225
2.3.2. Ý NGHĨA CỦA MỨC TRƯỞNG THÀNH 2
• Định nghĩa: KTPM là một quy trình riêng biệt, là một chặng của toàn bộ chu trình 
 PTPM và hoàn toàn phân biệt với công việc dò tìm lỗi (debug);
•Mục tiêu của kiểm tra nhằm chứng minh PM hoặc hệ thống đáp ứng được yêu cầu;
•KTPM được lập kế hoạch chi tiết và được theo dõi chặt chẽ;
• Quy trình kiểm tra có thể được sử dụng lặp lại trong các dự án khác nhau;
•Kế hoạch kiểm tra thường được hoàn thành sau khi đã xong giai đoạn viết code;
•Kỹ thuật và phương pháp kiểm tra cơ bản được thiết lập và đưa vào sử dụng;
•Các mục tiêu của mức 2 bao gồm:
  Phát triển các mục tiêu dò lỗi và kiểm tra phần mềm;
  Quy trình lập kế hoạch kiểm tra;
  Thể chế hóa các kỹ thuật và phương pháp kiểm tra cơ bản.
 28
v1.1013109225
2.3.3. NGHĨA CỦA MỨC TRƯỞNG THÀNH 3
•Một nhóm kiểm tra viên được thành lập như một bộ phận trong công ty. Kiểm tra viên 
 được huấn luyện kỹ và đặc biệt;
•KTPM không còn làmột chặng, mà được thực hiện xuyên suốt toàn bộ chu kỳ PTPM;
•Việc sử dụng công cụ kiểm tra tự động bắt đầu được tính đến;
•Kế hoạch kiểm tra được thực hiện sớm hơn nhiều so với mức trưởng thành 2;
• Quy trình kiểm tra giám sát, tiến độ và hiệu quả kiểm tra được kiểm soát chặt chẽ;
•Mục tiêu của mức 3 bao gồm:
  Thiết lập bộ phận KTPM;
  Thiết lập chương trình huấn luyện kỹ thuật;
  Tích hợp KTPM vào chu kỳ PTPM;
  Kiểm soát và giám sát quy trình kiểm tra.
 29
v1.1013109225
2.3.4. Ý NGHĨA CỦA MỨC TRƯỞNG THÀNH 4 
•Một chương trình xem xét cấp công ty được thành lập với mục tiêu loại bỏ sai sót 
 trong sản phẩm kể cả sản phẩm trung gian bằng kỹ thuật xem xét ngang hàng 
 (peer review – kỹ thuật phổ biến để phát hiện lỗi sớm trên các sản phẩm và sản 
 phẩm trung gian không thi hành được như yêu cầu khách hàng, bản thiết kế, mã 
 nguồn, kế hoạch kiểm tra được thực hiện bởi một nhóm người cùng làm việc);
• Quy trình kiểm tra là một quy trình định lượng. Các chỉ số liên quan đến KTPM được 
 định nghĩa và thu thập nhằm phân tích, khảo sát chất lượng và hiệu quả của quy 
 trình kiểm tra;
•Mục tiêu của mức 4 bao gồm:
  Thiết lập chương trình xem xét xuyên suốt các dự án trong công ty;
  Thiết lập chương trình đo lường việc KTPM;
  Đánh giá chất lượng PM.
 30
v1.1013109225
2.3.5. Ý NGHĨA CỦA MỨC TRƯỞNG THÀNH 5
•Dữ liệu liên quan đến các sai sót đã thu thập (ở mức 4) được phân tích để tìm ra 
 nguyên nhân gốc phát sinh các sai sót đó. Căn cứ vào các nguyên nhân này, hành 
 động phòng ngừa được thiết lập và thi hành. Các phép thống kê được dùng để ước 
 lượng tính tin cậy của phần mềm, cũng như làm cơ sở cho các quyết định liên quan 
 đến xác định các mục tiêu về độ tin cậy của phần mềm. Chi phí và tính hiệu quả của 
 KTPM được giám sát chặt chẽ, công cụ kiểm tra tự động được sử dụng rộng rãi;
•Mặt khác, ở mức 5, quy trình KTPM phải được cải tiến một cách liên tục, nhằm khắc 
 phục những yếu kém của quy trình, cũng như hướng đến những mục tiêu xa hơn;
•Mục tiêu của mức 5 bao gồm:
  Sử dụng dữ liệu thu thập để phòng ngừa sai sót;
  Kiểm soát chất lượng;
  Tối ưu hóa quy trình KTPM.
 31
v1.1013109225
3. CÁC CÔNG CỤ KIỂM THỬ
3.1. Vai trò của công cụ kiểm thử;
3.2. Khái quát về kiểm thử tự động;
3.3. Công cụ kiểm thử tự động;
3.4. Kiểm thử đơn vị với công cụ jUnit;
3.5. Kiểm thử với công cụ quicktest pro.
 32
v1.1013109225
3.1. VAI TRÒ CỦA CÔNG CỤ KIỂM THỬ
•Giảm nhân lực kiểm thử và công sức thực hiện kiểm thử;
•Giảm thời gian kiểm thử;
•Giảm sai sót và tăng độ tin cậy;
•Giảm sự nhàm chán;
•Rèn luyện kỹ năng lập trình cho kiểm thử viên;
•Giúp thực hiện việc kiểm thử phần mềm một cách tự động và nó thường được 
 sử dụng khi:
  Không đủ tài nguyên;
  Kiểm tra khả năng vận hành trong một môi trường đặc biệt.
 33
v1.1013109225
3.2. KHÁI QUÁT VỀ KIỂM THỬ TỰ ĐỘNG
Các bước thực hiện kiểm thử tự động:
•Tạo Test Script;
•Chỉnh sửa Test Script;
•Chạy Test Script để KTTĐ;
• Đánh giá kết quả.
 34
v1.1013109225
THUẬN LỢI VÀ KHÓ KHĂN CỦA KIỂM THỬ TỰ ĐỘNG
•Không cần sự can thiệp của kiểm thử viên;
•Giảm chi phí thực hiện khi kiểm thử với số lượng lớn hoặc phải lặp lại nhiều lần;
•Giả lập được các tình huống khó có thể làm thủ công;
•Mất các chi phí để tạo các script;
•Yêu cầu kiểm thử viên phải có kỹ năng cao để tạo các script KTTĐ;
•Không áp dụng khi tìm lỗi mới của phần mềm.
 35
v1.1013109225
3.3. CÔNG CỤ KIỂM THỬ TỰ ĐỘNG
• QuickTest Professional (QTP) của Mercury; 
• WinRunner;
• Rational Robot;
• SkilkTest;
•Jtest;
•Nunit;
•Junit;
• Load Runner
 36
v1.1013109225
3.4. KIỂM THỬ ĐƠN VỊ VỚI CÔNG CỤ JUNIT
• Định nghĩa: jUnit là một framework đơn giản dùng cho việc tạo các kiểm thử đơn vị
 tự động và chạy các kiểm thử có thể lặp đi lặp lại. Nó chỉ là một phần của họ kiến 
 trúc xUnit cho việc tạo các kiểm thử đơn vị. jUnit là một chuẩn trên thực tế cho 
 kiểm thử đơn vị trong Java;
•JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma và Kent Beck;
•JUnit cóthể tham khảo tại:
   
  Java eXtreme Programming Cookbook – Eric M. Burkev & Brian M. Coyner, 
 O’Reilly;
  Test Driven Development By Example – Addison Wesleyv. 
 37
v1.1013109225
3.5. KIỂM THỬ VỚI CÔNG CỤ QUICK TEST PRO
• Quicktest professional (QTP) dùng để kiểm tra chức năng và cho phép thực hiện 
 kiểm tra hồi quy một cách tự động.
•Hỗ trợ sẵn cho các loại chương trình thông dụng như:
  Ứng dụng windows chuẩn/win32;
  Ứng dụng web theo chuẩn HTML, XML chạy trog trình duyệt Internet Explorer, 
 Netscape hoặc AOL;
  Visual Basic, ActiveX, Unicode.
•Một số chương trình phải thêm thành phần bổ xung như: .NET, Java, Oracle, 
 38
v1.1013109225
TÓM LƯỢC CUỐI BÀI
 •Nắm được các khái niệm về test case và test script;
 •Nắm được quy trình kiểm thử phần mềm;
 •Nắm được khái niệm, nguồn gốc xuất xứ và mô hình TMM;
 •Nắm được vai trò của kiểm thử tự động, các công cụ kiểm 
 thử tự động cũng như quy trình kiểm thử tự động.
 39
v1.1013109225

File đính kèm:

  • pdfbai_giang_cong_cu_kiem_thu_phan_mem_bai_3_kiem_thu_phan_mem.pdf