Nhóm 2. Lớp 07TH1D

Mục tiêu của chương này là mô tả quá trình kiểm thử phần mềm và giới thiệu những kĩ thuật kiểm thử.

1) Hiểu được sự khác nhau giữa kiểm thử phể chuẩn(validation testing) và kiểm thử sai sót(defect testing).2) Hiểu được nguyên tắc kiểm thử hệ thống(system testing) và kiểm thử thành phần(component testing).

3) Hiểu được 3 chiến lược có thể được sử dụng để tạo ra các ca kiểm thử hệ thống(system test cases).4) Hiểu được những đặc điểm thiết yếu của các công cụ phần mềm(software tools) hỗ trợ tự động hóa việc kiểm thử.

Có 2 hoạt động kiểm thử căn bản là: +Kiểm thử thành phần(kiểm từng phần của hệ thống)+Kiểm thử hệ thống(kiểm toàn bộ hệ thống)

Mục đích của kiểm thử thành phần?+Phát hiện ra sai sót ở những thành phần riêng lẻ của chương trình(hàm, đối tượng hay thành phần dùng lại).

Mục đích của kiểm thử hệ thống?. +Xác địch đã đạt được các yêu cầu chức năng và phi chức năng, các tác nhân không mong đợi.+Phát hiện ra sai sót đã bị bỏ qua ở khâu kiểm thử trước đó.

Quá trình kiểm thử phần mềm có 2 mục đích phân biệt:1) Chứng minh cho người lập trình viên và khách hàng thấy phần mềm đạt yêu cầu của nó(tài liệu của phần mềm hoặc tính năng phần mềm).2) Phát hiện lỗi, thiếu sót không đúng với tính năng kĩ thuật đã định trước.(lệch lạc dữ liệu, tính toán sai, giao tiếp không tốt với hệ thống khác)

Mục đích 1 dẫn tới công việc kiểm thử phê chuẩn(validation testing).Hệ thống được trải qua các ca kiểm thử(test cases) để công nhận chức năng mong đợi.+Kiểm thử phê chuẩn thành công khi hệ thống vận hành chính xác.

Mục đích 2 dẫn tới công việc kiểm thử sai sót(defect testing). Hệ thống được trải qua các ca kiểm thử(test cases) để phát hiện các sai sót.+Kiểm thử sai sót thành công khi phát hiện được điểm sai khiến hệ thống vận hành không chính xác.

Kết luận:* Kiểm thử mọi khía cạnh, mọi trường hợp thực thi chương trình là không thể.* Do đó, phải chọn ra được tập các ca kiểm thử(test cases) có thể.* Nên có chính sách giải quyết để chọn ra các ca kiểm thử dựa trên tổng thể, kinh nghiệm và đặc điểm của hệ thống đang vận hành.

Ví dụ:* Tất cả các câu lệnh của chương trình nên thực thi ít nhất 1 lần.* Nếu có chức năng user input thì tất cả các hàm nên được kiểm thử với các input hợp lệ và không hợp lệ.*Tập tất cả các hàm được truy cập qua cùng 1 thực đơn(menu) nên được kiểm thử.

Test cases: bảng ghi chi tiết các inputs để kiểm tra và các outputs được người ta mong đợi và báo cáo những gì sẽ được kiểm thử.

Test data: dữ liệu để kiểm thử(inputs), có thể được phát sinh tự động.

Mô hình quá trình kiểm thử phần mềm

Kiểm thử hệ thống bao gồm: +tích hợp nhiều thành phần(components) để thực hiện chức năng của hệ thống.+kiểm tra lại hệ thống được tích hợp.

Trong quá trình phát triển lặp, kiểm thử hệ thống được hiểu là kiểm thử tăng dần(increment) để phân phối đến khách hàng.

Trong quá trình thác nước, kiểm thử hệ thống được hiểu là kiểm thử toàn bộ hệ thống.

Ở các hệ thống phức tạp, có 2 giai đoạn để kiểm thử hệ thống:1) Kiểm thử tích hợp(integration testing): đội ngũ kiểm thử truy cập vào mã nguồn của hệ thống. Kiểm thử các thành phần của hệ thống sau khi được tích hợp. 2)Kiểm thử phát hành(Release testing): Kiểm thử một phiên bản của toàn bộ hệ thống để có thể phát hành cho người sử dụng.

+Nếu có khách hàng tham gia trong quá trình kiểm thử phát hành thì được gọi là kiểm thử chấp nhận(acceptance testing). Nếu phiên bản phát hành đủ tốt, họ sẽ chấp nhận sử dụng.

*Kết luận:+Ưu thế của kiểm thử tích hợp là phát hiện sai sót trong hệ thống.+Ưu thế kiểm thử phát hành là công nhận hệ thống đạt đầy đủ yêu cầu của nó.

Quá trình tích hợp hệ thống gồm: +Xây dựng hệ thống từ các thành phần của nó.+Kiểm thử hệ thống hợp thành với các vấn đề sau khi tương tác, giao tiếp giữa các thành phần.

Bộ khung tổng thể của hệ thống được phát triển trước, cách thành phần gắn vào sau, gọi là top-down integration.

Tích hợp các thành phần có cấu trúc bên dưới trước như: dịch vụ chung, mạng, truy cập csdl. Sau đó gắn thêm các thành phần chức năng, gọi là bottom-up integration.

Vấn để xảy ra trong suốt quá trình kiểm thử là những lỗi cục bộ(localising errors). Một khi có output bất thường được phát hiện thì khó có thể xác định được lỗi xảy ra ở đâu.

Để xác định đúng vị trí lỗi ta nên kiểm thử tăng dần hệ thống.

Ta nên tích hợp 1 hệ thống nhỏ trước và kiểm tra lại hệ thống này.

ABCD là các thành phần(components) T1,T2,T3 là các kiểm thử. Test sequence 2 thực hiện lại các kiểm

thử(regression testing) T1,2,3 nếu có lỗi thì chắc chắn là do tương tác với C.

Ưu tiên tích hợp trước các thành phần được sử dụng nhiều cho các chức năng hệ thống.

Kết luận:1)Kiểm thử tích hợp top-down phát hiện lỗi tốt hơn trong việc phê chuẩn kiến trúc của hệ thống. Và có thể chứng minh được hệ thống họat động tốt sớm hơn trong quá trình phát triển phần mềm.2) Sự thi hành của hệ thống thì kiểm thử tích hợp bottom-up là tốt hơn.

Là quá trình kiểm thử bản phát hành của hệ thống, sẽ được phân phối cho khách hàng.

Mục đích chính của quá trình là làm tăng độ tin tưởng của hệ thống và đã đạt yêu cầu.

Để chứng minh hệ thống đạt yêu cầu thì cần phải chỉ ra nó đã đạt các chức năng, hiệu suất, độ tin cậy, không bị lỗi khi sử dụng.

Là quá trình kiểm thử hộp đen(black-box), các kiểm thử được lấy từ bảng mô tả chức năng(specification) của hệ thống.

Testers không biết sự thi hành bên trong hệ thống(black-box). Họat động của nó được xác định bởi các inputs và outputs liên quan.

Còn được gọi là kiểm thử chức năng vì các testers chỉ phải kiểm thử chức năng bên ngoài, không kiểm thử bên trong phần mềm.

Nếu outputs nằm ngoài dự đoán(tập Oe) thì xác định vấn đề này.

Bằng kinh nghiệm, tài liệu chọn ra các test cases(tập Ie) dễ làm cho hệ thống họat động sai.

Một số kinh nghiệm của Whittaker:1)Chọn những inputs bắt buộc hệ thống phát sinh lỗi.2)Thiết kế các inputs làm cho vùng đệm inputs đó tràn.3)Lặp lại cùng 1 input hay 1 dãy inputs nhiều lần.4)Bắt buộc các outputs ngoài ý muốn phát sinh.5)Bắt buộc kết quả tính toán quá lớn hay quá nhỏ.

Để công nhận hệ thống đạt đủ các chức năng thì nên kiểm thử dựa trên kịch bản(scenario-based testing) đã được thực hiện trong lúc phát triển test cases.

Nên xếp lại thứ tự các kịch bản của từng chức năng để kiểm thử, kịch bản quan trọng đặt trước, kịch bản ít sử dụng hoặc ngoại lệ đặt sau.

