Tổng quan về kiểm thử phần mềm | Tìm ở đây

1. Tìm hiểu về phần mềm và kiểm thử phần mềm

1.1. Phần mềm

1.1.1. Khái niệm phần mềm

Phần mềm máy tính (Computer Software) hay gọi tắt là Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó.

Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần cứng (hay phần cứng máy tính, Computer Hardware) hoặc bằng cách cung cấp dữ liệu để phục vụ các chương trình hay phần mềm khác.

1.1.2. Phân loại các loại phần mềm

Phần mềm hệ thống: Dùng để quản lý hành vi phần cứng máy tính, cung cấp các chức năng cơ bản được người dùng yêu cầu hoặc phần mềm khác chạy đúng (nếu có). Được thiết kế để cung cấp một nền tảng để chạy phần mềm ứng dụng như hệ điều hành Windows, iOS, Android, trình điều khiển thiết bị Driver…
Phần mềm ứng dụng:
1. Sử dụng hệ thống máy tính để thực hiện các chức năng đặc biệt hoặc cung cấp các chức năng giải trí ngoài hoạt động cơ bản của chính máy tính.
2. Phổ biến trong các phần mềm văn phòng như Microsoft Office, phần mềm game, các công cụ và tiện ích khác…
Phần mềm dịch mã (trình biên dịch và trình thông dịch): Dịch các câu lệnh từ mã nguồn của ngôn ngữ lập trình sang dạng ngôn ngữ máy sao cho thiết bị thực thi có thể hiểu được và hiện thực.
Nền tảng ứng dụng (ASP.net, PHP…): Dựa vào nền tảng ứng dụng Web của Microsoft tạo ra các ứng dụng Web, dịch vụ Web (Web Service)

1.2. Quy trình phát triển phần mềm

Cũng như các ngành sản xuất khác, quy trình là một trong những yếu tố đầu tiên và cực kỳ quan trọng đem lại thành công cho các nhà phát triển phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng với trị trí của mình thông qua cách thức chung của công ty. Quy trình phát triển phần mềm có tính chất quyết định để tạo ra 1 sản phẩm có chi phí thấp và năng suất cao.

Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần mềm. Một quy trình phát triển phần mềm bao gồm các giai đoạn như sau:

Giải pháp, yêu cầu: Thực hiện khảo sát chi tiết yêu cầu của khách hàng để từ đó tổng hợp vào tài liệu giải pháp. Tài liệu này phải mô tả đầy đủ các yêu cầu về chức năng, phi chức năng và giao diện. Kết quả đầu ra là Tài liệu đặc tả yêu cầu.
Thiết kế: Thực hiện thiết kế và tổng hợp vào tài liệu thiết kế. Kết quả là tài liệu thiết kế tổng thể, thiết kế module, thiết kế CSDL.
Lập trình: Lập trình viên thực hiện lập trình dựa trên tài liệu Giải pháp và Thiết kế đã được phê duyệt. Kết quả đầu ra là Source code.
Kiểm thử: Tester tạo kịch bản kiểm thử (testcase) theo tài liệu đặc tả yêu cầu, thực hiện kiểm thử và cập nhật kết quả vào kịch bản kiểm thử, log lỗi trên các tool quản lý lỗi. Kết quả đầu ra là Testcase, lỗi trên hệ thống quản lý lỗi.
Triển khai: Triển khai sản phẩm cho khách hàng. Kết quả đẩu ra là biên bản triển khai với khách hàng.

1.3. Một số mô hình phát triển phần mềm phổ biến hiện nay

1.3.1. Mô hình thác nước (Waterfall model)

Hình 1.1: Mô hình thác nước

-Mô tả:

Đây được coi như là mô hình phát triển phần mềm đầu tiên được sử dụng.
Mô hình này áp dụng tuần tự các giai đoạn của phát triển phần mềm.
Đầu ra của giai đoạn trước là đầu vào của giai đoạn sau. Giai đoạn sau chỉ được thực hiện khi giai đoạn trước đã kết thúc. Đặc biệt không được quay lại giai đoạn trước để xử lý các yêu cầu khi muốn thay đổi.

-Các giai đoạn xử lý của mô hình thác nước:

Phân tích yêu cầu và đặc tả (Requirements and Specifications): là giai đoạn xác định những yêu cầu liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm”. Tài liệu đặc tả chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra làm thế nào để hệ thống phần mềm đáp ứng những yêu cầu mà khách hàng yêu cần trong tài liệu SRS.
Lập trình (Coding and Unit Test): là giai đoạn hiện thực làm thế nà được chỉ ra trong giai đoạn “Phân tíc hệ thống và thiết kế”.
Kiểm thử (Test): bao gồm kiểm thử tích hợp cho nhóm các thành phần kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.
Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt cầu hình và đào tạo cho khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).

-Ứng dụng vào các dự án phần mềm sau:

Các dự án nhỏ, ngắn hạn.
Các dự cán có ít thay đổi về yêu cầu và không có những yêu cầu không rõ ràng.

-Ưu điểm:

Dễ sử dụng, dễ tiếp cận, dễ quản lý.
Sản phẩm phát triển theo các giai đoạn được xác định rõ ràng.
Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm lỗi.

-Nhược điểm:

Ít linh hoạt, phạm vi điểu chỉnh hạn chế.
Rất khó để đo lường sự phát triển trong từng giai đoạn.
Mô hình không thích hợp với những dự án dài, đang diễn ra, hay những dự án phức tạp, có nhiều thay đổi yề yêu cầu trong vòng đời phát triển.
Khó quay lại khi giai đoạn nào đó đã kết thúc.

1.3.2. Mô hình chữ V (V model)

Hình 1.2: Mô hình chữ V

-Mô tả:

Mô hình chữ V là một phần mở rộng của mô hình thác nước và được dựa trên sự kết hợp của một giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.
Với V model thì công việc test được tham gia ngay từ đầu.

-Giai đoạn phát triển:

Xác định yêu cầu và đặc tả (Requirement and Specification): xác định yêu cầu cần thiết mà hệ thống đòi hỏi, đưa ra đặc tả.
Phân tích hệ thống (System Analysis): phân tích các yêu cầu mà hệ thống cần có và đưa ra giải pháp tích hợp các yếu tố đó vào hệ thống.
Thiết kế chi tiết (Detailed Design): chi tiết hóa các bước thực hiện xây dựng hệ thống (Về cả giao diện và nội dung).
Phát triển (Development): thực hiện việc viết code.

-Giai đoạn triển khai:

Kiểm tra từng thành phần và tích hợp (Unit and Intergration Test): kiểm tra các module của hệ thống tương ứng với pha thiết kế tương ứng.
Kiểm thử toàn hệ thống (System Test): kiểm thử hoạt động của hệ thống (về chức năng, giao diện).
Nghiệm thu (Accepted Test): Kiểm tra lần cuối cùng và nghiệm thu sản phầm đưa vào hệ thống.

-Ứng dụng vào các dự án phần mềm sau:

Yêu cầu được xác định rõ ràng.
Xác định sản phẩm ổn định.
Công nghệ không thay đổi và được hiểu rõ bởi nhóm dự án.
Không có yêu cầu không rõ ràng hoặc không xác định.
Dự án ngắn.

-Ưu điểm:

Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hình thành cùng một lúc.
Hoạt động tốt cho các dự án nhỏ, khi các yêu cầu được hiểu rất rõ.
Đơn giản và dễ hiểu và dễ sử dụng, dễ quản lý.

-Nhược điểm:

Khó quản lý kiểm soát rủi ro, rủi ro cao.
Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
Mô hình kém cho các dự án dài và đang diễn ra.
Không thích hợp cho các dự án có nguy cơ thay đổi yêu cầu trung bình đến cao.

1.3.3. Mô hình Agile

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI”. Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng.

Hình 1.3: Mô hình Agile

-Mô tả:

Các yêu cầu và giải pháp phát triển dựa trên sự kết hợp của các function
Trong Agile, các tác vụ được chia thành các khung thời gian nhỏ để cung cấp các tính năng cụ thể cho bản phát hành cuối.

-Ứng dụng vào các dự án phần mềm sau:

Có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng cần sự tham gia và tính tương tác của khách hàng.
Sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn.

-Ưu điểm:

Tăng cường tinh thần làm việc nhóm và trao đổi công việc hiệu quả.
Các chức năng được xây dựng nhanh chóng và rõ ràng, dễ quản lý.
Dễ dàng bổ sung, thay đổi yêu cầu.
Quy tắc tối thiểu, tài liệu dễ hiểu, dễ sử dụng.

-Nhược điểm:

Mô hình Agile được sử dụng rộng rãi trên thế giới nhưng cũng không đồng nghĩa với phù hợp với tất cả các dự án phần mềm.

Không thích hợp để xử lý các phụ thuộc phức tạp.
Có nhiều rủi ro về tính bền vững, khả năng bảo trì và khả năng mở rộng.
Cần một team có kinh nghiệm.
Phụ thuộc rất nhiều vào sự tương tác rõ ràng của khách hàng.
Chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn do thiếu tài liệu.

1.3.4. Mô hình Scrum

Hình 1.4: Mô hình Scrum

-Mô tả:

Chia các yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn(sprint) chỉ làm 1 số lượng yêu cầu nhất định.
Mỗi một sprint thường kéo dài từ 1 tuần đến 4 tuần ( ko dài hơn 1 tháng).
Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ thực hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả code lẫn test có thể demo và chạy được.
Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint… cho đến khi hoàn thành hết các yêu cầu.
Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting từ 15 – 20 phút. Mỗi thành viên sẽ báo cáo: Hôm qua tôi đã làm gì? Hôm nay tôi sẽ làm gì? Có gặp khó khăn gì không?
Scrum là mô hình hướng khách hàng (Customer oriented).

-Các nhân tố tạo nên quy trình Scrum:

-Có ba nhân tố quan trọng cấu thành nên Scrum:

Tổ chức (Organization):
1. Tổ chức nhóm dự án và Roles: Vai trò.
2. Product Owner: Người sở hữu sản phẩm.
3. ScrumMaster: Người điều phối.
4. Development Team: Nhóm phát triển.
Tài liệu (Atifacts): đó chính là các kết quả đầu ra.
1. Product Backlog: danh sách các chức năng cần phát triển của sản phẩm.
2. Sprint Backlog: danh sách các chức năng cần phát triển cho mỗi giai đoạn.
3. Estimation: kết quả ước lượng của team.
Quy trình (Process): quy định cách thức vận hành của Scrum.
1. Sprint Planning meeting: Hoạch định cho mỗi giai đoạn.
2. Review: Tổng kết cho mỗi giai đoạn.
3. Daily Scrum Meeting: Review hàng ngày.

