Phương pháp sinh bộ kiểm thử tự động cho kiểm thử giao diện ứng dụng web luận văn ths công nghệ thông tin 60 48 10 pdf

Đầu tiên sử dụng mô hình máy hữu hạn trạng thái cho giao diện ứng dụng Web, sau đó tạo ra các bộ kiểm thử từ máy hữu hạn trạng thái, từ đó xây dựng một đồ thị có hướng để biểu diễn các t

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

Hà Nội - 2013

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của tôi dưới sự giúp đỡ rất lớn của Giảng viên hướng dẫn là Tiến sĩ Lê Thanh Hà, Tiến sĩ Phạm Ngọc Hùng Những nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực

Các trích dẫn từ nguồn tài liệu bên ngoài đều được liệt kê rõ ràng ở phần cuối của luận văn

Hà Nội, tháng 12 năm 2013

Học viên

LỜI CẢM ƠN

Để có thể hoàn thành đề tài luận văn thạc sĩ một cách hoàn chỉnh, bên cạnh sự

nỗ lực cố gắng của bản thân còn có sự hướng dẫn nhiệt tình của quý Thầy Cô, cũng như sự động viên ủng hộ của gia đình và bạn bè trong suốt thời gian học tập, nghiên cứu và thực hiện luận văn thạc sĩ

Xin chân thành bày tỏ lòng biết ơn sâu sắc đến Tiến sĩ Lê Thanh Hà, Tiến sĩ Phạm Ngọc Hùng, những người đã dành rất nhiều thời gian và tâm huyết hướng dẫn tôi nghiên cứu và hoàn thành luận văn thạc sĩ Xin gửi lời tri ân nhất đối với những điều mà các Thầy đã dành cho tôi

Xin chân thành bày tỏ lòng biết ơn đến toàn thể quý Thầy Cô trong khoa Công Nghệ Thông Tin Trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội đã tận tình truyền đạt những kiến thức quý báu cũng như tạo mọi điều kiện thuận lợi nhất cho tôi trong suốt quá trình học tập, nghiên cứu và cho đến khi thực hiện đề tài luận văn

Cuối cùng, tôi xin chân thành bày tỏ lòng cảm ơn đến Ban lãnh đạo Hệ thống Đào tạo Lập trình viên Quốc tế Aprotrain-Aptech đã tạo điều kiện cho tôi rất nhiều trong suốt quá trình làm việc, học tập và thực hiện đề tài luận văn thạc sĩ của mình Mặc dù tôi đã rất cố gắng hoàn thiện luận văn bằng tất cả sự nhiệt tình và năng lực của mình Tuy nhiên do trình độ, kinh nghiệm và khả năng chuyên môn có hạn, chắc chắn luận văn còn nhiều thiếu sót Rất mong nhận được những góp ý của quý Thầy Cô và các bạn

Hà Nội, tháng 12 năm 2013

Học viên

Hà Khánh Toàn

MỤC LỤC

TRANG PHỤ BÌA

LỜI CAM ĐOAN

LỜI CẢM ƠN

MỤC LỤC

DANH MỤC CÁC TỪ VIẾT TẮT

DANH MỤC CÁC BẢNG

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

CHƯƠNG 1 GIỚI THIỆU 1

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

2.1 Khái niệm Web Application 3

2.2 Các kỹ thuật kiểm thử 3

2.2.1 Kiểm thử hộp đen 3

2.2.3 Kiểm thử hộp xám 6

2.2.4 Kiểm thử dựa trên mô hình 7

2.2.5 Kiểm thử sử dụng máy hữu hạn trạng thái 9

2.3 Các mức kiểm thử 11

2.3.1 Kiểm thử đơn vị 12

2.3.2 Kiểm thử tích hợp 12

2.3.3 Kiểm thử hệ thống 13

2.3.4 Kiểm thử chấp nhận 13

2.4 BỘ CÔNG CỤ SELENIUM – WEBDRIVER TRONG VIỆC KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB 13

2.4.1 Tổng quan về Selenium 14

2.4.2 Selenium-RC (Remote Control) 14

2.4.3 Selenium 2 (Selenium – Webdriver) 15

2.4.4 Một số Selenium-Webdriver API 15

CHƯƠNG 3 PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB 18

3.1 Mục tiêu của phương pháp nghiên cứu 18

3.2 Tổng quan 18

3.3 Tạo các ca kiểm thử cho ứng dụng Web 19

3.3.1 Xây dựng mô hình máy hữu hạn trạng thái 19

3.3.2 Xây dựng mô hình đồ thị cho máy hữu hạn trạng thái 27

3.3.3 Thực hiện việc tạo ra các ca kiểm thử 30

3.3.4 Thuật toán sinh ca kiểm thử 30

CHƯƠNG 4 THỰC NGHIỆM 32

4.1 Phương pháp thực hiện 32

4.2 Xây dựng công cụ kiểm thử tự động 32

4.2.1 Mô tả công cụ kiểm thử 33

4.2.2 Xây dựng ứng dụng Web 34

4.2.3 Xây dựng máy hữu hạn trạng thái cho ứng dụng Web 38

4.3 Kết quả thử nghiệm chương trình 41

4.4 Thảo luận 44

CHƯƠNG 5 KẾT LUẬN 45

PHỤ LỤC 47

TÀI LIỆU THAM KHẢO 54

DANH MỤC CÁC TỪ VIẾT TẮT

FSM Finite State Machine Máy hữu hạn trạng thái

HTTP Hypertext Transfer Protocol Giao thức truyền siêu văn bản WSDL Web Services Description

Language

Ngôn ngữ mô tả các dịch vụ Web

SOAP Simple Object Access Protocol Giao thức truy cập đối tƣợng

đơn giản API Application Programming

Interface

Giao diện lập trình ứng dụng

UML Unified Modeling Language Ngôn Ngữ Mô Hình Hóa

Thống Nhất SWEBOK Software Engineering Body of

Knowledge

