Quản lý bugs của jira

I. Quy trình quản lý bug
I.1 Vòng đời bugs
I.2 Trạng thái bugs

1. NEW
bug vừa được post lên hệ thống. bugzilla request email đến thành viên được
phân việc fix bug. Từ trạng thái NEW có thể chuyển sang ASSIGN || RESOLVED
NEW ---> ASSIGNED || RESOLVED

1.1/ ASSIGNED: bugs này được giao cho Developer fix, lúc này bug chưa được
fix (ở trạng thái này bugs có thể được chuyển sang NEW (chuyển cho người khác fix)
hoặc chuyển sang RESOLVED (đã fix xong)

assigned ---> resolved (fixed)
---> new (chuyển cho người khác fix).

1.2/ RESOLVED: bugs được sửa xong và chuyển sang kết quả bug có thể là 1 trong các trạng thái sau:
FIXED
INVALID
WONTFIX
DUPLICATE
LATER
REMIND
Từ các trạng thái bug trên có thể chuyển sang trạng thái: Reopen
 Verified
 Closed
 Unconfirmed (trạng thái này ít dùng)

Ghi chú:
Giải thích ý nghĩa của các trạng thái bugs (kết quả trạng thái bugs của RESOLVED) như sau:
FIXED: bugs đã fix xong
INVALID: Vấn đề này không phải là bug
WONTFIX: Vì lý do nào đó, bug này không fix hoặc không có time hoặc bug không nghiêm trọng, để cải tiến sau..
DUPLICATE: bug được post lên bị trùng với bug cũ. ở trạng thái này yêu cầu tester cập nhật lại ID của bug
LATER: Vì lý do nào đó chưa thể fix ngay lúc nảy.
REMIND: Giống với LATER.


2. REOPEN
Trạng thái này do QC/ manager test chuyển trạng thái từ RESOLVED. trong trường hợp kiểm tra lại vẫn còn bug
bug giống tương tự với bug cũ. trạng thái này có thể chuyển sang assigned hoặc resolved.
REOPEN ---> ASSIGNED
      ---> RESOLVED
3. VERIFIED
Trạng thái này được test xong và xác nhận bug được fix (QC lead đóng).

4. CLOSED
Kết thúc 1 vòng đời bug ( bug được fix và tet lại hoàn tất)
Nếu xảy ra bug hoặc vẫn còn bug thì chuyển sang trạng thái REOPEN.

10 nguyên tắc cơ bản cho người mới bắt đầu học automation testing

[quote] Automation testing từ khóa này lúc nào mình cũng search search research bao là nhiêu. tìm hiểu về nó thì có rất nhiều tài liệu nhưng sẽ rất mung lung không biết bắt đầu từ đâu. Bởi vậy, không biết thì hỏi muốn giỏi thì search google nhiều =)))
Dưới đây, mình cũng tìm đọc và chia sẻ cho bạn nào muốn tìm hiểu về auto testing. Bạn nào đang tìm hiểu hoặc có kinh nghiệm chia sẻ cùng mình nha. :) [/quote]

Testing là một một nhiệm vụ khó khăn và để tự động hóa đòi hỏi người kiểm thử
có sự hiểu biết sâu sắc về quá trình và thực hành liên tục, tìm ra cho mình một tool hoặc ngôn ngữ
basic để hiểu và viết testscript bằng java hoặc python (còn nhiều ngôn ngữ khác áp dụng nếu như bạn nào rành về C# cũng OK tuốt =D)
Bạn nào mới bắt đầu về java thì có thể lên mạng search learning java basic hoặc học theo bài cơ bản nhất theo link này: http://workbench.cadenhead.org/book/java-8-24-hours/

Nhưng trước hết bạn hiểu và nắm rõ được 10 nguyên tắc cơ bản dưới đây:

Nguyên tắc 1: Đọc và học/ hiểu cơ bản về nó (automation testing)
ngay cả những người phát triển có tay nghề cũng phải rà soát
lại kiến thức của mình theo thời gian, học tập là luôn cập nhật trau dồi kiến thức thường xuyên

Tự động hóa là gì? tự đặt câu hỏi và tự tìm hiểu để trả lời thì bạn sẽ nhớ lâu hơn, hoặc có thể tham khảo của những người đi trước. tự động hóa một đánh giá đơn thuần của các bước chương trình phải thực hiện, bạn tự viết một hướng dẫn chi tiết.

Nguyên tắc 2: Kế hoạch chuẩn bị để đáp ứng các dự án tự động

Thực hành là cách duy nhất để có được kiến thức hợp lệ.
Lấy bất kỳ công cụ kiểm tra mã nguồn mở có sẵn, cài đặt  và học cách sử dụng nó trong thời gian rảnh của bạn. Các sandbox (hộp kiểm thử hiện đại) có thể làm được bất cứ điều gì, thậm chí MS Office của bạn hoặc công cụ Calculator ( thực hiện demo trươc1). Chỉ cần có được công cụ và bắt đầu, Khi bạn đạt được sự hiểu biết và kinh nghiệm có thể sẵn sàng đối mặt với các dự án thực tế khi cần thiết.

Nguyên tắc 3: Các khái niệm/ định nghĩa cơ bản là giống nhau. Hãy khám phá chúng!
Ngoài đặc thù là khác nhau nhưng tất cả các ngôn ngữ cơ bản hoạt động
cùng một khái niệm như các biến, tham số, các chức năng, các
loại dữ liệu khác nhau, vòng lặp có điều kiện hoặc báo cáo, mảng, chỉ khác nhau ở công nghệ của mỗi ngôn ngữ. Sau khi có những hiểu và ghi nhớ, bạn sẽ có thể áp dụng kiến
 thức này để coding bất kỳ ngôn ngữ nào bạn học. (java ? python..)

Nguyên tắc 4: Không dừng lại khi chương trình đầu tiên bị FAIL
Khi mà thực hành viết 1 chương trình testscript nào đó bị lỗi bạn đừng vội nản lòng.
Có một câu ngạn ngữ Nga tuyệt vời: "the first pancake is a mess. It means first try on anything will most likely fail, but all the next ones will be better, as you will gain experience in the process.
 No matter how good you are on theory, first practice likely will be disappointing. So just go on."

Nguyên tắc 5: Nhìn vào code như một thủ tục chứ không phải là một magic :3

Bất cứ khi nào mới bắt đầu nhìn vào code, nó có vẻ gần như khá phức tạp.
Tuy nhiên, sau khi thực hiện một số coding, bạn sẽ có thể nhận ra mô hình và quy trình cùng một lúc làm cho việc đọc mã dễ dàng hơn nhiều. Bạn sẽ thấy nó chỉ đơn thuần là một hướng dẫn cho các chương trình.

Nguyên tắc 6: Khám phá tool
Mình nói rồi đấy. Bất cứ một người làm kiểm thử nào nếu không muốn mình đơn thuần là 1 manual testing hay chỉ test function dựa trên spec document thì hãy tìm cho mình một tool thích hợp nhất để tìm hiểu. Cách tốt nhất để làm quen với một công cụ thì hãy khám phá các tính năng của nó từ đơn giản nhất cho đến phức tạp. càng hiểu sâu bạn càng thích thú với nó. tool rất nhiều bạn có thể search tool for testing là ra cả đống =D

Nguyên tắc 7: Search for help in help section
Trong quá trình khám phá tìm hiểu bạn gặp một số lỗi thì hãy đọc phần Help của công cụ. Nó là một nguồn tuyệt vời và hướng dẫn trên mọi khía cạnh của việc sử dụng của công cụ. Khám phá kỹ để làm chủ công cụ hoàn hảo.

Nguyên tắc 8: Thực hành nhiều, nhiều hơn có thể

Hãy thử nghiệm nhiều lần như một quá trình xác nhận. Nó cho phép bạn để kết luận nếu đoạn code này là chức năng hay không. Kiểm tra nhiều lần và xem xét nó có cho ra kết quả mong muốn hay không? lặp lại nhiều lần như thế để xác nhận

Nguyên tắc 9: Cải tiến cách/ phương pháp làm việc của bạn

Tất cả những việc làm tốt có thể được thực hiện tốt hơn. Rà soát, phấn đấu để cải thiện dự án của bạn là một cách  để cải thiện kỹ năng của bạn và hướng bạn lên một tầm cao mới.


Nguyên tắc 10: Không phải lúc nào cũng cần đến tự động

Automated test là phương pháp hữu dụng và ấn tượng, thường được
sử dụng để giúp tiến hành test một cách hiệu quả. Tuy nhiên, automated test lại không phù hợp với tất cả các dự án. Nguyên nhân là do thiếu thời gian và thiếu kĩ thuật. Mất nhiều thời gian để tạo Automated test. Thời gian này phụ thuộc vào các tester. Để tạo automated test thì mất thời gian gấp 3-10 lần  so với việc chạy test bằng tay. Vì vậy, automated test sẽ chỉ được  chạy tương đương với lượng thời gian gấp 3-10 lần. bạn tìm hiểu và nắm rõ 2 trường hợp sau:
1. Automated test sẽ phù hợp cho những mục đích:
- Thực hiện test hồi quy cho 1 hệ thống ổn định chạy trên 1 cơ sở thường xuyên.
- Việc tạo dữ liệu xử lý nhanh trong các hệ thống test có cơ sở dữ liệu căn cứ trên 1 cơ sở thường xuyên.
2. Automated test KHÔNG phù hợp cho những mục đích sau:
- Thực hiện test chức năng mới – Việc này nên được làm bằng tay trước khi tạo automated test.
- Những hệ thống test hồi quy sẽ mang lại sự thay đổi giao diện người sử dụng quan trọng. Sự thay đổi lớn đối với giao diện người sử dụng cần nhiều sự bảo dưỡng duy trì cho automated test.
Khi tiến hành tự động hóa test, bạn nên chỉ tự động hóa các test mà nhóm của bạn có thể duy trì được dễ dàng. Nếu có vài test khó có thể duy trì thì phải cân nhắc để giảm các test đó.
Nói tóm lại, bạn hãy nhớ rằng automated test sẽ không bao giờ tìm ra được nhiều bug như 1 người tester tìm ra theo cùng các bước. Đó là bởi vì người tester có thể bắt được nhiều thứ bằng con mắt của mình.

Những quy tắc là không bắt buộc, nhưng chúng tương đối đơn giản hóa và rõ ràng. Sau đó sẽ giúp bạn cải thiện kỹ năng và trở thành một người kiểm thử tốt hơn.
Nếu bạn có nhận xét hay ý kiến thêm về vấn đề nào trong 10  nguyên tắc trên
hãy feedback cho mình qua mail thuyph910@gmail.com Thanks all.

Checklist for usability testing

Có rất nhiều khía cạnh liên quan đến quy trình kiểm thử, bài viết này sẽ tập trung vào “danh sách kiểm tra (checklist)” khía cạnh đó là một phần cơ bản trong các quy trình kiểm thử phần mềm.

Tại sao phải sử dụng checklist trong kiểm thử

·                     Theo quan điểm của tôi, nó có một vài lợi ích chính mà bạn đạt được khi sử dụng checklist

·                     Checklist có thể bảo đảm tất cả các yêu cầu của client sẽ được đảm bảo trong quy trình kiểm thử

·                     Checklists cón thể đảm bảo rằng phần mềm được kiểm tra với mức bao phủ cần thiết

·                     Checklists có thể giảm bớt bỏ quên lỗi cho tester

·                     Checklist có thể giúp công việc kiểm thử đảm bảo mức đúng đắn/ chính xác cho phần mềm

·                     Checklist có thể giúp tester bao quát được  vùng kiểm thử

·                     Checklist có thể giúp tester nhìn rõ thấy quy trình kiểm thử

·                     Checklist có thể tăng cường sự phối hợp giữa các nhóm tham gia khác liên quan tới nhau trong quy trình  kiểm thử phần mềm

Dưới đây, tôi chọn một vài tiêu chí cho các trường hợp test, mỗi tiêu chí đi kèm với với các ví dụ cụ thể giúp bạn thực hiện công việc kiểm thử tính khả dụng một cách tốt hơn:


User experience  

·                     Kiểm tra định dạng các thông tin hiển thị thích hợp với mức tương phản với bakground

·                     Kiểm tra / xác nhận rằng mọi thao tác người dùng có thể sử dụng các chức năng chính ngoài các hệ thống không cần thiết

·                     Kiểm tra/ xác nhận người dùng nhận được các thông báo lỗi cho các thông tin không hợp lệ VD: thông tin đăng nhập

·                     Kiểm tra người dùng có thể đăng nhập vào site của bạn, khi đó hệ thống phải chỉ dẫn tốt cho người dùng sau khi đăng nhập thành công

·                     Kiểm tra thao tác người dùng có thể thi hành hệ thống với phần cứng

·                     Kiểm tra tất cả các buttons, checkboxes, radio buttons.. khi click

·                     Kiểm tra/ xác nhận người dùng nhận được thông tin pop-up trước khi ứng dụng được thay đổi 

·                     Kiểm tra người dùng có thể thoát ra từ bất kỳ thao tác nào khỏi hộp thoại phức tạp (complex dialog)

·                     Kiểm tra/ xác nhận người dùng có thể sử dụng thông tin liên hệ có sẵn

·                     Kiểm tra/ xác nhận rằng người dùng có thể so sánh các sản phẩm khác (Nếu có liên quan)

·                     Kiểm tra/ Xác nhận rằng mọi thao tác/ hoạt động được kết thúc với thời gian hợp lý

·                     Kiểm tra/ Xác nhận rằng người dùng có thể truy cập vào chỉ dẫn “help” một cách dễ dàng

·                     Kiểm tra/ xác nhận rằng website của bạn tương thích với nhiều kích thước độ phân giải màn hình khác nhau

·                     Kiểm tra/ xác nhận rằng người sử dụng có thể truy cập nhanh vào thông tin website

·                     Kiểm tra/ xác nhận rằng người dùng nhận được một đăng ký chờ duyệt

Information and visibility

·                     Kiểm tra/ xác nhận các trường không cho phép chọn phải ở dạng disable

·                     Kiểm tra/ xác nhận cú pháp/ kiểu ngôn ngữ viết của bạn được viết đơn giản cho người dùng cuối

·                     Kiểm tra/ xác nhận rằng các thông tin không cần thiết thì không nằm trong phần nội dung của quảng cáo

·                     Kiểm tra/ xác nhận rằng logo của công ty bạn được hiển thị trên tất cả các vùng có liên quan

·                     Kiểm tra/ xác nhận rằng người dùng nhận đươc thông báo lỗi khi thao tác có lỗi xảy ra không hợp lệ

·                     Xác nhận rằng bạn có không gian hiển thị giữa các thông báo, các trường, các label … một cách hợp lý

·                     Xác nhận rằng tất cả các hình ảnh/ video phải có mô tả  thích hợp.

·                     Chắc chắn rằng nội dung của bạn được viết bằng chữ in thường/ in hoa

·                     Xác nhận rằng nội dung của bạn không có lỗi chính tả

·                     Xác nhận rằng những thông tin quan trọng phải được định dạng nổi bật

·                     Chắc chắn rằng nội dung của bạn luôn được cập nhật

·                     Xác nhận tất cả các pages/ grids phải có title

Navigation

·                     Kiểm tra/ Xác nhận rằng bạn không có bất kỳ “Drop – down” list nào chứa quá nhiều record

·                     Xác nhận thanh navigation “Tabs” được trỏ đến vị trí thích hợp khi có lệnh

·                     Kiểm tra/ Xác nhận website bạn phải có một “site map” có thể giúp người dùng end user

·                     Kiểm tra/ xác nhận người dùng di chuyển thuận tiện các phím tabs/ pages với các option trả về tab/page hiện tại có những gì

·                     Kiểm tra/ xác nhận thanh cuộn “scrolling” phải sẵn có trong vùng thích hợp

·                     Kiểm tra/ xác nhận người dùng không thể chèn thông tin đầu vào trên các danh sách “drop-down” list

·                     Kiểm tra tất cả các link liên kết được cấu hình bởi các chữ cái (?)

·                     Kiểm tra/ xác nhận tất cả các trường textbox, các button liên quan đến việc di chuyển giữa các tabs/ pages với nhau

Site links

·                     Chắc chắn các chức năng chính phải được cấu hình như các button chứ không phải dạng link liên kết.

·                     Kiểm tra/ xác nhận tất cả các link được cấu hình với các phạm vi mong muốn

·                     Kiểm tra các link liên kết được đánh dấu bởi màu sắc thích hợp

·                     Chắc chắn rằng người dùng nhận được thông báo thích hợp đối với các trường hợp bị delay giữa các link được chọn và các tham chiếu được gửi tới

·                     Kiểm tra/ xác nhận rằng không có có liên kết link nào bị hỏng

Search fields

·                     Kiểm tra/ xác nhận sẽ có lựa chọn cho keysearch đề nghị nếu người dùng search mà trả về kết quả rỗng

·                     Kiểm tra/ xác nhận màn hình hiển thị thông báo cho bất kỳ trường hợp nào bị delay trong quá trình tìm kiếm

·                     Xác nhận rằng phải có màn hình hiển thị thông báo thích hợp nếu kết quả search trả về null

·                     Kết quả tìm kiếm được hiển thị tương ứng với thuộc tính kết quả tìm kiếm

·                     Kiểm tra/ xác nhận bộ máy tìm kiếm chứa các đối tượng khai thác kết quả khác nhau (ví dụ bằng kết quả tìm kiếm hoặc gần giống với kết quả tìm kiếm, kết quả tìm kiếm tương tự,….)

·                     Xác nhận rằng người dùng có thể lọc kết quả tìm kiếm với một vài tiêu chí tìm kiếm khác  nhau

·                     Kiểm tra/ xác nhận rằng phải có màn hình hiển thị thông báo thích hợp nếu người dùng chèn vào các ký tự đặc biệt

·                     Kiểm tra rằng việc hiển thị kết quả tìm kiếm không được nhân đôi kết quả tìm kiếm giống nhau

·                     Xác định trang hiển thị kết quả tìm kiểm phải rõ ràng

·                     Xác nhận thanh công cụ tìm kiếm phải được đặt ở vị trí thích hợp

·                     Xác nhận/ kiểm tra kết quả tìm kiếm phải được hiển thị theo thứ tự hợp lý

·                     Xác nhận/ kiểm tra người dùng có thể bắt đầu tìm kiếm trên bàn phím keyboard

·                     Mặc định, website của bạn phải có một thanh công cụ tìm kiếm, kích thước, font, size, màu sắc thích hợp

·                     Kiểm tra/ xác nhận kết quả tìm kiếm trả về phải chính xác

Tham khảo tại https://userium.com/

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.