-Tổ chức dự án:

Product Owner:
1. PO là người sở hữu sản phẩm, người quyết định sản phẩm có những chức năng nào và là người quyết định Product Backlog.
2. Thông thường Role này được khách hàng hoặc người đại diện khách hàng đảm nhận.
ScrumMaster: là người đảm bảo các quy trình của Scrum được thực hiện đúng và thuận lợi.
Development Team
1. Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm.
2. Nhóm dự án phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint (giai đoạn )này và kết quả sẽ ra sao.
3. Thảo luận để đưa ra các giải pháp, ước lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc.
Product Backlog:
1. Product Backlog là danh sách các chức năng cần được phát triển của sản phẩm.
2. Danh sách này do PO quyết định.
3. Thường xuyên được cập nhật để đáp ứng được nhu cầu thay đổi của khách hàng và dự án.

-Ưu điểm:

Một người có thể thực hiện nhiều việc ví dụ như dev có thể test.
Phát hiện lỗi sớm.
Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.

-Nhược điểm:

Trình độ của nhóm cần có một kỹ năng nhất định.
Phải có sự hiểu biết về mô hình aglie.
Khó khăn trong việc xác định ngân sách và thời gian.
Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài.
Vai trò của PO rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung.

1.4. Lỗi phần mềm

1.4.1. Khái niệm lỗi phần mềm

Một lỗi phần mềm là một lỗi, lỗ hổng, thất bại, hoặc có lỗi trong một chương trình máy tính hoặc hệ thống đó là nguyên nhân nó tạo ra kết quả không chính xác hoặc không mong muốn, hoặc vận hành theo cách không được định hướng trước.

1.4.2. Những thuật ngữ mô tả về lỗi phần mềm

Có nhiều thuật ngữ khác nhau để mô tả lỗi phụ thuộc vào tình trạng của lỗi.

Dưới đây là một số thuật ngữ:

Defect: nhược điểm
Fault: khuyết điểm
Failure: sự thất bại
Anomaly: sự dị thường
Variance: biến dị
Incident: việc rắc rối
Error: lỗi
Bug: lỗi
Feature: đặc trưng
Inconsistency: sự mâu thuẫn

“Fault”, “failure” và “defect” có xu hướng ám chỉ một vấn đề thật sự quan trọng, thậm chí là nguy hiểm. “Anomaly”, “incident”, “variance” thường được sử dụng để đề cập tới sự vận hành không được dự tính trước thay vì hoàn toàn là lỗi (all-out failure). “Problem”, “error” và “bug” là những thuật ngữ chung nhất thường được sử dụng, dùng để chỉ sai sót của lập trình viên trong quá trình tạo ra sản phẩm.

1.4.3. Quy tắc xác định lỗi phần mềm

Một lỗi phần mềm xuất hiện khi vi phạm ít nhất 1 trong 5 quy tắc dưới đây:

Quy tắc 1: Phần mềm không thực hiện một số thứ giống như mô tả trong bản đặc tả phần mềm.
Quy tắc 2: Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện.
Quy tắc 3: Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới.
Quy tắc 4: Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhưng là những việc nên làm.
Quy tắc 5: Đối với người kiểm thử, phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng.

1.4.4. Vòng đời lỗi

Vòng đời của lỗi là một hành trình mà mà lỗi đi qua trong suốt cuộc đời của nó. Nó thay đổi từ tổ chức này sang tổ chức khác, từ dự án này đến dự án khác và nó được điều chỉnh bởi quy trình kiểm thử phần mềm.

Hình 1.5: Vòng đời của lỗi

-Vòng đời của lỗi bao gồm các trạng thái dưới đây:

New: Khi mà lần lỗi được log lên đầu tiên bởi người kiểm thử.
Assigned: Khi lỗi được đăng lên và chỉ định cho lập trình viên nào đó.
Open: Khi lập trình viên đang sửa lỗi.
Fixed: Khi lập trình viên hoàn thành việc sửa lỗi.
Retest: Người kiểm thử kiểm tra lỗi đã được sửa hay chưa, có phát sinh thêm lỗi mới nào không.
Reopened: Nếu lỗi vẫn còn, người kiểm thử sẽ trả lại cho lập trình viên. Lỗi phải đi lại một vòng đời như cũ.
Deferred: Lỗi được sửa trong bản phát hành tiếp theo. Lý do có thể là độ ưu tiên của lỗi có thể là thấp, thiếu thời gian để phát hành hoặc lỗi có thể không ảnh hưởng lớn đến phần mềm.
Rejected: Nếu lập trình viên cho rằng không phải lỗi, họ có thể chuyển sang trạng thái này.
Duplicate: Lỗi được đăng trùng với nhau.
Closed: Khi người kiểm thử đã thấy lỗi được sửa triệt để.
Not a bug/Enhancement: Một số thay đổi trong ứng dụng, không phải là lỗi.

1.5. Kiểm thử phần mềm

1.5.1. Kiểm thử phần mềm (Software Testing)

Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra. Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy.

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì việc kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.

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.[1]

1.5.2. Các nguyên tắc cơ bản của kiểm thử phần mềm

