Đề cương kiểm thử phần mềm tự động

Để kiểm thử tự động thì công cụ là thành phần không thể thiếu trong tiến trình này, việc kiểm thử viên thành thạo các công cụ kiểm thử đảm bảo cho quy trình kiểm thử tự động được hiệu qu

Mục lục

Bài 1: Tổng quan về kiểm thử tự động .5

1.1Khái niệm kiểm thử tự động 5

1.2 Mục tiêu của kiểm thử tự động 5

1.3 Quy trình kiểm thử tự động phần mềm 7

1.4 Kiến trúc của một khung làm việc trong kiểm thử tự động 7

1.5 Lợi ích của kiểm thử tự động 12

Bài 2: Tổng quan về kiểm thử tự động (tiếp) 13

2.1 So sánh kiểm thử tự động và kiểm thử thủ công 13

2.2 Phân loại các công cụ kiểm thử tự động 15

2.3 Lựa chọn công cụ kiểm thử tự động cho bài toán và tổ chức của bạn 21

Bài 3: Selenium WebDriver cơ bản 22

3.1 Giới thiệu Selenium WebDriver 22

3.2 Giới thiệu WebElements 24

3.3 Xác định các phần tử của trang web (Elements) 26

3.4 Các WedDriver hiện hành 28

Bài 4: Làm việc với WebDriver 29

4.1 Khám phá các đặc tính của WebDriver 29

4.2 Các tương tác năng cao của Webdriver 31

4.3 Hiểu các sự kiện của WebDriver 31

4.4 Vào ra dữ liệu với WebDriver 31

4.5 Mô hình đối tượng trang (Page Object Model) 31

Bài 5: Thảo luận 1 – Lựa chọn công cụ kiểm thử tự động 37

Bài 6: Thực hành 1 – Làm việc với Selenium WebDriver 37

Bài 7: Xây dựng công cụ kiểm thử hướng dữ liệu (Data Driven Test Framework with Selenium Webdriver) 37

7.1 Yêu cầu của một Framework kiểm thử tự động 37

7.2 Các đặc tính của một Framework 37

7.3 Framework kiểm thử mức thành phần 38

7.4 Giới thiệu về kiểm thử hướng dữ liệu 40

7.5 Kiến trúc của Framework kiểm thử hướng dữ liệu 40

7.6 Chuẩn bị và lưu trữ dữ liệu kiểm thử 41

Bài 8: Thực hành 2 – Viết kịch bản kiểm thử tự động với Selenium WebDriver 42 Bài 9: Xây dựng công cụ kiểm thử hướng dữ liệu (Data Driven Test Framework with Selenium Webdriver) (tiếp) 42

9.1 Xử lý dữ liệu kiểm thử 42

9.2 Sử dụng dữ liệu kiểm thử 44

9.3 Thao tác với các ca kiểm thử, kịch bản kiểm thử 45

9.4 Trình điều khiển kịch bản 46

9.5 Xây dựng thư viện kiểm thử 47

9.6 Nhật ký kiểm thử (Test Log) 48

Bài 10: Thảo luận 2 – Công cụ kiểm thử hướng dữ liệu 49

Bài 11: Thực hành 3 - Xây dựng công cụ kiểm thử hướng dữ liệu 51

Bài 12: Xây dựng công cụ kiểm thử hướng từ khoá (Keyword Driven Test Framework with Selenium Webdriver) 51

12.1 Giới thiệu về kiểm thử hướng từ khoá 51

12.2 Chuẩn bị và lưu trữ dữ liệu kiểm thử 52

12.3 Xử lý dữ liệu kiểm thử 52

12.4 Từ khoá ở các mức độ khác nhau 53

12.5 Thể hiện và xử lý dữ liệu kiểm thử dựa trên từ khoá 53

Bài 13: Thực hành 4 – Xây dựng công cụ kiểm thử hướng dữ liệu (tiếp) 54

Bài 14: Xây dựng công cụ kiểm thử hướng từ khoá (Keyword Driven Test Framework with Selenium Webdriver) (tiếp) 54

14.1 Thao tác với các ca kiểm thử 54

14.2 Thao tác với từ khoá 55

14.3 Sử dụng dữ liệu kiểm thử 56

14.4 Trình điểu khiển kịch bản 56

14.5 Thư viện kiểm thử 58

14.6 Nhật ký kiểm thử 59

Bài 15: Thực hành 5 – Xây dựng công cụ kiểm thử hướng từ khoá 63

Bài 16: Xây dựng công cụ kiểm thử lai cho ứng dụng web (Hybrid Test Framework with Selenium Webdriver) 63

16.1 Giới thiệu về Hybrid Framework 63

16.2 Tích hợp kiểm thử hướng dữ liệu và kiểm thử hướng từ khoá 64

16.3 Dữ liệu kiểm thử 69

16.4 Trình điều khiển ca kiểm thử 69

16.5 Báo cáo kiểm thử 73

Bài 17: Thảo luận 3 – Công cụ kiểm thử hướng từ khoá và lai 74

Bài 18: Thực hành 6 - Xây dựng công cụ kiểm thử hướng từ khoá và lai 74

Bài 19: Xây dựng công cụ kiểm thử ứng dụng Mobile với Appium 74

19.1 Giới thiệu công cụ kiểm thử ứng dụng Mobile – Appium 74

19.2 Cài đặt và cấu hình Appium 75

19.3 Viết kịch bản đơn giản với Appium 78

19.4 Thực thi kịch bản với Appium 79

19.5 Báo cáo kết quả kiểm thử 80

Bài 20: Xây dựng công cụ kiểm thử ứng dụng Mobile với Appium (tiếp) 82

20.1 Chuẩn bị dữ liệu kiểm thử 82

20.2 Trình điều khiển các ca kiểm thử 83

20.3 Xử lý lỗi 83

20.4 Thực thi các ca kiểm thử 84

20.5 Báo cáo kết quả kiểm thử 85

Bài 21: Thảo luận 4 – Kiểm thử tự động ứng dụng di động 86

Bài 22: Thực hành 7 – Viết kịch bản kiểm thử tự động cho ứng dụng di động 86

Bài 23: Phát triển hướng hành vi và tự động kiểm thử chấp nhận 87

23.1 Phát triển hướng hành vi 87

23.2 Kiểm thử chấp nhận 87

23.3 Các công cụ kiểm thử chấp nhận 90

23.4 Công cụ SpecFlow 90

23.5 Ngôn ngữ Gherkin 91

23.6 Tự động hoá kiểm thử chấp nhận với Specflow và Selenium 97

Bài 24: Thực hành 8 – Kiểm thử chấp nhận tự động với Specflow và Selenium 106 Bài 25: Thảo luận 5 – Phát triển hướng hành vi và kiểm thử chấp nhận 106

Bài 1: Tổng quan về kiểm thử tự động

1.1Khái niệm kiểm thử tự động

Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một TC

