(Tiểu luận) kiểm thử thủ công hệ thống bán vé máy bay và kiểm thử tự động bằng công cụ ms unit nunit

Với xu hướng phát triển ngành kiểm thử phần mềm của Việt Nam nói riêng cũng như của Châu Á nói chung đồng thời với mục đích hiểu rõ hơn về hoạt động kiểm thử phần mềm, nhóm chúng em đã q

TRƯỜNG ĐẠ I H ỌC THƯƠNG MẠ I

KHOA HTTT KINH T Ế & THƯƠNG MẠI ĐIỆ N T Ử -  -

BÀI TH O LU N Ả Ậ

Đề Tài: Kiểm thử thủ công h thống ệ bán vé máy bay và kiểm thử tự

độ ng b ng công cụ ằ MS Uni NUnit

giá

Ghi chú

15 Lưu Tiến Dũng

 Kiểm th v i phân ử ớhoạch tương đương

 Kiểm th v i b ng ử ớ ảquyết định

16 Nguyễn Thị Thuỳ Dương

 Kiểm th dử ựa trên đặc

MỤC LỤC

CHƯƠNG I: KHÁI QUÁT KIỂM THỬ PHẦN MỀM 7

1.1 Các khái niệm cơ bản trong kiểm thử phần mềm 7

1.1.1 Khái niệm về kiểm thử phần mềm 7

2.2.2 Ki m th vể ử ới phân hoạch tương đương 34

2.2.5 Ki m th vể ử ới dòng d u ữ liệ 39

3.1 Giới thiệu công cụ kiểm thử NUnit trong C# 44

3.4 Ý nghĩa chương trình kiểm thử t ự động 60

CHƯƠNG V: BÁO CÁO KIỂM THỬ VÀ ĐÁNH GIÁ.I 62

LỜI MỞ ĐẦU

“Lỗi phần mềm là một chuyện hiển nhiên của cuộc sống Chúng ta dù cố gắng đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không thể lúc nào cũng viết đúng được những đoạn mã không có lỗi Tính trung bình , ngay cả một lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh Người ta ước lượng rằng việc kiểm tra để tìm ra các lỗi này chiếm phân nửa khối lượng công việc phải làm để có được một phần mềm hoạt động được” (Software Testing Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990)

Với tốc độ phát triển nhanh chóng của công nghệ, ngày càng nhiều các chương trình phần mềm đã và đang được nghiên cứu mỗi ngày, đồng thời cũng trở nên phức tạp và đồ sộ hơn Để tạo ra một sản phẩm tốt, chất lượng đáp ứng được nhu cầu của người dùng đòi hỏi rất nhiều quy trình, tiêu chuẩn Đối với một sản phẩm công nghệ thông tin thì hoạt động kiểm thử phần mềm đóng một vai trò

vô cùng quan trọng, quyết định tới chất lượng của sản phẩm cuối cùng

Với xu hướng phát triển ngành kiểm thử phần mềm của Việt Nam nói riêng cũng như của Châu Á nói chung đồng thời với mục đích hiểu rõ hơn về hoạt động kiểm thử phần mềm, nhóm chúng em đã quyết định thực hiện đề tài: “ Kiểm thử phần mềm bằng công cụ Unit Test C#.”

Thông qua việc nghiên cứu đề tài này thì nhóm sinh viên chúng em có thể hiểu được khái quát về kiểm thử phần mềm, hiểu được về một số công cụ dùng

để kiểm thử như Nunit cho dotNet, Junit cho ngôn ngữ Java,…và hiểu được việc thiết kế test – case trong kiểm thử mức đơn vị (Unit test) Hơn hết, em có thể biết thêm một số công cụ kiểm thử tự động như: QuickTest Professional, LoadRunner, hay Test Complete…

Trong quá trình thực hiện nghiên cứu đề tài, chúng em nhận được sự hướng

dẫn tận tình của cô giáo Vũ Diệu Hương – giáo viên trực tiếp hướng dẫn Chúng

em hy vọng sẽ nhận được sự góp ý của các thầy cô và các bạn để chúng em có thể hoàn thành tốt đề tài này Những đóng góp của mọi người sẽ là những kinh nghiệm quý báu giúp em và các bạn trong nhóm có những dự định sau này trong khi làm đồ án tốt nghiệp và sau khi tốt nghiệp

Một lần nữa em xin chân thành cảm ơn cô giáo Vũ Diệu Hương đã hướng dẫn em và các bạn hoàn thành đề tài nghiên cứu.

KL Chu Thi Hong Hai

Tu Thi Ngoc Anh K22…kiểm thử phần

117

Kiểm thử thủ công chức năng quản lý…kiểm thử phần

78

19 Phạm-Văn-Đoan 20D191008…

N I DUNG Ộ CHƯƠNG I: KHÁI QUÁT KIỂM THỬ PHẦN MỀM

