Vai trò của kiểm thử tự động trong quy trình kiểm thử phần mềm

1.2 Luận văn tập trung nghiên cứu về sự tự động hóa trong kiểm thử phần mềm gồm khái niệm, lợi ích và cách thức thực hiện tự động hóa, chỉ ra một số công cụ kiểm thử phần mềm và tập tru

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

3.2 M Ô HÌNH CHUNG CủA Tự ĐộNG HÓA KIểM THử PHầN MềM 17

3.3.1 Lý do sử dụng công cụ kiểm thử 18 3.3.2 Các bước thực hiện kiểm thử tự động 19 3.3.3 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm 20

CHƯƠNG 4 – TÌM HIểU CÔNG Cụ TESTCOMPLETE 9 26

4.8 Đ ÁNH GIÁ CÔNG Cụ KIểM THử T EST C OMPLETE 9 56

4.8.1 So với mô hình chung của kiểm thử tự động 56 4.8.2 So với công cụ kiểm thử khác 57

BẢNG CÁC CHỮ VIẾT TẮT

DANH SÁCH CÁC HÌNH VÀ BẢNG BIỂU

Hình 2.2 Mô hình chữ V hiển thị thiết kế kiểm thử sớm 12

Hình 3.1 Mô hình chung của tự động hóa kiểm thử 17 Hình 3.2 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm 20 Hình 4.1 Giao diện Project Explorer của TestComplete 29 Hình 4.2 Cửa sổ làm việc chính của TestComplete 30

Hình 4.6 Ứng dụng hộp trắng trong TestComplete 33

Hình 4.11 Thêm tùy chọn Autorun cho ứng dụng kiểm thử 37 Hình 4.12 Thiết lập chế độ hiển thị trực quan kiểm thử 38

Hình 4.15 Chức năng Append to Test trên thanh công cụ của trình soạn thảo 42

Hình 4.17 Giao diện quản lý bệnh nhân Patients Management 42 Hình 4.18 Hộp thoại chỉnh sửa thông tin bệnh nhân 43 Hình 4.19 Giao diện hiển thị các tùy chọn cho Checkpoint 44

Hình 4.23 Giao diện Visualizer Frame 47 Hình 4.24 Giao diện hiển thị các thao tác trong ca kiểm thử 48 Hình 4.25 Thao tác đăng nhập hệ thống đang kiểm thử 49 Hình 4.26 Thao tác chỉnh sửa thông tin bệnh nhân 50 Hình 4.27 Tổ chức cấu trúc cây các thao tác trong TestComplete 9 51 Hình 4.28 Giao diện hiển thị chức năng Run Test 52 Hình 4.29 Cửa sổ hiển thị quá trình thực hiện kiểm thử 53

Hình 4.31 Giao diện Log hiển thị kết quả kiểm thử 55 Hình 4.32 Giao điện hiển thị chi tiết thao tác tạo lỗi 56 Hình 4.33 TestComplete 9 trong mô hình chung của tự động hóa kiểm thử 57

Hình 4.36 Lược đồ tuần tự trong UML của giao thức thiết kế - SAECA 63 Hình 4.37 Phân tích dữ liệu ECG và chèn thêm thông tin của mẫu 64

Hình 4.40 Mô hình trạng thái của module lưu trữ dữ liệu 66

Hình 4.47 Kết quả chạy thực tế bằng TestComplete 9 70 Hình 4.48 Kết quả chạy kiểm thử của TestComplete 9 70

chạy bằng tay

Trong lĩnh vực Kiểm thử tự động hiện có khá nhiều công cụ kiểm thử thương mại nổi tiếng, phổ biến như TestComplete, QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest,…Trong số đó, Test Complete phiên bản 9 của Automated‟s QA SmartBear khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm thử tự động Nó có thể thực thi kiểm thử ở nhiều mức: Kiểm thử đơn vị, tích hợp, hệ thống và chấp nhận Đây là một trong những loại công cụ phổ biến nhất đang được sử dụng hiện nay

Việc thực hiện kiểm chứng thiết kế trong quá trình tạo ra sản phẩm phần mềm đặc biệt là những phần mềm phức tạp sẽ giúp làm tăng hiệu quả kinh tế nhờ việc phát hiện lỗi sớm – ngay từ bước thiết kế phần mềm sẽ rút ngắn thời gian và chi phí hoàn thành sản phẩm, đảm bảo tính tin cậy, an toàn của hệ thống được làm ra Tuy nhiên, thiết kế thường không ở dạng chương trình có thể cài đăt và chạy được Một câu hỏi đặt ra ở đây là liệu có thể áp dụng công cụ kiểm thử vào kiểm chứng thiết kế không? Trả lời cho câu hỏi này luận văn có trình bày cách tiếp cận dùng công cụ kiểm thử vào việc kiểm thử thiết kế mà cụ thể ở đây là công cụ kiểm thử TestComplete 9 Dùng kỹ thuật trừu tượng hóa, biến đổi thiết kế thành mô hình có thể tiến hành để kiểm thử bằng công cụ kiểm thử nhằm phát hiện lỗi ở giai đoạn sớm hơn

1.2

Luận văn tập trung nghiên cứu về sự tự động hóa trong kiểm thử phần mềm gồm khái niệm, lợi ích và cách thức thực hiện tự động hóa, chỉ ra một số công cụ kiểm thử phần mềm và tập trung vào việc tìm hiểu công cụ kiểm thử TestComplete 9 – công cụ đang được sử dụng khá phổ biến hiện nay Ngoài ra, luận văn có trình bày một phương pháp sử dụng công cụ kiểm thử TestComplete trong kiểm chứng thiết kế phần mềm

1.3

Phần còn lại của luận văn có cấu trúc như sau:

Chương 2: Quy trình kiểm thử phần mềm Chương này trình bày về mô hình phát triển phần mềm và quy trình kiểm thử trong các mô hình phát triển phần mềm

Chương 3: Các kỹ thuật kiểm thử phần mềm Chương này trình bày sơ qua về hai

kỹ thuật kiểm thử: Hộp đen (Black box), Hộp trắng (White box) và việc lựa chọn kiểu kiểm thử cho hệ thống phần mềm

Chương 4: Tự động hóa trong kiểm thử phần mềm Chương này trình bày về khái niệm, mô hình chung của tự động hóa kiểm thử, lợi ích và cách thức thực hiện tự động hóa trong kiểm thử phần mềm Giới thiệu một số công cụ kiểm thử tự động và đi sâu vào việc tìm hiểu công cụ kiểm thử TestComplete 9 Trình bày phương pháp sử dụng công cụ kiểm thử này trong kiểm chứng thiết kế

Chương 2 – QUY TRÌNH KIỂM THỬ PHẦN MỀM

quy trình phát triển phần mềm là điều quan trọng Nếu chỉ viết nh

), bạn sẽ thấy các phương thức bạn sử dụng

sẽ khác nhiều so với những gì các công ty lớn sử dụng để phát triển phần mềm Để tạo

ra một sản phẩm phần mềm lớn có thể bao gồm hàng chục, hàng trăm, thậ

làm việc chặt chẽ.Chi tiết về những việc họ làm, cách thức họ tương tác, và cách thức

họ quyết định là những thành phần trong quy trình phát triển phần mềm

2.1 Quy trình phát triển phần mềm:

2.2 Quy trình kiểm thử phần mềm

Quy trình kiểm thử gồm các hoạt động sau:

− Kế hoạch kiểm thử (test planning)

− Thiết kế kiểm thử (test design)

− Triển khai kiểm thử (test implementation)

− Thực thi kiểm thử (test execution)

− Đánh giá kiểm thử (test evaluation)

Quy trình kiểm thử được mô tả trong hình vẽ dưới đây:

Hình 2.1: Quy trình kiểm thử phần mềm

Mỗi hoạt động đều có một sự chuyển giao riêng từ khâu này đến khâu khác Cuối cùng, các báo cáo lỗi và tài liệu sẽ cho kết quả Đội triển khai sẽ sử dụng các tài liệu này để xác định nguyên nhân gây ra lỗi và sửa chữa chúng

Sau khi kế hoạch kiểm thử được xây dựng, dựa trên đầu vào cụ thể (ngân sách, nguồn lực, thời gian), bước tiếp theo là phân tích các yêu cầu và xác định mục tiêu kiểm thử cho đội kiểm thử

Pha thiết kế kiểm thử chủ yếu tập trung vào xác định và thiết kế các thủ tục kiểm thử Ở bước này một quyết định sẽ được làm là xác định những gì cần kiểm thử bằng tay và những gì sẽ được kiểm thử tự động

Các ca kiểm thử và các thủ tục kiểm thử là kết quả của pha triển khai kiểm thử Các kịch bản kiểm thử (Test scripts) được viết bằng các ngôn ngữ lập trình xác định như Visual Basic, Java hoặc C++ Ở pha này, một số kịch bản kiểm thử có thể được sử dụng lại từ các kiểm thử trước đó

Thực thi kiểm thử có các kế hoạch và thủ tục kiểm thử như là đầu vào Sau khi thực thi các kiểm thử, kết quả kiểm thử được đánh giá bằng một Oracle Oracle ở đây

là một chuyên gia có thể quyết định được kết quả đó là đúng hay sai

2.3 Giai đoạn phần mềm

Kiểm thử thường được xem là công việc sẽ được làm sau khi phần mềm đã được viết Điều này làm cho giả định rằng kiểm thử chỉ đơn thuần là thực hiện việc kiểm tra, chạy các kiểm thử Dĩ nhiên, các kiểm thử không thể được thực thi mà không có phần mềm cái đã thực sự làm việc Tuy nhiên, các hoạt động kiểm thử sẽ gồm nhiều hơn so với việc chỉ chạy các ca kiểm thử

Mô hình chữ V của phát triển phần mềm minh họa khi nào hoạt động kiểm thử sẽ diễn ra Mô hình này chỉ ra rằng mỗi hoạt động phát triển phần mềm có một hoạt động kiểm thử tương ứng

Mô hình chữ V được đơn giản hóa ở hình vẽ 2.2 chỉ ra bốn mức của hoạt động kiểm thử và phát triển Các tổ chức khác nhau có thể có cách đặt tên khác nhau cho mỗi giai đoạn Điều quan trọng là mỗi giai đoạn bên trái của mô hình có một đối tác bên phải, bất kể là giai đoạn nào

Yếu tố quan trọng nhất để một ứng dụng thành công trong mô hình chữ V là vấn

đề khi nào các ca kiểm thử được thiết kế Hoạt động thiết kế kiểm thử luôn luôn tìm thấy lỗi trong bất kỳ ca kiểm thử nào được thiết kế đối với Chẳng hạn, thiết kế các ca kiểm thử chấp nhận sẽ tìm lỗi trong yêu cầu, thiết kế các ca kiểm thử hệ thống sẽ tìm lỗi trong đặc tả chức năng, thiết kế các ca kiểm thử tích hợp sẽ tìm lỗi trong thiết kế,

và thiết kế các ca kiểm thử đơn vị sẽ tìm lỗi trong mã chương trình Nếu việc thiết kế kiểm thử được để lại sau cùng, các lỗi sẽ chỉ được tìm thấy ngay trước khi các ca kiểm thử sẽ được chạy thì việc chỉnh sửa chúng sẽ rất tốn kém

Việc thiết kế kiểm thử không cần phải đợi cho đến khi ca kiểm thử sẽ được thực thi; nó có thể được tạo ở bất kỳ thời điểm nào sau khi có tài liệu để tạo nó Như vậy, việc tìm lỗi mới thực sự hiệu quả bởi các lỗi có thể được chỉnh sửa trước khi chúng được lan truyền

2.2: Mô hình chữ V hiển thị thiết kế kiểm thử sớm

Dĩ nhiên, các ca kiểm thử không thể được thực hiện cho đến khi phần mềm đã được làm, nhưng chúng có thể được tạo sớm Thực tế, các kiểm thử được thực thi theo thứ tự ngược với thời điểm tạo chúng, ví dụ các ca kiểm thử đơn vị được tạo sau nhưng chúng lại được thực hiện trước

2.4 Các kỹ thuật kiểm thử phần mềm

2.4.1 Kiểm thử hộp trắng (White-box)

Khi biết được cấu trúc của sản phẩm, kiểm thử có thể kiểm soát được một cách chắc chắn bản chất thao tác thực hiện có theo đặc tả kỹ thuật không? Và các thành phần có được thực hiện hợp lý không?

ỹ thuật trong mã lệnh, bao gồm các kỹ thuật sau:

− Phân đoạn sự kiện: mỗi phân đoạn của cấu trúc điều khiển mã lệnh được thi hành theo sự phân đoạn nhỏ nhất

− Phân nhánh sự kiện hoặc kiểm thử nút: mỗi nhánh trong mã lệnh được thực hiện theo mỗi hướng có thể thực hiện được theo mức nhỏ nhất

− Sự kiện điều kiện ghép: Khi có nhiều điều kiện, chúng ta không cần kiểm thử từng hướng (từng điều kiện) nhưng phải kết hợp các hướng có thể thực hiện được của điều kiện, cách thường dùng là bảng chân lý

− Kiểm thử đường đi cơ bản: Mỗi đường đi độc lập từ đầu đến cuối trong mã lệnh trong trình tự đã được xác định trước

− Kiểm thử theo luồng dữ liệu (DFT - Data Flow Testing): phương pháp này thực hiện kiểm tra các biến đặc trưng trong mỗi tính toán có thể được thực thi, như vậy hạn chế thiết lập các đường trung gian từ đầu đến cuối mã lệnh, … đây là cơ

sở trên mỗi mảnh của mã lệnh để chọn và kiểm tra

− Kiểm thử đường đi: kiểm thử đường đi là kiểm thử kiểm thử tất cả các đường đi

có thể thực hiện được từ đầu đến cuối mã lệnh được định nghĩa và chuyển đổi Kiểm thử này rất phức tạp và tốn thời gian

− Kiểm thử vòng lặp: bổ sung đơn vị đo lường lớn nhất, đó là chiến lược kiểm thử căn bản trong kiểm thử vòng lặp Chiến lược này hướng tới việc kiểm thử các vòng lặp đơn, các vòng lặp ràng buộc nhau, và các vòng lặp lồng nhau

các tình huống kiểm thử mà:

− Đảm bảo tất cả các đường đi độc lập trong module được thực thi ít nhất một lần

− Sử dụng tất cả các quyết định logic trong các giá trị của nó (đúng hoặc sai)

− Thực thi được tất cả các vòng lặp

− Sử dụng các cấu trúc dữ liệu của nó để đảm bảo giá trị của chúng

nhiều lỗ hổng của các nhược điểm trong lập trình như:

− Các lỗi logic và các giả định không đúng bị đảo ngược Lỗi này xuất hiện khi thiết kế và thực thi các hàm chức năng, các điều kiện hoặc các điều khiển

− Luồng logic của chương trình có những khác thường, nghĩa là giả định của chúng

ta về luồng của điều khiển và dữ liệu có thể tạo ra các lỗi thiết kế mà nó chỉ có thể phát hiện được khi dùng kiểm thừ đường đi

− Lỗi sinh các giá trị ngẫu nhiên

Kỹ năng yêu cầu

ĩa tất cả các đường logic, mở rộng các tình huống kiểm thử để thực thi và đánh giá kết quả trả

về… Nói chung là các tình huống kiểm thử thực thi được tất cả các vấn đề trong chương trình

Để thực hiện được điều này chúng ta phải nắm được chương trình, đặc tả kỹ thuật và mã lệnh được kiểm thử

:

− Công cụ dò tìm lỗ hổng bộ nhớ và lỗi run-time

− Công cụ ghi lại chính xác thời gian sử dụng ứng dụng trong khối nhất định của

mã lệnh cho mục đích tìm kiếm những đoạn mã không hiệu quả

− Công cụ xác định các vùng của ứng dụng được hoặc không được thực thi

2.4.2

Với kiểm thử hộp đen, người kiểm thử không cần biết đến cấu trúc hoặc cơ chế làm việc bên trong hộp đen mà cái cần quan tâm là chức năng của nó

Kỹ thuật kiểm thử nền tảng đồ thị

Kiểm thử phần mềm bắt đầu bằng việc tạo ra đồ thị của các đối tượng quan trọng

và các mối liên quan tới nó, sau đó đưa ra một chuỗi các kiểm thử mà nó bao hàm được đồ thị để thực thi được các đối tượng và các quan hệ của đối tượng để phát hiện lỗi

Kỹ thuật phỏng đoán lỗi

Phỏng đoán lỗi được hình thành qua kinh nghiệm kỹ thuật và dự án Không có công cụ và công nghệ giành cho kỹ thuật này, nhưng chúng ta có thể dựng các tình huống kiểm thử dựa vào trạng thái làm việc của hàm chức năng

Kỹ thuật phân tích giá trị đường biên

Phân tích giá trị đường biên (BVA - Boundary Value Analysis) là kỹ thuật lựa chọn dữ liệu kiểm thử (kỹ thuật kiểm thử chức năng) với các giá trị đường biên Giá trị đường biên bao gồm: cực đại, cực tiểu giá trị sát trong/ sát ngoài đường biên, các giá trị đặc biệt và các giá trị lỗi Kỹ thuật này thực hiện với kỳ vọng: nếu hệ thống thực hiện đúng với các giá trị đặc biệt này thì sẽ chạy đúng với tất cả các giá trị trong phạm

vi của nó, thì một lớp tương đối hợp lệ và hai lớp tương đối không hợp lệ được xác định

− Nếu điều kiện định rõ thành phần thiết lập, thì một lớp tương đối hợp lệ và một lớp tương đối không hợp lệ được xác định

− Nếu điều kiện vào là giá trị logic, thì một lớp hợp lệ và một lớp không hợp lệ được xác định

Kỹ thuật kiểm thử so sánh

Có những tình huống giành cho những phiên bản độc lập của phần mềm ứng dụng, những phiên bản độc lập này là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hoặc kiểm thử back – to – back

Kỹ thuật kiểm thử chuỗi trực giao

Chiến lược kiểm thử chuỗi trực giao là phương thức thống kê, có hệ thống của kiểm thử tương tác bắt nguồn từ tập hợp nhỏ thích hợp của các tình huống kiểm thử

Ưu điểm:

− Người kiểm thử không cần biết về mặt kỹ thuật

− Kỹ thuật kiểm thử này thích hợp nhất cho việc tìm lỗi như một người dùng thực thụ

− Kỹ thuật kiểm thử này hỗ trợ nhận dạng sự gần đúng và trái ngược trong hàm chức năng

− Các tình huống kiểm thử được phác họa ngay sau khi hoàn thành hàm chức năng

Nhược điểm:

− Khả năng kiểm thử phụ thuộc vào người lập trình

− Dữ liệu đầu vào cho kiểm thử cần một lượng mẫu lớn

− Rất khó để nhận dạng được tất cả dạng dữ liệu đầu vào cho giới hạn kiểm thử

− Không xác định được đồ thị cho quá trình kiểm thử

định được cụ thể chi tiết kỹ thuật chưa hoàn chỉnh

− , khi tìm thấy lỗi sẽ xác định được phần lỗi của quy trình

Vậy nên để hoàn thành kiểm thử cho sản phầm phần mềm cần phải áp dụng cả hai loại kiểu thử này

của phần mềm trước khi dựng kế hoạch kiểm thử và nếu như phần mềm xây dựng không chính xác theo yêu cầu kỹ thuật thì rất khó xác định dữ liệu đầu vào phù hợp

(LLD – Low Level Design) là hoàn thành LLD sẽ ghi địa chỉ cho tất c

kiểm thử theo yêu cầu

Vai trò của giai đoạn giải quyết lỗi kiểm thử rất quan trọng vì lỗi của tình huống kiểm thử có thể có kết quả thay đổi theo từng

Sự lựa chọn ít phức tạp hơn là coi quá trình kiểm thử có kết quả đúng, sau đó dùng kết quả này thực hiện lại bước liền trước đó, có thể sẽ tìm thấy lỗi

Chương 3 –TỰ ĐỘNG HÓA KIỂM THỬ PHẦN MỀM

Kiểm thử là khâu quan trọng trong quy trình phát triển phần mềm Thông qua việc kiểm thử, chất lượng của ứng dụng phần mềm cuối cùng có thể được cải thiện Tuy nhiên, kiểm thử phần mềm cũng là một quy trình tốn kém, nó có thể làm tiêu tốn nhiều tài nguyên về thời gian, tiền bạc và con người

3.1 Định nghĩa:

Tự động hóa kiểm thử phần mềm là thực hiện kiểm thử phần mềm bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người.Việc thực hiện tự động phải đảm bảo được rằng không có hoạt động kiểm thử nào bị bỏ qua Nó giúp các kỹ sư kiểm thử (tester) không phải lặp đi lặp lại các bước nhàm chán

3.2 Mô hình chung của tự động hóa kiểm thử phần mềm

Tự động hóa kiểm thử phần mềm bao gồm một chuỗi các quá trình, các hoạt động, thao tác được quy tụ với nhau để thực hiện phần mềm cần kiểm thử và ghi lại kết quả kiểm thử

Phần lớn các kiến trúc kiểm thử thường là những hệ thống mở bởi yêu cầu kiểm thử là một tổ chức xác định

Hình 3.1: Mô hình chung của tự động hóa kiểm thử

Trong đó, các công cụ được dùng để tự động hóa quy trình kiểm thử trong mô hình kiểm thử thực hiện các chức năng:

Test Manager: quản lý việc thực hiện các kiểm thử của chương trình, theo dõi dữ

liệu kiểm thử, kết quả mong đợi và các chức năng, tiện ích của chương trình được kiểm thử

Test data generator: sinh dữ liệu kiểm thử cho chương trình

Oracle: tạo các phán đoán của kết quả mong đợi Nó có thể là các phiên bản

chương trình trước đó hoặc các hệ thống prototype Chú ý, ở đây không phải là cơ sở

dư liệu Oracle

File comparator: Đối chiếu kết quả kiểm thử chương trình với kết quả kiểm thử

trước đó và ghi lại sự khác nhau vào tài liệu

Report generator: cung cấp các mẫu báo cáo và các tiện ích cho kết quả kiểm thử Dynamic analyzer: thêm mã cho chương trình để tính lượng thời gian mỗi lệnh

được thực hiện

Simulator: mô phỏng môi trường kiểm thử cho sản phẩm phần mềm

3.3 Công cụ kiểm thử tự động

công cụ kiểm thử ?

mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp Việc bổ sung hoặc sửa lỗi code cho những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm thử tốt chạy sai mặc dù

Điều này sẽ khó khả thi về mặt thời gian nếu

kiểm tra thủ công

Đây là kiểm tra nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu cầu đặt ra hay không Thông qua đó, kỹ thuật viên có thể xác định được các yếu tố về phần cứng và phần mềm ảnh hưởng đến khả năng vận hành của phần mềm

Có thể liệt kê một số tình huống kiểm thử tiêu biểu thuộc loại này như sau:

− Đo tốc độ trung bình xử lý một yêu cầu của web server

− Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống 1000 người dùng truy xuất web cùng lúc

− Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của phần mềm vẫn có thể hoạt động ở mức cho phép

Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí "vô phương"

3.3.2 Các bước thực hiện kiểm thử tự động

− Thu thập các đặc tả yêu cầu hoặc test case; lựa chọn những phần cần thực hiện kiểm thử tự động

− Phân tích và thiết kế mô hình phát triển kiểm thử tự động

− Phát triển lệnh đặc tả cho kiểm thử tự động

− Kiểm tra và theo dõi lỗi trong đặc tả của kiểm thử tự động

:

1 Tạo kịch bản kiểm thử: Giai đoạn này chúng ta sẽ dùng công cụ kiểm thử

để ghi lại các thao tác lên phần mềm cần kiểm tra và tự động sinh ra kịch bản kiểm thử

2 Chỉnh sửa kịch bản kiểm thử: Chỉnh sửa để kịch bản kiểm thử thực hiện kiểm tra theo đúng yêu cầu đặt ra, cụ thể là làm theo ca kiểm thử cần thực hiện

3 Chạy kịch bản kiểm thử để kiểm thử tự động: Giám sát hoạt động kiểm tra phần mềm của kịch bản kiểm thử

4 Đánh giá kết quả: Kiểm tra kết quả thông báo sau khi thực hiện kiểm thử tự động Sau đó bổ sung chỉnh sửa những sai sót

3.3.3 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm

Công cụ kiểm thử tự động phần mềm rất đa dạng và được sử dụng trong nhiều giai đoạn kiểm thử khác nhau Hình vẽ 3.2 chỉ ra các loại công cụ khác nhau và việc sử dụng chúng trong vòng đời phát triển phần mềm

Hình 3.2: Công cụ hỗ trợ trong quy trình kiểm thử phần mềm Công cụ thiết kế kiểm thử (Design testing tools): giúp lấy dữ liệu đầu vào cho

kiểm thử (gọi là dữ liệu kiểm thử) Trong đó, công cụ thiết kế logic làm việc dựa trên logic của đặc tả, một giao diện hoặc từ mã, đôi khi nó còn được gọi là công cụ sinh ca kiểm thử (Test case generators) Ưu điểm chính của việc sử dụng công cụ kiểm thử

này là loại bớt những kiểm thử dư thừa bằng việc tìm những ca kiểm thử đảm bào bao phủ tốt nhất mã chương trình Công cụ thiết kế vật lý thao tác trên dữ liệu tồn tại hoặc sinh dữ liệu kiểm thử Nó còn được gọi là công cụ sinh dữ liệu kiểm thử (Test data generator) Công cụ này được dùng để đổ các dữ liệu kiểm thử vào các tệp tin hoặc cơ

sở dữ liệu Dữ liệu được chọn ngẫu nhiên hoặc dựa trên một số điều kiện xác định Công cụ này thường được sử dụng với khối lượng dữ liệu lớn cần thiết trong kiểm thử chịu tải và vận hành Ví dụ một công cụ có thể trích xuất các bản ghi ngẫu nhiên từ một cơ sở dữ liệu sẽ là một công cụ thiết kế vật lý.Một công cụ có thể lấy được dữ liệu đầu vào từ đặc tả sẽ là công cụ thiết kế logic

Công cụ quản lý kiểm thử (Test management tools): bao gồm công cụ trợ giúp

để lên kế hoạch kiểm thử, theo dõi những ca kiểm thử đã chạy, tổ chức các thành phần tham gia kiểm thử như: các tệp tin kịch script, các ca kiểm thử, báo cáo kiểm thử và các kết quả kiểm thử Nó cũng bao gồm các công cụ trợ giúp việc tìm nguồn gốc các kiểm thử cho các yêu cầu, thiết kế và mã, cũng như các công cụ theo dõi lỗi

Công cụ phân tích tĩnh (Static alnalysis tools): phân tích mã chương trình mà

không thực thi nó, giúp định lượng độ phức tạp của mã chương trình Một số công cụ cho ta thấy cấu trúc đồ họa của mã chương trình Loại công cụ này rất hữu ích trong việc tìm các ca kiểm thử cần thiết để thực thi một số điểm của mã trong các mô-đun phức tạp

Công cụ bao phủ (Coverage tools) đánh giá xem bao nhiêu phần của phần mềm

cần kiểm thử đã được thực hiện bởi một tập thử nghiệm Công cụ này được dùng phổ biến nhất ở giai đoạn kiểm thử đơn vị, nó giúp xác định các chuỗi mã chương trình không được bao phủ bởi các ca kiểm thử Chẳng hạn, nhánh bao phủ thường là một yêu cầu để kiểm thử các hệ thống an toàn quan trọng hoặc liên quan đến an toàn Công

cụ bao phủ có thể cũng đo phạm vi bao phủ của các cấu trúc mức thiết kế

Công cụ gỡ lỗi (Debugging tools) thực tế không phải là công cụ kiểm thử vì việc

gỡ lỗi không phải là một phần của kiểm thử.Tuy nhiên các công cụ gỡ lỗi thường được

sử dụng trong giai đoạn kiểm thử, đặc biệt khi ta muốn cô lập các lỗi mức thấp Công

cụ gỡ lỗi cho phép lập trình viên đi qua mã chương trình bằng cách thực thi theo từng chỉ dẫn ở thời điểm tương ứng và xem nội dung của vị trí dữ liệu

Công cụ phân tích động (Dynamic alnalysis tools) đánh giá hệ thống trong khi

phần mềm đang chạy, ví dụ công cụ tìm lỗ hổng trong bộ nhớ Một rò rỉ bộ nhớ xảy ra khi một chương trình không giải phóng các khối bộ nhớ khi nó cần, vì vậy

Mô phỏng (Simulators) là các công cụ cho phép các phần của một hệ thống được

kiểm thử theo những cách mà chúng không thể thực hiện được trong thế giới thực.Ví

dụ quá trình kiểm tra lỗi rò rỉ lò phản ứng hạt nhân có thể được kiểm thử bằng mô phỏng

Các công cụ kiểm thử hiệu năng (Performance testing) đo thời gian thực hiện

các sự kiện khác nhau Ví dụ, chúng có thể đo được thời gian phản hồi dưới điều kiện chịu tải hoặc đặc thù riêng Các công cụ kiểm thử chịu tải (Load testing) tạo ra quá trình tắc nghẽn của hệ thống Ví dụ, chúng có thể sinh ra một số giao dịch đại diện cho các mức tối đa Loại công cụ này có thể được sử dụng để kiểm thử chịu tải (volume and stress testing)

Các công cụ so sánh và thực thi kiểm thử (Test execution and comparison) cho

phép các kiểm thử được thực hiện một cách tự động và các kết quả được so sánh với kết quả mong đợi Các công cụ này có thể thực hiện ở bất kỳ mức nào: kiêm thử đơn

vị, tích hợp, hệ thống và kiểm thử chấp nhận Công cụ Capture/playback là công cụ so

sánh và thực thi kiểm thử, nó được dùng để ghi lại các phiên kiểm thử dưới dạng tệp tin script và cho phép chạy lại chúng sau đó Công cụ này rất hữu ích cho kiểm thử hồi quy Đây là một trong những công cụ đang sử dụng phổ biến nhất hiện nay Công cụ TestComplete 9 được trình bày trong luận văn thuộc loại công cụ kiểm thử này

3.4 Chuyên môn hóa con người

Để thực hiện kiểm thử phần mềm tự động, con người cần phải được đào tạo Trách nhiệm của kỹ sư thực hiện kiểm thử tự động là:

− Phát triển các thủ tục và ca kiểm thử dựa trên yêu cầu (hay đặc tả phần mềm)

− Thực hiện bằng tay các thủ tục kiểm thử

− Kiểm thử các hướng thủ tục

− Tiến hành kiểm thử

− Chuẩn bị các báo cáo về tiến độ kiểm thử và hồi quy