Nguyên tắc 1: Kiểm thử luôn có lỗi

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng một phần mềm không có lỗi.

Kiểm thử làm giảm xác suất lỗi tiềm ẩn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy, cần phải tìm được càng nhiều lỗi càng tốt.

Nguyên tắc 2: Kiểm thử toàn bộ là không thể

Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ khi kiểm thử chỉ bao gồm một số ít trường hợp thì có thể kiểm thử toàn bộ.

Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên người kiểm thử có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn. Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường hợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đến tay người dùng.

Nguyên tắc 3: Kiểm thử càng sớm càng tốt

Để tìm được lỗi sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong quy trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động/mục tiêu đã xác định trước.

Các hoạt động kiểm thử được bắt đầu càng sớm thì sẽ phát hiện ra lỗi sớm khi đó ít tốn công để tìm lỗi và sửa chữa.

Nguyên tắc 4: Sự tập trung của lỗi

Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.

Nguyên tắc 5: Nghịch lý thuốc trừ sâu

Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.

Nguyên tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh

Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.

Nguyên tắc 7: Không có lỗi – sai lầm

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.

1.5.3. Quy trình kiểm thử phần mềm

Quy trình kiểm thử phần mềm gồm có 5 bước:

Hình 1.6: Các bước trong một quy trình kiểm thử phần mềm

a) Lập kết hoạch

Nhằm chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện. Kết quả là bản kế hoạch kiểm thử phần mềm bao gồm chi tiết từ các loại kiểm thử, chiến lược kiểm thử, cho đến thời gian và phân định lực lượng kiểm thử viên.

Hình 1.7: Các bước lập kế hoạch kiểm thử

-Các bước lập kế hoạch kiểm thử:

Xác định yêu cầu kiểm thử: Xác định những gì cần phải kiểm thử dựa theo yêu cầu từ khách hàng, đặc tả yêu cầu người sử dụng.
Xác định các chiến lược kiểm thử: Xác định phương thức, loại kiểm thử cần thực hiện và tiêu chí đầu ra.
Xác định tài nguyên, môi trường: Xác định nguồn nhân lực và môi trường thực hiện kiểm thử (số lượng người, yêu cầu về phần cứng, phần mềm, công cụ hỗ trợ…).
Lập thời gian cho các giai đoạn kiểm thử:
Đánh giá kế hoạch: Trưởng dự án sẽ cùng những người liên quan tham gia đánh giá xem bản kế hoạch kiểm thử có phù hợp với yêu cầu dự án chưa. Nếu chưa thì sẽ phải thực hiển sửa lại theo yêu cầu.
Thông báo tới các bên liên quan: Trưởng dự án sẽ gửi thông báo toàn bộ những người trong dự án có liên quan đến kế hoạch kiểm thử.

b) Thiết kế test case (thiết kế trường hợp kiểm thử)

Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phần mềm. Giai đoạn thiết kế test case là hết sức quan trọng, nó đảm bảo các tình huống kiểm thử bao phủ tất cả các yêu cầu.

Hình 1.8: Các bước thiết kế kiểm thử

c) Phát triển test script

Bước này thường không bắt buộc trong các loại và mức kiểm thử, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kế kiểm thử.

d) Thực hiện kiểm thử

Mục đích thực hiện kiểm tra các bước đã thiết kế và ghi nhận kết quả.

Hình 1.9: Các bước thực hiện kiểm thử

Thiết lập môi trường và cài đặt: Để thực hiện kiểm thử, thao tác đầu tiên cần làm là xác lập và khởi động môi trường kiểm thử. Việc này nhằm đảm bảo tất cả các bộ phận liên quan (phần cứng, phần mềm, máy chủ, mạng, dữ liệu…) đã được cài đặt và sẵn sàng trước khi chính thức bắt đầu thực hiện kiểm thử.
Tiến hành kiểm thử theo các trường hợp kiểm thử đã chuẩn bị.
Thẩm định kết quả kiểm thử: Sau khi tiến hành kiểm thử, kết quả kiểm thử cần được xem xét để đảm bảo kết quả nhận được là đáng tin cậy. Nhận biết được những lỗi không phải do phần mềm mà do dữ liệu dùng để kiểm thử, môi trường kiểm thử, hoặc các bước kiểm thử gây ra. Nếu thực sự lỗi xảy ra do quá trình kiểm thử, cần phải sửa chữa và kiểm tra lại từ đầu.

e) Đánh giá quá trình kiểm thử

Bao gồm xem xét và đánh giá kết quả kiểm thử lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan đến quá trình kiểm thử (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi…)

Các bước đánh giá quá trình kiểm thử:

Thống kê số lượng lỗi.
Phân tích kết quả kiểm thử và yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong đợi và kết quả thực tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó.
Đánh giá chất lượng sản phẩm kiểm thử: Từ những kết quả kiểm thử, nhóm kiểm thử sẽ xem xét, đánh giá chất lượng sản phẩm.
Thông báo tới các bên liên quan: Trưởng dự án sẽ thông báo cho các bên liên quan về kết quả kiểm thử đạt được.

1.5.4. Phân loại kiểm thử

Có 2 phương pháp kiểm thử chính là: Static testing (Kiểm thử tĩnh) và Dynamic testing (Kiểm thử động).