Tổ chức quốc tế theo chuẩn ISO/IEC TR 19759:2005

4.4 Bảng biểu diễn trạng thái chuyển trang login.aspx 39 4.5 Các phần tử html trang studentInformation.aspx 39 4.6 Bảng trạng thái trang studentInformation.aspx 39 4.7 Bảng sự kiện trang studentInformation.aspx 39 4.8 Bảng biểu diễn trạng thái chuyển trang

4.9 Các phần tử html trang resultStudent.aspx 40 4.10 Bảng trạng thái trang resultStudent.aspx 40 4.11 Bảng sự kiện trang resultStudent.aspx 40 4.12 Bảng biểu diễn trạng thái chuyển trang

4.15 Bảng biểu diễn trạng thái chuyển trang logout.aspx 41

2.3 Sơ đồ luồng điều khiển được tạo ra từ chương trình 6

3.1 Máy hữu hạn trạng thái cho trang login.aspx 27 3.2 Máy hữu hạn trạng thái cho trang studentInformation.aspx 28 3.3 Máy hữu hạn trạng thái cho trang ResultStudent.aspx 28 3.4 Máy hữu hạn trạng thái cho trang addMark.aspx 29 3.5 Máy hữu hạn trạng thái cho trang logout.aspx 30

CHƯƠNG 1 GIỚI THIỆU

Ngày nay, sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác làm việc qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc sống của chúng ta Xu hướng này đòi hỏi các ứng dụng không chỉ là những hệ thống đơn lẻ trên một máy và chịu sự phụ thuộc vào một nền tảng cố định nào nữa, mà chúng phải là những hệ thống linh hoạt giúp người dùng làm việc

“mọi lúc, mọi nơi” Do đó, việc phát triển các ứng dụng Web đang là xu hướng tất yếu của ngành công nghiệp phần mềm Các ứng dụng Web đang được ứng dụng rộng rãi trong thực tế Càng ngày các doanh nghiệp nói chung và mọi người nói riêng càng phụ thuộc vào các ứng dụng Web và làm thế nào để các ứng dụng Web đáp ứng được các nhu cầu này Do đó, nhu cầu đảm bảo an toàn chất lượng các sản phẩm phần mềm ứng dụng Web ngày càng trở nên cấp thiết Việc đảm bảo chất lượng phần mềm hiện nay đang là một bài toán khó và nó tiêu tốn hơn 50% công sức và chi phí của các doanh nghiệp phần mềm

Kiểm thử đang được quan tâm như là phương pháp chủ yếu để đảm bảo chất lượng của sản phẩm phần mềm ứng dụng Web nói riêng và sản phẩm phần mềm nói chung Trong thực tế, các công ty gặp nhiều khó khăn, tốn thời gian và chi phí cao cho việc kiểm thử các ứng dụng Web Mặc dù họ có thể thuê những người kiểm thử có kỹ năng kiểm thử giỏi, song những sai sót hoặc thiếu sót trong kiểm thử ứng dụng Web là không thể tránh khỏi do các phương pháp kiểm thử ứng dụng Web thường được thực hiện thủ công Do đó, các phương pháp kiểm thử hiện tại không đảm bảo phát hiện ra tất cả các lỗi Ngoài ra, việc kiểm thử thủ công của một ứng dụng Web có thể tẻ nhạt và tốn thời gian (đôi khi do tương tác người dùng quá lớn), đặc biệt là khi thực hiện các bài kiểm thử qui hồi trong ứng dụng Kết quả là các ứng dụng Web hiện nay tiềm ẩn rất nhiều lỗi sau khi triển khai cho khách hàng

Trong kiểm thử các ứng dụng Web, kiểm thử tương tác giao diện người dùng là một vấn đề khó và thường được thực hiện thủ công Trong thực tế, chúng ta

có một thiết kế giao diện người dùng mô tả việc thay đổi trạng thái của màn hình ứng với các tương tác của người dùng Các thay đổi trạng thái này có thể xảy ra trong một trang Web hoặc từ trang Web này sang trang Web khác Làm thế nào để đảm bảo rằng việc cài đặt tuân thủ đúng theo thiết kế này chính là mục đích chính của kiểm thử tương tác giao diện người dùng cho các ứng dụng Web Các kỹ thuật kiểm thử tự động đã được biết đến như là các giải pháp tiềm năng để giải quyết vấn

đề trên Những kỹ thuật này có thể phát hiện ra tất cả các lỗi có thể trong ứng dụng bằng cách tạo ra và thực hiện tự động các ca kiểm thử Kết quả là, chúng ta có thể tiết kiệm thời gian và chi phí trong kiểm thử Tự động kiểm thử là quá trình thực

hiện tự động bởi một chương trình máy tính để tránh các lỗi không được phát hiện khi kiểm thử thủ công Để đảm bảo tính chính xác, các công cụ kiểm thử tự động thường được xây dựng dựa trên các phương pháp kiểm thử như kiểm thử hộp đen, kiểm thử hộp trắng, … Tuy nhiên, các công cụ kiểm thử tự động là rất đắt và nhiều công ty không thể mua chúng

Luận văn này tập trung nghiên cứu các phương pháp kiểm thử dựa trên mô hình nhằm đảm bảo việc cài đặt đúng theo thiết kế ban đầu Đầu tiên sử dụng mô hình máy hữu hạn trạng thái cho giao diện ứng dụng Web, sau đó tạo ra các bộ kiểm thử từ máy hữu hạn trạng thái, từ đó xây dựng một đồ thị có hướng để biểu diễn các trường hợp kiểm thử Dựa trên đồ thị có hướng, theo các nhánh chúng ta

có thể tạo ra các trường hợp kiểm thử cho sản phẩm Mục đích của luận văn này là

đề xuất một phương pháp cho phép để xây dựng một phương pháp kiểm thử tự động cho giao diện các ứng dụng Web Một công cụ kiểm thử tự động hỗ trợ cũng

