Ch ương 23: SOFTWARE TESTING

1. Chương 23: SOFTWARE TESTING Nhóm 2. Lớp 07TH1D

2. Mục tiêu • 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. Mục tiêu 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ử.

4. Kiểm thử phần mềm • 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)

5. Kiểm thử phần mềm • 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 đó.

6. Kiểm thử phần mềm • 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)

7. Kiểm thử phần mềm • 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.

8. Kiểm thử phần mềm • 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.

9. Kiểm thử phần mềm • 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ử.

10. Kiểm thử phần mềm Mô hình quá trình kiểm thử phần mềm • 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.

11. Kiểm thử hệ thống-System testing • 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.

12. Kiểm thử hệ thống-System testing • Ở 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.

13. Kiểm thử hệ thống-System testing +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ó.

14. Kiểm thử tích hợp • 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.

15. Kiểm thử tích hợp • 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.

16. Kiểm thử tích hợp • 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.

17. Kiểm thử tích hợp • 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.

18. Kiểm thử phát hành • 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.

19. Kiểm thử phát hành • 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.

20. Kiểm thử phát hành • 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.

21. Kiểm thử phát hành • 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ỏ.

22. Kiểm thử phát hà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.

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

24. Kiểm thử hiệu suất-Performance testing • 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.

25. Kiểm thử hiệu suất-Performance testing • 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.

26. Kiểm thử hiệu suất-Performance testing • 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.

27. Component testing (kiểm thử thành phần)

28. 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 đó.

29. Kiểm thử 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.

30. Kiểm thử 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:

31. Kiểm thử thành phần • 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.

32. Kiểm thử thành phần • Để 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

33. 14.14

34. Kiểm thử thành phần • 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.

35. Kiểm thử thành phần • _ 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.

36. Kiểm thử giao diện: _ 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.

37. _ Mô hình 23.7 minh họa cho tiến trình kiểm tra giao diện. Theo đó, những thành phần A,B và C được hợp lại với nhau để tạo thành một khối lớn hơn như một hệ thống con. Những ca kiểm thử không áp dụng việc kiểm tra cá thể từng thành phần nhưng có thể giao tiếp chúng lại để tạo nên những thành phần tổng hợp.

38. Kiểm thử giao diện: • _ 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.

39. Kiểm thử giao diện: • _ 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.

40. Kiểm thử giao diện: • _ 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.

41. Test case design

42. Test case design • 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ử: • Kiểm thử dựa trên yêu cầu-Requirements-based testing • Kiểm thử phân vùng-Patition testing. • Kiểm thử cấu trúc-Structural testing.

43. Requirements-based 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 đó.

44. Requirements-based testing _ 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.

45. Requirements-based testing 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.

46. Requirements-based testing • _ 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.

47. Kiểm thử cấu trúc-Structural testing • 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.

48. Kiểm thử cấu trúc-Structural testing Dữ liệu kiểm thử Các kiểm thử Lấy Code thành phần Các output kiểm thử

49. Tìm kiếm nhị phân- Phần vùng tương đương • Đ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ẻ.

50. Tìm kiếm nhị phân- Phần vùng tương đương