Thứ Ba, 30 tháng 12, 2014

Software Testing Type

Để bắt đầu dấn thân vào Automation testing step by step mình xin chia sẻ nội dung bài viết  mô tả sự khác nhau của nhiều loại kiểm thử, được sử dụng để test phần mềm trong chu kỳ phát triển phần mềm Software Development Lifecycle (SDLC)

Manual testing:
kiểu test này là kiểm thử phần mềm thông thường, các thao tác thực hiện bằng con người không sử dụng một số công cụ kiểm thử tự động hoặc kịch bản. Trong kiểu test này người kiểm thử đóng vai trò là người dùng cuối kiểm tra nhận dạng/ xác định chức năng của phần mềm để tìm ra các hành vi không mong muốn/ bất khả kháng hoặc là lỗi phần mềm
Một số giai đoạn thuộc dạng manual testing như unit testing, integration testing, system testing và user acceptance testing
người kiểm thử lập kế hoạch test, viết testcase hoặc kịch bản test để test phần mềm để đảm bảo đầy đủ các ca kiểm thử. Manual testing cũng bao gồm các kiểm thử thăm dò, người kiểm thử khám phá phần mềm để xác định lỗi trong đó

Automation testing
automation testing là một phương pháp kiểm thử tự động được hiểu như là test tự động, khi người kiểm thử viết kịch bản và sử dụng phần mềm khác để test. Quy trình này liên quan đến tự động hóa các quy trình manunal. Automation testing được sử dụng chạy lại các kịch bản test được viết bằng tay nhanh chóng và lặp lại nhiều lần
ngoài kiểm thử hồi quy (regression testing) automation testing cũng được dùng để test ứng dụng tải hiệu năng và điểm stress. Chúng làm tăng lên bao trùm vùng test; cải thiện độ chính xác, tiết kiệm thời gian và tiền bạc hơn so với manual testing

Tự động hóa những cái gì?
Phương pháp này không  tự động tất cả mọi thứ trong phần mềm; tuy nhiên, phân vùng mà người dùng có thể thực hiện giao dịch/ thao tác như form đăng nhập hoặc form đăng ký ... module test với số lượng nhiều user có thể truy cập vào phần mềm đồng thời có thể tự động
Hơn nữa tất cả thành phần của giao diện người dùng tương tác (GUI) được kết nối với database, các trường thông tin được xác nhận..có thể được kiểm tra một cách hiệu quả bằng phương pháp tự động

Tự động hóa khi nào?
kiểm tra tự động nên được áp dụng cho trường hợp cụ thể bằng cách xem xét các điều dưới đây:
- Các dự án lớn và quan trọng
- dự án đòi hỏi kiểm thử các khu vực thường xuyên
- Các yêu cầu không được thay đổi thường xuyên
- Truy cập ứng dụng tải và hiệu suất với nhiều người dùng ảo
- phần mềm ổn định với phương pháp kiểm thử thủ công
- sẵn có thời gian

Tự động hóa như thế nào?
Tự động là được chạy với sự hỗ trợ của ngôn ngữ lập trình máy tính như vb scripting và tự động trên một ứng dụng phần mềm
Chúng bao gồm một số công cụ có sẵn được ghi lại kịch bản tự động
trước khi đề cập đến các công cụ quyết định xác định quá trình đó có thể được sử dụng kiểm thử tự động:
- xác định vùng kiểm thử trong phần mềm
- Chọn lựa công cụ thích hợp cho test tự động
- viết kịch bản test
- phát triển bộ test (Test suits)
- thực thi các kịch bản
- tạo kết quả báo cáo
- xác định bất kỳ trường hợp có khả năng là lỗi hoặc vấn đề có tiềm năng

Công cụ kiểm thử phần mềm
Sau đây là các công cụ có thể sử dụng cho kiểm thử tự động :
- HP Quick Test Professional
- Selenium
- IBM Rational Functional Tester
- Silk Test
- TestComplete
- Testing anywhere
- WinRunner
- Load Runner
- Visual Studio Test Professional
- WATIR

Trong bài này nói tổng quát về automation testing trả  lời cho 5 câu hỏi chính What, Why, When, How, Where automate.Tiếp theo, bạn đọc tìm hiểu về html & element locator tại đây