sẽ được phát triển nhằm minh chứng cho tính hiệu quả của phương pháp này

Các phần tiếp theo của luận văn được tổ chức như sau Chương 2 trình bày

về cơ sở lý thuyết của đề tài Chương này đề cập đến các khái niệm cơ bản của kiểm thử phần mềm, tìm hiểu về kiểm thử dựa trên mô hình, máy hữu hạn trạng thái Tiếp theo, chương 3 đề cập đến cách làm thế nào để sinh được các bộ kiểm thử từ máy hữu hạn trạng thái Sau đó, chương 4 xây dựng chương trình thực nghiệm dùng công cụ Selenium và Webdriver Nghiên cứu các trường hợp sinh ca kiểm thử bằng chương trình thực nghiệm này Cuối cùng, chương 5 tóm tắt các kết quả đã đạt được, kết luận, những hạn chế và hướng nghiên cứu phát triển trong tương lai

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

2.1 Khái niệm Web Application

Các ứng dụng Web là các ứng dụng được giao tiếp với các máy khách thông qua các giao thức Web như HTTP, WSDL hoặc SOAP Với sự phổ biến của World Wide Web thì việc các ứng dụng Web được phát triển ngày càng nhiều Trình duyệt Web cung cấp cho các nhà phát triển các cơ hội để khai thác năng lực vốn có của trình duyệt để giảm bớt gánh nặng phụ thuộc vào các hệ điều hành khác nhau hoặc các nền tảng phần cứng có sẵn cho người dùng

Ngày nay các ứng dụng Web được phát triển khá đa dạng từ trang Web hẹn

hò đến các trang thương mại điện tử1, ngân hàng trực tuyến2, đặt vé các hãng hàng không3 …

2.2 Các kỹ thuật kiểm thử

Ngày nay, có rất nhiều các phương pháp được áp dụng trong kiểm thử, mỗi phương pháp sẽ có những ưu điểm và nhược điểm riêng Trong phần này sẽ miêu tả một số phương thức kiểm thử như kiểm thử hộp đen [14], kiểm thử hộp trắng [1], kiểm thử hộp xám [13] và kiểm thử sử dụng máy hữu hạn trạng thái [2]

2.2.1 Kiểm thử hộp đen

Kiểm thử hộp đen hay còn được gọi là kiểm thử chức năng, kiểm thử hộp đen coi phần mềm như là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm Các kiểm thử viên chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế nào Phương pháp kiểm thử hộp đen bao gồm: phân vùng tương đương, phân tích giá trị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử chéo, kiểm thử dựa trên mô hình, sử dụng các ca kiểm thử, thăm dò kiểm thử và kiểm thử dựa trên đặc điểm kỹ thuật

Kiểm thử dựa trên đặc điểm kỹ thuậtnhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng Mức độ kiểm thử thường đòi hỏi

ca kiểm thử kỹ lưỡng được cung cấp bởi các kiểm thử viên, những người mà sau đó

có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra

(hoặc cách xử lý) có thể giống hoặc không so với giá trị kỳ vọng được định vị trong

một ca kiểm thử nhất định Các ca kiểm thử được xây dựng quanh các thông số kỹ

thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm

Nó được sử dụng để mô tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các

yêu cầu và thiết kế được bắt nguồn trong ca kiểm thử Các kiểm thử này có thể là

chức năng hoặc phi chức năng

Hình 2.1 mô tả mô hình của kiểm thử hộp đen với các loại đầu vào như ngẫu

nhiên tạo ra đầu vào trong phạm vi cho phép, trường hợp ranh giới trong phạm vi

qui định đầu vào, kiểm tra đầu vào là số không, kiểm tra đầu vào là các giá trị rỗng,

đầu vào là các giá trị không hợp lệ hoặc ra khỏi phạm vi dự kiến,

Hình 2.1 Kiểm thử hộp đen

Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức

năng chính xác, nhưng nó không đủ để bảo vệ chống lại các tình huống phức tạp

hoặc có độ rủi ro cao Một lợi thế của kỹ thuật kiểm thử hộp đen là không yêu cầu

nhất thiết phải có kiến thức lập trình Các kiểm thử viên tiến hành kiểm thử ở các

khu vực và các chức năng khác nhau của phần mềm mà không liên quan đến các

lập trình viên Mặt khác, kiểm thử hộp đen được cho là “đi bộ trong một mê cung

tối tăm mà không có đèn pin”.Bởi vì họ không kiểm thử mã nguồn và đã có nhiều

tình huống các kiểm thử viên chỉ kiểm thử được tính năng trong một vài trường hợp

chứ không kiểm thử được toàn bộ hoạt động của chương trình

Phương pháp kiểm thử này có thể được áp dụng cho tất cả các cấp kiểm thử

phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận Nó không thể thực hiện được

tất cả các kiểm thử các cấp độ cao hơn nhưng nó có thể tạo ưu thế tốt khi kiểm thử

từng đơn vị

2.2.2 Kiểm thử hộp trắng

Kiểm thử hộp trắng hay còn được gọi là kiểm thử cấu trúc, quá trình thiết kế

các ca kiểm thử là quá trình xây dựng các phương pháp kiểm thử có thể phát hiện

lỗi, sai sót, khiếm khuyết của phần mềm để xây dựng một phần mềm đạt tiêu

chuẩn Kỹ thuật kiểm thử hộp trắng hay kiểm thử hướng lôgic cho phép bạn khảo

sát cấu trúc bên trong của chương trình Kỹ thuật này xuất phát từ dữ liệu kiểm thử

bằng sự kiểm thử tính lôgic của chương trình Kiểm thử viên sẽ truy cập vào cấu

trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng)

Đầu vào Hộp đen Đầu ra

Mục đích của bất cứ phương pháp kiểm thử nào cũng là để đảm bảo rằng tình trạng tốt của một hệ thống trên bề mặt của những sự tấn công độc hại hoặc là tránh những sự thất bại của phần mềm thông thường Kiểm thử hộp trắng là sự thực hiện dựa trên hiểu biết về những phần tử của một hệ thống Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại

lệ và những lỗi trình bày trong hệ thống để kiểm tra những hành động của phần mềm không được định hướng trước Kiểm thử hộp trắng có thể thực hiện để xác định tính hợp lệ cho dù việc triển khai thực hiện sau mã nhằm thiết kế, xác nhận tính hợp lệ để triển khai thực hiện chức năng bảo mật và giảm rủi ro việc bị tấn công ở những chỗ mở có thể khai thác được

Kiểm thử hộp trắng yêu cầu truy cập vào mã nguồn mặc dù kiểm thử hộp trắng có thể thực hiện tại bất cứ thời điểm nào trong vòng đời của phần mềm sau khi mã lệnh được phát triển Đó là một hành động tốt để thực hiện kiểm thử hộp trắng trong suốt giai đoạn kiểm thử đơn vị

Hình 2.2 hiển thị một kiểm thử hộp trắng đơn giản Trong hình 2.2, ở Ví dụ

1 chỉ có một đường thi hành nhưng rất dài: dài 1000*1000*1000 = 1 tỷ lệnh gọi

hàm doSomethingWith(i,j,k) khác nhau Ví dụ 2 gồm 32 câu lệnh if else độc lập

nhưng có 2^32 = 4 tỷ đường thi hành khác nhau Như vậy mục tiêu của kiểm thử 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 Tuy nhiên trong thực tế, công sức và thời gian để đạt được 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ỏ

Hình 2.2 Một ví dụ về kiểm thử hộp trắng

Trong hình 2.3 hiển thị sơ đồ luồng điều khiển của một đoạn mã lệnh Tại bước đầu tiên, điểm khởi đầu sẽ đi đến khối lệnh xử lý là điểm (1) Sau đó, luồng điều khiển sẽ đến điểm quyết định (2) Ở vị trí (2), luồng điều khiển có hai hướng

Nó có thể thực hiện đến điểm (3) để tạo ra một nhánh mới là 1  2  3 hoặc điểm (4) để tạo ra một nhánh khác là 1  2  4 Cả hai nhánh có đều đến điểm (5) và trở về điểm kết thúc

Trong hình 2.3, chúng ta có năm nút quyết định nhị phân trong đồ thị nên có

độ phức tạp C = 1 + 1 = 2 Hai đường độc lập tuyến tính trong đồ thị luồng điều khiển Kiểm thử viên có thể tạo ra hai ca kiểm thử cho đoạn mã trên là:

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

giữa hai mô-đun 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

2.2.4 Kiểm thử dựa trên mô hình

2.2.4.1 Khái niệm kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình [4] là tự động tạo ra các thủ tục kiểm thử phần mềm sử dụng các mô hình yêu cầu hệ thống và hành vi Mặc dù loại kiểm thử này đòi hỏi nhiều nỗ lực đáng kể trong việc xây dựng các mô hình trước, nhưng nó cung cấp lợi thế đáng kể so với cách phương pháp kiểm thử phần mềm truyền thống Các mẫu thiết kế hay mô hình là mô tả đơn giản của hệ thống dựa trên yêu cầu hệ thống và chức năng xác định, giúp chúng ta có thể hiểu và dự đoán được hành vi của hệ thống

2.2.4.2 Các bước thực hiện

Quá trình kiểm thử dựa trên mô hình được bắt đầu bằng việc xác định yêu cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ thống [12] Việc xây dựng mô hình còn phải dựa trên các yếu tố dữ liệu đầu vào và đầu ra Mô hình này được sử dụng để sinh ra các ca kiểm thử Chúng ta có thể biết kết quả đầu ra mong đợi từ mô hình hoặc từ quy định chuẩn Khi chạy kịch bản và kết quả thu được sẽ được so sánh với kết quả mong đợi Từ đó, quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử, …

Các bước để thực hiện kiểm thử dựa trên mô hình như được trình bày ở hình 2.4 bao gồm các bước sau:

 Xây dựng mô hình dựa trên các yêu cầu và chức năng của hệ thống

 Tạo đầu ra dự kiến từ mô tả bài toán

 Chạy kịch bản kiểm thử

 So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến

 Quyết định hành động tiếp theo (Sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lượng của phần mềm)

Hình 2.4 Các bước thực hiện kiểm thử mô hình

2.2.4.3 Những thuận lợi và khó khăn của kiểm thử dựa trên mô hình

Trong phát triển phần mềm các kiểm thử viên thường thực hiện công việc của mình bằng phương pháp truyền thống nên thường thiếu thời gian để thực hiện kiểm thử, hoặc giá thành sản phẩm khi hoàn thành thường cao….[4] Và kiểm thử dựa trên mô hình sẽ khắc phục được một số nhược điểm đó:

 Do quá trình sinh ca kiểm thử là tự động vì vậy mà rút ngắn thời gian làm phần mềm, và chất lượng phần mềm tốt hơn

 Đặc biệt tuy chi phí lớn cho việc xây dựng mô hình nhưng điều này sẽ được khấu trừ do chi phí bảo dưỡng thấp hơn nhiều khi hệ thống được hoạt động

 Quá trình sinh ra các ca kiểm thử được thực hiện một cách tự động nên sinh

ra nhiều ca kiểm thử và phát hiện nhiều lỗi

 Người kiểm thử phần mềm cần thường xuyên trao đổi với người phát triển phần mềm trong khi xây dựng mô hình hệ thống vì vậy mà tăng khả năng giao tiếp trao đổi giữa người phát triển phần mềm, và người kiểm thử

 Người kiểm thử sẽ không bị nhàm chán khi phải thực hiện lặp lại nhiều lần một công việc, điều đó làm cho người kiểm thử hài lòng với công việc của mình

 Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết kế vì vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử

 Tự động tạo và kiểm tra các ca kiểm thử trùng nhau hoặc không hữu hiệu

 Khi một yêu cầu của hệ thống thay đổi việc thay đổi các ca kiểm thử là rất phức tạp nhưng nó được giải quyết khi mà kiểm thử dựa trên mô hình Việc thay đổi các ca kiểm thử chỉ việc thay đổi mô hình của hệ thống

 Giống như các phương pháp kiểm thử khác, việc kiểm thử dựa trên mô hình chỉ phát hiện được lỗi của hệ thống mà không thể phát hiện được hệ thống còn lỗi hay không

