Giới thiệu project thử nghiệ m:

Một phần của tài liệu Luận văn: Tìm hiểu quy trình 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 Đại học Khoa học Tự nhiên. doc (Trang 90 - 105)

Dữ liệu được thu thập từ project “Kế tốn nơng trường cao su Phước Hồ”. Nơng trường gồm ba bộ phận : Phịng kế tốn, Phịng kế hoạch và nhĩm nơng trường, trung tâm y tế, tạm gọi nhĩm này là các bộ phận khác.

Mơi trường phát triển : Visual Basic 6.0

Cấu hình máy chủ :

Hệđiều hành : Windows 2000 Server

Hệ quản trị cơ sở dữ liệu : Microsoft SQL Server 2000.

Máy trạm :

Hệđiều hành : Windows XP, Windows 9x, Windows 2000; Cơ sở dữ liệu : Microsoft SQL Server 2000.

Phạm vi ứng dụng :

· Phịng kế tốn :

o Cập nhật bảng phân tốn lương của cơ quan

o Cập nhật, định khoản các chứng từ kế tốn : tiền mặt, chuyển khoản, tạm ứng, vật tư, thành phẩm, tổng hợp (khấu hao tài sản,

điều chỉnh tỷ giá, kết chuyển cuối kỳ) o Tập hợp và phân bổ chi phí giá thành.

o Lập các sổ sách kế tốn và báo cáo tài chánh.

· Phịng kế hoạch :

o Cập nhật các chứng từ vật tư, thành phẩm. o Lập các bảng kê, báo cáo xuất nhập tồn.

· Bộ phận khác :

KHOA CNTT –

ĐH KHTN

90

5.1.2 Bộ dữ liệu thử nghiệm :

- Các yêu cầu :

o Cập nhật bảng phân tốn lương của cơ quan

o Cập nhật, định khoản các chứng từ kế tốn : tiền mặt, chuyển khoản, tạm ứng, vật tư, thành phẩm, tổng hợp (khấu hao tài sản,

điều chỉnh tỷ giá, kết chuyển cuối kỳ) o Tập hợp và phân bổ chi phí giá thành.

o Lập các sổ sách kế tốn và báo cáo tài chánh o Cập nhật các chứng từ vật tư, thành phẩm. o Lập các bảng kê, báo cáo xuất nhập tồn

o Cập nhật các chứng từ thu chi, nhập xuất vật tư/phân bĩn. - Mối liên hệ giữa yêu cầu và phân hệ.

o Tương ứng giữa mỗi yêu cầu thuộc về phân hệ nào sẽ được thiết lập quan hệ với phân hệđĩ.

- Bộ testcase được thiết lập cho release : PH.IAS 1.0., được tạo lập cho các file sau :

o CN_CTKToan.frm

o clsPhatSinh_DinhKhoan.cls o DMVT.frm

o DMKhoVT.rpt - Mơi trường kiểm tra :

o CPU : P.III 500

o Độ phân giải : 800 x 600

o Hệđiều hành : Windows 2000 Professional

o Các component : Visual Studio 98; Data Widget 3.13; MDAC 2.7; Crystal Report 8.5; MS SQL 2000 Client Tools; Visual Studio Service package 5; VietKey

o Hệđiều hành server : Windows 2000 Server

KHOA CNTT –

ĐH KHTN

91

5.2 Kết qu thc hin chương trình

- Chức năng cập nhật yêu cầu : thực hiện thành cơng.

- Chức năng thiết lập mối liên hệ giữa yêu cầu và các phân hệ : thực hiện thành cơng.

- Chức năng xem báo cáo thống kê các yêu cầu của project : thành cơng.

- Chức năng lập mơi trường kiểm tra : thực hiện thành cơng. - Chức năng lập testcase cho các file : thành cơng.

- Chức năng cập nhật kết quả kiểm tra : thành cơng.

- Chức năng cập nhật thơng tin review kết quả test : thành cơng.

- Chức năng cập nhật thơng tin fix cho các testcase cĩ lỗi : thành cơng.

- Chức năng xem thống kê các lỗi trong một project : thành cơng. - Chức năng xem thống kê các lỗi trong một phân hệ : thành cơng. - Chức năng xem thống kê các lỗi trong tất cả project : thành cơng. - Chức năng tìm kiếm thơng tin liên quan khi cĩ mơ tả của một yêu

cầu : thành cơng.

- Chức năng tìm kiếm thơng tin liên quan đến một testcase khi cĩ mơ tả của một testcase : thành cơng.

