Kiểmthử bởi lập trình viên

CHƢƠNG 2 : CÁCKỸ THUẬT KIỂMTHỬ PHẦN MỀM NHÚNG

2.2 Vòng đời phát triển phần mềm nhúng

2.2.4 Kiểmthử bởi lập trình viên

Trong quá trình phát triển phần mềm thì các lý do đểkiểm thử bởi lập trình viên là hết sức quan trọng vì:

 Các lỗi được phát hiện sớm sẽ dễ dàng được sửa chữa với chi phí thấp, không tốn nhiều thời gian.

 Dễ dàng lần tìm ra các lỗi

 Các lỗi được phát hiện khi đã phân phối sản phẩm sẽ rất khó sửa vì công tác thu hồi gặp khó khăn.

 Công việc kiểm thử được thực hiện tốt trong giai đoạn phát triển sản phẩm có tác dụng tốt đối với tổng thời gian hoàn thiện dự án.

 Kiểm thử các trường hợp bắt ngoại lệ chỉ có thể được thực hiện trong giai đoạn kiểm thửđơn vị (unit test).

Hơn nữa chất lượng sản phẩm không thể cải tiến thêm nếu chỉ thực hiện kiểm thử vào giai đoạn cuối của quá trình làm ra sản phẩm. Kiểm thử chất lượng sản phẩm ở mọi giai đoạn phát triển là một điều cần thiết.

2.2.5 Kiểm thử bởi nhóm ngƣời kiểm tra độc lập

Các đội kiểm thử độc lập chiếm phần lớn các mức kiểm thử ở mức cao, các mức kiểm thử xảy ra ở giai đoạn cuối để đảm bảo rằng hệ thống phát triển đầy đủ. Các giai đoạn tiến hành gồm:

 Lập kế hoạch và kiểm soát giai đoạn kiểm thử

 Giai đoạn chuẩn bị: xác định xem cơ sở thử nghiệm có đủ chất lượng đảm bảo thực hiện thành công các trường hợp thử nghiệm.

 Giai đoạn đặc tả kỹ thuật: xây dựng mộttậpcáckiểm thửbằng cáchsử dụng cáckỹ thuậtthiết kế thử nghiệmđược phân bổ.

 Giai đoạn thi công: thực thi lệnh kiểm tra theo quy định để thu được kết quả về chất lượng của đối tượng kiểm tra.

 Giai đoạn hoàn thành: lưu trữ các phần mềm, hoàn thiện các báo cáo, đánh giá tích luỹ kinh nghiệm chocác phần mềm kiểm thử trong tương lai.

2.3 Các kỹ thuật kiểm thử phần mềm nhúng

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