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

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.

Đặ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.

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

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ử

- 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

Equivalence partitioning

Boundary value analysis

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

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

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ì?

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),

Để 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ù”.