- Chức năng tìm kiếm những testcase cĩ cùng mơi trường kiểm tra : thành cơng.

KHOA CNTT – ĐH KHTN 92 Chương 6 Tng kết 6.1 T đánh giá 6.1.1 Những kết quảđạt được :

Sau quá trình thực hiện luận văn, chúng em đã đạt được những kết quả sau :

Về mặt lý thuyết

· Đạt được một số kiến thức cơ bản về cơng việc quản lý chất lượng trong việc phát triển phần mềm. · Nắm tương đối đầy đủ kiến thức về tiến trình quản lý yêu cầu và kiểm thử. · Cĩ cơ hội tiếp cận với một đơn vị sản xuất phần mềm và hiểu về cơng việc sản xuất phần mềm tại T3H. Về mặt ứng dụng

· Xây dựng được một phần mềm hỗ trợ cơng việc quản lý yêu cầu và kiểm thử, phù hợp với một đơn vị sản xuất phần mềm trên thực tế.

· Chức năng quản lý yêu cầu thoảđược các yêu cầu cần thiết cho một cơng cụ quản lý yêu cầu.

o Tạo lập yêu cầu : cho phép người dùng nhập trực tiếp các yêu cầu và đính kèm tập tin mơ tả chi tiết

o Cải tiến yêu cầu : tạo lập mối liên quan giữa yêu cầu.

o Phân tích yêu cầu : tạo lập mối liên hệ giữa yêu cầu và phân hệ từ đĩ cho phép người dùng nhận biết các phân hệ bịảnh hưởng khi yêu cầu thay đổi, theo dõi tình trạng của một yêu cầu tương ứng với các giao đoạn phát triển của một project

o Quản lý thay đổi yêu cầu : lưu lại các vết của yêu cầu khi cĩ sự

thay đổi, đảm bảo tính nhất quán của yêu cầu.

KHOA CNTT – ĐH KHTN 93 · Chức năng quản lý kiểm thử : tổ hợp nhiều chức năng của các cơng cụ kiểm thử, phù hợp với lại các yêu cầu đặt ra của T3H. o Là sự kết hợp các tính năng của ba cơng cụ : cơng cụ quản lý kiểm thử, cơng cụ quản lý hồi quy và Bug Tracking, hỗ trợ cập nhật testcase, review và fix các kết quả kiểm tra.

o Cho phép tìm kiếm một testcase, và thơng tin liên quan đến testcase đĩ.

o Cho phép tìm kiếm các thơng tin lỗi cĩ mơi trường kiểm tra tương tự nhau, từđĩ giúp người dùng cĩ thể rút ra được nguyên nhân hay cách giải quyết cho lỗi đĩ.

6.2 Hướng phát trin ca chương trình.

· Theo dõi tốt hơn mối liên quan giữa các yêu cầu, cĩ thể tựđộng quản lý mối liên hệ này.

· Cho phép người dùng chọn lại những testcase chưa được thơng qua để

xây dựng kịch bản kiểm tra cho những lần kế tiếp.

· Cho phép người dùng trao đổi tài liệu thơng qua email.

· Mở rộng ứng dụng để hỗ trợ các tiến trình phát triển khác như phân tích, thiết kế…

KHOA CNTT –

ĐH KHTN

94 Tài liệu tham khảo

[SQA]Darrel Ince, Software Quality Assurance A student introduction, MacGraw- Hill, 1995

[MSR] Dean Leffingwell and Don Widrig, Managing Software Requirements : A

usecase approach, Second Edition, Addison Wesley May 05, 2003

[PGSQM] John W. Horch, Practical Guide to Software Quality Management, Second EditionArtech House2003

[CNPMNC] T.S Trần Đan Thư, Bài giảng Tiến trình phần mềm mơn Cơng nghệ

phần mềm nâng cao 02/2004.

[LVRUP99] Đào Kim Chinh, Trần Thị Diệu, Thân Thế Cường, Huỳnh Hữu Hùng, Trần Thế Hùng, Võ Phạm Trà My, Nguyễn Thị Thu Thủy, Đồn Chí Trung, Ứng Dụng RUP trong đề án xây dựng hệ thống thơng tin tích hợp trên Web tại khoa CNTT, 2003

[INCOSE] Proceedings of the Seventh International Symposium of the INCOSE -

Volume II, August 1997

Các trang web tham khảo về các cơng cụ hỗ trợ kiểm thử :

www.segue.com http://www.testingfaqs.org/t-driver.htm#SilkPilot www.julianjones.com http://www.testingfaqs.org/t-driver.htm#Test_Manager www.qcsltd.com,http://www.testingfaqs.org/t-driver.htm#cantata www.autotester.com,http://www.testingfaqs.org/t-driver.htm#Adviser