1.1 Các khái niệm cơ bản trong kiểm thử phần mềm

1.1.1 Khái niệm về kiểm thử phần mềm

Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế

để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa

1.1.2 Mục đích của kiểm thử phần mềm

- Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian

- Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng dụng giống với bản đặc tả yêu cầu

- Tạo ra các test case có chất lượng cao, thực thi hiệu quả…

- Một số lỗi cơ bản trong kiểm thử phần mềm như: lỗi ngay từ khi phân tích yêu cầu, lỗi từ bản đặc tả hệ thống, lỗi trong code, lỗi hệ thống và nguồn tài nguyên

hệ thống, lỗi trong vấn đề phần mềm, phần cứng…

1.1.3 Các cấp độ kiểm thử trong kiểm thử phần mềm

Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm

Preparing Vocabulary FOR UNIT 6

Led hiển thị 100% (2)

10

Hình 1-1: Sơ đồ các cấp độ kiểm thử

Kiểm thử đơn vị - Unit test: Cấp độ này chủ yếu do lập trình viên trực tiếp

thực hiện Phần mềm khi phát triển sẽ bao gồm nhiều đơn vị chức năng (hàm, phương thức) hợp thành Mỗi lập trình viên sẽ đảm nhiệm việc phát triển một hay nhiều đơn vị chức năng Kiểm thử đơn vị chính là việc lập trình viên sau khi hoàn thành code đơn vị chức năng của mình sẽ tiến hành kiểm thử chức năng đó một cách cô lập nhằm phát hiện ra lỗi và khắc phục trước khi tích hợp với các đơn vị chức năng khác Kiểm thử đơn vị thường được tiến hành theo 2 giai đoạn: kiểm thử đơn vị tĩnh và kiểm thử đơn vị động

Kiểm thử tích hợp – Integration test: Sau khi kiểm thử đơn vị được tiến

hành bởi chính lập trình viên viết ra nó, các đơn vị chức năng sẽ được ghép lại với nhau để tạo thành hệ thống đầy đủ và có thể làm việc được Các đơn vị chức năng hoạt động tốt khi ở trạng thái độc lập riêng rẽ, nhưng khi ghép lại sẽ có thể xuất hiện những lỗi về giao diện hoặc cho ra kết quả không đúng khi phải sử dụng

dữ liệu từ những đơn vị chức năng khác Đó chính là lý do tại sao phải tiếp tục kiểm thử để phát hiện ra những lỗi kể trên Người ta thường chia bước kế tiếp này thành 2 giai đoạn: kiểm thử tích hợp và kiểm thử hệ thống Ở mức kiểm thử tích hợp, các đơn vị chức năng được kết hợp lại với nhau và tiến hành kiểm thử chúng theo phương pháp tăng dần để đảm bảo cụm các đơn vị chức năng sẽ làm việc ổn định trong môi trường thử nghiệm

Kiểm thử hệ thống – System test: Sau khi tất cả các đơn vị chức năng đã

sẽ được thực thi để đảm bảo sản phẩm phần mềm đáp ứng đầy đủ các yêu cầu trong bản đặc tả yêu cầu phần mềm Đây là công việc tốn nhiều công sức nhất trong quá trình kiểm thử phần mềm Đồng thời cũng sử dụng nhiều kỹ thuật kiểm thử khác nhau như: kiểm thử giao diện người dùng, kiểm thử chức năng, kiểm thử hiệu năng, kiểm thử tính dễ dùng, v.v để hoàn tất công việc kiểm thử trong cấp độ này

Kiểm thử chấp nhận – Acceptance test: Khi kiểm thử hệ thống hoàn tất, sản

phẩm phần mềm được coi như đã sẵn sàng cho việc đưa vào sử dụng thực tế Lúc này, phần mềm cần được tiến hành cấp độ kiểm thử cuối cùng – kiểm thử chấp nhận bởi chính khách hàng hay người sử dụng phần mềm Tuy có phần tương tự như kiểm thử hệ thống nhưng mục đích chính của kiểm thử chấp nhận là quyết định việc đưa vào sử dụng chính thức sản phẩm phần mềm Người ta dựa trên các

số liệu thống kê thực tế về chất lượng, độ tin cậy của phần mềm để quyết định triển khai cho người dùng cuối Kiểm thử chấp nhận thường được thực hiện dưới hình thức cho một nhóm người dùng thử sản phẩm phần mềm để phát hiện các lỗi và nhận phản hồi từ người dùng Trong đó, phiên bản alpha dành cho đội phát triển phần mềm và phiên bản beta được cung cấp cho người sử dụng thật để đưa

ra đánh giá trong môi trường thực tế Ở thời điểm hiện tại, kiểm thử chấp nhận được coi là cấp độ quy chuẩn bắt buộc không thể thiếu trong quy trình phát triển của nhiều sản phẩm phần mềm

