Bằng

CHƯƠNG 6: TESTING
Mục tiêu học tập Sau khi nghiên cứu chương này, bạn sẽ có thể • Mô tả các vấn đề đảm bảo chất lượng. • Mô tả làm thế nào để thực hiện không dựa trên thực hiện thử nghiệm(kiểm tra) của hiện vật. • Mô tả các nguyên tắc dựa trên thử nghiệm thực hiện. • Giải thích những gì cần phải được kiểm tra. 6,1 Chất lượng các vấn đề Chúng tôi bắt đầu phần này bằng cách mở rộng định nghĩa mục 1.11 liên quan đến kiểm tra. Lỗi trong phần mềm khi con người làm cho 1 sai lầm. Một sai lầm trên một phần của một phần mềm chuyên nghiệp có thể gây ra một số lỗi, ngược lại, những sai lầm khác nhau có thể gay ra lỗi giống hệt nhau. Một thất bại là hành vi quan sát không chính xác của sản phẩm phần mềm như là một hệ quả của một lỗi, và lỗi là số tiền mà kết quả không chính xác. Một thất bại cụ thể có thể được gây ra do nhiều lỗi, và một số lỗi không bao giờ có thể gay ra một thất bại. từ khiếm khuyết (defect) là một thuật ngữ chung cho một lỗi, thất bại, hoặc lỗi. Bây giờ chúng ta chuyển sang vấn đề chất lượng. chất lượng hạn thường được hiểu lầm khi sử dụng trong bối cảnh phần mềm. sau khi tất cả, chất lượng ngụ ý sự xuất sắc của một số loại, nhưng điều này không may là hiếm khi mục đích ý nghĩa bởi các kĩ sư phần mềm. Để đặt nó một cách chính xác, tất cả các tổ chức phát triển nhiều phần mềm có thể đạt được là chỉ đơn thuần là để có được phần mềm hoạt động một cách chính xác, xuất sắc là một thứ tự độ lớn hơn so với những gì nói chung là có thể cho các tổ chức tai CMM mức 1. Chất lượng của phần mềm là mức độ sản phẩm đáp ứng các thông số kỹ thuật của nó. Tuy nhiên, điều này là không đủ. Ví dụ, để đảm bảo rằng sản phẩm có thể dễ dàng duy trì, sản phẩm phải được thiết kế tốt và tỉ mỉ mã hóa. Vì vậy, nó là cần thiết rằng phần mềm có chất lượng cao, nhưng điều này không có nghĩa là đủ. Nhiệm vụ của tất cả các phần mềm chuyên nghiệp để đảm bảo phần mềm chất lượng cao ở tất cả các lần. Đó là, mỗi nhà phát triển và duy trì là cá nhân chịu trách nhiệm kiểm tra công việc của mình chính xác. Chất lượng không phải là một cái gì đó thêm vào sau đó được đảm bảo bởi nhóm SQA mà là phải được xây dựng bởi các nhà phát triển ngay từ đầu. Một trong những vai trò của nhóm SQA là để đảm bảo rằng các nhà phát triển có làm việc chất lượng cao. Nhóm SQA có trách nhiệm bổ sung, cũng như mô tả trong muc 6.11 6.1.1 Đảm bảo chất lượng phần mềm Như đã nói, một khía cạnh của vai trò nhom SQA là để thử nghiệm các sản phẩm của nhà phát triển chính xác. Chính xác hơn, một khi các nhà phát triển đã hoàn thành mọt quy trình làm việc và cẩn thận kiểm tra công việc của họ, các thành viên của nhóm SQA phải đảm bảo rằng các quy trinh làm việc thực hiện một cách chính xác. Ngoài ra, khi sản phẩm hoàn tất và các nhà phát triển tin tưởng các sản phẩm là một toàn thể chính xác, nhóm SQA có đảm bảo rằng điều này là như vậy. Tuy nhiên, đảm bảo chất lượng phần mềm đi xa hơn chỉ là thử nghiệm cuối cùng mọt công việc hoặc kết thúc của quá trình phát triển. SQA áp dụng qui trình phần mềm chính nó. Ví dụ, trách nhiệm của nhóm SQA bao gồm sự phát triển của tiêu chuẩn khác nhau mà phần mềm phải phù hợp cũng như việc thành lập giám sát thủ tục bảo đảm phù hợ với những tiêu chuẩn.

1

