Hệ thống T3H Hà Nội

Điểm đến của học viên Công nghệ thông tin.

Học Thiết kế đồ họa

Ai cũng có thể học được.

Lập trình PHP

Ưu đãi sinh viên với mức học phí thấp nhất.

Học lập trình di động Android

Ngành hot nhất lập trình hiện nay.

Cơ hội nhận học bổng cho các học viên xuất sắc tại T3H

Sau khi hoàn thành xong khóa học Học viên sẽ được cấp chứng chỉ của ĐHKHTN ĐH Quốc Gia TP HCM.

21/4/15

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.

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

16/4/15

T3H Hà Nội chia sẻ kiến thức Testing - Ca kiểm thử

Cốt lõi của kiểm thử phần mềm dựa trên phân tích động là việc xác định
tập các ca kiểm thử sao cho chúng có khả năng phát hiện nhiều nhất các lỗi
(có thể có) của hệ thống cần kiểm thử. Vậy cái gì cần đưa vào các ca kiểm
thử? Rõ ràng thông tin đầu tiên là đầu vào. Đầu vào có hai kiểu: tiền điều
kiện (pre-condition) - tức là điều kiện cần thỏa mãn trước khi tiến hành ca
kiểm thử - và dữ liệu đầu vào thực sự được xác định bởi phương pháp kiểm
thử. Thông tin tiếp theo cần đưa vào là đầu ra mong đợi. Cũng có hai loại
đầu ra: hậu điều kiện (post-condition) và dữ liệu đầu ra thực sự. Phần đầu
ra của ca kiểm thử thường hay bị bỏ quên vì nó là phần khó xác định. Giả sử
ta cần kiểm thử phần mềm tìm đường đi tối ưu cho máy bay khi cho trước
các ràng buộc về hành lang bay và dữ liệu về thời tiết trong ngày của chuyến
bay. Đường đi tối ưu của máy bay thực sự là gì? Có nhiều câu trả lời cho
câu hỏi này. Câu trả lời lý thuyết là giả thiết về sự tồn tại của một cây đũa
thần (oracle) biết được tất cả các câu trả lời. Câu trả lời thực tế, được gọi
là kiểm thử tham chiếu, là hệ thống được kiểm thử dưới sự giám sát của các
chuyên gia về lĩnh vực ứng dụng của phần mềm, những người có thể phán
xét xem liệu các dữ liệu đầu ra đối với việc tiến hành trên các dữ liệu đầu
vào của ca kiểm thử có chấp nhận được hay không.
Hoạt động kiểm thử dẫn đến việc thiết lập các tiền điều kiện cần thiết,
việc cung cấp các ca kiểm thử, quan sát dữ liệu đầu ra và so sánh chúng với
các đầu ra mong đợi để xác định phát hiện các lỗi/khiếm khuyết (có thể có)
của sản phẩm phần mềm.

Chỉ số của ca kiểm thử
Mục đích
Tiền điều kiện
Đầu vào
Đầu ra mong đợi
Hậu điều kiện
Lịch sử thực hiện ca kiểm thử
Ngày.....Kết quả thực tế....Phiên bản....Kiểm thử viên 

Hình 1.2 mô tả các thông tin cơ bản trong một ca kiểm thử được phát
triển đầy đủ, chủ yếu là để trợ giúp việc quản lý. Các ca kiểm thử cần phải
định danh bằng tên/chỉ số và lý do tồn tại (chẳng hạn đặc tả nhu cầu tương
ứng là một lý do). Cũng nên bổ sung thêm lịch sử tiến hành của một ca kiểm
thử bao gồm cả việc chúng được thực hiện bởi ai và khi nào, kết quả của
mỗi lần thực hiện ra sao, qua hay thất bại và được thực hiện trên phiên bản
nào của phần mềm. Với các ca kiểm thử cho các hoạt động kiểm thử giao
diện người dùng, ngoài thông tin về đầu vào, chúng ta cần bổ sung thêm các
thông tin về trình tự nhập các đầu vào cho giao diện. Tóm lại, ta cần nhận
thức rằng ca kiểm thử ít nhất cũng quan trọng như mã nguồn. Các ca kiểm
thử cần được phát triển, kiểm tra, sử dụng, quản lý và lưu trữ một cách khoa
học.

T3H Chúc các bạn học tốt môn kiểm thử phần mềm Testing

15/4/15

FPT Software tuyển dụng

CT FPT Software tuyển dụng:








Vị trí tuyển:
Nhà phát triển
Số lượng tuyển: 5
5
Nơi làm việc
Hà Nội
Mã công việc:
Người thử
Ngày hết hạn:
Hà Nội

 Mô tả công việc:
- Quản lý đội ngũ test of the dự án phần mềm.
- Thực hiện kiểm tra sản phầm the làm lập trình viên triển khai ERP on the nền tảng JD Edwards cho khách hàng Nhật Bản.
- Đảm bảo chất lượng sản phẩm bàn giao cho khách hàng.

Quyền lợi :
- Cơ hội làm việc thăng tiến and in one môi trường chuyên nghiệp, hiện đại, năng động, đa văn hoá
- Mức lương cạnh tranh, tương Xứng with the position and đóng góp of you
- Chế độ chăm sóc sức khỏe đặc biệt dành cho nhân viên.
- Va many quyền lợi hấp dẫn khác ...
Yêu cầu:
- Ít nhất 3 năm kinh nghiệm kiểm thử phần mềm
- Ít nhất 1 năm kinh nghiệm kiểm tra chì cho dự án the phần mềm
- Có Khả năng giao tiếp bằng tiếng Nhật be a lợi thế
- Giao tiếp tốt, kỹ năng lãnh has đạo nhóm, xử lý vấn đề ...



Khẩn cấp! 20  Java Developers
Vị trí tuyển:
Nhà phát triển
Số lượng tuyển:
20/5/2015
Nơi làm việc
Hà Nội
Mã công việc:
DEV
Ngày hết hạn:
14/05/2015

Những gì chúng tôi mong đợi bạn để thực hiện?
- Tham dự các chương trình đào tạo 1-3 tháng
- Hãy tham gia vào các dự án phát triển phần mềm lớn nhất của FPT Software cho các khách hàng lớn sau khi đào tạo
Nhà phát triển
- Làm việc và phát triển trong môi trường chuyên nghiệp với các công nghệ mới nhất và các khuôn khổ như Java Struts 2, Spring
- Bạn sẽ làm việc với Mỹ / Nhật Bản khách hàng

Những gì chúng tôi đang tìm kiếm ở ứng viên đủ tiêu chuẩn?
- Kỹ năng kỹ thuật: J2E, Java core, JSP, OOP, thuật toán, cấu trúc dữ liệu, SQL cơ bản
- Có khả năng học hỏi công nghệ mới một cách nhanh chóng
- Nhận thức và đánh giá cao của các quá trình liên quan đến chất lượng tốt.
- Kỹ năng mềm tốt: nhóm hàng đầu thảo luận, làm việc nhóm, giải quyết vấn đề và đào tạo.
- Great tinh thần tại nơi làm việc và nghiên cứu, năng động, tận tâm, cam kết
- Tiếng Anh / tiếng Nhật là Advantage 

Tại sao bạn sẽ thích làm việc với chúng tôi?
Ứng viên thành công sẽ là một phần của một thân thiện, năng động đũa cam đội tài năng với những lợi ích khác nhau và
Mời hấp dẫn:
- Thu nhập cạnh tranh trong thời gian đào tạo phụ thuộc vào kỹ năng và tiến bộ. Được đào tạo về công nghệ mới nhất
- Cơ hội để trở thành thành viên chủ chốt của dự án quan trọng và được đào tạo lãnh đạo để chuẩn bị cho việc quản lý vị trí
- "Chăm sóc FPT" bảo hiểm y tế được cung cấp bởi AON và là độc quyền cho nhân viên FPT.
- Nghỉ hè hàng năm: theo chính sách của công ty và bắt đầu từ tháng mỗi năm.
- Công ty cung cấp xe buýt đưa đón đường giao thông thuận lợi cho tất cả nhân viên.
- Phụ cấp khác: phụ cấp đi lại, phụ cấp ăn trưa, làm việc trên trang web trợ cấp, vv
- F-Town Campus cung cấp nhiều tiện ích cho nhân viên FPT như sân bóng đá, bóng rổ và bóng chuyền, trung tâm tập thể dục,
nhà hàng, quán cà phê, vv

Các thuật ngữ và định nghĩa cơ bản về kiểm thử Phần 2

Kiểm thử: Rõ ràng việc kiểm thử liên quan đến các khái niệm trên: lỗi,
sai, thất bại và sự cố. Có hai mục đích chính của một phép thử: tìm thất bại
hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn.
Vai trò của kiểm thử phần mềm: Kiểm thử phần mềm đóng vai trò
quan trọng trong việc đánh giá và thu được chất lượng cao của sản phẩm
phần mềm trong quá trình phát triển. Thông qua chu trình “ kiểm thử - tìm
lỗi - sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ được cải
tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi
cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào. Vì
thế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểm
chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm. Quy
trình này gồm hai công việc chính là phân tích tĩnh và phân tích động.
• Phân tích tĩnh: Việc phân tích tĩnh được tiến hành dựa trên việc khảo
sát các tài liệu được xây dựng trong quá trình phát triển sản phẩm như
tài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, hồ sơ thiết
kế và mã nguồn phần mềm. Các phương pháp phân tích tĩnh truyền
thống bao gồm việc khảo sát đặc tả và mã nguồn cùng các tài liệu thiết
kế. Các kỹ thuật khảo sát này sẽ được giới thiệu trong chương 4. Người
ta cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm chứng
mô hình (model checking) và chứng minh định lý (theorem proving)
để chứng minh tính đúng đắn của thiết kế và mã nguồn. Các kỹ thuật
này tương đối phức tạp và nằm ngoài khuôn khổ của cuốn giáo trình
này. Công việc này không động đến việc thực thi chương trình mà chỉ
duyệt, lý giải về tất cả các hành vi có thể của chương trình khi được
thực thi. Tối ưu hóa các chương trình dịch là các ví dụ về phân tích
tĩnh.
• Phân tích động: Phân tích động liên quan đến việc thực thi chương
trình để phát hiện những thất bại có thể có của chương trình, hoặc
quan sát các tính chất nào đó về hành vi và hiệu quả (performance).
Vì gần như không thể thực thi chương trình trên tất cả các dữ liệu đầu
vào có thể, ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thực
thi, gọi là các “ca kiểm thử”. Chọn như thế nào để được các bộ dữ liệu
đầu vào hiệu quả (tức là các bộ dữ liệu có xác suất phát hiện thất bại
(nếu có) cao hơn là công việc cần suy nghĩ và là nội dung chính của
các giáo trình này.
Bằng việc phân tích tĩnh và động, người kiểm thử muốn phát hiện nhiều
lỗi nhất có thể được để chúng có thể được sửa ở giai đoạn sớm nhất trong
quá trình phát triển phần mềm. Phân tích tĩnh và động là hai kỹ thuật bổ
sung cho nhau và cần được làm lặp đi lặp lại nhiều trong quá trình kiểm thử.
Ca kiểm thử: Mỗi ca kiểm thử có một tên và được liên kết với một hành
vi của chương trình. Ca kiểm thử gồm một tập các dữ liệu đầu vào và một
xâu các giá trị đầu ra mong đợi đối với phần mềm.

Hình 1.1 mô tả vòng đời của việc kiểm thử ứng với mô hình thác nước.
Lưu ý rằng trong giai đoạn phát triển phần mềm, lỗi có thể được đưa vào
tại các gia đoạn đặc tả yêu cầu, thiết kế và lập trình. Các lỗi này có thể tạo
ra những sai lan truyền sang các phần còn lại của quá trình phát triển. Một
nhà kiểm thử lỗi lạc đã tóm tắt vòng đời này như sau: Ba giai đoạn đầu là
“đưa lỗi vào”, giai đoạn kiểm thử là để tìm lỗi, và ba giai đoạn cuối là “khữ
lỗi đi” [Pos90]. Bước sửa sai là cơ hội mới cho việc đưa vào lỗi (và các sai
mới). Vì vậy, việc sửa sai này có thể làm cho phần mềm từ đúng trở thành
sai. Trong trường hợp này, việc sửa sai là không đầy đủ. Kiểm thử hồi quy
(sẽ được giới thiệu trong chương 11) là giải pháp tốt để giải quyết vấn đề
này.

Các thuật ngữ trên đây cho thấy các ca kiểm thử chiếm vị trí trung tâm
trong việc kiểm thử dựa trên phân tích động. Quá trình kiểm thử dựa trên
phân tích động được chia thành các buớc sau: lập kế hoạch kiểm thử, phát
triển ca kiểm thử, chạy các ca kiểm thử và đánh giá kết quả kiểm thử. Tiêu
điểm của cuốn giáo trình này là việc xác định tập hữu ích các ca kiểm thử,
tức là các ca kiểm thứ giúp ta cải tiến tốt hơn chất lượng của sản phẩm.

Các thuật ngữ và định nghĩa cơ bản về kiểm thử

Kỹ nghệ kiểm thử đã phát triển và tiến hoá hàng mấy chục năm nên các
thuật ngữ trong các tài liệu khác nhau thường không thống nhất và thiếu
tương thích. Các thuật ngữ được trình bày trong cuốn sách này dựa vào các
thuật ngữ chuẩn được phát triển bởi IEEE (Viện Kỹ nghệ điện và điện tử)
với việc chọn lọc cẩn thận các thuật ngữ tiếng Việt tương ứng.
Lỗi (Error): Lỗi là những vấn đề mà con người mắc phải trong quá trình
phát triển các sản phẩm phần mềm. Trong thực tế, con người luôn có thể
phạm lỗi. Khi lập trình viên phạm lỗi trong lập trình, ta gọi các lỗi đó là
bug (con bọ). Lỗi có thể phát tán. Chẳng hạn, một lỗi về xác định yêu cầu
có thể dẫn đến sai lầm về thiết kế và càng sai khi lập trình theo thiết kế này.
Lỗi là nguyên nhân dẫn đến sai.
Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.
Cũng có thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức, chẳng
hạn chương trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,.... Sai lầm có thể
khó bị phát hiện. Khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế,
sai kết quả từ lỗi đó là thiếu mất cái gì đó mà lẽ ra cần phải có. Sai về nhiệm
vụ xuất hiện khi vào sai thông tin, còn sai về bỏ quên xuất hiện khi không
vào đủ thông tin. Loại sai thứ hai khó phát hiện và khó sửa hơn loại sai thứ
nhất.
Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi. Có
hai điều cần lưu ý ở đây. Một là thất bại chỉ xuất hiện dưới dạng có thể
chạy được mà thông thường là mã nguồn. Hai là các thất bại chỉ liên kết
với các lỗi về nhiệm vụ. Còn các thất bại tương ứng với các lỗi về bỏ quên
thì xử lý thế nào? Những cái lỗi không bao giờ được tiến hành, hoặc không
được tiến hành trong khoảng thời gian dài cần được xử lý thế nào? Virus
Michaelangelo là một ví dụ về lỗi loại này. Nó chỉ được tiến hành vào ngày
sinh của Michaelangelo, tức ngày 6/3 mà thôi. Việc khảo sát có thể ngăn
chặn nhiều thất bại bằng cách tìm ra các lỗi thuộc cả hai loại.
Sự cố (Incident): Khi thất bại xuất hiện, nó có thể hiển thị hoặc không,
tức là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử.
Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùng
hoặc người kiểm thử về sự xuất hiện của thất bại này.
Yêu cầu của khách hàng và đặc tả của phần mềm: Phần mềm được
viết để thực hiện các nhu cầu của khách hàng. Các nhu cầu của khách hàng
được thu thập, phân tích và khảo cứu và là cơ sở để quyết định chính xác
các đặc trưng cần thiết mà sản phẩm phần mềm cần phải có. Dựa trên yêu
cầu của khách hàng và các yêu cầu bắt buộc khác, đặc tả được xây dựng để
mô tả chính xác các yêu cầu mà sản phẩm phần mềm cần đáp ứng, và có
giao diện thế nào. Tài liệu đặc tả là cơ sở để đội ngũ phát triển phần mềm
xây dựng sản phẩm phần mềm. Khi nói đến thất bại trên đây là nói đến việc
sản phẩm phần mềm không hoạt động đúng như đặc tả. Lỗi một khi được tiến hành có thể dẫn đến thất bại. Do đó, lỗi về bỏ quên được coi là tương
ứng với các lỗi khi xây dựng đặc tả.
Kiểm chứng và thẩm định: Kiểm chứng (verification) và thẩm định
(validation) hay được dùng lẫn lộn, nhưng thực ra chúng có ý nghĩa khác
nhau. Kiểm chứng là quá trình để đảm bảo rằng một sản phẩm phần mềm
thỏa mãn đặc tả của nó. Còn thẩm định là quá trình để đảm bảo rằng
sản phẩm đáp ứng được yêu cầu của người dùng (khách hàng). Trong thực
tế, chúng ta cần thực hiện kiểm chứng trước khi thực hiện việc thẩm định
sản phẩm phần mềm. Vì vậy, chúng ta có thuật ngữ V&V (Verification &
Validation). Lý do của việc này là chúng ta cần đảm bảo sản phẩm đúng với
đặc tả trước. Nếu thực hiện việc thẩm định trước, một khi phát hiện ra lỗi,
chúng ta không thể xác định được lỗi này do đặc tả sai hay do lập trình sai
so với đặc tả.
Chất lượng và độ tin cậy của phần mềm: Theo từ điển, chất lượng
của một sản phẩm được thể hiện bằng các đặc trưng phù hợp với đặc tả của
nó. Theo cách hiểu này, chất lượng của một sản phẩm phần mềm là sự đáp
ứng các yêu cầu về chức năng (tức là các hàm cần được tính toán), sự hoàn
thiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi sản
phẩm phần mềm chuyên nghiệp. Chất lượng phần mềm đặc trưng cho “độ
tốt, độ tuyệt hảo” của phần mềm, và gồm có các yếu tố về chất lượng như:
tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian
và tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễ
sử dụng, dễ bảo trì ... Như vậy, độ tin cậy chỉ là một yếu tố để đánh giá chất
lượng phầm mềm. Người kiểm thử hay nhầm lẫn độ tin cậy với chất lượng.
Khi kiểm thử đạt tới mức phần mềm chạy ổn định, có thể phụ thuộc vào nó,
người kiểm thử thường cho rằng phần mềm đã đạt chất lượng cao. Các yếu
tố về mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềm
được gọi là các tiêu chuẩn chất lượng như tính có cấu trúc, tính đơn thể,
tính khả kiểm thử, ...
Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất
bại trong một khoảng thời gian nhất định. Nó được xem là một yếu tố quan
trọng của chất lượng phần mềm. Ngoài ra, thời gian trung bình cho việc khắc
phục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tin
cậy của sản phẩm phần mềm.

10/4/15

Quy trình test phần mềm trong quá trình sản xuất phần mềm.

Sau khi nhận được tài liệu yêu cầu (spec) từ khách hàng hoặc bộ phận thiết kế chi tiết.



QC sẽ tìm hiểu spec và viết test plan, sau đó gửi test plan cho khách hàng và project manager xem lại, sau khi duyệt test plan này.

QC sẽ tiến hành viết test case dựa vào spec đó. (song song đó DEV sẽ dựa vào spec để code)

Nếu công ty có bộ phận test whitebox thì dựa vào spec viết test case test whitebox và viết test script để test whitebox. (thường gọi là unit test - ở đây, "unit" là 1 hàm, 1 class hoặc 1 component,... tùy cách nhìn nhận và quản lý của mỗi công ty)

Sau khi test whitebox thành công (test pass các test case whitebox) thì QC sẽ tiến hành test blackbox (test chức năng của từng màn hình - cái này cũng được xem là unit test, "unit" ở đây là 1 màn hình hoặc một chức năng tùy qui định và cách quản lý của mỗi công ty).

Sau khi test từng màn hình thành công (pass hết các test case hoặc đạt được số % test case pass nào đó - ví dụ 97% test case pass) thì chuyển sang giai đoạn test tích hợp (integration testing) là kết hợp một số màn hình/chức năng có liên quan lại với nhau rồi test theo luồng xử lý (user story)

Sau khi pass vòng này thì sẽ tiến hành tổng hợp toàn bộ hệ thống (sản phẩm phần mềm) và tiến hành test ở mức hệ thống.

Có một số công ty hoặc khách hàng yêu cầu test UAT (User Acceptance Testing) thì sẽ thực hiện test lại hệ thống theo các chức năng đã được mô tả trong spec.

Có một số loại phần mềm hoặc khách hàng yêu cầu hoặc qui trình sản xuất phần mềm của công ty, phần mềm sẽ được test alpha và beta.

Trên đây là một qui trình test 1 phần mềm. Tùy vào tính chất của sản phẩm và qui trình sản xuất của mỗi công ty, qui trình trên có thể có nhiều hoặc ít loại test khác hơn.

Trong quá trình test ở bất kỳ mức nào, nếu phát hiện bug thì tester sẽ post bug lên hệ thống quản lý bug (bằng excel hoặc chương trình riêng) và DEV sẽ dựa vào đó fix bug và tester sẽ test lại. (đây là qui trình quản lý và xử lý bug - sẽ nói riêng ở một bài khác)

Ví dụ một qui trình test dựa theo mô hình xây dựng phần mềm V model

Nguồn : Sưu tầm

8/4/15

Kiểm tra phần mềm là gì?

Thực ra KTPM là công việc mà bất cứ người nào từng tham gia phát triển phần mềm (PTPM) đều biết và từng làm. Theo nghĩa thông thường nhất, KTPM bao gồm việc “chạy thử” PM hay một chức năng của PM, xem nó “chạy” đúng như mong muốn hay không. Việc kiểm tra này có thể thực hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau cùng, khi PM đã được phát triển hoàn tất.

KTPM đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng PM và sử dụng PM, trước khi giao sản phẩm hoàn chỉnh cho khách hàng. Bạn có thể tham khảo bài “Tổng quan các mô hình phát triển phần mềm” trong TGVT A số tháng 8/2005 (ID: A0508_106) để biết vị trí của KTPM trong các mô hình PTPM.


CÁC MỨC ĐỘ CỦA KTPM

Thực tế, KTPM không đơn giản như nhiều người thường nghĩ, công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dự án PTPM. Hình 1 cho thấy 4 mức độ cơ bản của KTPM và hình 2 cho thấy mối tương quan với các chặng PTPM trong mô hình V-model.

Phần sau sẽ làm rõ chi tiết về các mức độ KTPM, do một số thuật ngữ không có từ tương đương sát nghĩa trong tiếng Việt, mặt khác để các bạn tiện tham khảo sau này, chúng tôi xin giữ nguyên một số thuật ngữ gốc tiếng Anh.

1. Unit Test – Kiểm tra mức đơn vị

Để có thể hiểu rõ về Unit Test, khái niệm trước tiên ta cần làm rõ: thế nào là một đơn vị PM (Unit)?

Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit.

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.

2. Integration Test – Kiểm tra tích hợp

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:

- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

Có 4 loại kiểm tra trong Integration Test:

- Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.
- Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
- Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
- Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

3. System Test - Kiểm tra mức hệ thống

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án.

Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau, phổ biến nhất gồm:
- Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.
- Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…
- Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…
- Kiểm tra cấu hình (Configuration Test)
- Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
- Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.
Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào.

Hình 2: Mối tương quan giữa phát triển và kiểm tra phần mềm

4. Acceptance Test - Kiểm tra chấp nhận sản phẩm

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng (tiềm năng) kiểm tra PM ngay tại nơi PTPM, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, PM sẽ được gửi tới cho người sử dụng (tiềm năng) để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình PTPM thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ.

Hình 3: Các loại kiểm tra khác nhau trong System Test

5. Regression Test - Kiểm tra hồi quy

Trước tiên cần khẳng định Regression Test không phải là một mức kiểm tra, như các mức khác đã nói ở trên. Nó đơn thuần kiểm tra lại PM sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản PM mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt. Regression test có thể thực hiện tại mọi mức kiểm tra.

Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.

Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là “không được phép” vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!

TÓM TẮT

Trên đây là tổng quan về các mức và loại kiểm tra PM cơ bản. Thực tế nếu đi sâu vào từng mức và loại kiểm tra, còn có rất nhiều kiểm tra đặc thù khác nữa, mang tính chuyên biệt cho từng vấn đề hoặc từng loại ứng dụng. Tuy nhiên, những mức độ và loại kiểm tra nêu trên là cơ bản nhất và có thể áp dụng trong hầu hết các loại ứng dụng PM khác nhau.

Trong số báo tới chúng tôi sẽ giới thiệu những bước cơ bản của một quy trình KTPM, làm thế nào để đánh giá và cải tiến năng lực KTPM của một tổ chức thông qua mô hình TMM (Testing Maturity Model), một mô hình được các chuyên gia đánh giá khá tốt dành cho hoạt động KTPM.

(Sưu tầm)