Kiểm thử phần mềm là khái niệm rộng hơn thường được nói tới như vấn đề kiểm chứng và xác nhận (V&V).
Kiểm chứng nói tới một tập các hành động đảm bảo rằng phần mềm cài đặt đúng cho một chức năng đặc biệt. Xác nhận nói tới một tập các hoạt động khác đảm bảo rằng phần mềm đã được xây dựng lại theo yêu cầu của khách hàng. Bochum phát biểu điều này theo cách khác:
– Kiểm chứng: “Chúng ta có làm ra sản phẩm đúng không?”
– Xác nhận: “Chúng ta có làm ra đúng sản phẩm không?”
Định nghĩa về V&V bao quát nhiều hoạt động ta đã tham khảo tới như việc đảm bảo chất lượng phần mềm (SQA). Việc kiểm thử cung cấp một thành lũy cuối cùng để có thể thẩm định về chất lượng, lỗi có thể được phát hiện ra một cách thực tế hơn.
Các phương pháp kỹ nghệ phần mềm cung cấp nền tảng để xây dựng nên chất lượng. Các phương pháp phân tích, thiết kế và thực hiện (mã hoá) làm nâng cao chất lượng bằng cách đưa ra những kỹ thuật thống nhất và kết quả dự kiến được.
Các cuộc họp xét duyệt kỹ thuật chính thức giúp đảm bảo chất lượng của sản phẩm được tạo ra như hệ quả của từng bước kỹ nghệ phần mềm. Qua toàn bộ tiến trình này, việc đo đạc và kiểm soát được áp dụng cho mọi phần tử của cấu hình phần mềm.
Tuy nhiên không nên coi kiểm thử như một tấm lưới an toàn. Như người ta vẫn nói, “Bạn không thể kiểm thử được chất lượng. Nếu nó không sẵn có trước khi bạn bắt đầu kiểm thử, thì nó sẽ chẳng có khi bạn kết thúc kiểm thử”.
Chất lượng được tổ hợp vào trong phần mềm trong toàn bộ tiến trình kỹ nghệ phần mềm. Việc áp dụng đúng các phương pháp và công cụ, các cuộc họp xét duyệt kỹ thuật chính thức và việc quản lý vững chắc cùng cách đo đạc, tất cả dẫn tới chất lượng được xác nhận trong khi kiểm thử.
Miller kể lại việc kiểm thử phần mềm về đảm bảo chất lượng bằng cách nói rằng: “Động cơ nền tảng của việc kiểm thử chương trình là để xác nhận chất lượng phần mềm, bằng những phương pháp có thể được áp dụng một cách kinh tế và hiệu quả cho cả các hệ thống quy mô lớn và nhỏ”.
Điều quan trọng là cần lưu ý rằng việc kiểm chứng và xác nhận kiểm thử phần mềm hợp lệ hoá, bao gồm một phạm vi rộng các hoạt động đảm bảo chất lượng phần mềm có chứa cả họp xét duyệt chính thức, kiểm toán chất lượng và cấu hình, điều phối hiệu năng, mô phòng, nghiên cứu khả thi, xét duyệt tài liệu, xét duyệt cơ sở dữ liệu, phân tích thuật toán, kiểm thử phát triển, kiểm thử chất lượng, kiểm thử cài đặt. Mặc dù việc kiểm thử đóng một vai trò cực kỳ quan trọng trong V&V, nhưng nhiều hoạt động khác cũng vẫn còn cần tới.
| Yếu tố kỹ thuật | Quản lý chất lượng | Đo lường và kiểm tra |
|---|---|---|
| Phương pháp thiết kế phần mềm (Cách thức tiếp cận để thiết kế và xây dựng phần mềm, ví dụ: lập trình hướng đối tượng, phát triển theo mô hình thác nước…) |
Họp xét duyệt kỹ thuật chính thức (Quá trình đánh giá chính thức về thiết kế và code để đảm bảo chất lượng và tuân thủ các tiêu chuẩn) |
Đo đạc (Thu thập số liệu về các khía cạnh của phần mềm, ví dụ: số dòng code, độ phức tạp, hiệu năng…) |
| Tiêu chuẩn và thủ tục (Quy định và hướng dẫn về cách thức phát triển và kiểm tra phần mềm) |
Chất lượng (Mức độ đáp ứng của phần mềm với các yêu cầu và mong đợi) |
Kiểm thử (Quá trình thực thi phần mềm để tìm ra lỗi và đảm bảo nó hoạt động đúng) |
| SCM và SQA (Quản lý cấu hình phần mềm (SCM) và Đảm bảo chất lượng phần mềm (SQA) là các hoạt động quản lý để kiểm soát chất lượng trong suốt vòng đời phát triển phần mềm) |
Giải thích:
– Phương pháp thiết kế phần mềm: Là cách tiếp cận và kỹ thuật được sử dụng để thiết kế và xây dựng phần mềm. Lựa chọn phương pháp thiết kế phù hợp ảnh hưởng đến chất lượng, khả năng bảo trì và khả năng mở rộng của phần mềm.
– Họp xét duyệt kỹ thuật chính thức: Là một phần của quản lý chất lượng, trong đó các chuyên gia kỹ thuật xem xét thiết kế, mã nguồn và tài liệu kỹ thuật để phát hiện lỗi, đảm bảo tuân thủ tiêu chuẩn và cải thiện chất lượng sản phẩm.
– Đo đạc: Là quá trình thu thập dữ liệu định lượng về các thuộc tính của phần mềm, ví dụ như kích thước code, độ phức tạp, hiệu suất, độ tin cậy. Dữ liệu này được sử dụng để đánh giá chất lượng phần mềm và theo dõi tiến độ phát triển.
– Tiêu chuẩn và thủ tục: Là tập hợp các quy tắc, hướng dẫn và quy trình được xác định trước để đảm bảo tính nhất quán, chất lượng và hiệu quả trong quá trình phát triển phần mềm.
– Chất lượng: Là mức độ mà phần mềm đáp ứng các yêu cầu và mong đợi của người dùng, bao gồm tính năng, độ tin cậy, hiệu suất, khả năng sử dụng, bảo trì và bảo mật.
– Kiểm thử: Là quá trình thực thi phần mềm với mục đích tìm ra lỗi và đảm bảo rằng nó hoạt động đúng như mong đợi. Kiểm thử là một phần quan trọng của đảm bảo chất lượng phần mềm.
– SCM (Software Configuration Management): Quản lý cấu hình phần mềm là quy trình quản lý các thay đổi đối với phần mềm trong suốt vòng đời phát triển. Nó bao gồm việc theo dõi các phiên bản, kiểm soát các thay đổi và đảm bảo tính toàn vẹn của phần mềm.
– SQA (Software Quality Assurance): Đảm bảo chất lượng phần mềm là một tập hợp các hoạt động có hệ thống nhằm đảm bảo rằng phần mềm được phát triển đáp ứng các tiêu chuẩn chất lượng đã được xác định. SQA bao gồm các hoạt động như lập kế hoạch chất lượng, kiểm tra chất lượng và cải tiến quy trình.
Tóm lại, bảng này mô tả các yếu tố quan trọng cần được xem xét để đạt được chất lượng phần mềm, bao gồm cả các khía cạnh kỹ thuật, quản lý và đo lường. Việc kết hợp hiệu quả các yếu tố này sẽ giúp tạo ra phần mềm chất lượng cao, đáp ứng nhu cầu của người dùng và mang lại giá trị cho doanh nghiệp.
1. Tổ chức việc kiểm thử phần mềm.
Với mọi dự án phần mềm, có một mâu thuẫn cố hữu về lợi ích xuất hiện ngay khi việc kiểm thử bắt đầu. Người đã xây phần mềm bây giờ được yêu cầu kiểm thử phần mềm. Điều này bản thân nó dường như vô hại; vì sau cùng, ai biết được chương trình kỹ hơn là người làm ra nó?
Nhưng không may, cũng những người phát triển này, lại có mối quan tâm chứng minh rằng chương trình là không có lỗi, rằng nó làm việc đúng theo yêu cầu khách hàng, rằng nó sẽ được hoàn tất theo lịch biểu và trong phạm vi ngân sách. Một trong những mối quan tâm này lại làm giảm bớt việc tìm ra lỗi trong toàn bộ tiến trình kiểm thử.
Theo quan điểm tâm lý, việc phân tích và thiết kế phần mềm (cùng với mã hoá) là nhiệm vụ xây dựng. Người kỹ sư phần mềm tạo ra một chương trình máy tính, tài liệu về nó và các cấu trúc dữ liệu có liên quan. Giống như bất kỳ người xây dựng nào, người kỹ sư phần mềm tự hào về dinh thự đã được xây dựng, và nhìn ngờ vực vào bất kỳ ai định làm sập đổ nó.
Khi việc kiểm thử bắt đầu, có một nỗ lực tinh vi, dứt khoát để “đập vỡ” cái mà người kỹ sư phần mềm đã xây dựng. Theo quan điểm của người xây dựng, việc kiểm thử có thể được coi như (về tâm lý) có tính phá hoại. Cho nên người xây dựng dè dặt đề cập tới việc kiểm thử thiết kế, và thực hiện sẽ chứng tỏ rằng chương trình làm việc, thay vì phát hiện lỗi. Điều không may lỗi sẽ hiện hữu và nếu người kỹ sư phần mềm không tìm ra chúng thì khách hàng sẽ tìm ra.
Thường có một số nhận thức sai có thể được suy diễn sai lạc từ thảo luận trên:
(1) Người phát triển phần mềm không nên tiến hành kiểm thử;
(2) Phần mềm nên được “tung qua tường” cho người lạ làm việc kiểm thử một cách tàn bạo;
(3) Người kiểm thử nên tham gia vào dự án chỉ khi bước kiểm thử sắp sửa bắt đầu.
Các phát biểu này đều không đúng. Người phát triển phần mềm bao giờ cũng có trách nhiệm với việc kiểm thử riêng các đơn vị (mô đun) chương trình, để đảm bảo rằng mỗi mô đun thực hiện đúng chức năng nó đã được thiết kế. Trong nhiều trường hợp, người phát triển cũng tiến hành cả kiểm thử tích hợp – bước kiểm thử dẫn đến việc xây dựng và kiểm thử toàn bộ cấu trúc chương trình. Chỉ sau khi kiến trúc phần mềm hoàn tất, thì nhóm kiểm thử độc lập mới tham gia vào.
Vai trò của nhóm kiểm thử độc lập (ITG) là loại bỏ vấn đề cố hữu liên quan tới việc để người xây dựng kiểm thử những cái anh ta đã xây dựng ra. Việc kiểm thử độc lập loại bỏ xung khắc lợi ích nếu không có nhóm đó thì có thể hiện hữu. Cuối cùng nhân sự trong nhóm kiểm thử độc lập được trả tiền để tìm ra lỗi.
Tuy nhiên, người phát triển phần mềm không chuyển giao chương trình cho ITG rồi bỏ đi. Người phát triển và ITG làm việc chặt chẽ trong toàn bộ dự án phần mềm để đảm bảo rằng những kiểm thử kỹ lưỡng sẽ được tiến hành. Trong khi tiến hành kiểm thử, người phát triển phải có sẵn để sửa chữa lỗi đã phát hiện ra.
ITG là một phần của nhóm dự án phát triển phần mềm theo nghĩa là nó tham dự trong tiến trình đặc tả và vẫn còn tham dự (lập kế hoạch và xác định các thủ tục kiểm thử) trong toàn bộ dự án lớn. Tuy nhiên, trong nhiều trường hợp ITG báo cáo cho tổ chức đảm bảo chất lượng phần mềm. Do đó, đạt tới một mức độ độc lập có thể không có được, nếu nó là một phần của tổ chức phát triển phần mềm.
2. Chiến lược kiểm thử phần mềm.
Tiến trình kỹ nghệ phần mềm có thể được xét theo vòng xoắn ốc, Spiral model. Ban đầu, kỹ nghệ phần mềm xác định vai trò của phần mềm và đưa tới việc phân tích yêu cầu phần mềm, chỗ thiết lập nên lĩnh vực thông tin, chức năng, hành vi, hiệu năng, ràng buộc và tiêu chuẩn hợp lệ cho phần mềm. Đi vào trong vòng xoắn ốc, chúng ta tới thiết kế và cuối cùng tới mã hoá. Để xây dựng phần mềm máy tính, chúng ta đi dọc theo đường xoắn ốc, mỗi lần mức độ trừu tượng lại giảm dần.
Một chiến lược cho kiểm thử phần mềm cũng có thể xem xét bằng cách đi theo đường xoắn ốc ra ngoài. Việc kiểm thử đơn vị bắt đầu tại tâm xoáy của xoắn ốc, và tập trung vào các đơn vị của phần mềm khi được cài đặt trong chương trình gốc. Việc kiểm thử tiến triển bằng cách đi ra theo đường xoắn ốc tới kiểm thử tích hợp, nơi tập trung vào thiết kế và việc xây dựng kiến trúc phần mềm.
Đi thêm một vòng xoáy nữa trên đường xoắn ốc chúng ta gặp kiểm thử hợp lệ, nơi các yêu cầu được thiết lập như một phần của việc phân tích yêu cầu phần mềm, được hợp lệ hoá theo phần mềm đã được xây dựng. Cuối cùng, chúng ta tới kiểm thử hệ thống, nơi phần mềm và các phần tử hệ thống khác được kiểm thử như một toàn bộ. Để kiểm thử phần mềm máy tính, chúng ta theo đường xoáy mở rộng dần phạm vi kiểm thử một lần.
Xem xét tiến trình này theo quan điểm thủ tục, vì việc kiểm thử bên trong ngữ cảnh kỹ nghệ phần mềm thực tại, là một chuỗi gồm ba bước được thực hiện tuần tự nhau. Ban đầu, việc kiểm thử tập trung vào từng mô đun riêng biệt, đảm bảo rằng nó vận hành đúng đắn như một đơn vị. Do đó, mới có tên kiểm thử đơn vị.
Kiểm thử đơn vị dùng rất nhiều các kỹ thuật kiểm thử hộp trắng, thử các đường đặc biệt trong cấu trúc điều khiển của một mô đun, để đảm bảo bao quát đầy đủ và phát hiện ra lỗi tối đa. Tiếp đó, các mô đun phải được lắp ghép hay tích hợp lại để tạo nên bộ trình phần mềm hoàn chỉnh.
Việc kiểm thử tích hợp để cập tới các vấn đề có liên quan tới các vấn đề kiểm chứng và xây dựng chương trình. Các kỹ thuật thiết kế kiểm thử hộp đen chiếm đại đa số trong việc tích hợp, mặc dù một số giới hạn các kiểm thử hộp trắng cũng có thể được dùng để đảm bảo bao quát đa số các đường điều khiển.
Sau khi phần mềm đã được tích hợp (được xây dựng), một tập các phép kiểm thử cao cấp sẽ được tiến hành. Các tiêu chuẩn hợp lệ (được thiết lập trong phân tích yêu cầu) cũng phải được kiểm thử. Việc kiểm thử hợp lệ đưa ra sự đảm bảo cuối cùng rằng, phần mềm đáp ứng cho tất cả các yêu cầu chức năng, hành vi và sự hoàn thiện. Các kỹ thuật kiểm thử hộp đen được dùng chủ yếu trong việc hợp lệ hoá này.
Bước kiểm thử cấp cao cuối cùng rơi ra ngoài phạm vi của kỹ nghệ phần mềm, và rơi vào ngữ cảnh rộng hơn của kỹ nghệ hệ thống máy tính. Phần mềm, một khi được hợp lệ hoá, phải được tổ hợp với các phần tử hệ thống khác (như phần cứng, con người, cơ sở dữ liệu). Kiểm thử hệ thống kiểm chứng lại rằng tất cả các yếu tố có khớp đúng với nhau không, và chức năng cũng như độ hoàn thiện hệ thống toàn bộ đã đạt được.
3. Tiêu chuẩn hoàn thành kiểm thử.
Câu hỏi cổ điển nảy sinh mỗi khi có việc thảo luận về kiểm thử phần mềm là: Khi nào chúng ta thực hiện xong kiểm thử? Làm sao ta biết rằng chúng ta đã kiểm thử đủ? Đáng buồn là không có câu trả lời xác định cho câu hỏi này, nhưng có một số hướng dẫn kinh nghiệm cho câu hỏi này.
Một đáp ứng cho câu hỏi trên là: Chúng ta chẳng bao giờ hoàn thành việc kiểm thử, gánh nặng đơn giản chuyển từ chúng ta (người phát triển) sang khách hàng. Mỗi khi khách hàng/người dùng thực hiện một chương trình máy tính, thì chương trình này lại được kiểm thử trên một tập dữ liệu mới.
Sự kiện này nhấn mạnh tầm quan trọng của các hoạt động đảm bảo chất lượng phần mềm khác. Một đáp ứng khác là: Chúng ta hoàn thành việc kiểm thử khi hết thời gian hay hết tiền. Mặc dù số ít người thực hành sẽ biện minh cho những đáp ứng trên, người kỹ sư phần mềm vẫn cần những tiêu chuẩn chặt chẽ hơn, để xác định khi nào việc kiểm thử đủ được tiến hành.
Musa và Ackerman gợi ý một đáp ứng dựa trên tiêu chuẩn thống kê: “Không, chúng ta không thể tuyệt đối chắc chắn rằng phần mềm sẽ không bao giờ hỏng, nhưng theo mô hình thống kê đúng về lý thuyết và hợp lệ về thực nghiệm, thì chúng ta đã hoàn thành kiểm thử đủ để nói với sự tin tưởng tới 95% rằng xác suất của 1000 giờ vận hành CPU không hỏng, trong một môi trường được xác định về xác suất là ít nhất 0.995″.
Dùng mô hình hóa thống kê và lý thuyết độ tin cậy phần mềm, các mô hình về hỏng hóc phần mềm (được phát hiện trong khi kiểm thử) xem như một hàm của thời gian thực hiện có thể được xây dựng ra. Một bản của mô hình sai hỏng, được gọi là mô hình thực hiện – thời gian Poisson logarit.
Dùng mối quan hệ trong phương trình, người kiếm thử có thể tiên đoán việc loại bỏ lỗi khi việc kiểm thử tiến triển. Nếu dữ liệu thực tại được thu thập trong khi kiểm thử, và mô hình thực hiện – thời gian theo logarit Poisson là xấp xỉ gần nhau với số điểm dữ liệu thì mô hình này, có thể được dùng để dự đoán thời gian kiểm thử toàn bộ cần để đạt tới mật độ hỏng thấp chấp nhận được.
Bằng cách thu thập các độ đo trong khi kiểm thử phần mềm, và dùng các mô hình về độ tin cậy phần mềm hiện có, có thể phát triển những hướng dẫn có nghĩa đế trả lời câu hỏi: Khi nào thì chúng ta hoàn thành việc kiểm thử? Còn ít tranh luận về việc có phải làm công việc công nghệ thêm nữa hay không, trước khi các quy tắc định tính cho kiểm thử có thể xác định, những cách tiếp cận kinh nghiệm hiện đang tồn tại được coi là tốt hơn đáng kể so với trực giác thô.
Tác giả: Thạc Bình Cường
Bạn đang xem bài viết:
Kiểm chứng và xác nhận trong kiểm thử phần mềm
Link https://vnlibs.com/cong-nghe/kiem-chung-va-xac-nhan-trong-kiem-thu-phan-mem.html