− Sử dụng các tiêu chuẩn kiểm thử

Kỹ năng đòi hỏi tối thiểu đối với kỹ sử kiểm thử tự động là:

− Có kinh nghiệm kiểm thử phần mềm

− Có kinh nghiệm thiết kế các bộ kiểm thử

− Quen với thiết kế giao diện người dùng và các chuẩn thiết kế giao diện người dùng

− Quen với lĩnh vực kinh doanh của phần mềm được phát triển

− Có kinh nghiệm lập trình

Trong nhóm kiểm thử cũng có thể gồm những người không có kinh nghiệm sử dụng công cụ kiểm thử, ở đó họ sẽ được giao những nhiệm vụ cụ thể trong quy trình kiểm thử

3.5 Chi phí trong kiểm thử tự động phần mềm

Chi phí liên quan đến kiểm thử tự động bao gồm:

− Chi phí về công cụ phần mềm

− Chi phí phần cứng

− Chi phí về lương cho kỹ sư kiểm thử tự động

− Chi phí đào tạo

− Phần trăm trả cho các trang thiết bị và công cụ phần mềm sử dụng trong quy trình kiểm thử

− Chi phí bảo trì cho các thiết bị và công cụ

− Chi phí phân tích khả năng vận hành của sản phẩm dựa trên dữ liệu kiểm thử đã tạo ra và kết quả của các kiểm thử đã thực hiện trước đó

So với kiểm thử thủ công thì chi phí kiểm thử tự động là cao hơn, đặc biệt ở thời điểm bắt đầu của quy trình tự động hóa Từ công cụ kiểm thử cho đến các trang thiết

bị cần thiết đều rất đắt đỏ Tuy nhiên, vốn đầu tư sẽ được hoàn lại sau khoảng thời gian dùng kiểm thử tự động

Không có sự so sánh rõ ràng giữa chi phí thực hiện các kiểm thử tự động và kiểm thử thủ công, ở đây ngụ ý về chi phí cho mỗi lần một ca kiểm thử được thực hiện Tổng chi phí kiểm thử được xác định bằng tổng chi phí kiểm thử thủ công và tự động:

ở đây bao gồm các phí phát sinh khác

3.6 Một số hạn chế trong tự động hóa kiểm thử

Không thể thay thế kiểm thử thủ công

Nó là không thể, cũng không phải là đáng mong muốn để tự động hóa tất cả các hoạt động kiểm thử, tất cả các ca kiểm thử Sẽ luôn có một số ca kiểm thử mà việc kiểm thử bằng tay sẽ dễ dàng hơn nhiều so với kiểm thử tự động, hoặc nó là quá khó

khăn để tự động hóa hay nó là không kinh tế để thực hiện tự động hóa Các kiểm thử như vậy gồm:

− Kiểm thử rất hiếm khi chạy Chẳng hạn, nếu một ca kiểm thử chỉ chạy một lần một năm, thì có lẽ không đáng giá nếu tự động hóa kiểm thử đó

− Phần mềm thường xuyên thay đổi Chẳng hạn, nếu giao diện người dùng và các tính năng thay đổi gần như hoàn toàn từ một phiên bản đến phiên bản tiếp theo, việc nỗ lực thay đổi các kiểm thử tự động sao cho phù hợp gần như là không hiệu quả

− Các kiểm thử mà kết quả dễ dàng được kiểm chứng bởi một người, nhưng là rất khó khăn nếu thực hiện tự động hóa Ví dụ: sự phù hợp của một bảng màu, tính hấp dẫn lôi cuốn về mặt thẩm mỹ của một cách bố trí màn hình…

− Các kiểm thử liên quan đến tương tác vật lý Chẳng hạn, nhận dạng một thẻ thông qua đầu đọc thẻ, ngắt kết nối một số thiết bị, bật tắt nguồn điện

Không phải tất cả các kiểm thử thủ công đều nên được tự động hóa – chỉ những kiểm thử sẽ được chạy lại thường xuyên Chiến lược kiểm thử tốt cũng sẽ bao gồm một số kiểm thử bên hay kiểm thử thăm dò, cái được thực hiện tốt bằng thủ công, ít nhất ở lần đầu tiên Khi phần mềm không ổn định, việc kiểm thử bằng tay sẽ tìm được lỗi nhanh hơn

Kiểm thử thủ công có khả năng phát hiện lỗi tốt hơn kiểm thử tự động

Một kiểm thử hầu hết có thể tìm thấy một lỗi ở lần chạy đầu tiên Nếu một ca kiểm thử được tạo để thực hiện tự động hóa, đầu tiên nó phải được kiểm tra đề đảm bảo chắc chắn nó là chính xác Việc kiểm tra ca kiểm thử thường được làm bằng bằng việc chạy ca kiểm thử thủ công Nếu phần mềm đang được kiểm thử có lỗi mà ca kiểm thử có thể phát hiện ra, nó sẽ được phát hiện ở lần đầu tiên, khi thực hiện bằng thủ công

Sau khi bộ kiểm thử tự động đã được xây dựng, nó được sử dụng để chạy lại các thử nghiệm Theo định nghĩa, các thử nghiệm này đã được chạy trước đó, và do vậy, chúng ít có khả năng tìm thấy lỗi thời điểm này Các công cụ thực thi kiểm thử không phải là công cụ „kiểm thử‟, mà chúng là công cụ „chạy lại kiểm thử‟ hay còn gọi là công cụ kiểm thử hồi quy