2.2.5 Kiểm thử sử dụng máy hữu hạn trạng thái

Trong kiểm thử phần mềm có nhiều kiểu mô hình được sử dụng như: mô hình máy hữu hạn trạng thái [2], ngôn ngữ mô hình hóa thống nhất - UML, văn phạm, Trong nghiên cứu này trình bày về mô hình máy hữu hạn trạng thái

Mô hình máy hữu hạn trạng thái cũng được gọi là ôtômat hữu hạn trạng thái hoặc chỉ đơn giản là một máy trạng thái Nó được sử dụng rộng rãi trong các mô hình tính toán với nhiều ứng dụng Một máy hữu hạn trạng thái bao gồm ba thành phần chính là các trạng thái, các quá trình chuyển đổi, và các hành động Các thành phần này có thể phân thành hai loại chính là Máy hữu hạn trạng thái chấp nhận - Acceptor Finite State Machine (AFSM) và Bộ chuyển đổi hữu hạn trạng thái - Finite State Transducer (FST) Trong thực tế máy hữu hạn trạng thái đóng một vai trò quan trọng trong nhiều lĩnh vực như công nghệ điện tử, ngôn ngữ học, lôgic và đặc biệt là khoa học máy tính Trong khoa học máy tính, máy hữu hạn trạng thái

được sử dụng rộng rãi trong các mô hình hóa các hoạt động phần mềm, thiết kế hệ thống phần cứng, dịch thuật,… Do đó luận văn áp dụng mô hình này để xây dựng chương trình kiểm thử tự động cho giao diện ứng dụng Web [3]

Máy hữu hạn trạng thái được định nghĩa theo mô hình như sau:

M = (Σ, Q, δ, S, F) Trong đó:

 Σ: tập tất cả các sự kiện: tất cả các sự kiện có thể xảy ra trong chương trình,

 Q: tập trạng thái: các trạng thái khi chương trình thực hiện,

 δ: trạng thái chuyển đổi: được định nghĩa giữa các cặp trạng thái hoặc sự kiện đến các trạng thái tiếp theo,

 S: là trạng thái khởi tạo được khởi tạo khi chương trình bắt đầu thực hiện và

 F: là tập kết thúc là tập con của Q

Trong bảng 2.1 hiển thị các trạng thái chuyển đổi[5], dòng đầu tiên là các trạng thái cuối, cột đầu tiên là các trạng thái đầu, còn lại là các trạng thái chuyển đổi Bảng này được chuyển đổi thành đồ thị có hướng được biểu diễn trong hình 2.1

Bảng 2.1 Bảng chuyển trạng thái

Result

Student.aspx

s_Result Student

Hình 2.5 Mô hình đồ thị của máy FSM

Từ mô hình đồ thị của máy hữu hạn trạng thái (Hình 2.5) Chúng ta có thể thấy tất cả các đường đi từ đồ thị có hướng Ví dụ một số đường trong đồ thị này là:

1 S_ResultStudent  submit  errorSt

2 S_ResultStudent  select_khoahoc  KhoaHoc  t_stdNameText  StudentName + KhoaHoc  Submit  ResultStudent.aspx

3 S_ResultStudent  select_khoahoc  submit  errorSt

4 S_ResultStudent  t_stdNameText  StudentName  Submit  errorSt

5 S_ResultStudent  t_stdNameText  StudentName  select_KhoaHoc

 StudentName + KhoaHoc  Submit  ResultStudent.aspx

2.3 Các mức kiểm thử

Kiểm thử thường xuyên được nhóm lại theo vị trí chúng được thêm vào trong quá trình phát triển phần mềm, hoặc do mức độ đặc hiệu của kiểm thử Các cấp chính trong quá trình phát triển theo quy định của hướng dẫn SWEBOK là kiểm thử đơn vị [7], kiểm thử tích hợp [11], và kiểm thử hệ thống [8] được phân biệt bởi các mục tiêu kiểm thử mà không ám chỉ một mô hình quy trình cụ thể Các mức độ kiểm thử khác được phân loại theo mục tiêu kiểm thử

del_Name del_khoahoc t_stdnameText

Student Name

errorSt

StudentName +KhoaHoc

Submit

2.3.1 Kiểm thử đơn vị

Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng Một hàm có thể có nhiều kiểm thử từ

đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong mã lệnh Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau

Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro, thời gian và chi phí Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm Không chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung

Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá

mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác

2.3.2 Kiểm thử tích hợp

Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn

Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống

2.3.3 Kiểm thử hệ thống

Kiểm thử hệ thống giúp xác minh rằng một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình)

2.3.4 Kiểm thử chấp nhận

Kiểm thử chấp nhận thường là nghĩa vụ của khách hàng hoặc người sử dụng của hệ thống, các chủ sở hữu khác có thể cũng có liên quan Mục tiêu của Kiểm thử chấp nhận là để xác nhận sự tin tưởng trong hệ thống, các đặc điểm chức năng hoặc không có chức năng của hệ thống Tìm kiếm lỗi không phải là trọng tâm chính của kiểm thử chấp nhận Kiểm thử chấp nhận có thể đánh giá sự sẵn sàng của hệ thống

để triển khai và sử dụng, mặc dù nó không nhất thiết phải là mức cuối cùng của kiểm thử Ví dụ, một kiểm thử tích hợp có hệ thống trong một phạm vi lớn có thể được thực hiện sau khi kiểm thử chấp nhận thực hiện cho một hệ thống

