Luận văn Xây dựng ứng dụng Từ điển trên Pocket PC

Luận văn Xây dựng ứng dụng Từ điển trên Pocket PC KH OA C NT T – Đ H KH TN 1 Lời cám ơn Lời đầu tiên, chúng con xin gửi đến cha mẹ lịng biết ơn, sự tơn kính của chúng con. Cha mẹ đã sinh dưỡng và khơng ngại khĩ khăn tạo mọi điều kiện tốt nhất cho chúng con cĩ được ngày hơm nay. Chúng em xin chân thành cám ơn thầy Trần Đan Thư, thầy Nguyễn Trọng Tài đã tận tâm hướng dẫn chúng em, giúp đỡ chúng em hồn thành đề tài này. Chúng em cũng xin cám ơn các anh chị làm việc trong phịng phát triển phần mềm Trung tâm Tin học trường Đại học Khoa học Tự nhiên đã sẵn sàng giúp đỡ chúng em, cung cấp các thơng tin cho chúng em trong quá trình khảo sát. Chúng em cũng xin cám ơn các thầy cơ, cán bộ giảng viên trẻ đã nhiệt tình đĩng gĩp những kinh nghiệm, ý kiến quý báu cho chúng em. Chúng em xin gửi lời cám ơn tất cả các quý thầy cơ đã giảng dạy, cung cấp cho chúng em vốn kiến thức quý báu suốt những năm học vừa qua. Chúng em cám ơn khoa Cơng nghệ thơng tin trường Đại học Khoa học Tự nhiên đã tạo điều kiện cho chúng em thực hiện đề tài này. Chúng tơi cũng xin cám ơn các bạn đã nhiệt tình giúp đỡ khi chúng tơi vướng phải những khĩ khăn, động viên chúng tơi trong suốt quá trình thực hiện đề tài luận văn tốt nghiệp này. Mặc dù chúng em đã cố gắng rất nhiều để hồn thành tốt luận văn, nhưng chắc chắn khơng tránh khỏi những thiếu sĩt, chúng em rất mong được sự cảm thơng và tận tình giúp đỡ của quý thầy cơ. Tp. Hồ Chí Minh, 07/2004 Nhĩm sinh viên thực hiện Nguyễn Khánh Chi- Tăng Nguyễn Trung Hiếu KH OA C NT T – Đ H KH TN 2 Lời mở đầu Sau cuộc khủng hoảng trong ngành cơng nghệ thơng tin vào đầu những năm 2000, đến nay, cơng nghệ sản xuất phần mềm trên thế giới và nhất là Việt Nam đang tiến những bước tiến mạnh mẽ hơn. Vượt qua cuộc khủng hoảng này, ngồi những kinh nghiệm trong kinh doanh, các cơng ty tin học Việt Nam nhận thức được rằng quy trình sản xuất phần mềm của chính cơng ty họ cần được nâng cấp với mục tiêu đầu tiên là nâng cao chất lượng, gia tăng tính chuyên nghiệp trong sản xuất phần mềm. Một điều khơng thể tranh cãi , quy trình đĩng một vai trị rất quan trọng trong việc sản xuất phần mềm. Hiện nay cĩ rất nhiều quy trình sản xuất phần mềm như Quy trình RUP, Quy trình xoắc ốc, Quy trình thác nước.., nhưng điều cốt lõi nhất là ứng dụng những quy trình đĩ như thế nào và ứng dụng như vậy sẽ đạt được những thuận lợi gì, quá trình sản xuất phần mềm cĩ tốt hơn khơng, chất lượng phần mềm cĩ được nâng cao hay khơng. Trong một quy trình sản xuất phần mềm, ngồi việc thành lập các chuẩn coding, phân cơng sắp xếp các cơng việc cho các thành viên trong tổ chức, một yếu tố rất quan trọng là việc quản lý các tài liệu bao gồm các bản đặc tả yêu cầu, bản phân tích thiết kế chương trình, chương trình nguồn, các bản báo cáo kiểm thử và vơ số những tài liệu khơng tên khác. Trong bối cảnh đĩ, chúng em đã thực hiện đề tài “Tìm hiểu về quản lý yêu cầu và kiểm thử tại Phịng phát triển phần mềm Trung Tâm Tin Học trường ĐHKHTN_Xây dựng phần mềm hỗ trợ” nhằm cĩ thể hiểu rõ hơn việc quản lý yêu cầu và kiểm thử, những mục tiêu, thuận lợi mà hai tiến trình này đem lại. Đề tài này cĩ thể được xem như một phần trong việc quản lý cấu hình, trong đĩ chú trọng ở hai giai đoạn khảo sát và kiểm thử. Luận văn của chúng em được trình bày với tám chương chính, bao gồm : KH OA C NT T – Đ H KH TN 3 - Chương 1 Mở đầu - Chương 2 Tổng quan về SQA (Software Quality Assurance) và các cơng việc quản lý yêu cầu, quản lý kiểm thử - Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay. - Chương 4 Giới thiệu về ứng dụng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management) - Chương 5 Thực hiện _ Kiểm tra ứng dụng - Chương 6 Tổng kết KH OA C NT T – Đ H KH TN 4 Mục lục Chương 1 Mở đầu................................................................................................................ 9 1.1 Khái quát vai trị quy trình phát triển phần mềm........................................................... 9 1.2 Tầm quan trọng của việc quản lý quy trình .................................................................. 10 1.3 Hiện trạng phát triển phần mềm tại T3H...................................................................... 10 1.4 Đánh giá hiện trạng ........................................................................................................ 19 1.4.1 Quản lý yêu cầu : ............................................................................................................................19 1.4.2 Quản lý kiểm thử :...........................................................................................................................19 1.5 Mục tiêu đề tài ................................................................................................................ 20 Chương 2 Tổng quan về SQA và các cơng việc quản lý yêu cầu, quản lý kiểm thử ...... 21 2.1 Vai trị của việc quản lý chất lượng phần mềm ............................................................. 21 2.2 Tại sao cần quản lý chất lượng ?.................................................................................... 24 2.3 Tổng quan về quản lý yêu cầu........................................................................................ 25 2.3.1 Quản lý yêu cầu là gì ?....................................................................................................................25 2.3.2 Các thơng tin cần quản lý trong quản lý yêu cầu. ..........................................................................25 2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI...............................................27 2.4 Tổng quan về quản lý kiểm thử...................................................................................... 28 2.4.1 Mục tiêu của quản lý kiểm thử. .......................................................................................................28 2.4.2 Các thơng tin cần quản lý trong quản lý kiểm thử...........................................................................29 2.4.3 Giới thiệu tiến trình Verification (VER) trong CMMI....................................................................30 Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay 32 3.1 Cơng cụ hỗ trợ quản lý yêu cầu...................................................................................... 32 3.1.1 Giới thiệu : ......................................................................................................................................32 3.1.2 Định nghĩa cơng cụ quản lý yêu cầu ...............................................................................................33 3.1.3 Các loại cơng cụ ..............................................................................................................................33 3.1.4 Tại sao phải sử dụng các cơng cụ quản lý yêu cầu :........................................................................34 3.1.5 Kiến trúc chức năng : ......................................................................................................................35 3.1.6 So sánh với các phần mềm cĩ chức năng tương tự : .......................................................................37 3.1.7 Đánh giá các cơng cụ quản lý yêu cầu ............................................................................................38 3.2 Cơng cụ kiểm thử : ......................................................................................................... 38 3.2.1 Các loại cơng cụ kiểm thử :.............................................................................................................38 3.2.2 Một số cơng cụ quản lý kiểm thử : ..................................................................................................41 Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management) ....................................................................................................... 44 4.1 Mục tiêu của ứng dụng................................................................................................... 44 4.2 Thủ tục cho các quy trình được xây dựng mới .............................................................. 44 4.3 Đặc tả yêu cầu................................................................................................................. 49 KH OA C NT T – Đ H KH TN 5 4.4 Thiết kế ứng dụng........................................................................................................... 51 4.4.1 Mơ hình use case.............................................................................................................................51 4.4.2 Đặc tả use case ................................................................................................................................52 4.5 Mơ hình dữ liệu .............................................................................................................. 72 4.5.1 Kiến trúc hệ thống...........................................................................................................................73 4.5.2 Thiết kế màn hình ...........................................................................................................................77 Chương 5 Thử nghiệm ứng dụng..................................................................................... 89 5.1 Dữ liệu thử nghiệm......................................................................................................... 89 5.1.1 Giới thiệu project thử nghiệm : .......................................................................................................89 5.1.2 Bộ dữ liệu thử nghiệm :...................................................................................................................90 5.2 Kết quả thực hiện chương trình..................................................................................... 91 Chương 6 Tổng kết ............................................................................................................ 92 6.1 Tự đánh giá..................................................................................................................... 92 6.1.1 Những kết quả đạt được : ................................................................................................................92 6.2 Hướng phát triển của chương trình. .............................................................................. 93 Phụ lục ..................................................................................................................................... 95 Phụ lục A. Mơ tả dữ liệu ................................................................................................... 95 Phụ lục B. RM Tool Survey Summary [INCOSE]............................................................ 98 KH OA C NT T – Đ H KH TN 6 Danh sách các hình Hình 1-1 Mơ hình phát triển phần mềm theo quy trình thác nước tại T3H.............................. 11 Hình 1-2 Sơ đồ tổ chức các vai trị của nhân sự trong 1 đề án phần mềm ............................... 14 Hình 1-3 Mơ hình quản lý yêu cầu tại T3H.............................................................................. 16 Hình 1-4 Mơ hình kiểm thử tại T3H......................................................................................... 18 Hình 2-1 Các hoạt động trong CM ........................................................................................... 22 Hình 2-2 Tổng quan về CM...................................................................................................... 23 Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI) ............................................................. 27 Hình 5-1 Mơ hình tiến trình quản lý yêu cầu cho hệ thống mới............................................... 45 Hình 5-2 Mơ hình quản lý kiểm thử cho hệ thống mới ............................................................ 48 Hình 5-3 Mơ hình usecase ....................................................................................................... 51 Hình 5-4 Kiến trúc hệ thống ..................................................................................................... 73 Hình 5-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử. ................................................... 75 Hình 5-6 Các lớp xử lý yêu cầu ................................................................................................ 76 Hình 5-7 Các lớp xử lý kiểm thử .............................................................................................. 76 Hình 5-8 Sơ đồ màn hình cho phần truy cập cơ sở dữ liệu ...................................................... 77 Hình 5-9 Sơ đồ các trang tổng quát .......................................................................................... 77 Hình 5-10 Sơ đồ nhĩm các màn hình liên quan đến phần quản lý yêu cầu.............................. 78 Hình 5-11 Sơ đồ các màn hình liên quan đến phần kiểm thử ................................................... 79 Hình 5-12 MH. Trang chính ..................................................................................................... 80 Hình 5-13 MH.Thơng tin yêu cầu tổng quát............................................................................ 81 Hình 5-14 MH. Cập nhật tài liệu mơ tả yêu cầu. ...................................................................... 82 Hình 5-15 MH. Cây kiến trúc của project ................................................................................ 83 Hình 5-16 MH. Thiết lập mối liên hệ giữa các yêu cầu và phân hệ ......................................... 84 Hình 5-17 MH. Các release trong Project................................................................................. 84 Hình 5-18 MH. Cập nhật mơi trường kiểm tra. ........................................................................ 85 Hình 5-19 MH. Các release và file đã được lập testcase. ......................................................... 86 Hình 5-20 MH. Cập nhật thơng tin review ............................................................................... 87 KH OA C NT T – Đ H KH TN 7 Thuật ngữ / Từ viết tắt / Khái niệm Phần mềm _Software Là những chương trình, những thủ tục được gắn liền với các tài liệu mơ tả và các dữ liệu cĩ liên quan đến tác vụ của một hệ thống máy tính.[PGSQM] Chất lượng _Quality Việc thỏa mãn một sản phẩm theo đúng sự mong đợi của khách hàng, dựa vào những yêu cầu cho sản phẩm.[PGSQM] Việc đảm bảo chất lượng _Quality Assurance hay Kiểm sốt chất lượng _ Quality Control Là một tập các hành động đã được dự định trước đĩ nhằm dị tìm, dẫn chứng qua các tài liệu, phân tích, và hiệu chỉnh các lỗi của sản phẩm cũng như quản lý các thay đổi của sản phẩm.[PGSQM] Quản lý chất lượng _ Quality Management Là việc ủy nhiệm, xúc tiến nhà sản xuất nhận ra, chấp thuận các cải tiến cho tiến trình sản xuất sản phẩm.[PGSQM] SQA Software Quality Assurance SQS Software Quality System CM Configuration management T3H Phịng phát triển phần mềm Trung tâm Tin học trường Đại học Khoa học Khoa học Tự nhiên. Internal release Mỗi khi việc coding hồn tất ở một phân KH OA C NT T – Đ H KH TN 8 hệ hay một phần cụ thể nào đĩ của project, project manager hay coding manager sẽ compile cho một bản release. Bản release này sẽ được kiểm tra, sửa lỗi dùng trong nội bộ cơ quan. Release Release sẽ được giao cho khách hàng khi chương trình đã hồn tất CMMI Capability Maturity Model Integration RM Requirement Management KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 9 Chương 1 Mở đầu 1.1 Khái quát vai trị quy trình phát triển phần mềm Thưở ban đầu của ngành cơng nghiệp máy tính nĩi chung và cơng nghệ phần mềm nĩi riêng, việc phát triển phần mềm được xem như một quá trình “viết và sửa” (code and fix), khơng cĩ bất kỳ một kế hoạch nào trước đĩ. Quá trình này thành cơng cho đến khi các chương trình phần mềm bắt đầu cĩ quy mơ lớn hơn, độ phức tạp cao hơn, cần cĩ sự hợp tác của nhiều người hơn, do đĩ các phương pháp phát triển phần mềm hay quy trình phần mềm ra đời.Thực tế cho thấy, hầu hết các dự án thất bại do các nguyên nhân sau 1 : · Hiểu khơng đúng yêu cầu người dùng · Khơng thể thích ứng với các thay đổi về yêu cầu đối với hệ thống. · Các module khơng khớp với nhau. · Phần mềm khĩ bảo trì và nâng cấp, mở rộng. · Phát hiện trễ các lỗ hổng của dự án. · Chất lượng phần mềm kém. · Hiệu năng của phần mềm thấp. · Các thành viên trong nhĩm khơng biết được ai đã thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi. · Quá trình build-and-release khơng đáng tin cậy. Để khắc phục những rủi ro này địi hỏi việc phát triển phần mềm phải theo một quy trình cụ thể đảm bảo phần mềm được xây dựng đảm bảo được chất lượng, thỏa mãn các yêu cầu của người dùng. 1 [LVRUP99] KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 10 1.2 Tầm quan trọng của việc quản lý quy trình Như đã đề cập ở trên, việc thỏa mãn nhu cầu (Fitness for purpose) của người dùng rất quan trọng, đĩ là đích cuối cùng cho mọi sản phẩm được sản xuất ra. Vì vậy, việc đảm bảo chất lượng phần mềm cũng là một phần rất quan trọng trong quá trình sản xuất phần mềm và do đĩ, việc quản lý chất lượng cũng được đặt ra. Hơn thế nữa, quan điểm hiện đại về việc đảm bảo chất lượng ngày càng phức tạp hơn, khơng cịn giới hạn ở mục tiêu thỏa yêu cầu khách hàng. Một sản phẩm phần mềm chất lượng cao (high quality product) phải kết hợp được nhiều nhân tố chất lượng (quality factors) hay thuộc tính chất lượng (Quality Attributes), trong đĩ cĩ thể chia làm ba loại, đĩ là những nhân tố cĩ thể tìm thấy trong đặc tả yêu cầu ví dụ như tính linh động (portability), là “cutural factors” ví dụ như tính hiệu dụng (usability), và những nhân tố mà người lập trình sẽ chú trọng nhưng người dùng thì khơng, đơn cử là tính tái sử dụng (reusability). Để một sản phẩm đặt ra đạt được những nhân tố chất lượng này khơng phải là một việc dễ dàng, vì vậy, việc quản lý chất lượng phần mềm là một cơng việc khơng thể tránh khỏi trong cơng nghệ phần mềm. 1.3 Hiện trạng phát triển phần mềm tại T3H T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau : · Khảo sát hiện trạng – xác định yêu cầu · Lập giải pháp khả thi · Phân tích · Thiết kế · Coding · Kiểm thử · Triển khai và bảo trì Quy trình được minh họa qua sơ đồ KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 11 NV quản lý đề án NV phân tích _ thiết kế NV quản trị hệ thống NV lập trình NV kiểm tra NV huấn luyện NV quản lý cấu hình NV phân tích _ thiết kế NV phân tích _ thiết kế NV lập trình NV phân tích _ thiết kế NV lập trình NV huấn luyện Lập kế hoạch & theo dõi tiến độâ Lập giải pháp khả thi Khảo sát - phân tích Thiết kế phần mềm Xây dựng phần mềm Kiểm tra & thử nghiệm nội bộ Triển khai Hoàn chỉnh sản phẩm Quản lý cấu hình NV phân tích _ thiết kế Hình 1-1 Mơ hình phát triển phần mềm theo quy trình thác nước tại T3H KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 12 MƠ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM Gđoạn Lập giải pháp khả thi Khảo sát – phân tích Thiết kế phần mềm Xây dựng phần mềm Kiểm tra và thử nghiệm nội bộ Tài liệu đầu vào Tài liệu giải pháp khả thi Tài liệu khảo sát phân tích - Tài liệu khảo sát phân tích - Tài liệu thiết kế phần mềm - Prototype chưong trình - Tài liệu khảo sát phân tích - Tài liệu thiết kế phần mềm - Chương trình Mơ tả cơng việc cụ thể của giai đoạn 1. Khảo sát khả thi 2. Mơ tả và phân tích hiện trạng : chú trọng đến tính khả thi của quy trình nghiệp vụ sẽ được tin học hĩa. 3. Xác định yêu cầu nghiệp vụ 4. Xác định yêu cầu kỹ thuật 5. Đề xuất giải pháp thực hiện - Kiến trúc kỹ thuật - Vấn đề chuyển đổi, cập nhật dữ liệu cũ - Kinh phí - Thời gian thực hiện 6. Thương thảo hợp đồng 1. Khảo sát chi tiết 2. Mơ tả và phân tích hiện trạng (chi tiết hơn Giải pháp khả thi) : - Quy trình nghiệp vụ - Sơ đồ tổ chức xử lý - Mối liên quan với hệ thống khác 3. Phân tích sơ bộ - Mơ hình dữ liệu sơ bộ - Yêu cầu nghiệp vụ - Yêu cầu hệ thống - Yêu cầu giao diện - Yêu cầu sao lưu - Yêu cầu bảo mật - Yêu cầu đường truyền (gửi/nhận) dữ liệu - Yêu cầu về chuyển đổi, cập nhật dữ liệu cũ 4. Tập hợp các tài liệu đã thu thập từ quá trình khảo sát 1. Thiết kế kiến trúc phần mềm 2. Thiết kế dữ liệu mức vật lý. 3. Thiết kế chiến lược: - Các quy ước chung - Cơ chế phát sinh khĩa - Kiểm tra RBTV - Xử lý và thơng báo lỗi - Sao lưu và phục hồi dữ liệu - Bảo mật - Truyền (gửi/nhận) dữ liệu 4. Thiết kế chức năng: - Sơ đồ màn hình - Màn hình chính và hệ thống thực đơn -Màn hình - Báo biểu - Thuật tĩan xử lý chính trên các màn hình và báo biểu 5. Xây dựng prototype chương trình 1. Thiết kế chung kỹ thuật: - Biến dùng chung - Thư viện hàm: các hàm dùng chung, các hàm hệ thống - Các lớp đối tượng (hoặc màn hình) cơ sở 2. Thiết kế chi tiết chức năng 3. Cài đặt CSDL 4. Lập trình và kiểm thử cục bộ 1.Thiết kế kịch bản kiểm tra 2.Kiểm tra từng chức năng: - Kỹ thuật - Nghiệp vụ 3. Kiểm tra tích hợp 4.Chỉnh sửa các lỗi của chương trình 5.Thủ nghiệm chuyển đổi từ dữ liệu cũ 6. Lập tài liệu hướng dẫn Mơ tả cơng việc chung 1. Lập kế họach và theo dõi tiến độ 2. Quản lý cấu hình 3. Xem xét và duyệt kết quả cơng việc 4. Tập huấn, chuyển giao kết quả cơng việc Kết quả đầu ra -Tài liệu giải pháp khả thi -Hợp đồng đã ký Tài liệu khảo sát phân tích - Tài liệu thiết kế phần mềm - Prototype chương trình - Tài liệu Xây dựng phần mềm - Script phát sinh CSDL - Chương trình -Tài liệu Kết quả -Kiểm tra chương trình -Tài liệu hướng dẫn -Chương trình đã kiểm tra KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 13 · Các vai trị tham gia trong một quy trình phát triển phần mềm - NVPhân tích thiết kế - Quản trị hệ thống : hoạt động chủ yếu trong giai đoạn lập giải pháp khả thi & khảo sát phân tích, các hồ sơ, tài liệu cuối cùng được lưu trữ chủ yếu là văn bản giấy, nếu cĩ lưu trữ trên máy thì cũng lưu trữ trên máy của nhân viên phụ trách.. Sau khi kết thúc quá trình khảo sát, nhân viên ghi nhận các yêu cầu từ khách hàng, lưu lại dưới dạng document. Khi cĩ sửa đổi thì ghi nhận lại ngay trên document đĩ. - NV Phân tích thiết kế : Khảo sát phân tích, thiết kế phần mềm lưu lại dưới dạng các document, khơng theo chuẩn nhất định và cũng được sửa chồng khi cĩ sự thay đổi. Việc chuyển giao sang giai đoạn khác được thực hiện thơng qua việc ký nhận văn bản. - NV Lập trình : chịu trách nhiệm lập trình, chỉnh sửa code, đưa ra các release. Mỗi nhĩm lập trình sẽ được phân cơng từng module cụ thể. Quản lý các phiên bản bằng Visual Source Safe. Khi source code thay đổi sẽ phát sinh 1 phiên bản mới, tuy nhiên nĩ khơng thể hiện được sự thay đổi này ảnh hưởng đến những module nào. Việc phân cơng coding cũng được thực hiện bằng tay. - NV Kiểm tra : Sau khi 1 module được coding xong hay đến 1 thời điểm quy định, chương trình được test bởi nhĩm NVKiểm tra. Việc kiểm tra được thực hiện trên giấy. Khi phát hiện lỗi, nhân viên kiểm tra ghi nhận lại lỗi, và thực hiện lặp lại cho đến hết module. Sau khi test xong một module, bảng tường trình lỗi sẽ được gởi đến người chịu trách nhiệm đánh giá lỗi, thường là quản lý dự án. Nếu là lỗi cĩ thể sửa sẽ đựơc xác nhận và chuyển giao cho bộ phận lập trình. Nếu lỗi cĩ thể bỏ qua, người quản lý dự án sẽ xác nhận và kết thúc việc test. (xem chi tiết mơ hình bên dưới) - NV quản lý đề án : là người cĩ chức vụ cao nhất trong quy trình phát triển phần mềm, quản lý tồn bộ các thành viên, chịu trách nhiệm phân cơng, lên kế hoạch, theo dõi tiến độ thực hiện. - Trưởng dự án : chịu trách nhiệm xem xét duyệt lại các tài liệu, kiểm sốt các tiến trình, đảm bảo các tiến trình được thực hiện đúng đắn và đúng tiến độ. KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 14 - NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài liệu cĩ liên quan đến đề án đang thực hiện như : quản lý các thành phần của từng phiên bản cĩ trong đề án, tạo các phiên bản test và phiên bản giao cho khách hàng, đĩng gĩi sản phẩm... - NV Quản lý kiểm thử : chịu trách nhiệm về việc lên kế hoạch kiểm thử, cho từng giai đoạn của đề án, đánh giá kết quả của việc kiểm thử. Và cùng với nhân viên quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử trong trường hợp chương trình vẫn cịn lỗi nhưng những lỗi đĩ khơng nghiêm trọng, cĩ thể chấp nhận để giao cho khách hàng vì thời giao đã gần kề... 2/25/2004 Subtitle Sơ đồ các vai trò trong một đề án Wednesday, February 25, 2004 TRUNG TÂM TIN HỌC Trường đại học Khoa học Tự nhiên Đại học Quốc gia TpHCM PHÒNG PHÁT TRIỂN PHẦN MỀM Quản lý dự án Trưởng dự án NV Quản lý cấu hình NV Quản lý kiểm thử NV Phân tích thiết kế NV Quản trị hệ thống NV lập trình NV kiểm thử NV huấn luyện Hình 1-2 Sơ đồ tổ chức các vai trị của nhân sự trong 1 đề án phần mềm Trong các quy trình phát triển trên, đề tài chú trọng đến hai tiến trình : Quản lý yêu cầu và quản lý kiểm thử KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 15 · Quản lý yêu cầu - Khách hàng đặt hàng, T3H đồng ý nhận đơn đặt hàng, chuẩn bị tiến hành khảo sát - Quản lý dự án lập kế hoạch ban đầu, đặc tả các nhiệm vụ, phân cơng. Bảng kế hoạch được in giấy, phân phát cho nhân viên liên quan. - Khảo sát viên tiến hành khảo sát, sau mỗi lần khảo sát, một bản mơ tả hiện trạng, yêu cầu khách hàng được thiết lập. Đến thời hạn, nhân viên này đưa bản báo cáo cuối cùng cho Quản lý dự án. Khảo sát viên hồn tồn tự quản lý các tài liệu này và chỉ giao cho Quản lý dự án bản cuối cùng. - Khi tiến hành phân tích thiết kế, phân tích viên hay nhân viên thiết kế sẽ làm việc trên tài liệu mà Quản lý dự án đưa. Nếu cĩ thay đổi, nhân viên đĩ sẽ thay đổi trên tài liệu này, ghi nhận và đến thời hạn sẽ giao lại cho Quản lý dự án. - Cuối giai đoạn này, một bản đặc tả yêu cầu và phân tích thiết kế được đưa ra. - Thơng thường, khảo sát viên, nhân viên phân tích thiết kế là một và là quản lý dự án. Quá trình này được mơ hình hĩa thơng qua mơ hình sau : KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 16 QUẢN LÝ YÊU CẨU (Hệ thống hiện tại) Khảo sát viên Trưởng dự ánKhảo sát viên Trưởng dự án Quản lý dự án Nhận đơn đặt hàng từ KH Tiếp xúc với KH Xem xét việc tiến hành dự án Khơng thực hiện dự án Đặc tả nhiệm vụ & phân cơng Tiến hảnh khảo sát Đưa ra các yêu cầu Khách hàng chấp thuận bản yêu cầu Kết thúc khảo sát Bảng yêu cầu (tự quản lý thơng tin) Y N Y N Tài liệu đặc tả yêu cầu cuối cùng Toản bộ các tiến trình được thực hiện bằng tay. Các tài liệu được phát sinh trong giai đoạn này do người phụ trách tự quản lý. Chỉ cĩ bản yêu cầu cuối cùng được gửii cho các thành viên phát triển dự án Hình 1-3 Mơ hình quản lý yêu cầu tại T3H KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 17 · Quản lý kiểm thử : - Sau mỗi lần coding xong ra một internal release, cơng việc kiểm thử được tiến hành. - Thơng qua kinh nghiệm và kiến thức về nghiệp vụ, nhân viên kiểm tra lập ra các bộ kiểm thử (test case) và ghi nhận lại kết quả này bằng tài liệu kiểm thử. - Đến thời hạn, nhân viên này đưa lại cho trưởng bộ phận kiểm thử (Test manager) xem xét đánh giá lỗi trên tài liệu kiểm thử và đưa lại bản tài liệu đã được đánh giá cho người lập trình sửa lỗi. Quá trình này được mơ hình hĩa bên dưới : KH OA C NT T – Đ H KH TN Chương 1 Mở đầu 18 Hình 1-4 Mơ hình kiểm thử tại T3H KH OA C NT T – Đ H KH TN Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H 19 1.4 Đánh giá hiện trạng 1.4.1 Quản lý yêu cầu : · Hiện tại T3H làm phần mềm cĩ quy trình, các nhân viên đều nắm được nhưng việc thủ tục hĩa từng quy trình khơng cĩ, kết quả là khơng cĩ một mẫu biểu chuẩn ghi nhận lại nên thơng tin cĩ thể khơng nhất quán. · Khi các yêu cầu thay đổi trong quá trình thực hiện đề án, nhân viên khơng nhất thiết phải ghi lại thơng tin thay đổi nên cĩ thể họ sẽ quên một số thơng tin, điều này cĩ thể gây ra sự bất đồng bộ trong việc thực hiện phần mềm ở những bộ phận khác nhau. · Đối với một cơng ty nhỏ như T3H chỉ gồm khoảng trên dưới 30 nhân viên thì việc trao đổi thơng tin bằng miệng như hiện nay rất dễ dàng. Khi cĩ một vướng mắc nào đĩ họ cĩ thể hỏi ngay tại đĩ để làm rõ vấn đề. Nhưng đặt trường hợp PPTPM mở rộng, phát triền hơn thì với việc quản lý như hiện nay sẽ rất khĩ khăn. · Khi yêu cầu thay đổi, yêu cầu mới được ghi chồng lên các yêu cầu cũ mà khơng cĩ sự ghi nhận rõ ràng ( người sửa, ngày sửa, nguyên nhân,…) do đĩ khơng lưu vết được các yêu cầu, gây ra khĩ khăn khi cần xem xét lại tài liệu hoặc truy cứu trách nhiệm khi yêu cầu sai. · Khi một yêu cầu được thay đổi người trưởng dự án khơng biết được yêu cầu này ảnh hưởng đến những module nào, và khĩ biết yêu cầu mới cĩ bị trùng lặp với những yêu cầu cũ hay khơng. 1.4.2 Quản lý kiểm thử : · Như phần hiện trạng đã đề cập ở trên, các test case được chính người kiểm thử đề ra, và cũng người đĩ thực hiện việc kiểm tra, nên những người khác hồn tồn khơng biết về những test case này nếu nĩ khơng cĩ xảy ra lỗi. Như vậy các nhân viên khác khĩ cĩ thể học hỏi kinh nghiệm test cũng như chưa kể người thực hiện kiểm thử cĩ thể quên hoặc thiếu một số trường hợp test. KH OA C NT T – Đ H KH TN Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H 20 · Do thơng tin về những lỗi khơng lưu lại, những lỗi xuất hiện trong đề tài nào thì người phát triển đề tài đĩ biết. Đặt trường hợp nếu lỗi đĩ xuất hiện trong một đề tài khác, do người khác phụ trách kiểm thử, nếu như người đĩ biết đã cĩ người gặp phải lỗi đĩ thì người đĩ cĩ thể biết ngay cách chỉnh sửa. Nhưng đặt trường hợp người đĩ khơng biết cĩ người gặp phải lỗi này, thì người đĩ cĩ thể phải tự tìm tịi, chưa kể nếu lỗi đĩ xuất hiện nhiều lần lại phải tốn nhiều cơng sức đầu tư. · Do khơng quản lý phiên bản test, nên trong một sản phẩm, cĩ những lỗi đã được phát hiện rồi, sửa rồi, nhưng phiên bản cuối cùng lại là phiên bản cũ, cĩ lỗi. · Từ việc chuyển giao các test case đến người lập trình viên để cập nhật kết quả đến việc xem xét lại các testcase, cho đến việc kiểm và sữa chữa lỗi trải qua nhiều giai đoạn, do đĩ các hồ sơ dễ bị thất lạc và khơng đúng phiên bản hiện hành. 1.5 Mục tiêu đề tài Tìm hiểu về việc quản lý yêu cầu và quản lý kiểm thử trong quá trình phát triển phần mềm. Ứng dụng xây dựng phần mềm hỗ trợ việc quản lý yêu cầu và kiểm thử tại T3H · Tìm hiểu cơng việc quản lý yêu cầu và quản lý kiểm thử nhằm bảo đảm chất lượng phần mềm. Trong đĩ, chú trọng các thơng tin cần phải quản lý trong hai tiến trình này. · Ứng dụng những kiến thức đĩ, xây dựng chương trình nhằm cải tiến và hỗ trợ cơng việc quản lý yêu cầu và quản lý kiểm thử tại Phịng phát triển phần mềm, Trung tâm Tin học trường Đại học Khoa học Tự nhiên. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 21 Chương 2 Tổng quan về SQA và các cơng việc quản lý yêu cầu, quản lý kiểm thử 2.1 Vai trị của việc quản lý chất lượng phần mềm Hệ thống quản lý chất lượng SQA hay SQS cĩ hai mục tiêu chính : · Đưa vào việc quản lý chất lượng ngay từ khi bắt tay vào xây dựng phần mềm · Đảm bảo chất lượng trong suốt quá trình xây dựng phần mềm Để đạt được hai mục tiêu trên, SQS địi hỏi sự kết hợp của 10 yếu tố : · Standards : là một yếu tố mấu chốt trong SQS. Các chuẩn là nền tảng để cĩ thể đánh giá các hoạt động. Hơn nữa, chúng cung cấp những phương thức thơng thường mà theo đĩ cùng một cơng việc sẽ được hồn thành theo cùng một cách mỗi khi nĩ được thực hiện. Khi áp dụng các chuẩn trong phát triển phần mềm sẽ giúp cho việc đánh giá sự phát triển được đồng đều. · Reviewing : là một hoạt động rất quan trọng trong kiểm sốt chất lượng. Việc kiểm sốt chất lượng liên quan với việc tìm kiếm các lỗi ở nhiều loại sản phẩm phần mềm trong suốt quá trình phát triển chúng. Nếu như việc thanh tra mã nguồn cũng liên quan đến việc tìm lỗi thì việc kiểm duyệt lại tỏ ra hiệu quả hơn vì nĩ tìm các lỗi sớm hơn. · Testing : mục đích của việc kiểm thử là tìm các lỗi và kiểm tra lại xem phần mềm cĩ thỏa yêu cầu của người dùng đưa ra hay khơng. Trong một số trường hợp, cơng việc kiểm thử lại chú trọng vào việc kiểm tra xem phần mềm chạy đúng hay sai hơn là xem phần mềm cĩ thỏa yêu cầu người dùng hay khơng. Điều này hơi đi chệch hướng với mục đích của việc kiểm thử chương trình. Nếu cơng việc kiểm thử khơng dựa trên mục tiêu thỏa mãn yêu cầu thì chỉ phí thời gian. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 22 · Defect analysing : hầu hết các tổ chức dùng thuật ngữ chất lượng (quality) để ngụ ý khơng cĩ hoặc cĩ ít lỗi. Một số khác cho rằng đĩ là chỉ việc phần mềm thỏa mong đợi của người dùng hay khách hàng. Ở đây, cả hai quan niệm đĩ đều đúng. Bất cứ lúc nào, khi phần mềm khơng thể hiện được như mong đợi của người dùng, lúc đĩ xem như một lỗi đã được bắt. Đây cĩ thể là trường hợp lỗi trong code, thiếu yêu cầu người dùng hay chỉ là thiếu một hàm. Khi phát hiện ra một lỗi, cơng việc địi hỏi cần thực hiện là sửa lại cho nĩ đúng. Việc phân tích lỗi được thực hiện trên tất cả các lỗi nhằm khắc phục các thiếu sĩt hiện tại và giảm thiểu số lượng lỗi trong tương lai. · Configuration management (CM) : CM đảm bảo tại bất kỳ thời điểm nào, tình trạng của phần mềm đều được xác định rõ và cĩ thể tái cấu trúc lại. CM bao gồm ba yếu tố cơ bản : định danh cấu hình (configuration identification CID), kiểm sốt cấu hình (configuration control CC) và configuration accounting (CA) tạm dịch là sự diễn giải cấu hình. Hình 2-1 Các hoạt động trong CM CID cung cấp một phương pháp nhằm nhận dạng sự đặc trưng và tính duy nhất của mỗi instance (ví dụ như release, version) trong một sản phẩm phần mềm hay một tập các sản phẩm phần mềm. Bằng cách sử dụng một chuẩn đặt tên để định danh mỗi một instance của sản phẩm, mỗi một hồ KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 23 sơ tài liệu mới, mỗi phần mới được hồn tất, mỗi một phần vừa được build. CC là một yếu tố nhằm đảm bảo bất kỳ sự thay đổi nào của một instance đều được biết, được kiểm sốt và được ghi nhận lại. CC bao gồm các hoạt động thay đổi trong bảng kiểm sốt (control board CCB) như xem xét và kiểm sốt các thay đổi đối với các tài liệu và code. CA giữ vai trị theo vết các tình trạng của các instance sản phẩm. Điều này ngày càng quan trọng hơn trong việc tích hợp các phần hay module vào các hệ thống hoặc các hệ thống con. CA theo vết các thay đổi của yêu cầu, thiết kế, kiểm thử, code, v.v... Hình 2-2 Tổng quan về CM · Security : Các hoạt động bảo đảm an ninh được thực hiện đối với dữ liệu và trung tâm lưu trữ dữ liệu. Một hệ thống quản lý chất lượng tốt nhất nếu khơng cĩ trung tâm lưu trữ dữ liệu sẽ rất dễ bị hư hại hoặc phá hủy hồn KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 24 tồn. Các tai nạn như vỡ ống dẫn nước, cháy nhà, chưa kể những trường hợp bị hacker, viruses… Vì vậy, đảm bảo an tồn dữ liệu cũng như trung tâm lưu trữ dữ liệu cũng là một điều cần thiết. · Education : Việc huấn luyện hay đào tạo bảo đảm những thành viên phát triển dự án hoặc những người sẽ sử dụng phần mềm khi nĩ được hồn tất đều cĩ thể thực hiện cơng việc của họ một cách đúng đắn. Một điều rất quan trọng trong việc đảm bảo chất lượng phần mềm là thành viên sản xuất phải được đào tạo để cĩ thể sử dụng nhiều cơng cụ phát triển khi được yêu cầu. Vai trị của người đảm bảo chất lượng phần mềm là xem xét những kiến thức nào sẽ cần đến trong tương lai và trang bị những kiến thức đĩ cho nhân viên của mình. · Vendor management : khi một phần mềm được hồn tất, cơng việc phát hành cũng rất quan trọng. Việc quản lý những cơng việc nhỏ nhặt xung quanh việc phát triển phần mềm như liên hệ mua bản quyền các phần mềm hỗ trợ cho việc phát triển, các phần mềm chống virus… cũng là một yếu tố trong việc đảm bảo chất lượng. · Safety : Mỗi đề án đều bắt buộc phải đảm bảo an tồn cho chính phần mềm đĩ và cho cả hệ thống. Kế hoạch quản lý dự án nên cĩ phần mơ tả các giải pháp bảo đảm an tồn. · Risk management : Bất kỳ một đề án nào cũng chứa đựng nhiều loại rủi ro, cĩ loại rủi ro đơn giản đến những rủi ro cĩ thể làm phá sản hồn tồn đề án. Do đĩ, rủi ro và những giải pháp cho các giải pháp đĩ là một phần cần thiết trong kế hoạch quản lý dự án. 2.2 Tại sao cần quản lý chất lượng ? · Như đã trình bày ở trên, mục tiêu đầu tiên của phần mềm là thỏa mãn yêu cầu được đặt ra từ phía khách hàng. · Sự thành cơng của một dự án phụ thuộc vào một hệ thống quản lý yêu cầu hiệu quả. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 25 · Các lỗi xuất phát từ đặc tả hay nhầm lẫn yêu cầu là những lỗi thường xuyên nhất và gây tốn kém nhất trong các loại lỗi phát sinh trong quá trình thực hiện phần mềm · Bằng một ít kỹ năng trong quản lý nhưng ta cĩ thể giảm đáng kể các lỗi yêu cầu và vì vậy chất lượng phần mềm cũng được cải thiện. 2.3 Tổng quan về quản lý yêu cầu 2.3.1 Quản lý yêu cầu là gì ? Quản lý yêu cầu là một cách tiếp cận cĩ hệ thống nhằm suy ra, tổ chức lại, ghi nhận ra tài liệu các yêu cầu. Đây là một tiến trình cho phép thiết lập và duy trì hợp đồng giữa khách hàng và nhĩm phát triển phần mềm khi cĩ sự thay đổi yêu cầu trên hệ thống.2 Ở đây, chúng tơi xin đề cập một chút về các khái niệm quan trọng trong định nghĩa trên : · Đầu tiên, bất kỳ ai đã từng cĩ liên quan đến các hệ thống phần mềm phức tạp đều nhận ra rằng việc suy ra được các yêu cầu từ khách hàng là một kỹ năng chủ yếu trong tiến trình khảo sát và đặc tả yêu cầu khách hàng. · Tiếp nữa, nếu một phần mềm chỉ cần hai người làm, độ mươi mười yêu cầu thì khơng cĩ vấn đề gì, nhưng một hệ thống cĩ cả trăm, nếu khơng muốn nĩi hàng ngàn yêu cầu, thì việc quản lý thơng tin đĩ thực sự rất cần thiết. · Cuối cùng, cĩ một điều rõ ràng là bộ ĩc chúng ta chỉ nhớ khoảng vài chục thơng tin, vì vậy việc ghi nhận bằng tài liệu các yêu cầu cũng cần thiết, nhằm hỗ trợ mối liên lạc hiệu quả với khách hàng. 2.3.2 Các thơng tin cần quản lý trong quản lý yêu cầu. Tài liệu đầu tiên mà nhĩm phát triển phần mềm nhận được từ khách hàng là bản liệt kê các yêu cầu. Thơng thường, tài liệu này rất trừu tượng. Bản liệt kê cĩ hai 2 [MSR] , Chapter 2, What is requirement management ? KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 26 loại một được trình bày tổng quát, dành cho Senior Management của khách hàng, bản thứ hai được trình bày chi tiết hơn, dành cho người trực tiếp thực hiện các cơng việc đĩ. Cả hai tài liệu này đều quan trọng, tuy nhiên vấn đề là tài liệu này khơng được tổ chức và cấu trúc hĩa. Bản liệt kê yêu cầu gồm cĩ hai phần quan trọng nhất, đĩ là các yêu cầu chức năng và yêu cầu ràng buộc. Yêu cầu chức năng mơ tả hệ thống cần làm những việc gì, trong khi đĩ các yêu cầu ràng buộc cĩ thể ràng buộc về sản phẩm hay ràng buộc trong tiến trình. Ràng buộc sản phẩm chứa đựng các thơng tin, tính chất mà sản phẩm sau khi được hồn thành sẽ cĩ. Ràng buộc tiến trình quy định cách mà tiến trình phần mềm hay tập các tiến trình được thực hiện. Tài liệu quan trọng nhất trong bất kỳ đề án nào là bản đặc tả yêu cầu. Đây là tài liệu cơ bản cho các tiến trình sau phân tích thiết kế và đặc tả yêu cầu như : đánh giá chi phí chi tiết, thiết kế hệ thống, cấu trúc hệ thống, lập các bộ test và soạn các tài liệu hướng dẫn. Bản đặc tả được phân cấp thành nhiều phần ví dụ như phân chia các hệ thống con, đặc tả dữ liệu, các chế độ của hệ điều hành, giao diện. Một bản đặc tả yêu cầu thường cĩ các phần3 : Tittle Contents Introduction About this document Glossary System requirements Target system environment Customer-imposed constraints Phần About this document : mơ tả các quy ước đặt tên, phạm vi của tài liệu, các chủ đề chính, các thành viên cĩ liên quan, các chuẩn, cách mà bản đặc tả được thực hiện, và cuối dùng là danh sách các đặc tả. 3 The structure of the requirements specification [SQA] KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 27 Glossary chức đựng danh sách các thuật ngữ được dùng và các định nghĩa của chúng. Phần chủ yếu Requirement specification bao gồm đặc tả chi tiết các yêu cầu của hệ thống. Target system environment : mơ tả mơi trường hệ thống sẽ được thiết lập. Phần cuối cùng Customer-imposed constraints sẽ liệt kê danh sách các ràng buộc được đưa ra từ khách hàng. 2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI CMMI (Capability Maturity Model Integration) tích hơp các tiến trình cải tiến phần mềm, được phát hành phiên bản đầu tiên vào năm 2000. CMMI đưa ra năm mức độ trưởng thành hay năm tầng trưởng thành theo năng lực phần mềm theo thứ tự từ cao xuống thấp như sau : Optimizing (Tối ưu hĩa), Quantitatively Management (Được quản lý dựa vào định lượng), Defined (Được định nghĩa), Managed (Được quản lý), Initial (Khởi động). Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI) KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 28 Tiến trình RM nằm ở mức 2 trong 5 tầng trưởng thành của CMMI. Mục đích của RM là quản lý những yêu cầu đặt ra cho sản phẩm, thành tố được sản sinh bởi các đề án và nhận ra những điểm khơng nhất quán giữa những yêu cầu này so với các bảng hoạch định đề án và các sản phẩm. Các quy tắc thực tiễn chuyên biệt cho vùng tiến trình này : · Hiểu rõ yêu cầu (Optain an understanding of Requirement), phát triển một sự hiểu biết với những người cung cấp yêu cầu dựa trên ý nghĩa các yêu cầu. · Thống nhất về thực hiện yêu cầu (Obtain Commitment to Requirements) giữa các thành viên thực hiện dự án. · Quản lý thay đổi yêu cầu (Manage Requirement Changes) khi cĩ sự thay đổi phát sinh trong suốt quá trình thực hiện dự án. · Duy trì mối liên hệ hai chiều (Mantain Bidirectional Tracebility of Requirements) giữa các yêu cầu, hoạch định đề án và các cơng việc sản xuất sản phẩm. · Xác định mâu thuẫn giữa yêu cầu và sản phẩm cơng việc (Identify Inconsistencies between Project work and Requirement ). Các vùng tiến trình liên quan đến RM : Phát triển yêu cầu_Requirement Development (RD), Hoạch định đề án_Project Plan (PP), Giải pháp kỹ thuật_ Technical Solution (TS), Quản lý cấu hình_Configuration Management (CM), Theo dõi và kiểm sốt đề án_Project Monitoring and Control (PMC), Quản lý rủi ro_Risk Management (RKSM). 2.4 Tổng quan về quản lý kiểm thử 2.4.1 Mục tiêu của quản lý kiểm thử. · Gồm cĩ ba mục tiêu chính : quản lý testcase, lập kế hoạch test, quản lý testscript. · Bảo đảm tiến trình kiểm thử được thực hiện một cách đúng đắn. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 29 · Kiểm sốt quá trình kiểm thử tốt hơn, hiệu quả hơn, phát hiện lỗi càng sớm càng tốt. · Theo dõi được các kịch bản kiểm thử, tránh trường hợp trùng lắp các kịch bản cho mỗi đợt kiểm tra. · Theo vết các lỗi, xác định tình trạng của một lỗi tại bất kỳ thời điểm nào. 2.4.2 Các thơng tin cần quản lý trong quản lý kiểm thử. Cĩ rất nhiều tài liệu mơ tả hệ thống và các tiến trình test trong giai đoạn này bao gồm : · Tài liệu đặc tả thiết kế test . · Đặc tả kịch bản kiểm thử · Thủ tục kiểm thử · Test log · Bảng báo cáo lỗi · Tổng kết kiểm thử Tài liệu đặc tả thiết kế test : đây là một trong những tài liệu mơ tả cách nào các tính năng và các nhĩm tính năng liên quan được kiểm thử. Tài liệu này khơng chú trọng vào bất kỳ một kịch bản kiểm thử nào, ở đây chỉ mơ tả đến các thuật ngữ dùng trong quá trình kiểm thử. Đặc tả kịch bản kiểm thử : tài liệu này mơ tả các kịch bản test thành phần. Mỗi kịch bản kiểm thử được đánh mã duy nhất. Trong kịch bản kiểm thử cịn cĩ : Test input : bao gồm danh sách các dữ liệu được dùng cho việc kiểm thử. Nếu dữ liệu được lưu trong một file thì tên file đĩ phải được nêu. Test output : Kết quả mong đợi sau khi kiểm tra. Yêu cầu về cứng và phần mềm : mơ tả những yêu cầu cho phần cứng và phần mềm để thực hiện kịch bản kiểm tra bao gồm cả những phần mềm hay cơng cụ hỗ trợ việc kiểm tra và phiên bản hệ điều hành, các phiên bản các phần mềm hỗ trợ khác. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 30 Các chỉ thị đặc biệt : nếu cơng việc kiểm thử địi hỏi người kiểm thử thực hiện bất kỳ hành động đặc biệt nào thì những hành động này đều phải được ghi nhận lại. Thủ tục kiểm thử : đây là tài liệu mơ tả từng bước một cơng việc kiểm thử được thực hiện cũng như cách tiến hành các bộ test tương tự khác. Thủ tục kiểm thử cũng mơ tả chi tiết làm thế nào tìm thấy item cần kiểm tra, loại item này là gì, và loại kiểm tra này là loại gì. Thơng thường, thủ tục kiểm tra được thực hiện cho nhĩm kiểm tra độc lập, khơng biết rõ phần mềm mình đang kiểm thử. Test log : Mơ tả điều gì xảy ra khi một kịch bản được thực hiện, trong đĩ mơ tả nội dung kiểm thử, thủ tục kiểm tra, việc xảy ra trong suốt quá trình test, phần cứng, phần mềm nào được sử dụng, mơ tả bất kỳ hành động nào khơng được mong đợi, và nếu như bộ test nào khơng được pass thì phải cĩ tham chiếu đến bảng báo cáo các lỗi. Bảng báo cáo lỗi : được phát sinh khi một thủ tục kiểm thử cho trước nào đĩ khơng thực hiện đúng như mong đợi. Tài liệu này bao gồm thơng tin các sự kiện, mơi trường phần cứng và phần mềm được sử dụng, khi nào thì lỗi phát sinh, và người thực hiện kiểm tra là ai. Tổng kết kiểm thử : Đây là bảng tổng kết các kịch bản kiểm tra. Thơng thường cơng việc này được thực hiện sau việc kiểm tra một hệ thống con hay tồn bộ hệ thống được hồn tất. Nội dung bảng tổng kết bao gồm danh sách các bộ test đã được thực hiện, đánh giá mức độ hồn thành, chi tiết các lỗi quan trọng và các thơng tin chung như thời gian thực hiện việc kiểm tra là bao nhiêu. 2.4.3 Giới thiệu tiến trình Verification (VER) trong CMMI Mục đích của VER là đảm bảo rằng các sản phẩm được lựa chọn đáp ứng các yêu cầu đã được quy định cho chúng. VER gồm ba mục tiêu chuyên biệt : · Chuẩn bị cho cơng tác kiểm tra (Prepare for Verification) trên sản phẩm đã chọn. KH OA C NT T – Đ H KH TN Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử 31 · Tiến hành việc xem xét ngang cấp (Perform Peer Review) trên sản phẩm đã chọn. · Kiểm tra các sản phẩm được chọn (Verify Selected Work Product) dựa trên các yêu cầu cụ thể. Để đạt được các mục tiêu chuyên biệt này, CMMI quy định các tiến trình chuyên biệt tương ứng với từng mục tiêu. · Đối với mục tiêu Chuẩn bị cho cơng tác kiểm tra , các tiến trình bao gồm : - Lựa chọn sản phẩm kiểm tra (Selected Work Products for Verification). - Thiết lập mơi trường kiểm tra sản phẩm (Establish the Verification Environment). - Thiết lập các thủ tục và tiêu chuẩn kiểm tra (Establish Verification Procedures and Criteria). · Đối với mục tiêu Tiến hành xem xét ngang cấp , các tiến trình bao gồm : - Chuẩn bị cơng tác xem xét ngang cấp (Prepare for Peer Review). - Tiến hành cơng tác xem xét (Conduct Peer Review). - Phân tích dữ liệu kết quả của quá trình xem xét (Analyze Peer Review Data). · Đối với mục tiêu Kiểm tra các sản phẩm được chọn , các tiến trình bao gồm : - Tiến hành kiểm tra (Perform Verification). - Phân tích kết quả kiểm tra và xác định các hành động khắc phục (Analyze Verification Results and Identify Corrective Action) Các tiến trình liên quan đến tiến trình này : Phát triển yêu cầu_Requirement Development (RD), Xác nhận_Validation (VAL), Quản lý yêu cầu_Requirement Management (RM) KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 32 Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay 3.1 Cơng cụ hỗ trợ quản lý yêu cầu 3.1.1 Giới thiệu : Ngày nay cĩ rất nhiều cơng cụ hỗ trợ cho việc quản lý yêu cầu, nên việc chọn lựa cơng cụ quản lý yêu cầu cũng gặp khĩ khăn. Để giải quyết vấn đề này, các nhà phân tích khuyên chúng ta nên lựa chọn dựa vào những yêu cầu của Project đang thực hiện hoặc những địi hỏi của cơng ty hoặc thơng qua sự tìm hiểu về các cơng cụ này. Cĩ hai yếu tố chính giúp chúng ta trong việc lựa chọn các cơng cụ, thứ nhất là chúng phải giúp chúng ta theo vết các yêu cầu một cách đầy đủ và thứ hai là hỗ trợ việc kiểm thử một cách đặc biệt. Kiểm thử là một phần của quy trình phát triển sản phẩm phần mềm, và nên được duy trì cùng với việc phát triển phần mềm, vì vậy việc theo vết để kiểm thử rất quan trọng. Thời gian để học và sử dụng cơng cụ thơng thường khoảng một tháng. Sau đây là danh sách các cơng cụ quản lý yêu cầu 4: RM Tool List Active!Focus AnalystPro Caliber-RM C.A.R.E. 2.0 Catalyze CORE Cradle DOORS & DOORSrequireIT 001 (double oh one) EasyRM Focal Point IRqA Jalsoft Mac A&D and Win A&D Projectricity Prosareq Requirements Manager Qualica QFD RDT Reconcile Reqtify 4 Ludwig Consulting Services, LLC KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 33 Requirement Tracing System Requisite Pro RMTrak RTM Workshop SLATE SpeedReq Team-Trace Tracer (free) Vital Link XTie-Requirements Tracer Một cơng cụ quản lý yêu cầu sẽ khơng giải quyết những vấn đề bị gây ra bởi những yêu cầu kém chất lượng. Bất kể cơng cụ cĩ tốt như thế nào, những yêu cầu kém chất lượng rất khĩ để quản lý và cĩ thể dẫn đến sự tranh cãi với khách hàng. Những yêu cầu kém làm tăng chi phí và kéo dài thời gian. Chúng làm cho sản phẩm bị lỗ hổng và cĩ thể dẫn đến dự án bị hủy bỏ. 3.1.2 Định nghĩa cơng cụ quản lý yêu cầu Một bộ cơng cụ quản lý yêu cầu là một bộ cơng cụ giúp cho việc quản lý yêu cầu được dễ dàng. Những tính chất cơ bản cho một cơng cụ được xem là cơng cụ quản lý yêu cầu [INCOSE]: · Sự xác nhận những yêu cầu riêng biệt · Sự phân phối và sắp xếp các yêu cầu · Sự xác nhận việc duyệt lại nhĩm yêu cầu · Cung cấp việc ghép nối dữ liệu cơ bản Tất nhiên một phần của việc lưu trữ các yêu cầu này cũng được thực hiện tùy thuộc vào người dùng, cĩ thể trên giấy hoặc trên các thiết bị điện tử. Một bộ cơng cụ cĩ thể bao gồm một hoặc vài cơng cụ và những cơng cụ này đều cĩ thể thực hiện những chức năng phụ trợ thêm cho việc quản lý yêu cầu. 3.1.3 Các loại cơng cụ Hiện nay đang cĩ rất nhiều cơng cụ quản lý yêu cầu. Về loại thì việc sắp xếp cĩ thể khơng rõ ràng, nhưng những cơng cụ này cĩ thể sắp xếp thơng qua các yếu tố : · Dựa trên tài liệu : Theo vết các yêu cầu bằng cách thêm vào các bảng/liên kết đến những tài liệu đã tồn tại trước đĩ. KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 34 · Theo vết yêu cầu : theo vết và thường xuyên chỉnh sửa những yêu cầu trong số các tập hợp yêu cầu được đưa vào · Phát sinh yêu cầu : phát sinh ra những tập hợp yêu cầu trong các cơng cụ. Các bộ cơng cụ như vậy thơng thường cũng cĩ thể được dùng tương tự như những cơng cụ cĩ trước khác · Mơ hình cĩ sẵn và sự mơ phỏng 3.1.4 Tại sao phải sử dụng các cơng cụ quản lý yêu cầu : Để tối ưu hĩa chi phí phát triển phát triển, sự trễ hạn, và chất lượng phần mềm, người quản lý phải quản lý các yêu cầu một cách chính xác. Những nhà quản lý doanh nghiệp định nghĩa các yêu cầu thương mại ở cấp độ cao. Bộ phận chuyên mơn về cơng nghệ thơng tin cần phải chuyển các yêu cầu thương mại này thành những đặc tính chức năng để phát triển. Bộ phận này cũng cần phải thống nhất với nhà quản lý doanh nghiệp về phạm vi của project và đưa vào bản miêu tả những yêu cầu phi chức năng như là mức độ phục vụ và tính dễ bảo trì. Phạm vi của dự án thay đổi khác nhau trong suốt thời gian phát triển. Nhà quản lý doanh nghiệp địi hỏi những chức năng mới, muốn cĩ sự tích hợp mới và thường xuyên thay đổi ý kiến của họ. Do đĩ, bộ phận cơng nghệ thơng tin gặp khĩ khăn trong việc xác nhận sự ảnh hưởng của những yêu cầu mới trong project và cần phải xác nhận phạm vi của project sau khi thêm yêu cầu mới vào là hợp lệ. Bộ phận cơng nghệ thơng tin muốn xác nhận những yêu cầu tương tự trong những dự án khác nhau để sử dụng lại các những gì đã được phát triển trước đĩ. Điều này giúp tiết kiệm thời gian cho việc thiết kế, phát triển và kiểm thử cho những yêu cầu tương tự. Những cơng cụ quản lý yêu cầu rất hữu dụng trong việc điều khiển chất lượng của việc phát triển phần mềm. Nĩ làm việc quản lý yêu cầu được dễ dàng hơn và đảm bảo sự tồn vẹn cho quy trình phát triển. Nĩ giúp cho doanh nghiệp và bộ phận tin học thống nhất với nhau về phạm vi của dự án bằng cách quản lý độ ưu tiên KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 35 của những yêu cầu đang cấp bách. Ngồi ra những cơng cụ này cũng làm cho việc hồn thành các yêu cầu được thực hiện. Những cơng cụ quản lý yêu cầu giúp cho việc phát triển liên quan đến sự thay đổi các yêu cầu được nhất quán. Điều này được thực hiện nhờ vào sự phân tích ảnh hưởng của sự thay đổi, giúp cho người dùng cĩ một cái nhìn tồn vẹn các yêu cầu và sự phát triển liên quan. 3.1.5 Kiến trúc chức năng : Những cơng cụ quản lý yêu cầu cung cấp những chức năng sau : · Tạo lập yêu cầu : Các yêu cầu cĩ thể được tạo lập bằng cách phân tích cấu trúc của các tập tin bên ngồi. Chúng cĩ thể được định nghĩa trực tiếp từ giao diện người dùng của phần mềm. Nĩ giúp người dùng phân loại những yêu cầu trong project và thư mục. · Cải tiến các yêu cầu : Ngay khi những yêu cầu thương mại được đưa ra từ khách hàng, người quản lý dự án cần phải tìm ra những yêu cầu chức năng một cách nhanh chĩng và tác vụ cần phát triển một cách chính xác. Ngồi ra các cơng cụ này cũng giúp liên kết các yêu cầu khác nhau trong những bước phát triển của dự án. · Phân tích các yêu cầu : Các yêu cầu được phân tích để đảm bảo tính nhất quán của nĩ. Ngay khi những yêu cầu được lấy, các cơng cụ sẽ theo dõi nguồn gốc của nĩ. Hơn nữa các cơng cụ này cịn giúp chúng ta hiểu được các tình trạng của yêu cầu ở tất cả cấp độ của project và phân tích sự ảnh hưởng của việc thay đổi yêu cầu đối với project. · Quản lý thay đổi của những yêu cầu : Các cơng cụ quản lý yêu cầu giúp người dùng cĩ thể điều khiển được sự truy xuất những yêu cầu đã được định nghĩa. Nĩ giúp cho việc quản lý yêu cầu được đồng nhất bằng cách quản lý những phiên bản dựa trên các thay đổi được đưa vào. Những thay đổi này được ghi nhận lại trong lịch sử thay đổi của yêu cầu. KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 36 Những cơng cụ quản lý yêu cầu cung cấp các khả năng đặc biệt làm cho việc quản lý yêu cầu bởi nhiều người sử dụng được dễ dàng hơn : · Khả năng cộng tác : Các yêu cầu được quản lý bởi những người khác nhau. Các cơng cụ quản lý yêu cầu giúp tổ chức cơng việc giữa các yêu cầu. Chúng cho phép việc truy xuất đồng thời vào các yêu cầu và cung cấp khả năng làm việc theo luồng để quản lý sự các tiến trình định nghĩa yêu cầu, dẫn xuất và thay đổi. Nĩ cũng hỗ trợ cho các cổng liên lạc như e-mail và diễn đàn thảo luận để làm cho việc truyền đạt thơng tin về các yêu cầu được dễ dàng hơn. · Khả năng tích hợp : Các yêu cầu phải được thiết kế và phát triển ứng dụng phần mềm. Những cơng cụ quản lý yêu cầu tích hợp vào các cơng cụ thiết kế, phát triển và kiểm thử. Nĩ cũng tích hợp vào các cơng cụ quản lý dự án phần mềm, hay các cơng cụ của các sản phẩm phổ biến như mục giúp đỡ của các trình xử lý văn bản trong việc thay đổi nội dung của yêu cầu. Nội dung của yêu cầu và những thơng tin khác ( tự điển dùng để phân tích các yêu cầu, siêu dữ liệu về yêu cầu, mẫu kết xuất, và những tài liệu liên quan đến yêu cầu) được lưu trong một kho chứa. Việc mở các thư mục này đảm bảo việc truy xuất các thơng tin. Hình 3-1 Kiến trúc chức năng của các cơng cụ quản lý yêu cầu KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 37 3.1.6 So sánh với các phần mềm cĩ chức năng tương tự : · Các cơng cụ quản lý yêu cầu giúp chúng ta ghi nhận, phân tích, thay đổi và cải tiến các yêu cầu đồng thời đảm bảo sự đồng nhất của nĩ thơng qua việc theo vết các yêu cầu và xem xét sự phụ thuộc của nĩ. · Các cơng cụ quản lý yêu cầu khác với các cơng cụ xử lý văn bản vì các cơng cụ xử lý này thiếu những đặc tính hỗ trợ cho sự theo vết các yêu cầu, một vài trình xử lý văn bản như Word (Microsoft), WordPerfect (Corel) và StarWriter (Sun Microsystems). · Các cơng cụ này cũng khác với những cơng cụ quản lý dự án vì các cơng cụ này khơng đưa vào bản miêu tả sự nắm bắt và cải tiến yêu cầu. Các cơng cụ quản lý yêu cầu dựa trên những cơng cụ này để theo dõi sự hồn thành các tác vụ. Một vài cơng cụ quản lý dự án như : AllFusion Project Planner (CA), Niku (Niku), TeamPlay (Primavera) and Project (Microsoft). · Những cơng cụ quản lý yêu cầu khác với các cơng cụ quản lý phiên bản. Những cơng cụ quản lý yêu cầu hoặc cung cấp những đặc tính quản lý phiên bản của riêng nĩ hoặc dựa trên những cơng cụ thuộc lớp thứ ba. Một vài cơng cụ quản lý phiên bản như : SourceSafe (Microsoft), PVCS Version Manager (Merant) và CVS (Concurrent Versions System, một dự án mã nguồn mở). KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 38 Hình 3-2 Mối liên hệ giữa quản lý yêu cầu và các hoạt động khác. 3.1.7 Đánh giá các cơng cụ quản lý yêu cầu5 3.2 Cơng cụ kiểm thử : 3.2.1 Các loại cơng cụ kiểm thử : · Cơng cụ kiểm thử dựa trên yêu cầu : Cơng cụ thiết kế Test case chức năng, làm sáng tỏ yêu cầu ứng dụng, và sử dụng “yêu cầu” như là cơ sở cho việc thiết kế kiểm thử · Cơng cụ quản lý kiểm thử : Theo dõi tất cả các tài liệu kiểm thử thơng qua một kho chứa thơng tin chung và chứa đựng các nội dung như kế hoạch kiểm thử (test plan), trường hợp kiểm thử ( test case), kịch bản test (test script) · Cơng cụ kiểm thử hồi quy : Mỗi sự thay đổi code, cải tiến, sửa lỗi, và các phần nền tảng địi hỏi cần phải cĩ sự kiểm thử lại tồn bộ ứng dụng để đảm bảo chất lượng của phiên bản phát hành · Cơng cụ phân tích thơng tin Mục đích của nĩ là giám sát hệ thống trong khi một cơng cụ kiểm thử tự động được thực thi · Cơng cụ kiểm thử động Nĩ bao gồm một chuỗi thứ tự các chỉ thị của máy tính. Mục đích của cơng cụ test động là để khảo sát một chương trình đối xử và hoạt độmg của hệ thống trong khi nĩ thực thi · Cơng cụ kiểm thử tĩnh Mục đích của nĩ nhằm phát hiện các lỗi bằng cách khảo sát phần mềm hơn là thực thi · Cơng cụ quản lý Website 5 Tham khảo phụ lục B KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 39 Giúp người quản trị và quản lý doanh nghiệp mọi khía cạnh của sự thay đổi của trang web. Nĩi giúp nhận dạng và sửa chữa các lỗi trong việc tích hợp các cấu trúc của website, đứt kết nối, orphan page, những vẫn đề về hoạt động tiềm tàng trong website.6[TestTools] Sau đây là bảng so sánh các chức năng của các cơng cụ test : 6 Lecture NoteSWE 637 Software Testing and Quality AssuranceYe Wu KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 40 KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 41 3.2.2 Một số cơng cụ quản lý kiểm thử : 3.2.2.1 Cơng cụ quản lý kiểm thử hỗ trợ cho phần viết bằng ngơn ngữ CORBA (Common Object Request Broker Architecture) 3.2.2.1.1 SilkPilot, Segue Software, Inc., Đây là cơng cụ hỗ trợ cho việc kiểm thử chức năng và hồi quy của các máy chủ lớp giữa. Silk Pilots giúp người dùng kiểm thử một cách nhanh chĩng và dễ dàng hoạt động của đối tượng được phân phối trong những thành phần của ứng dụng. SilkPilot cĩ thể được dùng để kiểm tra những máy chủ CORBA (Common Object Request Broker Architecture) mà nĩ được thực thi bằng bất cứ ngơn ngữ nào, cũng như những máy chủ Java thuần thơng qua giao diện chung RMI (Remote Method Invocation). SilkPilot cũng hỗ trợ mơ hình thành phần Enterpise Java Bean (EJB). Khi sử dụng Silk Pilot chúng ta khơng cần phải xây dựng những chương trình kiểm tra như thường lệ, một giao diện người dùng point-and-click (trỏ-và-nhấn chuột) sẽ giúp bạn tạo ra những bộ test mà khơng cần coding. Platforms: Siemens, Stratus, Win 95/98/NT. 3.2.2.1.2 Test Manager, Julian Jones Ltd Đây là cơng cụ để xây dựng, thực thi và quản lý các bộ test. TestManger là một hệ thống phát triển phần mềm việc viết thuần bằng Java. Nĩ cĩ thể cung cấp một IDE (Interactive Development Environment) để làm việc với các bộ test hồi quy giúp người dùng dễ dàng tạo lập, phân loại, thực thi và lưu trữ một bộ test. Các thủ tục testcase cĩ thể được xây dựng từ một tập hợp của các thủ tục cơ bản được cung cấp bởi hệ thống. Những thủ tục này được cấu hình thơng qua IDE bằng cách sử dụng các thuộc tính. Khơng việc lập trình nào được địi hỏi để thực thi các chương trình một cách tùy tiện, những câu truy vấn SQL, hay những giao tác HTTP trong IDE. Thêm vào đĩ, hệ thống cũng cung cấp những thủ tục đăng kí truyền thống đơn giản được viết bằng Java, cho phép hệ thống được mở rộng để thực thi bất kì loại thủ tục test nào, bao gồm cả việc kiểm tra các máy chủ CORBA, EJB, Java RMI hoặc những hệ thống hợp pháp. Hệ thống sẽ tự động xác nhận sự thực thi KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 42 một bộ test mà khơng địi hỏi người dùng phải can thiệp, cung cấp những thống kê, tĩm tắt về kết quả của việc thực hiện kiểm tra. Platforms: Bất kì platform nào 3.2.2.2 Cơng cụ quản lý kiểm thử hỗ trợ cho phần viết bằng ngơn ngữ C/C++ 3.2.2.2.1 Cantata, Quality Checked Software Ltd. Là cơng cụ dùng để khai thác việc kiểm thử, phân tích các thơng tin, và là cơng cụ phân tích tĩnh. Cantata cung cấp một giải pháp sản phẩm cao cho việc test đơn thể và tích hợp mã C và C++. Nĩ cung cấp một cách thực hiện dễ hiểu cho việc kiểm tra động, thơng tin kiểm thử, phân tích tĩnh trong một đĩng gĩi được tích hợp đơn. Platforms: Hầu hết các hệ thống đích và đang phát triển, bao gồm DOS, OS/2, Windows, Unix và VMS và hỗ trợ hầu hết các trình biên dịch phổ biến sử dụng C/C++. 3.2.2.3 Cơng cụ quản lý kiểm thử hỗ trợ cho những ngơn ngữ khác 3.2.2.3.1 AutoAdviser, AutoTester Inc. Là cơng cụ để phân tích và quản lý test. AutoAdviser quản lý tiến trình đảm bảo chất lượng của tất cả dự án phần mềm thơng qua tồn bộ chu kì sống của nĩ. Từ những yêu cầu thơng qua sản phẩm, AutoAdviser cung cấp một kho chứa trung tâm cho việc tổ chức và quản lý những yêu cầu thương mại, test và các tập tin liên quan, và kết quả test của người dùng. AutoAdviser khơng chỉ là một cơng cụ quản lý test – nĩ là những cơng cụ tiện lợi cho việc phân tích mà cho phép bạn đánh giá sự sẵn sàng của ứng dụng khi phát hành vào thị trường. Kho chứa trung tâm: AutoAdviser thực sự là một giải pháp nhĩm làm việc cho việc sử dụng, quản lý, và duy trì những thư viện kiểm thử ứng dụng. Nĩ phục vụ như một kho chứa trung tâm, AutoAdviser thống nhất với các thành phần giao diện test và cung cấp những thành viên nhĩm test với sự truy cập đến các thành KH OA C NT T – Đ H KH TN Chương 3 Các cơng cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử 43 phần đĩ. Những yêu cầu thương mại, kế hoạch kiểm tra, việc kiểm tra, và kết quả kiểm tra, đều được chứa và quản lý trong AutoAdviser. Lập kế hoạch kiểm tra : AutoAdviser giúp bạn lập kế hoạch cho việc kiểm tra để chắc chắn rằng các thủ tục thương mại chính đều được kiểm tra và các yêu cầu thương mại đều được định địa chỉ. Những yêu cầu thương mại được chứa trong kho và được liên kết trực tiếp đến việc kiểm tra của AutoAdviser. AutoAdviser hiển thị những yêu cầu thương mại của bạn dưới dạng kiến trúc phân tầng cho phép bạn cĩ thể phân tích một cách nhanh chĩng luồng tiến trình của ứng dụng. Những đặc tính của tài liệu dẫn chứng một cách đầy đủ cung cấp sự tham khảo dễ dàng đến chi tiết các yêu cầu và việc kiểm thử liên quan. Với AutoAdviser bạn cĩ thể chắc chắn rằng mỗi chức năng của ứng dụng đều được kiểm tra một cách thỏa đáng trước khi phát hành. Điều khiển thay đổi : Quản lý dự án điều khiển tồn bộ khả năng kiểm tra với các chức năng quản lý yêu cầu của AutoAdviser. Việc phân quyền cho việc truy xuất ở những cấp độ khác nhau, từ việc xem lại báo cáo đến việc chỉnh sửa việc test cho phép bạn quản lý việc truy cập đến thành phần thư viện kiểm tra của bạn. Việc giám sát thay đổi của AutoAdviser giúp bảo vệ thơng tin kiểm thử bằng cách ngăn chặn người dùng viết đè lên file hoặc chỉnh sửa cùng lúc những file kiểm thử. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 44 Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management) 4.1 Mục tiêu của ứng dụng Ứng dụng được xây dựng nhằm hỗ trợ tiến trình quản lý yêu cầu và quản lý kiểm thử tại T3H. Ứng dụng sẽ chú trọng vào quản lý nội dung yêu cầu, các testcase và giúp nhà quản lý cĩ thể theo vết các thay đổi yêu cầu, các lỗi. 4.2 Thủ tục cho các quy trình được xây dựng mới 4.2.1.1 Quản lý yêu cầu Với hệ thống mới, các quy trình lấy yêu cầu vẫn giữ lại hầu như tồn bộ hệ thống hiện tại, cĩ thay đổi ở chỗ ghi nhận các tài liệu yêu cầu. Sau mỗi lần nhân viên khảo sát về sẽ cập nhật các yêu cầu này vào cơ sở dữ liệu. Các thơng tin này được quản lý bởi phần mềm hỗ trợ sẽ được xây dựng. Như vậy, mỗi lần cĩ sự thay đổi trong tài liệu mơ tả yêu cầu, người sử dụng sẽ dùng các chức năng cập nhật lại của phần mềm sẽ được xây dựng, sẽ cĩ lưu vết sự thay đổi này cho dễ dàng cho cơng việc tham khảo sau này. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 45 Hình 4-1 Mơ hình tiến trình quản lý yêu cầu cho hệ thống mới 4.2.1.2 Quản lý kiểm thử Để việc kiểm thử được thực hiện một cách thủ tục hơn, PPTPM đã quyết định sẽ tiến hành theo các tiến trình cụ thể và cĩ sự hỗ trợ của một phần mềm nhằm lưu vết việc kiểm thử. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 46 Trước tiên, người trưởng dự án hay người quản lý cấu hình sẽ tiến hành xác định phiên bản kiểm tra vì việc coding được thực hiện bởi nhiều người, do đĩ các phần khác nhau sẽ cĩ nhiều phiên bản khác nhau. Nhiệm vụ của người trưởng dự án, quản lý cấu hình là xác định phân hệ cĩ phiên bản nào cần kiểm tra. Cơng việc này sẽ được hỗ trợ bởi phần quản lý cấu hình để cĩ cái nhìn tổng quát về cấu hình phần mềm đang xây dựng. Sau đĩ, duyệt yêu cầu kiểm tra, cơng việc cụ thể là duyệt bảng yêu cầu kiểm tra, xem cần kiểm tra những yêu cầu nào. Đây là cơng việc làm bằng tay. Tiếp theo, chuẩn bị phiên bản kiểm tra, đây cũng là cơng việc làm bằng tay, nghĩa là người trưởng dự án sẽ đưa ra những phân hệ cụ thể với phiên bản cụ thể cho các nhân viên chuẩn bị tiến hành kiểm thử. Kế đến, người quản lý cơng việc kiểm thử sẽ tiến hành lập kế hoạch kiểm tra. Thực chất giai đoạn này, người phụ trách sẽ tiến hành đề ra những test case cụ thể, chuẩn bị cho cơng việc test. Đây sẽ là một trong những chức năng chính của phần mềm xây dựng hỗ trợ cơng việc kiểm thử. Các test case được lập trong giai đoạn này sẽ được quản lý chi tiết, được lưu trữ trong cơ sở dữ liệu do chương trình hỗ trợ quản lý. Bước tiếp theo là thành lập nhĩm kiểm tra, cơng việc chính trong giai đoạn này là phân cơng ai, thực hiện test trong những phần nào. Hiển nhiên, cơng việc này thực hiện thơng qua buổi họp và cơng việc này cũng làm bằng tay. Bắt đầu tiến hành kiểm tra, trước tiên phải thiết lập mơi trường kiểm tra, cài đặt cấu hình máy cho phù hợp để chạy được chương trình cần kiểm tra, hiển nhiên là khơng cần cĩ chức năng hỗ trợ ở đây. Song song với nĩ là xem xét cĩ cần phải hiệu chỉnh gì các test case nữa hay khơng, chức năng này sẽ được xây dựng. Khi hồn tất hai cơng việc trên, việc tiếp theo là thực hiện kiểm tra sản phẩm, cập nhật lại kết quả kiểm tra cho các test case tương ứng, ghi nhận kết quả thơng qua chức năng cập nhật test case, cập nhật lỗi phát hiện trong giai đoạn này. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 47 Sau khi hồn tất kiểm tra, người trưởng dự án sẽ xem xét, đánh giá lại kiểm tra, xem các lỗi được phát hiện trong giai đoạn trước cĩ cần phải đem chỉnh sửa hay khơng, thơng qua chức năng cập nhật lỗi. Bước qua giai đoạn này, người trưởng dự án, quản lý cơng việc test, quản lý dự án sẽ quyết định xem cĩ kết thúc kiểm tra hay khơng, thơng qua cuộc họp giữa các nhân viên ở trên. Nếu thấy những lỗi phát hiện trong giai đoạn này khơng nhất thiết phải sửa thì cĩ thể kết thúc cơng việc kiểm thử ở đây. Nếu khơng sẽ đưa cho nhân viên lập trình chỉnh sửa và quay lại việc bắt đầu kiểm tra. Cơng việc này cũng cĩ một phần làm bằng tay và một phần dùng chức năng cập nhật lỗi. Các cơng việc làm bằng tay trong giai đoạn này sẽ được lưu tình trạng tiến hành cơng việc thơng qua chức năng phần mềm sẽ xây dựng. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 48 Hình 4-2 Mơ hình quản lý kiểm thử cho hệ thống mới KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 49 4.3 Đặc tả yêu cầu 4.3.1.1 Quản lý yêu cầu Ứng với mỗi lần khảo sát xong, khảo sát viên sẽ rút ra các yêu cầu từ hiện trạng hệ thống của khách hàng. Như vậy, nhân viên sẽ mơ tả các yêu cầu này trong một document trên word, mơ tả chi tiết các yêu cầu. Phần mềm sẽ phải quản lý các tài liệu này. Một tài liệu mơ tả yêu cầu sẽ phải cĩ các thơng tin mơ tả sau : Thực hiện : [Người thực hiện tài liệu này] Ngày thực hiện : [Ngày hồn tất tài liệu này] Ấn bản : [version thứ mấy , ví dụ v01] Phê duyệt / Phê bình : [Tên người phê bình hay duyệt tài liệu này] (reviewed/approved) Ngày phê duyệt : [Ngày phê duyệt tài liệu] Ngày bắt đầu cĩ hiệu lực : [Tư liệu này cĩ hiệu lực từ ngày] Ngày hết hiệu lực : [Tư liệu này hết hiệu lực từ ngày] Ký duyệt hết hiệu lực : [Người quyết định vơ hiệu hĩa tư liệu này] Ngồi ra, cần phải ghi nhận mối liên hệ giữa từng yêu cầu cụ thể với từng phân hệ trong chương trình đang xây dựng. Khi cần thiết, phần mềm sẽ phải hỗ trợ việc thể hiện mối liên hệ này, cụ thể là khi thay đổi yêu cầu này sẽ ảnh hưởng đến những phân hệ nào. Các yêu cầu cụ thể cho phần này : · Yêu cầu lưu trữ Thơng tin từng yêu cầu Thơng tin đường dẫn file mơ tả yêu cầu tương ứng Mối liên hệ giữa yêu cầu và các phân hệ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 50 · Yêu cầu chức năng Cập nhật thơng tin yêu cầu Thiết lập mối liên hệ giữa yêu cầu và phân hệ thực hiện các yêu cầu đĩ Thể hiện sự ảnh hưởng giữa yêu cầu và phân hệ 4.3.1.2 Quản lý kiểm thử Để hổ trợ cho việc kiểm thử, phần mềm sẽ cĩ các chức năng ghi nhận các test case (kịch bản test) cho từng phân hệ cụ thể. Ứng với mỗi test case này sẽ cĩ kết quả kiểm thử, kết quả này cũng phải được ghi nhận lại. Yêu cầu phải lưu vết cơng việc test này, nghĩa là phải cung cấp được thơng tin chương trình này đã được kiểm thử bao nhiều lần, ứng với mỗi lần thử, cho biết cĩ bao nhiêu test case được lập, kết quả từng test case. Ngồi ra, cần phải hỗ trợ chức năng thể hiện mối liên hệ giữa các lỗi và các phân hệ. Khi cần thiết, cho người sử dụng biết nếu sửa một lỗi sẽ phải sửa những phân hệ nào. Các yêu cầu cụ thể cho phần này : · Yêu cầu lưu trữ Thơng tin các test case được lập Thơng tin lỗi Mối liên hệ giữa lỗi và các phân hệ · Yêu cầu chức năng Lập các test case Cập nhật các lỗi Cập nhật mối liên hệ giữa lỗi với các phân hệ Thể hiện sự ảnh hưởng đến các phân hệ khi sửa một lỗi nào đĩ Thống kê lỗi KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 51 4.4 Thiết kế ứng dụng 4.4.1 Mơ hình use case User Login Analyser Update requirement View History Set relationship between req & Module Project Manager View Requirement report View test report Create testcase Test Manager Update test environment Tester Update test result Reviewer Review test result Programmer Fix test result Hình 4-3 Mơ hình usecase KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 52 4.4.2 Đặc tả use case Quản lý Yêu cầu và kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Login Date : Đặc tả UseCase : Login 1. Login 1.1. Mơ tả chính : Use Case cho phép người dùng đăng nhập vào hệ thống khi đã cĩ Account hợp lệ tương ứng với một role trong một project cụ thể. Ngăn chặn người ngồi xâm nhập vào hệ thống. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : Người dùng chọn chức năng đăng nhập từ màn hình chính · Hệ thống hiển thị màn hình Đăng nhập. · Hệ thống yêu cầu người dùng nhập UserName và Password. · Hệ thống yêu cầu người dùng chọn một project. · Hệ thống yêu cầu người dùng chọn một vai trị/ role. · Người dùng nhấn nút đồng ý. · Hệ thống nhận thơng tin từ người dùng và kiểm tra trong cơ sở dữ liệu · Hệ thống thơng báo việc đăng nhập đã thành cơng với người dùng 2.2. Dịng sự kiện phụ : 2.2.1. Tên hoặc mật khẩu sai : · Người dùng chọn chức năng Đăng Nhập từ màn hình chính · Hệ thống hiển thị màn hình Đăng nhập · Hệ thống yêu cầu người dùng nhập UserName và Password KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 53 · Hệ thống nhận thơng tin từ người dùng và kiểm tra trong cơ sở dữ liệu · Hệ thống thơng báo việc đăng nhập khơng thành cơng 2.2.2. Chọn vai trị khơng đúng trong project đĩ : · Người dùng chọn chức năng Đăng Nhập từ màn hình chính · Hệ thống hiển thị màn hình Đăng nhập · Hệ thống yêu cầu người dùng nhập UserName và Password · Hệ thống yêu cầu người dùng chọn project. · Hệ thống yêu cầu người dùng chọn vai trị trong project đĩ. · Hệ thống nhận thơng tin từ người dùng và kiểm tra trong cơ sở dữ liệu · Hệ thống thơng báo việc đăng nhập khơng thành cơng 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải được cấp một Account hợp lệ 5. Điều kiện hậu quyết Người dùng đăng nhập thành cơng vào hệ thống 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 54 Quản lý Yêu cầu và kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Update requirement Date : Đặc tả UseCase : Update requirement 1. Update requirement 1.1. Mơ tả chính : Use Case cho phép người dùng cập nhật tài liệu mơ tả yêu cầu của một project 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : Người dùng chọn chức năng Update requirement từ màn hình chính · Hệ thống hiển thị màn hình Update requirement. · Hệ thống hiển thị các tài liệu đã được lập cho project. 2.1.1. Tạo mới một tài liệu yêu cầu 2.1.1.1. Tạo một tài liệu hồn tồn mới · Người dùng chọn Add new requirement · Hệ thống mở màn hình cập nhật tài liệu yêu cầu · Người dùng nhập các thơng tin tổng quát : ngày tạo tài liệu, người cập nhật, người được phỏng vấn · Người dùng chọn đường dẫn file đặc tả yêu cầu · Người dùng chọn chức năng attach tài liệu vào hệ thống để quản lý phiên bản · Hệ thống thể hiện cây cấu trúc các thư mục, tập tin được quản lý phiên bản7. · Người dùng chọn thư mục để lưu tài liệu · Chọn nút Save để lưu 7 Chức năng Phần mềm quản lý phiên bản_ Triệu Ngọc Tồn và Hồ Nguyễn Ngọc Phương KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 55 · Người dùng chọn các yêu cầu đã cĩ sẵn cho tài liệu yêu cầu đĩ · Nhấn nút lưu để lưu thơng tin 2.1.1.2. Tạo tài liệu mới từ một phiên bản tài liệu trước đĩ · Người dùng chọn một version của tài liệu để dựa theo. · Người dùng chọn Add new requirement · Hệ thống mở màn hình cập nhật tài liệu yêu cầu cĩ thơng tin dựa theo phiên bản đã được chọn trước đĩ. · Người dùng cập nhập các thơng tin tổng quát : ngày tạo tài liệu, người cập nhật, người được phỏng vấn · Người dùng cập nhật đường dẫn file đặc tả yêu cầu · Người dùng chọn chức năng attach tài liệu vào hệ thống để quản lý phiên bản · Hệ thống thể hiện cây cấu trúc các thư mục, tập tin được quản lý phiên bản. · Người dùng chọn thư mục để lưu tài liệu · Chọn nút Save để lưu · Người dùng chọn cập nhật các yêu cầu đã cĩ sẵn cho tài liệu yêu cầu đĩ · Nhấn nút lưu để lưu thơng tin 2.1.2. Cập nhật thơng tin tài liệu yêu cầu · Người dùng chọn một tài liệu để cập nhật thơng tin. · Hệ thống mở màn hình cập nhật tài liệu yêu cầu cĩ thơng tin dựa theo phiên bản đã được chọn trước đĩ. · Người dùng cập nhập các thơng tin tổng quát : ngày tạo tài liệu, người cập nhật, người được phỏng vấn · Người dùng cập nhật đường dẫn file đặc tả yêu cầu · Người dùng chọn chức năng attach tài liệu vào hệ thống để quản lý phiên bản KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 56 · Hệ thống thể hiện cây cấu trúc các thư mục, tập tin được quản lý phiên bản. · Người dùng chọn thư mục để lưu tài liệu · Chọn nút Save để lưu · Người dùng chọn cập nhật các yêu cầu đã cĩ sẵn cho tài liệu yêu cầu đĩ · Nhấn nút lưu để lưu thơng tin 2.1.3. Cập nhật một yêu cầu 2.1.3.1. Thêm mới một yêu cầu · Chọn chức năng Add new requirement · Hệ thống mở màn hình tạo mới một yêu cầu · Người dùng nhập thơng tin mơ tả yêu cầu đĩ : mơ tả cho yêu cầu đĩ, loại yêu cầu, ngày chỉnh sửa, tình trạng yêu cầu, người chỉnh sửa yêu cầu, yêu cầu liên quan. · Nhấn nút lưu để lưu lại thơng tin. 2.1.3.2. Cập nhật một yêu cầu · Người dùng chọn một tài liệu mơ tả yêu cầu · Hệ thống mở màn hình mơ tả tài liệu đặc tả yêu cầu. · Người dùng chọn một yêu cầu để cập nhật. · Hệ thống mở màn hình cập nhật yêu cầu. · Người dùng nhập thơng tin mơ tả yêu cầu đĩ : mơ tả cho yêu cầu đĩ, loại yêu cầu, ngày chỉnh sửa, tình trạng yêu cầu, người chỉnh sửa yêu cầu, yêu cầu liên quan, nguyên nhân thay đổi. · Nhấn nút lưu để lưu lại thơng tin. 2.2. Dịng sự kiện phụ : 2.2.1. Nhập các ngày sai: · Khi cập nhật tài liệu mơ tả yêu cầu. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 57 · Người dùng nhập các ngày khơng hợp lý : ngày Review trước ngày tạo tài liệu, ngày cĩ hiệu lực trước ngày review, ngày cĩ hết hiệu lực trước ngày cĩ hiệu lực. · Hệ thống thơng báo lỗi cho người dùng. 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với vai trị Analyser hay Project Manager 5. Điều kiện hậu quyết Nếu usecase này thực hiện thành cơng thì thơng tin mơ tả yêu cầu được cập nhật. 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 58 Quản lý Yêu cầu và kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : View History Date : Đặc tả UseCase : View History 1. View History 1.1. Mơ tả chính : Use Case cho phép người dùng xem lịch sử của một yêu cầu trong một project. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : Người dùng chọn chức năng Requirement từ màn hình chính · Hệ thống hiển thị các tài liệu mơ tả đã được lập cho project đĩ. · Người dùng chọn một tài liệu. · Hệ thống hiển thị tài liệu mơ tả yêu cầu và các yêu cầu trong project đĩ. · Người dùng chọn một yêu cầu nào cần xem lịch sử. · Hệ thống hiển thị lịch sử của yêu cầu đĩ. 2.2. Dịng sự kiện phụ : 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng đăng nhập quyền Analyser hay Project Manager 5. Điều kiện hậu quyết Nếu usecase được thực hiện thành cơng thì người dùng xem được thơng tin lịch sử các yêu cầu 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 59 Quản lý Yêu cầu và kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : View Requirement Report Date : Đặc tả UseCase : View requirement report 1. View Requirement report 1.1. Mơ tả chính : Use Case cho phép người dùng xem báo cáo thống kê về các yêu cầu. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : Người dùng chọn chức năng xem thống kê từ màn hình chính · Hệ thống hiển thị màn hình lập báo cáo. · Người dùng chọn loại báo cáo. · Hệ thống người dùng chọn project hay thống kê tất cả các yêu cầu từ tất cả các project. · Người dùng nhấn nút view để xem thống kê. · Hệ thống kết xuất thống kê. 2.2. Dịng sự kiện phụ : 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền Project Manager. 5. Điều kiện hậu quyết Nếu usecase được thực hiện thành cơng thì một báo cáo thống kê cần thiết sẽ được kết xuất. 6. Điểm mở rộng Khơng cĩ. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 60 Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Update test environment Date : Đặc tả UseCase : Update test environment 1. Update test environment 1.1. Mơ tả chính : Use Case này cho phép TestManager tạo mới hay điều chỉnh thơng tin mơi trường kiểm tra cho một internal release cụ thể. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : 2.1.1. Tạo test environment mới · Người dùng chọn internal release. · Người dùng chọn chức năng lập mơi trường kiểm tra · Hệ thống mở màn hình cập nhật thơng tin mơi trường kiểm tra. · Người dùng nhập các thơng tin mơi trường kiểm tra chung cho internal release đĩ như đợt test, ngày lập, thơng tin cấu hình máy kiểm tra, thơng tin cấu hình server, các component sử dụng. · Người dùng nhấn nút lưu để lưu các thơng tin này. 2.1.2. Sửa thơng tin mơi trường kiểm tra · Người dùng chọn internal release. · Người dùng chọn chức năng edit để thay đổi thơng tin kiểm tra chung · Hệ thống mở màn hình cập nhật thơng tin mơi trường kiểm tra. · Người dùng thay đổi các thơng tin mơi trường kiểm tra chung cho internal release đĩ như đợt test, ngày lập, thơng tin cấu hình máy kiểm tra, thơng tin cấu hình server, các component sử dụng. · Người dùng nhấn nút lưu để lưu các thơng tin này.. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 61 2.1.3. Xĩa thơng tin kiểm tra liên quan đến release đĩ · Người dùng chọn internal release. · Người dùng chọn chức năng delete để xĩa. · Hệ thống sẽ xĩa tất cả các thơng tin mơi trường kiểm tra cũng như các thơng tin kiểm tra được lập chung cho các file và các testcase lập cho file đĩ. 2.2. Dịng sự kiện phụ : 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là TestManager 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thơng tin chung về mơi trường kiểm tra được thay đổi, hoặc thêm vào hoặc xĩa tất cả các thơng tin kiểm khỏi hệ thống 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 62 Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Create testcase Date : Đặc tả UseCase : Create testcase 1. Create testcase 1.1. Mơ tả chính : Use Case này cho phép TestManager tạo mới hay điều chỉnh thơng tin của một TestCase của một file trong một internal release cụ thể. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : 2.1.1. Thêm TestCase mới · Người dùng chọn internal release cần tạo testcase · Hệ thống hiển thị các file cĩ trong internal release đĩ · Người dùng chọn một file để lập các testcase cho file đĩ. · Người dùng nhập các thơng tin kiểm thử chung cho file đĩ như interface caption, người lập, ngày lập, người được phân cơng test, ngày dự kiến sẽ test. · Người dùng nhấn nút lưu để lưu các thơng tin này. · Người dùng chọn chức năng tạo mới một testcase · Hệ thống thêm một dịng vào bảng testcase bên dưới cho người dùng nhập vào các thơng tin như đặc tả testcase, kết quả mong đợi khi thực hiện test case đĩ. · Người dùng nhấn nút lưu lưu thơng tin testcase vừa mới nhập 2.1.2. Sửa testcase 2.1.2.1. Sửa thơng tin kiểm thử chung · Người dùng chọn internal release. · Hệ thống hiển thị các file cĩ trong internal release đĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 63 · Người dùng chọn một file để lập các testcase cho file đĩ. · Hệ thống hiển thị các thơng tin kiểm thử của file đã được lập trước đĩ · Người dùng sửa các thơng tin này · Người dùng nhấn nút lưu để lưu các thơng tin này. 2.1.2.2. Sửa từng testcase trong file · Người dùng chọn internal release. · Hệ thống hiển thị các file cĩ trong internal release đĩ · Người dùng chọn một file để lập các testcase cho file đĩ. · Hệ thống hiển thị các testcase của file đã được lập trước đĩ · Người dùng nhấn nút edit trong bảng để điều chỉnh các thơng tin · Người dùng nhấn nút lưu để lưu các thơng tin này. 2.1.3. Xĩa TestCase 2.1.3.1. Xĩa cả thơng tin chung · Người dùng chọn internal release. · Hệ thống hiển thị các file cĩ trong internal release đĩ · Người dùng chọn chức năng xĩa thơng tin kiểm tra liên quan đến một file · Hệ thống xĩa thơng tin chung này đồng thời xĩa tất cả các testcase lập cho file đĩ 2.1.4. Xĩa riêng từng Testcase · Người dùng chọn internal release. · Hệ thống hiển thị các file cĩ trong internal release đĩ · Hệ thống hiển thị các testcase đã được lập cho file đĩ · Người dùng chọn chức năng xĩa testcase · Hệ thống xĩa testcase 2.2. Dịng sự kiện phụ : KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 64 2.2.1. Cập nhật thơng tin kiểm thử chung khi internal release đĩ chưa thiết lập test environment · Người dùng chọn một internal release · Hệ thống hiển thị các file trong internal release đĩ · Người dùng chọn một file để lập testcase · Hệ thống thơng báo internal release này chưa được lập test environment 2.2.2. Cập nhật testcase khi chưa cĩ thơng tin kiểm thử chung của file · Người dùng chọn một internal release · Hệ thống hiển thị các file trong internal release đĩ · Người dùng chọn một file để lập testcase · Người dùng chọn chức năng tạo mới một testcase · Hệ thống thơng báo thơng tin kiểm thử chung của file chưa được tạo. 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là TestManager 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thơng tin của TestCase được thay đổi, hoặc thêm vào hoặc xĩa Testcase khỏi hệ thống 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 65 Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Update test result Date : Đặc tả UseCase : Update test result 1. Update test result 1.1. Mơ tả chính : Use Case này cho phép Tester cập nhật thơng tin kiểm tra trên một file. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : · Người dùng chọn chức năng cập nhật kết quả test. · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file cần cập nhật kết quả test. · Người dùng nhấn nút test. · Hệ thống mở màn hình cập nhật thơng tin kiểm thử. · Hệ thống hiển thị tồn bộ thơng tin chung của file đĩ và các testcase được lập riêng cho file này. · Người dùng nhấn nút edit để cập nhật thơng tin test : cho biết testcase đĩ pass hay khơng, ghi chú thêm · Người dùng nhấn nút lưu để lưu lại thơng tin này. 2.2. Dịng sự kiện phụ : 2.2.1. Người dùng chưa chọn một file nào đĩ cần cập nhật thơng tin kiểm tra. · Người dùng chọn chức năng cập nhật kết quả test. · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 66 · Hệ thống hiển thị các file đã được lập testcase. · Người dùng nhấn nút test. · Hệ thống thơng báo người dùng cần chọn một file để cập nhật thơng tin 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là Tester 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thì thơng tin kiểm tra cho một file được cập nhật. 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 67 Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Review test result Date : Đặc tả UseCase : Review test result 1. Review test result 1.1. Mơ tả chính : Use Case này cho phép Reviewer xem xét lại kết quả kiểm tra và cập nhật thơng tin review trên một file. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file cần review. · Người dùng nhấn nút Review. · Hệ thống mở màn hình cập nhật thơng tin review. · Hệ thống hiển thị tồn bộ thơng tin chung của file đĩ và các testcase được lập riêng cho file này. · Người dùng nhấn nút edit để cập nhật thơng tin review : nhận xét xem testcase đĩ pass hay khơng, ghi chú thêm và đánh giá mức độ nghiêm trọng nếu testcase đĩ cĩ lỗi. · Người dùng nhấn nút lưu để lưu lại thơng tin này. 2.2. Dịng sự kiện phụ : 2.2.1. Người dùng chưa chọn một file nào đĩ cần cập nhật thơng tin review. · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 68 · Hệ thống hiển thị các file đã được lập testcase. · Người dùng nhấn nút Review. · Hệ thống thơng báo người dùng cần chọn một file để cập nhật thơng tin 2.2.2. Người dùng chọn một file chưa sẵn sàng để review · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file · Người dùng nhấn nút Review. · Hệ thống kiểm tra thấy vẫn cịn một số testcase của file này chưa được test · Hệ thống thơng báo người dùng cần chọn một file khác vì file này chưa được test xong. 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là Reviewer 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thì thơng tin review cho một file được cập nhật. 6. Điểm mở rộng Khơng cĩ Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : Fix testcase Date : KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 69 Đặc tả UseCase : Fix testcase 1. Fix testcase 1.1. Mơ tả chính : Use Case này cho phép Programmer xem xét lại kết quả kiểm tra, kết quả review và cập nhật thơng tin đánh giá lại của programmer trên một file. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : 2.1.1. Cập nhật thơng tin chung · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file cần Fix. · Hệ thống hiển thị thơng tin kiểm tra chung của file đĩ · Reviewer cập nhật thơng tin tên của mình, ngày review. · Người dùng nhấn nút Lưu để lưu thơng tin chung. 2.1.2. Cập nhật thơng tin fix từng testcase · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file cần Fix. · Hệ thống hiển thị thơng tin kiểm tra chung của file đĩ · Người dùng chọn một testcase cĩ lỗi cần fix. · Hệ thống mở màn hình cập nhật thơng tin của testcase đĩ. · Người dùng cập nhật các thơng tin nhận xét của người lập trình như thực sự testcase đĩ cĩ lỗi hay khơng, nguyên nhân gây lỗi, đoạn code chú thích nếu cĩ. · Người dùng thiết lập mối liên hệ giữa testcase này với những testcase khác. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 70 · Người dùng nhấn nút lưu để lưu lại thơng tin này. · Hệ thống lưu thơng tin vừa nhập. 2.2. Dịng sự kiện phụ : 2.2.1. Người dùng chưa chọn một file nào đĩ cần cập nhật thơng tin fix. · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng nhấn nút Fix. · Hệ thống thơng báo người dùng cần chọn một file để cập nhật thơng tin 2.2.2. Người dùng chọn một file chưa sẵn sàng để fix · Hệ thống hiển thị các internal release đã được lập testcase. · Người dùng chọn một internal release. · Hệ thống hiển thị các file đã được lập testcase. · Người dùng chọn một file · Người dùng nhấn nút fix. · Hệ thống kiểm tra thấy vẫn cịn một số testcase của file này chưa được review · Hệ thống thơng báo người dùng cần chọn một file khác vì file này chưa được review xong. 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là Reviewer 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thì thơng tin fix cho một testcase sẽ được cập nhật. 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 71 Quản lý Yêu cầu và Kiểm thử phần mềm Phịng phát triển phần mềm Trung Tâm Tin Học ĐH Khoa Học Tự Nhiên Version : Đặc tả UseCase : View Test Report Date : Đặc tả UseCase : View Test Report 1. View Test Report 1.1. Mơ tả chính : Use Case này cho phép người dùng xem thống kê báo cáo kết quả kiểm tra. 2. Dịng sự kiện : 2.1. Dịng sự kiện chính : · Người dùng chọn chức năng xem báo cáo kết quả kiểm tra từ màn hình chính. · Hệ thống hiển thị màn hình lập báo cáo. · Người dùng chọn loại báo cáo cần lập. · Người dùng chọn lập báo cáo dựa trên một project hay tất cả project. · Người dùng chọn nút xem báo cáo. · Hệ thống hiển thị báo cáo thống kê. 2.2. Dịng sự kiện phụ : 3. Special Requirements Khơng cĩ 4. Điều kiện tiên quyết Người dùng phải đăng nhập với quyền là Test Manager 5. Điều kiện hậu quyết Nếu việc thực hiện UseCase này thành cơng thì sẽ kết xuất thơng tin thống kê cần thiết. 6. Điểm mở rộng Khơng cĩ KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 72 4.5 Mơ hình dữ liệu8 8 Mơ hình các quan hệ sử dụng trong ứng dụng. Xem mơ hình dữ liệu của tồn bộ hệ thống tại Phụ lục A. KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 73 4.5.1 Kiến trúc hệ thống 4.5.1.1 Kiến trúc tổng quát của tồn bộ hệ thống Hệ thống được xây dựng bao gồm Quản lý cấu hình phần mềm và Quản lý yêu cầu, kiểm thử cho T3H. Kiến trúc của tồn bộ hệ thống như sau : Qly cac version (Toan + Phuong) Qly cac yeu cau (Hieu + Chi) Qly test case (Hieu + Chi) Phan Quyen + phan cong nhiem vu trong de an (Toan + Phuong) C SD L C hu ng C VS D B Hình 4-4 Kiến trúc hệ thống Cả hai phần mềm sử dụng một cơ sở dữ liệu chung. Cơ sở dữ liệu này bao gồm cơ sở dữ liệu lõi của phần mềm CVS9 quản lý các version và một cơ sở dữ liệu mới được bao phủ bên ngồi. Cơ sở dữ liệu của CVS sẽ hỗ trợ việc quản lý các thơng tin cơ bản về version các thành phần. Cơ sở dữ liệu chung được xây dựng bọc ngồi sẽ hỗ trợ lưu trữ cụ thể và đáp ứng rõ hơn nhu cầu cần lưu trữ cho hệ thống Các chức năng được xây dựng sẽ truy xuất vào phần thơng tin chung bao bọc ngồi. 9 Luận văn Quản lý cấu hình_ Triệu Ngọc Tồn và Hồ Nguyễn Ngọc Phương KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 74 4.5.1.2 Kiến trúc phần mềm Quản lý yêu cầu và kiểm thử Hình 4-1 Kiến trúc Client_Server Do hệ thống được sử dụng và triển khai qua mạng Intranet nên hệ thống được thiết kế theo mơ hình client/server, việc cung cấp các xử lý chính được tập trung ở server, các xử lý phụ sẽ được cung cấp ở các client tương ứng. “Client” được định nghĩa như một người địi hỏi các dịch vụ, “server” được xem như là nhà cung cấp dịch vụ. Ngồi ra với mơ hình client- server, các máy trạm sẽ giao tiếp với các dịch vụ dữ liệu ở server (ví dụ như store procedure) Ngồi ra hệ thống cũng được cài đặt theo mơ hình 3-lớp : KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và kiểm thử” 75 Hình 4-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử. · Presentation : Dùng để giao tiếp với người dùng, nĩ hiển thị dữ liệu đến người dùng, cho phép thao tác dữ liệu và là đầu vào của dữ liệu. Ví du : thể hiện giao diện, kiểm tra tính hợp lệ của dữ liệu, nhận các thơng tin dữ liệu do người dùng nhập vào. · Business Service : Dùng để xử lý các dữ liệu đầu vào từ lớp presentation, kiểm tra tính đúng đắn của dữ liệu, đảm bảo kiến trúc của dữ liệu, gọi đến lớp DataService để truy cập dữ liệu. · Data Service : Đây là lớp nhận các tham số dữ liệu, truy cập vào hệ quản trị cơ sở dữ liệu để rút trích, cập nhật dữ liệu. · Kiến trúc 3 lớp giúp ứng dụng cĩ được những thuận lợi như : Tính sử dụng lại, tính linh động, dễ quản lý, dễ bảo trì. Giúp cho người lập trình KH OA C NT T – Đ H KH TN Chương 4 Xây dựng “Phần mềm qu