Tự động hóa kiểm thử không cải thiện nhiều về tính hiệu quả

Việc tự động hóa một tập các kiểm thử không làm cho chúng hiệu quả hơn so với cùng tập kiểm thử đó được thực hiện bằng tay Cuối cùng tự động hóa có thể cải thiện

tính hiệu quả của các kiểm thử Tuy nhiên dường như tự động hóa sẽ ảnh hưởng bất lợi đến khả năng cải thiện của kiểm thử

Tự động hóa kiểm thử có thể làm hạn chế sự phát triển phần mềm

Kiểm thử tự động là “mỏng manh” hơn kiểm thử bằng tay Chúng có thể bị phá

vỡ bởi những thay đổi dường như vô hại tới phần mềm

Bởi vì cài đặt và duy trì kiểm thử tự động tốn kém hơn nhiều so với kiểm thử bằng tay Điều này làm cho bản thân nó có thể hạn chế các tùy chọn thay đổi và nâng cấp hệ thống phần mềm hoặc các ứng dụng

Các công cụ không có trí tưởng tượng

Một công cụ chỉ là một phần mềm, và vì thế chúng chỉ làm theo hướng dẫn Cả công cụ và kỹ sư kiểm thử có thể làm theo hướng dẫn để thực hiện một tập các ca kiểm thử nhưng nếu là kỹ sư kiểm thử với cùng công việc sẽ thực hiện một cách khác biệt Chẳng hạn, nếu là một kỹ sư kiểm thử được giao nhiệm vụ chạy một thủ tục kiểm thử đã được chuẩn bị, họ có thể theo thủ tục đó để bắt đầu với và sẽ kiểm tra được rằng kết quả thực tế là chính xác Tuy nhiên, với kỹ sư kiểm thử họ có thể nhận ra được rằng, mặc dù phần mềm phù hợp với kết quả mong đợi nhưng có thể cả hai đều sai

Chương 4 – Tìm hiểu công cụ TestComplete 9

Trong lĩnh vực Kiểm thử tự động hiện có khá nhiều công cụ kiểm thử thương mại nổi tiếng, phổ biến như TestComplete, QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest,…Trong số đó, TestComplete phiên bản 9 của Automated‟s QA SmartBear khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm thử tự động

TestComplete cung cấp các tính năng để kiểm thử tự động bao gồm: tạo kịch bản kiểm thử, xác định dữ liệu chuẩn, thực hiện kiểm thử và ghi lại kết quả kiểm thử Chẳng hạn, nó có tính năng “recording tests” đặc biệt cho phép bạn tạo các kịch bản kiểm thử một cách trực quan Bạn chỉ cần chọn để ghi lại, thực hiện tất cả các hành động cần

điểm kiểm tra (checkpoints)

− Java (AWT, SWT, Swing, WFC)

− Sybase PowerBuilder, Microsoft FoxPro, Microsoft Access, Microsoft InfoPath

− Web browsers (Internet Explorer, Firefox, Netscape Navigator)

Kiểm thử từ khóa (Keyword tests): Đây là loại kiêm thử trực quan, đơn giản và

không đòi hỏi nền tảng lập trình

Tạo kịch bản kiểm thử (Create Sripts): Đ

Tuy nhiện, loại kiể TestComplete nhiều loại Script: VBScript, JScript, DelphiScript, C++Script and C#Script

Dự án và các thành phần trong dự án kiểm thử

Project: Giống như các công cụ phát triển phần mềm (v

dự án kiểm thử Dự án

dự án

Project Items: Một dự án gồm dữ liệu và các tệp tin, chúng gọi là thành phần

của dự án (Project Items), chúng thực hiện hoặc trợ giúp thực hiện các thao tác kiểm

tra khác nhau

Tập dự án (Project Suite): Một Project Suite bao gồm một hoặc nhiều Project

TestComplete sẽ tự động sinh ra tập dự án khi tạo một project mới Ta cũng có thể tạo m

Giao diện người dùng (TestComplete User Interface)

Hình 4.4: Đối tượng Process trong TestComplete

Hình 4.6: Ứng dụng hộp trắng trong TestComplete

TestComplete

Đặt điểm kiểm tra và lưu giữ liệu kiểm tra (Checkpoints and Stores)

Checkpoints kiểm tra TestComplete cho phép thêm các lệnh so

4.6 Các bước tạo một dự án kiểm thử với TestComplete 9

Bao gồm các bước sau:

1 Tạo một dự án kiểm thử

2 Xác định ứng dụng cần kiểm thử

3 Hoàn thành việc tạo dự án kiểm thử

4 Tạo ca kiểm thử

5 Phân tích ca kiểm thử đã được ghi

6 Chạy ca kiểm thử được ghi

7 Phân tích kết quả kiểm thử

Select File|New|New Project Tạo dự án kiểm thử

(Create New Project) :

Hình 4.8: Hộp thoại Tạo dự án kiểm thử Project name : “Patients_Management”

project: keyword test, scripts, test logs, stores…được lưu trong thư mục này

(Defining Applications to Test)

Sử dụng wizard Create New Project

1

: