Giao diện ngƣời dùng hệ thống đƣợc phân tích để liệt kê ra các hoạt động có thể tiến hành trên giao diện. Các hoạt động này có thể đƣợc thực hiện trở thành xƣơng sống cho kiểm thử và gọi các operator của kế hoạch kiểm thử. Trạng thái ban đầu của các thành phần giao diên đƣợc quyết định. Trạng thái mục tiêu của các thành phần đƣa ra các trạng thái có thể thực hiện của các thành phần đã đƣợc liệt kê. Kế hoạch kiểm thử đƣợc viết ra để cân nhắc các trạng thái khởi tạo và trạng thái mục tiêu [8].
3.4.2. Sử dụng công cụ kiểm thử giao diện tự động
Khi kiểm thử giao diện tự động, cần đảm bảo một số vấn đề sau [8]: - Xác nhận không xuất hiện các liên kết hỏng
- Chắc chắn rằng giao diện ngƣời dùng là đồng nhất trên các trình duyệt khác nhau và nhiều platforms
- Xác nhận việc tuân thủ các chuẩn kiểm thử giao diện
- Định danh và phân cấp địa chỉ hiệu quả của các thay đổi trong ứng dụng - Xác thực các tính năng
- Chắc chắn rằng bản build là phù hợp để bắt đầu pha kiểm thử - Đi tìm các khiếm khuyết và các lỗi lặp đi lặp lại để đƣa ra cảnh báo
- Đảm bảo rằng mỗi phiên bản có cùng các chức năng đi theo cùng một cách - Tập trung trên các vùng của các hoạt động hỗ trợ kiểm thử nhƣ danh mục dữ
liệu kiểm thử đặc tả chức năng
- Xác định và dò tìm những thay đổi trên giao diện ngƣời dùng khi tập trung vào một khía cạnh kiểm thử
- Các miền ứng dụng của kiểm thử giao diện tự động
- Trong danh mục kiểm thử, trong các miền trạng thái kiểm tra của đối tƣợng, menu và window chuẩn nhìn và thấy đặc trƣng
- Hoàn thành tự động hóa của kiểm thử sự điều hƣớng
- Số lƣợng lớn các điều kiện đơn giản đƣợc dựa trên kiểm thử với cùng chức năng logic, ví dụ nhƣ bảng quyết định dựa trên kiểm thử (Decision table based Testing)
- Kiểm thử trên nhiều platform, các hệ điều hành khác nhau và so sánh
3.4.3. Mười điều cần nhớ khi kiểm thử giao diện tự động
- Công cụ tự động hóa phải dễ sử dụng
- Công cụ tự động hóa đƣợc sử dụng phải hỗ trợ tính tái sử dụng
- Các script tái sử dụng phải có khả năng chuyển đổi thành các test case tự động - KTTĐ phải khởi tạo dễ dàng trong chu trình phát triển ứng dụng
- Bắt đầu tạo các script kiểm thử cho các chức năng đơn giản
- Duy trì các tài liệu hƣớng dẫn của các script có thể tái sử dụng và các chức năng của chúng
- Công cụ tự động hóa phải hỗ trợ lƣu trữ và phục hồi dữ liệu thời gian chạy - Sử dụng các tên chuẩn cho các script, kiểm chứng các điểm, lƣu trữ dữ liệu để
đảm bảo tính nhất quán và dễ dàng khôi phục trong công cụ tự động
- Bugs và errors phải đƣợc truyền đạt đúng cách và đƣợc đóng để tránh dƣ thừa về sau
- Nhớ rằng thành công trong kiểm thử khi sử dụng công cụ KTTĐ đó là nhận biết các yêu cầu và phát triển các yêu cầu đã đƣợc xác định với các mục tiêu hợp lý trong kiểm thử.
3.4.4. Các thủ thuật khi kiểm thử giao diện tự động
Tự động hóa kiểm thử là một quá trình kiểm thử ứng dụng có sử dụng các công cụ thích hợp và dựa theo các phƣơng pháp kiểm thử đa dạng. Các công cụ khác nhau đƣợc tạo ra bởi các nhà sản xuất khác nhau tập trung vào các dạng kiểm thử khác nhau. Tuy nhiên, thực tế chỉ ra rằng, kết hợp giữa kiểm thử thủ công và KTTĐ sẽ đạt hiệu quả tốt nhất.
KTTĐ nên tập trung vào các yếu tố sau đây [11]: Cải tiến quy trình kiểm thử
Cải tiến quy trình kiểm thử đề cập tới việc liệt kê ra các yêu cầu quy tình kiểm thử. Sau khi định nghĩa các yêu cầu quy trình kiểm thử, tiến hành thiết kế quy trình kiểm thử. Sự cải tiến này là một tiến trình logic phân tích những gì cần tự động hóa, các vùng tự động hóa, cách viết các chuẩn tự động hóa, tài liệu rủi ro và các giả định. Quy trình này lặp đi lặp lại trong khí quy trình phát triển ứng dụng và quy trình kiểm thử cũng đồng thời đƣợc cải tiến.
Định nghĩa các yêu cầu
Định nghĩa yêu cầu gồm hai nhóm - các yêu cầu tự động hóa và các yêu cầu kiểm thử. Chúng đƣợc tài liệu hóa bởi các tài liệu thiết kế kiểm thử và mục tiêu tự động hóa. Có bốn tập hợp khác nhau để hiểu rõ về kiểm thử ở giai đoạn này. Nhóm nghiên cứu phát triển ý tƣởng kiểm thử, quản lý mục tiêu kiểm thử, kiểm tra các tham số của các kiểm thử liên quan và nhóm tự động hóa kiểm thử quan sát quá trình kiểm thử. Thành công của bƣớc này đó là sự hòa trộn giữa việc quan sát và các yêu cầu thành một thiết kế kiểm thử để đạt đƣợc thành công khi kiểm thử tự động. (adsbygoogle = window.adsbygoogle || []).push({});
Tính khả thi
Tính khả thi là việc lựa chọn thích hợp công cụ và phƣơng pháp kiểm thử tự động. Công cụ đƣợc lựa chọn và phƣơng pháp đƣợc lựa chọn phải kết nối tới sản phẩm và đội ngũ liên quan. Nó sẽ là một ý tƣởng khôn ngoan khi sử dụng cách chứng minh kiểm thử bằng cách lấy mẫu kiểm thử tự động thông qua sử dụng một test case phù hợp để ứng dụng và thực hiện thông qua các nhóm kiểm thử. Điều này cung cấp một ƣớc lƣợng thực tế về tính khả thi của công cụ và phƣơng pháp đã đƣợc thông qua. Công cụ kiểm thử tự động là khó khăn nhất để lựa chọn khi có quá nhiều phƣơng pháp và kiểm thử thành công vẫn khó nắm bắt. Ví dụ khi lựa chọn công cụ phải đảm bảo đồng thời cả kiểm thử hồi quy, quản lý cấu hình, khả năng tái sử dụng và kiểm thử không giao diện.
Khả năng kiểm thử giao diện
Giao diện ứng dụng cần kiểm thử chặt chẽ. Chúng đƣợc phân cấp thành kiểm thử mức dòng lệnh, kiểm thử mức ứng dụng và kiểm thử mức giao diện. Một ứng dụng phải có ít nhất một trong ba giao diện đó. Trong nhiều ứng dụng, giao diện có thể bị ẩn và đƣợc thực hiện bên trong giao diện GUI nhìn thấy rõ ràng. Thành công trong khả năng kiểm thử giao diện nằm trong sự hiểu biết rằng khả năng để kiểm thử một ứng dụng là một yêu cầu ứng dụng.
Khả năng bảo trì
Sự bảo trì trong kiểm thử đƣợc gọi là sự “nuôi dƣỡng”. Các tham số tự động phải đƣợc ứng biến, mở rộng, nâng cao nhƣ các phiên bản mới của ứng dụng để có thể thực hiện. Thiết kế kiểm thử và các test case vẫn đƣợc duy trì sau khi thực thi ứng dụng. Với một phiên bản mới đƣợc lên kế hoạch, thiết kế kiểm thử có sẵn và các test case đƣợc thực thi mà không có bất kỳ lỗi nào. Điều này không có nghĩa là bản phát hành không có lỗi nào, và thích hợp để phát hành. Có trƣờng hợp bản phát hành đƣợc tiếp cận theo phƣơng pháp này và thất bại thê thảm khi đi vào thực hiện. Điều này nhấn mạnh tầm quan trọng khả năng bảo trì của công cụ kiểm thử tự động và tính dễ
tổn thƣơng của các ứng dụng trong kiểm thử khi mà các tham số kiểm thử khoogn đƣợc cập nhật nâng cao hoặc sửa lỗi của ứng dụng.
Khả năng tái sử dụng
Có hiểu biết về các thành phần có thể tái sử dụng sẽ giúp giảm rất nhiều thời gian làm lại các thành phần. Điều này nhấn mạnh “xây dựng trên công trình của ngƣời khác”. Các thành phần tái sử dụng có thể đƣợc dùng khi kiểm thử các phiên bản mới của phần mềm. Nếu ứng dụng đƣợc giới thiệu trên một nền tảng mới, các thành phần tái sử dụng có thể áp dụng cho các kiểm thử tiêu chuẩn chung cho mọi ứng dụng và có thể hỗ trợ quy trình xây dựng với nỗ lực ít hơn và tiêu tốn ít thời gian hơn.
3.4.5. Một số vấn đề thường gặp với kiểm thử tự động
Một trong những vấn đề thƣờng gặp nhất khi kiểm thử tự động đó là về kỹ thuật con ngƣời. Nếu đội ngũ kiểm thử viên thiếu kinh nghiệm và khả năng tƣ duy lập trình, khi xây dựng các script kiểm thử rất dễ để thiếu sót các trƣờng hợp kiểm thử. Kiểm thử tự động cũng khó kiểm soát hơn, và khả năng mở rộng bảo trì khó khăn, còn phụ thuộc vào nền tảng và khả năng của công cụ kiểm thử tự động.
3.5. Đánh giá mức độ hài lòng ngƣời dùng
Giao diện phần mềm có đƣợc chấp nhận hay không hoàn toàn phụ thuộc vào sự đánh giá của ngƣời dùng cuối. Bất kể là phần mềm nào, đƣợc kiểm thử thủ công hay kiểm thử tự động, hiệu quả của việc phát triển và kiểm thử phần mềm đƣợc phản ánh rõ nhất qua mức độ hài lòng của khách hàng, khi mà sản phẩm đƣợc phân phối tới ngƣời dùng cuối.
Để xác định đƣợc sự đánh giá của khách hàng, sau khi quá trình kiểm thử hoàn tất, phần mềm đƣợc phê duyệt và đƣa ra các bản dùng thử alpha hay beta. Cần tiến hành thu thập trƣng cầu ý kiến phản ánh của ngƣời dùng theo từng nhóm đối tƣợng sử dụng. Bản thu thập ý kiến cần nêu rõ các yếu tố giao diện sản phẩm, với các mức đánh giá sự hài lòng của ngƣời dùng. Các thành phần giao diện các đƣợc liệt kê chi tiết rõ ràng thì càng hiệu quả trong việc đánh giá mức độ hài lòng về giao diện của sản phẩm. Thông qua đó, đội ngũ phát triển có thể chỉnh sửa phần mềm để đáp ứng tốt hơn nhu cầu ngƣời dùng trong các bản release tiếp theo. Nhóm kiểm thử viên cũng dựa trên kết quả đánh giá này mà bổ sung các ca kiểm thử phù hợp. Đây cũng chính là một phần việc trong quá trình kiểm thử hồi quy phần mềm.
CHƢƠNG 4 – KIỂM THỬ GIAO DIỆN THEO PHÂN LOẠI PHẦN MỀM 4.1. Phân loại phần mềm
Phân loại phần mềm theo một số tiêu chí sau: Theo mức độ hoàn thiện:
o Phần mềm đơn lẻ: Là phần mềm chỉ thực hiện một số nhiệm vụ nhất định. Ví dụ: các trình soạn thảo văn bản, phần mềm đồ họa,…
o Phần mềm mang tính hệ thống: Là phần mềm đƣợc truy cập và sử dụng bởi nhiều ngƣời dùng trong một hệ thống. Thƣờng phải đi đôi với mạng máy tính.
Theo chức năng mà phần mềm thực hiện:
o Phần mềm hệ thống
o Phần mềm công cụ
o Phần mềm ứng dụng Theo lĩnh vực đƣợc ứng dụng:
o Phần mềm nghiệp vụ: thƣờng đƣợc ứng dụng cho nghiệp vụ của từng doanh nghiệp, tổ chức xác định.
o Phần mềm nhúng: phần mềm đƣợc gắn vào chip của các thiết bị điện tử: ti vi, tủ lạnh,…
o Phần mềm máy tính cá nhân: phần mềm dùng trong lĩnh vực tính toán
o Phần mềm trên nền web: phần mềm đƣợc truy cập thông qua các trình duyệt web, ngƣời dùng có thể truy cập thông qua mạng internet
o Phần mềm trí tuệ nhân tạo: các phần mềm thông minh sử dụng trí tuệ nhân tạo, nhƣ các hệ chuyên gia (hệ cơ sở tri thức), phần mềm trong lĩnh vực nhận dạng (hình ảnh, tiếng nói), các phần mềm chứng minh định lý và trò chơi, các hệ mạng nơ ron nhân tạo mô phỏng cấu trúc của việc xử lý trong bộ óc con ngƣời.
o Phần mềm hệ thống: là một tập hợp các chƣơng trình giải quyết các bài toán.
Mỗi loại phần mềm có đặc điểm riêng, do đó cách tiếp cận và kiểm thử phần mềm cũng có những điểm khác nhau. Các mục tiếp theo trong Chƣơng 4 của luận văn đề cập tới kiểm thử giao diện phần mềm đƣợc phân loại theo lĩnh vực đƣợc ứng dụng.
4.2. Kiểm thử giao diện phần mềm nghiệp vụ (adsbygoogle = window.adsbygoogle || []).push({});
Phần mềm nghiệp vụ là các phần mềm đƣợc xây dựng dựa theo yêu cầu nghiệp vụ của từng doanh nghiệp. Phần mềm có thể là các ứng dụng trên nền tảng Window hoặc các ứng dụng web. Các phần mềm quản lý bệnh viện, trƣờng học, phần mềm kế
toán,… là các ví dụ điển hình về phần mềm nghiệp vụ. Mỗi phần mềm có các tiêu chí và đặc thù riêng, việc kiểm thử phần mềm phải thật sát với tài liệu đặc tả phần mềm.
Nhìn chung, giao diện phần mềm nghiệp vụ sẽ đƣợc kiểm thử theo các tiêu chí đã đƣợc nêu trong Chƣơng 3 của luận văn. Phần mềm nghiệp vụ có thể đƣợc phát triển trên nền tảng window hay web. Tùy từng nền tảng mà áp dụng các kỹ thuật kiểm thử đƣợc nêu trong Mục 4.4 và Mục 4.5 của chƣơng này.
Các phần mềm nghiệp vụ có thể có một số yêu cầu riêng về giao diện, khi đó sẽ có tài liệu đặc tả về các yếu tố đó. Quá trình kiểm thử cần chú trọng vào các thành phần này, bởi đó chính là nét đặc trƣng của ứng dụng.
4.3. Kiểm thử giao diện đối với phần mềm nhúng
4.3.1. Hệ thống nhúng và các đặc điểm cơ bản
Hệ thống nhúng (Embedded system) là một thuật ngữ để chỉ một hệ tính toán
nằm trong sản phẩm, tạo thành một phần của hệ thống lớn hơn và thực hiện một số chức năng của hệ thống. Đó là các hệ thống tích hợp cả phần cứng và phần mềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự động hoá điều khiển, quan trắc và truyền tin. Đặc điểm của các hệ thống nhúng là hoạt động ổn định và có tính năng tự động hoá cao.
Mỗi hệ thống nhúng phải đáp ứng đƣợc các yêu cầu dƣới đây – đây cũng là những đặc tính chung của các hệ thống nhúng:
1. Khả năng độc lập và thông minh hoá: Điều này đƣợc chỉ rõ hơn thông
qua một số các thuộc tính yêu cầu, cụ thể nhƣ: - Độ tin cậy
- Khả năng bảo trì và nâng cấp - Sự phổ cập và tiện sử dụng - Độ an toàn
- Tính bảo mật
2. Hiệu quả: Yêu cầu này đƣợc thể hiện thông qua một số các đặc điểm
của hệ thống nhƣ sau:
- Năng lƣợng tiêu thụ
- Kích thƣớc về phần cứng và phần mềm - Hiệu quả về thời gian thực hiện
- Kích thƣớc và khối lƣợng - Giá thành
3. Phân hoạch tác vụ và chức năng hoá: Các bộ vi xử lý trong các hệ
nhúng thƣờng đƣợc sử dụng để đảm nhiệm và thực hiện một hoặc một nhóm chức năng rất độc lập và cũng đặc thù cho từng phần chức năng của hệ thống lớn mà nó đƣợc nhúng vào. Ví dụ nhƣ một vi xử lý thực hiện một phần điều khiển cho một chức năng thu thập, xử lý và hiển thị của ôtô hay hệ thống điều khiển quá trính. Khả năng này làm tăng thêm sự chuyên biệt hoá về chức năng của một hệ thống lớn và dễ dàng hơn cho quá trính xây dựng, vận hành và bảo trì.
4. Khả năng thời gian thực: Các hệ thống đều gắn liền với việc đảm nhiệm
một chức năng chính và phải đƣợc thực hiện đúng theo một khung thời gian qui định. Thông thƣờng một chức năng của hệ thống phải đƣợc thực hiện và hoàn thành theo một yêu cầu thời gian định trƣớc để đảm bảo thông tin cập nhật kịp thời cho phần xử lý của các chức năng khác và có thể ảnh hƣởng trực tiếp tới sự hoạt động đúng và chính xác của toàn hệ thống. Tuỳ thuộc vào từng bài toán và yêu cầu của hệ thống mà yêu cầu về khả năng thời gian thực cũng rất khác nhau.
4.3.2. Kiểm thử giao diện hệ thống nhúng
Hệ thống nhúng cũng đƣợc lập trình nhƣ một phần mềm, do đó kiểm thử hệ thống nhúng cũng trải qua các giai đoạn kiểm thử và sử dụng các kỹ thuật kiểm thử