Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm

Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm , môn chuyên đề Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm , môn chuyên đề Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm , môn chuyên đề Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm , môn chuyên đề Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm , môn chuyên đề

Câu 1: Chất lượng phần mềm là gì? Cái gì được dùng để làm cơ sở kiểm định chất lượng phần mềm?

a Chất lượng phần mềm:

- Việc tuân thủ các yêu cầu chức năng và sự hoàn thiện đã được phátbiểu tường minh

- Các chuẩn phát triển được tư liệu hóa tường minh

- Các đặc trưng ko tường minh được trông đợi từ tất cả các phầnmềm đã được phát triên theo cách chuyên nghiệp

 Theo quan điểm của nhà phát triển phần mềm, nhà lập trình thì mộtphần mềm được coi là tốt khi phần mềm đó ít lỗi, đây chính là chấtlượng của chương trình Và làm thế nào để chương trình chạy ít lỗi

 Theo quan điểm của khác hàng (quan điểm thiết kế) phầm mềm tốt

là phần mềm đáp ứng được nhu cầu, mục đích sử dụng, dễ sử dụng, dễ bảo trì

 Chất lượng của phần mềm còn được hiểu là độ tin cậy, tính chínhxác và độ an toàn của phần mềm

b Cái gì được dùng để làm cơ sở kiểm định chất lượng phần mềm:

- Y/C PM là cơ sở để đo chất lượng phần mềm

+ Sự phù hợp với yêu cầu là có chất lượng

+ Phù hợp y/c cả về số lượng và chất lượng

- y/c thể hiện đặc tả - đặc tả phải có chuẩn của nó mới kiểm trađược

- các chuẩn đặc tả xác định một bộ các t/c phát triển, các tiêu chuẩnnày hướng dẫn cách thức làm ra phần mềm nêu skhoong tuân thủtheo các chuẩn đó thfi hầu như và chắc chắn là chất lượng sẽ kém

- Luôn có 1 tập hợp các y/c ngầm thường ít được nhắc đến

+ quá thông dụng, hiển nhiên (sử dụng cử số)

+ không thể hiển ra ngoài (quy tắc nghiệm vụ)

- Nếu pm chỉ phù hợp với các y/c hiển thị mà chưa phù hơp với cácy/c ngầm thì p/m đó là đáng nghi ngờ

- Cần làm ro các y/c và đưa vào đặc tả càng nhiều càng tốt

Câu 2: Có thể đo trực tiếp chất lượng phần mềm không? Tại sao? Bằng cách nào?

Có thể đo trực tiếp chất lượng phần mềm, thông qua nhân tố trựctiếp KLOC (KLOC – Kilo Line Of Code) Bởi vì:

Theo McCall đề xuất thì có tới 11 nhân tố ảnh hưởng đến chấtlựơng phân mềm, trong đó nó được chia ra làm 3 loại chính:

- Loại 1: Đặc trưng về chức năng (5 nhân tố)

- Loại 2: Khả năng đương đầu với những thay đổi (3 nhân tố)

- Loại 3: Khả năng thích nghi với môi trường mới (3 nhân tố)

Trong đó nhân tố trực tiếp ở loại 3 sẽ tác động trực tiếp đến chấtlượng phần mềm.đó là số lỗi gặp phải của chương trình/KLOC/đơn vịthời gian.Chương trình luôn luôn có lỗi.Những lỗi của chương trìnhđược thể hiện ở ngay trên những dòng code, đó là những lệnh sai màngười lập trình mắc phải

Trong đó KLOC là thước đo kích thước của một chương trình máytính Kích thước được xác định bằng cách đo số lượng các dòng mãnguồn một chương trình có Ngôn ngữ cao cấp như C++, sẽ tổng hợpthành dòng mã máy hơn một ngôn ngữ lắp ráp, C++ là một ngôn ngữcấp thấp

Câu 3: Độ tin cậy của phần mềm là gì? Đo độ tin cậy của phần mềm như thế nào? Giải thích?

a Độ tin cậy của phần mềm là:

- Độ tin cậy của phần mềm là một trong những yêu tố quan trọngtrong chất lượng phần mềm