Nó sử dụng một công cụ kiểm thử tự động nào đó để rút ngắn thời gian kiểm thử Kiểm thử tự động hỗ trợ các kiểm thử viên rất nhiều tùy vào công cụ và các nội dung kiểm thử có thể thực hiện bằng tay hay không Đối với những nhiệm vụ kiểm tra khó

mà thực hiện bằng tay hoặc yêu cầu chi phí về nhân công là quá lớn thì sử dụng tool

hỗ trợ là điều hết sức cần thiết

1.2 Mục tiêu của kiểm thử tự động

Phần mềm có khiếm khuyết là thông thường và gây ra thiệt hại về kinh tế theo thời gian Chính vì vậy các tổ chức về phần mềm dành nhiều thời gian và nguồn lực để phân tích và kiểm thử phần mềm

Ngày nay ứng dụng tự động hóa vào các ngành đa dạng, trong đó có ngành kiểm thử Trước đây kiểm thử viên kiểm thử bằng tay thực hiện và ghi lại kết quả trên giấy, nhưng với ứng dụng công nghệ thông tin thì các công cụ kiểm thử cũng phát triển từ rất sớm hỗ trợ kiểm thử viên rất nhiều và đặc biệt là các trường hợp kiểm thử đặc biệt mà kiểm thử bằng tay không thể thực hiện được hoặc rất khó khăn để thực hiện Các tổ chức càng quan tâm đến chất lượng phần mềm thì càng có nhiều chức năng và nội dung được kiểm tra đòi hỏi kiểm thử viên phải thực hiện nhiều công việc hơn vì vậy kiểm thử với sự hỗ trợ của công cụ là rất cần thiết

Để giúp các kiểm thử viên có thể kiểm thử tự động đó là các Test Tool, tuy nhiên không phải trong bất cứ trường hợp nào cũng có thể kiểm thử tự động Vậy kiểm thử thử tự động khi nào?

 Kiểm thử tự động trong các tình huống sau:

 Không đủ tài nguyên:

 Khi số lượng tình huống kiểm tra (TC) quá nhiều mà các kiểm thử viên không thể hoàn tất bằng tay trong thời gian cụ thể nào đó

Có thể lấy một dẫn chứng là khi thực hiện kiểm tra chức năng của một website Website này sẽ được kiểm tra với 6 môi trường gồm 4 trình duyệt và 2 hệ điều hành Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6 lần so với việc kiểm tra cho một môi trường cụ thể

 Kiểm tra hồi quy:

Trong quá trình phát triển phần mềm (PTPM), nhóm lập trình thường đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm tra Thực tế cho thấy việc đưa ra các phiên bản phần 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 tra tốt chạy sai mặc dù phần code của nó không hề chỉnh sửa Để khắc phục điều này, đối với từng phiên bản, kiểm thử viên không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó Điều này khó khả thi

về mặt thời gian nếu kiểm tra thủ công

 Kiểm tra vận hành phần mềm trong môi trường đặc biệt:

Đâ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 đó kiểm thử viên có thể xác định được các yếu tố về phần cứng, 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 tra 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" Vì vậy kiểm thử tự động tăng độ tin cậy, chính xác, giảm bớt chi phí thực hiện kiểm thử cho các kiểm thử viên về thời gian, công sức; bên cạnh đó việc thiết kế test case cho mỗi lần kiểm thử giúp kiểm thử viên rèn luyện kỹ năng lập trình (viết test script), giảm sự nhàm chán khi cứ mãi thực hiện các kiểm thử thủ công Hoạt động kiểm thử tự động nhằm mục đích kiểm tra, phát hiện những lỗi của phần mềm trong những trường hợp đoán trước Nghĩa là nó thường được thực hiện sau khi đã thiết kế xong các tình huống (TC) Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì kiểm thử viên phải đánh giá và chọn ra những TC nào phù hợp hoặc cần thiết để áp dụng kiểm thử tự động dựa trên những tiêu chí đã đề cập bên trên

 Mục tiêu của kiểm thử tự động :

 Giảm bớt công sức và thời gian thực hiện

 Tăng độ tin cậy

 Giảm sự nhàm chán

 Giảm chi phí cho tổng quá trình kiểm thử

 Ưu điểm của kiểm thử tự động:

 KTPM không cần can thiệp của kiểm thử viên

 Giảm chi phí khi thực hiện kiểm tra số lượng lớn TC hoặc TC lặp lại nhiều

Hình 1.1: Quy trình KTTĐ trong mối quan hệ với KTPM

Để kiểm thử tự động thì công cụ là thành phần không thể thiếu trong tiến trình này, việc kiểm thử viên thành thạo các công cụ kiểm thử đảm bảo cho quy trình kiểm thử tự động được hiệu quả

Một công cụ kiểm thử phần mềm tự động yêu cầu phải làm được những công việc sau:

 Hiểu các mã assembly được kiểm tra một cách tự động

 Tiến hành các nhiệm vụ đơn giản và lặp đi lặp lại một cách tự động

 Tạo ra các kịch bản và chạy các kịch bản trong những lô lệnh theo một lịch trình đã vạch ra

 Kiểm tra giao diện của các đối tượng COM và các thành phần phần mềm khác với tập dữ liệu được thiết lập sẵn

 Truy cập vào dữ liệu để xác minh lại các kết quả

 Truy cập vào Regestry để xác minh lại các kết quả

1.4 Kiến trúc của một khung làm việc trong kiểm thử tự động

Kiến trúc của một khung kiểm thử tự động giống như một kiến trúc ứng dụng: nó vạch ra cấu trúc tổng thể cho môi trường thử nghiệm tự động, xác định các chức năng chung, các bài kiểm tra tiêu chuẩn, cung cấp các khuôn mẫu cho cấu trúc kiểm tra và chỉ ra các quy tắc cơ bản về cách các bài kiểm tra được đặt tên, tài liệu và quản lý, để một thư viện thử nghiệm duy trì và chuyển nhượng được

Sự cần thiết cho một khuôn khổ thử nghiệm được xác định rõ ràng và thiết kế đặc biệt tốt trong thử nghiệm Đối với một ứng dụng, bạn có thể ít nhất cho rằng nhà phát triển có một cơ bản sự hiểu biết về thiết kế phần mềm và các nguyên tắc phát triển, nhưng đối với các bài kiểm tra tự động, tỷ lệ chênh lệch cao so với người kiểm tra không có nền tảng kỹ thuật và không nhận thức được kỹ thuật phát triển có cấu trúc Khung kiểm tra được trình bày trong chương này có thể được áp dụng cho bất kỳ

hệ thống tự động hóa nào Cách tiếp cận được miêu tả trong Cẩm nang này Sự khác biệt duy nhất giữa một phương pháp tiếp cận và một là trong cách các trường hợp thử nghiệm cá nhân và kịch bản được cấu trúc Bằng cách áp dụng một khuôn khổ, bạn có thể tận hưởng hiệu quả đến từ việc chia sẻ các chức năng chung và hiệu quả mà các bài kiểm tra tiêu chuẩn và các mẫu cung cấp

