Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1. Khái niệm phần mềm Phần mềm máy tính (Computer Software) hay còn 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ị đƣợ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 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. Phần mềm là một khái niệm trừu tƣợng, nó khác với phần cứng ở chỗ là “phần mềm không thể sờ hay đụng vào”, và nó cần phải có phần cứng mới có thể thực thi đƣợc.
Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là một cuộc kiểm tra đƣợc tiến hành để cung cấp cho các bên liên quan thông tin về chất lƣợng của sản phẩm hoặc dịch vụ đƣợc kiểm thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu đƣợc những rủi ro trong quá trình triển khai phần mềm. 2 Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chƣơng trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chƣơng trình máy tính / ứng dụng / sản phẩm nhằm: - Đáp ứng đƣợc mọi yêu cầu hƣớng dẫn khi thiết kế và phát triển phần mềm - Thực hiện công việc đúng nhƣ kỳ vọng - Có thể triển khai đƣợc với những đặc tính tƣơng tự - Và đáp ứng đƣợc mọi nhu cầu của các bên liên quan 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ì các nỗ lự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. Mục đích của kiểm thử phần mềm là tìm ra lỗi chƣa đƣợc phát hiện, tìm một cách sớm nhất và đảm bảo rằng lỗi sẽ đƣợc sửa. Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhƣng tiết kiệm đƣợc thời gian, công sức và chi phí. Phương pháp kiểm thử Có 2 phƣơng pháp kiểm thử chính là: Kiểm thử tĩnh và kiểm thử động 1.
Kiểm thử tĩnh Là phƣơng pháp kiểm thử phần mềm đòi hỏi duyệt lại các yêu cầu và các đặc tả bằng tay thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chƣơng trình. Kiểu kiểm thử này thƣờng đƣợc sử dụng bởi chuyên gia thiết kế ngƣời mà viết mã lệnh một mình. 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.
Kiểm thử động Là phƣơng pháp thử phần mềm thông qua việc dùng máy chạy chƣơng trình để điều tra trạng thái tác động của chƣơng trình. Đó là kiểm thử dựa trên ca kiểm thử xác định bằng sự thực hiện của đối tƣợng kiểm thử hay chạy các chƣơng trình. 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 kiểm thử Unit – Unit Test, kiểm thử tích hợp – Intergration Test, kiểm thử hệ thống – System Test và kiểm thử chấp nhận – Acceptance Test. Các chiến lược kiểm thử Ba trong số những chiến lƣợc kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám. Kiểm thử hộp đen Một trong những chiến lƣợc kiểm thử quan trọng là kiểm thử hộp đen, hƣớng dữ liệu, hay hƣớng vào/ra.
Kiểm thử hộp đen xem chƣơng trình nhƣ là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cấu trúc bên trong của chƣơng trình. Thay vào đó, tập trung vào tìm các trƣờng hợp mà chƣơng trình không thực hiện theo đặc tả của nó. Theo hƣớng tiếp cận này, dữ liệu kiểm thử đƣợc lấy chỉ từ các đặc tả.
Kiểm thử dựa trên đặc tả tập chung vào kiểm thử tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, nhân viên kiểm thử nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tƣợng kiểm thử. Mức kiểm thử này thƣờng yêu cầu các ca kiểm thử để triệt để đƣợc cung cấp cho nhân viên kiểm thử mà khi đó nó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã đƣợc xác định trong ca kiểm thử đó không. Kiểm thử dựa trên đặc tả là cần thiết, nhƣng không đủ để ngăn chặn những rủi ro chắc chắn.
Ƣu, nhƣợc điểm: Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và nhân viên kiểm thử chỉ rất đơn giản tâm niệm là: Một mã lệnh phải có lỗi, sử dụng nguyên tắc “Hãy đòi hỏi và bạn sẽ đƣợc nhận”, những nhân viên kiểm thử hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhƣng mặt khác, ngƣời ta cũng nói kiểm thử hộp đen giống nhƣ đi trong bóng tối mà không có 5 đèn bởi vì nhân viên kiểm thử không biết các phần mềm đƣợc kiểm thử đƣợc xây dựng nhƣ thế nào. Đó là lý do mà có nhiều trƣờng hợp là một nhân viên kiểm thử hộp đen viết rất nhiều ca kiểm thử để kiểm thử một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm thử bằng một ca kiểm thử duy nhất, và/hoặc một số phần của chƣơng trình không đƣợc kiểm thử chút nào. Do vậy, kiểm thử hộp đen có ƣu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhƣợc điểm của “thăm dò mù”.
Kiểm thử hộp trắng Là một chiến lƣợc kiểm thử khác, trái ngƣợc hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hƣớng logic cho phép bạn khảo sát cấu trúc bên trong của chƣơng trình. Chiến lƣợc này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chƣơng trình. Nhân viên kiểm thử sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chƣơng trình (và cả mã lệnh thực hiện chúng). Phƣơng pháp kiểm thử hộp trắng cũng có thể đƣợc sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà đƣợc tạo cùng với các phƣơng pháp kiểm thử hộp đen.
Điều này cho phép các nhóm phần mềm khảo sát các phần một hệ thống ít khi đƣợc kiểm thử và đảm bảo rằng những điểm chức năng quan trọng nhất đã đƣợc kiểm thử. Kiểm thử hộp xám Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử nhƣng là kiểm thử ở mức ngƣời sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống nhƣ một chiếc 6 hộp xám, bởi vì đầu vào và đầu ra rõ ràng ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống đƣợc kiểm thử. Sự khác biệt này đặc biệt quan trọng khi quản lý tích hợp giữa 2 mô – đun mã lệnh đƣợc viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là đƣợc đƣa ra để kiểm thử.
Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định. Kiểm thử hộp xám kết hợp kiểm thử hộp đen và kiểm thử hộp trắng. Kỹ thuật này xem xét tác động ngƣời dùng cuối, kiến thức kỹ thuật của hệ thống cụ thể và môi trƣờng vận hành. Kỹ thuật này đánh giá thiết kế ứng dụng trong ngữ cảnh tƣơng tác giữa các thành phần của hệ thống.
Kỹ thuật kiểm thử hộp xám là cần thiết nhằm kiểm thử hiệu quả các ứng dụng web, bởi vì các ứng dụng web thƣờng bao gồm nhiều thành phần phần cứng và phần mềm. Các thành phần này cần phải đƣợc kiểm thử trong ngữ cảnh thiết kế hệ thống để đánh giá tính năng và khả năng tƣơng thích của chúng. Các cấp độ kiểm thử phần mềm Cấp độ kiểm thử phần mềm đƣợc thể hiện ở hình 1. Bốn cấp độ cơ bản của kiểm thử phần mềm 1.
Kiểm thử đơn vị (Unit Test) Một đơn vị (Unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử đƣợc, ví dụ: Các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phƣơng thức (Method). Kiểm thử tích hợp (Integration Test) Kiểm thử tích hợp 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 thành. Trong khi kiểm thử đơn vị kiểm tra các thành phần và Unit riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Kiểm thử hệ thống (System Test) Mục đích của kiểm thử hệ thống là kiểm thử xem 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.
8 Kiểm thử hệ thống kiểm tra tất 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. Kiểm thử hệ thống 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. Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp 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.