Tóm lại, vai trò của nhóm SQA là đảm bảo chất lượng của quá trình phần mềm và do đó đảm bảo chất lượng của sản phẩm. 6.1.2 Quản lý độc lập Điều quan trọng là phải độc lập quản lí giữa các nhóm phát triển và nhóm SQA. Đó là, phát triển cần được theo một người quản lí, SQA dưới một người quản lí khác, và không quản lí nên có thể bác bỏ. lí do là, quá thường xuyên, các lỗi nghiêm trọng thường được tìm thấy trong một sản phẩm khi tiệm gần thời gian giao hàng. Tổ chức phần mềm bây giờ phải lựa chọn giữa hai lựa chọn không đạt yêu cầu. Hoặc là sản phẩm có thể được phát hành vào đúng thời gian nhưng đầy lỗi, để khác hàng phải chịu lỗi phần mềm, hoặc là các nhà phát triển sửa lỗi nhưng giao hàng muộn. Không có vấn đề gì, khách hàng có thể mất đi sự tin tưởng vào tổ chức phần mềm. Quyết định cung cấp phần mềm lỗi đúng thời gian không nên được thực hiện bởi người quan lí chịu trách nhiệm phát triển, cũng không phải người quản lí SQA sẽ đưa ra quyết định để thực hiện thử nghiệm thêm nữa và cung cấp các sản phẩm cuối. thay vào đó, cả hai nhà quản lí phải báo cáo cho quản lí cấp cao hơn những người có thể quyết định sự lựa chọn sẽ là những lợi ích tốt nhất của cả hai tổ chức phát triển và khách hàng. Ở cái nhìn đầu tiên, có một nhóm SQA riêng biệt sẽ xuất hiện thêm đáng kể chí phí phát triển phần mềm, nhưng điều này không phải là như vậy. Chi phí bổ sung là tương đối nhỏ so phần mềm lợi ích chất lượng cao hơn kết quả.nếu có một nhóm SQA, mỗi thành viên của tổ chức phát triển phần mềm sẽ phải đươc tham gia đến mức độ nào với chất lượng đảm bảo hoạt động. Giả sử, một tổ chức có 100 chuyên gia phần mềm và từng dành khoảng 30% thời gian của mình để hoạt động đảm bảo chất lượng. Thay vào đó, 100 cá nhân nên được chia thành 2 nhóm, với 70 cá nhân thực hiện phát triển phần mềm và 30 người khác chịu trách nhiệm cho SQA. Cùng một lượng thời gian dành cho SQA, chỉ có thêm chi phí là một người quản lí để dẫn đầu nhóm SQA. đảm bảo chất lượng bây giờ có thể được thực hiện bởi một nhóm độc lập của các chuyên gia, dẫn đến sản phẩm chất lượng cao hơn so với khi hoạt động SQA được thự hiện trong toàn bộ tổ chức. Trong trường hợp của một công ti phần mềm rất nhỏ ( bốn nhân viên hoặc ít hơn), nó có thể chỉ đơn giản là không phải là kinh tế khả thi để có một nhóm SQA riêng biệt. tốt nhất có thể được thực hiện theo những trường hợp như vậy là để đảm bảo rằng các phác thảo phân tích được kiểm tra bởi một người khác hơn so với người chịu trách nhiệm sản xuất những bản mẫu và tương tự cho các phác thảo thiết kế. 6.2 Non-Execution-Based Testing Kiểm thử phần mềm mà không cần chạy các trường hợp thử nghiệm được gọi là khôngthực hiện dựa trên thử nghiệm. Ví dụ về các phương pháp kiểm tra không thực hiện dựa trên phần mềm xem xét (một cách cẩn thận đọc qua nó) và phân tích phần mềm toán học (Phần 6,5). Nó không phải là một ý tưởng tốt cho người có trách nhiệm xây dựng một tài liệu là chỉ có một trách nhiệm xem xét nó. Hầu như tất cả mọi người có những điểm mù cho phép lỗi trong tài liệu, và những điểm mù cùng ngăn chặn các lỗi bị phát hiện xem xét. Vì vậy, nhiệm vụ xem xét phải được giao cho một ai đó khác hơn so với tác giả gốc của tài liệu. Ngoài ra, chỉ có một nhà xem xét lỗi có thể không được đầy đủ, tất cả chúng ta đã có kinh nghiệm đọc qua một tài liệu nhiều lần, trong khi không phát hiện một lỗi chính tả nghiêm trọng. Đây là một trong nguyên tắc cơ bản đánh giá kỹ thuật như walkthroughs hoặc kiểm tra. Trong cả hai loại xem xét, một tài liệu (chẳng hạn như một tài liệu đặc điểm kỹ thuật hoặc tài liệu thiết kế) là kiểm tra sửa chữa bởi một nhóm các chuyên gia phần mềm với một loạt các kỹ năng. Sức mạnh của xem xét bởi một nhóm các chuyên gia là các kỹ năng khác nhau của những người tham gia tăng cơ hội của tìm kiếm một lỗi. Ngoài ra, một nhóm các cá nhân có tay nghề cao làm việc cùng nhau thường tạo ra sự ăn ý.

Walkthroughs và kiểm tra là hai loại ý kiến. Sự khác biệt cơ bản giữa chúng là walkthroughs có bước ít hơn và ít chính thức hơn so với kiểm tra.

2

Cường 6.2.1 Walkthroughs Một nhóm Walkthrough nên bao gồm 4-6 cá nhân. Một nhóm Walkthrough phân tích nên bao gồm ít nhất một đại diện từ đội chịu trách nhiệm xây dựng các chi tiết kỹ thuật, người quản lý chịu trách nhiệm cho các công việc phân tích, một đại diện khách hàng, một đại diện của nhóm nghiên cứu sẽ thực hiện các công việc tiếp theo của sự phát triển (trong trường hợp này, đội ngũ thiết kế), và một đại diện của nhóm phần mềm đảm bảo chất lượng. Vì lý do đó sẽ được giải thích trong mục 6.2.2, thành viên nhóm SQA nên được chọn làm chủ tịch Walkthrough. Các thành viên của nhóm Walkthroughs nên có càng nhiều kinh nghiệm của nhân viên cấp cao kỹ thuật càng tốt bởi vì họ thường tìm những lỗi quan trọng. Đó là, họ phát hiện những lỗi lầm mà có thể ảnh hưởng tiêu cực lớn về dự án [R.NEW, thông tin cá nhân năm 1992]. Tài liệu cho Walkthrough phải được phân phối trước cho những người tham gia để cho phép chuẩn bị kỹ lưỡng. Mỗi người xem cần phải nghiên cứu vật liệu và phát triển hai danh sách: một danh sách các bài người xem không hiểu và một danh sách các mặt hàng người xem tin là không chính xác. 6.2.2 Managing Walkthroughs Walkthrough nên được chủ trì bởi đại diện SQA vì đại diện SQA sẽ thua nếu Walkthrough được thực hiện kém và lỗi phiếu thông qua. Ngược lại, người đại diện chịu trách nhiệm cho các công việc phân tích có thể là mong muốn có tài liệu đặc tả đã được phê duyệt càng nhanh càng tốt để bắt đầu một số nhiệm vụ khác. Đại diện khách hàng có thể quyết định rằng bất kỳ lỗi lầm không được phát hiện vào lúc xem xét có thể sẽ hiển thị trong quá trình thử nghiệm chấp nhận và được cố định tại thời điểm đó không có chi phí cho tổ chức của khách hàng. Tuy nhiên, đại diện SQA có hầu hết cổ phần: chất lượng của sản phẩm là một sự phản ánh trực tiếp của năng lực chuyên nghiệp của nhóm SQA. Người dẫn đầu Walkthrough dẫn các thành viên khác của nhóm Walkthrough thông qua văn bản để phát hiện ra bất kỳ lỗi lầm nào. Nó không phải là nhiệm vụ của đội sửa lỗi, nhưng chỉ đơn thuần là để ghi lại chúng để sửa chữa sau này. Có bốn lý do cho điều này: Một sự điều chỉnh sản xuất bởi một hội đồng (có nghĩa là, đội Walkthrough) trong thời gian có hạn của Walkthrough có khả năng thấp hơn chất lượng hơn so với một sự điều chỉnh được sản xuất bởi một cá nhân được đào tạo trong các kỹ thuật cần thiết. Một sự điều chỉnh sản xuất bởi một đội ngũ Walkthrough của 5 người phải mất ít nhất nhiều thời gian như một sự điều chỉnh sản xuất bởi một người và, dto đó, chi phí tiền lương của người tham gia tăng lên năm lần. Không phải tất cả các mục đánh dấu là lỗi đều không thực sự chính xác. Trong văn cảnh của câu châm ngôn "Nếu nó không được phá vỡ thì không sửa chữa nó", là tốt hơn cho những lỗi được phân tích có phương pháp và sửa chữa nếu có thực sự là một vấn đề, hơn là có một đội ngũ cố gắng để "sửa chữa"cái gì đó là hoàn toàn chính xác.
-

Chỉ đơn giản là không đủ thời gian trong một walkthrough để vừa phát hiện và vừa sửa lỗi.Không có Walkthrough được kéo dài hơn 2 giờ. Thời gian nên được dùng để phát hiện và ghi lại những lỗi lầm, không sửa chữa chúng
-