Kiến trúc chung của một khung làm việc trong kiểm thử tự động được thể hiện như hình dưới:

Các chắc năng chung:

Các chức năng phổ biến là các thủ tục tự động hoá các tác vụ được chia sẻ trong toàn bộ thư viện thử nghiệm Một số chức năng có thể được chia sẻ bởi tất cả các kiểm tra, chẳng hạn như các thủ tục phục hồi từ các lỗi không mong muốn, kết quả nhật ký

và các tác vụ tương tự khác Các chức năng này thường được cấu trúc như các thủ tục con, có nghĩa là chúng có thể được gọi từ bất kỳ điểm nào và trở lại bước tiếp theo sau khi gọi nó

Các loại chức năng phổ biến khác là các tập lệnh hữu ích: ví dụ như làm mới cơ

sở dữ liệu hoặc nạp nó bằng một tập các bản ghi đã biết, xóa các tệp công việc tạm thời hoặc quản lý môi trường thử nghiệm Rõ ràng xác định và chia sẻ những thói quen này sẽ làm giảm và đơn giản hóa sự phát triển và bảo trì testware Các kịch bản này nên được cấu trúc sao cho chúng có thể được thực hiện độc lập hoặc được liên kết với

nhau tuần tự như một phần của chu kỳ kiểm tra được tích hợp

Các tiêu chuẩn kiểm thử:

Test templates

Mẫu kiểm tra cung cấp cấu trúc để phát triển các bài kiểm tra cá nhân Nó có thể được sử dụng để tăng tốc độ phát triển bằng cách cho phép một định dạng đơn được nhanh chóng sao chép và điền vào, tiết kiệm thời gian cho các bài kiểm tra mới và thúc đẩy sự nhất quán Mặc dù các quy ước đặt tên cho các bài kiểm tra và các nội dung của chúng rất quan trọng, và được mô tả đầy đủ hơn trong phần tiếp theo của Bản đồ ứng dụng, điều quan trọng là mỗi bài kiểm tra riêng lẻ phải tuân theo một cấu trúc chung

để nó có thể dễ dàng liên kết với khung kiểm tra

Ví dụ, các bài kiểm tra được dự kiến sẽ được gọi là chương trình con và chia sẻ với các bài kiểm tra khác phải được phát triển để cho phép quay lại kiểm tra gọi; Tương tự như vậy, các bài kiểm tra sẽ được thực hiện từ trình điều khiển hoặc cơ chế kiểm soát khác phải có khả năng hoàn trả kiểm soát khi chúng được hoàn tất Các phương tiện chính xác để hoàn thành việc này sẽ thay đổi theo từng cách tiếp cận tự động hóa và được thảo luận trong phần liên quan cho từng cách tiếp cận

Application Map

Tương tự như từ điển dữ liệu cho một ứng dụng, Application Map mô tả và mô

tả các thành phần bao gồm ứng dụng và cung cấp thuật ngữ được sử dụng để kết hợp các bài kiểm tra với ứng dụng

1.5 Lợi ích của kiểm thử tự động

- Tiết kiệm tiền bạc vời thời gian: Nhận định này đặc biệt đúng nếu xét trong giai đoạn bảo trì của các dự án lớn Mỗi tuần chúng ta phải thực hiện regression test từ 1 đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày Gần như không thể thực hiện cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể với nguồn nhân lực vô cùng khiêm tốn

- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test case với độ chính xác cao hơn

- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta có thể thực thi số lượng lớn test case trong một thời gian ngắn Điều này giúp chúng ta tăng độ bao phủ trong giai đoạn regression test (một ví dụ điển hình)

- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất

Ngoài ra còn một số lợi ích khác như:

+ Giảm bớt công sức và thời gian thực hiện quá trình kiểm thử

+ Tăng độ tin cậy

+ Giảm sự nhàm chán cho con người + Rèn luyện kỹ năng lập trình cho kiểm thử viên + Giảm chi phí cho tổng quá trình kiểm thử

Bài 2: Tổng quan về kiểm thử tự động (tiếp)

2.1 So sánh kiểm thử tự động và kiểm thử thủ công

2.1.1 Hạn chế của kiểm thử thủ công

Kiểm thử thủ công có một số hạn chế:

+ Không sử dụng lại được trong trường hợp kiểm thử hồi quy

+ Khi phải điền Form có quá nhiều thông tin thì kiểm thử thủ công tiêu tốn thời gian và nguồn lực

+ Độ tin cây không cao

+ Trong một số trường hợp như kiểm thử hiệu năng, kiểm thử chịu tại thì kiểm thư thủ công khó thực hiện được

+ Tốn thời gian đối với mỗi lần release người kiểm thử vẫn phải thực hiện lại một tâp hợp các test case đã chạy dẫn tới sự mệt mỏi lãng phí công sức

2.1.2 Ưu điểm của kiểm thử tự động

Độ tin cậy cao(Reliability): Nhờ sự ổn định vượt trội của công cụ kiểm thử tự động so với con người, đặc biệt trong trường hợp có quá nhiều test cases cần được thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ công

- Khả năng lặp (Repeatability): Hãy cùng xem xet một ví dụ: Trong một ngày thời tiết xấu chúng ta phải thực thi một test case với 50 bộ dữ liệu đầu vào khác nhau Nếu thực thi cách thủ công, ngồi trước màn hình, nhập dữ liệu, click click , check check … trong 50 lần có lẽ bạn sẽ gục ngã sớm trên bàn làm việc của mình NHƯNG, nếu bạn thực thi bằng kiểm thử tự động, chỉ cần nhập dữ liệu vào file excel ( or csv,

…) cho script chạy và ngồi rung đùi cho tới khi nhận được báo cáo Với độ ổn định cao, bạn hoàn toàn có thể tin tưởng vào kết quả thực thi của công cụ kiểm thử tự động Quả là một viễn cảnh lý tưởng hơn nhiều

- Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử tự động, chúng ta có thể sử dụng cho nhiều phiển bản ứng dụng khác nhau, đây được gọi là tính tái sử dụng

- Nhanh (Fast): Đây là điều không cần phải bàn cãi, nếu cần 5 phút để thực thi một test case cách thủ công, có thể bạn cần chưa đầy 30s để thực thi cách tự động

- Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tự động đúng cách, chúng

ta có thể tiết kiệm được rất nhiều chi phí, thời gian và nhân lực (Khi nào nên áp dụng kiểm thử tự động sẽ được nói ở cuối bài)

2.1.3 Hạn chế của kiểm thử tự động

+ Các công cụ kiểm thử tự động mặc dù rất thuận tiện về nhiều phương diện nhưng thực tế dù như thế nào đi chăng nữa thì nó cũng không phải là một công cụ có thể thay thế hoàn toàn quá trình kiểm thử Để thực hiện các thiếp lập tự động thì vẫn cần có con người, phải bỏ công sức, tiền bạc và thời gian

