2.3.1 Chiến lƣợc đánh giá rủi ro (Risk-base test strategy)
2.3.1.1 Giới thiệu
Phát triển một chiến lược đánh giá rủi ro dựa trên kiểm thử là một phương tiện giao tiếp với các bên liên quan cái gì là quan trọng nhất về hệ thống này vàđiều này có
nghĩa là cho những thử nghiệm của hệ thống này. "Chỉ cần kiểm thử tất cả mọi thứ" về mặt lý thuyết là không thể, hoặc ít nhất là về kinh tế không khả thi nó sẽ là một sự lãng phí nguồn lực (thời gian, tiền bạc, con người và cơ sở hạ tầng).Chiến lược đánh giá rủi ro là một yếu tố quan trọng trong một phương pháp kiểm tra cấu trúc và đóng góp lớn vào một quá trình thử nghiệm quản lý.
Phát triển một chiến lược thử nghiệm đòi hỏi sự hiểu biết sâu sắc về những rủi ro. Hậu quả gì sẽ xảy ra khi các mô-đun xác thực không làm việc chính xác? Điều gì sẽ bị thiệt hại khi hệ thống này cho thấy hiệu quả chưa đầy đủ?Vớiđặc thù của chiến lược này là phải nhìn thấu đáo những hậu quả mà sản phẩm kém chất lượng gây ra. Để làm được điều đó các khía cạnh khác nhau của rủi ro được phân tích trong đó có nguồn gốc từ phương trình nổi tiếng (Reynolds, 1996):[1]
Rủi ro = cơ hội lỗi* hậu quả lỗi gây ra (Risk=chanceoffailure x damage)
Trong đó cơ hội lỗi liên quan đến tần suất sử dụng và cơ hội của một lỗi có mặt trong hệ thống.Với một thành phần được sử dụng nhiều lần một ngày bởi nhiều người, cơ hội lỗi xuất hiệnlà cao. Khi đánh giá các cơ hội lỗi xảy ra, danh sách sau đây cho thấy những vị trí mà lỗi có xu hướng xảy ra:
Các thành phần phức tạp Các thành phần mới hoàn toàn
Các thành phần thường xuyên thay đổi
Các thành phần lần đầu dùng các công cụ và kỹ thuật nhất định Các thành phần mà chuyển qua nhiều người phát triển
Các thành phần được xây dựng dưới áp lực rất lớn về thời gian Các thành phần thường được tối ưu thường xuyên hơn bình thường Các thành phần mà nhiều lỗi được tìm thấy trong các phiên bản trước Các thành phần với nhiều giao tiếp với các thành phần khác
Cơ hội lỗi cũng lớn hơn đối với:
Những lập trình viên còn thiếu kinh nghiệm Không đủ sự tham gia của đại diện người sử dụng Không đủ bảo đảm chất lượng trong quá trình phát triển Không đủ chất lượng của kiểm thử mức độ thấp
Phát triển các công cụ mới và môi trường phát triển mới Những đội phát triểnvới các dự án lớn
Đội phát triển phân tán ở nhiều nơi dẫn đến giao tiếp bị hạn chế
Những thông tin cần thiết để đánh giá rủi ro thường được lấy từ các nguồn khác nhau. Bao gồm những người dùng cuối, các kỹ sư hỗ trợ và quản lý sản phẩm. Thành viên trong đội dự án như kiến trúc sư, lập trình, kiểm thử viên và nhân viên bảo đảm chất lượng biết rõvề những khó khăn trong việc phát triển sản phẩm. Họ có thể cung cấp những thông tin hữu ích trong việc đánh giá rủi ro.
Không thể đánh giá rủi ro khách quan đầy đủ và chính xác.Đánh giá rủi ro không chỉ thực hiện bởi quản lý kiểm thử mà còn cả bởi những người liên quan đến dự án. Điều này không chỉ làm tăng chất lượng của chiến lược thử nghiệm, mà mọi người tham gia có nhận thức tốt hơn về các rủi ro và các thử nghiệm. Điều này là cực kỳ quan trọng trong việc "thiết lập những kỳ vọng đối với thử nghiệm". Nó phải được hiểu rằng thử nghiệm chỉ là một trong những cách thức quản lý rủi ro. Hình 2.7 chỉ ra các lựa chọnđể quản lý rủi ro. [1]
Hình 2. 7: Xử lý rủi ro
2.3.1.2 Chiến lược kiểm thử trong lập kế hoạch kiểm thử tổng thể
Mục tiêu của chiến lược kiểm thử trong lập kế hoạch kiểm thử tổng thể là để nhận thấy được những rủi ro trong các tổ chức lớn cần kiểm thử trên nhiều thử nghiệm, được thực hiện ở đâu, khi nào trong quá trình phát triển.
Những bước phải làm:
Lựa chọn các đặc tính chất lượng: Một tập các đặc tính chất lượng được lựa chọn và được tài liệu hóa kết quả.
Xác định tầm quan trọng tương đối của các đặc tính có chất lượng: Chính là việc thảo luận để so sánh sự quan trọng của các thành phần. Mô tả bằng ma trận rất trực quan và dễ hiểu. Phần trăm thấp nghĩa là nhận ít sự quan tâm khi kiểm thử.
Gán các đặc tính chất lượng cho các mức độ kiểm thử: Trong quá trình phát triển phần mềm có nhiều pha. Các hoạt động này cần được đánh số ưu tiên.
2.3.1.3 Chiến lược kiểm thử cho một mức thử
Mục tiêu của chiến lược kiểm thửcho một mức thử nghiệm là tạo ra sự lựa chọn những gì cần kiểm thử và có các kỹ thuật kiểm thử để áp dụng. Chiến lược kiểm thử phải giải thích cho tất cả các bên liên quan biết lý do tại sao thử nghiệm hệ thống theo
cách này là sự lựa chọn tốt nhất có thể, xem xét áp lực thời gian và nguồn lực khan hiếm.
Các chiến lược kiểm thửcho các cấp độ thử nghiệm khác nhau được xem như là sàng lọc thêm các mục tiêu cụ thể đã được đặt ra trong chiến lược kiểm thửtổng thể.Các kỹ thuật kiểm thửcụ thể áp dụng cho các phần cụ thể của hệ thống.
Sau đây là các bước để thực hiện: Lựa chọn các đặc tính chất lượng
Xác định tầm quan trọng tương đối của các đặc tính chất lượng
Cách chia hệ thống thành hệ thống con(subsystem): Mỗi thành phần con được gọi là các thành phần (component) hay một đơn vị chức năng (functional unit). Mỗi thành phần này có thể được kiểm thử riêng rẽ và chúng có mức độ rủi ro khác nhau. Các hệ thống con được chia theo kiến trúc thiết kế. Một cách để chia nữa là dựa vào phạm vi rủi ro.
Xác định tầm quan trọng tương đối của các hệ thống con: Sau khi có danh sách các thành phần của hệ thống, cần phải đánh trọng số cho các thành phần. Đặt các thành phần trong mối tương quan. Kết quả sẽ được làm thành tài liệu, mô tả bằng ma trận. Việc đánh trọng số không dựa vào quan niệm cá nhân của người quản lý kiểm thử mà phải là từ cái nhìn của người dùng sản phẩm, người quản lý sản phẩm.
Xác định tầm quan trọng của việc kiểm thử mỗi hệ thống con, sự kết hợp các đặc tính chất lượng: Đây là bước làm mịn chiến lược bằng cách kết hợp đánh giá cácđặc tính chất lượng và hệ thống con. Có nghĩa là một đặc tính chất lượng cụ thể của một hệ thống con cụ thể sẽ được đánh giá mức độ quan trọng. Kết quả của bước này cung cấp một cái nhìn tổng quan về cái mà tổ chức thấy là quan trọng và nên kiểm thử.
Thiết lập các kỹ thuật kiểm thử được sử dụng: Đội kiểm thử sẽ được kì vọng là tổ chức và thực thi một quá trình kiểm thử mà bao trùm những phần quan trọng của sản phẩm đã được tổ chức định nghĩa ra. Công việc của người quản lý kiểm thử là thiết lập một tập các kỹ thuật mà có thể thực hiện để đảm bảo mức độ bao phủ cao. Nó phụ thuộc vào nhiều yếu tố như các đặc tính chất lượng được kiểm thử, loại ứng dụng, cơ sở kiểm thử được yêu cầu, tài nguyên được yêu cầu, kiến thức và kỹ năng được yêu cầu.
2.3.1.4 Chiến lược thay đổi trong quá trình thử nghiệm
Người quản lý kiểm thửkhông được phép cho rằng các chiến lược thử nghiệm sẽ được phát triển một lần và sau đó cố định trong suốt quá trình của dự án.Quá trình kiểm thửphải liên lục thay đổi sao cho phù hợp với những thay đổi của thực tế. Sử dụng chiến lược kiểm thửnhư một cơ sở, người quản lý kiểm thửcó thể thảo luận về các chủ đề này với các bên liên quan. Khi hoàn cảnh thay đổi yêu cầu việc thử nghiệm
cũng nên được thử nghiệm khác hơn trước đó, sau đó những mong đợi của các thử nghiệm cần đạt được cũng phải thay đổi.
2.3.1.5 Chiến lược kiểm tra bảo trì
Trong thời gian bảo trìcác lỗi có nguy cơ xuất hiện khi hệ thống có những thay đổi. Những thay đổi này của hệ thống tất nhiênphải được kiểm tra. Nhưng cũng có thể là hệ thốngđã hoạt động chính xác trong bản phát hành trước đó, chứkhông làm việc trong bản phát hành mới bởi vì những thay đổi của hệ thống. Hiện tượng này được gọi là hồi quy. Trong các phiên bản bảo trì phần lớn thời gian kiểm thử tập trung vào kiểm tra các chức năng trư ớcđó hoạt động chính xác không. Điều này được gọi là kiểm thử hồi quy.
Kiểm thử hồi quy là yếu tố tiêu chuẩn trong một dự án kiểm tra bảo trì. Thông thường một bộ trường hợp kiểm thử được duy trì cho mục đích này. Tuỳ thuộc vào những rủi ro và ngân sách dành cho việc kiểm thử mà lựa chọn thực hiện kiểm thử hồi quy đầyđủ hoặc kiểm thử các tình huống thích hợp nhất với các thay đổi của dựán. Các công cụ kiểm thử có thể được sử dụng rất hiệu quả để hỗ trợ việc thực hiện kiểm thử hồi quy.
2.3.2 Xem xét khả năng kiểm thử (Testability Review)
2.3.2.1 Giới thiệu
Việc chuẩn bị kiểm thử bắt đầu từ việc xem xét tính có thể kiểm thử. Tính có thể kiểm thử được hiểu là sự hoàn thiện, rõ ràng và nhất quán của các tài liệu để kiểm thử. Tính có thể kiểm thử cao nhất định sẽ đảm bảo thành công quá trình đặc tả kiểm thử. Việc phát hiện càng sớm những lỗi trong tài liệu sẽ càng làm đơn giản việc sửa chữa và chi phí thấp ngược lại nếu các lỗi trong tài liệu không được phát hiện và sửa chữa sẽ dẫn đến tiêu tốn chi phí nhiều và ảnh hưởng đến thời hạn đưa sản phẩm ra thị trường.
2.3.2.2 Thủ tục
Xem xét khả năng kiểm thử có các bước sau:[1]
Lựa chọn tài liệu liên quan: Trong kế hoạch kiểm thử (test plan) cần phải xác định các tài liệu nào sẽ được sử dụng để dẫn ra các trường hợp kiểm thử. Khâu xem xét tính có thể kiểm thử sẽ xác định một cách hình thức cơ sở kiểm thử và những tài liệu thực tế sẽ được dùng.
Soạn một danh sách hạng mục kiểm tra: Danh sách kiểm tra phụ thuộc vào các kỹ thuật thiết kế kiểm thử được sử dụng.
Đánh giá tài liệu: Với danh sách các mục cần kiểm tra, đội kiểm thử sẽ xác nhận tài liệu và đưa ra một báo cáo lỗi cho một lỗi được phát hiện. Phát hiện càng sớm thì càng tạo ra cơ hội cải thiện chất lượng của việc kiểm thử.
Báo cáo kết quả: Dựa trên các lỗi được phát hiện, đội kiểm thử sẽ bàn giao một báo cáo xem xét tính có thể kiểm thử. Báo cáo sẽ cung cấp tóm tắt về chất lượng của tài liệu.
Cơ sở kiểm thử không lý tưởng:Trong thực tế có khi những yêu cầu chưa có sẵn ngay nó có thể nảy sinh trong quá trình phát triển sản phẩm. Trong những tình huống này không áp dụng xem xét tính khả kiểm thử mà pha chuẩn bị đơn thuần là khoảng thời gian để gom lại những thông tin đúng.
2.3.3 Thanh tra (Inspections)
2.3.3.1 Giới thiệu
Thanh tra là một kỹ thuật đánh giá trong đó một người hay một nhóm khác với tác giả xem xét các yêu cầu phần mềm, thiết kế hoặc mã nguồnđể phát hiện lỗi, vi phạm các tiêu chuẩn phát triểnvà vấn đề khác. Thanh tra đã được chứng minh là một cách thức kiểm thử hiệu quả với chi phí rất rẻ cho việc tìm ra các lỗi.
Mục tiêu của thanh tra:
Để xác nhận phần mềm làm đúng đặc tả
Để xác nhận phần mềm tuân theo các tiêu chuẩn
Thiết lập những cải thiện chất lượng của sản phẩm và quy trình
Chuẩn bị là giai đoạn quan trọng nhất của thanh tra. Trong giai đoạn này, các nhà giám định đánh giá các thông số kỹ thuật. Một hoặc nhiều vai trò được giao cho mỗi giám định và do đó có thể đánh giá được những chi tiết kỹ thuật.Mỗi giám định sẽ phát hiện các lỗi duy nhấtmà không thể được phát hiện bởi các nhà đánh giá khác vì vai trò khác nhau của họ. Thanh tra là một kỹ thuật thích hợp để nâng cao chất lượng sản phẩm.
Ưu điểm:
Thiếu sót được phát hiện sớm có thể được điều chỉnh với chi phí thấp. Tỷ lệ phát hiện lỗi là khá cao vì có một nhóm chuyên tập trung thực hiện
việc đánh giá.
Việc đánh giá một sản phẩm bởi một đội sẽ thúc đẩy sự trao đổi thông tin giữa các thành viên của nó.
Thanh tra không chỉ giới hạn với các tài liệu thiết kế mà có thể được sử dụng cho tất cả các tài liệu được bàn giao của quá trình phát triển cũng như quá trình kiểm thử.
Việc kiểm tra kích thích cao nhận thức và động lực phát triển các sản phẩm chất lượng.
2.3.3.2 Thủ tục
Thanh tra sẽ được thực hiện theo các bước:[1]
Tiếp nhận thanh tra kiểm tra: Người phụ trách tiếp nhận kiểm tra sản phẩm, dựa trên các tiêu chuẩn tiếp nhận. Các tiêu chuẩn tiếp nhận đưa cho tác giả của sản phẩm những hướng dẫn rõ ràng về việc khi nào sản phẩm sẽ được chấp nhận để thanh tra.
Tổ thức thanh tra: Người chịu trách nhiệm sẽ tổ chức một cuộc thanh tra liệu sản phẩm có vượt qua vòng tiếp nhận hay không. Một đội phải được
tổ chức ra làm việc này và mỗi thành viên có vai trò tương xứng với sự quan tâm và kinh nghiệm của người tham gia sau đó thống nhất một cuộc họp.
Khởi động thanh tra Chuẩn bị
Họp để công bố thiếu sót Họp phân tích nguyên nhân Thực hiện làm lại
Kiểm tra tiêu chuẩn chấp nhận
2.3.4 Phân tích an toàn (Safety Analysis)
2.3.4.1 Giới thiệu
Có nhiều hệ thống nhúng được sử dụng trong các tình huống quan trọng với các yêu cầu cao về tính an toàn. Vì vậy trong quá trình thiết kế và phát triển các hệ thống này phải xây dựng một số biện pháp đảm bảo an toàn cho hệ thống. Cách tốt nhất để xử lý các yêu cầu về an toàn của một hệ thống là bắt đầu theo dõi nó trong giai đoạn thiết kế.
Hai kỹ thuật phân tích an toàn được mô tả:FMEA (Failure Mode and Effect Analysis)và FTA (Fault Tree Analysis).
Phân tích an toàn là mối quan hệ giữa nguyên nhân - kết quả. Kết quả luôn luôn liên quan đến những nguy hại.
Hình 2. 8: Mối quan hệ giữa nguyên nhân, chức năng, chế độ thất bại và kết quả. Phần đóng hộp có thể được phân tích bởi FMEA và toàn bộ được phân tích bởi FTA.
2.3.4.2 Các kỹ thuật phân tích an toàn
FMEA (Failure Mode and Effect Analysis) là một phương pháp phân tích xác định tác động của một thất bại lên hệ thống. Kỹ thuật này được sử dụng sớm trong quá trình thiết kế để tăng cườngan toàn thông qua thiết kế.
FMEA bao gồm ba bước:
Xác định chế độ thất bại tiềm ẩn
Xác định ảnh hưởng của chế độ thất bại tiềm ẩn lên chức năng của hệ thống
Xây dựng các hành động để giảm thiểu những tác động hoặc chế độ thất bại
Việc sử dụng phù hợp các FMEA có thể có những lợi ích sau đây: Nâng cao an toàn của hệ thống
Nâng cao khả năng theo dõi những rủi ro trong suốt chu trình phát triển Sớm xác định các mối nguy hiểm tiềm ẩn
Làm giảm bớt rủi ro về tài liệu và các tác động Giảm thiểu các thay đổi và chi phí liên quan
Là sản phẩm đầu vào đáng tin cậy cao cho chiến lược kiểm thử
FTA (Fault TreeAnalysis) được sử dụng để xác định nguyên nhân của thất bại. Đây là một kỹ thuật để phân tích thiết kế với sự an toàn và độ tin cậy cao. Sự thất bại của hệ thống được lấy ở trên cùng của cây lỗi và bước kế tiếp là phải xem xét những trạng thái không mong muốn (các bộ phận của hệ thống) chịu trách nhiệm về những trục trặc của hệ thống. Một cây lỗi cũng có thể được sử dụng để tìm nguyên nhân thất bại. Những thất bại này ảnh hưởng đến nhiều phần của hệ thống.[1]
FMEA và FTA là các kỹ thuật thường được trình bày và sử dụng để phân tích an toàn. Tuy nhiên chúng cũng rất hữu ích trong việc xác định chiến lược thử nghiệm. FTA và FMEA sau đó có thể được áp dụng có hiệu quả để xác định các điểm yếu và