Xây Dựng Các Tình Huống Kiểm Thử (Test Case)

- Thiết lập các yêu cầu về độ tin cậy bằng cách sử dụng các độ đo thích hợp cho từng loại.

2) Đo độ tin cậy: theo một vài cách đo như sau

- Xác suất thất bại tính theo đòi hỏi.

- Tỷ lệ xuất hiện thất bại

- Thời gian trung bình giữa hai thất bại kế tiếp nhau. MTBF=MTTF+MTTR

Trong đó: MTBF: Thời gian trung bình giữa hai thất bại kế tiếp nhau MTTF: Thời gian trung bình của thất bại

MTTR: Thời gian trung bình để sửa chữa thất bại

- Độ đo mức sẵn sàng hoạt động của hệ thống MLA = MTTF/(MTTF+MTTR)*100%

3) Thử nghiệm tĩnh

Có thể bạn quan tâm!

Xem toàn bộ 305 trang tài liệu này.

Mục tiêu chủ yếu của thử nghiệm tĩnh là xác định độ tin cậy của phần mềm chứ không phải là xác định các hư hỏng phần mềm. Quá trình thử nghiệm tĩnh liên quan đến 4 bước sau:

- Xác định độ đo thao tác phần mềm. Độ đo thao tác là một mẫu sử dụng phần mềm và xác định mẫu đó liên quan đến việc phát hiện các lớp thông tin vào của chương trình và ước tính xác suất của chúng.

- Chọn ra hoặc sinh ra một tập các dữ liệu thử tương ứng với độ đo đó.

- Áp dụng các trường hợp thử chương trình, ghi lại độ dài thời gian thi hành giữa mỗi cặp thất bại quan sát được. Thích hợp hơn là dùng thời gian thô, với đơn vị thời gian thích hợp cho độ đo mức tin cậy.

- Tính toán độ đo mức tin cậy sau một số đáng kể (về mặt thống kê) các thất bại đã quan sát được.

4) An toàn phần mềm

Có những hệ thống mà thất bại của nó có thể gây ra một mối đe dọa tính mạng con người. Thí dụ về hệ thống an toàn sinh mệnh như vậy là hệ thống điều khiển máy bay. Có hai lớp phần mềm an toàn sinh mệnh.

- Các phần mềm an toàn sinh mệnh sơ cấp: các phần mềm lồng nhúng trong một hệ phần cứng dùng để điều khiển quá trình khác mà sự làm việc sai sót của nó có thể trực tiếp gây ra thương vong hoặc phá hủy môi trường sống của con người.

- Các phần mềm an toàn sinh mệnh thứ cấp: các phần mềm có thể gián tiếp gây ra thương vong. Thí dụ hệ thống phần mềm trợ giúp thiết kế kỹ thuật, hệ thống cơ sở dữ liệu y tế liên quan đến các chất độc bảng A.

5) Thử nghiệm khiếm khuyết

Thử nghiệm chương trình có hai mục đích: thứ nhất là chỉ ra rằng hệ thống là phù hợp với các đặc tả của nó, thứ hai là thực hành hệ thống theo một cách sao cho các khuyêt tật được phơi ra. Các thử nghiệm với mục đích thứ nhất chính là các thẩm định, nó là các thử nghiệm để chấp nhận. Các thử nghiệm cho mục đích thứ hai lại khác hẳn: thử nghiệm thành công nhất là thử nghiệm phơi ra được nhiều khuyết tật nhất.

Các thử nghiệm có thể được phát triển song song với việc thiết kế và thực hiện bởi những người không dính dáng tới việc thiết kế.

7.2.4. Lập trình vì độ tin cậy

Lập trình là một là một công đoạn phụ thuộc nhiều vào kỹ xảo cá nhân, sự chú ý đến các chi tiết và kiến thức về việc làm như thế nào để sử dụng các công cụ sẵn có theo cách thức tốt nhất. Nhu cầu các hệ thống đáng tin là đang tăng lên vì vậy cần có các kỹ thuật chuyên biệt nhằm đạt được một hệ thống tin cậy được. Hiện nay, có hai kỹ thuật để tăng độ tin cậy phần mềm khi viết các chương trình ứng dụng là: tránh lỗi và tha thứ lỗi.

1) Tránh lỗi

Việc phát triển phần mềm không có lỗi là một việc rất đắt đỏ, và khi mà một số lỗi đã được tháo khỏi chương trình thì giá cả cho việc tìm và tháo lỗi còn lại có xu hướng tăng theo hàm số mũ. Tránh lỗi và phát triển phần mềm không lỗi bằng cách:

- Tuân theo đúng đặc tả

- Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc che dấu thông tin và bao gói thông tin.

- Tăng cường việc duyệt lại trong quá trình phát triển và thẩm định hệ phần

mềm.

- Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình

phát triển phần mềm.

- Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để trưng ra các lỗi mà các lỗi này chưa được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống.

2) Thứ lỗi

Ngay với một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả. Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin cậy.

Có bốn hoạt động cần phải tiến hành nếu hệ thống phải là thứ lỗi:

- Phát hiện lỗi

- Định ra mức độ thiệt hại

- Hồi phục sau khi gặp lỗi: Hệ thống phải hồi phục về trạng thái mà nó biết là an toàn. Cũng có thể là chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), cũng có thể là lui về một trạng thái trước mà an toàn (hồi phục lùi).

- Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. Trong nhiều trường hợp sự thất bại của phần mềm là tàng hình và gây ra bởi một tổ hợp đặc biệt của thông tin vào.

3) Xử lý bất thường

Một sai loại nào đó hoặc một sự cố bất ngờ xuất hiện thì ta gọi chúng là một bất thường. Các bất thường có thể do phần cứng cũng có thể do phần mềm. Khi mà một bất thường không được dự đoán thì bộ điều khiển sẽ chuyển cho cơ chế xử lý bất thường hệ thống. Nếu một bất thường đã được dự đoán thì mã phải bao gồm cả việc phát hiện và việc xử lý bất thường đó.

Hầu hết các ngôn ngữ lập trình là không có các tiện ích để phát hiện và xử lý bất thường.

Các bất thường có thể được ghi lại bằng cách dùng một biến Logic nhằm chỉ ra rằng có một bất thường đã xuất hiện.

4) Lập trình phòng thủ

Lập trình phòng thủ là cách phát triển chương trình mà người lập trình giả định rằng các mâu thuẫn hoặc các lỗi chưa được phát hiện có thể tồn tại trong chương trình. Mã sẽ có phần kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi trạng thái là kiên định. Nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút lại và trạng thái phải trở về trạng thái đúng đắn trước đó.

Lập trình phòng thủ là một cách thứ lỗi, mà được tiến hành không cần bộ điều khiển thứ lỗi. Về cơ bản quá trình vẫn là: phát hiện lỗi, đánh giá lỗi, và phục hồi sau lỗi. Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái được gắn các trị không hợp luật.

Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho hiệu ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy giảm. Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống. Hồi phục lùi liên quan đến việc lưu trạng thái của hệ thống ở một trạng thái đúng đã biết.

7.3. Các giai đoạn kiểm thử phần mềm

Quá trình kiểm thử bắt đầu với bước lập kế hoạch, trong đó trưởng nhóm kiểm thử chuẩn bị và xây dựng kế hoạch kiểm thử. Sau đó, trưởng nhóm kiểm thử sẽ xây dựng các tình huống kiểm thử (bước thiết kế kiểm thử). Từ các tình huống kiểm thử, trưởng nhóm kiểm thử sẽ xây dựng các thủ tục kiểm thử hoặc chương trình kiểm thử (test script). Các cán bộ kiểm thử sẽ sử dụng các thủ tục kiểm thử hoặc test script để thực hiện kiểm thử. Các kết quả kiểm thử sẽ được đánh giá, xem xét bởi trưởng nhóm kiểm thử. Dựa vào kết quả xem xét, mô hình kiểm thử sẽ được hiệu chỉnh, nếu cần.

Mô hình kiểm thử là một tập hợp bao gồm kế hoạch kiểm thử, các tình huống kiểm thử và các thủ tục kiểm thử.

Đối với các dự án bảo trì và nâng cấp, việc thực hiện kiểm thử hồi qui (regression test) được thực hiện định kỳ. Hơn nữa kiểm thử hồi qui sẽ được thực hiện trước khi bàn giao lần cuối. Thời gian để thực hiện kiểm thử hồi qui sẽ được xác định trong kế hoạch dự án.

Hình 7.1. Qui trình kiểm thử phần mềm

7.3.1. Lập kế hoạch kiểm thử (Test plan)

1) Xác định các yêu cầu cho kiểm thử Mục đích:

- Xác định nội dung và phạm vi kiểm thử

- Xác định các yêu cầu kiểm thử là khởi đầu của bước lập kế hoạch kiểm thử.

+ Các yêu cầu chỉ rò kiểm thử cái gì, phạm vi và vai trò.

+ Các yêu cầu cho kiểm thử được sử dụng để xác định khối lượng công việc của việc kiểm thử (cho lập kế hoạch, thiết kế kiểm thử, v.v...) và dùng làm cơ sở cho đánh tỷ lệ kiểm thử.

- Các yêu cầu cho kiểm thử phải có thể kiểm tra được. Nói cách khác, chúng phải có thể quan sát được, các kết quả có thể đo được. Những yêu cầu mà không thể kiểm tra được thì sẽ không được coi là yêu cầu cho kiểm thử.

Xác định các yêu cầu cho kiểm thử được thực hiện như sau:

- Xem xét tất cả các yếu tố/dữ liệu

- Chỉ ra các yêu cầu cho kiểm thử.

2) Xây dựng chiến lược kiểm thử Mục đích:

- Xác định và thống nhất các công cụ và kỹ thuật kiểm thử.

- Xác định và thống nhất các phương pháp đánh giá để xác định chất lượng sản phẩm và và mức độ hoàn thành công việc kiểm thử.

Xây dựng chiến lược kiểm thử bao gồm:

- Xác định và mô tả các cách tiếp cận cho kiểm thử. Ví dụ đối với mỗi tình huống sử dụng (use case), các tình huống kiểm thử sẽ được xác định và thực hiện, bao gồm các dữ liệu đầu vào hợp lệ và không hợp lệ hoặc các thủ tục kiểm thử sẽ được thiết kế và xây dựng cho mỗi tình huống, hoặc các thủ tục kiểm thử và tình huống kiểm thử sẽ được thực hiện bởi 1500 người sử dụng, mỗi người sẽ thực hiện các chức năng A, B và C, và sử dụng các dữ liệu đầu vào khác nhau.

- Xác định các tiêu chí kiểm thử: kiểm thử cái gì, làm sao để đánh giá, tiêu chí đánh giá.

- Xác định các điều cần đặc biệt chú ý khi thực hiện kiểm thử. Ví dụ các CSDL kiểm thử phải được lấy từ hoạt động hàng ngày, sau mỗi giờ phải thực hiện kiểm thử lại....

3) Lập lịch trình thực hiện

Mục đích: Xác định khối lượng công việc, lịch trình, và các mốc thời gian chính Lập lịch trình thực hiện gồm có:

- Dự tính khối lượng công việc dựa trên năng suất và kỹ năng của cán bộ kiểm thử, các thông số về ứng dụng đựơc xây dựng (như số lượng màn hình, component, các thực thể dữ liệu và các mối quan hệ, và phần trăm tái sử dụng) và tỷ lệ kiểm thử cần đạt được

- Tạo ra lịch trình thực hiện.

4) Cấu trúc chung của một test plan

- Tên project

- Danh sách các Module cần test

- Ngày bắt đầu, ngày kết thúc

- Danh sách các Test case

- Nhân sự tham gia

- Tài nguyên sử dụng (Servers, Workstations, Printers,…)

- Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch)

7.3.2. Xây dựng các tình huống kiểm thử (Test Case)

1) Phân tích khối lượng công việc Mục đích:

- Xác định và mô tả các biến gây ảnh hưởng đến việc sử dụng và hoạt động của hệ thống

- Xác định các tập con trong các tình huống sử dụng

2) Xác định và mô tả các tình huống kiểm thử

Mục đích:

- Xác định và mô tả các điều kiện kiểm thử

- Xác định các dữ liệu kiểm thử cần thiết

- Xác định các kết quả kiểm thử dự kiến Đối với mỗi yêu cầu cho kiểm thử:

- Phân tích luồng thực hiện của ứng dụng

- Xác định và mô tả các tình huống kiểm thử (bắt nguồn từ yêu cầu/tình huống sử dụng hoặc mô hình thiết kế)

- Xác định các dữ liệu của tình huống kiểm thử (đầu vào, các kết quả mong đợi, các dữ liệu hỗ trợ)

3) Cấu trúc chung của các tình huống kiểm thử

- Tên project, module

- Màn hình, chức năng

- Mã số

- Tài liệu tham khảo (SRS)

- Mục đích

- Dữ liệu test

- Mô tả các bước (Test step)

- Trạng thái

- Ngày tạo Ví dụ:

Hình 7.2. Kiểm tra màn hình đăng nhập

- Project: Web testing application

- Module: Testing

- Màn hình: Đăng nhập hệ thống

- Chức năng: đăng nhập

- Mã số: TC001

- Dữ liệu test

+ Username = “thanh”, pass = “thanh”

+ Username = “admin”, pass = “admin”

- Các bước thực hiện kiểm tra

Bảng 7.1. Kiểm tra màn hình đăng nhập

7.3.3. Xây dựng các thủ tục kiểm thử (Test script)

1) Ghi hoặc lập trình các thủ tục kiểm thử

Mục đích: Tạo ra các thủ tục kiểm thử phù hợp để thực hiện các tình huống kiểm thử và các thủ tục kiểm thử như mong muốn.

Thực hiện các bước sau đây:

- Tạo hoặc thu thập các thủ tục kiểm thử

- Kiểm tra, sửa lỗi các thủ tục kiểm thử

- Xem xét và đánh giá tỷ lệ đã được kiểm thử

2) Xác định các chức năng hỗ trợ kiểm thử trong các mô hình thiết kế và lập

trình

Chỉ rò các yêu cầu chức năng phần mềm cần thiết (phải bổ sung) để trợ giúp

cho việc xây dựng hay thực hiện kiểm thử. Các chức năng hỗ trợ được sử dụng nhiều nhất trong kiểm thử tích hợp.

3) Thiết lập các bộ dữ liệu ngoài Mục đích:

- Tạo và duy trì cơ sở dữ liệu, lưu trữ dữ liệu độc lập với các thủ tục kiểm thử.

- Dữ liệu được các thủ tục kiểm thử sử dụng trong thời gian thực hiện kiểm thử Các bộ dữ liệu ngoài cung cấp dữ liệu theo các cách sau:

- Dữ liệu nằm ngoài các thủ tục kiểm thử sẽ hạn chế các tham chiếu cố định trong thủ tục kiểm thử.

- Dữ liệu ngoài dễ dàng cho việc sửa đổi mà ít hoặc không ảnh hưởng đến các thủ tục kiểm thử.

- Các tình huống kiểm thử có thể dễ dàng được bổ sung vào dữ liệu kiểm thử mà ít hoặc không phải sửa đổi thủ tục kiểm thử.

- Dữ liệu ngoài có thể chia sẻ giữa nhiều thủ tục kiểm thử.

- Các bộ dữ liệu ngoài có thể bao hàm nhiều giá trị dữ liệu sử dụng để kiểm soát các thủ tục kiểm thử.

7.3.4. Thực hiện các thủ tục kiểm thử

1) Thực hiện các thủ tục kiểm thử

Mục đích: Thực hiện các thủ tục kiểm thử (hoặc các test script nếu là test tự

động).

Thực hiện kiểm thử theo các bước sau:

- Thiết lập môi trường kiểm thử để đảm bảo rằng môi trường kiểm thử đã có

đầy đủ các yếu tố cần thiết (phần cứng, phần mềm, công cụ kiểm thử, dữ liệu kiểm thử , v.v.).

- Kiểm tra môi trường kiểm thử để đảm bảo rằng tất cả các yếu tố cần thiết đang ở trạng thái ban đầu đúng theo yêu cầu để bắt đầu thực hiện kiểm thử.

- Thực hiện các thủ tục kiểm thử (kiểm thử tự động hoặc kiểm thử bằng tay)

2) Đánh giá việc thực hiện kiểm thử Mục đích:

- Xác định việc thực hiện kiểm thử có thực hiện theo đúng yêu cầu hay không

- Xác định các hành động khắc phục cần thiết (từ nhóm phát triển). Việc thực hiện kiểm thử kết thúc với một trong hai điều kiện sau:

- Điều kiện thường: tất cả các thủ tục kiểm thử (hoặc test script) đã được thực hiện như dự kiến (Xem phần Kiểm tra lại kết quả kiểm thử)

- Điều kiện bất thường hoặc kết thúc sớm: kiểm thử bị tạm dừng và tỷ lệ kiểm thử chưa đạt yêu cầu (Xem phần Khôi phục hệ thống khi kiểm thử bị treo)

3) Khôi phục hệ thống khi kiểm thử bị treo Mục đích:

- Quyết định các hành động sửa đổi cần thiết để thực hiện tiếp các kiểm thử bị tạm dừng

- Giải quyết các vấn đề tồn đọng, khôi phục, và tái thực hiện các kiểm thử Để khôi phục hệ thống khi kiểm thử bị treo, cần thực hiện các bước sau đây:

- Tìm hiểu nguyên nhân của các vấn đề tồn đọng.

- Thực hiện các hành động khắc phục cần thiết.

- Tái thiết lập môi trường kiểm thử

- Kiểm tra lại môi trường kiểm thử

- Tái thực hiện kiểm thử

4) Kiểm tra lại kết quả kiểm thử

Mục đích: Xem các kết quả có nằm trong giới hạn cho phép hay không

Xem toàn bộ nội dung bài viết ᛨ