Hợp đồng và quy định chấp nhận thử nghiệm: Kiểm tra nghiệm thu hợp

đồng được thực hiện với các tiêu chí chấp nhận một hợp đồng nâng cấp - phát triển phần mềm Chuẩn mực chấp nhận phải được xác định để thực hiện một thỏa thuận hợp đồng Điều lệ kiểm thử chấp nhận được thực hiện trong bất kỳ quy định nào phải căn cứ vào như các quy định của chính phủ, pháp luật hoặc các quy định an toàn

Kiểm thử Alpha và Beta: Các nhà phát triển của thị trường phần mềm

thường muốn nhận được thông tin phản hồi từ khách hàng tiềm năng hoặc khách hàng trong thị trường của họ trước khi sản phẩm phần mềm được đóng gói thương mại Thử nghiệm alpha được thực hiện tại địa điểm tổ chức đang phát triển Giai đoạn thử nghiệm, hoặc trường thử nghiệm, được thực hiện bởi khách hàng hoặc khách hàng tiềm năng tại các địa điểm riêng của họ

2.4 BỘ CÔNG CỤ SELENIUM – WEBDRIVER TRONG VIỆC KIỂM

THỬ GIAO DIỆN ỨNG DỤNG WEB

Selenium là một tập hợp mạnh mẽ các công cụ hỗ trợ phát triển nhanh chóng của các thử nghiệm tự động hóa cho các ứng dụng Web [6] Selenium cung cấp một tập phong phú các thử nghiệm chức năng đặc biệt hướng đến các nhu cầu của các

thử nghiệm trong một ứng dụng Web Các hoạt động này là rất linh hoạt, cho phép nhiều tùy chọn cho vị trí các thành phần giao diện và so sánh kết quả thử nghiệm

dự kiến sẽ chống lại hành vi ứng dụng thực tế

2.4.1 Tổng quan về Selenium

Selenium ra đời năm 2004 bởi Jason Huggin Ông đã phát triển một thư viện Javascript điều khiển tương tác với các trang, cho phép chạy lại kiểm thử đối với nhiều trang Cuối cùng thư viện này đã trở thành Selenium – Core nền tảng của các chức năng Selenium Remote Control (RC) và Selenium IDE Selenium RC là sự đột phá vì không có sản phẩm nào cho phép bạn kiểm soát một trình duyệt từ một ngôn ngữ lập trình

Năm 2006, Stimon Stewart là một kỹ sư tại Google bắt đầu làm việc với một

dự án có tên là Webdriver Ông ấy muốn có một công cụ kiểm tra trực tiếp với trình duyệt bằng cách sử dụng phương pháp tự nhiên cho trình duyệt và hệ điều hành do

đó tránh được hạn chế của Javascript Sandbox

Năm 2008 đánh dấu sự kết hợp của Selenium và Webdriver Selenium có cộng đồng lớn và hỗ trợ thương mại nhưng Web Driver là một công cụ của tương lai Việc kết hợp hai công cụ này cung cấp tập hợp các tính năng chung cho nhiều người sử dụng và lợi ích trong tự động hóa kiểm thử

2.4.2 Selenium-RC (Remote Control)

Selenium-RC cho phép các nhà phát triển tự động hóa kiểm thử sử dụng một ngôn ngữ lập trình, nó cho tính linh hoạt tối đa và mở rộng trong việc phát triển lôgic thử nghiệm Ví dụ, nếu trình ứng dụng trả về một tập kết quả của việc kiểm tra, và nếu chương trình thử nghiệm tự động cần chạy thử nghiệm trên mỗi phần tử trong tập hợp kết quả, hỗ trợ lặp đi lặp lại Các ngôn ngữ lập trình có thể được sử dụng để chuyển đổi thông qua việc tập hợp kết quả, kêu gọi Selenium lệnh chạy thử nghiệm trên mỗi mục

Selenium-RC cung cấp một API (Application Programming Interface) và thư viện cho mỗi ngôn ngữ được hỗ trợ: HTML, Java, C #, Perl, PHP, Python, và Ruby Khả năng sử dụng Selenium-RC với một ngôn ngữ lập trình bậc cao để phát triển các trường hợp thử nghiệm cũng cho phép thử nghiệm tự động được tích hợp với một dự án xây dựng môi trường tự động

2.4.3 Selenium 2 (Selenium – Webdriver)

Selenium 2 là hướng tương lai của dự án nó bổ sung mới nhất của công cụ Selenium Công cụ này cung cấp những tính năng tuyệt vời, bao gồm API định hướng gắn kết hơn và giải quyết các vấn đề tồn tại của các phiên bản trước Nó hỗ trợ các API Webdriver, cùng với công nghệ Selenium 1 API WebDriver cho sự linh hoạt tối đa trong việc kiểm thử Ngoài ra, Selenium 2 vẫn chạy Selenium RC 1 của giao diện để tương thích ngược

2.4.4 Một số Selenium-Webdriver API

2.4.4.1 Một thể hiện của browser driver

Một browser driver (ví dụ như FirefoxDriver) là một đối tượng, đối tượng này được coi như đại diện một trình duyệt trong chương trình

WebDriver ffdriver = new FirefoxDriver();

Từ đây, đối tượng ffdriver sẽ có những phương thức từ đó điểu khiển trình duyệt ở đây là Firefox Sau khi thực hiện lệnh này, trình duyệt sẽ được khởi động

2.4.4.2 Truy cập một trang Web

Điều đầu tiên chúng ta muốn làm với một Webdriver đó là truy cập vào một trang Web, thông thường điều này sẽ được thực hiện qua phương thức:

driver.get("http://www.google.com");

Khi đó trình duyệt sẽ được tự động truy cập vào địa chỉ đã truyền vào

2.4.4.3 Định vị các thành phần trên giao diện Web

Tất cả các thành phần trên giao diện Web đều có thể định vị bằng nhiều cách