KHOA CNTT –

ĐH KHTN

95 Phụ lục A. Mơ tả dữ liệu

KHOA CNTT –

ĐH KHTN

96

Mơ tả dữ liệu

STT Tên bảng Mơ tả

1. REQUIREMENTS Thơng tin tổng quát của yêu cầu được lập cho một đề

án.

2. REQ_DETAILS Chi tiết của một tài liệu mơ tả yêu cầu, cho biết tài liệu

đĩ gồm những yêu cầu nào.

3. REQ_RELATIONSHIP Mối liên hệ giữa một yêu cầu và phân hệ. 4. REQ_DOC Thơng tin về một tài liệu mơ tả các yêu cầu. 5. REQ_TYPE Loại yêu cầu.

6. REQUIREMENT_STATUS Tình trạng của yêu cầu đĩ, đang trong giai đoạn khảo sát, đang được phân tích, thiết kế hay coding các phần

để thoả yêu cầu đĩ. 7. HISTORY_REQ Lịch sử của một yêu cầu.

8. TEST_CASE Thơng tin một kịch bản kiểm tra. 9. TEST_CASE_FILE Thơng tin kiểm tra chung cho một file.

10. TEST_CASE_RELEASE Thơng tin mơi trường kiểm tra chung cho một internal release.

11. RELATED_TESTCASE Lưu trữ các testcase liên quan đến một testcase. 12. RAM Thơng số về kích thước RAM cần để thực hiện kiểm

tra.

13. RESOLUTION Độ phân giải màn hình cần để thực hiện kiểm tra. 14. OPERATION_SYSTEM Hệđiều hành cần thiết để chạy các testcase trong một

release.

15. DBMS Hệ quản trị cơ sở dữ liệu cần thiết để chạy các testcase trong một release.

16. COMPONENT Các component cần thiết để cĩ thể chạy một testcase. 17. RELEASE_COMPONENT Các component cần thiết để chạy các testcase trong

một release.

18. CPU Loại CPU cần để chạy các testcase trong một release. 19. STAFF Thơng tin các nhân viên trong phịng.

20. STAFF_ROLE Vai trị nhân viên trong một đề án. 21. ROLE Các vai trị trong một đề án 22. ROLE_FUNCTION Chức năng của một vai trị.

23. FUNCTION_LIST Các chức năng của các thành viên trong hệ thống :

được phép check in, check out... (liên quan đến các chức năng hệ thống)

24. FUNCTION_GROUP Nhĩm các chức năng của các thành viên. 25. DIRECTORY Thơng tin của thư mục

26. RUNNING_STATE Tình trạng của một project : đang khảo sát, phân tích thiết kế, …

27. WORKING_DIRECTORY Chứa cây thư mục để check out của mỗi nhân viên 28. ACTION_DIRECTORY Lưu trữ các thao tác tác động lên thư mục

29. ACTION_TYPE Các lọai chức năng (add, check in, check out, label, remove…)

30. ACTION_VERSION_FILE Lưu trữ các thao tác tác động lên file

31. LABEL_VERSION_FILE Ghi nhận việc gán nhãn của người dùng cho một version file nào đĩ

KHOA CNTT –

ĐH KHTN

97

33. VERSION_FILE Lưu trữ các thơng tin của một version file (version này dựa vào version của CVS)

34. FILE_INFO Lưu thơng tin về File 35. FILE_TYPE Loạii File (Tex/binary)

36. RELATIONSHIP Mối liên hệ giữa hai version file với nhau 37. TYPE_RELATIONSHIP Các lọai ảnh hưởng giữa mối quan hệ của các

thành phần (references, link)

38. CONTENT_FILES Lưu trữ sự thay đổi về mối quan hệ giữa Thư mục và file

39. CONSTRUCTION Bảng lưu mối quan hệ của các thư mục với nhau 40. DIRECTORY_TYPE Loại thư mục: Project, thư mục, phân hệ, chức năng 41. FUNCTION_VERSION_FILE Lưu trữ mối liên hệ giữa các phân hệ/ chức năng với

file.

42. ACCESS_STATE Tình trạng truy cập của một thành phần : Normal, Check in, check out, dissynchronize

KHOA CNTT – ĐH KHTN 98 ! symbol indicates explanation available or question requires explanation Analyst Studio (RequisitePro) v2002 Calibe r RM

3.0 C.A.R.E. 3.0 Catalyze 1.0 CORE 4.0 Cradle 4.0 DOORS 6.0