Có thể viết trước các report để kiểm thử với report của hệ thống.

Các kiểm thử hiệu suất được thiết kế để đảm bảo hệ thống có thể xử lý được số lượng load dự định của nó.

Bao gồm việc tạo các kiểm thử mà lượng load tăng dần cho đến khi hiệu suất hệ thống không thể chấp nhận.

Kinh nghiệm cho thấy nên thiết kế các kiểm thử xung quanh những giới hạn của hệ thống. Còn được gọi là kiểm thử nhấn mạnh(stress testing). Tạo ra các yêu cầu nằm ngoài giới hạn phần mềm

Ví dụ hệ thống có xử lý 300 giao dịch(giao dịch)/1giây.

Kiểm thử nhấn mạnh kiểm tra thiết kế số lần load lớn nhất cho đến khi hệ thống lỗi. Kiểu kiểm thử này có 2 chức năng:1)Trong mọi tình huống, hệ thống không nên bị mất dữ liệu hoặc mất các dịch vụ của người sử dụng. Chỉ có thể bị lỗi nhẹ.2)Phát hiện được sai sót của hệ thống mà ở tình huống bình thường không thấy.

(kiểm thử thành phần)

Component testing (kiểm thử thành phần) là một quá trình kiểm thử từng thành phần riêng biệt trong toàn hệ thống. Quá trình này diễn ra với mục đích tìm ra những thiếu sót, lỗi trong từng thành phần của toàn hệ thống. Như đã đề cập ở phần trước, trong suốt quá trình kiểm thử lỗi, người thiết kế thành phần nào sẽ có trách nhiệm kiểm tra lỗi thành phần đó.

Có 3 loại thành phần được test trong bước này:

1/ Những hàm con hoặc phương thức của từng đối tượng.

2/ Các lớp đối tượng có nhiều thuộc tính và phương thức.

3/ Các thành phần kết hợp với nhau tạo nên nhiều hàm hoặc đối tượng khác nhau. Những thành phần kết hợp này có giao thức được định nghĩa để sử dụng truy cập tất cả các chức năng của từng thành phần.

_Những hàm riêng hoặc phương thức được xem đơn giản nhất trong mỗi thành phần và thử nghiệm của bạn sẽ là tập hợp các cuộc gọi đến những hàm này với các thông số đầu vào khác nhau. Bạn có thể sử dụng những phương pháp tiếp cận để thiết kế những phép kiểm thử để thiết kế phép kiểm tra các hàm chức năng hoặc phương thức.

_ Khi bạn đang thử nghiệm các lớp đối tượng, bạn nên thiết kế phép kiểm tra của mình phải bảo đảm kiểm tra đầy đủ tất cả các chức năng của đối tượng đó. Theo đó, việc kiểm tra lớp đối tượng bao gồm:

1/ Các phép kiểm thử diễn ra trong sự độc lập với toàn bộ hoạt động liên kết với đối tượng.

2/ Kiểm thử các thiết lập và truy vấn của toàn bộ thuộc tính liên kết với đối tượng.

3/ Tất cả các sự kiện có thể làm thay đổi giá trị của đối tượng đều phải được mô phỏng.

 Xem xét cho ví dụ ở chương 14 có hình minh họa 23.6. Nó chỉ có 1 thuộc tính đơn để nhận dạng. Nó là 1 hằng số được thiết lập khi trạm thời tiết được cài đặt. Vì vậy bạn chỉ cần kiểm tra xem hằng số đó đã được thiết lập hay chưa. Bạn cần phải xác định những ca kiểm thử cho những bài báo cáo, hiệu chỉnh, khởi động và tắt. Thông thường các bài kiểm thử sẽ diễn ra độc lập giữa các phương thức, nhưng trong một số trường hợp thì khác. Ví dụ như khi muốn kiểm tra chức năng tắt thì trước hết ta phải khởi động mới kiểm tra tiếp được.

Để kiểm tra trạng thái của trạm khí tượng, bạn sử dụng mô hình 14.14. Sử dụng mô hình này, bạn có thể xác định được trình tự thay đổi của các trạng thái đã được đưa vào kiểm tra và xác định được chuỗi sự kiện để khiến chúng có sự thay đổi trên. Về nguyên tắc, bạn nên kiểm tra từng quá trình thay đổi của từng trạng thái, nhưng trong thực tế kinh phí sẽ rất tốn kém. Một số ví dụ về các trình tự kiểm thử trong ví dụ trạm khí tượng :Tắt → Đợi xử lý → Tắt.Đợi → Hiệu chỉnh → Kiểm tra → Chuyển trạng thái

→ ĐợiĐợi → Thu thập thông tin → Đợi → sơ lược →

Chuyển trạng thái → Đợi

• Nếu sử dụng tính thừa kế, thì điều này sẽ làm cho việc thiết kế các bài kiểm tra lớp đối tượng trở nên khó khăn hơn. Nơi mà một lớp được cung cấp các hoạt động được thừa kế bởi một số các lớp con khác, thì khi kiểm tra đến lớp đó ta phải kiểm tra toàn bộ các lớp mà nó đã thừa kế. Nguyên nhân của việc kiểm tra tất cả các lớp mà nó thừa kế là vì khi di truyền các phương thức thì trong một số trường hợp giả định nó sẽ làm thay đổi các họat động cũng như phương thức của các lớp khác.

Tương tự khi một lớp thừa kế bị ghi đè bởi một phương thức hay thuộc tính khác thì nó phải được kiểm tra lại.

_ Khái niệm về lớp tương đương, được đề cập trong phần 23.3.2, cũng có thể áp dụng trong các lớp đối tượng. Các bài kiểm thử rơi trúng vào cùng lớp tương đương có thể sử dụng cùng một thuộc tính của đối tượng. Vì vậy, các lớp tương đương phải được xác định từ những bước khởi tạo, truy nhập, và câp nhật trong tất cả các thuộc tính của lớp đối tượng.

_ Nhiều phần trong hệ thống có những phương thức rất phức tạp hoặc những đối tượng kết hợp với nhau tạo ra nhiều mối ảnh hưởng liên tiếp. Như đã được đề cập ở chương 19, những chức năng được bao bọc bởi những kỹ thuật lập trình, và mình chỉ tiếp cận với những chức năng đó hoàn toàn thông qua những giao diện đã được xác định trước. Việc kiểm tra những thành phần kết hợp này liên quan chính thống với việc kiểm tra thành phần giao diện ứng xử theo đặc điểm kỹ thuật của chúng.

_ Bước kiểm tra giao diện này là đặc biệt quan trọng trong hướng đối tượng và trong các bước thiết kế các thành phần cơ bản khác. Những thành phần và đối tượng được định nghĩa trước trong giao diện của chúng và có thể sử dụng lại để kết hợp tạo nên các thành phần khác trong hệ thống. Lỗi giao diện trong những thành phần kết hợp thì không thể phát hiện bằng cách kiểm thử các đối tượng riêng biệt hoặc các thành phần riêng biệt. Những lỗi có trong những thành phần kết hợp có thể sẽ phát sinh do tính thừa kế giữa các phần đã kết hợp với nhau.

_ Có nhiều loại giao diện trong các thành phần chương trình nên kết quả sẽ tạo ra nhiều loại lỗi giao diện phát sinh, một số loại giao diện:

1/ Giao diện hằng số 2/ Giao diện chia sẻ bộ nhớ 3/ Giao diện thủ tục 4/ Giao diện gửi thông điệp.

_ Những lỗi giao diện thường được coi như là những lỗi phức tạp nhất của hệ thống. Thường rơi vào 3 trường hợp:

1/ Lạm dụng giao diện( interface misuse) 2/ Gọi sai giao diện( interface misunderstanding). 3/ Timing errors.

_ Việc kiểm thử những thiếu sót trong giao diện là khó vì những lỗi giao diện này thường lộ ra trong những điều kiện khác thường. Ví dụ, một đối tượng sử dụng hàng đợi queue với cấu trúc dữ liệu đã thiết kế sẵn. Mà một đối tượng khác gọi đến và sử dụng queue này nhưng không kiểm tra xem queue có rỗng không mà đưa dữ liệu vào sẽ dẫn đến lỗi. Lỗi này chỉ được phát hiện khi ta đem so kết quả kiểm thử với kết quả chứa trong queue.

_Những sự cố khác sẽ nảy sinh bởi sự ảnh hưởng lẫn nhau giữa các bộ phận và đối tượng. Những lỗi của một đối tượng có thể phát hiện khi một đối tượng khác xử lý sai. Ví dụ như khi một đối tượng cần xử lý thông tin và gọi cho một đối tượng khác có chức năng xử lý thông tin đó và trả về kết quả sai.

Mục đích của quy trình thiết kế kiểm thử là tạo ra 1 bộ các ca kiểm thử hiệu quả trong việc phê chuẩn và kiểm thử sai sót.

Những phương pháp tiếp cận để thiết kế kiểm thử:

1.Kiểm thử dựa trên yêu cầu-Requirements-based testing

2.Kiểm thử phân vùng-Patition testing.3.Kiểm thử cấu trúc-Structural testing.

_ Nguyên tắc kiểm thử chung của các yêu cầu kĩ thuật là yêu cầu đó phải khả thi trong việc kiểm thử.

_ Kiểm thử dựa trên yêu cầu là một kỹ thuật kiểm thử phê chuẩn. Xem xét mỗi yêu cầu và tạo ra kiểm thử cho yêu cầu đó.

_ Xem xét yêu cầu trong ví dụ LIBSYS.

LIBSYS requirements+ Người dùng có thể tìm thấy các thiết lập gốc trong database và chọn một phần nhỏ trong đó.

+ Hệ thống sẽ cung cấp góc nhìn thích hợp cho người dùng để đọc những tài liệu trong kho dữ liệu

+ Mỗi yêu cầu sẽ được cấp một định dạng (Order_ID) mà người dùng có thể sao chép vào khu dữ liệu.

LIBSYS Test _ Khởi đầu việc tìm kiếm của người dùng là xác định xem

phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm một cơ sở dữ liệu.

_ Khởi nguồn việc tìm kiếm của người dùng là xác định xem phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm hai cơ sở dữ liệu.

_ Bắt đầu việc tìm kiếm của người dùng là xác định xem phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm hơn hai cơ sở dữ liệu.

_ Chọn một cơ sở dữ liệu và một cuộc tìm kiếm của người dùng và xác định chúng có tồn tại hay không.

_ Chọn nhiều hơn một cơ sở dữ liệu và nhiều cuộc tìm kiếm hơn của người dùng và xác định chúng có tồn tại hay không.

_ Bạn có thể thấy việc kiểm thử yêu cầu không có nghĩa là chỉ viết một ca kiểm thử cho yêu cầu đó mà bạn phải nhiều ca kiểm thử cho một yêu cầu mới có thể khái quát được yêu cầu đó.

_ Kiểm thử yêu cầu trong hệ thống LIBSYS có thể được phát triển bằng phương pháp như vậy. Ở yêu cầu thứ 2, bạn sẽ viết kiểm thử để phân phối tài liệu cho hết các kiểu mà hệ thống xử lý và bảo đảm chúng phải được hiển thị. Yêu cầu thứ ba thì đơn giản hơn. Để kiểm thử yêu cầu này, bạn có thể mô phỏng đặt yêu cầu và xem chúng có được hệ thống nhận dạng và có hiện diện trong bản xác nhận của người dùng và có tồn tại duy nhất không.

Còn được gọi là kiểm thử hộp trắng. Nguồn gốc của các ca kiểm thử là dựa theo

cấu trúc của chương trình. Hiểu biết chương trình thì có thể xác định được các ca kiểm thử.

Mục đích là kiểm thử tất cả các câu lệnh của chương trình.

Dữ liệu kiểm thử

Lấy

Code thành phần

Các kiểm thử

Các output kiểm thử

Điều kiện trước thỏa, phần tử khóa trong mảng.

Điều kiện trước thỏa, phần tử khóa không trong mảng.

Điều kiện trước không thỏa, phần tử khóa trong mảng

Điều kiện trước không thỏa, phần tử khóa không trong mảng

Mảng đầu vào có 1 giá trị. Mảng đầu vào có những giá trị chẵn. Mảng đầu vào có những giá trị lẻ.

Mục đích kiểm thử đường đi là để chắc rằng mỗi hướng đi của chương trình được thực thi ít nhất 1 lần

Điểm bắt đầu của kiểm thử đường đi nằm ở biểu đồ dòng chương trình. Nodes đại diện cho mỗi dòng lệnh của chương trình. Các cung đại diện cho dòng điều khiển

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … Các ca kiểm thử nên lấy từ kết quả của

những đường đi trên. Phân tích động chương trình có thể được

sử dùng để kiểm tra những đường đi trên.

Kiểm thử phần mềm là giai đoạn khó nhọc và tốn nhiều tiền trong tiến trình làm phần mềm.

Vì vậy, những công cụ test được phát triển, những công cụ này đưa ra một phạm vi thuận lợi để có thể giảm bớt chi phí test một cách đáng kể.

Những hệ thống như JUnit hỗ trợ sự thực hiện tự động của quá trình test.

Một chu trình kiểm thử phần mềm là sự tổng hợp những công cụ để hỗ trợ quá trình kiểm thử,

để hỗ trợ quá trình kiểm thử, một chu trình kiểm thử có thể bao gồm nhiều công cụ để mô phỏng những phần khác nhau của hệ thống và phát sinh ra những dữ liệu để kiểm thử hệ thống.

Test manager: quản lý sự vận hành của chương trình test, theo dõi dữ liệu, những kết quả và những điều kiện thuận lợi mà chương trình được kiểm thử.

Test data generator: phát sinh ra những dữ liệu thực nghiệm cho chương trình để test. điều này có thể được thực hiện bằng việc lựa chọn dữ liệu từ cơ sở dữ liệu hay bằng cách sử dụng mẫu để phát sinh dữ liệu ngẫu nhiên phù hợp.

Oracle: phát sinh ra những dự đoán của những kết quả kiểm thử được mong đợi. Oracle có thể là những phiên bản chương trình trước đây hay hệ thống đầu tiên.

File comparator: so sánh kết quả của quá trình test với kết quả test trước đó và rút ra báo cáo về sự khác nhau giữa chúng.

Report generator: cung cấp báo cáo định nghĩa và phương tiện phát sinh cho kết quả test.

Dynamic analyser: thêm mã vào một chương trình để đếm số lần mỗi câu lệnh được thực thi. sau khi test, một cấu hình thực thi được phát sinh chỉ ra mỗi câu lệnh trong chương trình được thực thi có thường hay không.

Simulator: nhiều chưong trình mô phỏng khác nhau được cung cấp. Mục tiêu những trình mô phỏng là mô phỏng bộ máy mà chương trình thực thi. Những trình mô phỏng giao diện người dùng là những chương trình hướng kịch bản có mổ phỏng giao tiếp với người dùng. Sử dụng trình mổ phỏng cho nhập xuất(I/O) đồng nghĩa với việc các giao dịch bị lập lại.

Khi sử dụng cho hệ thống test lớn, những công cụ này phải được cấu hình phù hợp cho hệ thống đặc biệt được test.

Test chỉ có thể hiển thị những lỗi hiện tại trong chương trình. nó không thể chứng minh rằng không còn những lỗi, thiếu sót còn lại.

Những người phát triển thành phần chịu trách nhiệm về test thành phần, test hệ thống là trách nhiệm của một đội riêng biệt.

Sự thử hợp nhất là những sự thử tăng dần của hệ thống, sự thử phiên bản bao gồm kiểm tra một hệ thống được gửi tới khách hàng.

Sử dụng kinh nghiệm và hướng dẫn để chọn trường hợp kiểm thử mà có hiệu quả trong việc tìm ra những khuyết điểm trong những hệ thống khác.

Test giao diện được thiết kết để tìm ra những khuyết điểm trong giao diện của những thành phần phức.

Phân chia tương đương là cách tìm ra những trường hợp test.

Test cấu trúc dựa trên phân tích một chương trình và thu được những test từ sự phân tích này.

Test automation giảm bớt chi phí Test bằng việc hỗ trợ quá trình test với một phạm vi của những công cụ phần mềm.