Ở phần trình duyệt, chúng ta cần chú ý đến tính khả kiểm thử của các trang web viết bằng ngôn ngữ HTML. Để có thể tăng tính khả kiểm thử cho trang web, ví dụ viết mã kiểm thử tự động, áp dụng lý thuyết ở Chƣơng 2, chúng ta cần:
Tăng khả năng điều khiển trang web Tăng khả năng quan sát trang web
3.2.3.1 Công cụ hỗ trợ
Khác với phần trƣớc, ở phần trình duyệt này chúng tôi muốn giới thiệu một công cụ phổ biến nhất là Selenium17. Selenium là một cài đặt của
16 http://en.wikipedia.org/wiki/SoapUI
WebDriver18. WebDriver là một công cụ để tự động hóa kiểm thử ứng dụng web. Cụ thể nó cung cấp giao diện lập trình ứng dụng giúp viết mã kiểm thử với trang web dễ dàng hơn, không phụ thuộc vào trình duyệt cụ thể nào (minh họa Hình 11), tƣơng tự nhƣ JUnit cho Java.
Hình 12 WebDriver
Hình 13 là một đoạn mã Java sử dụng selenium để tƣơng tác với trang
18 https://w3c.github.io/webdriver/webdriver-spec.html
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement;
import org.openqa.selenium.htmlunit.HtmlUnitDriver; public class Example {
public static void main(String[] args) {
// Create a new instance of the html unit driver
// Notice that the remainder of the code relies on the interface, // not the implementation.
WebDriver driver = new HtmlUnitDriver(); // And now use this to visit Google driver.get("http://www.google.com"); // Find the text input element by its name
WebElement element = driver.findElement(By.name("q")); // Enter something to search for
element.sendKeys("Cheese!");
// Now submit the form. WebDriver will find the form for us from the element element.submit();
// Check the title of the page
System.out.println("Page title is: " + driver.getTitle()); driver.quit();
}
web, thực hiện các hành động thay cho ngƣời kiểm thử phải làm bằng tay.
Khi viết những đoạn mã này chúng ta có thể thấy chúng ta cần điều khiển trang web, và quan sát kết quả, thông tin ở trên trang web đó. Do đó để tăng khả năng điểu khiển và khả năng quan sát, tức là tăng tính khả kiểm thử, ta phải chú ý đến việc giúp định vị các phần tử trong trang web một cách dễ dàng. Ở ví dụ trên chúng ta có lệnh xác định phần tử có thuộc tính name là “q”.
3.2.3.2 Tăng khả năng điều khiển trang web
Để tăng khả năng điều khiển trang web, chúng ta cần dễ dàng truy cập các thành phần trong trang web. Thông thƣờng các trang HTML này rất phức tạp vì đƣợc sinh ra từ mã nguồn, nên cấu trúc của chúng nhiều khi không thể đọc đƣợc. Ví dụ nhƣ Hình 14 là một đoãn mã HTML của trang web
http://asp.net. Có thể thấy việc đọc file này để lấy đƣợc một phần tử trong hình là việc rất không dễ dàng.
Hình 14 Một đoạn mã HTML của trang web asp.net
Trong khi đó một đoạn mã của trang https://www.ruby-lang.org/en/ lại khá dễ đọc nhƣ trong Hình 15. (adsbygoogle = window.adsbygoogle || []).push({});
Hình 15 Một đoạn mã HTML của trang web ruby-lang
Nhƣ vậy để tăng khả năng điều khiển các trang web chúng ta cần hết sức chú ý đến mã HTML sinh ra từ ứng dụng máy chủ. Các trang web thực chất là một máy trạng thái hữu hạn. Khi thiết kế các trang web, cần phân tích các máy trạng thái nền để tăng tính khả kiểm thử của trang web nhƣ giảm số trạng thái, giảm chu trình hoặc giảm tính không đơn định đối với các dãy truyền ứng.
3.2.3.3 Tăng khả năng quan sát trang web
Để tăng khả năng quan sát, dễ thấy, chúng ta cần thiết kế trang web sao cho không có các phần thông tin trùng lặp hoặc khi có trùng lặp thì cần biết số lƣợng các phần tử sẽ xuất hiện trên trang web. Từ đó việc quan sát và kiểm tra kết quả sẽ dễ dàng, chính xác.
3.3 Áp dụng đánh giá độ đo tính khả kiểm thử của một dự án cụ thể
Theo mục tiêu ban đầu đặt ra, tác giả mong muốn thông qua nghiên cứu này có thể tạo cơ sở cho việc áp dụng, nâng cao khả năng kiểm thử cũng nhƣ độ tin cậy của dự án mà tác giả đang tham gia. Dựa trên các nghiên cứu đã đạt đƣợc, tác giả đã thực hiện đánh giá toàn bộ các yếu tố ảnh hƣởng đến tính khả kiểm thử và kết quả đánh giá đã giúp cho tác giả có cái nhìn tổng thể về cách thức để nâng cao khả năng kiểm thử của một hệ thống thay vì cách nhìn phiến diện về việc chỉ cần áp dụng kiểm thử tự động trƣớc khi thực hiện nghiên cứu này.
3.3.1 Đánh giá về tính khả kiểm thử của tài liệu mô tả
Tài liệu chưa cung cấp đủ thông tin: Các dự án tại đơn vị đều phải tuân thủ quy trình phát triển tƣơng đối nghiêm ngặt, bắt buộc phải xây dựng các tài liệu mô tả trƣớc khi cài đặt, và sau khi xây dựng tài liệu có thực hiện xem xét tài liệu qua nhiều vòng. Tuy nhiên, giai đoạn viết tài liệu thƣờng không dự đoán đƣợc hết các thông tin cần thiết làm đầu vào cho giai đoạn cài đặt, kiểm thử và yêu cầu của khách hàng cũng có nhiều thay đổi, do đó, tài liệu đã hoàn chỉnh ở giai đoạn đầu thì vẫn chƣa đủ đáp ứng cho giai đoạn cài đặt, kiểm thử.
Tài liệu chưa cập nhật theo đúng bản cài đặt: Cũng vì lý do trên, bƣớc cài đặt thƣờng sẽ thực hiện theo trao đổi giữa lập trình viên và kỹ sƣ giải pháp, việc cập nhật tài liệu sẽ do kỹ sƣ giải pháp thực hiện sau. Do đó, bản cài đặt và tài liệu có thể có sự sai khác nhất định. Điều này làm cho việc truy vết, so sánh giữa tài liệu, cài đặt sau này gặp phải vấn đề về không trùng khớp, không biết nên theo tài liệu hay theo bản cài đặt.
Chưa sử dụng ngôn ngữ hình thức trong các tài liệu thiết kế: Việc sử dụng các ngôn ngữ hình thức trong thiết kế đã đƣợc nghiên cứu và đánh giá là mang lại nhiều lợi ích, giảm thiểu rủi ro cho các hệ thống có ảnh hƣởng lớn đến kinh doanh. Tuy nhiên, tại đơn vị hiện tại tác giả công tác chƣa sử dụng cách mô tả này. Lý do chính là do đã quen với cách làm cũ, theo lối mòn và chƣa có kiến thức vững chắc về ngôn ngữ này.
3.3.2 Đánh giá về tính khả kiểm thử của bản cài đặt
Bản cài đặt có tốt hay không, có khả năng kiểm thử tốt hay không cũng phụ thuộc vào khả năng, trình độ của lập trình viên. Trong khi đơn vị đang đẩy mạnh công tác tuyển dụng nhân sự trẻ, tham gia với vai trò cộng tác viên để giảm bớt chi phí trả cho nhân công. Điều này dẫn đến rủi ro về việc bản cài đặt không đảm bảo chất lƣợng do nhân sự mới ra trƣờng thƣờng chƣa thật sự chuyên, sử dụng thành thạo một ngôn ngữ lập trình cụ thể.
Đơn vị cũng đã thành lập bộ phận phụ trách về công nghệ mới cũng nhƣ đào tạo nội bộ về các công nghệ mới. Tuy nhiên, cán bộ đào tạo vừa phụ trách công việc phát triển hoặc giải pháp vừa thực hiện tìm hiểu và đào tạo nên kiến thức còn giới hạn trong kinh nghiệm làm việc, chƣa theo sát những cải tiến của đơn vị cung cấp nền tảng ngôn ngữ lập trình cũng nhƣ công cụ phát triển.
3.3.3 Đánh giá về tính khả kiểm thử của Kiểm thử kèm theo
Toàn bộ các tài liệu mô tả của dự án chƣa đề cập đến vấn đề tự kiểm thử của hệ thống cũng nhƣ các ràng buộc về thiết kế, cài đặt nhằm đảm bảo khả năng tự kiểm tra của hệ thống. Đây là vấn đề chung của toàn bộ các dự án trong đơn vị. Tuy nhiên, cho đến nay vẫn chƣa có giải pháp và thậm chí chƣa có kế hoạch để đƣa việc Kiểm thử kèm theo vào thực hiện.
Một lý do nữa dẫn đến chƣa có kế hoạch thực hiện Kiểm thử kèm theo là do sức ép về thời gian ra sản phẩm mới. Theo [15], để tiến hành Kiểm thử kèm theo cần tạo ra mã nguồn kiểm thử trƣớc khi tạo mã nguồn chƣơng trình. Trong khi đó, để đảm bảo chỉ trong ba đến sáu tháng có thể đƣa một ý tƣởng sản phẩm ra kinh doanh, việc viết thêm mã nguồn đƣợc coi là việc tốn thời gian. Thêm nữa, một sản phẩm từ khi lên ý tƣởng đến khi thành hình và đƣa ra triển khai có thể có sự luân chuyển ngƣời lớn, do đó việc làm thuận tiện cho các bƣớc ở tƣơng lai cũng không đƣợc chú trọng.
Thông qua việc tìm hiểu về việc xây dựng các mã nguồn giúp hệ thống có thể tự kiểm tra sau mỗi lần dịch lại này. Tác giả thật sự mong muốn có thể tạo
ra một tƣ duy mới và đầy đủ về cách để giảm thiểu các rủi ro trong tƣơng lai thay vì chỉ nhìn vào những lợi ích tạm thời, ngắn hạn trƣớc mắt.
3.3.4 Đánh giá về tính khả kiểm thử của Công cụ kiểm thử
Việc không đặt mục tiêu, kế hoạch ngay từ đầu về việc sử dụng các Công cụ kiểm thử dẫn đến các điều kiện chuẩn bị cho việc kiểm thử tự động gặp rất nhiều khó khăn và thậm chí không áp dụng kiểm thử tự động đƣợc. Cụ thể là khi tác giả thực hiện kiểm thử tự động hệ thống tác giả đang tham gia bằng công cụ Selenium đã gặp một số vấn đề sau:
- Thiết kế giao diện có nhiều lớp, ID không duy nhất dẫn đến khi bắt các thành phần trên giao diện không chính xác.
- Giao diện có quá nhiều thông tin, dẫn đến phải nhập nhiều số liệu trên một trang cũng làm cho việc bắt các thành phần khó hơn.
3.3.5 Đánh giá về tính khả kiểm thử của Bộ kiểm thử
Bộ kiểm thử tốt hay không, khoa học hay không, rõ ràng hay không là dựa trên khả năng, kinh nghiệm phân tách, viết của kỹ sƣ kiểm thử. Trong khi nhân sự kiểm thử đa số là sinh viên mới ra trƣờng, kinh nghiệm còn ít ỏi, việc học tập ở trƣờng cũng chƣa chuyên biệt về môn kiểm thử. Do đó, các tài liệu kiểm thử còn chƣa đồng đều về chất lƣợng, tính khả kiểm thử cơ bản chƣa cao.
Ngoài ra, tài liệu và các yêu cầu ngƣời dùng có sự thay đổi liên tục, do đó Bộ kiểm thử thƣờng phải cập nhật theo. Trong khi đó, liên kết giữa tài liệu mô tả yêu cầu và Bộ kiểm thử mới chỉ dừng lại ở liên kết các tiêu đề chức năng lớn, chƣa có công cụ hỗ trợ để liên kết từng ý, từng yêu cầu nhỏ. Do đó, việc đối chiếu giữa các thay đổi của Bộ kiểm thử và tài liệu mô tả yêu cầu là rất khó truy lại.
3.3.6 Đánh giá về tính khả kiểm thử của Quy trình kiểm thử
Đây là tiêu chí đƣợc đánh giá tƣơng đối tốt tại đơn vị do kiểm thử viên đƣợc tham gia vào dự án từ rất sớm và các chiến lƣợc kiểm thử cũng đƣợc xác
định khá rõ ràng trong giai đoạn đầu của dự án. Mặc dù vậy vẫn mang nặng tính hình thức.
Sau khi đánh giá lại các yếu tố chính về tính khả kiểm thử của dự án, ta có thể thấy, để tăng tính khả kiểm thử của bất cứ một dự án nào thì yếu tố đầu tiên và quan trọng nhất chính là các tài liệu mô tả, tài liệu thiết kế. Các yêu cầu về kiến trúc, tính tách biệt các phân hệ, chức năng, và sự rõ ràng của các tài liệu này sẽ định hƣớng, tác động đến toàn bộ các yếu tố còn lại và giúp tăng độ đo về tính khả kiểm thử cho các yếu tố còn lại. Ngoài ra, để tăng tính khả kiểm thử của một hệ thống, cần có mục tiêu, kế hoạch thực hiện ngay từ giai đoạn thu thập yêu cầu từ khách hàng. Việc chỉ nhắm đến mục tiêu giảm chi phí kiểm thử thông qua việc áp dụng kiểm thử tự động là việc khó thực hiện do hệ thống không đảm bảo các yếu tố chuẩn bị cho việc áp dụng kiểm thử tự động này.
KẾT LUẬN (adsbygoogle = window.adsbygoogle || []).push({});
Qua kinh nghiệm làm việc tôi nhận thấy công việc kiểm thử ở đơn vị đang thực hiện chủ yếu là thủ công, rất tốn kém, và còn nhiều điểm chƣa hiệu quả. Đó là lý do chính tôi tìm hiểu đề tài về tính khả kiểm thử này. Qua nghiên cứu, khảo sát, tôi thấy đây là một vấn đề còn khá mới mẻ, đặc biệt ở Việt Nam. Trên thế giới cũng có khá ít tài liệu nghiên cứu về tính khả kiểm thử cho lớp ứng dụng trên nền web.
Từ lý do trên, luận văn đã cố gắng tổng hợp, trình bày khái niệm và kiến thức liên quan về tính khả kiểm thử của một hệ thống phần mềm và tập trung vào nghiên cứu một số kỹ thuật quan trọng, hiệu quả giúp làm tăng tính khả kiểm thử của hệ thống phần mềm. Tiếp đó tôi vận dụng các kiến thức tìm hiểu này để đề xuất áp dụng cho các ứng dụng web, hiện đang rất phổ biến ngày nay.
Đóng góp chính của luận văn là ở Chƣơng 3. Ở chƣơng này, dựa trên phân tích các đặc thù của các ứng dụng trên nền web, luận văn đã chia các kỹ thuật làm tăng tính khả kiểm thử vào hai thành phần quan trọng của một ứng dụng web là phần máy chủ và phần chạy trên trình duyệt ngƣời sử dụng. Tiếp đó dựa trên đặc tính của phần máy chủ và phần chạy trên trình duyệt luận văn đã đề xuất các vấn đề cần chú ý đối với các ứng dụng trên nền web.
Qua nghiên cứu này tôi đang triển khai áp dụng vào một dự án tôi đang làm việc và bƣớc đầu các kiến thức này đƣợc đội phát triển rất ủng hộ. Tuy nhiên cần thêm thời gian để có thể đánh giá mức độ hiệu quả của những đề xuất này. Trong thời gian tới tôi hy vọng dựa trên phản hồi của việc áp dụng những đề xuất đã nêu ở đây để hoàn thiện, cải tiến tiếp không những giúp ích cho công việc của đơn vị tôi mà còn phổ biến ra cộng đồng phát triển phần mềm trên nền web.
TÀI LIỆU THAM KHẢO
Tiếng Anh
[1] E. Mulo, Design for Testability in Software Systems, 2007: Master thesis.
[2] R. V. Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools (ARP/AOD) 2 Vol., 1999.
[3] S. Jungmayr, Improving testability of object-oriented systems, 2003: Dissertation.
[4] R. V. Binder, "Design for testability in object-oriented systems,"
Communications of the ACM, vol. Volume 37 , no. Issue 9, Sept. 1994 .
[5] IEEE, 610-1990 - IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, 1009.
[6] ISO, ISO/IEC TR 9126-2 Software engineering -- Product quality -- Part 2: External metrics, 2003.
[7] Y. L. Trao and C. Robach, "Testability measurements for data flow designs.," METRICS'97. IEEE Computer Society, 1997.
[8] M. Wynne and A. Hellesoy, The Cucumber Book: Behaviour-Driven Development for Testers and Developers, Pragmatic Bookshelf, 2012.
[9] L. Bass, P. Clements and R. Kazman, Software architecture in practice (3rd edition), Pearson, 2013.
[10] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design patterns: elements of reusable object-oriented software, Addison-Wesley Professional, 1995.
[11] B. Baudry, Y. L. Traon and G. Sunye, Testability analysis of a UML class diagram., In Proceedings of the 8th International Symposium on Software
Metrics (METRICS ‟02), pages 54–63. IEEE Computer Society., 2002.
[12] T. Jeon, S. Lee and H. Seung, "Increasing the Testability of Object-Oriented Frameworks with Built-in Tests," in Lecture Notes in Computer Science Volume 2402, 2002, pp 169-182, 2002.
[13] C. Mao, Y. Lu and J. Zhang, "Regression Testing for Component-based Software via Built-in Test Design," in SAC '07 Proceedings of the 2007 ACM symposium on Applied computing. 1416-1421 , 2007 .
[14] A. C. W. Finkelstein, A. Savigni, E. Kimmerstorfer and B. Pröll, "Ubiquitous Web Application Development - A Framework for Understanding," in Proc. of SCI2002, 2002.
[15]Jon Galloway, Phil Haack, Scott Hanselman, Scott Guthrie, Rob Conery, "Professional ASP.NET MVC 2", 2010.