- Độ tin cậy của phần mềm được định nghĩa theo ngôn ngữ thốngkê:”Xác suất thao tác không thất bại của chương trình máy tínhtrong một môi trường đặc biệt với một thời gian xác định rõ”

b Đo độ tin cậy của phần mềm bằng cách:

- Đo trực tiếp và được đánh giá qua các dữ liệu phát triển và dữ liệulịch sử

+ Tính xác xuất xuất hiện thành công hay thất bại

+ Đo độ dài khoảng thời gian trung bình giữa 2 lần thất bại liêntiếp

+ Khả năng sẵn sang hoạt động lại của hệ thống.

- Để đo tính tin cậy của phần mềm người ta dung công thức

MTBF = MTTF + MTTRTrong đó:

MTBF: thời gian trung bình giữa các hỏng hóc

MTTF: Thời gian hỏng hóc

MTTR: Thơi gian sửa chữa

Tính sẵn có của phần mềm được xác định bởi

Tính sẵn có = MTTF / (MTTF + MTTR) * 100

c Giải thích:

- Ví dụ ta có 1 chương trình X với ước lượng có độ tin cậy là 96%

và được thực hiện trong 8h trong một trường hợp khác chươngtrình đó phải thực hiện 100 công việc trong 8h và số công việcthực hiện thành công là 96

Câu 4: Trình bày quá trình đo độ tin cậy của phần mềm.

- Xác định sư lược hoạt động: Đầu tiên bạn nghiên cứu các hệ thốngtồn tại của các kiểu như nhau để đưa ra mô tả sơ lược về hoạtđộng Mô tả sơ lược hoạt động nhận biết loại đầu vào hệ thống vàxác xuất xuất hiện các đầu vào này trong trường hợp bình thường

- Chuẩn bị tập dữ liệu kiểm thử: Sau đó, bạn thiết đặt tâp các dữ liệukiểm thử để phản ánh mô tả sơ lược hoạt động Có ý nghĩa là bạntạo ra bộ dữ liệu kiểm thử với xác xuất như nhau (dữ liệu cho hệthống mà bạn đã nghiên cứu) thông thường bạn sử dụng máy sinh

dữ liệu để sinh ra bộ dữ liệu kiểm thử này

- Áp dụng các dữ liệu vào để kiểm thử hệ thống: bạn sử dụng dữ liệu

đã được sinh ra ở trên và đếm các lỗi sinh ra Các lỗi sinh ra nàycũng được ghi nhận

- Tính toán độ tin cậy: tiến hành thống kê xem số lỗi sinh ra và từ đótính toán được độ tin cậy của phần mềm thông qua cách tính giá trị

đo độ tin cậy

Câu 5: những khó khan khi đo độ tin cậy của phàn mềm là gì?

Không chắc chắn mô tả sơ lược hoạt động: mô tả sư lược hoạt động dựa trên kinh nghiệm, với các:

1 hệ thống khác có thể không phản ánh chính xác thực tê sử dụngcủa hệ thống

2 Giá trị cao của dữ liệu kiểm thử sinh ra: để sinh ra mộ bộ dữ liệukiểm tra như vậy sẽ tốn rất nhiều thời gian và tiền bạc, giá trị bộ dữliệu sinh ra khi đó rấtự đắt.trừ khi quá trình này sinh ra là tự động

3 Thống kê không chắc chắn khi yêu cầu tính tin cậy cao được chỉra: Bạn phải sinh mộ số lượng thống kê quan trọng các sai sót đểcho phép đo độ tin cậy chính xác Khi phần mềm đã được xác thựctính tin cậy, một vài sai sót liên quan xuất hiện và nó khó khan đểsinh ra sai sót mới

4 Phát triển mô tả sơ lược thao tác chính xac chắc chắn có thể với vàikiểu thệ thống, như hệ thống truyền thông có một mẫu tiêu chuẩnhóa được sử dụng Tuy nhiên, với các loại hệ thống khác cố rấtnhiều người sử dunjgk hác nhau, mỗi người có một cách riêng khi

sử dụng hệ thống những người dùng khác nhau sẽ có những ấntượng khác nhau về độ tin cậy vì họ sử dụng thống theo nhữngcách khác nhau

Câu 6: Những mô hình dự đoán tính tin cậy.

Có 5 mô hình dự đoán độ tin cậy của phần mềm:

- Mô hình tiên đoán độ tin cậy của phần mềm như là một hàm củathời gian lịch

- Mô hình tiên đoán độ tin cậy như là một hàm thời gian xử lý đãtrôi qua(thời gian vận hành của CPU)

- Mô hình sử dụng phương pháp kịch bản (Scenarios) để dự đoán độtin cậy cảu phần mềm

- Mô hình tin cậy hướng người sử dụng Cheung

- Mô hình sử dụng kịch bản và chuỗi Markov

Câu 7: Nguyên lý của luận chứng tính an toàn của phần mềm.

Hầu hết các kĩ thuật hiệu quả để chứng mìh tính an toàn của hệ thống là chứng minh bằng phản chứng Bắt đầu vớ giả thiết rằng trạng thái ban đầu không an toàn đã được xác định bằng phân tích rủi ro của

hệ thống, có thể được đi đến khi chương trình thực thi Bạn viết một thuộc tính để xác định đó là trạng thái không an toàn Sau đó, một cách

có hệ thống, bạn phân tích mã chương trình và chỉ ra,

với tất cả các đường dẫn chương tình dẫn tới trạng thái đó, điều kiện kếtthúc của các đường dẫn đó ma thuân với thuộc tính trạng thái không antoàn Nếu trường hợp đó xảy ra, giả thiết ban đầu của trạng thái không

an toàn là không đúng Làm lại điều đó nhiefu lần với các định danhđược cho là rủi ro thì phần mềm đó là an toàn

Để xây dựng những luận chứng về tính ant oàn, bạn xác định điềukiện cho trạng thái không an toàn, trong trường hợp đó như làcurrentDose > maxDose Sau đó, bạn chứng mình rằng tất cả các đườngdẫn chương tình đa đến sự mâu thuẫn của điều khẳng định tính không antoàn đó Nếu đó là một trường hợp, điều kiện không an toàn không thểđúng Do đó, hệ thống là an toàn Bạn có thể cấu trúc và đa ra nhữngluận chứng về tính an toàn bằng đồ thị như hình dưới

Trong các luận chứng về tính an toàn chỉ ra trên hình có ba đường dẫn chương trình có thể dẫn tới việc gọi tới phương thức

administerInsulin Điều cần chứng mình rằng lượng insulin phân phối không bao giờ vượt quá maxDose

Tất cả các đường dẫn chương tình có thể dẫn tới phương thứcadministerInsulin đã được xem xét:

1 Không có nhánh nào của câu lệnh if thứ 2 được thực thi Nó chỉ cóthể xảy re nếu một trong hai điều sau xảy ra: currentDose là lơnhơn hoặc bằng minimumDose và nhỏ hơn hoặc bằng maxDose

2 Nhánh then của câu lệnh if thứ 2 được thực thi Trong trường hợp

đó, việc gán currentDose bằng 0 được thực thi Do đó, hậ điềukeienj đó là currentDose = 0

3 Nhánh else-if của câu lệnh if thứ 2 được thực thi Trong trườnghợp đó, việc gán currentDose bằng maxDose được thực thi Do đó,hậu điều kiện đó là currentDose = maxDose

Trong cả 3 trường hợp trên, các hậy điều kiện mâu thuẫn với cácđiều kiện và tính không an toàn lầ liều lượng thuốc được phần phói lànhiều hơn maxDose, vì vậy hệ thống là an toàn

Câu 8: các nội dung thuộc tính chất lượng phần mềm:

1 Tính đúng đắn:

- Làm đúng với khách hàng mong muốn

- Có thỏa mãn những điều đã được đặc tả (yêu cầu của đối tượngkhác)

2 Tính tin cậy được:

- Có thể trong đpị vào sự thực hiện các chức năng dự kiến

- Mức chính xác được đòi hỏi

3 Tính hiệu quả: tổng lượng nguồn lực tính toàn và mã yêu càu khithực hiện các chức năng của chương tình là thích hợp

4 Tính toàn vẹn là sự khống chế đơcj việc truy cập trái phép tới phầnmềm và dữ liệu hệ thống

5 Tính khả dụng: công sức để đọc hiểu, thao tác, chuẩn bị đầu vào,thể hiện đầu ra của chương trình là chấp nhận được

6 Tính bảo trì được: nỗ lực cần để định vị và xác đinh được một lỗitrong chương tình là chấp nhận được.

7 Tính mềm deo: nỗ lực cần để cải biên một chương tình là chấpnhận được

8 Tính kiểm thử được: nỗ lực cần để kiểm thử một chương tình vàđảm bảo rằng nó thực hiện đúng chức năng dự địh là chấp nhậnđược

9 Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ 1 môi trường phần cứng/ phần mmeef này sang một môi trường phần cứng/ phần mềm khác là chấp nhận được

10 Tính sử dụng lại được: khả năng chương trình (hoặc mộtphần của nó) có thể được dùng lại trong mộ ứng dụng khác

11 Tính liên tác đượ: nỗ lực đòi hỏi để ghép hệ thoogns chươngtình vào một hệ thống khác chập nhận được

Câu 9: tại sao phải đảm bảo chất lượng phần mềm.

Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu làsản xuất ra phần mềm có chất lượng cao hơn

Phải đảm bảo chất lượng phần mềm vì:

- Từ nhu cầu của khác hàng

- Từ nhà sản xuất: đảm bảo tính đồng đều của sản phầm làm ra

- Giúp nhà phân tích có được đặc ta chất lượng cao

- Giúp nhà thiết kế có được thiết kế chất lượng cao

- Theo dỗi chất lượng phần mềm

- Đánh giá ảnh hưởng của thay đổi về phương pháp luận và thủ tụclên chất lượng phần mềm

- SQA có những lị ích sau:

o Phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất

ít công sức và thời gian kiểm thử và bảo trì

o Độ tin cậy cao hơn và do đó khác hàng thỏa mãn hơn

o Giảm phí tổn bảo trì

o Giảm phí tỏn tổng thể toàn bộ vòng đời của phần mềm

- SQA đóng vai trò trong một doanh nghiệp phát triển phần mềm:

+ Đảm bảo chất lượng là một hoạt đọng cốt yêu trong bất kì mộtdoanh nghiệp nào làm ra sản phẩm được người khác dùng.

Câu 10: Các hoạt động chính của đảm bảo chất lượng phần mềm? Giải thích những hoạt động đó.

1 Áp dụng công nghệ kĩ thuật hiệu quả (phươg pháp, công cụ) giúpđể:

- Người phân tích có được đặc tả chất lượng cao

- Người thiết kế có được thiết kế với chất lượng cao

2 Tiến hành ra soát kỹ thuật chính thức: tac dụng không kém gì kiểmthử để phát hiện khiếm khuyết

3 Kiểm thử phần mềm: là một chiến lược nhiều bước với một loạtcác phương pháp thiết kế các trường hợp kiểm thử giúp đảm bảophát hiện ra các lỗi một các có hiệu quả Tuy nhiện, chỉ kiểm thửpàn mềm không thể tìm ra được hầu hết các lỗi sai

4 Tuân theo các chuẩn và các thủ tục chính thức là nhu cầu và điềukiện SQS Tuy nhiên còn tùy thuộc mỗi công ty Có 2 loại chuẩn

và thủ tục: do khác hàng hay chính quyền quy đinh và tự công tyđặt ra

- Đánh giá sự phù hợp với các chunar là một phần của việc rà soátchính thức

- Khi cần phải kiểm chứng (verification) sự phù hợp, nhóm SQA cóthể tiến hành kiểm toán (audit) riêng

5 Khống chế các thay đổi: đóng gpops trực tiếp vào chất lượng phầnmềm nhờ

- Chính thức hóa các yêu cầu đổi thay

- Đánh giá bản chất của sự đổi thay

- Khống chế các ảnh hưởng của sự đổi thay

- Đe dọa chủ yêu của chất lượng đến từ sự thay đổi, thay đổi là bảnchất của phần mềm

- Thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lantruyền

- Khóng chế thay đổi áp dụng tron suốt quá trình phát triển và trongquá trình bảo trị

6 Thực hiện đo lường: dùng để theo dỗi chất njgphanaf mềm đánhgiá ảnh hưởng những thay đổi phương pháp luận và thủ tục lênchất lượng phần mềm đã được cải tiến.

- Các độ đo phần mmeef hướng đến 2 mặt: quản lý (thủ tục); kĩthuật (phương pháp)

7 Báo cáo và quản lý các báo cáo

- Lập và lưu trữ báo cáo về SQA: phổ biến các thông tin SQA(người cần có thể biết); cung cấp các thủ tục để thu thập thông tin

- Đối tượng báo cáo là kết quả các hoạt động SQA: rà soát, kiểmtóa, khống chế đổi thay, kiểm thr và các hoạt động SQA khác

- Người phát triển sử dụng theo quy tác “cần thì biết” trong suất quátrình dự án

Câu 11: Rà soát (review) phần mềm là gì? Tại sao phải tiến hành rà soát phần mềm?

a Rà soát phần mềm là:

- Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗigiai đoạn để phát hiện ra những khiếm khuyết cần sửa chữa trướckhi sang giai đoạn sau

b Phải tiến hành rà soát phần mềm vì:

- Lợi ích hiển nhiên của FTR là sớm phát hiện các "khiếm khuyết"phần mềm để có thể chỉnh sửa từng khiếm khuyết một tr¬ước khibước sang bư¬ớc tiếp theo của quá trình phần mềm

- Các nghiên cứu của công nghiệp phần mềm đã chỉ ra rằng: cáchoạt động thiết kế tạo ra đến 50%-60% tổng số các khiểm khuyếttạo ra trong phát triển phần mềm

- Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗigiai đoạn VD: Lỗi không được phát hiện trong thiết kế tốn phí 1.0

để sửa chữa, trước kiểm kiểm thử: 6.5; trong kiểm thử: 15 và saukhi phân phối sẽ là từ 60.0 đến 100.0

Câu 12: Trình bày danh mục chính của rà soát phần mềm? Danh mục rà soát từng giai đoạn trong quy trình sx phần mềm?

Danh mục chính rà soát phần mềm

-Rà soát trong kỹ nghệ hệ thống

-Rà soát việc lập kế hoạch

-Rà soát phân tích yêu cầu phần mềm

-Rà soát thiết kế phần mềm (tương ứng với từng giai đoạn thiết kế)

-Các chức năng chủ yếu đã được xác định đủ và rõ ràng (không mơ hồ)?

-Các giao diện giữa các hệ con của hệ thống đã được xác định đủ vàđúng hay chưa?

-Các ràng buộc thực thi đã được thiết lập cho toàn hệ thống và cho từngphần tử hay chưa?

-Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa? -Khả năng chọn đã là đã tốt nhất chưa?

-Giải pháp này có khả thi kỹ thuật không?

-Có sự hoà hợp giữa các phần tử của hệ thống hay chưa?

-Cơ chế kiểm chứng và thẩm duyệt đã được thiết lập hay chưa?

b) Rà soát việc lập kế hoạch

Danh mục rà soát:

1 Phạm vi của phần mềm đã xác định đúng đắn chưa? có bị hạn chếhay không?

2 Thuật ngữ có trong sáng không?

3 Các nguồn lực (người, chi phí, thời gian): có đủ tương xứng vớiphạm vi đó không? Các nguồn lực đã có sẵn sàng chưa?cơ sở dựđoán giá cả có hợp lý không? dữ liệu năng xuất và chất lượngtrước đây có được sử dụng không? Sự khác biệt của ước lượng đãđược sử lý chưa?

Các công việc lên lịch biểu đã: xác định thích hợp chưa? Sắp xếp trình

tự thực hiện đúng logic chưa?

4 bố trí song song có phù hợp với các nguồn lực đã sẵn có haykhông?

5 Phương án tổ chức và nhân sự đã hợp lý chưa?

6 Các rủi ro trong tất cả các hạng mục quan trọng đã: xác định vàđánh giá đầy đủ chưa? Lập kế hoạch quản lý và kế hoạch thích hợpchưa?

7 Các nhiệm vụ đã thật sự được xác định và sắp xếp tuần tự chưa?,tính song song có hợp lý đối với các nguồn lực đã sẵn có haychưa?

8 Ngân sách và giới hạn chót được dự kiến: có hiện thực hay không?

có phù hợp với lịch biểu không?

c) Rà soát phân tích yêu cầu phần mềm

Danh mục rà soát phân tích yêu cầu:

- Phân hoạch vấn đề (hệ con) có đầy đủ hay không?

- Các giao diện trong và ngoài đã thực sự được xác định chưa?

- Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chínhxác hay không?

- (Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, cácthuộc tính và các quan hệ?

- Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?

- Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?

- Có thực hiện được với những ràng buộc quy định bởi các phần tử

hệ thống khác hay không?

- Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí haykhông?

- Các chuẩn thẩm định có đầy đủ hay không?

d) Rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)

Danh mục rà roát

 Rà soát thiết kế sơ bộ

 Các yêu cầu phần mềm có được phản ánh trong kiến trúc phầnmềm hay không?

 Có đạt được sự modul hoá hiệu quả không?

 Các modul có độc lập chức năng hay không

 Kiến trúc chương trình có được phân tách cấu trúc không?

 Các giao diện đã được xác định cho các modul và các phần tử hệthống ngoại lai chưa?

 Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?

 Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?

 Khả năng bảo trì đã được xem xét chưa?

 Các nhân tố chất lượng đã được đánh giá rõ ràng chưa?

 Rà soát thiết kế toàn bộ

 Thuật toán có hoàn thành chức năng mong muốn không?

 Thuật toán có đúng đắn logic không?

 Giao diện có phù hợp với thiết kế kiến trúc không?

 Độ phức tạp logic có phải chăng hay không?

 Sử lý sai đã được đặc tả chưa?

 Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?

 Nguyên lý lập trình cấu trúc đã xuyên suốt chưa?

 Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?

 Dùng hệ điều hành hay ldùng các đặc trưng độc lập ngôn ngữ?

 Có dùng logic component hoặc logic inverse?

 Khả năng bảo trì đã được xét tới chưa

e) Rà soát lập mã phần mềm

Danh mục rà soát

 Thiết kế đã thực sự được dịch thành mã chưa?

Có các sai sót chính tả hoặc in ấn nào không?

 Có thực sự dùng các quy ước ngôn ngữ hay không?

 Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngônngữ, ghi chú

 Có ghi chú nào không đúng đắn hoặc mơ hồ?

 Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?

Danh mục rà soát kế hoạch kiểm thử phần mềm:

- Các pha kiểm thử chủ yếu có thực sự được định rõ và được xắp xếpthứ tự hay chưa?

- Tiêu chuẩn yêu cầu kiểm thử có được thiết lập như một phần của phaphân tích yêu cầu phần mềm hay không?

- Các chức năng chủ yếu có được trình diễn sớm không?

- Kế hoạch kiểm thử có phù hợp với kế hoạch dự án tổng thể haykhông?

- Lịch trình kiểm thử có được xác định rõ ràng hay không?

- Nguồn lực và công cụ kiểm thử đã được minh định và đã sẵn sànghay chưa?

- Đã thiết lập cơ chế lưu trữ các báo cáo chưa?

- Các thiết bị và các tình huống kiểm thử đã được minh định chưa?

- Công việc phát triển kiểm thử đã được lập lịch chưa?

- Kiểm thử áp lực cho phần mềm đã được đặc tả chưa?

- Cả hai loại kiểm thử hộp trắng và hộp đen đã được đặc tả chưa?

- Có phải tất cả các đường logic độc lập đều được kiểm thử?

- Có phải tất cả các ca kiểm thử đều đã được minh định và lập danhsách với đủ các kết quả mong đợi?

- Việc xử lý sai có được kiểm thử?

- Các giá trị biên có được kiểm thử?

- Các yêu cầu thời gian và sự diễn tiến có được kiểm thử?