Có 2 cách để thực hiện một walkthrough. Đầu tiên là tham gia điều khiển. Những người tham gia trình bày danh sách các hạng mục không rõ ràng và các hạng mục họ nghĩ là không chính xác. Người đại diện của nhóm phân tích phải đáp ứng với mỗi truy vấn, làm rõ những gì là chưa rõ ràng cho người xem và cả hai đồng ý rằng thực sự là một lỗi hoặc giải thích lý do tại sao người xem bị nhầm lẫn. Cách thứ hai tiến hành rà soát tài liệu điều khiển. Một người chịu trách nhiệm về tài liệu, hoặc riêng lẻ hoặc như là một phần của một nhóm, đi tham gia thông qua tài liệu đó, với những nhận xét gián đoạn hoặc với ý kiến chuẩn bị trước của họ hoặc ý kiến được thực hiện

3

bằng cách trình bày. Cách tiếp cận thứ hai là có khả năng được triệt để hơn. Ngoài ra, nó thường dẫn đến việc phát hiện lỗi nhiều hơn vì phần lớn các lỗi tại một walkthroughs dựa vào tài liệu được phát hiện một cách tự nhiên bởi người thuyết trình. Mỗi lần những người thuyết trình sẽ tạm dừng ở giữa một câu, mình khuôn mặt sẽ sáng lên, và một lỗi, ….(one that has lain dormant through many readings of the document), đột nhiên trở nên rõ ràng. Một lĩnh vực có kết quả nghiên cứu của một nhà tâm lý học là để xác định lý do tại sao miệng trong(verbalization) quá thường xuyên dẫn đến phát hiện lỗi trong quá trình walkthroughs của tất cả các loại, bao gồm cả các walkthroughs yêu cầu, walkthroughs phân tích, các walkthroughs thiết kế, các walkthroughs kế hoạch, và walkthroughs mã hóa. Không ngạc nhiên, các tài liệu theo định hướng xem xét kỹ lưỡng hơn là kỹ thuật được quy định trong Tiêu chuẩn IEEE cho Phần Mềm [IEEE 1028, 1997]. Vai trò chính của các nhà lãnh đạo Walkthrough là để gợi ra câu hỏi và tạo điều kiện thuận lợi cho thảo luận.Walkthrough là một quá trình tương tác, nó không có nghĩa vụ phải là một mặt hướng dẫn bởi người thuyết trình. Nó cũng là điều cần thiết mà Walkthrough không được sử dụng như một phương tiện để đánh giá những người tham gia. Nếu điều đó xảy ra, Walkthrough thoái hóa thành một phiên họp point-scoring và không phát hiện lỗi, không có vấn đề như thế nào các nhà lãnh đạo kỳ họp sẽ cố gắng để chạy nó. Nó đã được gợi ý rằng người quản lý, những người chịu trách nhiệm cho các tài liệu, đang được xem xétlà thành viên của nhóm Walkthrough. Nếu quản lý này cũng chịu trách nhiệm cho các đánh giá hàng năm của các thành viên của nhóm Walkthrough (và đặc biệt là của người trình bày), khả năng phát hiện lỗi của đội bóng sẽ bị tổn hại, bởi vì động cơ chính của người thuyết trình sẽ được giảm thiểu số lượng lỗi hiển thị. Để ngăn chặn điều này xung đột lợi ích, người chịu trách nhiệm cho một công việc nhất định nên cũng không được trực tiếp chịu trách nhiệm về đánh giá bất kỳ thành viên nào của đội ngũ Walkthrough cho công việc đó. 6.2.3 kiểm tra(thanh tra) (ai ko thích tiếng việt thì có thể để nguyên tiếng anh là “inspections”) kiểm tra lần đầu tiên được đề xuất bởi Fagan [1976] để thử nghiệm thiết kế và mã. kiểm tra còn đi xa hơn một hương dẫn và có 5 bước chính thức. 1. Tổng quan của tài liệu được kiểm tra (yêu cầu, đặc điểm kỹ thuật, thiết kế, mã, hoặc kế hoạch) được cho bởi một trong nhữngcá nhân chịu trách nhiệm sản xuất tài liệu đó. Vào cuối của phiên họp tổng quan, tài liệu được phân phối cho những người tham gia. 2. Để chuẩn bị, tham gia cố gắng để hiểu các tài liệu chi tiết. Danh mục các loại lỗi được tìm thấy trong các kiểm tra gần đây, với các loại lỗi được xếp hạng bởi tần số, hỗ trợ tuyệt vời. Những danh sách này giúp các thành viên trong nhóm tập trung vào các lĩnh vực mà hầu hết lỗi lầm đã xảy ra. 3. Để bắt đầu việc kiểm tra, một trong những người tham gia đi qua các tài liệu với các đoàn kiểm tra, đảm bảo rằng mỗi món hàng đều được bảo hiểm và mỗi chi nhánh được thực hiện ít nhất một lần. Sau đó, lỗi phát hiện bắt đầu. Như với các hướng dẫn, mục đích là để tìm kiếm và đưa ra tài liệu lỗi, không sửa chữa chúng. Trong vòng một ngày, lãnh đạo của đoàn kiểm tra (kiểm duyệt) phải đưa ra 1 báo cáo bằng văn bản kiểm tra tỉ mỉ để đảm bảo thông qua. 4.Trong bước làm lại, các cá nhân chịu trách nhiệm về tài liệu giải quyết tất cả các lỗi và vấn đề lưu ý trong báo cáo bằng văn bản. 5.Trong bước theo dõi, điều phối viên phải đảm bảo rằng mọi vấn đề nêu ra đã được giải quyết thỏa đáng, bằng cách sửa chữa các tài liệu hoặc làm rõ các mụckhông chính xác gắn cờ là lỗi lầm. Tất cả các bản sửa lỗi phải được kiểm tra để đảm bảorằng không có lỗi mới đã được giới thiệu [Fagan, 1986]. Nếu hơn 5% của vật liệu được kiểm tra đã được làm lại, sau đó đội phải triệu tập lại cho tái kiểm tra 100%. Việc kiểm tra cần được tiến hành bởi một nhóm bốn người. Ví dụ, trong trường hợp kiểm tra thiết kế, nhóm nghiên cứu bao gồm một người điều tiết, thiết kế, triển khai, và thử

4

nghiệm. Người điều hành là cả người quản lý và lãnh đạo của đoàn thanh tra. đó phải là đại diện của nhóm chịu trách nhiệm cho các công việc hiện tại cũng như đại diện chịu trách nhiệm cho các công việc tiếp theo. Người thiết kế là một thành viên trong nhóm - nghiên cứu,đưa ra thiết kế, trong khi triển khai cũng là trách nhiệm, riêng lẻ hoặc như là một phần của một đội,cho việc chuyển thiết kế thành mã. Fagan đề xuất răng tester là 1 số lập trình viên chịu trách nhiệm cho các trường hợp thử nghiệm, tất nhiên, tester là một thành viên của nhóm SQA. Các tiêu chuẩn IEEE đề nghị một nhóm từ ba đến 6 người tham gia [IEEE 1028, 1997]. Vai trò đặc biệt được dữ bởi các điều hành viên, người đọc là người dẫn đầu nhóm thông qua việc thiết kế, và recorder chiu trách nhiệm đưa ra một báo cáo bằng văn bản các lỗi được phát hiện. Một thành phần thiết yếu của thanh tra là danh sách kiểm tra các lỗi tiềm năng. Ví dụ, danh sách kiểm tra cho kiểm tra thiết kế bao gồm các hạng mục: mỗi hạng mục tài liệu đặc tả có đầy đủ và chính xác địa chỉ hay ko? Đối với mỗi giao diện,các đối số có thực tế và chính thức tương ứng ko? cơ chế xử lý lỗi có xác định đầy đủ ko? Thiết kế tương thích với các tài nguyên phần cứng hoặckhông yêu cầu phần cứng có thực sự có sẵn? thiết kế tương thích với các nguồn tài nguyên phần mềm, ví dụ, hệ thống điều hành, có được quy định trong các tạo tác phân tích các chức năng theo yêucầu của thiết kế ko? Một thành phần quan trọng của các thủ tục kiểm tra hồ sơ của các số liệu là thống kê lỗi.Lỗi phải được ghi lại bởi mức độ nghiêm trọng (lớn hoặc nhỏ, một ví dụ về một lỗi nghiêm trọng là một trong những việc làm chấm dứt hoặc tổn thương một cơ sở dữ liệu) và các loại lỗi. Trong trường hợp của một thiết kế kiểm tra, các loại lỗi điển hình bao gồm các lỗi giao diện và các lỗi logic. Thông tin này có thể được sử dụng một cách hữu ích: • Số lượng các lỗi trong một sản phẩm nhất định có thể được so sánh với mức trung bình của lỗi phát hiện cùng một giai đoạn phát triển trong các sản phẩm so sánh, cho quản lý sớm cảnh báo rằng một cái gì đó không ổn và cho phép hành động khắc phục kịp thời để được thực hiện. • Nếu kiểm tra hai hoặc ba mã kết quả hiện vật trong sự phát hiện của 1 số lỗi ko cân xứng của một loại cụ thể, quản lý có thể bắt đầu kiểm tra các hiện vật mã khác cho những lỗi loại đó, và có hành động khắc phục nếu cần thiết. • Nếu kiểm tra của một tạo tác mã cụ thể cho thấy những lỗi lầm xa hơn được tìm thấy trong mã bất kỳ tạo tác khác trong sản phẩm, thường có một trường hợpmạnh mẽ cho thiết kế lại rằng tạo tác từ đầu và thực hiện các thiết kế mới. • Thông tin về số lượng và loại lỗi được phát hiện tại một kiểm tra của một thiết kế tạo tác sẽ viện trợ nhóm thực hiện việc kiểm tra mã của việc thực hiện đó tạo tác ở các giai đoạn sau. Thí nghiệm đầu tiên của Fagan [1976] đã được thực hiện trên một sản phẩm hệ thống. một trăm người giờ được dành để kiểm tra, với tỷ lệ 2 giờkiểm tra mỗi ngày bởi một nhóm bốn người. Trong tất cả các lỗi được tìm thấy trong quá trìnhphát triển của sản phẩm, 67% được đặt bằng cách kiểm tra trước khi kiểm tra đơn vị được bắt đầu. Hơn nữa, trong thời gian đầu tiên 7 tháng sau khi sản phẩm đã được cài đặt, 38% lỗi được phát hiện trong sp kiểm tra hơn một sản phẩm so sánh xem xét sử dụng walkthroughs. Fagan [1976] tiến hành một thí nghiệm khác trên một sản phẩm ứngdụng và thấy rằng 82% của tất cả các lỗi được phát hiện đã được phát hiện trong quá trình thiết kế và kiểm tra mã. Một hữu íchtác dụng phụ của thanh tra là lập trình năng suất tăng vì ít thời gianphải được chi cho kiểm tra đơn vị. Sử dụng một mô hình ước tính tự động,Fagan xác định rằng, kết quả là của quá trình kiểm tra, các khoản tiết kiệm về lập trình nguồn tài nguyên là 25% mặc dù thời gian có được dành cho các cuộc thanh tra. Trong một thí nghiệm khác nhau, Jones [1978] được tìm thấy rằng hơn 70% các lỗi được phát hiện có thể được phát hiện bằng cách tiến hành thiết kế và kiểm tra mã.

5

