Quá trình nghiên cứu bản đặc tả phần mềm

Hãy nghĩ về 4 mô hình phát triển phần mềm được mô tả trong bài 2 “Quy trình phát triển phần mềm”: big-bang, code-and-fix, waterfall và spiral. Trong mỗi mô hình, ngoại trừ big-bang, đội phát triển phần mềm tạo ra một bản đặc tả (product specification) từ tài liệu yêu cầu của khách hàng (requirement document) để định nghĩa những cái mà phần mềm sẽ làm.

Điển hình, bản đặc tả sản phẩm là tài liệu được viết bằng word và có các bức tranh để mô tả sản phẩm dự định. Một trích dẫn từ bản đặc tả phần mềm Windows Calculator (trong hình 4.1) có thể đọc một số thứ giống như dưới đây:

Menu Edit sẽ có 2 lựa chọn: Copy và paste. Có thể chọn bằng một trong 3 cách: trỏ chuột và click vào các item của menu, sử dụng phím truy cập (alt+E và sau đó là C để Copy và P để Paste), hoặc sử dụng các phím tắt chuẩn của windows như Ctrl+C để Copy và Ctrl+V để Paste.

Chức năng Copy sẽ sao chép toàn bộ dữ liệu hiện tại được hiển thị trên ô textbox và đưa vào Windows Clipboard. Chức năng Paste sẽ dán những dữ liệu được lưu trữ trong Windows Clipboard thành dữ liệu trong ô textbox.

Phần mềm Windows Calculator chuẩn hiển thị menu drop-down Edit

Bạn có thể nhìn thấy rằng, phải mất một đoạn văn bản ngắn để mô tả về việc điều khiển 2 item menu trong một chương trình Calculator đơn giản. Một bản đặc tả chi tiết và triệt để cho toàn bộ ứng dụng có thể phải dài hàng trăm trang.

Dường như với cách viết như vậy, chúng ta đã tạo ra một văn bản quá tỉ mỉ cho một phần mềm đơn giản. Tại sao lại không để cho lập trình viên viết một phần mềm Calculator theo ý của anh ta? Vấn đề là bạn sẽ không thể có ý tưởng nào là cuối cùng. Ý tưởng của các lập trình viên sẽ hình thành nên phần mềm, chức năng nào nên có, và người sử dụng sẽ sử dụng nó như thế nào. Chỉ có cách đảm bảo rằng sản phẩm cuối cùng là cái mà khách hàng yêu cầu với kế hoạch hợp lý về những lỗ lực kiểm thử để mô tả thấu đáo sản phẩm trong một bản đặc tả.

Những thuận lợi khác có trong một bản đặc tả, và là nội dung cơ bản của bài này, một tester sẽ có một văn bản về các item để thực hiện kiểm tra. Bạn có thể tìm các lỗi trong chính văn bản đó trước khi dòng mã đầu tiên được viết.

a) Kiểm thử black-box và white-box

Hai thuật ngữ mà các tester sử dụng để mô tả cách mà họ tiếp cận để kiểm thử phần mềm là kiểm thử black-box và kiểm thử white-box. Hình 4.2 biểu diễn sự khác nhau giữa 2 hướng tiếp cận này. Trong kiểm thử black-box, tester chỉ biết cái mà phần mềm giả định là thực hiện được và anh ta cũng không hề biết cách thức phần mềm hoạt động như thế nào. Nếu anh ta đưa vào một dữ liệu chính xác, anh ta cần nhận được dữ liệu chính xác. Anh ta không hề biết làm cách nào và tại sao điều đó lại xảy ra.

Với kiểm thử black-box, tester không biết chi tiết về cách thức mà phần mềm làm việc

Lời khuyên: Đôi khi, kiểm thử black-box được quy về kiểm thử chức năng (function testing) hoặc kiểm thử về cách hoạt động (behavioral testing). Đừng có cố chạy theo những thuật ngữ được dùng trong thực tế. Đội của bạn có thể sử dụng những thuật ngữ khác đi. Công việc của bạn là phải hiểu những thuật ngữ này và cách mà chúng được sử dụng trong đội của bạn.

Hãy suy nghĩ về phần mềm Calculator được mô tả trong hình 4.1. Nếu bạn đưa dữ liệu vào là 3.14159 và nhần nút Sqrt, bạn sẽ nhận được 1.772453102341. Với kiểm thử black-box, không có vấn đề gì khi phần mềm thực hiện tính toán . Nó vừa thực hiện điều này. Là một tester, bạn có thể xác minh kết quả trên một Calculator đã được chứng thực khác và xác nhận rằng Windows calculator thực hiện chức năng này đúng.

Trong kiểm thử white-box (đôi khi còn được gọi là kiểm thử clear-box), tester có khả năng truy cập vào mã nguồn và có thể kiểm tra nó với các manh mối để giúp ích quá trình kiểm thử. Dựa trên những gì mà tester nhìn thấy, anh ta có thể xác định rằng những con số chính xác nào có thể gây lỗi và từ đó anh ta có thể thiết kế bài kiểm tra của mình dựa trên những thông tin này.

Chú ý: Kiểm thử white-box có nhiều rủi ro. Rất dễ dàng để phát sinh lỗi khi kiểm thử phần mềm 1 cách khách quan bởi vì bạn có thể thiết kế bài kiểm tra kết nối với điều khiển của mã.

b) Kiểm thử static và dynamic

Có 2 thuật ngữ khác cũng được sử dụng để mô tả cách phần mềm được kiểm tra là kiểm thử static và kiểm thử dynamic. Kiểm thử static quy về việc kiểm tra một số thứ mà nó không phải đang được chạy, đang kiểm tra và đang duyệt lại nó. Kiểm thử dynamic là cái mà thông thường bạn nghĩ về cách để kiểm tra, cách chạy và sử dụng phần mềm.

Sự giống nhau nhiều nhất của các thuật ngữ này là quy trình bạn đi xuyên qua khi kiểm tra một chiếc xe car đã được sử dụng. Đá vào vỏ xe, kiểm tra lớp sơn và nhìn xuống dưới mui xe là các kỹ thuật kiểm tra static. Nào hãy bắt đầu, lắng nghe tiếng động cơ, và đánh xe trên đường là các kỹ thuật kiểm thử dynamic.

c) Kiểm thử static black-box: Kiểm tra bản đặc tả

Kiểm tra bản đặc tả là kiểm thử static black-box. Bản đặc tả là một tài liệu, không phải là một chương trình đang chạy, vì vậy mà nó được xem xét tĩnh (static). Nó cũng có thể là một số thứ được tạo ra sử dụng dữ liệu từ nhiều đề tài nghiên cứu tiện dụng, các nhóm trọng tâm, đầu vào mang tính thị trường… Bạn không cần phải biết làm cách nào và tại sao các thông tin này lại được sử dụng hoặc các chi tiết của quá trình xử lý đã sử dụng nó. Chúng được tóm tắt lại trong một bản đặc tả sản phẩm. Sau đó, bạn có thể nắm bắt được tài liệu này, thực thi việc kiểm thử static black-box, và nghiên cứu cẩn thận về các lỗi.

Ở ngay phần đầu, bạn đã quan sát một ví dụ về bản đặc tả sản phẩm cho phần mềm Windows Calculator. Ví dụ này đã sử dụng một tài liệu được viết rất chuẩn với một bức tranh mô tả về cách thức hoạt động của phần mềm. Mặc dù đây là cách thức rất phổ biến cho việc viết một bản đặc tả, có nhiều sự thay đổi. Đội phát triển dự án của bạn có thể làm nổi bật biểu đồ dựa trên các từ hoặc nó có thể sử dụng một ngôn ngữ máy self-document ví dụ như Ada. Với bất kể lựa chọn nào của họ, bạn vẫn có thể áp dụng tất cả các kỹ thuật biểu diễn trong bài này. Bạn sẽ phải thiết kế chúng dựa trên định dạng của bản đặc tả mà bạn có, nhưng ý tưởng vẫn giống như vậy.

Bạn phải làm gì nếu dự án của bạn không có một bản đặc tả? Có thể đội của bạn đang sử dụng mô hình big-bang hoặc một mô hình code-and-fix không chặt chẽ lắm. Là một tester, đây là một vị trí khác. Mục đích của bạn là tìm ra các lỗi sớm nhất có thể, trước khi phần mềm được viết code. Nhưng nếu như sản phẩm của bạn không có một bản đặc tả, dường như điều này là không thể được. Mặc dù, bản đặc tả có thể không được viết ra, một ai đó, hoặc một vài người, biết cái thứ mà họ đang cố gắng để xây dựng. Có thể đó là người phát triển phần mềm, là một quản trị dự án, hoặc là một thương gia. Sử dụng chúng như khi đi dạo, nói chuyện, đặc tả sản phẩm và áp dụng các kỹ thuật giống như đánh giá đánh giá bản đặc tả tinh thần này (mental specification), mặc dù nó được viết trên giấy. Thậm chí, bạn có thể từng bước ghi lại các thông tin và tụ họp lại để tính toán lại nó.

Hãy nói với đội dự án của bạn, “Đây là cái mà tôi lập kế hoạch để kiểm tra và đệ trình lại các lỗi”. Bạn sẽ hết sức ngạc nhiên rằng có bao nhiêu chi tiết, họ sẽ ngay lập tức điền đầy nó.

Lời khuyên: Bạn có thể kiểm tra một bản đặc tả với các kỹ thuật static black-box mà không có vấn đề gì về định dạng của bản đặc tả. Nó có thể là văn bản viết hoặc tài liệu mô tả hoặc cả hai. Thậm chí, bạn có thể kiểm tra một bản đặc tả không được viết, mà chỉ gồm các câu hỏi của những người đang thiết kế và viết phần mềm