DI ĐỘNG VÀ PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT
3.2. Kỹ thuật sinh ca kiểm thử và dữ liệu dựa trên yêu cầu người dùng và điều kiện chấp
3.2.2. xuất tiếp cận sinh trường hợp kiểm thử và dữ liệu kiểm thử
3.2.2.1. Xây dựng giải pháp AgileUATM
Xem xét các cách tiếp cận và các nghiên cứu đã được trình bày ở mục 1 của phần giới thiệu và mục 1.5 của chương 1, tác giả luận án đã quan sát thấy rằng tất cả các
nghiên cứu được thực hiện và các nghiên cứu đề xuất cho đến nay chủ yếu liên quan đến sinh thử nghiệm GUI, dữ liệu được tạo từ mô hình UML hoặc tạo trường hợp thử nghiệm và dữ liệu thử nghiệm từ mã nguồn. Chỉ có một cách tiếp cận được đề xuất bởi Pandit và Tahiliani [84] sử dụng xử lý ngơn ngữ tự nhiên để trích xuất thơng tin từ câu chuyện của người dùng và tiêu chí chấp nhận để tạo trường hợp kiểm tra và dữ liệu thử nghiệm.
Theo cách tiếp cận được đề xuất trong luận án, xText được sử dụng để định nghĩa một ngôn ngữ, gọi là myDSL, ngôn ngữ định nghĩa theo miền ứng dụng. Z3 SMT Solver được áp dụng để sinh trường hợp kiểm thử và dữ liệu kiểm thử. Phát triển công cụ AgileUATM nhằm thực hiện các chức năng như tạo các trường hợp kiểm thử và dữ liệu kiểm thử, dịch DSL sang ngôn ngữ Z3 SMT để sinh dữ liệu tự động; sinh mã lệnh và kịch bản kiểm thử đơn vị theo phương pháp BDD. Giải pháp đề xuất có một số ưu điểm như sinh trường hợp kiểm thử và sinh dữ liệu kiểm thử sớm trong quy trình phát triển dự án ngay khi đặc tả yêu cầu. Đặc tả dưới dạng myDSL có thể bảo trì hoặc thay đổi các điều kiện và tạo dữ liệu thử nghiệm thuận tiện hơn trong quá trình phát triển dự án, thừa kế và kiểm thử hồi qui. Ngoài ra, bằng cách thêm heuristic vào myDSL có thể hỗ trợ kỹ sư kiểm thử sinh dữ liệu theo mục đích cụ thể. Cơng cụ AgileUATM sinh mã và kịch bản kiểm thử đơn vị BDD với Cucumber. Hình 3.1 trình bày cách tiếp cận được đề xuất và kiến trúc của AgileUATM.
Hình 3.1. Mơ hình hoạt động của giải pháp AgileUATM đề xuất
Ghi chú: các ví dụ và dữ liệu được sử dụng sau đây là các yêu cầu, nội dung, dữ liệu từ dự án ACMapp, hồ sơ phân tích thiết kế hồn tồn bằng tiếng Anh nên NCS sử dụng nguyên gốc ngôn
Các thành phần trong giải pháp AgileUATM:
(1) User story (US): yêu cầu của sản phẩm với bối cảnh của người dùng được
viết bởi khách hàng hoặc bởi chủ sở hữu sản phẩm (Product owner-PO). Nếu có sự hợp tác giữa nhóm phát triển và khách hàng sẽ có sự hiểu biết tốt hơn về sản phẩm. Bảng 3.1 mơ tả ví dụ mẫu về một US theo cú pháp đã trình bày trong mục 3.2.1.
Bảng 3.1. Ví dụ mẫu về mơ tả một user story
USER I WANT TO So that I CAN <achieve some
STORY AS A <type of user> <perform some goals>
ID tasks>
Asaconference I want to be able so that I can register
1 attendee, to register quickly and cut down on
online, paperwork
(2) Acceptance criteria (AC): Trong môi trường phát triển Agile, AC là một tập
hợp các câu lệnh, mỗi câu lệnh có tun bố thành cơng / thất bại được chỉ định trong cả các yêu cầu chức năng và phi chức năng và được áp dụng. AC được cung cấp để xác định ranh giới cho một câu chuyện hoặc tính năng người dùng và được nhà phát triển sử dụng để kiểm thử. Vì vậy, từ yêu cầu được xác định tại bước (1), PO và kỹ sư kiểm thử xác định các điều kiện chấp nhận cho từng câu chuyện của người dùng
để có cơ sở cho trường hợp thử nghiệm trong các bước tiếp theo. Tiêu chí chấp nhận AC cũng giúp nhóm phát triển xác định tầm quan trọng của US một cách nhanh chóng vì họ biết cách US được kiểm tra, hiểu nỗ lực cần thiết để triển khai nó. Ví dụ về đặc tả AC được trình bày trong Bảng 3.2.
Bảng 3.2. Ví dụ về đặc tả tiêu chuẩn chấp nhận cho tính năng Register
Acceptance INPUT PROCESS OUTPUT
Criteria ID
Valid User- Pre-condition: fieldname.length>0; name, First- Condition: Username.length >=4 and
AC1 name, Last- Username.length ¡=16 and not user- Register name, Email, name.contains (!%$#@ˆ˜?/*)
successfully Password, Email is valid format.
Institution, Password.length =8 characters and Detail-Info
Password.contains(!,@,#,$,%,ˆ,˜,*)
(Username.length>0 and
AC2 Invalid Username.length <= 4) or Register Username Username.length >=16 or failed
ˆ Username.contains(!%$#@ ?/()*+-=)
(3) Đặc tả yêu cầu kiểm thử bằng ngôn ngữ myDSL: là một ngôn ngữ đặc tả
chuyên biệt cho một miền ứng dụng cụ thể. Dựa trên xText, tác giả luận án định nghĩa cú pháp, ngữ nghĩa và quy tắc cho ngơn ngữ đặc tả hình thức được gọi là myDSL. Trong cú pháp này, các kỹ sư kiểm thử dựa vào AC được mô tả trong bước (2), xác định lại các điều kiện này thành dạng myDSL. Các kỹ sư kiểm thử có thể sử dụng bất kỳ trình soạn thảo nào như Notepad, Wordpad hoặc có thể sử dụng tính năng chỉnh sửa mà tác giả luận án đã phát triển để biên dịch và kiểm tra cú pháp đặc tả myDSL. Hình 3.2 là cú pháp được xác định để xây dựng ngơn ngữ đặc tả myDSL và Hình 3.3 là một ví dụ AC được chỉ định bởi trình soạn thảo giải pháp được đề xuất (từ AC đến myDSL). Bảng 3.3 dưới đây là mô tả cú pháp của myDSL.
(1) ================ myDSLsyntax ===================
(2) grammar org.xtext.example.domainmodel.Domainmodel with org.eclipse.xtext.common.Terminals
(3) generate domainmodel "http://www.xtext.org/example/domainmodel/Domainmodel"
(4) (5) Model:
(6) myDSL+=myDSL*;
(7) myDSL: (8)
(9) Enum | Define | Precondition | Postcondition | Testcase | Function | Run | Example | Limit; (10) (11)terminal DIGIT: (12) (13) '-'?('0'..'9')* (14) ; (15)terminal REAL: (16) DIGIT'.'DIGIT (17) ; (18) terminal STRING : (19) (20) '"' ('\\' ('b'|'t'|'n'|'f'|'r'|'u'|'"'|"'"|'\\') | !('\\'|'"') )* '"'; (21) (22) // "'" ( '\\' ('b'|'t'|'n'|'f'|'r'|'u'|'"'|"'"|'\\') | !('\\'|"'") )* "'"; (23) ConditionOperation: '||' | 'and'; (24) MathOperation: '+' | '-' | '*' | '/' | '^' | '%'; (25) CompareOperation: '>' | '<' | '=' | '>=' | '<='; (26) Variable: MyID | DIGIT | REAL; (27)
(28) MathFormula: '('? Variable ( MathOperation Variable)* ')'?;
(29) CompareFormula: MathFormula CompareOperation MathFormula | MathFormula CompareOperation STRING; (30)
(31) Method: '.'('onlyDigit' | 'onlyLetter' | 'length' | 'contain')('(' (STRING)* ')')?; (32)
(33) MyID: (ID | ('!')ID) (Method)*; (34)
(35) TestcaseElement: CompareFormula | MathFormula; (36)
(37) //enum
(38) Enum: 'enum' (ID | 'Int' | 'Real' | 'Bool' | 'String') '{' EnumOptions '}'; (39) EnumOptions: (ID)*;
(40) //define
(41) Define: 'define' name=ID '{' (42)
(43) '('?(CompareFormula | MyID)')'? (ConditionOperation '(‘? (CompareFormula | MyID)')'?)* (44) '}'
(46) //precondition (47) Precondition: 'precondition' '{' (49) '}' (50) ; (51) //postcondition (52) Postcondition: 'postcondition' '{' (54) '}' (55) ; (56) //example (57) Example: 'example' '{' (59) '}'; (60) //limit
(61) Limit: 'limit' DIGIT; (62)
(63) TestCondition: STRING ('('? TestcaseElement ')'? '('? (ConditionOperation '('? TestcaseElement')'?) * ')'?)? (64) ; (65) //test case (66) Testcase: 'testcase' '{' (67) (TestCondition)* (68) '}' (69) ;
(70) Datatype: 'Int' | 'Real' | 'Bool' | 'String';
(71) Function: 'function' name=ID '(' (Datatype name=ID (',' Datatype name=ID) *) * ')'; (72) Run: 'run';
================ myDSLsyntax ===================
Hình 3.2. Xây dựng cú pháp định nghĩa cho ngôn ngữ myDSL
Bảng 3.3. Mô tả cú pháp của ngôn ngữ đặc tả myDSL
Yếu tố từ khóa Mơ tả cú pháp Ví dụ
Enum Lệnh bắt đầu kịch bản kiểm thử Enum Register {SUCCESS Cú pháp: enum<scenarioname> FAIL INVALID}
{[datareturned]}
Function It is a statement to define input for enum function Register (String statement. It is necessary to determine the user, String fname, String variable represent for each test data. lname, String password, The syntax: Function < nameof enum > String email)
(<Typename1 > [, Typename])
Precondition It is a statement to define precondition for precondition {fname.length Postcondition variable. The syntax is:> 0 && fname.length < 50}
precondition{<comparing−expression >}
Define It is a statement to define comparing define userLength expression and assign it to a variable. The {user.length >= 4 && syntax: define <name> {<comparing − user.length <= 16}
expression >}
Test case It is a statement to begin a block code to testcase{”SUCCESS”
define test case. The syntax: testcase{(< conSuccess &&
result >< comparingexpression >)∗} emailContain && validUser
&& validPass ”FAIL” conFail ”INVALID” }
Run It is statement to finish test scenario. Its syntax: run
Hình 3.3. Ví dụ về đặc tả myDSL cho tính năng đăng ký tài khoản Register
(4) Dịch myDSL sang Z3 SMT: Sau khi kết thúc bước đặc tả hình thức, cơng cụ
AgileUATM sẽ chuyển đổi ngôn ngữ đặc tả này sang ngơn ngữ SMTLib để sử dụng tùy chọn đối sánh tìm kiếm nghiệm thỏa mãn các điều kiện được chỉ định trong bước đặc tả. Tại bước này, công cụ dịch từ myDSL sang Z3 SMT sẽ được thực hiện. Ví dụ cú pháp chuyển đổi như trong Bảng 3.4.
Bảng 3.4. Ví dụ mô tả cú pháp chuyển đổi từ MyDSL sang Z3
myDsl (.agt) Z3 (.smt2)
enum Register {SUCCESSFAIL (declare-datatypes () ((Register
IN VALID} SUCCESS
FAIL INVALID)))
function Register (String user, String (declare-fun result () Register) fname, String lname, String password, (declare-const user Int) String email) (declare-const fname Int)
(declare-const lname Int) (declare-const password Int) (declare-const email Int)
String datatype will be changed to check the length of string
precondition {fname.length > 0 && (assert (and (> fname 0) (< fname 50))) fname.length < 50}
define userLength {user.length >= 4 && (definefun userLength () Bool (and (>= user.length <= 16} user 4) (<= user 16)))
myDsl (.agt) Z3 (.smt2)
testcase { ”SUCCESS” conSuccess && (assert(=result(ifconSuccess emailContain&&validUserandand SUCCESS
validPass” FAIL” conFail ”INVALID” } (if conFail FAIL INVALID ))))
Run (check-sat)
(5) Sinh Test Cases/ Test Inputs: Trong bước này, dựa trên đặc tả Z3 SMT
(.smt2), Z3 SMT Solver tìm các giải pháp thỏa mãn các điều kiện được đặc tả
trong .smt2 (tức là đáp ứng các điều kiện đầu vào, đầu ra, các yêu cầu của vấn đề). Từ đó, người kiểm thử có thể sử dụng các trường hợp thử nghiệm và kiểm tra dữ liệu để xác minh sản phẩm (bằng thử nghiệm hộp đen hoặc bằng kiểm đơn đơn vị được thực hiện bởi lập trình viên). Ví dụ mẫu ở bảng Bảng 3.5 bên dưới.
Bảng 3.5. Ví dụ về test case / test input được sinh ra cho tính năng Register
FName UserName Password Email Result
73u8OB oJRNjn npWWaY dmC3Ih FAIL
8vAlr41WW hhC4fCkA OiWiMRTTa 0ZQ6kf@qe9Y.ca SUCCESS
a m B x FAIL
B1d 6de cIC FeX FAIL
DIZMlH90 yrw9bobAMpLyOrAfw JaDGTu8r 6elcYlQV FAIL
dR 5u t1 j7 FAIL
FECEGpD jfyK8Yi FiP6Mg5 SsQtPWd FAIL
IFuMBzWfA 5GhPr0LXw 9mRQsZSsfu oJ3WWV@NShJV.cn SUCCESS
L3kq ntZt MFyD y13M FAIL
aFGH Hj%rD N&^gt#R G6amh@hsn.tv FAIL
Từ bước (3) đến bước 5 được thực hiện bởi công cụ AgileUATM và được mô tả bở thuật toán DSL2TestCase như sau:
Giải thuật DSL2TestCase sinh test case và test data từ DSL file:
//Input: file DSL (.agt) //Output: test data (.csv)
DSL2TestCase (input.agt, output.csv)
1. call ReadWriteFile to read DSL file
2. call TranslateDsl to translate myDSL file to z3 smt language,
2.1. convert String type to Int or Boolean type before translation (ex: length of a string is Int, use the length of String to generate String, contain of String)
2.2. covert infix expression to prefix expression 2.3. return list of code z3 (z3 smt file)
//GenTest using z3 constraint solver to find models read and parse file SMT2
3. invoke SMT solver
3.2. loop while (s. check () == Status.SATISFIABLE and limit)
// limit is a number of test cases we want to generate
3.3. find all satisfiable models and getModel ()
if data is String, use generateStringDataByCondition method to generate a string.
3.4. seek to next model, remove the duplicated value 4. call ReadWriteFile method to write data test to CSV file. 5. return output.csv
(6) Kiểm tra kết quả (Validate Output): Dữ liệu được tạo ra sẽ được kiểm tra
lại và được xác nhận bằng các heurictics thông qua myDSL. Tại bước này, kết quả được kiểm tra và có thể thêm điều kiện, chiến lược để tối ưu hóa việc tạo ra các trường hợp kiểm thử, dữ liệu đầu vào thử nghiệm trong đặc tả myDSL - quay lại bước xác định các yêu cầu. Ví dụ, đối với kiểu dữ liệu số của một trường có thể áp dụng các kỹ thuật phân tích giá trị biên (BVA), phân vùng tương đương (EPC) và loại bỏ đối xứng để làm giảm dữ liệu sinh ra. Ngồi ra, các thuật tốn meta-heuristic có thể được áp dụng để tối ưu hóa dữ liệu được tạo ra (nếu cần). Trong trường hợp có quá nhiều giải pháp thỏa mãn (dữ liệu sinh ra quá lớn) được sinh ra bởi Z3 SMT, chúng ta có thể điều chỉnh các kết quả được cung cấp theo cách thủ công để phù hợp hơn với các yêu cầu thực tế.
(7) Tệp dữ liệu kết quả (TestcaseOp.csv): Kết quả các trường hợp kiểm thử và dữ
liệu sinh ra được lưu trữ ở định dạng XLS / CSV hoặc ở các định dạng khác để sử
dụng sau này. Người phát triển có thể sử dụng đặc tả BDD kết hợp sử dụng Cucumber để thực hiện kiểm thử tự động. Người kiểm thử có thể thực hiện kiểm thử chức năng cho hệ thống. Dựa trên đầu ra của cách tiếp cận được mơ tả trong Hình 3.1, AgileUATM cịn hỗ trợ tính năng sinh mã kịch bản kiểm thử (TestScript) theo ngôn ngữ Gherkin và tải dữ liệu này để thực hiện cho kiểm thử đơn vị theo phương pháp BDD trong mơi trường Cucumber. Hình 3.4 thể hiện luồng hoạt động của tính năng sinh mã kịch bản kiểm thử theo phương pháp BDD.
.feature file: được gọi là Test Scenario. Mục đích của tệp này là tạo ra một kịch
bản thử nghiệm cho yêu cầu của người dùng để có thể kiểm tra dữ liệu được xây dựng bằng cơng cụ AgileUATM.
Hình 3.4. Workflow sinh test script cho Unit test (BDD)
File .feature có định dạng:
Given: Thiết lập điều kiện, ngữ cảnh cho kịch bản kiểm thử When: Hành động thực hiện
Then: Kiểm tra output/ kết quả của hành động
Test Case/ Test Input: Dữ liệu ca kiểm thử được sinh ra bởi AgileUATM. Auto Test Script: Tạo kịch bản kiểm thử.
Cucumber Execution: Công cụ thực thi ca kiểm thử dựa trên kịch bản và dữ liệu
được sinh ra bởi AgileUATM.
Report: Báo cáo kiểm thử (trường hợp kiểm thử thành công hay thất bại).
Thuật toán sinh file BDD- CreateBdd:
//Input: file BDD (. feature) and file data test (.csv)
//Output: file BDD with data like cucumber format //(.feature), file java test case in corresponding path.
1. createBdd (bdd.feature, output.csv) //output.csv is generated form step (6) above
2. call ReadWriteBDDFile method to read BDD file and data test file.
3. merge BDD file with data test file and
4. write it to a file [name of BDD file] + ‘cucumber.feature’ in the same folder with BDD file.
5. generate java test case file in corresponding path.
6. return a test script file that developer can use in automation unit test.
Khi một dự án được bắt đầu, chủ sở hữu sản phẩm (PO – Product Owner) và người kiểm tra xác định US và AC cho mỗi câu chuyện. PO sử dụng các nguyên tắc được đề xuất để làm cho câu chuyện của người dùng rõ ràng hơn và tuân thủ các quy tắc
và chỉ định kịch bản để viết tiêu chí chấp nhận. Đây là một bước quan trọng vì AC ảnh hưởng trực tiếp đến myDSL để tạo dữ liệu thử nghiệm. Điều đặc biệt là cách tiếp cận của tác giả luận án sử dụng các heurictics cho việc đặc tả myDSL với kỳ vọng rằng dữ liệu thử nghiệm được tạo sẽ được tối ưu hóa và bao phủ điều kiện. Vấn đề là Z3 SMT không hỗ trợ dịch cho kiểu String, vì vậy chúng tơi tạo bản dịch để tạo dữ liệu thử nghiệm với nhiều trường hợp có kiểu dữ liệu String. Quá trình xử lý kiểu String sẽ được thực hiện đồng thời với việc xử lý dữ liệu thử nghiệm bằng cách sử dụng Z3 SMT. Từ các case test/test inputs được tạo ra, các kỹ sư phát triển tiếp tục thực hiện nó với cơng cụ Cucumber.
AgileUATM được phát triển dưới dạng cơng cụ tự động có thể hỗ trợ q trình kiểm tra tự động hóa. Các tính năng của nó được đưa ra trong Bảng 3.6 và kiến trúc của nó được mơ tả trong Hình 3.1.
Bảng 3.6. Các chức năng của cơng cụ AgileUATM
No. Các tính năng của AgileUATM
1 Đặc tả Acceptance criteria từ User stories
2 Đặc tả hình thức cho AC sử dụng các heuristics (MyDSL) 3 Dịch MyDSL sang Z3 SMT2
4 Sinh ca kiểm thử và dữ liệu kiểm thử 5 Kiểm tra dữ liệu
6 Sinh Testscript cho Cucumber để thực thi Unit Test theo BDD
Hình 3.5 là màn hình của cơng cụ AgileUATM sinh file test.feature và testscript cho phương pháp kiểm thử BDD.
3.2.2.2. Bài toán thực nghiệm cho phương pháp đề xuất
Ứng dụng được dùng trong nghiên cứu này là dự án ACM (Academic Conferrence Management – phiên bản di động iOS và Android). Ứng dụng này sẽ cung cấp một giải pháp cho các hội nghị, hội thảo của một trường đại học hoặc một tổ chức. Ứng dụng sẽ cung cấp cho người tham dự sự kiện dễ dàng chia sẻ hoạt động của họ, theo dõi lịch biểu của họ, ghi chú nhanh, gửi tin nhắn thời gian thực cũng như nhiều tính năng khác.
Các bước thực hiện:
Bước 1: Xác định các US của ứng dụng
Là một người tham dự (attendee), họ muốn xem thông tin về các hội nghị, quản lý hồ sơ và lịch biểu của họ. Trong một cuộc họp, người tham dự muốn kết nối với mọi người bằng cách theo dõi họ và gửi một tin nhắn. Người tham dự cũng có thể chụp ảnh, viết một cái gì đó về các hoạt động và sau đó chia sẻ với những người tham dự khác để họ có thể xem, thích và nhận xét về bài viết.
Hình 3.6 Giao diện của ứng dụng ACM
Hơn nữa, ứng dụng phải thông báo về các tương tác như ai đó thích hoặc nhận xét về bài viết của mình, đặc biệt là trước khi bất kỳ hoạt động nào được bắt đầu 30 phút.
Ban tổ chức nên cho phép người tham dự xếp hạng diễn giả và hoạt động vì bất kỳ hoạt động nào được hồn thành, người tham dự cũng có thể gửi đánh giá cho họ để