● Mô hình chữ V trong kiểm thử phần mềm

Hình 1-2: Mô hình chữ V

+ Các bước tiến hành của mô hình chữ V

- Sau khi đã có yêu cầu của khách hàng ta thực hiện đồng thời việc thiết kế hệ thống và bản kiểm thử cho người dùng (user acceptance testing) dựa trên các yêu cầu đó

- Khi hoàn thành được bản thiết kế hệ thống, ta vừa thực hiện bảng kiểm thử hệ thống (system testing) và vừa làm thiết kế kiến trúc phần mềm

- Sau khi có được thiết kế kiến trúc ta chuyển sang thiết kế các module Từ các thiết kế module ta vừa làm bản thiết kế các unit test đồng thời bắt đầu coding

- Sau giai đoạn coding thì các công đoạn sau bao gồm unit test, integration test, system test và acceptance testing được thực hiện lần lượt dựa trên các thiết kế đã thực hiện sẵn trước đó trong giai đoạn phát triển phần mềm ban đầu

+ Ưu điểm trong mô hình chữ V

- Có thể làm 1 số việc song song Ví dụ : Nếu làm yêu cầu đúng thì có thể làm song song với việc thiết kế test

- Đạt được phần mềm chất lượng, các pha tương thích với nhau, hỗ trợ cho nhau

- Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động liên quan đến đặc tả yêu cầu và thiết kế Hay nói cách khác, mô hình này khuyến khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực

+ Nhược điểm trong mô hình chữ V

- Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án

- Pha sau thực chỉ được thực hiện khi pha trước kết thúc, không thể quay ngược trở lại pha trước

- Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử

1.1.4 Các phương pháp kiểm thử

Có 2 cách cơ bản để xác định các ca kiểm thử là kiểm thử tĩnh và kiểm thử động

Kiểm thử tĩnh: là một hình thức của kiểm thử phần mềm mà không cần thực

thi chương trình Điều này ngược với thử nghiệm động Công việc chủ yếu là kiểm tra tính đúng đắn của mã lệnh, thuật toán hay tài liệu Đây là loại kiểm thử được thực hiện bởi lập trình viên Lỗi được phát hiện bằng kiểm thử tĩnh ít tốn kém để sửa chữa hơn so với lỗi phát hiện bằng kiểm thử động sẽ được đề cập dưới đây Các lập trình viên có thể trao đổi mã nguồn chéo nhau hoặc làm việc một cách độc lập để thực hiện kiểm thử tĩnh

Kiểm thử động: Liên quan đến việc thực thi chương trình để phát hiện các

lỗi, thất bại có thể có của chương trình hay tìm ra các vấn đề về hiệu năng hệ thống Việc thực thi chương trình trên tất cả các dữ liệu đầu vào là không thể nên

ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thực thi hay nói cách khác

là sinh ra các ca kiểm thử Trong kiểm thử động, người ta chia làm 2 kỹ thuật: kiểm thử hộp trắng (kiểm thử cấu trúc) và kiểm thử hộp đen (kiểm thử chức năng)

1.1.5 Các chiến lược kiểm thử

Trong chiến lược kiểm thử, chúng ta có ba chiến lược kiểm thử hay dùng nhất là: kiểm thử hộp đen, kiểm thử hộp trắng, và kiểm thử hộp xám

Kiểm thử hộp trắng – White box: là kỹ thuật kiểm thử dựa vào thuật toán, cấu trúc mã nguồn bên trong của chương trình với mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần Người kiểm thử truy cập vào mã nguồn chương trình và kiểm tra nó, lấy đó làm cơ sở để thực hiện việc kiểm thử Kiểm thử hộp trắng bao gồm các công việc cơ bản: Kiểm thử đường dẫn, kiểm thử luồng điều khiển, kiểm thử nội bộ (xác nhận các tham số, vòng lặp), kiểm thử tính năng (kiểm tra thời gian xử lý, dữ liệu cụ thể) Tuy nhiên, việc kiểm thử hộp trắng tồn tại khá nhiều hạn chế như: không thể đảm bảo rằng chương trình đã tuân theo đặc tả, khó phát hiện được các lỗi do dữ liệu, thiếu đường dẫn, v.v Như vậy, không thể chỉ sử dụng kiểm thử hộp trắng để kiểm thử chương trình

Kiểm thử hộp đen – Black box: Là kỹ thuật kiểm thử dựa trên đầu vào và

đầu ra của chương trình mà không quan tâm tới mã nguồn bên trong được viết ra sao Với kỹ thuật này, kiểm thử viên xem phần mềm như là một hộp đen Để thực hiện, kiểm thử viên sẽ xây dựng các nhóm giá trị đầu vào sao cho chúng có thể thực hiện đầy đủ các chức năng cần có của chương trình Kiểm thử hộp đen sử dụng các phương pháp: phân tích giá trị biên, kiểm thử tính bền vững, kiểm thử trường hợp xấu nhất, kiểm thử phân lớp tương đương miền dữ liệu đầu vào, đầu

