Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu

Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu. Bạn đang chuẩn bị làm bài báo cáo thực tập nghề nghiệp, hay bạn đang làm đồ án tốt nghiệp, nhưng các bạn lại chưa biết lựa chọn đề tài nào cho phù hợp với trường hợp của bạn, giờ đây các bạn không còn phải lo lắng về vấn đề đó nữa, vì dưới đây Dịch Vụ Hỗ Trợ Viết Luận Văn sẽ chia sẻ đến các bạn sinh viên một bài Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu các bạn có thể tham khảo thử nhé.

MỞ ĐẦU

Phần mềm đóng một vai trò quan trọng trong mọi lĩnh vực của cuộc sống. Trong đó, kiểm thử phần mềm là một trong những quy trình đảm bảo phần mềm hoạt động chính xác theo yêu cầu của thiết kế. Do đó, việc nắm vững kiến thức và rèn luyện các kỹ năng về kiểm thử phần mềm là một tiêu chí quan trọng đối với sinh viên ngành Công nghệ Thông tin.

Quy trình kiểm thử phần mềm được chia thành nhiều giai đoạn và nhiều hoạt động khác nhau tùy thuộc vào phần mềm được phát triển dựa trên các quy trình khác nhau. Dù phần mềm được phát triển theo quy trình nào thì các bước kiểm thử đều có những giai đoạn giống nhau gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, v.v. Các hoạt động của kiểm thử được tiến hành từ những giai đoạn đầu của quá trình phát triển phần mềm. Căn cứ vào bản đặc tả yêu cầu phần mềm, người ta có thể xây dựng các ca kiểm thử và dựa vào đó khi triển khai phần mềm đến đâu thì hoạt động kiểm thử phần mềm được thực hiện ngay đến đó để kịp thời phát hiện lỗi trong sản phẩm phần mềm. Khóa luận này, với tên đề tài Phương pháp tính toán các ca kiểm thử dựa trên biểu đồ luồng dữ liệu”, lần lượt trình bày một số khái niệm cơ bản về phần mềm, kiểm thử phần mềm, các bước xác định ca kiểm thử từ biểu đồ luồng dữ liệu, và sử dụng công cụ Ranorex Studio trong kiểm thử phần mềm. Nội dung của khóa luận được trình bày theo cấu trúc dưới đây.  “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Chương 1: Các khái niệm cơ bản

Chương này cung cấp các kiến thức cơ bản trong lĩnh vực phát triển phần mềm và kiểm thử phần mềm như các khái niệm về phần mềm, lỗi phần mềm, quy trình xử lí lỗi phần mềm và khái niệm cơ bản trong kiểm thử phần mềm.

Chương 2: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu

Chương này trình bày các bước phân tích biểu đồ luồng dữ liệu, trên cơ sở đó xây dựng ca kiểm thử và các thành phần liên quan.

Chương 3: Thực nghiệm với công cụ Ranorex Studio

Ranorex Studio là một công cụ mạnh trong kiểm thử phần mềm cho ứng dụng Window Forms. Chương này trình bày các bước thực hiện kiểm thử các ứng dụng với công cụ Ranorex.

Kết luận:

Phần này khóa luận đưa ra những kết quả, hạn chế và hướng phát triển tiếp theo của đề tài trong tương lai.

Chương này khóa luận trình bày những thuật ngữ và khái niệm cơ bản về phần mềm, lỗi phần mềm, xử lý lỗi phần mềm và kiểm thử phần mềm.

1.1 Khái niệm cơ bản về phần mềm “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Theo IEEE (1991): Phần mềm là các chương trình máy tính kết với các dữ liệu hoặc các tài liệu hướng dẫn, đặc tả, v.v. thường gồm 4 phần được mô tả dưới đây:

• Chương trình máy tính: Thành phần này giúp cho máy tính thực thi các ứng dụng được yêu cầu.
• Quy trình: Là thành phần xác định trình tự và kế hoạch trong đó các chương trình được thực hiện, phương pháp sử dụng và những người chịu trách nhiệm cho các hoạt động của kế hoạch.
• Các tài liệu: Có rất nhiều những tài liệu cần thiết với nhân viên phát triển, người sử dụng và nhân viên bảo trì như: tài liệu thiết kế, tài liệu hướng dẫn sử dụng, tài liệu hướng dẫn bảo trì.
• Dữ liệu: Dữ liệu bao gồm tham số, mã nguồn và các danh sách thích ứng của phần mềm dành riêng cho người dùng cụ thể là dành cho hoạt động phần mềm.

1.1.1 Vòng đời phần mềm

Mô hình vòng đời phát triển phần mềm là một loạt các pha (giai đoạn) mà phần mềm trải qua từ bắt đầu phát triển đến khi phần mềm bị loại bỏ hoàn toàn. Mô hình vòng đời phát triển phần mềm thường gồm những pha sau:

• Pha yêu cầu: là pha đầu tiên trong quá trình xây dựng phần mềm, nhằm xác định yêu các yêu cầu phải có trong phần mềm giữa nhóm phát triển và khách hàng.
• Pha phân tích: Pha này phân tích các yêu cầu của khách hàng được mô tả chi tiết kết quả đầu ra, quá trình phát triển phần mềm dưới dạng “tài liệu đặc tả”. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”
• Pha thiết kế: Pha này căn cứ vào tài liệu đặc tả để mô tả chi tiết cách phần mềm thực hiện các công việc cụ thể.
• Pha lập trình: Pha này là quá trình thực hiện viết chương trình bằng một ngôn ngữ cụ thể.
• Pha kiểm thử hệ thống: Pha này hoạt động sau khi giai đoạn lập trình kết thúc. Mục đích chính là phát hiện lỗi phần mềm càng nhiều càng tốt để đạt được chất lượng phần mềm ở mức chấp nhận được sau khi chỉnh sửa.
• Pha bảo trì và loại bỏ: Pha này bảo trì sửa lỗi có thể còn xuất hiện trong chương trình sau khi cài đặt cho khách hàng và cập nhật sửa đổi phần mềm theo ý khách hàng hoặc thích nghi với điều kiện ràng buộc để nâng cao hiệu quả làm việc. Nếu chi phí bảo trì quá lớn có thể dẫn đến loại bỏ phần mềm.

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

Phần mềm được phát triển dựa trên các mô hình để xác định các hoạt động và quy trình theo trình tự nhất định. Một số mô hình phát triển phần mềm tiêu biểu sau:

Mô hình thác nước

Mô hình thác nước hay còn gọi là mô hình vòng đời truyền thống do tác giả Royce đề xuất năm 1970. Mô hình này yêu cầu tiếp cận một cách hệ thống, tuần tự và chặt chẽ đối với việc phát triển phần mềm, bắt đầu ở mức hệ thống và tiến dần xuống phân tích, thiết kế, mã hóa, kiểm thử, và bảo trì (Hình 1-1) [2].

Mô hình chữ V

Ngoài phát triển phần mềm theo mô hình thác nước, thì mô hình chữ V cũng khá phổ biến trong các dự án phát triển phần mềm của các công ty.

Mô hình chữ V được thực hiện từ trái qua phải, mô tả dãy các hoạt động và kiểm thử cơ bản. Mô hình này nêu bật các mức kiểm thử liên quan đến các pha phát triển phần mềm tương ứng từng giai đoạn.

Đặc điểm phát triển phần mềm theo mô hình chữ V được trình bày trong

Bảng 1-2 sau:

Ưu điểm

• Quá trình phát triển và quy trình quản lý có tính tổ chức và hệ thống
• Hoạt động tốt cho các dự án có quy mô vừa và nhỏ.
• Kiểm tra bắt đầu từ khi bắt đầu phát triển vì vậy sự mơ hồ được xác định ngay từ đầu.
• Dễ dàng quản lý vì mỗi giai đoạn có các mục tiêu và mục tiêu được xác định rõ ràng.

Nhược điểm

• Không thích hợp cho các dự án lớn và phức tạp
• Không phù hợp nếu các yêu cầu thường xuyên thay đổi.
• Không có phần mềm làm việc được sản xuất ở giai đoạn trung gian.
• Không có điều khoản cho việc phân tích rủi ro nên có sự không chắc chắn và có tính rủi ro.

1.2 Chất lượng và đảm bảo chất lượng phần mềm “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

1.2.1 Chất lượng phần mềm

Theo IEEE (1991):

1. Chất lượng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hoặc quy trình đáp ứng được đặc tả yêu cầu.
2. Chất lượng phần mềm là mức độ mà hệ thống, thành phần hệ thống hoặc quy trình, đáp ứng được mong đợi của khách hàng hoặc người sử dụng.

Theo Pressman: Chất lượng phần mềm là phần mềm phải đáp ứng được ba yêu cầu sau:

• Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra của sản phẩm.
• Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.
• Các đặc tính cần được đáp ứng trong quá trình phát triển cho dù không được nói đến rõ ràng trong hợp đồng.

1.2.2 Đảm bảo chất lượng phần mềm 

Để đánh giá được chất lượng một phần mềm ngay cả khi nó đang hoạt động là rất khó, những người khác nhau có thể đánh giá về nó khác nhau.

Theo tác giả Daniel Galin, việc đảm bảo chất lượng phần mềm là một tập hợp các hành động cần thiết được lên kế hoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách.

Tuy nhiên, khi đánh giá phần mềm người ta thường đưa ra một số tiêu chí để nói đến chất lượng tổng thể của phần mềm bao gồm:

• Đạt được các mục tiêu thiết kế đề ra của tổ chức: thực hiện được các chức năng thiết kế cho tổ chức.
• Chi phí vận hành là chấp nhận được: chi phí không quá cao so với lợi ích mang lại.
• Đáp ứng được các chuẩn mực của một hệ thống tin: đưa ra thông tin kịp thời, phù hợp với cho tính sẵn sàng hay kết quả đưa ra đúng chuẩn với mẫu bảng biểu, số chỉ tiêu, v.v. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”
• Sản phẩm tạo ra có giá trị xác đáng: thông tin đưa ra có ý nghĩa thiết thực đối với chức năng và quản lý, góp phần nâng cao chất lượng sản phẩm và dịch vụ của tổ chức.
• Bảo trì được: dễ bảo trì, bảo trì không quá tốn kém.
• Khả dụng: dễ học và dễ sử dụng.
• Mềm dẻo – có khả năng làm thích nghi được: có thể kiểm tra, mở rộng ứng dụng và phát triển tiếp.
• Có tính khả chuyển: có thể chuyển từ môi trường làm việc này sang môi trường làm việc khác.

1.3 Lỗi phần mềm

Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó. Lỗi phần mềm được chia thành 3 dạng:

• Lỗi sai: sản phẩm phần mềm được xây dựng khác với đặc tả.
• Lỗi thiếu: các yêu cầu cầu sản phẩm phần mềm đã có trong đặc tả nhưng lại không có trong sản phẩm thực tế.
• Lỗi thừa: phần mềm trong thực tế có những tính năng không có trong tài liệu đặc tả.

1.3.1 Nguyên nhân gây lỗi phần mềm: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả nguyên nhân chủ quan và các nguyên nhân khách quan. Sau đây là một số nguyên nhân chủ yếu gây ra lỗi phần mềm:

• Lỗi trong giao tiếp giữa khách hàng và nhóm phát triển: nhưng lỗi này thường xuất hiện ở đầu dự án do hiểu lầm trong giao tiếp giữa nhóm phát triển và khách hàng khi trình bày bằng lời nói và tài liệu không thống nhất.
• Các lỗi thiết kế lôgíc: lỗi xảy ra trong quá trình các chuyên gia thiết kế hệ thống, kỹ sư phần mềm, các nhà phân tích bỏ sót hay áp dụng thuật toán sai dẫn đến xây dựng phần mềm sai theo lôgíc.
• Các lỗi lập trình: có rất nhiều lý do dẫn đến việc các lập trình viên gây ra các lỗi lập trình. Ví dụ như: sai sót trong ngôn ngữ lập trình, hiểu sai các tài liệu thiết kế, v.v.
• Các lỗi về tài liệu: các lỗi về tài liệu là vấn đề của nhóm phát triển và bảo trì khi có những sai sót trong các tài liệu liên quan.

1.3.2 Chi phí cho việc sửa lỗi phần mềm

Việc sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của vòng đời phần mềm. Tuy nhiên công việc này càng thực hiện sớm càng tốt vì càng về sau của giai đoạn sau của phần mềm thì chi phí, thời gian cho việc tìm và sửa lỗi càng tăng. Theo tài liệu của Boehm, chi phí tìm và sửa lỗi phần mềm tăng theo hàm mũ trong biểu đồ sau:

1.3.3 Quy trình xử lý lỗi phần mềm

Trước khi giới thiệu về quy trình xử lý lỗi phần mềm, khóa luận trình bày về các trạng tháng có thể có của lỗi.

Trong đó, các thành phần được giải thích dưới đây.

• New: Lỗi mới.
• Assigned: Lỗi đã được gán cho nhân viên phát triển.
• Resolved: Lỗi đã được xử lý.
• Confirmed: Lỗi cần được chứng thực.
• Canceled: Lỗi được xác định không phải là lỗi, lỗi bỏ qua được
• Next: Lỗi không thuộc phạm vi của dự án hoặc sẽ được xử lý trong giai đoạn khác của dự án
• Accepted: Các lỗi có thể chấp nhận được.
• Closed: Trạng thái đóng, lỗi đã được sửa thành công. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Mỗi nhóm phát triển phần mềm sẽ sử dụng một công cụ quản lý lỗi riêng, nhưng gần như phần đa đều có một quy trình xử lý lỗi phần mềm chung. Theo đó, quy trình xử lý lỗi có thể bao gồm 6 bước chính:

• Bước 1: Phát hiện phần mềm có lỗi.
• Bước 2: Đưa lỗi lên hệ thống quản lý lỗi.
• Bước 3: Gán lỗi cho nhân viên phát triển.
• Bước 4: Xử lý lỗi.
• Bước 5: Kiểm thử lại.
• Bước 6: Đóng lỗi.

1.4 Các thuật ngữ và khái niệm kiểm thử phần mềm

Tăng năng suất kiểm thử là một nhu cầu thiết yếu để tăng chất lượng phần mềm. Vì thế nghiên cứu để phát triển các kỹ thuật, công cụ kiểm thử hữu hiệu là đóng góp thiết thực nhất để tăng cường chất lượng sản phẩm phần mềm.

1.4.1 Các thuật ngữ “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Kỹ thuật kiểm thử phần mềm đã phát triển và tiến hóa hàng mấy chục năm nên các thuật ngữ trong các tài liệu khác nhau thường không thống nhất và thiếu tương thích. Các thuật ngữ được trình bày trong khóa luận này dựa vào các chuẩn được viện phát triển IEEE.

Lỗi (Error): Lỗi là những vấn đề con người mắc phải trong quá trình phát triển các sản phẩm phần mềm. Khi lập trình viên phạm lỗi trong lập trình, các lỗi đó là bug( con bọ). Lỗi có thể phát tán. Lỗi là nguyên nhân dẫn đến sai.

Sai (Fault): Sai là kết quả của lỗi. Sai về nhiệm vụ khi xuất hiện khi vào sai thông tin hoặc sai về bỏ quên xuất hiện khi không vào đủ thông tin. Loại sai thứ hai khó phát hiện và sửa hơn loại sai thứ nhất.

Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi, nó chỉ xuất hiện dưới dạng có thể chạy được mà thông thường là mã nguồn.

Sự cố (Incident): Khi thất bại xuất hiện, nó có thể hiện thị hoặc không, tức là rõ ràng hoặc không rõ ràng đối với những người dùng hoặc kiểm thử viên. Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùng hoặc kiểm thử viên về sự xuất hiện của thất bại này.

Kiểm chứng và thẩm định: Kiểm chứng và thẩm định là hai khái niệm hay sử dụng nhầm lẫn, nhưng thực ra chúng có ý nghĩa khác nhau. Kiểm chứng là quá trình đảm bảo rằng một số sản phẩm phần mềm thỏa mãn các đặc tả. Còn thẩm định là quá trình để đảm bảo rằng sản phẩm đáp ứng được yêu cầu của người dùng.

1.4.2 Khái niệm kiểm thử phần mềm

Cùng với phát triển phần mềm, kiểm thử phần mềm cũng có nhiều định nghĩa khác nhau được phát biểu bởi nhiều tổ chức hay cá nhân khác nhau. Khóa luận sẽ trình bày một số định nghĩa nổi bật: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Theo Myer (1979, Chương 10): “Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra lỗi.” Theo như định nghĩa này, quá trình kiểm thử bao gồm tất cả các hoạt động từ kiểm tra mã nguồn đến chạy thử chương trình.