Các nghiên cứu sau đó đã đưa ra các kết quả ấn tượng không kém. Trong một doanh nghiệp-6000 dòng xử lý dữ liệu ứng dụng, 93% của tất cảcác lỗi được phát hiện đã được tìm thấy trong quá trình thanh tra [Fagan, 1986]. Theo báo cáo trong [Ackerman, Buchwald, vàLewski năm 1989], việc sử dụng kiểm tra chứ không phải là thửnghiệm trong quá trình phát triển của một hệ điều hành làm giảm chi phí phát hiện một lỗi 85%, trong một sản phẩm hệ thống chuyển mạch,giảm 90% [Fowler, 1986]. Tại Phòng thí nghiệm Jet Propulsion (JPL), trung bình, mỗi lần kiểm tra 2 giờ tiếp xúc với 4 lỗi lớn và 14 lỗi nhỏ [Bush, 1990]. Dịch sang đồng đô la, điều này có nghĩa là tiết kiệm khoảng $ 25.000 cho mỗi kiểm tra. Một nghiên cứu khác JPL [Kelly, Sherif, Hops, 1992] cho thấy rằng số lượng lỗi được phát hiện giảm theo cấp số nhân giai đoạn cổ điển. Nói cách khác, với sự trợ giúp của thanh tra, lỗi có thể được phát hiện sớm trong quá trình phần mềm.Tầm quan trọng của phát hiện sớm này được thể hiện trong hình1.6. Một trong những lợi thế mà kiểm tra mã hơn chạy các trường hợp thử nghiệm dựa trên thử nghiệm thực hiện là các xét nghiệm không cần phải đối phó với những thất bại.Nó thường xuyên xảy ra rằng, khi một sản phẩm theo thử nghiệm được thực thi, nó không thành công. Có lỗi gây rasự thất bại bây giờ phải được đặt và cố định trước khi thực hiện dựa trên thử nghiệm có thể tiếp tục.Ngược lại, một lỗi được tìm thấy trong các mã trong quá trình thử nghiệm không thực hiện dựa trên đăng nhập và xem xét tiếp tục. Một nguy cơ của quá trình thanh tra, như Walkthrough, có thể đc sử dụng để thẩm định hiệu suất.Điều nguy hiểm đặc biệt nghiêm trọng trong trường hợp của thanh tra do lỗi thông tin chi tiết có sẵn. Fagan gạt bỏ nỗi sợ này bằng cách nóirằng, trong khoảng thời gian 3 năm, ông biết không có người quản lý IBM, người sử dụng thông tin như vậy đối với một lập trình viên, hoặc như ông đặt nó, không có quản lý nào cố gắng "giết chết con ngỗng đẻ trứng vàng" [Fagan, 1976]. Tuy nhiên, nếu kiểm tra không được tiến hành đúng cách, họ có thể không được thành công vang dội như họ đã có tại IBM. Trừ khi nhà quản lý cao nhận thức của các vấn đề tiềm năng, lợi dụng kiểm tra thông tin là một khả năng riêng biệt. 6.2.4 So sánh inspections với Walkthroughs Bề ngoài, sự khác biệt giữa inspection và walkthrough là đoàn thanh tra sử dụng một danh sách kiểm tra của các truy vấn để hỗ trợ nó trong tìm kiếm lỗi. Nhưng sự khác biệt đi sâu hơn.Walkthrough là một quá trình hai bước: chuẩn bị tiếp theo là phân tích nhóm các tài liệu. Lê Tú Anh 6.2.4: Comparison of Inspections and Walkthroughs(So sánh giữa kiểm tra và hướng dẫn) Bề ngoài, sự khác nhau giữa kiểm tra và hướng dẫn là các đoàn kiểm tra sử dụng 1 checklist của các truy vẫn để hỗ trợ việc tìm kiếm lỗi.Nhưng sự khác biệt còn sâu hơn thế. Hướng dẫn là 1 quá trình gồm 2 bước: sự chuẩn bị tiếp theo bởi nhóm phân tích của tài liệu. Còn kiểm tra là 1 quá trình 5 bước: tổng quan, chuẩn bị, kiểm tra, làm lại và theo dõi, và sau mỗi bước các thủ tục được hợp thức hóa. Ví dụ của việc hợp thức hóa đó là phương pháp phân loại lỗi và sử dụng thông tin đó trong việc kiểm tra các văn bản của những workflow thành công cũng như việc kiểm tra của những sản phẩm tương lai. Quá trình kiểm tra mất nhiều thời gian hơn hướng dẫn. Việc đánh giá kiểm tra có cần thêm thời gian và công sức ko? Mục 6.2.3 đã chỉ ra rõ ràng rằng kiểm tra là 1 công cụ mạnh mẽ,chi phí hiệu quả để phát hiện lỗi.

6

6.2.5 Strengths and Weaknesses of Reviews(Ưu nhược điểm của nhận xét) Có 2 ưu điểm chính của 1 bài nhận xét,đánh giá(hướng dẫn hoặc kiểm tra). Thứ nhất, 1 bài nhận xét có hiệu quả là phát hiện ra lỗi,thứ 2 là,lỗi được phát hiện sớm trong software process,trước khi chúng trở nên tốn kém để sửa chữa. Ví dụ, lỗi thiết kế được phát hiện trước khi đưa vào triển khai, và các lỗi code được tìm thấy trước khi bản phác thảo được thực hiện trên sản phẩm. Tuy nhiên, hiệu quả của 1 bài đánh giá có thể được giảm nếu software là ko đầy đủ,phù hợp. • Thứ nhất, phần mềm quy mô lớn là rất khó để đánh giá,trừ khi nó bao gồm nhiều thành phần nhỏ hơn và phần lớn là độc lập với nhau. Ưu điểm của mô hình hướng đối tượng là:nếu thực hiện 1 cách chính xác thì kết quả là sản phẩm là tập hợp của nhiều thành phần độc lập. • Thứ 2, 1 nhóm đánh giá thiết kế đôi khi tham khảo các bản phác thảo phân tích, nhóm đánh giá code cần thường xuyên truy cập vào các tài liệu thiết kế. Trừ khi, các tài liệu của các workflow trươc đó được hoàn thành,cập nhật để phản ánh các phiên bản hiện tại của dụ án,sẵn trực tuyến nếu ko hiệu quả của đội đánh giả bị cản trở nghiêm trọng 6,3 Thực hiện dựa trên thử nghiệm Người ta đã khẳng định rằng thử nghiệm là một minh chứng rằng lỗi("bugs") không được thể hiện.Mặc dù một số tổ chức chi tiêu lên đến 50% ngân sách phần mềm của họthử nghiệm, chuyển giao phần mềm "kiểm tra" là nổi tiếng không đáng tin cậy. Lý do cho mâu thuẫn này là đơn giản.Như Dijkstra, "Chương trình thử nghiệm có thể là một cách rất hiệu quả để hiển thị sự hiện diện của lỗi, nhưng nó là vô vọngkhông đủ cho thấy sự vắng mặt của chúng" [Dijkstra, 1972].Dijkstra nói rằng, nếumột sản phẩm được thực hiện với dữ liệu thử nghiệm và đầu ra là sai, sau đó sản phẩm chắc chắn có chứa một lỗi.Tuy nhiên, nếu đầu ra là chính xác, sau đó vẫn có thể là một lỗi trong sản phẩm, thông tin duy nhất có thể được rút ra từ đó kiểm tracụ thể là sản phẩm chạy chính xác trên tập hợp các dữ liệu thử nghiệm đó. Hà Văn Thụy 6.4 có thể để mô tả những thuộc tính gì nên được thử nghiệm, đó là vấn đề cần thiết đầu tiên cho một mô tả chính xác dựa trên việc kiểm thử . Theo Goodenough [1979], kiểm thử là một quá trình suy luận dựa vào tính chất của sản phẩm,một phần vào kết quả thực hiện sản phẩm trong một môi trường được biết đến với đầu vào được lựa chọn.Sự hao hụt này có ba ý nghĩa gây phiền hà. 1. Đầu tiên, các trạng thái định nghĩa rằng thử nghiệm là một quá trình suy luận. Thử nghiệm các sản phẩm, chạy nó với các dữ liệu đầu vào được biết đến, và kiểm tra đầu ra. Kiểm thử có để suy ra những gì,nếu bất cứ điều gì là sai với sản phẩm. Từ quan điểm này, thử nghiệm so sánh với việc cố gắng tìm một con mèo đen trong một căn phòng tối. Thử có vài manh mối để giúp tìm bất kỳ lỗi:có lẽ 10 hoặc 20 bộ đầu vào và đầu ra tương ứng, có thể là một lỗi người sử dụng báo cáo,và hàng ngàn dòng mã. Từ điều này, thử nghiệm để suy ra nếu có một lỗi,

7