mà Selenium hỗ trợ Mỗi một thành phần sẽ được ánh xạ qua một thể hiện của WebElement

Webdriver sử dụng một phương thức findElement mà tham số của phương thức này là định nghĩa vị trí của element trên trang Web Có rất nhiều cách để định nghĩa vị trí của một element trên Website trong đó có một số cách phổ biến sau:

Theo ID:

// <div id="coolestWidgetEvah"> </div>

WebElement element = driver.findElement(By.id("id_value"));

Theo Class Name:

// <div class="cheese"><span>Cheddar</span></div>

// <input name="cheese" type="text"/>

WebElement cheese = driver.findElement(By.name("cheese"));

Theo Link Text

// <a href="http://www.google.com/search?q=cheese">cheese</a>>

WebElement cheese = driver.findElement(By.linkText("cheese"));

2.4.4.4 Điền các giá trị vào trang Web qua Selenium-Webdriver

Sau khi định vị được các thành phần trên một Website và ánh xạ chúng với các WebElement, chúng ta có thể thay đổi giá trị hoặc thực hiện các thao tác chuột cũng như các thao tác gõ chữ lên WebElement đó thông qua các phương thức

// Find the text input element by its name

WebElement element = driver.findElement(By.name("q"));

// Enter something to search for

element.sendKeys("Cheese!");

// Now submit the form

element.submit();

2.4.4.5 Di chuyển giữa các cửa sổ và frame

Một số ứng dụng Web có thể chứa nhiều cửa sổ hoặc frame, Webdriver cung cấp phương thức giúp di chuyển giữa các cửa sổ thông qua tên:

driver.switchTo().window("windowName");

driver.switchTo().frame("frameName");

2.4.4.6 Điều hướng trình duyệt

Sau khi trình duyệt truy cập một trang Web và thực hiện một số sự kiện chuyển sang những trang mới, khi đó chúng ta có thể sử dụng phương thức

navigate() để quay lại một trang trước đó hoặc tới một trang theo tên trình duyệt đã truy cập trước đó

CHƯƠNG 3 PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB

Ngoài việc phát triển các ứng dụng Web, các công ty chú ý để đảm bảo chất lượng của sản phẩm Kiểm thử ứng dụng Web được coi là đảm bảo chất lượng sản phẩm Tuy nhiên các phương pháp kiểm thử tự động mới chỉ được áp dụng để kiểm thử các mô-đun chương trình Làm thế nào để kiểm thử tự động cho các giao diện người dùng vẫn đang là bài toán mở và chưa có giải pháp thỏa đáng Đề tài này tập trung nghiên cứu pha đầu trong quá trình kiểm thử tự động nhằm sinh tự động các

ca kiểm thử cho kiểm thử tự động giao diện ứng dụng Web Để thực hiện điều này bài toán xây dựng công cụ kiểm thử tự động từ máy hữu hạn trạng thái và tự động tạo ra các ca kiểm thử từ mô hình máy hữu hạn trạng thái

3.1 Mục tiêu của phương pháp nghiên cứu

Mục đích của phương pháp nghiên cứu này là để tạo ra các đường kiểm thử

tự động cho quá trình kiểm thử giao diện một ứng dụng Web, bằng phương pháp tiếp cận dựa trên mô hình Điều này được thực hiện bằng cách từ bản thiết kế của một ứng dụng Web tạo ra một máy hữu hạn trạng thái cho mỗi trang của ứng dụng Sau đó một thuật toán được phát triển và sử dụng để đi qua các đỉnh và các cạnh của mô hình, đảm bảo rằng mỗi trạng thái và chuyển đổi được bao phủ Cuối cùng mỗi đường kiểm thử được ánh xạ tới các chuỗi lệnh sử dụng Selenium, Webdriver

và chạy tự động

3.2 Tổng quan

Giả sử chúng ta có một bản thiết kế một ứng dụng Web gồm có năm trang được mô tả như sau:

1 Trang đăng nhập: login.aspx,

2 Trang hiển thị thông tin của học viên: studentInformation.aspx,

3 Trang hiển thị kết quả học tập của học viên: resultStudent.aspx,

4 Trang nhập kết quả học tập của học viên: addMark.aspx,

5 Và cuối cùng là trang đăng xuất: logout.aspx

Trang Login.aspx: đây là trang đăng nhập cho Website Người dùng được yêu cầu nhập tên đăng nhập và mật khẩu để vào các trang Web khác của ứng dụng Nếu người dùng có quyền quản trị hoặc quyền giáo vụ sẽ được vào trang nhập thông tin học viên hoặc trang nhập kết quả học tập của học viên Nếu người dùng

có quyền học viên thì sẽ được vào trang hiển thị thông tin học viên đó hoặc được vào trang hiển thị kết quả học tập của học viên Nút “Reset” sẽ xóa trắng các trường trong khi đó nút “Đăng nhập” sẽ vào trang tiếp theo tùy thuộc theo vai trò của tài khoản đó

Trang hiển thị thông tin của học viên: trang này bao gồm có một ô nhập (TextBox) cho phép người dùng nhập tên của học viên và có một nút tìm kiếm cho phép người dùng có thể tìm kiếm theo tên học viên được nhập vào ô nhập Khi người dùng nhấp vào nút tìm kiếm một danh sách học viên theo tiêu chí tìm sẽ được hiển thị Trên danh sách học viên có các liên kết cho phép người dùng nhấp vào thì sẽ chuyển người dùng sang trang kết quả học tập của học viên đó Nếu không có thông tin của học viên nào đúng theo tiêu chí tìm kiếm một thông báo sẽ được hiển thị

Trang hiển thị kết quả học tập của học viên: trang này cũng có một ô nhập cho phép người dùng tìm kiếm tên của học viên muốn hiển thị kết quả học tập Trang này cũng có một danh sách thả xuống cho phép người dùng chọn khóa học

để tìm kiếm Sau đó người dùng nhấp vào nút tìm kiếm để tìm kiếm kết quả học tập theo tiêu chí tìm

