Phương pháp kiểm thử

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên LỜI CẢM ƠN Trước tiên, tôi muốn gửi lời cảm ơn đến thầy giáo TS. Bùi Thế Hồng, người đã trực tiếp hướng dẫn tôi thực hiện luận văn này. Tôi cũng muốn bày tỏ lòng biết ơn đến các thầy giáo Viện Công nghệ thông tin và Khoa Công nghệ thông tin - Đại học Thái Nguyên đã tận tình dạy dỗ và tạo mọi điều kiện học tập thuận lợi cho tôi trong suốt khoá học qua. Tôi xin cảm ơn lãnh đạo Bệnh viện Y học cổ truyền Thái Nguyên, các anh chị đồng nghiệp đã tạo điều kiện cho tôi tham gia và hoàn thành khoá học. Tôi cũng xin cảm ơn các bạn của tôi, những người luôn bên cạnh động viên, giúp đỡ, và đã đóng góp nhiều ý kiến thiết thực trong quá trình học tập và thực hiện luận văn. Cuối cùng, tôi muốn gửi lời cảm ơn đến gia đình, đặc biệt là bố mẹ, chồng và con tôi - những người luôn hết mình yêu thương, dìu dắt và ủng hộ tôi trong cuộc sống./. Thái Nguyên, tháng 11 năm 2008 Sinh viên thực hiện Trần Thị Ngọc Liên Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên MỤC LỤC Danh sách bảng.................................................................................... 1 Danh sách hình vẽ ................................................................................ 2 Ký hiệu viết tắt ...................................................................................... 3 Lời nói đầu ............................................................................................ 4 Cấu trúc luận văn.................................................................................. 6 1.1 Rủi ro .................................................................................................. 7 1.1.1 Độ phơi nhiễm rủi ro ............................................................................ 8 1.1.2 Xử lý rủi ro ........................................................................................... 8 1.1.3 Quản lý rủi ro ....................................................................................... 9 1.1.4 Rủi ro trong công nghệ phần mềm .................................................... 10 1.2 Kiểm thử phần mềm ......................................................................... 12 1.2.1 Kiểm thử và các ca kiểm thử ............................................................. 12 1.2.2 Kiểm thử hộp đen và hộp trắng ......................................................... 13 1.2.3 Quá trình kiểm thử ............................................................................. 14 1.3 Kiểm thử dựa trên các rủi ro ............................................................ 16 1.3.1 Phân tích sơ bộ các mối nguy hiểm (PHA) ........................................ 17 1.3.2 Phân tích các kiểu lỗi và hậu quả (FMEA) ......................................... 17 1.3.3 Phân tích lỗi tiềm ẩn và khả năng thực hiện (HazOp) ....................... 18 1.3.4 Kiểm thử dựa trên rủi ro theo kinh nghiệm ........................................ 19 1.3.5 Ngăn ngừa các mối nguy hiểm .......................................................... 22 Tóm tắt Chương 1 .................................................................................. 24 Chương 2 Phân loại ưu tiên các kiểm thử .........................................26 2.1 Các nhân tố gây ra thiệt hại ............................................................. 26 2.2 Các hành động phát sinh sai sót trong quá trình phát triển ............. 28 2.3 Phát sinh lỗi trong khi lập trình ......................................................... 29 2.4 Kiểm thử hệ thống theo độ phơi nhiễm rủi ro ................................... 30 2.5 Lập thứ tự kiểm thử ưu tiên trước khi hết kỳ hạn ............................ 32 2.6 So sách các cách tiếp cận khác nhau .............................................. 33 Tóm tắt Chương 2 .................................................................................. 35 Chương 3 Một phương pháp kiểm thử mới .......................................36 3.1 Sắp thứ tự ưu tiên các rủi ro và tạo lập các kiểm thử và các rào cản có liên quan ............................................................................................ 36 3.2 Sắp thứ tự ưu tiên kiểm thử cho các modules trong hệ thống ......... 40 3.3 Lập danh sách ưu tiên kiểm thử ....................................................... 44 Tóm tắt Chương 3 .................................................................................. 47 Chương 4. Đặc tả các yêu cầu cho công cụ kiểm thử .......................48 4.1 Các yêu cầu chức năng.................................................................... 48 4.1.1 Dự án................................................................................................. 48 4.1.2 Loại rủi ro ........................................................................................... 48 Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 4.1.3 Module ............................................................................................... 49 4.1.4 Nguy cơ ............................................................................................. 50 4.1.5 Kiểm thử ............................................................................................ 50 4.1.6 Rào cản ............................................................................................. 51 4.2 Các yêu cầu không chức năng ......................................................... 51 4.2.1 Chất lượng ........................................................................................ 52 4.2.1 Công nghệ ......................................................................................... 52 4.3. Thiết kế công cụ phần mềm kiểm thử ............................................. 52 4.3.1 Ngôn ngữ thực hiện ........................................................................... 52 4.3.2 Mô hình dữ liệu .................................................................................. 53 4.4 Giao diện .......................................................................................... 55 4.4.2 Tạo ra một dự án mới ........................................................................ 57 4.4.3 Lựa chọn và trọng số các loại rủi ro .................................................. 58 4.4.4 Danh sách module ............................................................................. 59 4.4.5 Giá trị những module ......................................................................... 60 4.4.6 Tạo một kiểm thử mới ....................................................................... 61 4.4.7 Danh sách kiểm thử .......................................................................... 62 4.4.8 Danh sách những rủi ro ..................................................................... 63 4.4.9 Danh sách những rào cản ................................................................. 64 Tóm tắt chương 4 ................................................................................... 66 Kết luận ...............................................................................................67 Tài liệu tham khảo ..............................................................................68 1 Danh sách bảng Tên bảng Trang Bảng 1.1 Bảng PHA …………………………………………………. Bảng 1.2 Cấu trúc của bảng FMEA …………………………………. Bảng 1.3: Bảng HazOp ……………………………………………… Bảng 1.4: Danh sách rủi ro tổng quát ………………………………... Bảng 1.5: Danh sách rủi ro cho việc cài đặt …………………………. Bảng 1.6: Ma trận rủi ro của các thành phần ………………………… Bảng 2.1: Độ phơi nhiễm rủi ro đối với chức năng “Đóng tài khoản” ……………………………………………………………………….. Bảng 2.2: Ví dụ về tính toán rủi ro ………………………………….. Bảng 3.1: Các thông tin cần biết từ việc phân tích lỗi ………………. Bảng 3.2: Ma trận rủi ro cho độ phơi nhiễm ………………………… Bảng 3.3: Bảng với các thông tin nhận được từ phân tích rủi ro ……. Bảng 3.4: Các nhóm rủi ro và các nhân tố rủi ro được sử dụng trong phân tích rủi ro ……………………………………………………….. Bảng 3.5: Tính toán chi phí (bằng số) ………………………………. Bảng 3.6: Tính các số xác suất ……………………………………... Bảng 3.7: Quá trình tính các số chi phí và các số xác suất ………….. Bảng 3.8: Thiệt hại tiềm ẩn đã được tính toán ………………………. Bảng 3.9: Ma trận rủi ro được sử dụng trong lập thứ tự ưu tiên cuối cùng ………………………………………………………………….. Bảng 3.10: Danh sách các kiểm thử được phân loại ưu tiên ………. 17 18 18 20 20 22 32 33 36 38 39 40 42 43 43 34 45 46 2 Danh sách hình vẽ Tên hình vẽ Trang Hình 1.1 Vùng ALAPR………………………………………………. 23 Hình 4.1: Sơ đồ lớp UML thể hiện mô hình dữ liệu cho công cụ phần mềm …………………………………………………… 54 Hình 4.2: Màn hình của trang Xuatphat.asp ………………………… 56 Hình 4.3: Màn hình trang ThemDuan.aspx………………………….. 57 Hình 4.4: Màn hình trang LoaiRuiro.aspx ……………………………. 58 Hình 4.5: Màn hình trang Modules.aspx ……………………………... 59 Hình 4.6: Màn hình trang GiatriModules.aspx………………………... 60 Hình 4.7: Màn hình trang Taokiemthu.aspx…………………………....61 Hình 4.8: Màn hình trang Trangchu.aspx ……………………………...62 Hình 4.9: Màn hình trang Ruiro.aspx ………………………………….63 Hình 4.10: Màn hình trang Raocan.aspx ……………………………… 64 3 Ký hiệu viết tắt PM Phần mềm KTPM Kiểm thử phần mềm PTPM Phát triển phần mềm PHA Phân tích lỗi sơ bộ HazOp Phân tích lỗi và khả năng thực hiện FMEA Phân tích các kiểu lỗi và hậu quả FMEA 4 Lời nói đầu Kiểm thử phần mềm là một công việc đòi hỏi rất nhiều thời gian trong qui trình phát triển phần mềm. Thế nhưng, kiểm thử phần mềm lại thường được thực hiện vào pha gần cuối của vòng đời phát triển hệ thống khi tiền bạc và thời gian không còn dư rả nữa. Những người quản lý đều rất mong muốn sớm có được một phiên bản của sản phẩm và thường thúc ép những người kiểm thử phải hoàn thành công việc trong một khoảng thời gian không dễ dàng có thể thực hiện được. Nhưng cho dù thế nào thì những người kiểm thử vẫn phải làm công việc của họ, và vì vậy có thể họ không thể kiểm thử tất cả những thứ cần phải kiểm thử. Do đó, họ chỉ kiểm thử những thứ mà họ cho là quan trọng nhất. Mục tiêu của luận văn là nghiên cứu các cách tiếp cận kiểm thử khác nhau và tìm cách đề xuất một phương pháp kiểm thử hệ thống dựa trên các rủi ro đã phân tích được. Những rủi ro có thể có đối với hệ thống sẽ được phân tích cho từng ca sử dụng. Việc đánh giá những rủi ro này sẽ được sử dụng để tìm ra bản chất của rủi ro cho từng ca sử dụng. Các ca kiểm thử sẽ được thiết lập từ những ca sử dụng này và các ca kiểm thử có rủi ro cao nhất sẽ được chọn để thực hiện. Ngoài ra, trong luận văn sẽ xác định thêm những yêu cầu cần thiết cho việc xây dựng một công cụ phần mềm hỗ trợ cho phương pháp kiểm thử này và đề xuất một mô hình thử nghiệm. Kinh nghiệm cho thấy khi gặp một vấn đề nào đó trong cuộc sống, con người thường giải quyết bằng cách nhớ lại những vấn đề họ đã gặp trước đây để tìm ra vấn đề tương tự, rồi lục lại trí nhớ để tìm lại cách giải quyết của vấn đề tương tự này, và cuối cùng điều chỉnh cách giải quyết vừa tìm thấy nếu cần thiết để đưa ra cách giải quyết hợp lý cho vấn đề hiện tại của mình. Trong phân tích và quản lý rủi ro cũng vậy, khi tiếp nhận một dự án, những người 5 quản trị dự án bao giờ cũng nhớ lại những dự án trong quá khứ mà họ đã quản lý để tìm ra một số dự án tương tự, sau đó tìm lại danh sách rủi ro của các dự án tương tự này, và cuối cùng hiệu chỉnh trên các danh sách rủi ro vừa tìm thấy cho phù hợp với ngữ cảnh hiện tại để đưa ra dự đoán danh sách rủi ro cho dự án đang phát triển. Thực tế, các dự án luôn luôn có một độ tương tự nhất định tùy theo hướng nhìn nhận của người quản trị dự án và rủi ro phần mềm là một vấn đề phức tạp không nằm trong tầm kiểm soát của người quản trị dự án. Mục tiêu của mô hình là đảm bảo tự động hóa một phần quá trình phân tích và quản lý rủi ro. Dựa trên những thông tin về phân tích và quản lý rủi ro của các dự án phần mềm đã hoàn thành, mô hình đưa ra một dự đoán danh sách rủi ro cho dự án hiện tại, và mỗi rủi ro trong danh sách này là một trong những rủi ro đã được dự đoán trong quá khứ. Vì vậy khi sử dụng mô hình này, các nhà quản trị dự án có thể tận dụng và trau dồi những kinh nghiệm phân tích và quản lý rủi ro mà họ đã trải qua trong quá khứ, và họ có thể tự bổ sung kinh nghiệm bằng cách thêm những rủi ro mới xuất hiện và kế hoạch quản lý rủi ro tương ứng vào danh sách rủi ro của dự án hiện tại. Ngoài ra, do đặc điểm của lý thuyết, mô hình thử nghiệm được đề xuất trong luận văn chỉ áp dụng trong một ngữ cảnh hẹp, chẳng hạn một công ty phần mềm. Hiện nay, các công ty phần mềm có xu hướng phát triển phần mềm trong một số lĩnh vực nhất định, đáp ứng nhu cầu của một số đối tượng khách hàng nhất định, sử dụng một số công nghệ phát triển nhất định, … nên xây dựng mô hình trong một ngữ cảnh hẹp là hoàn toàn hợp lý. 6 Cấu trúc luận văn Luận văn gồm 4 chương, nội dung của mỗi chương được tóm tắt như sau: Chương 1: Trình bày những khái niệm cơ bản về kiểm thử nói chung và kiểm thử dựa trên các rủi ro. Chương 2: Trình bày các phương pháp phân loại ưu tiên các kiểm thử rủi ro và so sánh các phương pháp kiểm thử dựa trên rủi ro. Chương 3: Đề xuất một phương pháp kiểm thử dựa trên rủi ro mới. Chương 4: Phân tích các yêu cầu của một công cụ phần mềm kiểm thử và thiết kế các giao diện và cơ sở dữ liệu của phần mềm kiểm thử. 7 Chương 1 Kiểm thử phần mềm dựa trên các rủi ro Việc xem xét các rủi ro trong kiểm thử phần mềm không phải là mới. Những người kiểm thử phần mềm có kinh nghiệm thường kiểm thử hệ thống dựa trên các rủi ro với những linh cảm riêng. Hiện tại, đã có một vài cách tiếp cận dùng để kiểm thử phần mềm dựa trên các rủi ro. Mục tiêu của chương này là tìm hiểu xem rủi ro trong công nghệ phần mềm là gì và cách phòng ngừa, xử lý các rủi ro. Tiếp theo là nghiên cứu để biết rõ được kiểm thử phần mềm là gì và có các loại hình kiểm thử nào. Cuối cùng là nghiên cứu tìm hiểu một số phương pháp kiểm thử dựa trên các rủi ro đã phát hiện được khi phân tích. 1.1 Rủi ro Mỗi người đều có một ý niệm nào đó về rủi ro. Hàng ngày, chúng ta có thể gặp phải các rủi ro nào đó. Để có được một cái gì đó người ta thường phải chấp nhận các rủi ro. Băng qua một đường phố đông đúc để uống một tách cà phê có thể sẽ bị một tai nạn giao thông là một ví dụ về việc chấp nhận rủi ro để có một lợi ích nào đó. Việc mua xổ số là ví dụ khác của việc chấp nhận rủi ro, ta có thể được hoặc có thể mất. Trong thực tế, một số người sẵn sàng chấp nhận rủi ro trong khi những người khác lại rất ghét rủi ro. Theo từ điển Wikipedia thì “Rủi ro là thiệt hại tiềm tàng mà có thể xuất hiện từ quá trình hiện hữu nào đó hoặc từ sự kiện tương lai nào đó”. Tức là, rủi ro chưa trở thành một vấn đề nhưng nó có thể là một vấn đề nếu không tiến hành những hành động phù hợp. Trong ngữ cảnh một dự án, rủi ro là khả năng xảy ra một sự kiện nào đó và khả năng ảnh hưởng đến những mục tiêu của dự án nếu sự kiện đó xảy ra. Nó chứa đựng khả năng thiệt hại, và khả năng dẫn đến những sai khác so với kết quả mong đợi. 8 Tóm lại, rủi ro gồm hai thành phần: khả năng xảy ra và hậu quả phải gánh chịu nếu nó xảy ra. Hai thành phần này tạo nên hai đặc trưng của rủi ro: không chắc chắn (rủi ro có thể xảy ra hoặc không) và gây thiệt hại (rủi ro mang đến những hậu quả không mong đợi). Như vậy, rủi ro là nhân tố bất kỳ có thể gây trở ngại cho thành công của dự án. Một rủi ro chưa phải là một vấn đề mà chính xác hơn một rủi ro là một vấn đề có thể xảy ra. 1.1.1 Độ phơi nhiễm rủi ro Khi xem xét rủi ro, chúng ta phải tính đến những thiệt hại do rủi ro gây ra và khả năng có thể xảy ra rủi ro này. Thiệt hại là những thứ không may bị mất mát như thời gian, chất lượng, tiền bạc, kiểm soát hoặc hiểu biết. Khả năng mà một sự kiện có thể dẫn đến các thiệt hại nào đó thường được tính như một xác suất có giá trị từ 0 đến 1. Nếu xác suất này bằng 0 thì sự kiện sẽ không bao giờ xảy ra và không được coi là một rủi ro. Một xác suất bằng 1 có nghĩa là sự kiện này sẽ xảy ra trừ khi một vấn đề nào đó được giải quyết hoặc thay đổi. Nếu ta có một số rủi ro có thể xảy ra đối với một vấn đề nào đó thì có thể sẽ rất khó để xác định xem những rủi ro nào cần phải đặc biệt chú ý. Bởi vậy cần phải có một phương thức để đánh giá mức độ nguy hại của các rủi ro. Một trong những cách thức đó là tính Độ phơi nhiễm rủi ro (Risk Exposure). Đây là một tính toán đơn giản dùng để gán cho mỗi rủi ro một giá trị số cho phép so sánh các rủi ro với nhau. Độ phơi nhiễm rủi ro = Xác suất xảy ra rủi ro * Tổng thiệt hại nếu rủi ro xảy ra 1.1.2 Xử lý rủi ro Sau khi nhận dạng được các rủi ro, chúng ta sẽ xem xét phải làm gì với chúng. Trước hết, cần phải xem xét mức độ mà ta có thể thay đổi được các 9 hậu quả của rủi ro. Tức là chúng ta có thể giảm thiểu hoặc ngăn ngừa hậu quả của một rủi ro ở mức độ như thế nào. Các rủi ro có thể được chấp nhận, bị ngăn ngừa hoặc được san sẻ. Nếu rủi ro được chấp nhận thì những thiệt hại do rủi ro này gây ra phải được tính vào chi phí của dự án. Nếu phải chấp nhận nhiều rủi ro thì cần phải sử dụng độ phơi nhiễm rủi ro khi dự toán chi phí. Cách tính này sẽ cho một dự toán với mức thiệt hại trung bình do các rủi ro gây ra. Ngăn ngừa là cách giảm thiểu thiệt hại hoặc xác suất. Có thể làm được điều đó bằng cách thay đổi điều kiện sao cho sự kiện này sẽ không xảy ra. Trong công nghệ phần mềm, có thể tiến hành nhiều kiểm thử hơn để giảm thiểu rủi ro. Việc kiểm thử sẽ giảm bớt những gì còn chưa chắc, chưa rõ ràng và có thể phát hiện ra các lỗi quan trọng có thể sửa được. San sẻ thiệt hại có nghĩa là chia những thiệt hại này cho một số bên khác nhau, ví dụ như khách hàng, nhà thầu phụ hoặc một hãng bảo hiểm. Tuy nhiên, việc san sẻ thiệt hại cho khách hàng lại là một rủi ro vì nó sẽ làm giảm uy tín và có thể dẫn đến mất khách hàng và thị phần. 1.1.3 Quản lý rủi ro Hậu quả do rủi ro gây ra xuất hiện dưới nhiều hình thức khác nhau, có thể là chất lượng của sản phẩm cuối không đáp ứng được yêu cầu của khách hàng, chi phí dự án tăng lên, giao sản phẩm chậm hay không đạt được những mục tiêu đã đặt ra của dự án; và trường hợp xấu nhất là phá hỏng toàn bộ dự án. Mỗi thay đổi dù nhỏ hay lớn, như thay đổi yêu cầu khách hàng, thay đổi công nghệ phát triển hay thay đổi cơ cấu đội phát triển, đều ảnh hưởng đến tính chất kịp thời và thành công của dự án. Hơn nữa, làm phần mềm là một cuộc chiến giữa nhà quản trị dự án với những lựa chọn khác nhau, chẳng hạn như nên dùng phương pháp và công nghệ phát triển nào, cần khoảng bao nhiêu người phát triển hay chất lượng phần mềm như thế nào 10 là đủ …; và mỗi lựa chọn này có lợi và hại khác nhau đối với dự án. Vì thế nhà quản trị dự án phải cân nhắc giữa cái được và cái mất để đưa ra lựa chọn thích hợp nhất về phương pháp, công cụ, cơ cấu đội phát triển và tiêu chí chất lượng cho từng dự án. Quả thực, rủi ro là vấn đề luôn tiềm ẩn trong phát triển phần mềm và lúc nào cũng nằm chờ sẵn cơ hội để xuất hiện; do đó, quản lý rủi ro trở thành điều kiện cần để dẫn đến thành công của dự án. Quản lý rủi ro là một chuỗi các hoạt động hay các bước giúp đội phát triển hiểu và quản lý các rủi ro. Hoạt động này diễn ra liên tục xuyên suốt quá trình phát triển phần mềm nhằm tìm kiếm các rủi ro có thể xảy ra, xác định mức độ quan trọng của rủi ro để ưu tiên giải quyết và thực thi các chiến lược đã đề ra để khắc phục hậu quả nếu rủi ro xảy ra. Thực tế, tất cả những người liên quan đến quá trình làm phần mềm, bao gồm: quản trị dự án, kỹ sư phần mềm và khách hàng đều phải tham gia hoạt động quản lý rủi ro; trong đó, quản trị dự án có vai trò và trách nhiệm cao nhất đối với hoạt động này. Kết quả của quản lý rủi ro là một danh sách rủi ro hoàn toàn dựa trên những nghiên cứu của quản trị dự án về đội phát triển, yêu cầu khách hàng, các tiến trình phát triển và các thông tin dự án khác. Rủi ro được xem xét lặp đi lặp lại trong các giai đoạn phát triển phần mềm để đảm bảo rủi ro được cập nhật liên tục và các kế hoạch quản lý rủi ro đảm bảo tính thực tế. 1.1.4 Rủi ro trong công nghệ phần mềm Trước đây, rủi ro thường bị bỏ qua trong công nghệ phần mềm. Người ta luôn giả thiết là sẽ có một bản thiết kế tối ưu và không có quĩ dự trữ để đề phòng những rủi ro. Nhưng những gì họ làm lại không thường xuyên như kế hoạch đã định và trong mọi dự án phát triển phần mềm đều có nhiều rủi ro cần phải được xem xét. Vì luôn luôn tồn tại những điều không chắc chắn 11 trong công nghệ phần mềm cho nên công việc xử lý các rủi ro sẽ ảnh hưởng rất lớn đến thành công của dự án. Những rủi ro có liên quan tới sản phẩm thông thường được phân tích, xử lý riêng rẽ, tách biệt với những rủi ro liên quan đến quá trình dự án. Rủi ro sản phẩm có thể được phát hiện từ việc nhận dạng các nguy cơ và các đe dọa có thể xảy ra đối với hệ thống. Nguy cơ là một sự kiện không mong muốn nhưng vẫn có khả năng xảy ra. Thuật ngữ “nguy cơ” thường được sử dụng trong khi đánh giá độ an toàn của hệ thống. Tính chất nghiêm trọng của các nguy cơ sẽ phụ thuộc vào bản chất của phần mềm. Trong các hệ thống đòi hỏi độ an toàn cao thì hậu quả của các nguy cơ tất nhiên sẽ cao hơn so với các hệ thống thương mại, nhưng thuật ngữ “nguy cơ” vẫn có thể được sử dụng ở cả hai. Các phần mềm có những lỗi nghiêm trọng sẽ không chỉ có vấn đề ngay tại lúc này mà còn gây ảnh hưởng cho các công việc nghiệp vụ sau này. Nếu khách hàng gặp những vấn đề và thấy thời gian của họ bị lãng phí, thì họ sẽ không quay lại nữa. Từ lý do đó, một giao diện người dùng tốt cũng là một nhân tố quyết định phần mềm có rủi ro hay không. Đối với các phần mềm thương mại, nguy cơ đáng sợ nhất có thể là mất dữ liệu. Đối với những phần mềm đòi hỏi độ an toàn cao thì ảnh hưởng của lỗi có thể còn lớn hơn. Một nguy cơ có thể dẫn đến các thảm họa. Trong các hệ thống an ninh và nghiệp vụ quan trọng, việc kiểm soát các rủi ro đóng một vai trò quyết định đối với vìệc giảm thiểu các thiệt hại do lỗi phần mềm gây ra. Bởi vậy trong các hệ thống này, độ tin cậy của phần mềm trở nên rất quan trọng. Nhưng những phần mềm có độ tin cậy cao vẫn không đảm bảo là sẽ vận hành an toàn, do vậy nó cần phải đáng tin cậy. Rủi ro quá trình liên quan đến quá trình phát triển phần mềm được thực hiện như thế nào. Rủi ro quá trình xuất hiện từ quá trình phát triển phần mềm 12 không hoàn chỉnh có thể sẽ gây ra các lỗi làm cho độ tin cậy và độ an toàn có thể bị suy giảm. Bởi vậy, cả hai kiểu rủi ro gồm rủi ro sản phẩm và rủi ro quá trình đều cần phải được xem xét kỹ lưỡng. 1.2 Kiểm thử phần mềm Kiểm thử trong công nghệ phần mềm là “Một quá trình được sử dụng để nhận biết sự đúng đắn, hoàn chỉnh và chất lượng của một phần mềm máy tính đã được phát triển”. Trên thực tế, kiểm thử không bao giờ có thể chứng minh được tính đúng đắn của một phần mềm máy tính, mà điều này chỉ có thể thực hiện được bằng việc thẩm tra chính thức (và chỉ khi không có lỗi trong quá trình thẩm tra chính thức). Nó có thể chỉ tìm thấy những thiếu sót, chứ không đảm bảo rằng sẽ không có thiếu sót. Mục đích của kiểm thử là phát hiện lỗi trong hệ thống và tạo ra sự tin tưởng của khách hàng vào việc hệ thống có thể cung cấp những chức năng đã được xác định trong các yêu cầu và không gây ra những thiệt hại cho khách hàng. Cả hai điều này đều quan trọng. Ngoài ra, còn có thể có thêm hai mục tiêu nữa: “Cung cấp một bằng chứng là những lợi thế về nghiệp vụ đòi hỏi hệ thống phải đáp ứng luôn luôn sẵn sàng” và “Cung cấp dữ liệu về các rủi ro của phiên bản hệ thống đang được kiểm thử.” 1.2.1 Kiểm thử và các ca kiểm thử Hiện tại vẫn chưa có một định nghĩa chung cho ca kiểm thử (test case). Viện kỹ thuật điện và điện tử (IEEE) định nghĩa một kiểm thử là một tập hợp một hoặc nhiều ca kiểm thử. Một ca kiểm thử là “Một tình huống cần phải được kiểm thử bao gồm nhận dạng riêng của nó và phản ứng kỳ vọng”. Có thể mô tả một ca kiểm thử như một câu hỏi để hỏi chương trình nhằm thu được thông tin. Vả lại, một ca kiểm thử cũng không có gì quá đặc biệt, chẳng qua nó cũng chỉ là một ý định sẽ 13 kiểm thử cái gì trong chương trình. Điều quan trọng là các ca kiểm thử phải có khả năng khám phá thông tin. Chúng không cần thiết phải được thiết kế để phát hiện một khiếm khuyết nào đó. Vì vậy, có thể định nghĩa một ca kiểm thử như một tập các câu lệnh được thiết kế để phát hiện ra một lớp đặc biệt các khiếm khuyết có thể gây ra lỗi. Một ca kiểm thử bao gồm các mục kiểm thử, đặc tả đầu vào, đầu ra và các nhu cầu về môi trường. 1.2.2 Kiểm thử hộp đen và hộp trắng Hầu hết các kiểm thử dựa vào rủi ro đều là kiểm thử hộp đen. Kỹ thuật này cũng được gọi là kiểm thử chức năng hoặc kiểm thử dựa vào đặc tả yêu cầu. Kiểm thử hộp đen chỉ chú trọng đến chức năng của chương trình. Nó 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, cung cấp cho hệ thống các số liệu vào và quan sát các kết qủa ra. Kiểm thử hộp đen kiểm tra xem các kết quả của một chương trình với các số liệu vào đã cho có phù hợp với đặc tả chức năng của chương trình không. Thuật ngữ hộp đen có nghĩa là người kiểm thử không xem xét đến việc thực hiện bên trong của chương trình được thực thi như thế nào. Vì thế, kiểm thử hộp đen không cần phải do người lập trình thực hiện. Trong đa số các hãng công nghệ lớn trên thế giới đều có một nhóm làm công việc thiết kế trong khi một nhóm khác thì làm kiểm thử. Kiểm thử hệ thống dựa trên các rủi ro nên được dùng cùng với các kỹ thuật khác. Kiểm tra và kiểm thử mã chương trình trong khi thực thi kiểm thử cũng rất quan trọng. Cách kiểm thử này được gọi là kiểm thử hộp trắng và nó kiểm thử các kết quả ra của một chương trình với các số liệu đầu vào nhất định xem có phù hợp với thiết kế trong và sự thực thi của chương trình không. Thuật ngữ “hộp trắng” chỉ ra rằng người kiểm thử phải xem xét thật kỹ lưỡng việc thực thi bên trong chương trình được kiểm thử. 14 Thông thường, hầu hết các sai sót đều được phát hiện trong những pha kiểm thử đầu tiên này và rất dễ sửa chữa. Tuy nhiên, kiểm thử hộp đen mới là yếu tố căn bản đảm ảo cho chất lượng của hệ thống trước khi được chuyển giao. 1.2.3 Quá trình kiểm thử Chúng ta đã nói đến hai cách kiểm thử: Kiểm thử hộp đen và Kiểm thử hộp trắng. Việc kiểm thử được thực hiện như thế nào là tùy thuộc vào quá trình phát triển và bản chất của phần mềm được phát triển. Điều quan trọng là phải nghĩ ngay đến việc kiểm thử ngay khi dự án bắt đầu. Tức là ngay khi một ai đó đưa ra một yêu cầu thì phải có một người nào đó chịu trách nhiệm kiểm thử cho nó. Một yêu cầu không được kiểm thử sẽ bị bỏ qua và bị quên lãng. Kiểm thử là một công việc tương đối tỷ mẩn, mất nhiều thời gian và tiền của. Vì thế cần phải tiến hành lập kế hoạch cho quá trình kiểm thử sao cho đạt được kết quả tốt nhất. Kiểm thử được thực hiện trong tất cả các pha của quá trình phát triển nhưng các hoạt động lại thay đổi. Ở các giai đoạn ban đầu, việc kiểm thử do người lập trình thực hiện và bao gồm kiểm tra và kiểm thử đơn vị. Có hai cách tiếp cận có thể áp dụng cho qui trình kiểm thử: kiểm thử từ dưới lên (bottom-up) và kiểm thử từ trên xuống (top-down). Bottom-up tích hợp một số module sau khi được kiểm thử đơn vị thành các thành phần và các thành phần này sẽ được kiểm thử cho đến khi chúng ổn định. Sau đó, một số module nữa tiếp tục được thêm vào và hệ thống lại được kiểm thử lần nữa. Việc này được làm cho đến khi tất cả các module được tích hợp vào hệ thống. Kiểm thử bottom-up có thể được thực hiện ngay khi một số module hoàn thành và cần ghép với nhau. Tuy nhiên cách tiếp cận này tương đối chậm và người ta có cảm giác là đang kiểm thử trên bản mô phỏng chứ không phải 15 trên một hệ thống thật. Ngoài ra, không có một hệ thống thực nào lại hành động đúng như hệ thống mô phỏng. Cách tiếp cận top-down rất thích hợp trong trường hợp cần phải tích hợp nhiều hệ thống thành một hệ thống càng nhanh càng tốt. Sau đó, nếu có thể thì sẽ kiểm thử hệ thống từ giao diện người dùng. Cách tiếp cận top-down sẽ bắt đầu với những pha tích hợp. Điều đó đòi hỏi tất cả các module đều làm việc và qua được kiểm thử đơn vị. Sau đó, sẽ kiểm thử hệ thống như một tổng thể hoàn chỉnh. Các phương pháp kiểm thử trình bày trong luận văn này được phát triển cho cách tiếp cận top-down. 1.2.4 Kiểm thử và rủi ro Trong thực tế, công việc kiểm thử thường được tiến hành rất muộn khi dự án không còn nhiều thời gian và tiền bạc. Rút ngắn thời gian để nhanh chóng đưa sản phẩm ra thị trường và giảm giá thành là hai yếu tố rất quan trọng đối với các hãng phát triển phần mềm và do đó các hãng này sẽ không bao giờ có đủ tài nguyên để đáp ứng các yêu cầu này. Nếu hệ thống phải được chuyển giao đúng hạn thì rất nhiều thứ sẽ không được kiểm thử. Các nhà quản lý thường lựa chọn chuyển giao hệ thống đúng hạn thay vì chuyển giao một hệ thống hoàn chỉnh. Việc kiểm thử rất tốn kém và thường được dự toán rất thấp. Những thống kê gần đây cho thấy trong nhiều tổ chức phát triển phần mềm, việc chi phí cho kiểm thử phần mềm chiếm từ 30 tới 50% chi phí phát triển phần mềm. Tuy chi phí cao như vậy rồi mà nhiều người vẫn còn cho là phần mềm vẫn chưa được kiểm thử cẩn thận trước khi phân phối. Nếu dự toán chi phí một cách hợp lý thì nó sẽ ngốn phần lớn các nguồn lực từ phần còn lại của qui trình phát triển. Kết cục là các phần mềm đã không được kiểm thử một cách toàn diện và được chuyển giao trong tình trạng không đầy đủ chức năng. 16 Do các phần mềm ngày nay thường rất phức tạp và có kích thước lớn nên trong quá trình phát triển hệ thống không thể tránh khỏi các sai sót. Myers [6] đã đưa ra một ví dụ về một chương trình chỉ gồm có 20 dòng mã mà có thể có đến hơn hàng tỉ trạng thái khác nhau để kiểm thử. Kiểm thử được tất cả các trạng thái là một nhiệm vụ bất khả thi đối với một người kiểm thử. Một chương trình đơn giản đã khó như vậy thì những ứng dụng thương mại với hàng trăm nghìn dòng mã sẽ có bao nhiêu điều không chắc chắn. Sẽ luôn luôn tồn tại nhiều khiếm khuyết không bao giờ được nhận dạng và do đó sẽ tiềm ẩn rất nhiều rủi ro. Mặt._. khác, nhiều khiếm khuyết trong số này sẽ không bao giờ xuất hiện. Adam [1] đã công bố một số liệu chứng minh rằng chỉ một phần trăm nhỏ của những khiếm khuyết này gây ra hầu hết các vấn đề. Việc tìm thấy những lỗi này sẽ quan trọng hơn rất nhiều so với việc tìm thấy những lỗi khác. Những việc này tạo ra nhiều sức ép cho người kiểm thử. Bằng cách nhận dạng và phân loại các mối nguy hiểm và các chỉ số rủi ro, chúng ta có thể đảm bảo rằng với một khoảng thời gian và một lượng tài nguyên có hạn có thể giữ được mức rủi ro ở mức càng thấp càng tốt. 1.3 Kiểm thử dựa trên các rủi ro Việc phân tích rủi ro nhằm mục đích nhận dạng và đánh giá các chỉ số gây nguy hại tới độ an toàn của hệ thống. Phần này sẽ giới thiệu sơ lược về một số cách phân tích rủi ro: Phân tích sơ bộ các mối hiểm nguy (PHA – Preliminary Hazard Analysis), Phân tích các kiểu lỗi và hậu quả (FMEA – Failure Modes and Effect Analysis), Phân tích rủi ro và khả năng thực hiện (HazOp), và Phân tích theo kinh nghiệm. Sau đó sẽ xem xét có thể phòng ngừa những nguy hiểm này như thế nào. 17 1.3.1 Phân tích sơ bộ các mối nguy hiểm (PHA) Mọi phân tích rủi ro đều bắt đầu bằng việc nhận dạng các chướng ngại và các mối nguy hiểm. Việc này cần được thực hiện một cách có hệ thống. PHA được thực hiện ngay từ pha thiết kế. PHA sẽ cố tìm ra các mối nguy hiểm tiềm ẩn trong dự án để có thể loại trừ, giảm thiểu hoặc kiểm soát chúng trước khi quá muộn. Mỗi lỗi tiềm ẩn có thể có nhiều nguyên nhân và ảnh hưởng, và mỗi một nguyên nhân lại có thể có nhiều cách phòng ngừa. Ưu điểm của PHA là nó không đòi hỏi quá nhiều thông tin để thực hiện. Bảng 1.1 là một ví dụ về một bảng PHA. Nguy cơ Nguyên nhân Ảnh hưởng chính Hành động phòng ngừa Tìm thấy các chẩn đoán sai Các chẩn đoán sai đã được thêm vào Làm chết hoặc làm đau bệnh nhân Kiểm tra hai lần tất cả những thông tin về bệnh nhân đã được chèn vào Bảng 1.1 Bảng PHA 1.3.2 Phân tích các kiểu lỗi và hậu quả (FMEA) FMEA thường được thực hiện trong quá trình xây dựng phần mềm với mục đích nhận ra các thành phần của hệ thống cần được nâng cấp để đáp ứng được các yêu cầu về an toàn và tin cậy của hệ thống. FMEA chủ yếu là phân tích chất lượng, trừ những trường hợp nghiêm trọng mà có thể chỉ ra nhờ xác suất. Bước đầu tiên là tìm xem một đơn vị có thể mắc lỗi như thế nào và xác định ảnh hưởng của lỗi. Bước thứ hai là đánh giá mức độ nghiêm trọng của loại lỗi này. FMEA là một phương pháp dễ thực hiện nhưng nó đòi hỏi một kiến thức vững vàng về hệ thống. Một vấn đề khác nữa là nó chỉ hoạt động được nếu các lỗi này độc lập với nhau. Bảng 1.2 là một ví dụ về cấu trúc của một bảng FMEA. 18 Đơn vị Kiểu lỗi Ảnh hưởng của lỗi Tỷ lệ lỗi Độ nghiêm trọng Hành động Bảng 1.2 Cấu trúc của bảng FMEA 1.3.3 Phân tích lỗi tiềm ẩn và khả năng thực hiện (HazOp) HazOp là một phương thức phân tích rủi ro hình thức và có hệ thống hơn. Phương pháp này sẽ cần đến mô tả cấu trúc hệ thống để xác định các nút cần nghiên cứu. Như thế có nghĩa là HazOp phải tiến hành khá muộn trong quá trình phát triển, khi mà kiến trúc hệ thống đã được hình thành rõ ràng. Các nút nghiên cứu là các điểm của hệ thống nơi chúng ta sẽ tập trung phân tích. Chúng có thể là những điểm nơi hệ thống tương tác với môi trường của nó (đầu vào, đầu ra), hoặc nơi mà các bộ phận của hệ thống trao đổi thông tin với nhau. HazOp gồm hai thành phần cấu trúc: bảng và các từ hướng dẫn. Bảng 1.3 là một ví dụ về một bảng HazOp. Các từ hướng dẫn giải thích một điều gì đó về nút cần nghiên cứu. Các từ đời thường như "không có", "ít hơn", "nhiều hơn", "một phần của", "bổ sung", "khác hơn" sẽ được sử dụng. Các từ hướng dẫn thường tập trung vào việc tạo ra sự chú ý của người sử dụng, và họ có thể đặt các câu hỏi như: "Các từ hướng dẫn này có ý nghĩa gì trong hệ thống hoặc điểm cần nghiên cứu này?" Từ hướng dẫn Điểm nghiên cứu Hậu quả Nguyên nhân Giải pháp có thể Thiếu Thông tin bệnh nhân Thông tin không đầy đủ; Điều trị sai; Làm chết hoặc làm đau bệnh nhân Không được cập nhật; Mất cập nhật; Cập nhật không đầy đủ Kiểm tra và cho ngừng cập nhật; Cơ sở dữ liệu đối chứng Bảng 1.3: Bảng HazOp 19 1.3.4 Kiểm thử dựa trên rủi ro theo kinh nghiệm Bach [3] đã mô tả một phân tích heuristic để thực hiện kiểm thử dựa vào rủi ro. Ông ta cho rằng heuristic là một cách hướng sự chú ý của mình đến chỗ thành công. Phương pháp do Bach sử dụng chưa phải là cuối cùng hoặc chặt chẽ. Kinh nghiệm của con người được sử dụng để tìm ra những khu vực có rủi ro cao nhất. Bach đã đưa ra hai cách tiếp cận dùng cho kiểm thử dựa vào rủi ro theo kinh nghiệm được là từ trong ra ngoài (inside-out) và từ ngoài vào trong (outside-in). Trong cách tiếp cận inside-out, người kiểm thử nghiên cứu sản phẩm cùng với người phát triển và đặt các câu hỏi như "Cái gì có thể bị lỗi ở đây?". Đối với từng bộ phận của sản phẩm, người kiểm thử sẽ tìm các mối hiểm nguy, các mối đe dọa và các nạn nhân. Đây cũng là phương pháp tiếp cận đã sử dụng trong FMEA. Phương pháp tiếp cận outside-in bắt đầu với một tập hợp các rủi ro tiềm ẩn và đối sánh chúng với các chi tiết của tình huống. Một danh sách của các rủi ro đã được định nghĩa trước sẽ được tham khảo và sử dụng để xác định xem chúng xảy ra ở đây và vào thời điểm này hay không. Bach sử dụng 3 loại danh sách: phân loại theo tiêu chuẩn chất lượng, danh sách rủi ro tổng quát, và các danh mục rủi ro. Các nhóm tiêu chuẩn chất lượng: được thiết kế để gợi nên các yêu cầu như khả năng, độ tin cậy, tính hữu dụng, hiệu suất, khả năng cài đặt, tính tương thích, tính hỗ trợ, tính dễ kiểm thử, khả năng dễ bảo trì, tính dễ di chuyển, và tính địa phương hóa. Danh sách rủi ro tổng quát: là một danh sách các rủi ro có thể áp dụng được cho mọi hệ thống. 20 - Phức hợp: bất cứ thứ gì lớn một cách không cân đối, phức tạp, hoặc rối rắm - Mới: bất cứ thứ gì chưa có trong lịch sử của sản phẩm - Bị thay đổi: bất cứ thứ gì đã từng bị thay đổi hoặc "nâng cấp" - Phụ thuộc ngược lên bất cứ thứ gì mà mà sự hỏng hóc của nó có thể gây ra hỏng hóc dây truyền trong phần còn lại của hệ thống - Phụ thuộc xuôi xuống: bất cứ thứ gì đặc biệt nhạy cảm với các sai hỏng trong phần còn lại của hệ thống - Tính quyết định: bất cứ thứ gì mà hoạt động sai sẽ gây ra những tổn hại nghiêm trọng - Tĩnh chính xác: bất cứ thứ gì đòi hỏi phải đáp ứng các yêu cầu của nó một cách chính xác - Tính phổ dung: bất cứ thứ gì được sử dụng một cách rộng rãi - Tính chiến lược: bất cứ thứ gì có tầm quan trọng đặc biệt với việc kinh doanh, ví dụ như một đặc điểm làm bạn khác với đối thủ cạnh tranh - Bên thứ ba: bất cứ thứ gì được sử dụng trong sản phẩm, nhưng được phát triển bên ngoài dự án - Phân tán: bất cứ thứ gì có thể được nhân rộng ra trong không gian và thời gian, nhưng các phần tử của nó vẫn phải làm việc cùng nhau - Có rệp: bất cứ thứ gì được biết đến là có nhiều vấn đề - Sai sót vừa xong: bất cứ thứ gì vừa bị sai xong Bảng 1.4: Danh sách rủi ro tổng quát Danh mục rủi ro là một danh sách các rủi ro thuộc về một lĩnh vực cụ thể nào đó. Dưới đây là một ví dụ về danh sách rủi ro trong quá trình cài đặt. Các vấn đề có thể xảy ra trong lĩnh vực này sẽ được liệt kê: - Các files được cài đặt không đúng, không đủ + Không xóa hết các file tạm thời + Các file cũ không được xóa sạch sau khi đã được nâng cấp. + Cài đặt các file không cần thiết + Không cài đặt các file cần thiết + File được cài đặt đúng nhưng vào sai vị trí 21 - Các files bị lẫn lộn + File mới hơn bị thay thế bằng file cũ + File dữ liệu của người sử dụng bị xóa trong quá trình nâng cấp - Lẫn lộn với các ứng dụng khác + Các file được dùng chung với các sản phẩm khác bị sửa đổi + Các file thuộc về sản phẩm khác bị xóa - Phần cứng được cấu hình không phù hợp + Phần cứng bị lẫn lộn cho các ứng dụng khác + Phần cứng không được thiết lập cho ứng dụng cần cài đặt - Chương trình screen saver làm gián đoạn quá trình cài đặt - Không phát hiện các ứng dụng không tương thích + Các ứng dụng tương tranh với nhau + Các ứng dụng vừa được cài đặt - Bộ cài đặt lặng lẽ thay thế hoặc sửa đổi các file hoặc tham số quan trọng - Quá trình cài đặt quá chậm - Quá trình cài đặt đòi hỏi việc kiểm soát liên tục của người sử dụng - Quá trình cài đặt rối rắm + Giao diện người sử dụng không chính thống + Giao diện người sử dụng dễ bị sử dụng sai + Các thông báo và các hướng khó hiểu Bảng 1.5: Danh sách rủi ro cho việc cài đặt Ba loại danh sách được mô tả ở trên có thể được sử dụng để: 1. Xác định thành phần nào hoặc chức năng nào cần được phân tích 2. Quyết định mức độ liên quan. Mọi thứ đều được coi là có một độ rủi ro bình thường trừ khi có lý do để tin vào điều khác 3. Thu thập thông tin về những thứ cần phân tích thêm 4. Xác định mức độ quan trọng của từng nguy cơ 5. Ghi lại các rủi ro chưa có trong danh sách 6. Ghi lại mọi bất kỳ điều gì chưa biết mà lại tác động vào khả năng phân tích rủi ro 7. Kiểm tra sự phân bố rủi ro 22 Có ba cách để tổ chức kiểm thử dựa theo rủi ro được đề xuất là danh sách theo dõi rủi ro, ma trận rủi ro/tác vụ, và ma trận rủi ro thành phần. Danh sách theo dõi rủi ro là một danh sách các rủi ro cần phải theo dõi định kỳ trong thời gian mà dự án được cho là hay gặp những rủi ro thông thường nhất. Ma trận rủi ro/tác vụ sắp xếp các rủi ro theo mức độ nghiêm trọng của chúng. Các tác vụ cần phải được đầu tư thich đáng nhằm giảm thiểu tác hại của rủi ro đã được liệt kê. Đây là một công cụ hiệu quả nhất khi mà các nguồn lực giành cho kiểm thử đang phải cân nhắc. Ma trận rủi ro của các thành phần phân chia sản phẩm thành 30 hoặc 40 lĩnh vực hoặc thành phần. Các thành phần được liệt kê ở cột bên trái. Ở cột giữa là các mức độ liên quan “thấp”, “bình thường”, hoặc “cao”. Cột bên phải là rủi ro dự đóan theo kinh nghiệm cho thành phần này. Trong quá trình kiểm thử, các thành phần được kiểm thử trên cơ sở các rủi ro của chúng như đã được chỉ ra trong ma trận. Thành phần Mức rủi ro Rủi ro theo kinh nghiệm In Bình thường Phân tán, phổ dụng Sinh báo cáo Cao Mới, chiến lược, bên thứ ba, phức hợp, quyết định Cài đặt Thấp Phổ dụng, hữu dụng, dễ thay đổi Thư viện đồ họa Thấp Phức hợp Bảng 1.6: Ma trận rủi ro của các thành phần 1.3.5 Ngăn ngừa các mối nguy hiểm Để ngăn ngừa các mối nguy hiểm đã nhận dạng được không trở thành hiện thực thì cần phải chú ý đặc biệt đến chúng. Gerrard [4] cho rằng ngăn chặn các lỗi không cho chúng xảy ra cũng rất quan trọng đối với người kiểm thử. Người kiểm thử chịu trách nhiệm ngăn chặn cũng như phát hiện ra các lỗi. Họ buộc phải tác động để người phát triển cùng hành động nhằm giảm thiểu nguy cơ. 23 IEC [9] đã định nghĩa một vài thuật ngữ liên quan đến giảm thiểu lỗi. Nó chỉ ra rằng việc giảm thiểu rủi ro khi thực hiện các hệ thống có liên quan đến an toàn là rất quan trọng. Giảm bớt rủi ro để đáp ứng được mức rủi ro chấp nhận được cho một tình huống cụ thể được gọi là giảm thiểu rủi ro cần thiết. Rủi ro chấp nhận được phụ thuộc vào xác suất và hậu quả của một sự kiện nguy hiểm cụ thể. Một hệ thống liên quan đến cần phải thỏa mãn tiêu chuẩn giảm thiểu rủi ro cần thiết. Phương pháp để đạt được mức rủi ro chấp nhận được thường được gọi là "thấp đến mức được thực tế chấp nhận" (ALARP – as low as reasonable practicable). Mức rủi ro được chia ra thành các vùng. Vùng nằm giữa rủi ro không thể chấp nhận được và rủi ro có thể chấp nhận được thì được gọi là vùng ALARP. Vùng này được xác định là một vùng vẫn còn nhiều rủi ro, nhưng nó có thể được chấp nhận nếu một lợi ích nào đó đã đạt được. Những tốn kém cho việc giảm bớt rủi ro sẽ phụ thuộc vào độ lớn của rủi ro đó. Điều này được minh họa trong Hình 1.7, trong đó vùng ALARP được đặt ở giữa. Hình 1.1 Vùng ALAPR Rủi ro không thể chấp nhận được trừ những trường hợp thật đặc biệt Vùng không thể chấp nhận được Vùng ALARP Chấp nhận được (rủi ro được chấp nhận nếu một lợi ích nào đó đã đạt được ) Vùng được chấp nhận rộng rãi Chỉ chấp nhận nếu việc giảm rủi ro thêm nữa là không thực tế hoặc nếu chi phí quá vô lý so với những gì thu được Rủi ro không đáng kể Khi rủi ro được giảm bớt thì cần thiét phaỉ giảm tiếp để thỏa mãn ALARP. Khái niệm giảm thiểu tỷ lệ được thể hiện bằng hình tam giác 24 Để giảm thiểu rủi ro, gần như mọi rủi ro nghiêm trọng đều phải được chú ý đặc biệt. Tập trung vào kiểm thử và phân tích mã chương trình có thể cũng là một giải pháp. Một cơ hội khác là phân tích cấu trúc của chương trình và tối thiểu hóa rủi ro. Có một cách để thực hiện việc này là sử dụng phương pháp phân tích cây sai sót (FTA). Việc phân tích này có thể hữu ích trong nhiều lĩnh vực nhưng không phải là phương pháp hiệu quả nhất trong lĩnh vực phần mềm. Điều này đặc biệt đúng trong các hệ thống yêu cầu độ an toàn cao, những hệ thống mà nên được đảm bảo an toàn bằng cách sử dụng các hệ thống cho phép dư thừa (tài nguyên) và cho phép tiếp tục hoạt động mặc dù vẫn mắc lỗi. Chấp nhận điều đó sẽ có lợi hơn là phải mở rộng năng lực của thiết kế. Trong những phần mềm phức tạp, rất khó để đảm bảo rằng mọi việc đều đúng đắn và không lãng phí thời gian. Do đó chúng ta cần phải tránh những giải pháp quá phức tạp. Một kỹ thuật dễ dàng và hiệu quả hơn đó là ngăn cản không cho sự kiện gây ra lỗi xảy ra, hoặc ngăn cản hoặc giảm thiểu ảnh hưởng của sự kiện này. Cái đó được gọi là một thanh chắn hoặc rào cản. Smith [8] đã định nghĩa “thanh chắn là một chướng ngại có thể (i) ngăn cản, không cho một hành động được thực hiện hoặc một sự kiện nào đó được xảy ra, hoặc (ii) ngăn cản hoặc giảm thiểu tác hại của hậu quả, hạn chế tầm ảnh hưởng của hậu quả hoặc làm yếu chúng đi theo một cách nào đó". Đây có thể là một giải pháp kết hợp xã hội - kỹ thuật giống như dấu hiệu không hút thuốc hoặc các cảnh báo. Tóm tắt Chương 1 Tóm lại, trong chương này chúng ta đã tìm hiểu được rủi ro là gì và cách phòng ngừa, xử lý các rủi ro. Đồng thời, chúng ta cũng đã hiểu rõ hơn kiểm thử phần mềm là gì và có các loại hình kiểm thử nào. Đặc biệt là nghiên 25 cứu tìm hiểu một số phương pháp kiểm thử dựa trên các rủi ro đã phát hiện được khi phân tích. Chương sau sẽ trình bày về cách thức sắp xếp thứ tự ưu tiên cho các kiểm thử theo mức độ nguy hiểm của các rủi ro. 26 Chương 2 Phân loại ưu tiên các kiểm thử Trong chương trước, tiêu điểm là tìm hiểu xem phần mềm bị sai hỏng như thế nào và quyết định nên kiểm thử cái gì. Trong chương này này, mục tiêu là phát hiện ra những bộ phận nào của phần mềm gây rủi ro nhiều hơn so với các bộ phận khác. Sau đó sẽ sắp xếp ưu tiên kiểm thử cho những bộ phận có nguy cơ xảy ra sai sót cao hơn trước. Để làm được điều đó, trước tiên phải tìm xem những nhân tố nào sẽ tác động lớn đến các thiệt hại do rủi ro gây ra. Những bộ phận quan trọng của hệ thống nếu bị hư hại có thể sẽ gây ra thiệt hại lớn hơn. Những nhân tố làm tăng xác suất xuất hiện rủi ro liên quan đến quá trình phát triển và lập trình sẽ được trình bày trong các mục 2.1 và 2.2. Những nhân tố này được gọi là những tác nhân gây lỗi vì chúng được sử dụng để xác định các bộ phận hệ thống có nhiều lỗi. Hai ví dụ về việc sử dụng các nhân tố này sẽ được trình bày trong các mục còn lại. 2.1 Các nhân tố gây ra thiệt hại Có một số cách để tìm ra các nhân tố gây ra thiệt hai. Các nhân tố gây thiệt hại là các nhân tố được xem xét đối với một bộ phận nào đó của hệ thống mà sẽ gây ra mất mát lớn hơn nếu có các sai sót trong bộ phận này. Thứ nhất là phải xem xem từng bộ phận của hệ thống có vai trò, được hiện hữu và được sử dụng như thế nào trong hệ thống. Thứ hai là phải xem xét những hậu quả của các sai sót này sẽ gây thiệt hại cho người bán (người phát triển hệ thống) và người mua (người sử dụng hệ thống) như thế nào. Các hậu quả ở đây có thể là vô hình như mất thương hiệu (danh dự, uy tín), chịu các hình phạt về luật pháp hoặc hữu hình như chi phí bảo trì cao hơn chẳng hạn. Trong giải pháp mới được đề xuất ở Chương 3 sẽ sử dụng kết hợp cả hai quan điểm này về các chỉ số tác động tới các thiệt hại do rủi ro gây ra. 27 Một hỏng hóc nào đó trong một bộ phận quan trọng của hệ thống có thể sẽ dẫn đến mất uy tín. Những hỏng hóc trong một số bộ phận của hệ thống có thể sẽ đáng trách hơn so với ở các bộ phận khác. Để đánh giá được một hỏng hóc sẽ ảnh hưởng như thế nào thì cần phải tiến hành phân tích các hậu quả do nó gây ra. Nếu khách hàng không thể làm việc với phần mềm và mất thời gian và tiền bạc do chương trình bị hỏng hóc, hoặc có thể còn dẫn đến mất hoặc hỏng dữ liệu, thì người cung cấp sản phẩm này sẽ phải bồi thường một khỏan lớn. Nhưng nếu những hỏng hóc tại bộ phậnn đó của hệ thống lại khiến khách hàng sử dụng một cách khác để đạt được mục đích thì sẽ ít đáng trách hơn và thiệt hại có thể coi như ở mức trung bình. Một bộ phận của hệ thống được gọi là không quan trọng lắm nếu nó có hỏng thì chỉ gây trở ngại cho người dùng mất công đi tìm cách khác hoặc chỉ làm cho chương trình ít hấp dẫn hơn mà thôi. Một số bộ phận của hệ thống có thể xuất hiện thường xuyên hơn và nhiều người dùng có thể sẽ trải nghiệm những rắc rối trong các bộ phận này. Ở đây, cần phải có sự châm trước của người sử dụng. Các phần mềm được phát triển cho những người chưa có kinh nghiệm hoặc những người chưa biết gì như các phần mềm đại chúng cần phải chú chú ý đặc biệt đến các giao diện với người dùng và phải thật rành mạch và ổn định. Một số chức năng được sử dụng thường xuyên ở một mức độ nào đó cũng là một điều quan trọng cần phải xét đến khi tính toán các chi phí. Một số chức năng có thể được sử dụng hàng ngày trong khi một số khác thì chỉ thi thoảng. Có thể có một chức năng nào đó không nhìn thấy được từ bên ngoài nhưng vẫn thường được sử dụng thường xuyên ví dụ như các hệ thống điều khiển quá trình. Những hỏng hóc trong một số bộ phận của hệ thống có thể làm mất tín nhiệm đối với khách hàng hoặc nhà cung cấp. Việc mất tín nhiệm có thể dẫn 28 đến mất khách hàng và thị phần. Nguy hiểm hơn, những bộ phận được sử dụng và nhìn thấy được của hệ thống như đã nói ở trên sẽ là nguyên nhân tạo ra sự mất tín nhiệm nhiều hơn. Do trong phần mềm thường còn tồn tại một số lỗi nên chi phí cho bảo trì chiếm một tỷ lệ khá cao (khoảng 50 - 75%) trong tổng chi phí mua bản quyền. Khoảng một nửa số tiền bảo trì là dành cho việc phát triển chức năng mới, nhưng sửa lỗi cũng là một chi phí khá cao. Những hậu quả về mặt luật pháp cũng có thể dính dáng đến một vài hệ thống. Vi phạm luật pháp có thể sẽ phải chịu các hậu quả lớn đối với các công ty có liên quan. 2.2 Các hành động phát sinh sai sót trong quá trình phát triển Xác suất hỏng hóc thường tăng trong các bộ phận hệ thống có nhiều khiếm khuyết hơn. Chúng ta sẽ xem xét một vài nhân tố có thể phát sinh ra những khiếm khuyết này. Các hành động dẫn tới phát sinh lỗi thường liên quan đến việc lập trình, như độ phức tạp, số lỗi tìm thấy trong thời gian kiểm tra hoặc kiểm thử ban đầu và những thay đổi trong khi phát triển. Những vấn đề này sẽ được trình bày rõ trong phần tiếp theo. Trong phần này, chúng ta sẽ trình bày về các hành động phát sinh lỗi do qui trình như đưa vào các phương pháp, các công cụ hoặc công nghệ mới và bao nhiêu kỹ sư phát triển với trình độ như thế nào thì đủ để làm việc trên từng bộ phận của hệ thống. Các lỗi thường được phát sinh khi người ta không tập trung vào việc loại trừ các lỗi do sức ép về thời gian và việc tối ưu hóa việc lập trình. Những người phát triển có sử dụng các phương pháp mới, các công cụ hoặc công nghệ mới có thể sẽ sinh thêm một số lỗi. Những người này có thể sinh thêm nhiều lỗi hơn khi bắt đầu quá trình, và ít lỗi hơn khi họ học được cách sử dụng công nghệ mới. Sẽ luôn luôn có các rủi ro đối với những ai là 29 người đầu tiên sử dụng các phương pháp, công cụ hoặc công nghệ mới vì vẫn còn tồn tại những vấn đề chưa phái hiện hết. Số lượng người tham gia lập trình cũng có thể ảnh hưởng tới chất lượng mã chương trình. Tốt nhất là nên sử dụng một nhóm nhỏ có trình độ cao và lành nghề còn hơn là các nhóm lớn những người không chuyên. Các nhóm lớn những người có trình độ thấp có thể cũng làm được việc với cùng một chi phí nhưng có thể họ sẽ tạo ra nhiều lỗi mà sẽ gây ra sự cố sau này. Các bộ phận của hệ thống do những người không đủ trình độ thực hiện cần phải kiểm thử nhiều hơn. Nhiều công ty giao cho những người tốt nhất của họ xây dựng các bộ phận phức tạp nhất. Sức ép về thời gian trong khi phát triển có thể sẽ ảnh hưởng đến việc thực thi dự án. Khi không còn nhiều thời gian, những người lập trình chỉ quan tâm đến việc làm cho xong công việc hơn là tránh mắc lỗi và thường bỏ qua việc kiểm soát chất lượng. Làm việc ngoài giờ cũng có thể gây ra sự mất tập trung và có thể sẽ có nhiều lỗi hơn khi viết mã. Cũng có thể là những cuộc xung đột giữa những người quản lý mà ảnh hưởng số lượng của lỗi. Những người làm chủ chốt có thể bỏ việc. Đây là một vấn đề khó giải quyết nếu họ là những con người chính và duy nhất cho tổ chức. 2.3 Phát sinh lỗi trong khi lập trình Độ phức tạp của hệ thống là nguyên nhân phát sinh lỗi quan trọng nhất nhưng rất khó đánh giá. Độ phức tạp càng cao thì càng dễ mắc sai sót. Có thể tiến hành một số phân tích về độ phức tạp dựa vào các khía cạnh khác nhau của độ phức tạp. Kích thước cũng có thể được sử dụng như là một chỉ báo về độ phức tạp. Kích thước thường được đo bằng số dòng mã (LOC) không kể các dòng chú thích và các dòng trống. Người ta thống nhất là chỉ đếm những 30 dòng mã có thể thực hiện được. Một nghiên cứu đã chỉ ra rằng có thể có một kích thước chương trình tối ưu mà có thể đưa tới một tỷ lệ sai sót thấp nhất. Số lượng lỗi phát hiện được trong khi thanh tra hoặc trong các pha kiểm thử đầu tiên có thể cho biết nơi nào sau này có thể phát sinh nhiều lỗi. Sau khi biết được số lỗi, chúng ta có thể đánh giá chất lượng chương trình thông qua tỷ số giữa số lỗi và kích thước mã. Kích thước mã có thể là số dòng mã LOC hoặc các điểm chức năng (functional points), nếu các điểm này được tính và được sử dụng. Tùy thuộc vào tỷ lệ này lớn hay bé mà ta có thể biết được chất lượng của mã là xấu hay tốt. Những bộ phận của hệ thống bị thay đổi nhiều trong khi phát triển có thể có nhiều khiếm khuyết hơn so với những bộ phận khác. Những gì được thay đổi thì dễ nhận ra nhưng thường được thực hiện trong một thời gian gấp gáp. Chúng thường gây ra rắc rối bởi vì không được phân tích kỹ càng. Những bộ phận bị thay đổi của hệ thống có thể có một thiết kế tồi ngay từ đầu hoặc những thay đổi này có thể đã phá hủy thiết kế gốc. Số lượng các thay đổi đã được thực hiện trong suốt quá trình phát triển cần phải được ghi lại. Amland [1] đã sử dụng chất lượng thiết kế làm một trong những nhân tố quan trọng thể hiện xác suất hỏng hóc trong phân tích rủi ro. 2.4 Kiểm thử hệ thống theo độ phơi nhiễm rủi ro Để quyết định nên kiểm thử những vấn đề nào trước, chúng ta cần phải biết vấn đề nào trong số những vấn đề này có thể gây ra nguy hiểm nhất. Amland đã đưa ra một ví dụ mô tả phương pháp sử dụng độ phơi nhiễm rủi ro để lựa chọn chức năng cần kiểm thử trước. Đây là một ví dụ về lựa chọn các kiểm thử theo rủi ro đối với một ứng dụng được phát triển cho dịch vụ bán lẻ của ngân hàng. Trong khi thực hiện dư án này, người ta nhận ra rằng không 31 có đủ nguồn lực để kiểm thử mọi thứ. Hệ thống này bao gồm hai phần và mỗi phần sử dụng một cách tiếp cận khác nhau để quyết định nên kiểm thử cái gì. Trong phần thứ nhất của hệ thống, một tổ hợp gồm 20 giao tác quan trọng nhất và tất cả những giao tác có hơn 10 lỗi đã được kiểm thử trước đó. Việc này được tiến hành từ khá sớm và có rất ít thông tin có thể lấy được từ đội phát triển hệ thống. Sau đó, khi đã có nhiều thông tin hơn, nhiều nhân tố đã được xem xét thêm. Những nhân tố như thiệt hại do lỗi gây ra cho khách hàng C(c) và cho người bán hàng C(v) trong các lĩnh vực gồm bảo trì, các phát sinh từ luật pháp và uy tín đã được xem xét đối với từng chức năng. Thiệt hại do lỗi gây ra cho khách hàng và người bán hàng có tầm quan trọng như nhau nên thiệt hại đối với mỗi chức năng được tính bằng công thức (C(c) + C(v))/2. Xác suất mắc lỗi của từng chức năng f ký hiệu là P(t) sẽ được tính toán mỗi khi mã nguồn phải thay đổi hoặc một chức năng mới cần thêm vào, hoặc do chất lượng thiết kế, do độ lớn và độ phức tạp. Các nhân tố này được gán các trọng số có giá trị từ 1 đến 5 với ý nghĩa là trọng số cao hơn thì thể hiện chất lượng thấp hơn: + Bị thay đổi hoặc chức năng mới: 5 + Chất lượng thiết kế: 5 + Độ phức tạp 3 + Độ lớn chương trình: 1 Sau đó, đối với mỗi chức năng của hệ thống, xác xuất cho tất cả các chỉ số sẽ được xem xét để được gán các giá trị từ 1 đến 3. Tiếp theo, các trọng số và các giá trị tương ứng của các nhân tố đối với từng chức năng sẽ được nhân với nhau để tính trung bình (trung bình theo trọng số). Xác suất xảy ra lỗi ở chức năng f sẽ được tính theo công thức: 32 P(f) = Trung bình theo trọng số của f / Max của trung bình theo trọng số của tất cả các chức năng. Độ phơi nhiễm rủi ro của chức năng f được tính theo công thức: RE(f) = P(f) * (C(c) + C(v))/2 Bảng 2.1 là bảng được đung để tính độ phơi nhiễm rủi ro cho giao tác f là “đóng tài khoản”. Trong ví dụ này, thiệt hại do một lỗi gây ra cho người bán hàng tương đối thấp (nên được gán giá trị là 1), nhưng thiệt hại đối với khách hàng lại cao (nên được gán giá trị là 3). Vậy thiệt hại trung bình là 2. Các giá trị cho các nhân tố (từ 1 đến 3) đã được cho trong bảng theo thứ tự là 2, 2, 2, 3. Ngoài ra, trong ví dụ này Trung bình theo trọng số lớn nhất là 10.5. Trung bình theo trọng số = Average(5*2)+(5*2)+(1*2)+ (3*3) = 7.75 P(f) = 7.75 / 10.5 = 0.74 RE(f) = P(f) * (C(c)+C(v))/2 = 0.74 * 2 = 1.48 Thiệt hại Xác suất Chức năng C(v) C(c) Avrg. C Chức năng mới 5 Chất lượng TK 5 Độ lớn 1 Độ phức tạp 3 Trung bình TS Xác suất P(f) Độ phơi nhiễm rủi ro RE(f) Đóng Tài khoản 1 3 2 2 2 2 3 7.75 0.74 1.48 Bảng 2.1: Độ phơi nhiễm rủi ro đối với chức năng “Đóng tài khoản” 2.5 Lập thứ tự kiểm thử ưu tiên trước khi hết kỳ hạn Để tập trung ưu tiên kiểm thử những phần nào trước, chúng ta phải tìm được những bộ phận quan trọng nhất và tồi nhất của sản phẩm. Những bộ phận quan trọng nhất của hệ thống có thể được tìm thấy qua các nhân tố như thiệt hại do lỗi, những bộ phận hiện diện nhiều nhất và được sử dụng nhiều nhất của sản phẩm. Những bộ phận tồi nhất của hệ thống là những bộ phận có 33 xác suất hỏng cao nhất. Những bộ phận này có thể được tìm thấy nhờ các nhân tố phát sinh lỗi như độ phức tạp, các khu vực bị thay đổi, công nghệ mới, các giải pháp mới, các phương pháp mới, các công cụ mới, số người tham gia và những điều kiện cục bộ. Các trọng số sẽ được gán cho mỗi chỉ số thiệt hại và các yếu tố sinh lỗi. Đối với mỗi bộ phận của hệ thống, các giá trị cũng được gán cho các chỉ số và các yếu tố sinh lỗi. Các giá trị cao hơn có nghĩa là khu vực này quan trọng hơn hoặc xấu hơn những khu vực khác. Điều này được minh họa trong bảng 2.2. Bảng này được lấy từ Schaefer [7]. Các giá trị này được nhân với trọng số rồi cộng lại với nhau. Các giá trị lớn nhất cho biết các phần có rủi ro cao nhất và sẽ được ưu tiên kiểm thử trước Vùng kiểm thử Mức độ quan trọng Mức hiện diện Độ phức tạp Tần xuất thay đổi RỦI RO Trọng số 3 10 3 3 Nhận đặt hàng 2 4 5 1 46*18 Báo giá 4 5 4 2 62*18 Thống kê đơn hàng 2 1 3 3 16*18 Lập báo cáo quản lý 2 1 2 4 16*18 Thực hiện đơn hàng 5 4 0 1 55*3 Làm thống kê 1 1 0 0 13*0 Thực hiện báo giá 4 1 0 1 22*3 Bảng 2.2: Ví dụ về tính toán rủi ro 2.6 So sách các cách tiếp cận khác nhau Hai ví dụ đã được trình bày trên đây đều sử dụng rủi ro để ưu tiên kiểm thử. Nhiều người sử dụng các phương pháp tương tự như phương pháp của Amland, trong đó chủ yếu là tìm cho ra các yếu tố có thể làm tăng chi phí và 34 hậu quả do lỗi phát sinh từ một số bộ phận của sản phẩm. Amland xem xét các chi phí liên quan đến vấn đề bảo trì, những phát sinh từ phía luật pháp, và uy tín đối với người bán và khách hàng, trong khi Schaefer [7] và Besson tìm xem những chức năng nào có tầm quan trọng cao nhất và gây ra phiền phức nhất cho người sử dụng. Schaefer [7] xem xét nhiều yếu tố làm tăng khả năng có thể xảy ra đối với một lỗi nào đó do người phát triển tạo ra – các lỗi này có thể được gọi là ổ phát sinh sai sót. Từ những ổ phát sinh sai sót này, có thể tìm thấy những bộ phận có thể có nhiều lỗi nhất. Besson lại tìm hiểu xem một hỏng hóc sẽ gây trở ngại cho người sử dụng ở một mức độ nào và tần suất xuất hiện của nó để đưa ra thứ tự ưu tiên kiểm thử cái gì trước. Chen có nhiều ý tưởng giống như Amland, nhưng lại chú yếu nhiều đến các ca kiểm thử hơn là các chức năng hệ thống. Gerrard [4] sử dụng một cách khác để phân loại ưu tiên những gì phải kiểm thử. Thay vì xem xét các bộ phận khác nhau của sản phẩm, một phân tích rủi ro về các kiểu lỗi khác nhau sẽ được tiến hành. Các kiểm thử được sinh ra dựa vào các kiểu lỗi với mức ưu tiên cho các kiểu lỗi có độ rủi ro cao nhất. Việc này cũng tương tự của Stålhane và Sivertsen đã sử dụng HazOp để tìm thấy các nguy cơ rủi ro. Số lượng và độ nghiêm trọng của các mối hiểm nguy đối với mỗi chức năng được sử dụng để phân loại ưu tiên kiểm thử. Đây là một cách khác để phân loại các vùng có vấn đề trong một phân tích rủi ro. Phân tích rủi ro được thực hiện để quyết định những chức năng nào cần phải tăng cường nỗ lực hơn nữa, nhưng cũng có thể được sử dụng để quyết định những chức năng nào p._.