2.một vấn đề được định nghĩa bắt nguồn từ một phase trong môi trường được biết.Chúng ta chưa bao giờ biết rõ về môi trường của chúng ta kể cả phần cứng lẫn phần mềm.chúng ta chưa bao giờ chắc chắn rằng hệ điều hành của chúng ta luôn đúng,Và các lỗi thường xảy ra đói với bộ nhớ chính. 3.một trong những diều đáng lo ngại khác chính là lựa chọn dầu vào.Trong trường hợp hệ thống thời gian thực ,thường thường việc không kiểm soát là có thể dữ liệu vào vượt quá khả năng của hệ thống. 6.4.1.Sự có ích. Tiện ích là mức độ nhu cầu của người dùng được đáp ứng khi một sản phẩm được sử dụng đúng theo tài liệu dặc tả. Nói cách khác, một sản phẩm được hoạt động một cách chính xác với các trạng thái của tài liệu dặc tả. Người sử dụng có thể kiểm tra, ví dụ, sản phẩm đc sử dụng dễ dàng, cho dù sản phẩm thực hiện việc sử dụng tất cả các chức năng, và chi phí cho sản phẩn hoàn toàn là cạnh tranh so với các sản phản khác trên thị trường. Không phân biệt cho dù sản phẩm là chính xác hay không, những vấn đề quan trọng phải được kiểm tra. Nếu chi phí cho sản phẩm không hiệu quả và sau đó là ko có người mua nó,trừ khi sản phẩm dễ sử dụng, nếu ko nó sẽ không được sử dụng hoặc nó sẽ được sử dụng không chính xác. Vì vậy, khi cân nhắc mua một sản phẩm hiện có (bao gồm cả phần mềm đóng gói), tiện ích của sản phẩm phải được kiểm tra , và nếu sản phẩm không thành công , thử nghiệm nên dừng lại. 6.4.2 Độ tin cậy Một khía cạnh khác của một sản phẩm phải được thử nghiệm là độ tin cậy của nó. Độ tin cậy là một biện pháp của tần số và tính tới hạn của sự thất bại của sản phẩm, nhắc lại rằng thất bại là không thể chấp nhận, trong những điều kiện cho phép, xảy ra do hậu quả của một lỗi. Khi một sản phẩm thất bại,vấn đề quan trọng là phải mất bao lâu, trung bình, để sửa chữa nó(có nghĩa là thời gian để sửa chữa). Giả sử rằng các phần mềm chạy trên một hệ thống thông tin liêu lạc không thành công nó sẽ xóa sạch cơ sở dữ liệu. Tốt nhất, cơ sở dữ liệu thực sự đáng tin cậy khi thực hiện các kiểm soát cuối cùng Nguyễn Gia Thủy 6.4.3 Mạnh mẽ (Robustness) Vấn đề kiểm tra tính mạnh mẽ của sản phẩm. Mặc dù rất khó khăn để định nghĩa chính xác, mạnh mẽvề cơ bản là chức năng của một số yếu tố, chẳng hạn như phạm vi củađiều kiện hoạt động, khả năng kết quả không thể chấp nhận được với đầu vào hợp lệ, và sự chấp nhận củahiệu ứng khi sản phẩm đượckhông hợp lệ đầu vào.Một sản phẩm với một loạt các điều kiện hoạt động cho phép là mạnh hơn so với một sản phẩm hạn chế hơn.Một sản phẩm mạnh mẽ không đượcmang lại kết quả không thể chấp nhận được khi đầu vào đáp ứngtiêu chuẩnkỹ thuật của nó, ví dụ, đưa ra một lệnh hợp lệ nên không có hậu quả tai hại.Một sản phẩm mạnh mẽ không được sụp đổ khi sản phẩm không được sử dụng trong điều kiện hoạt độngcho phép.Để kiểm tra cho khía cạnh này, dữ liệu thử nghiệm được cốý nhập vàokhôngđáp ứng yêu cầu kĩ thuật, và thử nghiệm xác định làm thế nào sản phẩm phản ứng xấu.Ví dụ, khi sản phẩm muốn một tên, các tester cóthể trả lời với một chuỗi các kí tựkhông thể chấp nhận được, chẳng hạn như “% $ # @”.Nếu máy tính phản ứng với một tin nhắn như vậy là “ dữ liệukhông chính xác”, “thử lạimột lần nữa”, hoặc tốt hơn, thông báo cho người sử dụng như là lý do tại sao các dữ liệu không phù hợp với những gì đã được dự kiến, điềuđó là mạnh mẽ hơn so vớimột sản phẩm mà treo bất cứ khi nào dữ liệu đi chệch một chút so vớinhững gì đượcyêu cầu. 6.4.4 Hiệu suất (Performance) Hiệu suất là một khía cạnh của sản phẩm phải được kiểm tra. Điều đó là cần thiết để biết mức độ hạn chế của sản phẩm trong thời gian phản hồi lại hoặc trong yêu cầu về không gian. Đối với hệ

8

thống máy tính nhúng như một máy tính gắn trên một tên lửa phòng không cầm tay, hạn chế không gian của hệ thống là chỉ có 128 MB bộ nhớ chính có sẵn cho phẩn mềm Phần mềm thời gian thực đượcđặc trưng bởi những eo hẹp khó khăn về thời gian, đó là eo hẹp thời gian của tự nhiên, nếu eo hẹp về thời gian không đượcđápứng, thông tin sẽ bị mất. Ví dụ, một hệ thống điều khiển lò phản ứng hạt nhân có thể phải lấy mẫu nhiệt độ của lõi và xử lý dữ liệu 10 trong một giây.Nếu hệ thống không đủ nhanh để xử lý ngắt từ các cảm biến nhiệt độ 10 lần trong một giây, thìsau đó dữ liệu bị mất, và không có cách nào có thể phục hồi dữ liệu, trong thời gian tiếp theo hệ thống nhận được dữ liệu nhiệt độ, nó sẽ lànhiệt độ hiện tại, nhiệt độ không đọc được sẽ bị bỏ qua. Nếu lò phảnứngđangđứng trên bờ vực của cuộc khủng hoảng, sau đó điều quan trọng là tất cả các thông tin có liên quan đều nhận được và xử lý như đã nêu trong các thông số kỹ thuật. Với tất cả các hệ thống thời gian thực, hiệu quả hoạt động phải đáp ứng tất cả các eo hẹp về thời gian được liệt kê trong các chi tiết kỹ thuật. Hà 6.4.5: Đúng đắn: Cuối cùng, một định nghĩa đúng đắn có thể được đưa ra. Một sản phẩm là chính xác nếu nó đáp ứng đầu ra chi tiết kỹ thuật, độc lập của việc sử dụng tài nguyên máy tính, khi hoạt động theo điều kiện cho phép [Goodenough, 1979]. Nói cách khác, nếu đầu vào đáp ứng đầu vào thông số kỹ thuật được cung cấp và sản phẩm được cho tất cả các nguồn lực cần thiết, sau đó sản phẩm là chính xác nếu sản lượng đáp ứng các chi tiết kỹ thuật đầu ra. Định nghĩa này của đúng đắn, giống như định nghĩa testing, có đáng lo ngại ý nghĩa. Giả sử một sản phẩm đã được thử nghiệm thành công chống lại một loạt thử nghiệm rộng rãi của dữ liệu. Điều này có nghĩa là sản phẩm có thể chấp nhận được? Thật không may, nó không. Nếu một sản phẩm chính xác, tất cả các phương tiện đó là đáp ứng yêu cầu kỹ thuật của nó. Nhưng nếu các yêu cầu kỹ thuật chính nó là không chính xác? Để minh họa này, hãy xem xét các yêu cầu kỹ thuật thể hiện trong Hình 6.1. Tài liệu kỹ thuật yêu cầu các đầu vào để sắp xếp là một p mảng các số nguyên n, trong khi đầu ra là một mảng q sắp xếp thứ tự khôg giảm.bề ngoài có vẻ hoàn toàn chính xác. Nhưng xem xét trickSort phương pháp thể hiện trong hình 6.2. Trong phương pháp này, tất cả các yếu tố n của mảng q được thiết lập là 0. Phương pháp đáp ứng yêu cầu kỹ thuật của Hình 6.1 và do đó là chính xác. Điều gì đã xảy ra? Thật không may, các yêu cầu kỹ thuật của Hình 6.1 là sai. Những gì có được bỏ qua một tuyên bố rằng các yếu tố của q, các mảng đầu ra, là một hoán vị (phía sau rangement) của các yếu tố của mảng đầu vào p. Một khía cạnh nội tại của phân loại là nó là một sắp xếp lại quá trình. Và phương pháp của Hình 6.2 tận dụng lỗi yêu cầu kỹ thuật này. Nói cách khác, phương pháp trickSort là chính xác, nhưng các yêu cầu kỹ thuật của hình 6.1 sai. Yêu cầu kỹ thuật đúng xuất hiện trong hình 6.3. Từ ví dụ này, rõ ràng là hậu quả của lỗi yêu cầu kỹ thuật là không tầm thường. Sau tất cả, đúng đắn của một sản phẩm vô nghĩa nếu yêu cầu kỹ thuật của nó là không chính xác. Thực tế là một sản phẩm đúng đắn là chưa đủ, bởi vì các yêu cầu kỹ thuât mà nó đã được thể hiện có thể là đúng có thể sai. Nhưng nó cần thiết? Hãy xem xét tiếp theo ví dụ. Một tổ chức phần mềm đã giành được một trình biên dịch C + + mới tuyệt vời.

9

Trình biên dịch mới có thể dịch hai lần so với trình biên dịch cũ, mã đối tượng chạy nhanh hơn gần 45%, và kích thước của mã đối tượng là khoảng 20 phần trăm nhỏ hơn. Ngoài ra, các thông báo lỗi rõ ràng hơn và chi phí của bảo trì và cập nhật ít hơn một nửa của trình biên dịch cũ. Có một vấn đề, Tuy nhiên, thời gian đầu tiên xuất hiện trong bất kỳ class nào, trình biên dịch in một thông báo lỗi giả. Do đó, trình biên dịch là không đúng, bởi vì các yêu cầu kỹ thuật cho một trình biên dịch ngầm hay rõ ràng yêu cầu thông báo lỗi được in, nếu và chỉ nếu, có là một lỗi trong mã nguồn. Đó chắc chắn là có thể sử dụng trình biên dịch trên thực tế theo mọi cách nhưng một trong những trình biên dịch là hoàn toàn lý tưởng. Hơn nữa, nó là hợp lý để mong đợi lỗi nhẹ này sẽ được sửa chữa trong bản phát hành kế tiếp. Trong khi đó, các lập trình viên học cách bỏ qua các thông báo lỗi giả mạo. Không chỉ các tổ chức có thể sống trong sửa chữa biên dịch, nhưng nếu có ai đề nghị thay thế nó với các trình biên dịch chính xác cũ, sẽ có một sự phản đối kịch liệt. Do đó, tính đúng đắn của một sản phẩm không phải là cần thiết và không là đủ. Cả hai ví dụ trước đó thừa nhận là phần móng cial. Nhưng họ làm cho các điểm chính xác mà chỉ đơn giản có nghĩa là sản phẩm là một thực hiện chính xác theo các yêu cầu kỹ thuật. Nói cách khác, có nhiều thử nghiệm hơn là chỉ cho thấy rằng sản phẩm là chính xác. Với tất cả các khó khăn trong gắn liền với thực hiện dựa trên thử nghiệm, các nhà khoa học máy tính đã cố gắng để đến với những cách khác đảm bảo rằng sản phẩm làm những gì nó được yêu cầu làm. Một trong những thay thế mà không dựa trên thực hiện đã nhận được sự chú ý đáng kể hơn 50 năm được chứng minh đúng đắn. Phương 6.6 Ai nên thực hiện thực hiện dựa trên kiểm tra? (Who Should Perform Execution-Based Testing?) Giả sử một lập trình viên được hỏi để thử nghiệm một tạo tác mã (code artifact) họ đã thực hiện.Thử nghiệm đã được mô tả bởi Myers [1979] là quá trình thực hiện một sản phẩm với ý định tìm lỗi. Thử nghiệm do đó là một quá trình phá hoại. Mặt khác, các lập trình viên làm việc thử nghiệm thường không muốn để phá hủy công việc của mình. Nếu thái độ cơ bản của lập trình hướng tới đang là một trong những bảo vệ thông thường, sau đó các cơ hội mà lập trình bằng cách sử dụng dữ liệu thử nghiệm sẽ làm nổi bật lỗi là thấp hơn đáng kể hơn nếu động lực lớn đã thực sự phá hoại. Một thử nghiệm thành công phát hiện lỗi. Điều này cũng đặt ra một khó khăn.Nó có nghĩa rằng, nếu tạo tác mã (code artifact) đang vượt qua các kiểm tra, sau đó thử

10