a) Static testing (Kiểm thử tĩnh)

Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà phần mềm không được sử dụng thực sự. Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu. Chủ yếu kiểm tra cú pháp của code/ hoặc review code (kiểm tra xem code có được viết đúng tiêu chuẩn code. Đây là loại kiểm thử có thể được sử dụng bởi DEV (những người lập trình), làm việc một cách độc lập. Các kỹ thuật review code , kiểm tra và walkthoughs cũng được sử dụng trong test tĩnh này. Kiểm thử tĩnh liên quan đến việc xem xét các yêu cầu và các tài liệu thiết kế chi tiết.

Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chương trình.

Các kỹ thuật kiểm thử tĩnh giúp nâng cao chất lượng phần mềm bằng cách hỗ trợ các nhà phát triển nhận ra và sửa chữa các sai sót của họ trong quá trình phát triển phần mềm.

b) Dynamic testing (Kiểm thử động)

Kiểm thử tự động là việc sử dụng phần mềm đặc biệt (tách biệt với phần mềm đang được kiểm thử) để kiểm soát việc thực hiện các bài kiểm tra và so sánh kết quả thực tế với kết quả dự đoán. Kiểm thử tự động có thể tự động hóa một số nhiệm vụ lặp đi lặp lại nhưng cần thiết trong một quá trình kiểm thử đã được chính thức hóa, hay là các kiểm thử bổ sung nhưng sẽ khó thực hiện thủ công. Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự bao gồm: làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không.

Các phương pháp kiểm thử động gồm có: Unit test (Kiểm thử đơn vị), Intergration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thử chấp nhận).

1.5.5. Các cấp độ kiểm thử phần mềm

Kiểm thử phần mềm gồm có 4 cấp độ: Unit test (Kiểm thử đơn vị), Intergration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thử chấp nhận). Tùy theo yêu cầu và đặc trưng của từng hệ thống, khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người quản lý dự án sẽ quyết định những loại kiểm thử được sử dụng.

Hình 1.10: Các cấp độ kiểm thử phần mềm

a) Unit Test (Kiểm thử đơn vị)

Unit (Đơn vị) là một thành phần phần mềm nhỏ nhất có thể kiểm thử được. Các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit. 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, vì vậy thường không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. 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 vị đ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 thử và sửa lỗi ở các mức kiểm thử 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ỳ phát triển phần mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của kiểm thử đơn vị 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 đơn vị. Đ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. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và bao phủ 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 với các mục kiểm thử khác, unit test cũng đòi hỏi phải chuẩn bị trước test case (ca kiểm thử) hoặc test script (kịch bản kiểm thử), trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các test case và test script này nên được giữ lại để tái sử dụng.

b) Intergration Test (Kiểm thử tích hợp)

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

Hai mục tiêu chính của intergration test:

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ỏ và cuối cùng là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống.

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 thử đơ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 chỉ 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 kiểm thử tích hợp.

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.

c) System Test (Kiểm thử hệ thống)

System test là một phương pháp theo dõi và đánh giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chỉnh và đã được tích hợp đầy đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác định trước. System test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử 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 thử đò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, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử 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 intergration 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 intergration test chú trọng sự giao tiếp giữa các unit hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường, unit test và intergration test cần phải thực hiện trước để 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 intergration test, một hệ thống phần mềm đã đượ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 thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lên 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.

System test thực hiện kiểm thử 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 thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” hoặc chiếm dụng bộ nhớ. Sau giai đoạn system test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm hoặc dùng thử sản phẩm.

System 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 thử viên hoàn toàn độc lập với nhóm phát triển dự án. Trong system test lại bao gồm nhiều loại kiểm thử khác nhau, một số loại phổ biến nhất gồm:

Functional Testing (Kiểm thử chức năng): 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ế.
Interface/GUI Test (Kiểm thử giao diên người dùng): Là kỹ thuật kiểm thử để xác nhận xem giao diện của phần mềm có hoạt động đúng như mong đợi hay không (về các đối tượng trên giao diện, vị trí, màu sắc, lỗi chính tả, trạng thái của các đối tượng…).
Performance Testing (Kiểm thử hiệu năng): Đảm bảo tối ưu việc phân bổ tài nguyên hệ thống (bộ nhớ, …) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…
Stress Test (Kiểm thử khả năng chịu tải): Đảm bảo 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 như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM…).
Configuration test (Kiểm thử cấu hình): Kiểm thử sự tương thích giữa phần mềm và phần cứng.
Security Test (Kiểm thử bảo mật): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
Recovery Test (Kiểm thử khả năng phục hồi): 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…

d) Acceptance Test (Kiểm thử chấp nhận)

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 phần mềm 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.

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 phát triển phần mềm thì kết quả kiểm thử chấp nhận sản phẩm sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử 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.

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… Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.

1.5.6. Thiết kế Test Case

Test case mô tả một dữ liệu đầ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.

Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì vậy, việc chuẩn bị test case sớm nhất có thể trong quy trình phát triển phần mềm là rất hữu ích.

Các trường hợp kiểm thử phải bao phủ được toàn bộ luồng xử lý chức năng mô tả trong tài liệu phân tích và thiết kế; các yêu cầu về bảo mật an toàn thông tin, yêu cầu hiệu năng của hệ thống.

Cấu trúc một test case thường bao gồm các thông tin:

Test Case ID (Mã và tên của test case): Giá trị cần để xác định số lượng trường hợp cần để kiểm thử.
Test Items (Mục đích kiểm thử): Mô tả mục đích sử dụng của test case. Giúp Tester hiểu và thực hiện đúng khi kiểm thử phần mềm theo test case mô tả.
Pre-condition (Điều kiện tiên quyết): Mô tả điều kiện cần có để có thể thực hiện test case này.
Test Steps (Mô tả các bước): Mô tả cụ thể các bước cần thực hiện để tái hiện nội dung test case khi Tester thực hiện kiểm thử phần mềm.
Test Data (Dữ liệu đầu vào): Là dữ liệu nhập vào các trường của phần mềm để thực hiện kiểm thử.
Expected results (Kết quả mong đợi): Một test case được viết tốt cần phải đề cập một cách rõ ràng kết quả mong đợi của ứng dụng hoặc hệ thống. Chỉ ra những gì mong đợi như là đầu ra của bước kiểm tra đó.

a) Các bước viết một test case

Bước 1: Xác định mục đích test, cần hiểu rõ đặc tả yêu cầu của khách hàng.
Bước 2: Xác định chức năng testing, cần phải biết làm thế nào phần mềm được sử dụng bao gồm các hoạt động, tổ chức chức năng khác nhau.
Các bước thực hiện chỉ mô tả các bước thực hiện đứng từ phía người dùng cuối bao gồm nhập dữ liệu, nhấn button.
Bước 3: Xác định các yêu cầu phi chức năng, yêu cầu phần cứng, hệ điều hành, các khía cạnh an ninh.
Bước 4: Xác định biểu mẫu cho test case, bao gồm giao diện UI, chức năng, khả năng tương thích và hiệu suất…
Bước 5: Xác định tính ảnh hưởng giữa các nguyên tắc module test case nên được thiết kế để có thể bao phủ được sự ảnh hưởng của các module với nhau ở mức độ cao nhất.

b) Các kĩ thuật viết test case

Equivalence Partitioning (Phân vùng tương đương)

-Ý tưởng: Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể kiểm tra một giá trị đại diện trong vùng tương đương.

Hình 1.11: Kỹ thuật phân vùng tương đương

-Thiết kế test case bằng kỹ thuật phân vùng tương đương tiến hành theo 2 bước:

Bước 1: Xác định các lớp tương đương.
Bước 2: Xác định các ca kiểm thử.

-Ưu/ Nhược điểm của kỹ thuật phân vùng tương đương:

Ưu điểm: Vì mỗi vùng tương đương ta chỉ cần test trên các phần tử đại diện nên số lượng test case được giảm đi khá nhiều nhờ đó mà thời gian thực hiện test cũng giảm đáng kể.
Nhược điểm: Không phải với bất kỳ bài toán nào đều có thể áp dụng kỹ thuật này. Có thể bị sót lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tương đương. Vì vậy việc kết hợp linh hoạt giữa kỹ thuật phân vùng tương đương và phân tích giá trị biên dưới đây sẽ mang lại hiệu quả cao hơn để vừa tối ưu số lượng test case và vẫn đảm bảo đươc chất lượng phần mềm.

Boundary-value Analysis (Phân tích giá trị biên)

-Ý tưởng: Phân tích giá trị biên là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng tương đương tester sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn test case phù hợp.

-Các case chuẩn được lựa chọn dựa vào quy tắc sau:

Giá trị biên nhỏ nhất ± 1.
Giá trị biên nhỏ nhất.
Giá trị biên lớn nhất.
Giá trị biên lớn nhất ± 1.

Hình 1.12: Kỹ thuật phân tích giá trị biên

-Ưu/ Nhược điểm của kỹ thuật phân tích giá trị biên:

Ưu điểm: Thay vì phải kiểm tra hết toàn bộ các giá trị trong từng vùng tương đương, kỹ thuật phân tích giá trị biên tập trung vào việc kiểm thử các giá trị biên của miền giá trị inputs để thiết kế test case do “lỗi thường tiềm ẩn tại các ngõ ngách và tập hợp tại biên”. Do đó, tiết kiệm thời gian thiết kế test case và thực hiện test.
Nhược điểm: Phương pháp này chỉ hiệu quả trong trường hợp các đối số đầu vào độc lập với nhau và mỗi đối số đều có một miền giá trị hữu hạn.

Error Guessing (Đoán lỗi)

-Ý tưởng: Phương pháp này không có quy trình cụ thể vì có tính trực giác cao và không thể dự đoán trước. Phương pháp chỉ phù hợp với những Tester có kinh nghiệm. Họ phỏng lỗi phần mềm dựa vào trực giác, dựa vào kinh nghiệm, dữ liệu lịch sử về các lỗi đã từng xảy ra với chương trình trước đó… và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.

-Ưu/ Nhược điểm:

Ưu điểm: Sử dụng phương pháp này có thể giúp tester tìm ra những lỗi điển hình thường xảy ra trong phần mềm hoặc những lỗi không thể tìm thấy khi thiết kế test case theo hình thức formal.
Nhược điểm: Kỹ thuật này thường được thực hiện bởi các Tester có kinh nghiệm và không theo một quy tắc nhất định, thiết kế test case dựa nhiều vào cảm tính.

Ngoài 3 kỹ thuật thiết kế các trường hợp kiểm thử đã nói ở trên, còn rất nhiều các kỹ thuật kiểm thử khác như: thiết kế các trường hợp kiểm thử dựa trên đồ thị nguyên nhân – kết quả (Cause-Effect Diagram), dựa trên bảng quyết định (Decision Tables)…

Để giảm thiểu số case đến mức tối ưu mà vẫn đảm bảo chất lượng phần mềm, mỗi tester cần linh hoạt trong việc lựa chọn các kỹ thuật thiết kế các trường hợp kiểm thử.

1.6. Các kỹ thuật kiểm thử phần mềm

1.6.1. Kiểm thử hộp đen (Black box testing)

Kiểm thử hộp đen hay còn gọi là kiểm thử hướng dữ liệu. Trong kỹ thuật này người kiểm thử xem phần mềm như là một hộp đen. Người kiểm thử hoàn toàn không quan tâm đến cấu trúc, hành vi bên trong phần mềm. Người kiểm thử chỉ quan tâm đến việc tìm ra các lỗi mà phần mềm không xử lý theo đúng đặc tả của nó. Vì thế dữ liệu kiểm thử xuất phát từ đặc tả.

Hình 1.13: Kiểm thử hộp đen

-Kiểm thử hộp đen cố gắng tìm ra các lỗi trong các loại sau:

Các chức năng thiếu hoặc không đúng so với bản đặc tả
Các lỗi thi hành
Lỗi giao diện
Các lỗi cấu trúc dữ liệu trong việc truy cập cơ sở dữ liệu bên ngoài
Các lỗi khởi tạo hoặc kết thúc
Các lỗi khác

-Một số loại kiểm thử hộp đen hay dùng

Kiểm thử phân vùng tương đương
Kiểm thử phân tích giá trị biên
Kiểm thử dựa vào đồ thị nguyên nhân – kết quả
Sử dụng bảng quyết định

-Ưu điểm: Các tester được thực hiện từ quan điểm của người dùng sẽ giúp sáng tỏ sự chênh lệch về thông số kỹ thuật. Theo phương pháp này, tester không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, “Hỏi và bạn sẽ nhận” các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy. Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer, cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị.

-Nhược điểm: Dữ liệu đầu vào yêu cầu một khối lượng mẫu khá lớn. Nhiều dự án không có thông số rõ ràng thì việc thiết kế các trường hợp kiểm thử rất khó và do đó khó viết kịch bản kiểm thử cần xác định tất cả các yếu tố đầu vào, và cả yếu tố thời gian. Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao. Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình sẽ được để lại chưa được kiểm tra.

1.6.2. Kiểm thử hộp trắng (White box testing)

Kiểm thử hộp trắng còn gọi là kiểm thử cấu trúc. Dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng không. Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định về ngôn ngữ lập trình được dùng, về thuật giải được dùng trong phần mềm để có thể thông hiểu chi tiết về đoạn code cần kiểm thử.

Hình 1.14: Kiểm thử hộp trắng

Kiểm thử hộp trắng thường tốn rất nhiều thời gian và công sức nếu phần mềm quá lớn (thí dụ trong kiểm thử tích hợp hay kiểm thử chức năng). Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị, kiểm thử từng tác vụ của một lớp chức năng.

-Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như sau:

Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1 lần.
Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển phải được đi qua một lần.
Bao phủ đường: tất cả các đường từ điểm khởi tạo đến điểm cuối cùng trong sơ đồ dòng điều khiển phải được đi qua.

-Các kỹ thuật kiểm thử hộp trắng:

Kiểm thử đường dẫn cơ sở.
Kiểm thử cấu trúc điều khiển bao gồm các kĩ thuật: kiểm thử điều kiện và kiểm thử vòng lặp.

-Ưu điểm: Buộc các chuyên gia kiểm thử phải suy luận cẩn thận về việc kiểm thử lỗi vì vậy lỗi sẽ được triệt để, cho phép tìm kiếm các lỗi ẩn bên trong. Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất.

-Nhược điểm: Khá mất thời gian và công sức nhưng vẫn sẽ tồn tại lỗi. Đòi hỏi ngưởi kiểm thử có kinh nghiệm và am hiểu về kiểm thử cũng như về cấu trúc bên trong của phần mềm được thử nghiệm.

1.6.3. Kiểm thử hộp xám

Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa phương pháp kiểm thử Black Box và White Box. Trong kiểm thử hộp đen tester kiểm thử các hạng mục mà không cần biết cấu trúc bên trong của chương trình, còn kiểm thử hộp trắng thì tester biết được cấu trúc bên trong của chương trình. Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần. Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế các trường hợp kiểm thử, nhưng khi thực hiện kiểm thử thì test như người dùng cuối hoặc là ở mức hộp đen.

Hình 1.15: Kiểm thử hộp xám

Mặc dù phương pháp kiểm thử hộp xám có thể được dùng trong các mức khác nhau của kiểm thử, tuy nhiên nó chủ yếu được sử dụng trong kiểm thử tích hợp.

Kiểm thử hộp xám nhằm tìm ra tối đa số lỗi về cấu trúc dữ liệu của hộp trắng và lỗi chức năng của hộp đen. Trong kiểm thử hộp xám viết các trường hợp kiểm thử dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình). Thực hiện kiểm thử trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới kiểm thử được, không can thiệp vào code).