Trang nhập kết quả học tập của học viên: cho phép người dùng nhập điểm thi của các môn học cho từng học viên Trên trang này có ba danh sách thả xuống cho phép người dùng chọn học viên, chọn lớp học, chọn môn thi, có một ô nhập cho phép người dùng nhập điểm của học viên và một điều khiển ngày tháng cho phép người dùng chọn ngày thi

3.3 Tạo các ca kiểm thử cho ứng dụng Web

Các bước để tạo ra các ca kiểm thử cho ứng dụng Web trên được thực hiện như sau:

3.3.1 Xây dựng mô hình máy hữu hạn trạng thái

Để tạo ra máy hữu hạn trạng thái của ứng dụng Web trên chúng ta sẽ xây dựng từng máy hữu hạn trạng thái cho từng trang riêng biệt Để thực hiện điều này với mỗi trang Web chúng ta sẽ tạo một bảng trạng thái, các trạng thái mà trang Web có thể vào mà chỉ sử dụng các trạng thái chuyển đổi hợp lệ (tức là các thao tác của người dùng) Sau đó bảng này được sử dụng như là một hướng dẫn để tạo ra các máy hữu hạn tương ứng

Đầu tiên chúng ta xác định các trạng thái, các thao tác có thể xảy ra trong trang login.aspx Các trạng thái trong trang này bao gồm:

 S_index: trạng thái ban đầu,

 Error: trạng thái khi trang bị lỗi,

 F_main: trạng thái khi đăng nhập thành công,

 Ursname: trạng thái tồn tại có tên đăng nhập,

 Passwd: trạng thái tồn tại có mật khẩu,

 Usr+pass: trạng thái có cả tên đăng nhập và mật khẩu

Các thao tác trong trang này gồm:

 t_username: tên đăng nhập được nhập vào biểu mẫu,

 t_password: mật khẩu được nhập vào biểu mẫu,

 t_reset: xóa trắng các trường trên biểu mẫu,

 t_submit: gửi dữ liệu để xác thực

Từ đó chúng ta xây dựng được bảng 3.1 [5] Bảng 3.1 hiển thị trạng thái chuyển đổi, trong bảng 3.1 dòng đầu tiên là trạng thái kết thúc, cột đầu tiên là trạng thái bắt đầu còn lại là trạng thái chuyển đổi Các giá trị bên trong bảng là các thao tác thực hiện của người dùng từ một trạng thái này được chuyển sang trạng thái khác

Bảng 3.1 Bảng chuyển trạng thái trang login.aspx

Login.aspx s_index usrname Passwd usr + pass f_main error s_index t_reset t_usrname t_passwd - - t_submit

usr+pass t_reset del_passwd del_usrname - t_submit -

Tiếp theo là bảng chuyển trạng thái của trang studentInformation.aspx Các trạng thái trong trang được biểu diễn trong bảng 3.2 bao gồm:

 s_StudentInfor: trạng thái ban đầu,

 studentName: trạng thái tồn tại khi có tên học viên được nhập,

 f_main: trạng thái khi hiển thị thông tin học viên thành công,

 error: trạng thái khi trang bị lỗi

Các thao tác trong trang đƣợc biểu diễn trong bảng 3.2 gồm:

 t_studentName: tên học viên đƣợc nhập vào biểu mẫu,

 t_submit: trạng thái gửi dữ liệu để xác thực

Bảng 3.2 Bảng chuyển trạng thái trang studentInformation.aspx

StudentInformation.aspx s_StudentInfor studentName f_main error

 s_ ResultStudent: trạng thái ban đầu,

 studentName: trạng thái tồn tại khi có tên học viên đƣợc nhập,

 Khoahoc: trạng thái tồn tại khi chọn đƣợc khóa học của học viên,

 Student+KhoaHoc: trạng thái tồn tại khi cả tên học viên đƣợc nhập và khóa học của học viên đó đƣợc chọn,

 f_main: trạng thái khi hiển thị thông tin học viên thành công,

 error: trạng thái khi trang bị lỗi

Các thao tác trong trang đƣợc biểu diễn trong bảng 3.3 gồm:

 t_ StdName: tên học viên đƣợc nhập vào biểu mẫu,

 select_khoahoc: chọn khóa học trong biểu mẫu,

 del_StdName: xóa tên học viên đƣợc nhập vào biểu mẫu,

 del_khoahoc: bỏ chọn tên học viên,

 t_submit: trạng thái gửi dữ liệu để xác thực

Bảng 3.3 Bảng chuyển trạng thái trang resultStudent.aspx

Result

Student.aspx

s_Result Student

Student

Student+K

 S_addMark: trạng thái ban đầu,

 class: trạng thái tồn tại khi có tên lớp học đƣợc chọn,

 studentName: trạng thái tồn tại khi tên học viên đƣợc nhập,

 subject: trạng thái tồn tại khi tên môn học đƣợc chọn,

 mark: trạng thái tồn tại khi điểm môn học đƣợc nhập,

 ExamDate: trạng thái khi ngày thi đƣợc chọn,

 Class+StudentName: trạng thái tồn tại khi tên lớp đƣợc chọn và tên học viên đƣợc chọn,

 Class+ subject: trạng thái tồn tại khi tên lớp học đƣợc chọn và tên môn học đƣợc chọn,

 Class+ mark: trạng thái tồn tại khi tên lớp học đƣợc chọn và điểm đƣợc nhập,

 Class+ ExamDate: trạng thái tồn tại khi tên lớp học đƣợc chọn và ngày thi đƣợc chọn,

 Class+ studentName+ subject: trạng thái tồn tại khi tên lớp học đƣợc chọn, tên học viên đƣợc chọn và môn học đƣợc chọn,

 Class+ studentName+ mark: trạng thái tồn tại khi tên lớp học đƣợc chọn, tên học viên đƣợc chọn và điểm môn học đƣợc nhập,