Theo IEEE Std 610.12 (IEEE, 1990): Kiểm thử phần mềm là quá trình phân tích các yếu tố phần mềm để phát hiện những khác biệt giữa chương trình với các điều kiện yêu cầu và đánh giá các đặc điểm của các yếu tố phần mềm.

Theo Daniell Galin: Kiểm thử phần mềm là một quá trình được tiến hành bởi một nhóm chuyên viên kiểm thử, trong đó một đơn vị phần mềm, một nhóm các đơn vị được tích hợp, hoặc cả gọi phần mềm được kiểm tra bằng cách chạy chương trình trên máy tính. Tất cả các bước kiểm tra liền được tiến hành theo các quy trình kiểm thử và được thông qua ca kiểm thử.

1.4.3 Mục tiêu của kiểm thử phần mềm

Cũng giống như các sản phẩm máy móc và các hệ thống vật lý, mục đích của kiểm thử phần mềm là để đảm bảo hệ thống phần mềm có thể làm việc tốt như mong muốn khi chúng được đem ra thị trường tới tay khách hàng và người sử dụng. Cách thường dùng để đưa ra những kiểm chứng về chất lượng cho sản phẩm là đưa sản phẩm vào “chạy thử” hay được kiểm tra trong phòng thí nghiệm trước khi phân phối sản phẩm ra thị trường. Trong ngành Công Nghệ Phần Mềm, các sản phẩm phần mềm được kiểm tra, chạy thử được gọi chung là kiểm thử phần mềm.

Theo Daniel Galin:

Mục tiêu trực tiếp: Kiểm thử phần mềm là phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm thử. Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đến khi đảm bảo các yêu cầu chất lượng phần mềm. Kiểm thử là hoạt động cần thiết và hiệu quả trong kế hoạch và ngân quỹ giới hạn.

Mục tiêu gián tiếp: Kiểm thử phần mềm nhằm biên dịch bản ghi các lỗi để nhằm mục đích phòng ngừa và khắc phục lỗi.

CÓ THỂ BẠN QUAN TÂM ĐẾN DỊCH VỤ:

===>>> Viết Thuê Đồ Án Tốt Nghiệp

1.5 Nguyên tắc kiểm thử phần mềm “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau:

Quy tắc 1: Kiểm thử đưa ra 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 phần mềm không có lỗi. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn cò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 chúng ta phải tìm được càng nhiều lỗi càng tốt.

Quy tắc 2: Kiểm thử cạn kiệt là không thể

Nguyên tắc này nói rằng kiểm tra mọi thứ trong phần mềm một cách trọn vẹn 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ừ phi nó chỉ bao gồm í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 chúng ta 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.

Quy tắc 3: Kiểm thử càng sớm càng tốt

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến.

Quy 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ả.

Quy 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.

Quy tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

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.

Quy 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.6 Quy trình kiểm thử phần mềm

Tùy vào từng tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro của phần mềm mà quy trình kiểm thử phần mềm có thể gồm nhiều bước khác nhau. Nhưng nhìn chung mọi quy trình kiểm thử đều có những bước cơ bản (Hình 1-7) dưới đây:

Lập kế hoạch kiểm thử: Nhiệm vụ quan trọng trong phần lập kế hoạch kiểm thử là xác định được các yếu tố sau:

• Các giai đoạn kiểm thử áp dụng cho dự án
• Các phương pháp kiểm thử
• Các công cụ kiểm thử
• Nguồn lực kiểm thử
• Tài nguyên môi trường kiểm thử, bao gồm các tài nguyên phần cứng và phần mềm
• Mốc bàn giao các tài liệu kiểm thử

Chuẩn bị kiểm thử: Nhiệm vụ chiến lược của giai đoạn này là:

• Tìm hiểu nghiệp vụ của hệ thống phải kiểm thử.
• Xây dựng kịch bản kiểm thử, phát triển các thủ tục và các kịch bản kiểm thử tự động (trong trường hợp kiểm thử tự động).
• Chuẩn bị dữ liệu kiểm thử. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”
• Xem xét phê duyệt các tài liệu kiểm thử.

Thực thi kiểm thử:

• Thực hiện kiểm thử dựa trên các kịch bản kiểm thử,test script, thủ tục, dữ liệu có sẵn từ bước chuẩn bị kiểm thử.
• Tham gia quá trình quản lý lỗi: báo lỗi, sửa lỗi.

Báo cáo và phân tích dữ liệu kiểm thử:

• Báo cáo kiểm thử.
• Phân tích nguyên nhân và đề xuất các hành động khắc phục.

1.7 Các phương pháp phân tích kiểm thử

Có 2 phương pháp phân tích kiểm thử chính là: phân tích tĩnh và phân tích động.

1.7.1 Phân tích tĩnh

Việc phân tích tĩnh được tiến hành dựa trên việc khảo sát các tài liệu được xây dựng trong quá trình phát triển sản phẩm như tài liệu đặc tả, hồ sơ và mã nguồn phần mềm. Công việc này không động đến việc thực thi chương trình mà chỉ duyệt, lý giải về tất cả các hành vi có thể của chương trình khi được thực thi. Tối ưu hóa các chương trình dịch là các ví dụ về phân tích tĩnh [1].

1.7.2 Phân tích động

Phân tích động là công việc thực thi chương trình để phát hiện những thất bại có thể có của chương trình, hoặc quan sát cá tính chất nào đó về hành vi và hiệu quả. Vì gần như không thể thực thi chương trình trên tất cả các dữ liệu đầu vào có thể, ta chỉ chọn tập con các dữ liệu đầu vào để thực thi.

1.8 Các kỹ thuật kiểm thử “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Ba trong số những kĩ thuật 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.

1.8.1 Kỹ thuật kiểm thử hộp đen

Một trong những kỹ thuật kiểm thử quan trọng trong kiểm thử phần mềm là kiểm thử hộp đen hay còn gọi là kiểm thử hướng dữ liệu, hay kiểm thử 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 là hoàn toàn không quan tâm về cách vận hành 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ác đặc tả của nó. Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả. Kỹ thuật kiểm thử hộp đen được mô tả trong hình

Mục đích của kiểm thử hộp đen

Kiểm thử hộp đen luôn đóng vai trò quan trọng trong quá trình kiểm thử, mục đích của kiểm thử hộp đen là:

• Chức năng sai hoặc thiếu.
• Lỗi giao diện
• Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu từ bên ngoài
• Lỗi hiệu năng
• Lỗi khởi tạo hoặc kết thúc hệ thống Các phương pháp kiểm thử hộp đen

Một số phương pháp tiếp cận chủ yếu dành cho các phương pháp kiểm thử hộp đen bao gồm:

• Phân lớp tương đương – Equivalence partitioning.
• Phân tích giá trị biên – Boundary value analysis.
• Kiểm thử mọi cặp – All-pairs testing.
• Kiểm thử fuzz – Fuzz testing.
• Kiểm thử dựa trên mô hình – Model-based testing.
• Ma trận dấu vết – Traceability matrix.
• Kiểm thử thăm dò – Exploratory testing.
• Kiểm thử dựa trên đặc tả – Specification-base testing.

Kiểm thử hộp đen dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên 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 kiểm thử viên mà khi đó 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ử đó hay 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. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Ưu và 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à kiểm thử viên 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 kiểm thử viên 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ư là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, hoặc một số phần của chương trình không được kiểm tra 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ù”.

1.8.2 Kỹ thuật kiểm thử hộp trắng

Kỹ thuật kiểm thử hộp trắng hay còn gọi là kiểm thử cấu trúc là một kĩ thuật kiểm thử 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 dựa vào giải thuật cụ thể, vào cấu trúc 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 đó, kiểm thử viên cần phải có kỹ năng kiến thức nhất định để có thể hiểu chi tiết về đoạn mã cần kiểm thử. Kiểm thử hộp trắng thường tốn rất nhiều thời gian và chi phí nếu mức độ kiểm thử được nâng lên ở cấp kiểm thử tích hợp hay kiểm thử hệ thống.

Các phương pháp kiểm thử hộp trắng

Kiểm thử dòng điều khiển (control flow testing) và kiểm thử dòng dữ liệu (data flow testing) được coi là hai phương pháp tiếp cận chủ yếu trong kĩ thuật kiểm thử hộp trắng.

Kiểm thử dòng điều khiển: là phương pháp tập trung kiểm thử thuật toán chức năng tương ứng với các đường đi (dòng điều khiển) của chương trình. Tuy nhiên chỉ một phương pháp này là chưa đủ để phát hiện tất cả các lỗi tiềm ẩn trong chương trình.

Kiểm thử dòng dữ liệu: là phương pháp cho phép ta phát hiện những lỗi thường xuất hiện tại các biến được sử dụng trong chương trình, đơn vị chương trình.

Bằng cách áp dụng cả hai phương pháp trên sẽ giúp chúng ta đảm bảo về chất lượng của sản phẩm phần mềm tốt hơn.

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

Kiểm thử hộp trắng giúp chúng ta kiểm tra được toàn bộ mã nguồn của chương trình, phát hiện lỗi tại chỗ và có thể áp dụng được các công cụ giúp kiểm thử tự động. Tuy nhiên, kiểm thử hộp trắng yêu cầu kiểm thử viên phải am hiểu về cấu trúc mã lệnh chương trình. Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém. Bên cạnh đó cũng có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi, không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp.

1.8.3 Kiểm thử hộp xám “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Kiểm thử hộp xám là kỹ thuật kiểm thử có sự kết hợp giữa kiểm thử hộp đen và kiểm thử hộp trắng. Trong kiểm thử hộp đen, kiểm thử viên 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 nó, còn trong kiểm thử hộp trắng thì kiểm thử viên biết được cấu trúc bên trong của chương trình. Trong kiểm thử hộ xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, kiểm thử viên 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ế ca kiểm thử, nhưng khi kiểm thử thì chỉ kiểm thử như là người dùng cuối hoặc là ở mức hộp đen.

1.9 Các cấp độ kiểm thử

Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.

1.9.1 Kiểm thử đơn vị

Một đơn vị chương trình 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) hay phương thức (Method) đều có thể được xem là đơn vị.

Mỗi đơn vị chương trình đượ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 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 kiểm thử đơn vị 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 đó. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Kiểm thử đơn vị 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 lập trình và xuyên suốt chu kỳ phát triển phần mềm. Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và mã nguồn 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 đơn vị) 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 đơn vị đề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 đơn vị. 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 thử và quét hết đơn vị đò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, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), 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 ca kiểm thử và kịch bản kiểm thử này nên được giữ lại để tái sử dụng.

1.9.2 Kiểm thử tích hợp

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à đơn vị 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.

Hai mục tiêu chính của kiểm thử tích hợp:

• Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị.
• Tích hợp các đơn vị đơ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 thử ở mức hệ thống (System Test).

Trong kiểm thử đơn vị, 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 đơn vị. Có một số phép kiểm thử đơn giản trên giao tiếp giữa đơn vị 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 đơn vị chỉ thật sự được kiểm tra đầy đủ khi các đơn vị 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ệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức đơn vị đã được sửa chữa. Một số người hiểu sai rằng đơn vị một khi đã qua giai đoạn kiểm thử đơn vị với các giao tiếp giả lập thì không cần phải thực kiểm thử tích hợp nữa. Thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

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

Có 4 loại kiểm thử trong kiểm thử tích hợp:

• Kiểm thử cấu trúc (Structure Test): Tương tự kiểm thử hộp trắng, kiểm thử cấu trúc 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 và 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 câu lệnh và nhánh bên trong.
• Kiểm thử chức năng (Functional Test): Tương tự kiểm thử hộp đen, kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, mà 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 thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống.
• Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.

1.9.3 Kiểm thử hệ thống “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Mục đích kiểm thử hệ thống là kiểm thử 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.

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. 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 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 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 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. Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để 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 kiểm thử hệ thống.

Sau khi hoàn thành kiểm thử tích hợp, 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ập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu.

Kiểm thử hệ thống 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” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn kiểm thử hệ thống, 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 (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 kiểm thử hệ thống 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. Bản thân kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

• Kiểm thử 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 thử hiệu năng (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, v.v.
• Kiểm thử 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 thử chức năng

Việc kiểm thử chức năng chú trọng đến hai phần chính là kiểm thử giao diện người dùng (User interface) và kiểm thử luồng nghiệp vụ (Bussiness Flow Testing).

Kiểm thử giao diện người dùng: là việc kiểm tra các tương tác của người dùng với phần mềm. Mục tiêu của kiểm thử giao diện là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sử dụng các chức năng của hệ thống một cách thích hợp. Ngoài ra, kiểm thử giao diện còn để đảm bảo rằng các đối tượng trên giao diện giống như thiết kế và phù hợp với tổ chức hoặc chuyên ngành.

Mục đích kiểm thử

Kiểm tra việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gốm màn hình đến màn hình, trường đến trường và sử dụng các phương pháp truy cập(phím tabs, di chuột, tổ hợp phím).

Kiểm thử luồng nghiệp vụ: Mục đích của kiểm thử luồng nghiệp vụ là kiểm tra các yêu cầu chức năng và nghiệp vụ của hệ thống bao gồm các hoạt động để kiểm tra tính đúng đắn của dữ liệu, quy trình, báo cáo và việc thực hiện đúng những quy tắc nghiệp vụ. Kiểu kiểm thử này dựa vào kỹ thuật kiểm thử hộp đen, tức là kiểm tra ứng dụng và các xử lý bên trong ứng dụng bằng cách tương tác với ứng dụng thông qua giao diện người sử dụng và phân tích các kết quả hoặc đầu ra. Bảng sau liệt kê một số gợi ý đối với mỗi ứng dụng: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

• Mục đích kiểm thử
• Đảm bảo mục tiêu kiểm thử đúng đắn của chức năng, bao gồm dữ liệu đầu vào, xử lý dữ liệu và dữ liệu nhận được. Kiểm thử chức năng đảm bảo các yêu cầu sau:
• Nhập dữ liệu hợp lệ thì chương trình phải cho nhập
• Luồng nghiệp vụ đúng
• Quá trình xử lý dữ liệu và kết quả đầu ra phải đúng
• Phục hồi được dữ liệu

Kiểm thử hiệu năng

• Mục đích của kiểm thử hiệu năng là kiểm tra các yêu cầu về hiệu năng có đạt được hay không.
• Kiểm tra các biểu hiện về hiệu năng cho các giao dịch hoặc chức năng nghiệp vụ theo những điều kiện sau:
• Mục đích kiểm thử
• Khối lượng công việc bình thường đã biết trước.
• Khối lượng công việc xấu đã biết trước.
• Sử dụng các thủ tục cho kiểm thử luồng nghiệp vụ:
• Chỉnh sửa file dữ liệu để tăng số lượng các giao dịch
• Cách thực hiện hoặc scripts để tăng số tương tác xảy ra trong mỗi giao dịch.

Scripts phải được chạy trên một máy (trường hợp tốt nhất để đánh giá người dùng đơn lẻ, giao dịch đơn lẻ) và phải lặp lại trên nhiều máy trạm.

Nhiều giao dịch hoặc nhiều người dùng: Thực hiện thành công test script không có lỗi và trong thời gian chấp nhận được.

Kiểm thử bảo mật

Kiểm thử an toàn thông tin tập trung vào hai lĩnh vực bảo mật chính: Bảo mật ở mức ứng dụng và Bảo mật ở mức hệ thống.

Bảo mật mức ứng dụng đảm bảo rằng, dựa trên bảo mật đã yêu cầu, người dùng bị hạn chế sử dụng một số chức năng hoặc tình huống sử dụng, hoặc bị hạn chế trong giới hạn dữ liệu phù hợp với họ. Ví dụ, người dùng có thể được phép nhập dữ liệu để tạo tài khoản nhưng chỉ có người quản lý có thể xóa chúng. Nếu là bảo mật ở mức dữ liệu, việc kiểm thử đảm bảo rằng “người dùng nhóm 1” có thể nhìn thấy các thông tin khách hàng, bao gồm dữ liệu tài chính, tuy nhiên “người dùng nhóm 2” chỉ nhìn thấy các thông tin chung chung cho cùng một khách hàng.

Ghi chú “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

• Truy cập vào hệ thống phải được xem xét hoặc thảo luận với quản trị hệ thống hoặc quản trị mạng, có thể không cần nếu nó là chức năng của quản trị mạng hoặc quản trị hệ thống.

Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng.

Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tùy 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 áp dụng những loại kiểm thử nào.

1.9.4 Kiểm thử chấp nhận sản phẩm

Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận, đượ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 kiểm thử chấp nhận 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 (và trả tiền thanh toán hợp đồng).

Kiểm thử chấp nhận 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 thử của kiểm thử hệ thống và kiểm thử chấp nhận 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 thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với kiểm thử Alpha, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, 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 kiểm thử Beta, phần mềm sẽ được gửi tới cho người dùng để kiểm thử 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 phát triển phần mềm thì kết quả kiểm thử chấp nhận 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. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử 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 thử 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… “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

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

1.9.5 Một số cấp độ kiểm thử khác

Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:

Kiểm thử hồi quy – Regression Testing: là “Sự kiểm tra lại có lựa chọn của một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ra những hậu quả không mong muốn,v.v”. Trên thực tế, quan niệm này là chỉ ra rằng phần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại. Theo Beizer định nghĩa đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên là sự thỏa hiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần thực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.

Kiểm thử tính đúng – Correctness Testing: Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu của kiểm thử. Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách hoạt động đúng đắn từ cách hoạt động sai lầm. Kiểm thử viên có thể biết hoặc không biết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ luồng điều khiển, luồng dữ liệu, v.v. Do đó, hoặc là quan điểm hộp trắng, hoặc là quan điểm hộp đen có thể được thực hiện trong kiểm thử phần mềm.

1.10 Kỹ thuật xác định các yếu tố trong ca kiểm thử “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

1.10.1 Ca kiểm thử

Ca kiểm thử là tập các điều kiện đầu vào, điều kiện thực hiện và kết quả mong đợi được phát triển, được viết cho một mục đích nào đó nhằm xác định sự tuân thủ đối với đặc tả yêu cầu phần mềm của chương trình. Một ca kiểm thử bao gồm các thành phần trong hình 1-16 sau:

Trong đó:

• Test Case ID: là ô đánh số thứ tự của ca kiểm thử nhằm mục đích lần lượt, tránh bỏ sót ca kiểm thử.
• Test Case Description: là ô miêu tả nội dung của ca kiểm thử sắp tiến hành.
• Pre-Requisites: là ô miêu tả diễn các tiền điều kiện cần thiết để tiến hành ca kiểm thử.
• Steps: là số đánh số thứ tự các bước thực hiện ca kiểm thử, để sau khi kiểm thử có thể tìm thấy lỗi chi tiết hơn ở từng mục.
• Execution Steps: là ô miêu tả chi tiết từng hành động thực hiện ca kiểm thử của ca kiểm thử.
• Expected Results: là ô thể hiện các kết quả mong muốn đầu ra, như là output của các dữ liệu đầu vào.
• Actual Results: là ô phản ánh kết quả đúng sau khi thực hiện từng bước của ca kiểm thử.
• Result: kết quả tổng quan của ca kiểm thử, thường biểu diễn là Pass/Fail, thành công hoặc thất bại so với mong muốn đầu ra của ca kiểm thử.
• Note: là ô để kiểm thử viên ghi chú những thông tin cần lưu ý trong quá trình thực hiện ca kiểm thử.

1.10.2 Một số kỹ thuật xác định ca kiểm thử “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Kỹ thuật phần vùng tương đương

Định nghĩa: Phân vùng tương đương là phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Thiết kế ca kiểm thử cho phân vùng tương đương dựa trên sự đánh giá về các vùng tương đương với một điều kiện vào. Vùng tương đương biểu thị một tập cho các trạng thái hợp lệ hay không hợp lệ đối với điều kiện vào. Thiết kế ca kiểm thử bằng phân vùng tương đương tiến hành theo hai 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ử.

Xác định các lớp tương đương: Có hai kiểu lớp tương đương được xác định: lớp tương đương hợp lệ mô tả các đầu vào và lớp tương đương không hợp lệ mô tả. Để xác định các lớp tương đương được chính xác có thể áp dụng các nguyên tắc sau đây.

• Quy tắc 1: Nếu trạng thái đầu vào định rõ giới hạn của các giá trị, thì xác định một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ.
• Quy tắc 2: Nếu một trạng thái đầu vào xác định số giá trị, xác định một lớp tương đương hợp lệ và hai lớp tương đương bất hợp lệ.
• Quy tắc 3: Nếu 1 trạng thái đầu vào chỉ định tập các giá trị đầu vào và chương trình sử dụng mỗi giá trị là khác nhau, xác định một lớp tương đương hợp lệ cho mỗi loại và một lớp tương đương không hợp lệ.
• Quy tắc 4: Nếu 1 trạng thái đầu vào chỉ định một tình huống “chắc chắn – must be”, xác định một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ.

Xác định các bước trên, bước thứ kiểm thử.

ca kiểm thử: Với các lớp tương đương xác định được ở hai là sử dụng các lớp tương đương đó để xác định các ca này như sau: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

1. Gán 1 số duy nhất cho mỗi lớp tương đương.
2. Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi (hợp nhất thành) các ca kiểm thử, viết 1 ca kiểm thử mới bao phủ càng nhiều các lớp tương đương đó chưa được bao phủ càng tốt.
3. Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương không hợp lệ, viết một ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương đương không hợp lệ chưa được bao phủ.
4. Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là vì các kiểm tra đầu vào không đúng nào đó che giấu hoặc thay thế các kiểm tra đầu vào không đúng khác.

Ưu điểm: Vì mỗi vùng tương đương ta chỉ cần kiểm thử trên các phần tử đại diện nên số lượng ca kiểm thử được giảm đi khá nhiều nhờ đó mà thời gian thực hiện kiểm thử 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ị thiếu 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 khi phần lớn các lỗi được tìm thấy lúc kiểm tra giá trị ở biên của các phân vùng thì chúng ta nên tìm hiểu thêm một kỹ thuật nữa là Phân tích giá trị biên.

Phân tích giá trị biên

Đây là một trong những kỹ thuật kiểm thử phần mềm, trong đó các ca kiểm thử được thiết kế bao gồm các giá trị tại các biên. Nếu dữ liệu đầu vào được sử dụng là trong giới hạn giá trị biên, nó được cho là Positive testing. Nếu dữ liệu đầu vào được sử dụng là ngoài giới hạn giá trị biên, nó được cho là Negative testing. Mục tiêu là lựa chọn các ca kiểm thử để thực thi giá trị biên.

Phân tích giá trị biên yêu cầu kiểm thử viên có chuyên môn sâu và kinh nghiệm cao. Tuy nhiên, có một số quy tắc chung sau:

1. Nếu một trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các ca kiểm thử cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vào không hợp lệ cho các trường hợp vừa ra ngoài phạm vi.
2. Nếu một trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểm thử cho con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên, một giá trị dưới những giá trị này.
3. Sử dụng quy tắc số 1 cho mỗi trạng thái đầu vào.
4. Sử dụng nguyên tắc số 2 cho mỗi trạng thái đầu ra. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”
5. Nếu đầu vào hay đầu ra của một chương trình là tập được sắp thứ tự ( ví dụ, một file tuần tự hay một danh sách định tuyến hay một bảng) tập trung chú ý vào các phần tử đầu tiên và cuối cùng của tập hợp.
6. Sử dụng sự khéo léo của bạn để tìm các điều kiện biên.

Các ca kiểm thử 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

Nhưng nếu bạn muốn kiểm tra sâu hơn thì bạn cũng có thể lựa chọn theo quy tắc:

• Giá trị biên nhỏ nhất – 1
• Giá trị biên nhỏ nhất
• Giá trị biên nhỏ nhất + 1
• Giá trị biên lớn nhất – 1
• Giá trị biên lớn nhất
• Giá trị biên lớn nhất + 1

Phân tích các giá trị biên là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở hai khía cạnh:

1. Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong một lớp tương đương là điển hình, mà nó yêu cầu là một hay nhiều phần tử được lựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra.
2. Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp tương đương đầu ra).

Bảng quyết định

Kĩ thuật bảng quyết định tập trung vào tính lôgíc và các ràng buộc của hệ thống. Bảng quyết định là cách tốt nhất để đối ứng với sự kết hợp của các điều kiện. Lý do cho điều này: “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

• Bảng quyết định cung cấp một cách có hệ thống các quy tắc kinh doanh phức tạp, rất hữu ích cho cả lập trình viên và kiểm thử viên.
• Bảng quyết định có thể được sử dụng trong thiết kế ca kiểm thử, vì chúng giúp kiểm thử viên tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.
• Kiểm thử kết hợp có thể là một thách thức vì số lượng các kết hợp điều kiện có thể là rất lớn. Kiểm tra tất cả các kết hợp điều kiện có thể là không thực tế nếu không phải là không thể. Chúng ta phải hài lòng với việc chỉ kiểm thử một phần nhỏ trong số tất cả các kết hợp điều kiện, nhưng lựa chọn kết hợp điều kiện nào để kiểm thử và bỏ qua cũng là vấn đề rất quan trọng. Nếu như không có các kết hợp điều kiện được lựa chọn một cách có hệ thống, một tập tùy ý được sử dụng thì bảng quyết định cũng có thể dẫn đến kiểm thử không hiệu quả. Bảng quyết định có dạng mẫu trong hình 1-17 sau:

Các bước tạo “Bảng quyết định”:

• Liệt kê tất cả các nguyên nhân trong bảng quyết định.
• Tính tổng số lượng kết hợp giữa các nguyên nhân.
• Điền vào các cột với tất cả kết hợp có thể có.
• Rút bớt số lượng các phép kết hợp thừa.
• Kiểm tra các phép kết hợp có bao phủ hết mọi trường hợp không.
• Bổ sung kết quả vào bảng quyết định.

Để xác định số ca kiểm thử xảy, Bảng quyết định dựa vào nguyên nhân và số lượng giá trị lựa chọn đầu vào để tính toán:

=[số lượng giá trị của nguyên nhân]*…*[Số lượng giá trị nguyên nhân n]

Ưu điểm của kỹ thuật này là chúng ta có thể kiểm tra sự kết hợp của các điều kiện mà có thể đã bị thiếu sót và không được thử nghiệm đồng thời có thể tìm thấy khiếm khuyết. Tuy nhiên nếu có quá nhiều kết hợp các điều kiện, sử dụng kỹ thuật này có thể không khả quan hoặc không hợp lý để kiểm tra từng kết hợp điều kiện. Đừng cho rằng tất cả các kết hợp cần phải được kiểm tra, nên ưu tiên kiểm tra những kết hợp quan trọng nhất. Có đầy đủ các kết hợp điều kiện sẽ giúp chúng ta quyết định được kết hợp điều kiện nào cần kiểm tra và chưa cần kiểm tra ở thời điểm nhất định nào đó. “Đồ án: Xây dựng ca kiểm thử từ biểu đồ luồng dữ liệu”

Dịch Vụ Viết Luận Văn 24/7 Chuyên cung cấp dịch vụ làm luận văn thạc sĩ, báo cáo tốt nghiệp, khóa luận tốt nghiệp, chuyên đề tốt nghiệp và Làm Tiểu Luận Môn luôn luôn uy tín hàng đầu. Dịch Vụ Viết Luận Văn 24/7 luôn đặt lợi ích của các bạn học viên là ưu tiên hàng đầu. Rất mong được hỗ trợ các bạn học viên khi làm bài tốt nghiệp. Hãy liên hệ ngay Dịch Vụ Viết Luận Văn qua Website:  https://hotrovietluanvan.com/ – Hoặc Gmail: hotrovietluanvan24@gmail.com