Có sai sót hay thiếu phần nào bạn đọc có thể feedback cho mình nhé.
#best

Thứ Ba, 18 tháng 11, 2014

WHITE BOX TESTING



 Khái niệm: Còn được gọi là clear box testing, glass box testing, transparent box testing, or structural testing,  thường thiết kế các trường hợp kiểm thử dựa vào cấu trúc bên trong của phần mềm.
whitebox-testing
Đặc điểm: Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng cần thay đổi theo. Được ứng dụng trong các kiểm tra ở cấp độ mô đun(điển hình), tích hợp (có khả năng) và hệ thống của quá trình test phần mềm.
Các kỹ thuật:
Kiểm thử luồng, lộ trình ( Deriving Test Cases)
+ Lộ trình cơ sở (Basis path Testing)
Luồng điều khiển / Phạm vi
(Control-flow / Coverage Testing)
+ Phương thức – Method Coverage
+ Câu lệnh – Statement Coverge
+ Nhánh –  Branch Coverge
+ Điều kiện – Condition Converage
Kiểm thử luồng dữ liệu ( Data Flow Test )
Trường hợp hỏng ‘rác’ – Failure ‘Dirty’ Case Test
Flow Groaps Revisited
Basis Path Testing ( Kiểm thử lộ trình cơ sở)
Equivalence Partitioning / Boundary Value( Phân vùng tương đương và Giá trị biên )
Kiểm tra lộ trình cơ sở :
+ Là kĩ thuật kiểm thử mà phần mềm được chia thành các lộ trình
+ Đảm bảo các lộ trình độc lập qua một mô đun mã sẽ được kiểm thử đầy đủ
Một số khái niệm:
Đồ hình lộ trình : Bao gồm các hình, mũi tên (cạnh), chỉ số, mô tả khác
Độ phức tạp chu trình ( Cyclomatic Complexity ) : Được tìm ra bởi chu trình McCabe, chỉ ra độ phức tạp lôgic của một chương trình.
do-thi-test
Cách tạo kiểm thử:
Sử dụng một đoạn code hoặc thiết kế làm cơ sở để xây dựng lên đồ hình luồng.
Đưa ra các chu trình lộ trình từ đồ hình vừa có được.
Quyết định một lộ trình độc lập tuyến tính
Kiểm tra tất các chu trình đã tạo.
v Luồng điều khiển / Gom  (Control-flow / Coverage Testing)
Là cách tạo ra các bộ giá trị kiểm thử để có thể xem được 100% các trường hợp có thể xảy ra với các thành phần của một chương trình bao gồm :
+ Các phương thức ( Method )
+ Các câu lệnh (Statement )
+ Các nhánh (branch)
+ Các điều kiện
Ví dụ: Kiểm tra phương thức bằng các bộ giá trị của hàm foo sau :



Bộ giá trị được chọn là  foo(0,0,0,0,0)
v Luồng điều khiển / Phạm vi (Control-flow / Coverage Testing)
Với nhánh (branch )
IF ( a equals b AND c less than d ) THEN
statement 1
ELSE
statement 2
END IF
Chọn bộ giá trị a b c d sao cho có thể kiểm tra hết các nhánh rẽ .
Ví dụ : (a,b,c,d) = (1, 1, 2, 6) & (1,2,3,3)
v Kiểm thử luồng dữ liệu ( Data Flow Test )
Kiểm tra sự khởi tạo, biến đổi và huỷ của các các luồng  dữ liệu.
Thường  được phân tích qua đồ hình và đặt ra các bộ giá trị thử và giá trị trả về  mong muốn  dựa vào đồ hình đó.
Một số trạng thái của biến dữ liệu trong quá trình biến đối

Ví dụ: Hoá đơn thanh toán cho việc sử dụng điện -> Xét sự biến đổi luồng dữ liệu của hóa đơn

v Trường hợp hỏng ‘rác’ (Failure ‘Dirty’ Case Test)
Là trường hợp kiểm thử các trường hợp mà người lập trình cần đứng ở vị trí người dùng để nhập giá trị
Cụ thể là người dùng có thể nhập số thay cho chữ, hoặc không nhập gì, tạo ra lỗi phép toán (divided by Zero )…
Cách kiểm thử:
Tạo ra tất cả các trường hợp test mà người dùng thường mắc lỗi ( dựa vào kinh nghiệm thực tế )
Kiểm tra các lỗi toán học, số học, phạm vi biến, kiểu biến ….

