Sự khác nhau giữa Unit, Integration và Functional Testing
- Report
Đối với bất kỳ ứng dụng phần mềm nào, cả Unit Test và Integration test thì đều rất quan trọng khi mỗi loại sử dụng các quy trình khác nhau để test các ứng dụng phần mềm. Nhưng một hoặc cả hai không thể thay thế cho kiểm thử chức năng [Functional Testing].
Trong bài viết này, chúng ta sẽ hiểu Unit , Integration và Functional Testing và làm rõ sự khác nhau giữa các hình thức / mức độ kiểm thử.
Đối với người mới bước vào nghề, để dễ hình dung về ba loại test cơ bản chúng ta cùng tìm hiểu với một ví dụ đơn giản: Đối với chức năng của điện thoại di động, các bộ phận chính được yêu cầu kiểm thử là "pin" và "sim card".
Unit testing- Pin đã được kiểm tra về tuổi thọ, công suất của nó và các thông số khác. Thẻ sim được kiểm tra để kích hoạt nó.
Integration Testing- Pin và thẻ sim được tích hợp ví dụ: lắp ráp để khởi động điện thoại di động.
Functional Testing- các chức năng của điện thoại di động được kiểm tra về tính năng của nó về sử dụng pin cũng như thẻ sim.
Bây giờ chúng ta đã thấy những ví dụ về những thật ngữ không chuyên, bây giờ chúng ta lấy một ví dụ về kỹ thuật, trang đăng nhập:
Hầu hết các ứng dụng web yêu cầu người dùng / khách hàng đăng nhập. Chính vì những điều đó, mọi ứng dụng web đã có một trang "Đăng nhập" trang đó có những yếu tố sau:
• Account/Username
• Password
• Login/Sign in Button
Đối với Unit Testing, chúng ta có thể có những Test cases sau:
Độ dài của trường - username và password
Giá trị trường đầu vào nên là hợp lệ
Nút đăng nhập được kích hoạt chỉ sau khi giá trị hợp lệ [Định dạng và chiều dài đúng chuẩn] được nhập vào cả hai trường.
Đối với Integration Testing, chúng ta có thể có những Test cases sau:
Người dùng sẽ nhìn thấy thông báo chào mừng sau khi nhập các giá trị hợp lệ và nhấn nút đăng nhập. Người sử dụng cần được điều hướng đến các trang chào đón, trên trang chủ sau khi nhập nhập hợp lệ và nhấn nút Login.
Bây giờ, sau Unit và Integration testing được thực hiện, chúng ta sẽ xem xét đến test case cho kiểm thử chức năng.
Có rất nhiều trường hợp mà một tester có thể nghĩ và thực hiện kiểm thử. Nhưng một lập trình viên thì không thể cover hết tất cả các trường hợp đó trong khi vừa làm Unit và Integration.
Do đó, có rất nhiều kịch bản vẫn chưa được test thậm chí sau khi tiến hành Unit và Integration testing.
Bây giờ chúng ta sẽ cùng tìm hiểu từng loại một để làm rõ các vấn đề:
Unit Testing[UT]:
Như tên cho thấy, mức độ này liên quan đến việc kiểm thử của một 'đơn vị'. Ở đây đơn vị có thể là một phần nhỏ của ứng dụng cái có thể được kiểm thử; có thể là một chức năng đặc biệt nhỏ nhất, phương pháp, vv..
Phát triển phần mềm là những người viết các trường hợp kiểm thử ở mức độ đơn vị [Unit]. Mục đích ở đây là để phù hợp với yêu cầu và trạng thái mong muốn của đơn vị.
Dưới đây là vài điểm quan trọng trong Unit testing và lợi ích của nó:
• Unit testing được thực hiện trước khi Integration testing bởi các nhà phát triển phần mềm sử dụng các kỹ thuật kiểm thử hộp trắng [white box testing].
• UT không chỉ kiểm tra các trạng thái tích cực , ví dụ: đầu ra chính xác trong trường hợp đầu vào hợp lệ, nhưng cũng có những thất bại xảy ra với đầu vào không hợp lệ.
• Tìm kiếm các vấn đề / lỗi ở giai đoạn đầu là rất hữu ích và nó làm giảm tổng chi phí dự án. Là Đơn vị kiểm tra được thực hiện trước khi hội nhập của mã, các vấn đề phát hiện ở giai đoạn này có thể được giải quyết rất dễ dàng và ảnh hưởng của họ cũng rất ít.
• Một xét nghiệm đơn vị kiểm tra mảnh nhỏ của mã hay các chức năng cá nhân, và các vấn đề / lỗi được tìm thấy trong các trường hợp thử nghiệm độc lập và không ảnh hưởng đến các trường hợp thử nghiệm khác.
• Một lợi thế quan trọng là các trường hợp đơn vị kiểm tra đơn giản hóa và thực hiện thử nghiệm mã dễ dàng hơn. Vì vậy, nó trở nên dễ dàng hơn để giải quyết các vấn đề ở giai đoạn sau quá bởi vì chỉ có sự thay đổi mới nhất trong mã này là để được kiểm tra.
• Kiểm thử đơn vị [UT] tiết kiệm thời gian và chi phí, và nó là tái sử dụng và dễ dàng để duy trì.
Junit [Java framework], PHPUnit [PHP framework], NUnit [.Net framework] etc. là những tool phổ biến được dùng để UT [unit testing] cho các loại ngỗn ngữ khác nhau.
Integration Testing [IT]:
IT kiểm thử tích hợp của các phần khác nhau của hệ thống lại với nhau. Hai phần khác nhau hoặc các module của hệ thống được tích hợp đầu tiên và sau đó IT sẽ được thực hiện.
Mục đích của IT là để kiểm tra chức năng, độ tin cậy và hiệu suất của hệ thống khi tích hợp.
IT được thực hiện trên các module đã được UT [đơn vị kiểm thử] và sau đó IT sẽ xác định xem liệu sự kết hợp của các mô-đun có cho ra output mong muốn hay không.
IT hoặc có thể được thực hiện bằng cách kiểm thử độc lập hoặc do lập trình viên.
Có 3 loại khác nhau của phương pháp kiểm thử tích hợp. Tiếp theo chúng ta sẽ đi vào chi tiết của từng loại một.
a] Big Bang Integration approach:
Trong phương pháp này, tất cả các module hoặc đơn vị [Unit] được tích hợp và kiểm thử trong cùng một thời điểm. Điều này thường được thực hiện khi toàn bộ hệ thống đã sẵn sàng để IT tại một thời điểm duy nhất.
Xin đừng nhầm lẫn phương pháp này với system testing [ST]; phương pháp này chỉ tích hợp các module hoặc đơn vị được kiểm tra mà không phải là toàn bộ hệ thống như được thực hiện trong ST.
Ưu điểm chính của phương pháp Big bang là tất cả mọi thứ đã được tích hợp được test tại một thời điểm. Nhưng nhược điểm chính của phương pháp này là nó khó khăn để xác định lỗi hệ thống [failures].
Ví dụ: Trong hình dưới đây, Unit 1 đến Unit 6 được tích hợp và thử nghiệm bằng cách sử dụng phương pháp Big Bang.
b] Top down approach:
Tích hợp các đơn vị / modules được kiểm tra từ trên xuống dưới theo từng bước.
Đơn vị đầu tiên được test riêng biệt bằng cách viết test STUBS. Sau đó, các level thấp hơn được tích hợp từng cái một cho đến khi level cuối cùng được đặt lại với nhau và test.
Phương pháp Top down là một cách tiếp cận rất cơ bản của việc tích hợp vì nó phù hợp với các hoạt động sẽ diễn ra trong môi trường thực tế.
Mối quan tâm duy nhất với phương pháp này là các chức năng chính sẽ được là kiểm tra ở giai đoạn cuối.
c] Bottom Up approach:
Unit / modules được kiểm tra từ dưới lên cao nhất, từng bước một, cho đến khi tất cả các cấp của các Unit / module được tích hợp và test như là một đơn vị.
Chương trình mô phỏng sẽ được gọi là DRIVERS được sử dụng trong phương pháp này. Nó thì dễ dàng hơn để phát hiện các vấn đề hoặc lỗi ở mức độ thấp hơn.
Nhược điểm chính của phương pháp này là các vấn đề mức độ cao hơn chỉ có thể được xác định vào cuối khi tất cả các đơn vị đã được tích hợp.
Functional testing [FT]:
Kỹ thuật kiểm thử hộp đen [Back box testing technique], nơi mà các chức năng của ứng dụng được kiểm thử để tạo ra output mong muốn dựa vào việc cung cấp đầu vào nhất định được gọi là "kiểm thử chức năng”.
Trong quá trình kiểm thử phần mềm, chúng ta làm điều này bằng cách viết các trường hợp kiểm tra [testcase] theo yêu cầu và theo kịch bản. Đối với bất kỳ chức năng, số lượng các Test case bằng văn bản có thể thay đổi từ một đến nhiều.
Test case cơ bản bao gồm các phần sau đây: • Test Summary
• Prerequisites [if any]
• Test case input steps
• Test data [if any]
• Expected output
• Notes [if any]
"Dựa trên yêu cầu" và "Dựa trên kịch bản dự án" là hai hình thức của kiểm thử chức năng sẽ được thực hiện.
Trong kiểm thử dựa trên yêu cầu của khách hàng, Test case được tạo ra như một phần của yêu cầu và được kiểm thử sao cho phù hợp với yêu cầu đó .Đối với kiểm thử chức năng dựa trên kịch bản dự án, việc kiểm thử này được thực hiện bằng việc nhớtất cả các kịch bản từ góc độ kinh doanh.
Tuy nhiên, nhược điểm chính của kiểm thử chức năng là có thể dư thừa xảy ra trong kiểm thử và khả năng bị thiếu một số lỗi logic.
Vậy Unit , Integration, Functional testing khác nhau như thế nào?
Bây giờ chúng ta có một ý tưởng ngắn gọn của đơn vị, tích hợp và thử nghiệm chức năng, chúng ta hãy nhìn vào sự khác biệt của chúng.
| Định nghĩa và mục đích | Kiểm thử riêng biệt từng đơn vị hoặc từng module | Kiểm thử tích hợp hai hay nhiều đơn vị/modules kết hợp cùng với nhau để hoàn thành nhiệm vụ | Kiểm tra các hành vi của các ứng dụng theo yêu cầu. |
| Mức độ phức tạp | Không hề phức tạp vì nó bao gồm các dòng code nhỏ nhất | Phức tạp hơn một chút so với kiểm thử đơn vị | Phức tạp hơn so với kiểm thử đơn vị và kiểm thử tích hợp |
| Kỹ thuật kiểm thử | Kiểm thử hộp trắng | Kiểm thử hộp trắng, đen và xám | Kiểm thử hộp đen |
| Những điểm cần lưu ý chính | Những đơn vị hoặc module riêng lẻ | Tích hợp các đơn vị hoặc module | Toàn bộ chức năng ứng dụng |
| Lỗi/vấn đề được tìm thấy | Tìm các vấn đề có thể xảy ra thường xuyên trong các module | Tìm các vấn đề có thể xảy ra trong khi tích hợp các module khác nhau | Tìm thấy vấn đề không cho phép một ứng dụng thực hiện các chức năng của nó. Điều này bao gồm một số vấn đề dựa trên kịch bản dựa test. |
| Lọt bug | Không có cơ hội lọt bug | Ít có cơ hội | Nhiều cơ hội lọt issue khi danh sách chức năng phải test luôn là vô hạn. |
Kết luận:
Unit , Integration, Functional testing: Cả ba có tương quan lẫn nhau. Để đạt được việc bao phủ đầy đủ thì phải có kiểm thử đơn vị cho các đường dẫn / dòng code, chức năng và tích hợp để đảm bảo rằng công việc gắn kết với đơn vị.
Hy vọng bài viết này đã đưa cho bạn một ý tưởng rõ ràng về đơn vị, tích hợp và thử nghiệm chức năng và sự khác biệt của chúng, mặc dù có nhiều hơn còn có nhiều hơn những kiểu kiểm thử .
Nguồn dịch: //www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/
Các loại kiểm thử phần mềm – Unit, Integration, Systemtest
Một hoạt động mang tính sống còn trong các dự án sản xuất hoặc gia công phần mềm [PM], đó là kiểm tra [Testing]. Dân làm PM chắc hẳn không ai nghi ngờ vai trò quan trọng của nó, tuy nhiên không phải ai [cả trong ngành và ngoài ngành] cũng hiểu rõ hoạt động này. Bản thân công việc kiểm tra phần mềm [KTPM] cũng là một lĩnh vực hoạt động độc lập và khá "hấp dẫn". Cùng với các dự án gia công sản xuất PM, hiện cũng có khá nhiều dự án mà nội dung công việc chỉ là kiểm tra những PM đã được khách hàng phát triển sẵn.
Mặc dù công việc KTPM không xa lạ song những khái niệm và kỹ thuật lại khá rắc rối. Bài viết này sẽ nhằm cung cấp một cái nhìn tương đối bao quát về lĩnh vực "tưởng cũ nhưng không cũ” này.
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 [xem hình 3], 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.
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ướn
g 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ẽ.
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 tại PC world online
Share this:
Like this:
Related
Tags: tester
This entry was posted on October 13, 2008 at 5:07 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Sự khác nhau giữa Unit Test và Integration Test
Như chúng ta đã biết với một ứng dụng phần mềm được phát triển từ các module khác nhau, mỗi module được kiểm thử đơn vị và sau đó các module được tích hợp để kiểm thử. Hệ thống sẽ trải qua quá trình kiểm thử để xem rằng có đáp ứng được yêu cầu của khách hàng đề ra hay không. Hệ thống phải trải qua ...
Như chúng ta đã biết với một ứng dụng phần mềm được phát triển từ các module khác nhau, mỗi module được kiểm thử đơn vị và sau đó các module được tích hợp để kiểm thử. Hệ thống sẽ trải qua quá trình kiểm thử để xem rằng có đáp ứng được yêu cầu của khách hàng đề ra hay không. Hệ thống phải trải qua kiểm thử chấp nhận của khách hàng hoặc người dùng cuối, đảm bảo phần mềm chạy tốt. Dưới đây là dòng chảy cho quy trình kiểm thử phần mềm:
- UNIT TESTING: là cấp độ kiểm thử phần mềm, nơi các đơn vị / thành phần riêng lẻ của phần mềm được kiểm tra. Mục đích là để xác nhận rằng mỗi đơn vị phần mềm thực hiện như được thiết kế. Một đơn vị là phần nhỏ nhất có thể kiểm thử của bất kỳ phần mềm nào. Nó thường có một hoặc một vài đầu vào và thường là một đầu ra duy nhất. Trong lập trình thủ tục, một đơn vị có thể là một chương trình, chức năng, thủ tục, vv Trong lập trình hướng đối tượng, đơn vị nhỏ nhất là một phương thức, có thể thuộc về một lớp cơ sở / siêu hạng, lớp trừu tượng hoặc lớp dẫn xuất / lớp con.
- INTEGRATION TESTING: là cấp độ kiểm thử phần mềm trong đó các đơn vị riêng lẻ được kết hợp và thử nghiệm dưới dạng một nhóm. Mục đích của cấp độ kiểm tra này là để lộ các lỗi trong sự tương tác giữa các đơn vị tích hợp.
- SYSTEM TESTING: Kiểm tra hệ thống còn được gọi là kiểm tra hộp đen hoặc thử nghiệm chức năng và nó được tiến hành để kiểm tra chức năng tổng thể của hệ thống mà sẽ hoạt động như mong đợi hoặc được chỉ định trong tài liệu yêu cầu chức năng.
- ACCEPTANCE TESTING: Khi hệ thống đã sẵn sàng sử dụng, hệ thống sẽ trải qua thử nghiệm bởi người dùng cuối hoặc ứng dụng khách để xác minh rằng nó đáp ứng được kỳ vọng của người dùng và tất cả các chức năng mong muốn như được chỉ định trong tài liệu SRS [Software Requirements Specification].
| Kiểm thử tích hợp là tích hợp tất cả các module vào ứng dụng và kiểm tra chúng như một nhóm để xem chúng có hoạt động như mong đợi hay không | Kiểm thử đơn vị là để kiểm tra từng phần của module riêng lẻ và quan sát rằng các bộ phận riêng lẻ đang hoạt động như mong đợi. |
| Kiểm thử tích hợp còn được gọi là kiểm thử hộp đen, chúng ta không động đến mã code mà chỉ tập trung vào đầu vào đã cho và đầu ra mong đợi. | Kiểm thử đơn vị còn được gọi là kiểm thử hộp trắng vì nó đòi hỏi kiến thức về mã code và luồng điều khiển trong chương trình. |
| Integration Testing được thực hiện sau khi kiểm thử đơn vị nhưng trước khi kiểm thử hệ thống. | Unit testing có thể được thực hiện bất cứ lúc nào nhưng luôn luôn thực hiện trước khi kiểm thử tích hợp. |
| Các lỗi trong kiểm thử tích hợp được phát hiện sau khi các module được tích hợp để xây dựng hệ thống tổng thể. | Unit Testing chỉ kiểm tra chức năng của các module ở cấp độ đơn vị và không thể bắt được các lỗi mức tích hợp hoặc bất kỳ vấn đề nào trong toàn hệ thống. |
| Chủ yếu tập trung vào tích hợp các module. | Chủ yếu tập trung vào chức năng của một module riêng lẻ. |
| Integration Testing được thực hiện bởi người kiểm thử[Tester]. | Unit Testing thường được thực hiện bởi các developers. |
| Lỗi phát hiện thường khó khăn khi thử nghiệm tích hợp. | Lỗi phát hiện thường đơn giản khi thử nghiệm đơn vị. |
| Kiểm thử tích hợp bảo trì là khá tốn kém vì nó đòi hỏi phải thiết lập môi trường riêng biệt. | Chi phí bảo trì kiểm thử đơn vị là rất ít vì nó được duy trì và mức đơn vị. |
| Kiểm thử tích hợp giúp xác minh rằng mã code hoạt động như mong đợi với các phụ thuộc bên ngoài. | Kiểm thử đơn vị không xác minh xem mã code có hoạt động như mong đợi với các phụ thuộc bên ngoài hay không. |
Hi vọng những kiến thức trên sẽ giúp ích cho bạn trong quá trình tìm hiểu về kiểm thử phần mềm.