- Khó mở rộng, khó bảo trì (Poor scalability and maintainability): Trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động là khó hơn nhiều so với kiểm thử cách thủ công Số lượng công việc phải làm để mở rộng phạm vi cho kiểm thử tự động là nhiều hơn và khó hơn kiểm thử thủ công Cũng vậy, để cập nhật một test case thủ công, chúng ta chỉ cần mở ra và gõ, rất đơn giản Nhưng kiểm thử tự động lại không đơn giản như vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiều công việc như debug, thay đổi dữ liệu đầu vào, và cập nhật code mới

- Khả năng bao phủ thấp(Low coverage): Chính vì việc khó ứng dụng, khó mở rộng, cũng như đòi hỏi quá nhiều kỷ năng lập trình nên độ bao phủ của kiểm thử tự động khá thấp (xét trên góc nhìn toàn dự án)

- Vấn đề công cụ và nhân lực (Technology vs people issues): Cho đến nay công

cụ hỗ trợ kiểm thử tự động đã có những bước phát triển mạnh mẽ, chúng ta có các công cụ rất tốt như QTP, Selenium, Test Complete, LoadTest, Jmeter, Visual Studio,

… Nhưng nhìn chung vẫn còn rất nhiều mặt hạn chế Ngoài ra nguồn nhân lực đạt yêu cầu cũng không nhiều

+ Mất thời gian và công sức để tạo mới và chỉnh sửa script test

+ Mất chi phí cho các các công cụ tự động hóa như phí bản quyền, bảo trì, tìm hiểu, giáo dục

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

+ 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

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

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

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

2.2 Phân loại các công cụ kiểm thử tự động

Khi bắt đầu làm việc với kiểm thử tự động, chắc chắn chúng ta phải từng nghe đến cụm từ Test Automation Framework – Mô hình (nền tảng) kiểm thử tự động Cụm

từ này có thể gây khó chịu cho vài người, làm cho họ cảm thấy nó là một khái niệm khó hiểu và khó thực hiện Bài này được viết ra với mục đích giải thích vấn đề này một cách đơn giản

Mô hình kiểm thử tự động – một cách đơn giản – là một tập hợp các quy luật, nguyên tắc dùng trong quá trình viết mã kiểm thử Các quy luật giúp chúng ta viết mã theo một cách mà kết quả cuối cùng là “giảm thiểu việc chỉnh sửa mã kiểm thử khi ứng dụng thay đổi”

NHỮNG MÔ HÌNH PHỔ BIẾN HIỆN NAY

• Tuyến tính (Linear)

• Hướng Modular

• Hướng dữ liệu (Data Driven)

• Hướng từ khóa (Keyword Driven)

• Hỗn hợp (Hybrid)

Chúng ta sẽ đi qua từng kiểu mô hình và các đặc điểm của nó

TUYẾN TÍNH – LINEAR FRAMEWORK

Đặc điểm cơ bản

• Mọi thứ liên quan đến mã đều được định nghĩa bên trong phương thức kiểm thử

• Không quan tâm đến việc lãng phí và trùng lặp các câu lệnh

• Việc record/playback thường xuyên sinh ra mã tuyến tính

• Dễ dàng để bắt đầu

• Khó khăn trong việc chỉnh sửa

Mô hình này có thể được dùng trong dự án nhỏ, nơi mà không có quá nhiều màn hình giao diện cũng như chức năng Mặc khác, chúng ta cũng hay dùng Mô hình này khi sử dụng một công cụ kiểm thử tự động lần đâu tiên Ngoài hai lý do trên, Mô hình này không được khuyến khích sử dụng trong kiểm thử tự động

HƯỚNG MODULE – MODULARITY FRAMEWORK

• Cho phép chúng ta dễ dàng viết các mã dễ dàng được chỉnh sửa

Mục đích chính của mô hình này là việc chỉnh sửa dễ dàng Nếu có bất kỳ thay đổi nào trên giao diện, chúng ta chỉ cần chỉnh sửa trong các phương thức và đối tượng

Mã kiểm thử chính của chúng ta vẫn hoạt động chính xác Mô hình POM (Page Object

Model) – thường được dùng với Selenium – là một dạng của mô hình hướng modul Toàn bộ trang web sẽ được chia nhỏ thành các trang Các đối tượng UI của từng trang được định nghĩa bên trong từng lớp của trang đó Nếu có bất kỳ thay đổi nào trên ứng dụng web, chúng ta chỉ cần chỉnh sửa lớp của trang đó, những lớp của trang khác vẫn giữ nguyên Kết quả cuối cùng chúng ta sẽ có những đoạn mã được bảo trì tốt hơn và

Đặc điểm cơ bản

• Dữ liệu kiểm thử (giá trị đầu vào và đầu ra) được tách khỏi mã nguồn và lưu trong một tập tin bên ngoài Nó có thể là một tập tin CSV, một bảng Excel hay một cơ

sở dữ liệu

• Khi mã kiểm thử thực thi, các giá trị này được lấy ra từ tập tin, chứa vào biến

và thay thế các giá trị cứng (nếu có) trong mã nguồn

• Thực sự hữu ích khi mà cùng một kịch bản kiểm thử cần thực thi với nhiều dữ liệu đầu vào khác nhau

Có vài ưu điểm khi áp dụng mô hình này Tất cả các giá trị kiểm thử được lưu bên ngoài mã nguồn, do đó, bất kỳ thay đổi nào xảy ra trong quá trình phát triển ứng dụng, chúng ta chỉ cần thay đổi dữ liệu trong tập tin bên ngoài, và mã kiểm thử tự động của chúng ta vẫn được giữ nguyên

Một ưu điểm khác là, khả năng sử dụng một kịch bản kiểm thử cho nhiều dữ liệu khác nhau Ví dụ như, bạn đang làm một kịch bản đăng nhập hệ thống với 100 user Bạn có thể viết 1 đoạn mã và một tập tin lưu trữ thông tin của 100 user Sau đó, bạn chỉ cần thực thi 1 lần, và đi qua cả 100 bộ dữ liệu Bạn dễ dàng phát hiện, với kiểu dữ liệu nào thì đoạn mã Fail Đây cũng là một thế mạnh khi bạn đang làm kiểm thử phủ định – Negative Test

HƯỚNG TỪ KHÓA – KEYWORD FRAMEWORK

Đặc điểm cơ bản

• Cả dữ liệu và chức năng được định nghĩa bên ngoài mã nguồn

• Cần phát triển các từ khóa cho nhiều chức năng khác nhau

• Mã kiểm thử tự động đôi khi được lưu trữ ở một tập tin bên ngoài mã nguồn giống như mô hình hướng dữ liệu Các bước của kịch bản kiểm thử được viết từng bước với định dạng bảng, nơi mà sử dụng các từ khóa và dữ liệu kiểm thử