BLACK BOX TESTING




kiem-thu-hop-den
Khái niệm: Black-box testing sử dụng mô tả bên ngoài của phần mềm để kiểm thử, bao gồm các đặc tả (specifications), yêu cầu (requirements) và thiết kế (design). Không có sự hiểu biết cấu trúc bên trong của phần mềm. Các dạng đầu vào có dạng hàm hoặc không , hợp lệ và không không hợp lệ và biết trước đầu ra.


Đặc điểm: Được sử dụng để kiểm thử phần mềm  tại mức : mô đun, tích hợp, hàm, hệ thống và chấp nhận.
- Lợi điểm của kiểm thử hộp đen là khả năng đơn giản hoá kiểm thử tại các mức độ được đánh giá là khó kiểm thử
test-manual
- Yếu điểm là khó đánh giá còn bộ giá trị nào chưa được kiểm thử hay không

Các kỹ thuật chính của kiểm thử hộp đen:
Decision Table testing
Pairwise testing
State transition tables
Tests of Customer Requirement
Failure Test Cases
Decision Table Testing:
Là cách xây dựng một bộ các giá trị kiểm thử đầy đủ không cần biết cấu trúc bên trong của phần mềm.
Bảng quyết định được xây dựng dựa vào
Trong đó :
Condition : input

Action : output

blackbox-testing
Pairwise testing: là cách phối hợp các đầu vào để tạo ra bộ giá trị kiểm thử.

-         Ở ví dụ này Bộ có thể chọn của X=1 | 2; Y= Q | R , Z= 5 | 6
Hạn chế: số lượng giá trị của mỗi đầu vào tăng tạo ra sự tăng nhanh trong các trường hợp thử. Có thể gặp phải lỗi trong việc kết hợp các giá trị đôi khi không xảy ra
Ưu điểm: Xét được hết các trường hợp đầu vào kể cả trường hợp ngẫu nhiên của người dùng. Dựa vào các yêu cầu của khách hàng để tạo ra các bộ giá trị kiểm thử.
State transition tables: Là bảng mô tả sự chuyển trạng thái tương ứng với giá trị đầu vào tương ứng.




Tester là người như thế nào? Phân bậc Tester

tim-hieu-cac-loai-bug-trong-testing

1.Định nghĩa Tester là gì:
- Tester là người kiểm thử phần mềm.
- Thực hiện việc kiểm thử phần mềm nhằm giảm thiểu các lỗi
của sản phẩm bằng cách tìm kiếm lỗi phần mềm cho các
Lập trình viên.
Các Quy trình liên quan bao gồm: Quy trình Kiểm thử (Test
process), Quy trình Yêu cầu dự án (Requirement process),
Quy trình Quản trị dự án (Project Management process).
Các Tester báo cáo công việc cho Quản trị dự án, Phụ trách
Kỹ thuật dự án, Phụ trách Kiểm thử dự án và Cán bộ Chất
lượng (QA).
2. TESTER viết tắt của từ gì?
T Take care of quality (Chăm lo cho chất lượng)
E Eager for finding defect (Ham tìm lỗi)
S Standardize software (Chuẩn hóa phần mềm)
T Thought of logic (Tư duy lôgíc)
E Enjoyable job (Nghề thú vị)
R Raise of carefulness (Tăng thêm sự cẩn thận)
2.1. Mô tả công việc của người làm Test
>>> Đối với Kiểm thử phần mềm dưới 2 năm kinh nghiệm (Junior Testers):
- Nghiên cứu yêu cầu của khách hàng
- Lập kế hoạch kiểm thử (test plan)
- Tạo test cases/specs/scripts (điều kiện test, kịch bản test,
hành động, dữ liệu đầu vào và kết quả mong đợi)
- Tiến hành test
- Log các lỗi tìm được và lập báo cáo (test report)
- Phân tích các yêu cầu thay đổi và cập nhật các tài liệu
kiểm thử
>>> Đối với Kiểm thử phần mềm có 2 năm kinh nghiệm trở lên (Senior Testers):
-Rà soát lại test plan, test cases do các testers tạo ra
- Phụ trách một nhóm testers
- Tính toán và phân tích các chỉ số liên quan đến test
- Nghiên cứu automation test tools và áp dụng vào test
dự án
- Đề xuất cải tiến Quy trình Kiểm thử: lưu đồ, hướng dẫn,


biểu mẫu… để thực hiện và quản lý việc test tốt hơn.

QA là gì?

QA (Quality asurance) là gì?

tim-hieu-QA-la-gi

Trong các công ty sản xuất phần mềm, quan niệm
về QA hiện nay vẫn chưa thống nhất và bộ phận
QA còn nằm lẫn với bộ phận kiểm thử (test) sản
phẩm. Thực tế, QA là công việc khác biệt nhiều so
với test phần mềm.

Trước hết QA (Quality Assurance) phần mềm bao gồm: PQA (Process Quality Assurance) - Đảm bảo chất lượng quy trình và SQA (Software Quality Assurance - Bảo đảm chất lượng phần mềm). Cụ thể như sau:

PQA (Process Quality Assurance): có 2 việc chính
- Một là xây dựng hệ thống quy trình cho doanh nghiệp (bằng các ứng dụng những quy trình quản lý sẵn có
như ISO hay CMM hoặc dựa trên đó xây dựng quy trình chuẩn cho doanh nghiệp).
- Hai là thực hiện việc giám sát, kiểm tra việc thực hiện quy trình của từng bộ phận, từng dự án, từ đó tổng hợp thông tin để đưa ra những cải tiến cho quy trình hoạt động tốt.

SQA (Software Quality Asurance) -Tại một số công ty ở Việt Nam, SQA được xem như việc kiểm lỗi khi sản phẩm đã định hình. Còn số khác lại coi SQA là việc kiểm tra đầu ra trung gian của sản phẩm, để sản phẩm đạt được sự nhất quán trong quá trình thực hiện. Nhưng, dù ở khía cạnh nào thì SQA cũng là kiểm
tra trực tiếp sản phẩm.

TestCase là gì? Viết testcase như thế nào ?

Test case mô tả một dữ liệu bao gồm:
 Đầu vào (input), 
 Hành động (action) hoặc
 Sự kiện (event) và
 Một kết quả mong đợi (expected response),


huong-dan-viet-testcase

Để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không. Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu cầu data input, các bước thực hiện và các kết quả mong đợi. Mức chi tiết có thể được định nghĩa khác nhau dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm.

Kỹ thuật viết testcase:
Một testcase được cho là hiệu quả:
   Test case hiệu quả là test case mà tìm thấy bug.
   Tìm được nhiều bug khó.
   Chỉ ra được những điểm ban đầu  mà khi thực hiện test không tìm ra vấn đề
   Tuân theo đúng các con số thống kê bug

   Theo dõi các lỗi theo các trường hợp đã được tìm thấy
Đáp ứng được các kỹ thuật sau đây:
           Equivalence class partitioning
           Control flow testing
           Data flow testing
           Transaction testing
           Domain testing
           Loop testing
           Syntax testing
           Finite state machine testing
           Load and stress testing

Ưu nhược điểm của phương pháp kiểm thử hộp đen

I. Giới thiệu kiểm thử hộp đen (Blackbox tesing)

-          Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.
-          Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

-          Đây là kỹ thuật test mà công ty mình đang áp dụng ở các dự án: CĐT, NL, Ebay, Adnet …

II. Các phương pháp kiểm thử hộp đen (Blackbox testing method)

Ø  Phân lớp tương đương – Equivalence partitioning.
Ø  Phân tích giá trị biên – Boundary value analysis.
Ø  Kiểm thử mọi cặp – All-pairs testing.
Ø  Kiểm thử fuzz – Fuzz testing.
Ø  Kiểm thử dựa trên mô hình – Model-based testing.
Ø  Ma trận dấu vết – Traceability matrix.
Ø  Kiểm thử thăm dò – Exploratory testing.
Ø  Kiểm thử dựa trên đặc tả – Specification-base testing.
Ø  Đồ thị nguyên nhân – kết quả - Cause & Effect Graphing
Ø  Đoán lỗi – Error Guessing
Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

III. Ưu nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.
            Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

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