Thiết kế test case sử dụng kỹ thuật phân lớp tương đương và phân tích giá trị biên

Các kỹ thuật thiết kế test case

  • Phân lớp tương đương 
  • Phân tích giá trị biên
  • Sử dụng bảng quyết định
  • Sử dụng biểu đồ nguyên nhân-hậu quả
  • Sử dụng biểu đồ chuyển trạng thái

1. Kỹ thuật phân lớp tương đương

Khái niệm: Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các trường hợp kiểm thử

Giả thiết: Nếu một giá trị trong lớp tương đương đúng thì tất cả các giá trị khác cũng đúng

Xác định các trường hợp kiểm thử

  • Chia các giá trị đầu vào, đầu ra thành các lớp tương đương nhau
  • Gán 1 giá trị cho mỗi lớp tương đương
  • Viết các trường hợp kiểm thử đảm bảo phủ được nhiều nhất có thể các lớp tương đương hợp lệ
  • Viết các trường hợp kiểm thử sao cho mỗi trường hợp kiểm thử chỉ phủ duy nhất có thể các lớp tương đương không hợp lệ

Tình huống (1) – Vé tàu

Yêu cầu: Nếu bạn mua vé tàu để đi từ 7.30 sáng đến trước 9:30 sáng hoặc sau 4:00 chiều cho đến 7:30 tối (‘giờ cao điểm’), bạn phải trả 100% giá vé. Bạn sẽ được giảm giá nếu mua vé đi tàu giữa 9:30 sáng và đến 4:00 chiều, hoặc sau 7:30 tối. Tàu không hoạt động từ 12 giờ đêm đến trước 3h sáng.

Câu hỏi: Đâu là các lớp tương đương để kiểm tra giờ tàu – giá vé?

2. Kỹ thuật phân tích giá trị biên

bugarea

  • Lỗi thường có xu hướng xảy ra ở gần giá trị biên 
  • Giá trị biên là nơi rất tốt để tìm lỗi
  • Cần kiểm tra các giá trị biên ở cả 2 phía

Tình huống (1) – Vé tàu

Yêu cầu: Nếu bạn mua vé tàu để đi từ 7.30 sáng đến trước 9:30 sáng hoặc sau 4:00 chiều cho đến 7:30 tối (‘giờ cao điểm’), bạn phải trả 100% giá vé. Bạn sẽ được giảm giá nếu mua vé đi tàu giữa 9:30 sáng và đến 4:00 chiều, hoặc sau 7:30 tối. Tàu không hoạt động từ 12 giờ đêm đến trước 3h sáng.

Câu hỏi:

  1. Đâu là các giá trị biên và các  lớp tương đương để kiểm tra giờ tàu – giá vé?
  2. Tóm tắt các TC bạn sẽ sinh ra?

3. Thực hành

Tình huống (2): ứng dụng cho vay

  • Tên khách hàng – 2-64 ký tự chữ cái + Space
  • Số tài khoản – 6 chữ số, số đầu tiên ≠ 0
  • Khoản vay – Từ £500 đến £9000
  • Kỳ hạn – Từ 1 đến 30 năm
  • Tiền trả hàng tháng – Nhỏ nhất £10
  • Thời hạn
  • Tiền trả lại
  • Lãi suất
  • Tổng số tiền phải trả

Tên khách hàng

Screen Shot 2018-05-07 at 12.04.09 AM

Số tài khoản

Screen Shot 2018-05-07 at 12.04.55 AM

Khoản vay

Screen Shot 2018-05-07 at 12.05.24 AM

Bảng tổng hợp các lớp

Điều kiện Lớp hợp lệ Mã lớp Lớp không hợp lệ Thẻ Giá trị biên hợp lệ Thẻ Giá trị biên không hợp lệ Thẻ
Tên khách hàng 2 – 64 ký tự hợp lệ V1

 

< 2 ký tự X1 2 ký tự B1 1 ký tự D1
> 64 ký tự X2 64 ký tự B2 65 ký tự D2
Các ký tự không hợp lệ X3 0 ký tự D3
Số tài khoản 6 chữ số. Chữ số đầu tiên khác 0 V2

 

< 6 chữ số X4 100000 B3 5 chữ số D4
> 6 chữ số X5 999999 B4 7 chữ số D5
Chữ số đầu tiên = 0 X6 0 chữ số D6
Không phải chữ số X7
Khoản vay 500 – 9000 V3 < 500 X8 500 B5 499 D7
>9000 X9 9000 B6 9001 D8
Không phải số nguyên X10
Giá trị

rỗng

X11

 

Thiết kế test case

Screen Shot 2018-05-07 at 12.09.12 AM

 

——–END———

Advertisements

Khái niệm và nguyên tắc căn bản về kiểm thử

Nội dung bài học

1. Khái niệm căn bản về kiểm thử
2. Vai trò – tầm quan trọng của kiểm thử
3. Nguyên tắc thực hiện kiểm thử
4. Xác định thời điểm kết thúc kiểm thử

1. Khái niệm căn bản về kiểm thử

  1. Khái niệm kiểm thử phần mềm
  2. Cấp độ (giai đoạn) kiểm thử
  3. Tình huống kiểm thử
  4. Loại hình kiểm thử
  5. Phương pháp kiểm thử

1.1 Khái niệm kiểm thử phần mềm

  • Khái niệm: Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả,và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.
  • Mục đích: Tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm.

1.2 Giai đoạn kiểm thử

  • Kiểm thử đơn vị– Unit testMột đơn vị-Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit.

    Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra.

    Unit Test thường do lập trình viên thực hiện trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit.

     

  • Kiểm thử tích hợp– Intergration TestIntegration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

    Hai mục tiêu chính của Integration Test:

    • Phát hiện lỗi giao tiếp xảy ra giữa các Unit
    • Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test). 
  • Kiểm thử hệ thống – System TestMục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

     

  • System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. 
  • Kiểm thử chấp nhận sản phẩm– Acceptance TestThông thường, sau giai đoạnS ystem Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

    Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

1.3 Tình huống kiểm thử

  • Positive test: Còn gọi lại clean test hay valid test. Test những trường hợp mà user sử dụng hệ thống một cách bình thường, đúng ý đồ thiết kế.
  • Negative test: Còn gọi là dirty test hay invalid test.. Test  những trường hợp user làm những hành động khác thường hay đưa vào những dữ liệu không hợp lệ.

Các điều kiện mà người ta nghĩ ra để kiểm thử một sản phẩm nào đó có thể được chia làm hai loại: (1) loại thuộc nhóm những điều kiện thông thường mà một người sử dụng theo logic thông thường sẽ tạo ra chúng, (2) loại thuộc nhóm những điều kiện chỉ xảy ra khi NSD nhầm lẫn về logic hay thao tác, hoặc có kẻ cố tình phá hoại hoặc truy cập vào những thông tin mình không được phép vào, hặc khi môi trường sử dụng phần mềm có điểm bất thường (như không kết nối được với Database, mất điện đột ngột, User không được phân quyền…). Tương ứng với đó ta có hai khái niệm: (1) positive test hay còn gọi là test sạch, và (2) negative test hay còn gọi là test bẩn.

1.4 Loi hình kim th

Ứng với mỗi khía cạnh chất lượng nào đó của sản phẩm cần test – có các loại hình kiểm thử

  • Kiểm thử chức năng (Functional Test): nhằm bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. 
  • Kiểm thử hiệu năng (Performance Test): Bảo đảm hiệu suất hoạt động của hệ thống xét về thời gian cần thiết để phản hồi cho người dùng, tài nguyên (ví dụ RAM, CPU) bị tiêu tốn. Bao gồm các test để bảo đảm tối ưu việc sử dụng bộ nhớ nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn, các test để bảo đảm hệ thống vận hành được dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc)… 
  • Kiểm thử tính dễ dùng (Usability testing): bảo đảm người dùng dể hiểu, dễ đoán cách dùng phần mềm và có thể thao tác nhanh chóng trên phần mềm để thực hiện một tác vụ nào đó.
  • Kiểm thử bảo mật (Security testing): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. 
  • Kiểm thử khả năng cài đặt (Installability testing): bảo đảm phần mềm có thể được cài đặt hoặc gỡ bỏ thành công.
  • Kiểm thử khả năng phục hồi (Recovery testing): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn địnhtrước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến… 
  • Kiểm thử tính tương thích (Compatibility testing): bảo đảm phần mềm có thể tương thích được với nhiều hệ điều hành/trình duyệt/cấu hình phần mềm/phần cứng khác nhau

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

  • Kiểm thử hộp đen – Black box testing 

Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

Ưu, nhược điểm 

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

  • Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.

  • Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.

2. Vai trò – tầm quan trọng của kiểm thử

  • Chi phí phát triển phầm mềm
    • Chi phí thực thi
    • Chi phí kiểm thử
    • Chi phí sửa lỗi
  • Hiệu quả đầu tư vào Testing

Screen Shot 2018-05-06 at 11.25.51 PM

3. Nguyên tắc cơ bản trong kiểm thử

3.1 Phải truy vết từ Tests-Requirements. 

3.2 Phải chuẩn bị từ đầu dự án. 

Untitled2

3.3 Lỗi quần tụ – 20%  >> 80% lỗi

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.
=> Test kỹ chức năng quan trọng => found bug => test những gì liên quan + những chức năng gần nó để tìm ra bug nhiều hơn.

bugdensity

3.4 Phải test dần từ sớm. 

Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.

testsoon1testsoon2Screen Shot 2018-05-06 at 11.38.41 PM

3.5 Phải chú ý test các exceptions. – Kiểm thử theo các ngữ cảnh độc lập

Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau. Để hiểu rõ hơn chúng ta xem ví dụ sau:
Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:
– Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
– Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
– Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v….

Screen Shot 2018-05-06 at 11.44.30 PM

3.6 Việc sửa lỗi phải được hoạch định song song. 

Screen Shot 2018-05-06 at 11.45.25 PM

4. Xác định thời điểm kết thúc kiểm thử?

  • Không thể test hết mọi trường hợp
  • Test chỉ có thể chỉ ra rằng có lỗi chứ không thể chỉ ra rằng đã hết lỗi
  • Có thể dừng test khi
    • Rủi ro về chất lượng ở mức chấp nhận được
    • Các mục tiêu, chỉ tiêu đưa ra trong kế hoạch test đã đạt được
  • Phụ thuộc vào mức độ rủi ro của hệ thống
    • Khả năng bỏ sót những lỗi nghiêm trọng?
    • Mức độ ảnh hưởng nếu xảy ra lỗi bỏ sót?

 Nên dùng các biểu đồ, số liệu thống kê để đánh giá xu hướng lỗi của phần mềm nhằm phán đoán khả năng còn lỗi.

Screen Shot 2018-05-06 at 11.48.30 PM

——–END————