Khảo sát mã nguồn

Bài này giới thiệu các hạng mục cơ sở để tiến hành kiểm chứng thiết kế và mã nguồn của phần mềm. Nội dung chính của phần này bao gồm việc phân tích lợi ích của công việc, các kiểu khảo sát mã nguồn, một số hướng dẫn về chuẩn lập trình, và cách chung để khảo sát mã nguồn nhằm tìm lỗi.

1. Khảo sát thiết kế và mã nguồn hay là việc kiểm thử hộp trắng tĩnh

Kiểm thử tĩnh tức là việc kiểm thử chỉ gồm việc khảo sát mà không cần tiến hành chương trình, còn kiểm thử hộp trắng là việc kiểm thử có trong tay mã nguồn của chương trình. Vì thế kiểm thử hộp trắng tĩnh chính là việc khảo sát thiết kế và mã nguồn của chương trình. Công việc này bao gồm một quy trình để khảo sát một cách cẩn thận và có phương pháp đối với thiết kế, kiến trúc và mã nguồn của phần mềm để tìm lỗi mà không cần thực thi phần mềm. Công việc này còn có tên khác nữa là phân tích cấu trúc. Lý do hiển nhiên để tiến hành việc kiểm thử hộp trắng tĩnh là nhằm phát hiện lỗi sớm, và có thể phát hiện những lỗi mà khó có thể được phát hiện và định vị bằng các kỹ thuật kiểm thử hộp đen động. Vì thế việc tập trung nhân lực vào việc khảo sát thiết kế của phần mềm ở giai đoạn sớm của quá trình phát triển sẽ cho hiệu quả cao về chi phí. Một lợi ích thiết thực nữa của việc tiến hành kiểm thử hộp trắng tĩnh là nó cung cấp cho cho người kiểm thử hộp đen động những thông tin quan trọng để xác định những đặc trưng dễ bị mắc lỗi để tìm các ca kiểm thử thích hợp và hiệu quả. Tuy nhiên, việc kiểm thử hộp trắng tĩnh không phải lúc nào cũng được tiến hành. Nhiều người không nhận thức đầy đủ tầm quan trọng của nó và còn hiểu lầm rằng công việc này tiêu tốn thời gian, tốn kém và không năng suất. Tính hiệu quả của việc lập trình theo cặp (lập trình viên) của phương pháp phát triển phần mềm Agile đã chứng tỏ hiệu quả của kiểm thử hộp trắng tĩnh. Ngày nay ngày càng nhiều công ty phát triển phần mềm áp dụng kỹ thuật này, và vì thế, cơ hội cho những người làm kiểm thử hộp trắng tĩnh ngày càng nhiều. Sau đây là các loại kiểm thử hộp trắng tĩnh phổ biến.

2. Phản biện hình thức

Phản biện hình thức là quy trình để tiến hành kiểm thử hộp trắng tĩnh. Quy trình này có thể được áp dụng ở nhiều mức độ khác nhau, từ một cuộc họp đơn giản giữa hai lập trình viên cho đến cuộc thanh tra chi tiết và nghiêm túc đối với thiết kế và mã nguồn. Có bốn hạng mục cơ bản cho một lần phản biện hình thức:

• Xác định vấn đề. Mục đích của phản biện là tìm xem phần mềm có vấn đề gì không, không chỉ là những thứ bị sai, mà cả những thứ còn thiếu. Tất cả những phê phán này là nhằm vào thiết kế hoặc mã nguồn đang được khảo sát chứ không nhằm vào người tạo ra chúng. Người tham gia không được phép nhằm vào cá nhân nào.
• Tuân thủ các quy tắc. Cần xác định một tập các quy tắc để tuân thủ. Những quy tắc này có thể là: lượng mã nguồn để phản biện (thường là vài trăm dòng lệnh), thời gian dành cho việc phản biện (vài giờ), những gì cần được nhận xét, vân vân. Điều này là quan trọng vì người tham gia sẽ biết vai trò của họ là gì, và họ kỳ vọng cái gì, nhằm làm cho việc phản biện trơn tru hơn.
• Chuẩn bị. Mỗi người tham gia đều phải chuẩn bị và đóng góp vào việc phản biện. Tùy thuộc vào kiểu phản biện mà mỗi người tham gia có thể có các vai trò khác nhau. Họ cần biết nhiệm vụ và trách nhiệm của mình và sẵn sàng hoàn thành tốt chúng trong việc phản biện. Hầu hết các vấn đề được phát hiện là ở giai đoạn chuẩn bị chứ không phải ở giai đoạn phản biện thực sự.
• Viết báo cáo. Nhóm phản biện cần đưa ra một báo cáo bằng văn bản tóm tắt kết quả của việc phản biện và thông báo cho những người tham gia phần còn lại của dự án phát triển sản phẩm này. Những người này cần biết kết quả của buổi họp: bao nhiêu vấn đề được phát hiện, chúng được phát hiện ở chỗ nào, vân vân. Việc phản biện hình thức chỉ có hiệu quả khi tuân thủ một quy trình được xác định trước. Việc này, khi được tiến hành thực sự nghiêm túc sẽ là cách rất tốt để phát hiện lỗi. Ngoài việc tìm ra các vấn đề đối với thiết kế và mã nguồn, việc phản biện hình thức còn có vài kết quả gián tiếp nữa là:
• Truyền tải thông tin. Những thông tin không gồm trong báo cáo hình thức cũng được truyền tải. Ví dụ, người kiểm thử hộp đen động có thể biết được vấn đề đang nằm ở chỗ nào. Người lập trình ít kinh nghiệm có thể học hỏi thêm được từ những người có kinh nghiệm. Người quản lí có thể biết rõ hơn về tiến độ của dự án so với kế hoạch.
• Chất lượng. Khi mà mã của một người lập trình sẽ bị kiểm duyệt một cách chi tiết từng dòng một, người lập trình sẽ cẩn thận hơn trong việc viết chương trình.
• Tính đồng đội. Khi việc phản biện được tiến hành một các thực sự, nó sẽ là chỗ để người lập trình và người kiểm thử gặp gỡ và phát triển lòng kính trọng lẫn nhau về kỹ năng công việc và hiểu biết về công việc của nhau cũng như tầm quan trọng của họ.
• Lời giải. Lời giải cho các vấn đề được phát hiện có thể được tìm thấy thông qua việc thảo luận ngoài cuộc họp.

3. Phản biện chéo

Phản biện chéo là cách phản biện dễ nhất và ít hình thức nhất. Điều này cũng giống như loại thảo luận “tôi cho bạn biết phần của tôi và bạn cho tôi biết phần của bạn”. Phản biện chéo thường được tổ chức giữa lập trình viên thiết kế kiến trúc hoặc viết mã nguồn và người lập trình khác hoặc người kiểm thử trong vai trò người phản biện. Nhóm nhỏ này sẽ khảo sát mã nguồn cùng nhau để tìm lỗi hoặc các vấn đề tồn tại. Để đảm bảo việc khảo sát là hiệu quả và không trở thành cuộc tán gẫu, mỗi người cần đảm bảo bốn hạng mục nêu trong phản biện hình thức. Vì phản biện chéo là ít hình thức hơn, nên bốn hạng mục này thường được giảm nhẹ. Tuy nhiên, chúng vẫn giúp việc thảo luận về mã nguồn và tìm lỗi hiệu quả hơn.

4. Thông qua

Thông qua là bước kế tiếp hình thức sau phản biện chéo. Trong buổi thông qua, người lập trình sẽ trình bày hình thức về mã nguồn của mình trước một nhóm gồm năm người gồm những người lập trình khác và người kiểm thử để họ thông qua. Những người này đã nhận được một bản sao của mã nguồn này để họ xem xét trước và chuẩn bị nhận xét, câu hỏi hoặc thắc mắc cho buổi thông qua. Người trình bày đọc mã nguồn theo từng dòng hoặc từng hàm, giải thích chúng làm gì và tại sao lại được xây dựng như vậy. Người nghe sẽ hỏi khi có điều gì thắc mắc. So với phản biện chéo, số người thông qua sẽ nhiều hơn, nên những người này phải chuẩn bị trước cho việc phản biện và tuân thủ các quy tắc. Điều quan trọng là sau phản biện, người trình bày phải viết báo cáo về các vấn đề được phát hiện và kế hoạch khắc phục.

5. Thanh tra

Thanh tra là loại hình hình thức nhất của việc khảo sát mã nguồn. Việc này có tổ chức cao và đòi hỏi người tham gia được đào tạo. Thanh tra khác với phản biện chéo và thông qua ở chỗ người trình bày mã nguồn, gọi là người trình bày hoặc độc giả, không phải là người viết ra mã nguồn. Điều này đòi hỏi người trình bày phải đọc và hiểu được tư liệu cần trình bày và sẽ cho ý kiến khách quan và cách thể hiện khác trong cuộc họp thanh tra. Những người tham gia khác được gọi là các thanh tra viên. Nhiệm vụ của mỗi thanh tra viên là phản biện mã nguồn từ các khía cạnh và góc độ khác nhau, chẳng hạn của người dùng đầu cuối, người kiểm thử, hoặc người bảo trì sản phẩm. Điều này giúp việc đưa các quan điểm khác nhau về sản phẩm ra phản biện, và thường là xác định được các lỗi khác nhau của sản phẩm. Cần có một thanh tra viên duyệt mã từ cuối đến đầu (theo kiểu hồi quy) để đảm bảo mã nguồn được duyệt đầy đủ. Cũng cần một vài thanh tra viên làm điều hành viên và thư ký để đảm bảo các quy tắc được tuân thủ và buổi họp thanh tra được tiến hành hiệu quả. Sau buổi họp thanh tra, các thanh tra viên có thể cần gặp nhau lần nữa để thảo luận về các lỗi được phát hiện và làm việc với điều hành viên để chuẩn bị báo cáo và xác định điều cần làm để khắc phục lỗi. Người lập trình sau đó sẽ thay đổi mã nguồn để đưa ra bản đã được sửa lỗi và điều hành viên sẽ kiểm tra xem việc sửa đã được làm thực sự hay chưa. Phụ thuộc và phạm vi, kích thước và tầm quan trọng của phần mềm mà các buổi thanh tra tiếp theo có nên tổ chức hay không để phát hiện các lỗi còn lại. Thanh tra đã chứng tỏ là một kỹ thuật phát hiện lỗi hiệu quả trong các sản phẩm phần mềm, đặc biệt trong các tài liệu thiết kế và mã nguồn. Kỹ thuật này đang trở thành phổ dụng vì các công ty và đội ngũ phát triển sản phẩm đã phát hiện ra những lợi ích to lớn mà nó mang lại.

6. Các chuẩn và hướng dẫn trong lập trình

Trong việc phản biện hình thức, các thanh tra viên tìm kiếm các vấn đề tồn tại và các thiếu sót trong chương trình. Chúng là các lỗi kinh điển chẳng hạn cái gì đó bị viết sai. Chúng được phát hiện bằng cách phân tích mã nguồn. Công việc này được tiến hành hiệu quả hơn bởi những người lập trình và kiểm thử giàu kinh nghiệm. Còn một vấn đề khác nữa trong lập trình là chương trình chạy đúng nhưng không được viết theo các chuẩn và hướng dẫn quy định trước. Các chuẩn khi đã được thiết lập thì cần phải được tuân thủ. Còn các hướng dẫn là những kinh nghiệm thực hành được đề nghị là cách làm tiện lợi hơn cho công việc. Chuẩn là nghiêm ngặt, còn hướng dẫn có thể ít nghiêm ngặt hơn. Có thể có các mẩu phần mềm chạy ổn định nhưng vẫn không đúng do không thỏa mãn chuẩn. Có ba lý do nên tuân theo chuẩn và hướng dẫn:

• Độ tin cậy. Thực tế đã chứng tỏ rằng chương trình viết theo chuẩn và hướng dẫn có độ tin cậy và bảo mật cao hơn.
• Tính dễ hiểu và dễ bảo trì. Các chương trình viết theo chuẩn và hướng dẫn dễ đọc, dễ hiểu và dễ bảo trì hơn.
• Tính dễ chuyển đổi. Các chương trình viết theo chuẩn và hướng dẫn dễ được chuyển đổi để dịch bởi các chương trình dịch khác nhau cho các thiết bị tính toán với các hệ điều hành khác nhau. Các dự án khác nhau có thể đòi hỏi các chuẩn khác nhau (nội bộ, quốc gia hoặc quốc tế). Điều quan trọng là đội ngũ dự án phải có chuẩn, có hướng dẫn cho lập trình và phải được kiểm chứng xem chúng có được tuân thủ không trong khi phản biện.

7. Danh sách các hạng mục chung cho việc khảo sát mã nguồn

Mục này nêu những vài vấn đề cần tập trung tìm tòi khi khảo sát mã nguồn ngoài việc đối chiếu với các chuẩn và hướng dẫn. Lỗi tham chiếu dữ liệu: Đó là các lỗi gây ra do việc dùng các biến, hằng, xâu hoặc bản ghi mà chưa được mô tả hoặc khởi tạo.

• Liệu có trong chương trình việc tham chiếu đến biến chưa khởi tạo giá trị?
• Giá trị của chỉ số mảng hoặc xâu có là nguyên và có nằm trong cận và số chiều cho phép?
• Các phép tính trên chỉ số mảng có vượt ra ngoài cận cho phép?
• Lựa chọn giữa biến và hằng có hợp lý?
• Có vi phạm về kiểu trong khi gán giá trị cho biến?
• Giá trị tham chiếu của con trỏ có nằm trong vùng nhớ được phân phối?
• Tương ứng giữa tham số hình thức và thực sự trong các lời gọi hàm và chương trình con. Lỗi mô tả dữ liệu: Các lỗi này gây bởi việc mô tả không đầy đủ hoặc do việc dùng bất cẩn các biến và hằng số.
• Liệu các biến có được gán độ dài, kiểu, lớp đúng đắn? Chẳng hạn dùng kiểu xâu thay cho kiểu mảng.
• Liệu các biến có được khởi tạo và khởi tạo hợp kiểu khi mô tả?
• Các biến với tên tương tự nên tránh vì dễ dùng nhầm.
• Có biến không được tham chiếu hoặc tham chiếu chỉ một lần?
• Phạm vi của mô tả biến có bị vi phạm? Lỗi tính toán: Đó là các lỗi về toán, gây ra kết quả tính toán không như mong đợi.
• Có hay không việc tính toán số học với các kiểu khác nhau?
• Tính toán với các biến cùng kiểu nhưng khác độ dài.
• Các quy tắc biến đổi kiểu của chương trình dịch có được hiểu và dùng đúng?
• Giá trị của biểu thức vế phải của phép gán vượt ra ngoài miền giá trị của biến vế trái.
• Lỗi tràn ô nhớ trong khi ước luợng giá trị của biểu thức, lỗi chia cho không.
• Lỗi về sai số làm tròn.
• Có nhầm lẫn về thứ tự ước lượng các phép toán trong biểu thức. Lỗi so sánh: Các lỗi về so sánh và quyết định chính là các vấn đề hay gặp về điều kiện biên. Chúng là:
• Quan hệ trong so sánh có đúng đắn, chẳng hạn ≤ thay cho <.
• Ảnh hưởng của sai số làm tròn trong so sánh.
• Các biểu thức Boolean có được viết đúng không? Các toán hạng có được dùng đúng kiểu và nghĩa (kiểu boolean và kiểu nguyên)? Lỗi điều khiển: Đó là các lỗi gây ra, trực tiếp hay gián tiếp, do dùng không đúng các cấu trúc điều khiển như lệnh chu trình và rẽ nhánh.
• Các từ khóa mở và đóng nhóm các lệnh có sánh được với nhau?
• Đơn thể, chu trình có kết thúc như mong muốn?
• Có chu trình đan xen?
• Có nhánh chương trình không bao giờ được tiến hành? Nếu có thì liệu có là hợp lệ?
• Liệu các nhánh của lệnh case có tương thích với điều kiện của nó.
• Liệu có chu trình với việc lặp thân chu trình không mong đợi do chỉ số vượt cận. Lỗi truyền tham số trong chương trình con: Đó là các lỗi về sự không tương thích giữa tham số thực sự với tham số hình thức, lỗi về truyền theo tham chiếu hay theo giá trị, vân vân. Lỗi về đầu vào và đầu ra: Đó là các lỗi về đọc tệp đầu vào, khuôn dạng không tương thích khi vào dữ liệu từ bàn phím, lỗi đọc từ thiết bị không sẵn sàng cho trao đổi dữ liệu, vân vân. Các lỗi khác: Đó là các lỗi chưa được liệt kê trên đây, chẳng hạn lỗi về ngôn ngữ, mã ký tự (UNICODE or ASCII), lỗi hiển thị, lỗi về chuyển đổi giữa các hệ điều hành, lỗi về tương thích với phần cứng khác nhau, vân vân. Tóm lại, việc khảo sát để phát hiện lỗi ngày càng chứng tỏ là một kỹ thuật kiểm thử hiệu quả nhưng nó đòi hỏi người kiểm thử phải được chuẩn bị và đào tạo, và làm việc với năng suất cao, và phải tuân thủ các quy tắc khi áp dụng kỹ thuật này. Tham khảo: [1]. Giáo trình kiểm thử phần mềm - Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng