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.1SilkPilot, 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
KHOA CNTT –
ĐH KHTN
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
KHOA CNTT –
ĐH KHTN
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ử.
KHOA CNTT –
ĐH KHTN
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.
KHOA CNTT –
ĐH KHTN
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ử.
KHOA CNTT –
ĐH KHTN
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ả
KHOA CNTT –
ĐH KHTN
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.
KHOA CNTT –
ĐH KHTN
48
KHOA CNTT –
ĐH KHTN
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ệ
KHOA CNTT –
ĐH KHTN
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
KHOA CNTT –
ĐH KHTN
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
KHOA CNTT –
ĐH KHTN
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 : <2.0>
Đặc tả UseCase : Login Date : < 30/3/2004>
Đặ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
KHOA CNTT –
ĐH KHTN
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
KHOA CNTT –
ĐH KHTN
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 : <2.0>
Đặc tả UseCase : Update requirement Date : < 30/3/2004>
Đặ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