• Mã nguồn chính sẽ đọc các bước trong định dạng bảng và thực thi các chức năng tương ứng

• Cho phép các kỹ sư kiểm thử thủ công, nhưng người không biết về lập trình, có thể là một phần, ở một mức độ, của nhóm kiểm thử tự động

Ưu điểm của mô hình hướng từ khóa

Mô hình này rất hữu dụng trong những trường hợp mà kịch bản kiểm thử có quá nhiều thay đổi Nếu bất kỳ bước nào trong kịch bản kiểm thử bị thay đổi, chúng ta không cần phải chỉnh sửa mã nguồn Chúng ta chỉ cần chỉnh sửa tập tin bên ngoài và như vậy, kịch bản kiểm thử tự động sẽ được chỉnh sửa theo

Chúng ta định nghĩa toàn bộ kịch bản ở tập tin và đưa cho kỷ sư kiểm thử thủ công, họ sẽ thêm các đoạn văn bản (text) hoặc chỉnh sửa cái có sẵn Bằng cách này, kỹ

sư kiểm thử tự động cũng có thể trở thành một phần của nhóm kiểm thử tự động bởi vì

họ không cần phải lập trình gì cả Họ chỉ cần chỉnh sửa tập tin ở những vị trí cần thiết

và kịch bản kiềm thử tự động sẽ được chỉnh sửa một cách tự động

Một lợi ích khác của mô hình này là, kịch bản kiểm thử của bạn trở thành một công cụ độc lập Bạn chỉ cần bảo trì kịch bản kiểm thử trong một tập tin và nếu bạn cần thay đổi công cụ kiềm thử tự động ở điểm nào đó, bạn có thể dễ dàng chỉnh sửa bằng cách viết lại cách đọc và thực thi tập tin với công cụ mới

Mặc khác, khuyết điểm của mô hình này là, bạn cần phát triển các từ khóa cho các chức năng khác nhau Trong một dự án lớn, có thể có rất nhiều từ khóa mà bạn cấn phải nhớ và tổ chức nó hợp lý Bản thân việc này có thể sẽ làm một công việc nặng nhọc cho quá trình phát triển kiềm thử tự động

Ở vài trường hợp phức tạp, khi mà các đối tượng UI không thể được xác định dễ

dàng, chúng ta phải sử dụng nhiều kỹ thuật khác nhau để xử lý, mô hình này không hữu dụng cho lắm

Mô hình hướng từ khóa là một mô hình ưa thích của nhiều kỹ sư kiểm thử tự động Robot Framework – công cụ kiểm thử tự động được phát triển bởi Google – là một công cụ phổ biến đi theo hướng từ khóa Những công cụ đi theo hướng từ khóa này còn có Test Architect hay Katalon Studio

HƯỚNG HỖN HỢP – HYBRID FRAMEWORK

Một cách đơn giản, mô hình này sử dụng kết hợp nhiều kỹ thuật với nhau Chúng

ta có thể sử dụng hướng dữ liệu đồng thời với hướng modul Trong vài trường hợp, chúng ta có thể dùng từ khóa song song với modul Cơ bản, khi nào chúng ta sử dụng nhiều hơn một mô hình, đó là lúc chúng ta sử dụng hỗn hợp – Hybrid

Mô hình tồn tại là để cuộc sống của chúng ta dễ dàng hơn Nó giúp chúng ta viết

ra những kịch bản kiểm thử tự động dễ chỉnh sửa và dễ đọc Không có mô hình, kiểm

thử tự động có thể sẽ trở nên cực kỳ khó khăn Với những thay đổi nhỏ của ứng dụng

mà chúng ta phải chỉnh sửa hàng trăm vị trí trong mã nguồn

Do đó, hiểu và ứng dụng tốt những mô hình là một yêu cầu cần thiết cho bất kỳ

ai muốn tham gia và lĩnh vực kiểm thử tự động này

2.3 Lựa chọn công cụ kiểm thử tự động cho bài toán và tổ chức của bạn

2.3.1 Tại sao phải kiểm thử tự động

Nhu cầu về tốc độ là thực tế là thần chú của thời đại thông tin Bởi vì công nghệ hiện đang được sử dụng như là một vũ khí cạnh tranh trên các mặt trước của sự tương tác của khách hàng, lịch trình phân phối phải chịu áp lực thị trường Các sản phẩm muộn có thể làm mất doanh thu, khách hàng và thị phần Tuy nhiên, áp lực kinh tế cũng đòi hỏi nguồn lực và giảm chi phí, dẫn đến nhiều công ty áp dụng tự động hóa để giảm thời gian để thị trường cũng như cắt giảm ngân sách kiểm tra

Mặc dù có thể tốn kém để bị trễ thị trường, nhưng nó có thể là thảm khốc để cung cấp một sản phẩm bị lỗi Sự thất bại của phần mềm có thể làm mất hàng triệu hoặc thậm chí hàng tỉ đô la, và trong một số trường hợp toàn bộ các công ty đã bị mất

Vì vậy, nếu bạn không có đủ người hoặc thời gian để thực hiện kiểm tra đầy đủ để bắt đầu, việc thêm tự động hóa sẽ không làm giảm sự mất ổn định phần mềm và lỗi Vì nó được cung cấp đầy đủ thông tin rằng lỗi phần mềm - thậm chí chỉ một lỗi - có thể tốn hơn hàng triệu lần so với ngân sách thử nghiệm của bạn, ưu tiên hàng đầu là phải cung cấp phần mềm đáng tin cậy Một khi đã đạt được, sau đó tập trung vào việc tối ưu hóa thời gian và chi phí Nói cách khác, nếu phần mềm của bạn không hoạt động, nó không quan trọng như thế nào nhanh chóng hoặc giá rẻ bạn cung cấp nó

2.3.2 Tiêu chí lựa chọn công cụ kiểm thử tự động

Sự thành công của kiểm thử tự động một phần lớn phụ thuộc vào việc lựa chọn công cụ kiểm thử tự động (automation tools), trên thị trường hiện có rất nhiều tools bao gồm cả tool miễn phí (open source) lẫn tool thương mại (commercial tools) và việc chọn ra công cụ nào phù hợp nhất cho dự án là một thách thức thật sự

Bạn cần đưa ra một tiêu chuẩn đúng đắn để chọn ra tool chính xác cho mình, sau đây là một số tiêu chuẩn phổ biến, việc áp dụng các tiêu chuẩn nào, ưu tiên những tiêu chuẩn nào là phụ thuộc vào bài toán cụ thể

1) Bạn có đủ nhân lực cần thiết cho dự án automation

2) Ngân sách của bạn cho automation là bao nhiêu?

8 ) Tool có thể hỗ trợ những loại test nào? trên những nền tảng nào?

9) Tool có giao diện dễ dùng và tạo test script không? script có dễ bảo trì không?

10) Tool có hỗ trợ xử lý gì trong những trường hợp phức tạp?

11) tool có hỗ trợ việc xử lý dữ liệu đầu vào không? chẳng hạn dữ liệu test từ exel, xml,

12) Tool có cung cấp một report tốt, thông tin chi tiết và rõ rang không

13) Nó có thể tích hợp với các tool bạn đang dùng không?

14) Chính sách giá của nhà sản xuất

Ngoài ra còn có thêm một số tiêu chuẩn (criteria) khác mà tùy bài toán, chúng

ta cần thêm vào trong danh sách

Bài 3: Selenium WebDriver cơ bản

3.1 Giới thiệu Selenium WebDriver

a Lịch sử của Selenium

Với các ứng dụng web trở thành phương pháp defacto để phát triển các ứng dụng người dùng cuối, cần 1 giải pháp cho việc test Điều này có nghĩa nhiều hơn và chú trọng hơn vào framework tự động hóa trình duyệt để giúp kiểm tra trang web Nhiều năm qua, con người sử dụng Selenium IDE và Selenium RC để dẫn dắt nhiều loại trình duyệt khác nhau Selenium được tạo ra ban đầu bởi Jason Huggins, đã giải quyết được vấn về của việc trình duyệt tương tác với người dùng

Đây là 1 framework tự động hóa tốt, tuy nhiên nó bị giới hạn bởi JavaScript sandbox trong các trình duyệt JavaScript sandbox thực thi chính sách bảo mật khi JavaScript được thực hiện để ngăn chặn mã độc trên máy khách hàng Chính sách bảo mật chính mà con người thông qua là Same Origin Policy Nếu bạn cần chuyển từ HTTP sang HTTPS, trình duyệt sẽ ngăn chặn hành động do lúc đó chúng ta không còn

ở cùng một gốc Điều này khiến người phát triển trung bình như bạn khá phẫn nộ!

Selenium API cơ bản được thiết kế để làm việc từ bên trong máy chủ Người phát triển hay tester viết test đều phải làm như vậy trong HTML bằng cách sử dụng thiết kế 3 cột dựa trên FIT

Bạn có thể thấy điều này nếu mở Selenium IDE có 3 input box cần được hoàn thành cho mỗi dòng thực thi tuy nhiên nó có khá nhiều vấn đề

Patrick Lightbody và Paul Hammant đã nghĩ ra cách tốt hơn để điều khiển test của họ

và với cách này họ có thể sử dụng ngôn ngữ phát triển mà họ thích Họ đã tạo ra Selenium Remote Contral sử dụng Java như 1 máy chủ web

Phần tiếp theo ta sẽ tìm hiểu về kĩ thuật cơ bản của WebDriver

WebDriver sử dụng phương pháp thích hợp nhất để truy cập khả năng tiếp cận của API Nếu bạn nhìn vào Firefox, nó sử dụng JavaScript để truy cập API Nếu bạn nhìn vào Internet Explorer, nó sử dụng C++ Phương pháp này có nghĩa là ta có thể điều khiển trình duyệt bằng cách tốt nhất có thể nhưng có một nhược điểm là với các trình duyệt mới ra trên thị trường sẽ không hỗ trợ phương pháp này như với Selenium

WebDriver API

WebDriver API là một phần của hệ thống mà bạn tương tác trong suốt quá trình Nhiều thứ đã thay đổi từ API có độ dài 140 dòng mà Selenium RC API có Cái này hiện tại đã dễ quản lý và có thể thực sự phù hợp trên một màn hình thông thường Bạn

có thể thấy điều này khi bạn bắt đầu sử dụng WebDriver ở chương tiếp theo Điều này được tạo thành từ WebDriver và các đối tượng WebElement

driver.findElement(By.name("q")) và element.sendKeys("I love cheese");

Những lệnh này sau đó được dịch sang SPI Điều này có thể thấy ở phần tiếp theo

WebDriver SPI

Khi mã code đi vào Stateless Programming Interface hay SPI, sau đó được gọi đến 1 cơ chế phá vỡ các nhân tố sử dụng ID duy nhất và sau đó gọi lệnh có liên quan Tất cả API gọi trên sau đó gọi dưới Sử dụng ví dụ ở phần trước sẽ có code như sau:

findElement(using="name", value="q") sendKeys(element="webdriverID", value="I love cheese")

Từ đó sẽ gọi đến giao thức JSON Wire Ta vẫn sử dụng HTTP như một cơ chế vận chuyển chính Ta liên lạc tới các trình duyệt và 1 kĩ thuật vận chuyển client server đơn giản mà người phát triển đã tạo là JSON Wire Protocol

JSON Wire protocol

Những người phát triển WebDriver đã tạo ra 1 cơ chế vận chuyển gọi là JSON Wire Protocol Giao thức này có thể vận chuyển tất cả các yếu tố cần thiết tới code điều khiển nó Nó sử dụng REST giống như API như một cách để giao tiếp

3.2 Giới thiệu WebElements

Trang Web là thành phần cơ bản cấu tạo nên Website, do đó việc đặc tả một trang Web là bước căn bản để có thể đặc tả chính xác một Website Thông thường, mỗi trang Web sẽ thực hiện các chức năng, nhiệm vụ khác nhau Các trang Web có thể được liên kết với nhau bằng việc chuyển trang với thao tác nhấp chuột vào đường dẫn (link) hoặc các nút (button) Trong phần này, báo cáo trình bày một số khái niệm căn bản giúp trang Web hoạt động

Phần tử Web (Web Element) Phần tử Web là các thành phần cơ bản cấu tạo nên một trang Web, mỗi phần tử Web có nhiều thành phần nhưng có 4 thành phần cơ bản, bao gồm:

Thẻ mở (Opening Tag): Là phần mở đầu của một phần tử Web để thông báo việc phần tử Web nào đó được sử dụng Ví dụ: Để khai báo việc sử dụng một đoạn văn bản,

ta sử dụng thẻ mở <p>

Các thuộc tính (Attributes): Mô tả thêm thông tin về phần tử Web, mỗi phần tử Web có số lượng thuộc tính khác nhau, nhưng tất cả các phần tử Web đều có 4 thuộc tính cơ bản sau:

– id: Đặc tả định danh duy nhất của phần tử Web

– class: Đặc tả một hay nhiều lớp của phần tử Web

– style: Đặc tả CSS style cho phần tử Web

– title: Đặc tả thông tin mở rộng về phần tử Web

Nội dung (Element Content): Nằm giữa thẻ mở và thẻ đóng, được dùng để hiển thị nội dung của phần tử Web

Thẻ đóng (Closing Tag): Nằm ở vị trí cuối cùng trong cấu trúc một phần tử Web dùng để thông báo việc kết thúc nội dung của một phần tử Web Ví dụ: Để thông báo kết thúc một đoạn văn bản, ta sử dụng thẻ đóng </p>