ra, kiểm thử giá trị đặc biệt, kiểm thử dựa trên bảng quyết định Tất cả các phương pháp trên đều dựa trên thông tin xác định về các thành phần đang được kiểm thử

Cho tới nay, việc xác định kỹ thuật kiểm thử nào là tốt hơn trong 2 kỹ thuật: kiểm thử hộp đen và kiểm thử hộp trắng vẫn còn là một dấu hỏi lớn Biểu đồ Venn sau đây sẽ giúp hình dung khái quát về mối liên hệ giữa kiểm thử hộp đen và kiểm thử hộp trắng trong thực tế kiểm thử hiện nay

Trước hết cần khẳng định mục đích của hai kỹ thuật trên đều là để xác định ca kiểm thử Trong khi kiểm thử hộp trắng chỉ dùng đặc tả để xác định ca kiểm thử, thì kiểm thử hộp đen lại dùng mã nguồn chương trình để làm cơ sở xác định ca kiểm thử Trong phần trình bày chi tiết về hai kỹ thuật đã nói ở trên đều cho thấy không có kỹ thuật nào là đủ tốt hoàn toàn Cụ thể: Nếu tất cả các hành

vi được nêu trong bản đặc tả yêu cầu phần mềm vẫn chưa được cài đặt thì kiểm thử hộp trắng sẽ không thể nhận biết được điều đó Hay nếu các hành vi đã được cài đặt trong chương trình nhưng lại chưa có trong bản đặc tả yêu cầu phần mềm, kiểm thử hộp đen dường như bất lực trong trường hợp này Qua biểu đồ Venn, ta

có thể khẳng định: việc kết hợp khéo léo cả hai kỹ thuật kiểm thử trên sẽ đem lại một kết quả tốt nhất trong kiểm thử phần mềm Thực hiện song song kiểm thử hộp đen và kiểm thử hộp trắng sẽ hạn chế tối đa các khiếm khuyết có thể bị bỏ

sót Tuy nhiên, nếu biết được loại lỗi nào hay mắc phải hoặc những sai lầm thường thấy trong dự án đang được triển khai, ta hoàn toàn có thể chọn kỹ thuật kiểm thử thích hợp cho từng ca kiểm thử Kinh nghiệm của kiểm thử viên sẽ được phát huy trong những trường hợp này

Gray box testing:

Kiểm thử hộp xám – Kiểm thử hộp xám đòi hỏi phải có

sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết

kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài

“hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sự khác biệt này đặc

biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun

mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện

là được đưa ra để kiểm thử Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi

1.1.6 Các kĩ thuật xác định ca kiểm thử

1.1.6.1 Kiểm thử lớp tương đương

Kỹ thuật phân vùng tương đương có đặc điểm là:

● Chia miền dữ liệu đầu vào của một chương trình thành các vùng dữ liệu tương đương nhau

● Tất cả các giá trị trong một vùng tương đương sẽ cho ra kết quả đầu ra giống nhau

● Có thể chọn ra một giá trị đại diện trong một vùng tương đương để tiến hành kiểm thử

Việc thiết kế ca kiểm thử bằng kỹ thuật phân lớp tương đương dựa trên nguyên tắc xác định số vùng tương đương hợp lệ và số vùng tương đương không hợp lệ

Như vậy với kỹ thuật trên, kiểm thử viên đã rút ngắn được số ca kiểm thử cần sinh ra so với việc phải kiểm thử toàn bộ các giá trị đầu vào

1.1.6.2 Kiểm thử giá trị biên

Phân tích giá trị biên tập trung vào các giá trị tại biên của miền xác định để xây dựng ca kiểm thử Mục đích là tìm ra lỗi có thể xảy ra ở gần các giá trị biên này Phân tích giá trị biên chính là trường hợp đặc biệt của kỹ thuật phân vùng tương đương Dựa trên những vùng giá trị tương đương, kiểm thử viên sẽ xác định giá trị biên giữa những vùng này và thiết kế ca kiểm thử phù hợp

Với kỹ thuật phân tích giá trị biên, kiểm thử viên cần chú ý tới một số giá trị sau để sinh ca kiểm thử:

● Giá trị nhỏ nhất

● Giá trị gần kề lớn hơn giá trị nhỏ nhất

● Giá trị gần kề nhỏ hơn giá trị nhỏ nhất

● Giá trị bình thường

● Giá trị gần kề nhỏ hơn giá trị lớn nhất

● Giá trị lớn nhất

● Giá trị gần kề lớn hơn giá trị lớn nhất