QSS requireit

1.0 Envision 5.4.2 IRqA 2.1 RMTrak 5.0.4 Trace 2.1 Team Tracer 4.1 RDT 1.0 RTM 4.x SLATE 6.1 SpeeDev 3.5

Systems Engineer

2 Tofs 98 Vital Link XTie-RT

Response Date March 2002 May. 2002 June 2002 April 2002 March 2002 2002Dec. March 2002 1999May April 2000 2002Dec. April 2002 June 2002 Nov. 2000 2002Dec. 1999June June. 2002 2002Dec. Jan. 2000 July 1998 1997Jan. July 1998 1. Capturing Requirements/Iden tification 1.1. Input document enrichment / analysis

Full Full Full Full Full Full Full Full Full Full Full None Full Full Full Part. None None Full None

1.1.1. Input document change / comparison analysis

Full Full Full Full Full Full Full None Full Full Full Part. Full Full Full Full Full None None Part. None

1.2. Automatic parsing of

requirements Full Full Full Part. Full Full Full Full Full Full Full Full Full Full Full Full Full None None Full Full

1.3.

Interactive/semi- automatic requirement identification

Full Full Full Full Full Full Full Part. Full Part Full Full Full Full Full Part. None None Part. Full Full

1.4. Manual requirement

identification Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Part. Full Full Full

1.5. Batch mode

operation Full Full Full Full Full Full Full None Full Full ! Full Part. Full Full Part. Full None Part. None Full

1.5.1. Batch-mode document/source-

link update Full Full Full Full Full Full Full Full Full Full Full None Full Full Full Part. Full None Part. None

1.6. Requirement

classification Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

2. Capturing system element structure Full 2.1. Graphically capture systems

structure Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full None Full None Full

2.2. Textual capture of systems

structure Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

3. Requirements

KHOA CNTT – ĐH KHTN 99 req, req. to analysis/text) 3.2. Allocation of performance requirements to system elements (weight, risk, cost, etc.)

Full Full Full Full Full Full Full Full Full Full Full Part. Full Full Part. Full Full Full Full Part. Full

3.3. Bi-directional requirement linking to system

elements

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full None Full Full Full

3.4. Capture of allocation rationale, accountability, test/validation, criticality, issues, etc. -- if so, how and what

mechanism does it use.

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

4. Traceability analysis ! 4.1. Identify inconsistencies (orphans,...if so, what kind of...)

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

4.2. Visibility into existing links from source to

implementation-- i.e. follow the links.

Full Full Full Full Full Full Full Full Full Part Full Full Full Full Full Full Full Full Full Full Full

4.3. Verification of requirement (was it done, how was done)

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

4.4. Requirement performance verification from system elements (roll up of actuals)

Part. Part. Part. Part. Full Full Full None Full Part Part. Full Part. Full Full Full Full Part. Part. None None

5. Configuration Management 5.1. History of requirement changes, who, what, when, where, why, how.

KHOA CNTT – ĐH KHTN 100 control 5.3. Access control (modification,

viewing, etc.) Part. Full Full Part. Full Full Full Full Full Full Part Full Part. Full Full Full Full Full Part. Full Full

6. Documents and

other output media

6.1. Standard specification output (if so, what kind)

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Part. Full Full Full

6.2. Quality and consistency checking (spell, data dictionary, )

Full Full Full Full Full Full Full Full Full Part Full Part. Full Full Full Full Part Part. Full Full Part

6.3. Presentation

output Full Part. Full Full Full Full Full Full Full Part Full Full Full Full Full Part. Full None Part. Full Full

6.4. Custom output features &

markings

(definable tables, security marking)

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Part. Part. Full Full

6.5. WYSIWYG previewing of

finished output Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

6.6. Status

reporting Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Part. Full Part. Full

6.6.1. Technical Performance Measurement status accounting

Full Full Full Part. Full Full Full Full Full Full Part. Full Part. Full Full Full Full Part. Full Part. Full

6.6.2. Requirement progress/status reporting

Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full

6.6.3. Other ad hoc queries and

searches Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Full Part. Full Full

6.7. Support and display special

character sets. Full Full Full Full Full Full Full None

7. Groupware Full Full ! ! ! !

7.1. Support of concurrent review, markup, and comment

Full Full Full Full Full Full Full Part. Full Full Part. Full Part. Full Full Full Full None Full Full Full

Một phần của tài liệu Luận văn: Tìm hiểu quy trình 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 Đại học Khoa học Tự nhiên. doc (Trang 90 - 105)

Tải bản đầy đủ (PDF)

(105 trang)