nghiệm đã thất bại.Ngược lại, nếu tạo tác mã (code artifact) đang không thực hiện theo các thông số kỹ thuật, sau đó thử nghiệm thành công.Một lập trình viên được hỏi để thử nghiệm một tạo tác mã (code artifact) họ đã thực hiện được yêu cầu để thực hiện các giả mã trong một cách mà một sự thất bại không chính xác hành vi xảy ra sau đó.Điều này đi ngược lại bản năng sáng tạo của các lập trình viên. Một kết luận không thể tránh được là các lập trình viên không cần kiểm tra các tạo tác mã (code artifact) của họ.Sau khi một lập trình viên xây dựng và xây dựng một tạo tác mã (code artifact), thử nghiệm mà tạo tác mã (code artifact) đòi hỏi người sáng tạo để thực hiện hành động. Lý do thứ hai, lý do tại sao thực hiện dựa trên thử nghiệm nên được thực hiện bởi người khác là các lập trình viên có thể đã hiểu lầm một số khía cạnh của thiết kế hoặc thông số kỹ thuật.Nếu thử nghiệm được thực hiện bởi người khác, lỗi này có thể được phát hiện.Tuy nhiên, gỡ lỗi (tìm ra nguyên nhân của lỗi và sửa chữa các lỗi) tốt nhất được thực hiện bởi các lập trình viên ban đầu, người quen thuộc nhất với các mã. Những tuyên bố rằng một lập trình viên không nên kiểm tra mã của mình không phải đi quá xa.Hãy xem xét quá trình lập trình.Lập trình bắt đầu bằng cách đọc thiết kế chi tiết của tạo tác mã (code artifact), điều này có thể là các hình thức của một sơ đồ hay, nhiều khả năng, giả mã (pseudo-code).Nhưng, bất cứ kỹ thuật gì được sử dụng, các lập trình viên phải chắc chắn bàn kiểm tra mã các tạo tác mã (code artifact) trước khi nhập vào máy tính. Đó là, các lập trình viên phải cố gắng sơ đồ hoặc giả mã (pseudo-code) với các trường hợp thử nghiệm khác nhau, truy tìm thông qua các thiết kế chi tiết để kiểm tra xem mỗi trường hợp thử nghiệm được thực hiện một cách chính xác.Chỉ khi các lập trình viên hài lòng rằng các thiết kế chi tiết là chính xác các trình soạn thảo văn bản được gọi để viết code. Một khi các tạo tác mã (code artifact) đang ở dạng máy có thể đọc, nó trải qua một loạt các bài kiểm tra.Dữ liệu thử nghiệm được sử dụng để xác định rằng các tạo tác mã đang hoạt động thành công, có thể các dữ liệu thử nghiệm tương tự được sử dụng để bàn kiểm tra thiết kế chi tiết.Tiếp theo, nếu tạo tác mã đang thực hiện một cách chính xác với dữ liệu thử nghiệm chính xác được sử dụng, sau đó lập trình viên cố gắng thử với dữ liệu không chính xác để kiểm tra sự vững mạnh của các tạo tác mã.Khi lập trình viên hài lòng rằng các tạo tác đang hoạt động một cách chính xác, có hệ thống kiểm tra bắt đầu.Thử nghiệm hệ thống này không nên được thực hiện bởi các lập trình viên.. Nếu lập trình viên không thực hiện thử nghiệm hệ thống này, ai sẽ là người làm điều đó? Như đã nêu tại mục 6.1.2, thử nghiệm độc lập phải được thực hiện bởi nhóm SQA. Các từ khóa ở đây là độc lập. Chỉ khi nhóm SQA thật sự độc lập với nhóm phát triển thì thành viên của SQA có thể thực hiện nhiệm vụ của họ, đảm bảo rằng sản phẩm thực sự đáp ứng thông số kỹ thuật, mà không cần phần mềm quản lý phát triển so với áp lực của sản phẩm dead-line có thể cản trở công việc của họ. Nhân viên SQA phải báo cáo cho quản lý riêng của họ và do đó bảo vệ sự độc lập của họ. Liên Hệ thống thử nghiệm được thực hiện như thế nào? Một phần thiết yếu của một trường hợp thử nghiệm là một câu lệnh kết quả dự kiến trước khi thử nghiệm được thực hiện. Điều này hoàn toàn phí thời gian cho các thử nghiệm ngồi ở một thiết bị đầu cuối, thực hiện các mã phác thảo, nhập dữ liệu thử nghiệm lộn xộn, và sau đó nhìn vào màn hình và nói, “tôi đoán rằng có vẻ đúng”. Không kém vô ích cho các thử nghiệm rất cẩn thận và thực hiện từng trường hợp kiểm tra lần lượt, xem kết quả và nói, “Vâng, đó chắc chắn có vẻ đúng”. Quá dễ dàng bị đánh lừa bởi kết quả hợp lý. Nếu các lập trình viên đang được cho phép để kiểm tra mã riêng của họ, sau đó luôn luôn là mối nguy hiểm mà các lập trình viên sẽ thấy những gì họ muốn xem. Sự nguy hiểm tương tự có thể xảy ra ngay cả khi thử nghiệm được thực hiện bởi người khác. Giải pháp cho việc quản lý nhấn mạnh rằng, trước khi một thử nghiệm được thực hiện, các dữ liệu thử nghiệm và kết quả dự kiến của bài kiểm tra đó được ghi lại. Sau khi thử nghiệm đã được thực hiện, kết quả thực tế được ghi lại và so sánh với kết quả mong đợi.

11

Ngay cả trong các tổ chức nhỏ và với các sản phẩm nhỏ, điều quan trọng là ghi âm này được thực hiện ở dạng máy có thể đọc được, bởi vì các truongf hợp thử nghiệm không bao giờ được bỏ đi. Lý do cho điều này là bảo trì. Trong khi sản phẩmđang được duy trì, kiểm tra hồi quy phải được thực hiện. Lưu trữ trường hợp thử nghiệm sản phẩm có trước đó thực hiện một cách chính xác phải chạy lại để đảm bảo rằng các thay đổi đựơc thực hiện thêm chức năng mới cho sản phẩm đã không bị phá hủy chức năng hiện có của sản phẩm . Điều này tiếp tục được thảo luận trong chương 16. 6.7 When Testing Stops Sau khi sản phẩm đã được duy trì thành công trong nhiều năm, nó cuối cùng có thể mất đi tính hữu dụng của nó và được thay thế bởi một sản phẩm hoàn toàn khác nhau, giống như cách thay thế van điện tử bằng bóng bán dẫn. Ngoài ra, một sản phẩm vẫn có thể hữu ích, nhưng chi phí thay đổi phần cứng mới hoặc chạy theo một hệ điều hành mới (portting”thuật ngữ này đc sd khi phần mềm /phần cứng đc thay đổi để làm cho họ có thể sử dụng trong các môi truongf khác nhau”) nhiều chi phí xây dựng một sản phẩm mới, bằng cách sử dụng bản cũ như một nguyên mẫu. Vì vậy, cuối cùng, các sản phẩm phần mềm được ngừng hoạt động và loại bỏ khỏi dịch vụ. Chỉ vào thời điểm đó, khi phần mềm đã được bỏ đi không thể thay đổi, đó là thời gian để dừng thử nghiệm. Bây giờ tất cả các tài liệu nền tảng cần thiết đã được bao phủ, các đổi tượng có thể được kiểm tra chi tiết hơn. Đây là chủ đề của chương 7.

12

Sign up to vote on this title
UsefulNot useful