-Ưu điểm: Hoạt động tốt cho các đoạn mã lớn, các vai trò được xác định rõ ràng cho người dùng và nhà phát triển trong quá trình thử nghiệm. Thử nghiệm dựa trên yêu cầu của người dùng chứ không phải người thiết kế.

-Nhược điểm: Hầu hết các trường hợp kiểm thử đều khó thiết kế. Kiểm thử hộp xám không được coi là một phương pháp hiệu quả vì không có nhiều kịch bản để kiểm thử.

2. Kiểm thử tự động

2.1 Khái quát về kiểm thử tự động (Automation testing)

Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một ca kiểm thử. Nó sử dụng một công cụ kiểm thử tự động nào đó để rút ngắn thời gian kiểm thử. Kiểm thử tự động hỗ trợ các kiểm thử viên rất nhiều tùy vào công cụ và các nội dung kiểm thử có thể thực hiện bằng tay hay không. Đối với những nhiệm vụ kiểm tra khó mà thực hiện bằng tay hoặc yêu cầu chi phí về nhân công là quá lớn thì sử dụng công cụ hỗ trợ là điều hết sức cần thiết.

Lợi ích của kiểm thử tự động:

Tiết kiệm thời gian và tiền bạc: Kiểm thử tự động sử dụng các công cụ có sẵn thể ghi lại bộ kiểm thử này và phát lại nó theo yêu cầu. Kiểm thử tự động là tự động hóa công việc, không cần can thiệp của con người nên có thể chạy tự động kiểm tra mà không cần giám sát.
Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test cases với độ chính xác cao hơn.
Độ bao phủ cao: Khi sử dụng kiểm thử tự động, người kiểm thử có thể thực thi số lượng lớn các test cases trong một thời gian ngắn. Điều này giúp người kiểm thử tăng độ bao phủ trong giai đoạn regression test.

2.2 Ưu và nhược điểm

2.2.1. Ưu điểm

Độ tin cậy cao: Công cụ kiểm thử tự động có sự ổn định cao hơn so với các kiểm thử thủ công đặc biệt là trong trường hợp nhiều test case.
Khả năng lặp: Công cụ kiểm thử tự động ra đời để giúp cho các tester không phải lặp đi lặp lại các thao tác một cách nhàm chán với độ tin cậy và ổn định cao.
Khả năng tái sử dụng: Với một bộ kiểm thử tự động người ta có thể sử dụng nhiều phiên bản ứng dụng khác nhau.
Tốc độ cao: Do là công cụ kiểm thử tự động bằng máy nên việc kiểm thử tự động nhanh hơn nhiều so với kiểm thử thủ công.
Chi phí thấp: Nếu áp dụng kiểm thử tự động một cách khoa học giúp người thực hiện giảm chi phí, thời gian và nhân lực.

2.2.2. Nhược điểm

Các công cụ kiểm thử tự động mặc dù rất thuận tiện về nhiều phương diện nhưng thực tế dù như thế nào đi chăng nữa thì nó cũng không phải là một công cụ có thể thay thế hoàn toàn quá trình kiểm thử thủ công.
Để thực hiện các thiếp lặp tự động thì vẫn cần một người có kiến thức về lập trình, tư duy logic.
Mất thời gian và công sức để tạo mới và chỉnh sửa script phức tạp.
Mất chi phí cho các các công cụ tự động hóa như phí bản quyền, bảo trì, đào tạo….

2.3. Các loại kiểm thử tự động

2.3.1. Kiểm thử chức năng

Kiểm thử chức năng là một loại kiểm thử hộp đen và test case của nó được viết dựa trên đặc tả của ứng dụng phần mềm. Các chức năng được kiểm thử bằng cách nhập vào các giá trị nhập vào và kiểm tra các kết quả đầu ra, không quan tâm đến cấu trúc bên trong của phần mềm.

Kiểm thử chức năng phần mềm là một quy trình cố gắng tìm ra các sự khác biệt giữa đặc tả bên ngoài của phần mềm và thực tế của phần mềm cung cấp.

Một số công cụ kiểm thử chức năng: Selenium, QTP (Quick Test Pro), Appium, …

2.3.2. Kiểm thử hiệu năng (Performance Testing)

Kiểm thử hiệu năng là một loại kiểm thử nhằm xác định mức độ đáp ứng, độ tin cậy và khả năng mở rộng hệ thống dưới một khối lượng truy cập nhất định.

Kiểm thử hiệu năng thường được dùng để giúp xác định tắc nghẽn trong một hệ thống, thiết lập một đường cơ sở để kiểm thử trong tương lai, hỗ trợ điều chỉnh hiệu suất hiệu quả, xác định sự phù hợp mục tiêu và yêu cầu hiệu suất, và thu thập dữ liệu hoạt động liên quan khác để giúp các bên liên quan đưa ra quyết định liên quan đến chất lượng chung của các ứng dụng đang được kiểm thử. Ngoài ra, các kết quả từ việc kiểm thử hiệu suất và phân tích có thể giúp nhà phát triển ước tính cấu hình phần cứng cần thiết để hỗ trợ các ứng dụng khi đưa sản phẩm đi vào sử dụng rộng rãi

Một số công cụ kiểm thử hiệu năng: LoadRunner, Jmeter…