Các mức kiểm thử phần mềm Phần 2

5. Acceptance testing - Kiểm thử chấp nhận 

Kiểm thử chấp nhận có thể có là một trong hai điều sau đây:

1. Một smoke test được sử dụng như là một acceptance test trước khi giới thiệu bản build mới để thực hiện việc kiểm thử chính, có nghĩa là trước khi thực hiện kiểm thử tích hợp hoặc hồi qui.

2. Acceptance testing được thực thi bởi khách hàng, thường được thực hiện trong môi trường thí nghiệm trên phần cứng của họ, được biết như là kiểm thử chấp nhận người dùng (viết tắt là UAT). Acceptance testing có thể được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa 2 pha của quá trình phát triển phần mềm.[cần dẫn nguồn]

6. Alpha testing – Kiểm thử Alpha

Alpha testing là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS office, window, chương trình diệt virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta. van Veenendaal, Erik. "Bảng chú giải tiêu chuẩn của thuật ngữ dùng trong Kiểm thử phần mềm - Standard glossary of terms used in Software Testing".

7. Beta testing – Kiểm thử Beta

Beta testing được thực hiện sau alpha testing. Các phiên bản của phần mềm - được biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug. Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất.

T3H Hà Nội chúc các bạn học tốt môn kiểm thử phần mềm.

Read More

Các mức kiểm thử phần mềm Phần 1

1. Unit testing - Kiểm thử thành phần/đơn vị

Unit testing đề cập đến các kiểm thử để chứng thực (xác minh - verify) chức năng của một phần riêng biệt của code, thường ở mức hàm (function level). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử đơn vị thường được sử dụng ở mức lớp (class) và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor.

Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (loại test white-box), để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình không thể bảo đảm chức năng của một bộ phận của phần mềm mà là sử dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việc độc lập với nhau.

Unit testing (kiểm thử đơn vị) cũng được gọi là component testing (kiểm thử thành phần).

2. Integration testing - Kiểm thử tích hợp (đơn vị)

Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đây được xem là một cách làm tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định.

Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của thiết kế kiến trúc đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.

3. System testing - Kiểm thử hệ thống 

System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu.

Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các yêu cầu hệ thống.

4. Regression testing - Kiểm thử hồi qui

Regression testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo mong đợi. Điển hình, hồi qui xảy ra như là một kết quả không mong muốn của việc thay đổi chương trình, khi phần code của phần mềm mới được phát triển xung độ với code cũ đang có. Phương pháp thông thường của kiểm tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây và kiểm tra xem có lỗi đã được fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã fixed rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong quá trình phát hành và rủi ro của các tính năng được thêm vào. Chúng có thể được hoàn thành – vì việc thay đổi đã thêm vào sau bản phát hành hoặc coi nó là mạo hiểm, rất hời hợt, bao gồm các kiểm thử trường hợp đúng (positive) trên từng chức năng – nếu các thay đổi được thêm vào trước khi phát hành hoặc coi nó ít rủi ro.

T3H chúc các bạn học tốt Testing

Read More

Tester cơ bản

Vấn đề tự học tester, theo mình thì tốt cho mọi người, kể cả người có điều kiện tham gia các lớp học kiểm thử phần mềm. Như đã nói ở các bài viết trước khi tham gia bất kỳ khóa học Tester nào thì mọi người cũng nên tự tìm hiểu trước về kiểm thử phần mềm để tự mình trang bị một số kiến thức cơ bản, điều này sẽ giúp ích chúng ta trong lúc tham gia học, vì nếu không hiểu gì về kiểm thử phần mềm và một số khái niệm cơ bản, thì rất khó tiếp thu kiến thức do giáo viên truyền đạt. Nếu giáo viên kỹ, họ sẽ tìm cách, tìm ví dụ để giải thích cho các bạn hiểu mọi thứ, nhưng ít khi nào gặp được giáo viên như vậy, vì đa số họ sợ không kịp giờ (cháy giáo án), và thực tế nếu người có tâm huyết thì họ mới tốn nhiều công sức để giải thích cho mọi người trong lớp hiểu, còn nếu đi làm vì lương thì họ sẽ không cần 100% học viên hiểu mà chỉ cần ~60% hiểu là được rồi :D (cá nhân mình nghĩ vậy chứ không có đề tài nghiên cứu khoa học nào cho phần này, mình nghĩ nhiều người sẽ đồng ý với mình - kết quả này cũng dựa vào kiến thức của một số bạn đã từng tham gia một khóa tester basic mà mình biết, vì mình đã giúp các bạn đó update cv, ôn lại kiến thức và cách trả lời phỏng vấn xin việc,...).

Nếu so sánh một người tự học tester với một người đi học một khóa học tester ở trung tâm nào đó, thì chắc chắn bạn đi học 1 khóa tester vẫn nắm được một số kiến thức nhất định nhiều hơn bạn tự học tester. Nhưng nếu bạn nào đã tự học rồi sau đó theo học một khóa tester tương đương thì chắc chắn sẽ thu được nhiều kiến thức hơn nữa.

Sau đây là một số gợi ý để các bạn có thể tự học tester:

1. Kiểm thử phần mềm là gì?

2. Qui trình kiểm thử phần mềm trong Vòng đời phát triển phần mềm

3. Các hoạt động kiểm thử phần mềm trong qui trình kiểm thử phần mềm

4. Loại test và mức test

5. Test plan và cách viết test plan

6. Test cases và cách viết test cases

7. Nội dung của bug report (cách post bug)

8. Automation Test và cách áp dụng test tool vào một tổ chức (công ty)

Nay testingvn đã mở các khoá học nhằm giúp các bạn tìm hiểu về testing trong thời gian ngắn nhất ở cả cấp độ cơ bản - Fresher - và nâng cao - ISTQB.

Read More