Như vậy, có thể thấy phân tích giá trị biên là kỹ thuật bổ sung cho kỹ thuật phân vùng tương đương, giúp kiểm thử viên sinh ca kiểm thử để kiểm tra các giá trị tại biên

1.1.6.3 B ng quyả ết định (Decision Tables)

Trong các kỹ thuật viết Test Case, đối với các trường dữ liệu đơn như textbox, các tester thường sử dụng các phương pháp phân vùng tương đương hay phân tích giá trị biên Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, Bảng quyết định (Decision table) sẽ giúp chúng ta phân loại và định hình được kịch bản kiểm thử một cách chính xác và rõ ràng hơn

Bảng quyết định là một kỹ thuật tốt để áp dụng cho những trường hợp cần nhiều sự kết hợp Kỹ thuật này hỗ trợ việc lựa chọn Test Case tối thiểu một cách

có hệ thống kỹ thuật với độ bao phủ tối đa

Có 4 bước để người kiểm thử tạo được Decision Tables:

● Liệt kê tất cả Conditions/Inputs

● Tính số lượng kết hợp có thể (Rules)

● Đặt tất cả các kết hợp trong bảng

● Giảm thiểu các case kết hợp và quyết định Test Case

1.1.6.4 Kiểm thử luồng điều khiển

● Đường thi hành (Execution path) : là 1 kịch bản thi hành đơn vị phần mềm tương ứng, cụ thể nó là danh sách có thứ tự các lệnh được thi hành ứng với

1 lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phần mềm đến điểm kết thúc của đơn vị phần mềm

● Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau

● Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của ₫ơn vị phần mềm cần kiểm thử đều chạy đúng Rất tiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay

cả trên những đơn vị phần mềm nhỏ

1.1.6.5 Kiểm thử luồng dữ liệu

● Kiểm thử luồng dữ liệu liên quan đến việc chọn đường đi với mục tiêu bao phủ các cặp gán (definition) và dùng (use) dữ liệu, được gọi là các tiêu chuẩn luồng dữ liệu

● Quy trình tổng quát của kiểm thử luồng dữ liệu là:

○ Vẽ đồ thị luồng dữ liệu cho chương trình

○ Chọn tiêu chuẩn kiểm thử luồng dữ liệu

○ Xác định các đường đi trong đồ thị để thỏa mãn tiêu chuẩn lựa chọn (all-defs, all-uses, all-P-uses/some-C-uses, v.v )

○ Tạo các ca kiểm thử cho các đường đi đã xác định

Đỉnh gán (defining node) cho biến v nếu giá trị của v được thiết lập tại lệnh

ở đỉnh n

Đỉnh sử dụng của biến v là đỉnh giá trị của v được đọc ra bằng lệnh ở đỉnh

n

Đỉnh sử dụng là sử dụng mệnh đề (P use) nếu lệnh tương ứng là lệnh mệnh

-đề, ngược lại là sử dụng tính toán (C-use)

Đỉnh tương ứng với P use luôn có số cạnh ra > = 2, đỉnh C use có số cạnh -

-ra < = 1

1.2 Kiểm thử tự động

Kiểm thử tự động là quá trình kiểm tra một hệ thống nào đó bằng các công

cụ tự động hoá với dữ liệu đầu vào và đầu ra đã được xác định

Công việc kiểm thử thường chiếm từ 11% - 40% chi phí cho quá trình phát triển phần mềm Hơn nữa, các dự án phần mềm đều mong muốn giảm chi phí về thời gian, nhân lực mà vẫn đem lại hiệu quả cao, chất lượng tốt Đó chính là lý

do kiểm thử tự động được áp dụng rộng rãi trong các quy trình phát triển phần mềm ngày nay

Kiểm thử tự động đặc biệt phát huy tác dụng trong các trường hợp kiểm thử lặp đi lặp lại, kiểm thử hồi quy hay các ca kiểm thử có giá trị dữ liệu đầu vào rất lớn khiến cho việc kiểm thử thủ công gặp nhiều khó khăn Đối với các trường hợp kiểm thử lặp đi lặp lại, nếu thực hiện thủ công sẽ gây ra sự nhàm chán cho người kiểm thử, dẫn tới năng suất lao động kém Đó là chưa kể tới việc lặp đi lặp lại quy trình một cách thủ công hoàn toàn có thể dẫn tới sai sót Ngược lại, nếu thay bằng kiểm thử tự động, dù có lặp đi lặp lại bao nhiêu lần thì cũng cho ra thao tác và kết quả chính xác Điều này giúp chúng ta tránh được những rủi ro không đáng có và giảm đáng kể thời gian cho việc kiểm thử