Để thao tác với các phần tử trong C# ta sử dụng giao diện IWebElement

Các thuộc tính của IwebElement

Các phương thức của IwebElement

3.3 Xác định các phần tử của trang web (Elements)

Selenium sử dụng Locator để tìm kiếm và so khớp các phần tử trên trang web

mà có cần tương tác Có 8 loại locator phổ biến được sử dụng: id, name, identifier, dom, xpath, link, css và ui

class name Locates elements whose class name contains the search value

(compound class names are not permitted) css selector Locates elements matching a CSS selector

Id Locates elements whose ID attribute matches the search value

Name Locates elements whose NAME attribute matches the search value link text Locates anchor elements whose visible text matches the search value

partial link

text

Locates anchor elements whose visible text partially matches the search value

tag name Locates elements whose tag name matches the search value

Xpath Locates elements matching an XPath expression

Trong C# ta có thể sử dụng các phương thức sau để tìm kiếm một phần tử trên trang web

Cho trước form gồm 2 phần tử là Username và Passworld như sau:

<form name="loginForm">Login

Username: <input id="username" type="text" name="login" />

Password: <input id="password" type="password" name="password" />

<input type="submit" name="signin" value="SignIn" /></form>

* Định vị phần tử bằng ID

Trên các ứng dụng web ngày nay, các phần tử thường có 1 thuộc tính ID cho tất

cả các control của chúng trên trang Một control sẽ là 1 phần tử mà bạn có thể tương tác cùng và nó không phải văn bản tĩnh Điều này cho phép Selenium tìm mục duy nhất, do đó ID nên là duy nhất, và sau đó hoàn thiện action nó cần làm đối với phần tử

WebElement elementUsername = driver.findElement(By.id("username")); WebElement elementPassword = driver.findElement(By.id("password"));

* Tìm kiếm phần tử bằng tên

WebElement elementUsername = driver.findElement(By.name("login"));

WebElement elementPassword = driver.findElement(By.name("password"));

* Bằng Identifier: Tương tự như tên

* Bằng Link

<a href="link.html">Name of the Link</a>

WebElement element=driver.findElement(By.linkText("Name of the Link"));

Opera Opera Chromium / Presto 10.5 and newer

Safari Selenium 5.1 and newer

 Ngoài ra còn một số Driver đặc biệt khác

PhantomJSDriver Headless PhantomJS browser backed by

QtWebKit

GhostDriver project

HtmlUnitDriver Headless browser emulator backed by

 Một số Driver của hãng thứ 3

Browser Latest version

Google Chrome driver 2.22 - 2016-06-06 changelog issues wiki

Bài 4: Làm việc với WebDriver

Chúng ta lần lượt khảo sát các đặc tính của WebDriver

+ Thiết lập các thông số mong muốn cho một trình duyệt

Trong đó Capability có một số thông số phổ biến như sau:

+ Chụp ảnh màn hình

Tuỳ theo trình duyệt, mỗi trình duyệt tuân theo một thứ tự khác nhau, cơ bản tư

có thể sử dụng đoạn code sau để chụp ảnh màn hình

+ Khám phá trình điều hướng: chúng ta xem và phân tích đoạn code sau để thấy được các tính năng điều hướng của WebDriver

4.2 Các tương tác năng cao của Webdriver

4.3 Hiểu các sự kiện của WebDriver

4.4 Vào ra dữ liệu với WebDriver

4.5 Mô hình đối tượng trang (Page Object Model)

a Giới thiệu về POM (Page Object Model)

POM là một mô hình thiết kế testscript và có các đặc điểm sau:

+ Tạo Kho đối tượng (object repository) cho các phần tử giao diện của web + Dưới mô hình này, mỗi trang web trong ứng dụng đang viết có thể tương ứng với một lớp

+ Lớp này sẽ tìm kiếm tất cả phần tử của web và chỉ chứa các phương thức để thực hiện vận hành trên các phần tử của trang web đó

+ Tên của các phương thức này có thể được đặt như là công việc mà chúng đang thực hiện Nó rất dễ dàng ánh xạ với các hoạt động xảy ra trong giao diện với người dùng

Ví dụ, Nếu muốn nhập user cho textbox user trên một trang, tên phương thức đó

có thể là “setUserName”

b Lợi ích của POM

Khi tổ chức theo mô hình POM, các lợi ích thu được là:

+ Mô hình này làm cho code trở nên rõ ràng và dễ hiểu hơn, nó tránh sự lặp lại nhiều lần trong code Do đó, Mô hình này sẽ trở nên dễ dàng hơn trong việc bảo trì và tái sử dụng

+ Các kho lưu trữ là độc lập với các kịch bản test Vì vậy, chúng ta có thể sử các kho lưu trữ giống nhau cho các mục đích khác nhau với những tool khác nhau Ví dụ, chũng ta có thể tích hợp POM với TNG cho việc test chức năng

C Thực thi POM và ví dụ

Chúng ta cần xây dựng mô hình trang như hình sau:

Chúng ta xẽ xây dựng POM cho trang PageBase như sau:

{

private IWebDriver driver;

[FindsBy(How = How.LinkText,Using = "Home" )]

private IWebElement HomeLink;

public PageBase(IWebDriver _driver)

[FindsBy(How = How.Id, Using = "quicksearch_main" )]

private IWebElement QuickSearchTextBox;

[FindsBy(How = How.Id, Using = "find" )]

[CacheLookup]

private IWebElement QuickSearchBtn;

[FindsBy(How = How.LinkText, Using = "File a Bug" )]

[FindsBy(How = How.Id, Using = "Bugzilla_login" )]

private IWebElement LoginTextBox;

[FindsBy(How = How.Id, Using = "Bugzilla_password" )]

private IWebElement PassTextBox;

[FindsBy(How = How.Id, Using = "log_in" )]

[CacheLookup]

private IWebElement LoginButton;

[FindsBy(How = How.LinkText, Using = "Home" )]

private IWebElement HomeLink;

[FindsBy(How = How.Id, Using = "bug_severity" )]

private IWebElement SeverityDropDown;

private IWebElement Hardware;

[FindsBy(How = How.Id, Using = "op_sys" )]

private IWebElement OpSys;

[FindsBy(How = How.Id, Using = "short_desc" )]

private IWebElement ShortDesc;

[FindsBy(How = How.Id, Using = "comment" )]

private IWebElement Comment;

[FindsBy(How = How.Id, Using = "commit" )]

private IWebElement Commit;

Bài 5: Thảo luận 1 – Lựa chọn công cụ kiểm thử tự động

Bài 6: Thực hành 1 – Làm việc với Selenium WebDriver

Xem nội dung thực hành trong tài liệu thực hành

Bài 7: Xây dựng công cụ kiểm thử hướng dữ liệu (Data Driven Test Framework with Selenium Webdriver)

7.1 Yêu cầu của một Framework kiểm thử tự động

Yêu cầu ở mức cao thì một Framework kiểm thử tự động phải thoả mãn ít nhất

3 tính chất:

+ Tự động hoá việc thực thi kiểm thử

Framework phải hỗ trợ hoàn toàn việc tự động hoá kiểm thử, nếu chỉ mỗi hỗ trợ việc thực thi ca kiểm thử thì chưa đủ Nó còn phải hỗ trợ cả việc quản lý lỗi phát sinh, phân tích kết quả kiểm thử, quản lý báo cáo kiểm thử và ghi nhật ký việc kiểm thử một cách chi tiết

+ Dễ sử dụng

Framework phải được sử dụng một cách dễ dàng và thuận tiện bởi kỹ sư kiểm thử hoặc những người có trách nhiệm kiểm thử chỉ với các kiến thức cơ bản về sử dụng máy tính và phần mềm

Framework cũng cần phải hỗ trợ khả năng thiết kết, sửa đổi và quản lý kịch bản kiểm thử, ca kiểm thử, thực thi chúng và xem kết quả kiểm thử mà không cần thêm bất

cứ kỹ năng lập trình nào

+ Bảo trì được

Nó phải đủ dễ để bảo trì, sửa đổi, nâng cấp cả dữ liệu test lẫn mã nguồn của framework khi yêu cầu kiểm tra của hệ thống thay đổi hoặc được cập nhật hoặc do một lý do nào đó mà cần phải sửa đổi Hơn thế nữa nó cũng phải dễ dàng cho phép thêm các tính năng mới vào framework

bằng một lệnh có thể thao tác trên giao diện đồ hoạ hoặc dòng lệnh Điều này cũng đòi hỏi framework phải có khả năng thiết lập môi trưởng kiểm tra và hơn thế nữa trước khi thực thi một ca kiểm thử nó còn phải kiểm tra tiền điều kiện của ca kiểm thử đó đã được sẵn sàng hay chưa?

- Chức chạy và dừng ca kiểm thử: Framework phải hỗ trợ chức năng chạy từng

ca kiểm thử hoặc dừng ca kiểm thử được chỉ định

- Chức năng quản lý lỗi:

- Chắc năng xác minh kết quả kiểm thử:

- Quản lý trạng thái ca kiểm thử:

- Xử lý kết quả không mong đợi:

- Ghi nhật ký chi tiết:

- Tự động sinh báo cáo:

7.3 Framework kiểm thử mức thành phần

a Kịch bản kiểm thử tuyến tính

Các tập lệnh kiểm tra tuyến tính không sử dụng bất kỳ hàm bên ngoài nào, và như minh họa trong hình, chúng tương tác trực tiếp với hệ thống được kiểm tra Các tập lệnh tuyến tính đơn giản nhanh chóng được viết ban đầu và chúng rất thích hợp cho các tác vụ nhỏ Vấn đề với các tập lệnh tuyến tính là khi các nhiệm vụ trở nên lớn hơn và phức tạp hơn, chúng cũng phát triển lâu hơn, phức tạp hơn và nói chung là khó duy trì Họ cũng có xu hướng lặp lại mã mà có thể được đưa ra và sử dụng lại Nếu nhiều kịch bản thử nghiệm tương tự được tạo ra, vấn đề bảo trì chỉ phát triển lớn hơn bởi vì một thay đổi trong hệ thống được thử nghiệm có thể yêu cầu thay đổi trong mỗi tập lệnh

b Thư viện kiểm thử và trình điều khiển kịch bản kiểm thử

Mã hóa có cấu trúc là một mô hình lập trình chung và tất nhiên nó cũng có thể áp dụng được với mã kiểm tra Ở mức thấp có thể có nghĩa là chỉ đơn giản bằng cách sử dụng các chức năng nhỏ trong cùng một tập tin như kịch bản thử nghiệm chính Trong các hàm kiểm tra mức sử dụng cao hơn được đặt vào các thư viện thử nghiệm bên ngoài, từ nơi chúng có thể được sử dụng bởi bất kỳ tập lệnh kiểm tra nào

Khi các thư viện thử nghiệm làm hầu hết các bài kiểm tra thử nghiệm thực tế kịch bản có thể ngắn và đơn giản Bởi vì các kịch bản chỉ điều khiển thực hiện kiểm tra chúng thường được gọi là các tập lệnh trình điều khiển Hình 2.5 chỉ ra cách hai kịch bản trình điều khiển sử dụng thư viện thử nghiệm tương tự để tương tác với hệ thống được kiểm tra

7.4 Giới thiệu về kiểm thử hướng dữ liệu

Ở dạng cơ bản nhất, kiểm tra theo dữ liệu là một Khung Tự động Kiểm tra (Test Automation Framework), trong đó dữ liệu "ổ đĩa" thử nghiệm không được mã hóa cứng nhưng lấy từ bảng bên ngoài mã nguồn và được sử dụng bởi các tập lệnh kiểm tra trong quá trình thực hiện

Thật thuận tiện để giữ dữ liệu cho các bài kiểm tra tự động trong các kho lưu trữ đặc biệt có hỗ trợ tuần tự truy cập vào một bộ dữ liệu, ví dụ như bảng tính Excel, bảng cơ sở dữ liệu, mảng, v.v Thông thường dữ liệu được lưu trữ trong một tệp tin văn bản và được phân tách bằng dấu phẩy hoặc trong các tệp Excel và được trình bày dưới dạng bảng Điều này cho phép bạn sửa đổi chúng một cách dễ dàng Nếu bạn cần thêm nhiều dữ liệu, bạn chỉ cần chỉnh sửa tệp tin trong bất kỳ trình soạn thảo văn bản nào hoặc trong Microsoft Excel (trong trường hợp có các giá trị được mã hoá cứng, bạn phải sửa đổi cả dữ liệu và mã)

Thử nghiệm theo hướng dữ liệu cho phép bạn tạo các dự án kiểm thử tự động

có thể được mở rộng vô hạn bằng cách thêm dòng văn bản mới vào tệp tin văn bản hoặc bảng tính Ví dụ, dữ liệu được đọc từ một nguồn bên ngoài và fed-line-by-line vào thử nghiệm chức năng cho đến khi không có dữ liệu bên ngoài hơn Bằng cách này, các trường hợp thử nghiệm tự động mới được thêm vào dữ liệu bên ngoài đơn giản mở rộng vòng lặp cho mỗi dòng dữ liệu mới Không phải là một khoa học tên lửa

mà chỉ là quy trình 3 bước:

+ Đọc dữ liệu từ các nguồn dữ liệu được lưu trữ ở bộ nhớ ngoài

+ Điền dữ liệu tương ứng với các kịch bản kiểm thử

+ Xác minh kết quả kiểm thử

7.5 Kiến trúc của Framework kiểm thử hướng dữ liệu

Cơ bản các framework kiểm thử hướng dữ liệu theo 3 bước và được trình bày theo hình bên dưới