Dù có rất nhiều ưu điểm về mặt thời gian thực thi nhưng kiểm thử tự động cũng không thể thay thế hoàn toàn quá trình kiểm thử của con người Để thực hiện kiểm thử tự động, trước hết vẫn cần bàn tay con người thiết lập thao tác cho công cụ hay các đoạn kịch bản máy tính để thực thi Đối với những ca kiểm thử chỉ thực hiện số ít lần thì việc mất thời gian tạo kịch bản kiểm thử tự động là không cần thiết Chưa kể tới những ca kiểm thử với đặc thù riêng biệt mà kiểm thử tự động không làm được Thêm vào đó, không phải công cụ kiểm thử tự động nào cũng miễn phí và dễ sử dụng hay đưa vào triển khai rộng rãi

1.2.1 Khái ni m Unit test ệ

Unit Test là một loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của phần mềm được kiểm thử Kiểm thử đơn vị được thực hiện trong quá trình phát triển ứng dụng Mục tiêu của Kiểm thử đơn vị là cô lập một phần code và xác minh tính chính xác của đơn vị đó

1.2.2 Mục đích

❖ Đảm bảo thông tin xử lý và xuất ra là chính xác

❖ Trong mối tương quan với dữ liệu nhập và chức năng của một Unit

❖ Đòi hỏi tất cả các nhánh bên trong phải được kiểm tra phát hiện nhánh sinh lỗi(nhánh đó thường là câu lệnh để thực thi trong một Unit) Ví dụ: Chuỗi

câu lệnh If…then…else là một nhánh Đòi hỏi có kỹ thuật, đôi khi dùng thuật toán để chọn lữa

❖ Phát hiện ra các vấn đề tiềm ẩn hoặc các lỗi kỹ thuật

1.2.3 Yêu cầu.

- Muốn làm được Unit testing thì phải chuẩn bị trước các ca kiểm thử (Test case), các kịch bản kiểm thử (Test script, trong đó phải ghi rõ dữ liệu nhập vào, các bước thực hiện một ca kiểm thử hay một kịch bản kiểm thử và dữ liệu mong chờ đầu ra

- Các Test case, Test script được giữ lại để tái sử dung

1.2.4 Người thực hiện Unit test

Khi thực hiện kiểm thử mức đơn vị thì công đoạn này là do người lập trình viên (Deverloper) hay kỹ sư kiểm thử(Test Enginieer) Vì khi xây dựng được một test case để có thể tìm ra được lỗi là nhiều nhất thì người thực hiện phải biết về ngôn ngữ lập trình, có khả năng đọc và hiểu các đoạn code

1.2.5 Vòng đời Unit Test

Có ba trạng thái cơ bản:

- Trạng thái lỗi (Fail status)

- Trạng thái tạm ngừng thực hiện (Ignore status)

- Trạng thái làm việc(Pass Status)

Chú ý: Mỗi trạng thái của Unit test được thể hiện bằng một màu khác nhau:

- Fail: màu đỏ

- Ignore: màu vàng

- Pass: màu xanh

Như vậy: Unit test chỉ thực sự mang lại hiệu quả khi:

- Được vận hành nhiều lần

- Tự động hoàn toàn

- Độc lập với các Unit khác

1.2.6 Thiết k Unit test ế

Mỗi UT đều được thiết kế theo trình tự sau:

● Thiết lập các điều kiện cần thiết: khởi tạo các đối tượng, xác định tài nguyên cần thiết, xây dựng các dữ liệu giả…

● Triệu gọi các phương thức cần kiểm tra

● Kiểm tra sự hoạt động đúng đắn của các phương thức

● Dọn dẹp tài nguyên sau khi kết thúc kiểm tra

1.2.7 ng d ng Unit test Ứ ụ

● Kiểm tra mọi đơn vị nhỏ nhất là các thuộc tính, sự kiện, thủ tục và hàm

● Kiểm tra các trạng thái và ràng buộc của đối tượng ở các mức sâu hơn mà thông thường chúng ta không thể truy cập được

● Kiểm tra các quy trình (process) và mở rộng hơn là các khung làm việc(workflow – tập hợp của nhiều quy trình)

1.2.8 L i ích c a vi c áp d ng Unit test ợ ủ ệ ụ

Thời gian đầu, người ta thường do dự khi phải viết UT thay vì tập trung vào code cho các chức năng nghiệp vụ Công việc viết Unit Test có thể mất nhiều thời gian hơn code rất nhiều nhưng lại có lợi ích sau:

● Tạo ra môi trường lý tưởng để kiểm tra bất kỳ đoạn code nào, có khả năng thăm dò và phát hiện lỗi chính xác, duy trì sự ổn định của toàn bộ PM và giúp tiết kiệm thời gian so với công việc gỡ rối truyền thống

● Phát hiện các thuật toán thực thi không hiệu quả, các thủ tục chạy vượt quá giới hạn thời gian

● Phát hiện các vấn đề về thiết kế, xử lý hệ thống, thậm chí các mô hình thiết

● Giải phóng chuyên viên QA khỏi các công việc kiểm tra phức tạp

● Tăng sự tự tin khi hoàn thành một công việc Chúng ta thường có cảm giác không chắc chắn về các đoạn mã của mình như liệu các lỗi có quay lại không, hoạt động của module hiện hành có bị tác động không, hoặc liệu công việc hiệu chỉnh mã có gây hư hỏng đâu đó…

● Là công cụ đánh giá năng lực của bạn Số lượng các tình huống kiểm tra (test case) chuyển trạng thái “pass” sẽ thể hiện tốc độ làm việc, năng suất của bạn

Như vậy: Unit test là một môi trường lý tưởng để tiếp cận API bên ngoài một cách tốt nhất Sẽ rất nguy hiểm nếu chúng ta ứng dụng ngay các thư viện này

mà không kiểm tra kỹ lưỡng công dụng của các thủ tục trong thư viện Dành thời gian viết các Unit test kiểm tra từng thủ tục là phương pháp tốt nhất khẳng định sự hiểu đúng đắn về cách sử dụng thư viện đó Ngoài ra, Unit test cũng được sử dụng để phát hiện sự khác biệt giữa phiên bản mới và phiên bản cũ của cùng một thư viện

1.3 Nguyên tắc trong kiểm thử phần mềm

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau:

Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu

ra hay kết quả mong muốn

Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính

họ

Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra

Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào

không hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn

Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện

cái mà nó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình có thực hiện cái mà nó không cần phải thực hiện hay không

Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự

là 1 chương trình bâng quơ

Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là

không tìm thấy lỗi

Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với

số lỗi đã tìm thấy trong đoạn đó

Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách

trí tuệ

CHƯƠNG II: KIỂM THỬ THỦ CÔNG

2.1 Xây dựng bài toán

2.1.1 Phát bi u bài toán ể

Một trang bán vé máy bay tự động tính ra số tiền phải trả tương ứng với các điều kiện sau:

Yêu cầu 1: Nhập thông tin đăng ký vé bao gồm:

 Tên người đăng kí(Name)

 Địa chỉ(Address)

 Số CMT/CCCD (ID Card No)

 Ngày/Tháng/Năm sinh(date of birth): theo định dạng DD/MM/YYYY

 Loại vé (Type of Class)

Yêu cầu 2: Kiểm tra các ràng buộc:

 Tất cả các trường đều bắt buộc phải nhập dữ liệu

 Tên người đăng kí(Name) có từ 2 >64 ký tự

- Địa chỉ(Address) có từ 2 >64 ký tự

- ID Card No có 9 đến 12 ký tự

 Loại vé nhập vào là 0/1 tương ứng với (Normal/Vip)

Yêu cầu 3: Tự động xác minh số tuổi của khách hàng theo quy tắc:

 nếu năm hiện tại> năm sinh thì tuổi = năm hiện tại năm sinh-

 Nếu năm hiện tại= năm sinh thì tuổi=1

 Date of Birth(Ngày/Tháng/Năm sinh)

 Type of Class(Normal, Vip)

Output:

 Dữ liệu không hợp lệ Nhập lại-

 Dữ liệu được lưu thành công Thành tiền

-Kiểu dữ

liệu

Miền xác định Miền giá trị

Name string 2<=Name<=64 ký tự +Dữ liệu

không hợp

lệ +Nhập lại

+Thành tiền +Dữ liệu được lưu thành công

ID Card No String 9<=ID<=64

address string 2<=address<=64 ký tự

Date of Birth date time 0<Date<2022

Type of Class String “Hạng thường”

Type:0|| “Hạng thương gia” Type:1

Người lớn

2.2.1 Kiểm thử giá trị biên

Bước 1: Xác định các đầu vào

Trong đó: 0 <độ tuổi <=150

Hạng vé: có 2 hạng vé đó là hạng thường và hạng thương gia

Bước 2: Kiểm thử với version 1

2 Họ và tên: Nguyễn Ngọc Linh

Địa chỉ: 43 Cầu Giấy, Hà Nội

CCCD:012321893

Tuổi: 02/05/2023

Hạng vé: Hạng thương gia

Độ tuổi không hợp lệ

3 Tên: Nguyễn Thanh Hiền

Địa chỉ: số 1 Trần Khánh Dư, Hai Bà

4 Tên: Nguyễn Thanh Hiền

Địa chỉ: số 1 Trần Khánh Dư, Hai Bà

Trưng, Hà Nội

CCCD: 067384233

Năm sinh: 05/12/2022

Độ tuổi không hợp lệ

Hạng vé: Thương gia

5 Tên:Hoàng Văn Khoa

Địa chỉ: Mễ Trì, quận Nam Từ Liêm, Hà

6 Tên:Hoàng Văn Khoa

Địa chỉ: Mễ Trì, quận Nam Từ Liêm, Hà

9 Tên: Nguyễn Thanh Thảo

Địa chỉ: Hoàn Kiếm, Hà Nội

CCCD: 046656772

Năm sinh: 19/09/2016

Hạng vé: Hạng thường

700.000

10 Tên: Nguyễn Thanh Thảo

Địa chỉ: Hoàn Kiếm, Hà Nội

CCCD: 047576489

Năm sinh: 19/05/2016

Hạng vé: Hạng thương gia

1.500.000

11 Tên: Nguyễn Thanh Hoa

Địa chỉ: Hoàn Kiếm, Hà Nội

CCCD: 064975752

Năm sinh: 28/06/2015

Hạng vé: Hạng thường

700.000

12 Tên: Nguyễn Thanh Hoa

Địa chỉ: Hoàn Kiếm, Hà Nội

CCCD: 090475623

Năm sinh: 28/08/2015

Hạng vé: Hạng thương gia

1.500.000

13 Tên: Vũ Thảo Anh

Địa chỉ: Hai Bà Trưng, Hà Nội

CCCD: 075452754

Năm sinh: 08/05/2014

Hạng vé: Hạng thường

3.000.000

14 Tên: Vũ Thảo Anh

Địa chỉ: Hai Bà Trưng, Hà Nội

CCCD: 047756752

Năm sinh: 14/05/2014

Hạng vé: Hạng thương gia

4.000.000

15 Tên: Trịnh Hoàng Nam

Địa chỉ: Bắc Từ Liêm, Hà Nội

CCCD: 042311457

Tuổi: 17/09/1959

Hạng vé: Hạng thường

3.000.000

16 Tên: Trịnh Hoàng Nam

Địa chỉ: Bắc Từ Liêm, Hà Nội

CCCD: 042311457

Tuổi: 17/09/1959

Hạng vé: Hạng thương gia

4.000.000

17 Tên: Nguyễn Văn Sơn

Địa chỉ: 43 Cầu Giấy, Hà Nội

CCCD: 038202013

Sinh năm: 12/7/1903

Hạng vé: Hạng thường

3.000.000

18 Tên: Nguyễn Văn Sơn

Địa chỉ: 43 Cầu Giấy, Hà Nội

CCCD: 038202013

Sinh năm: 12/7/1903

Hạng vé: hạng thương gia

3.000.000

19 Tên: Lê Yến Nhi

Địa chỉ: 43 Cầu Giấy, Hà Nội

CCCD: 045675433

Sinh năm: 05/06/1902

Hạng vé: Hạng thường

3.000.000

20 Tên: Lê Yến Nhi

Địa chỉ: 43 Cầu Giấy, Hà Nội

CCCD: 065465845

Sinh năm: 05/06/1902

Hạng vé: Hạng thương gia

3.000.000

21 Tên: Hoàng Văn Cầu

Địa chỉ: Bắc Từ Liêm, Hà Nội

CCCD: 074256422

Sinh năm : 17/10/1901

Hạng vé: Hạng thường

Độ tuổi không hợp lệ

22 Tên: Hoàng Văn Cầu

Địa chỉ: Bắc Từ Liêm, Hà Nội

CCCD: 058782222

Sinh năm : 17/09/1901

Hạng vé: Hạng thương gia

Độ tuổi không hợp lệ

23 Tên: Đỗ Văn Văn Văn Văn Văn Văn

Văn Văn Văn Văn Văn Văn Văn Văn

Văn Văn Văn Văn Văn Văn Văn Văn

24 Tên: Đỗ Văn Văn Văn Văn Văn Văn

Văn Văn Văn Văn Văn Văn Văn Văn

Văn Văn Văn Văn Văn Văn Văn Văn

27 Tên: Lê Thúy Hòa

Địa chỉ: Cầu Diễn, Hà Nội

28 Tên: Lê Thúy Hòa

Địa chỉ: Cầu Diễn, Hà Nội

29 Tên: Lê Thúy Hòa

Địa chỉ: Cầu Diễn, Hà Nội

30 Tên: Lê Thúy Hòa

Địa chỉ: Cầu Diễn, Hà Nội

2.2.4 Kiểm thử với dòng điều khiển

ID Đường đi Test Case Tương ứng

Expected result

Năm sinh Type Of Class

hợp lệ

2 1, 2(T), 3, 4(T), 5(F), 7, 11 2016 hạng thương

gia

1,500,000 VND

Năm sinh Type Of Class

gia

Dữ liệu không hợp lệ

2.2.5 Ki m th vể ử ới dòng d ữ liệu

public void Payment_Test_1()

{

Ticket a = new Ticket(new DateTime(2010,11,6),TicketType.Normal);

//tạo một đối tượng a, khởi tạo đối tượng với hàm tạo gồm có ngày …