1.1 Phân biệt các khái niệm Kiểm thử và Đánh giá các yêu cầu phần mềm
Trả lời:
* Kiểm thử các yêu cầu phần mềm (Testing): Việc kiểm thử yêu cầu phần mềm nhằm xác định các yêu cầu có đáp ứng được các yêu cầu của người sử dụng không. Công việc được thực hiện như sau:
· Viết các trường hợp kiểm thử cho các yêu cầu.
· Sử dụng mô hình hộp đen từ các trường hợp kiểm thử để đánh giá họat động hành vi của hệ thống.
· Duyệt các hành vi và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng yêu cầu của người sử dụng hay không.
Quy trình kiểm thử:
•Business Requirement
•Use Case
•Functional Requirement
Các công cụ sử dụng:
•Dialog Map
•Test Case
•Ma trận theo dõi các trường hợp sửdụng
* Đánh giá các yêu cầu phần mềm
Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.
Cụ thể việc đánh dựa vào các đặc điểm sau:
a. Các đặc điểm đối với từng yêu cầu phần mềm tốt.
a. Đầy đủ ( complete )
b. Chính xác (Correct)
c. Khả thi ( feasible)
d. Cần thiét ( necessary).)
e. Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)
f. Rõ ràng.
g. Có thể kiểm tra được (Verifiable)
b. Các đặc điểm của một tài liệu đặc tả phần mềm tốt.
a. Đầy đủ.
b. Có thể sửa đổi (Modifiable)
c. Có thể thể theo dõi được (Traceable)
d. Thống nhất ( consistent)
(Có thể trả lời theo đặc tính chất lượng).
1.2Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm. Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết.
Trả lời:
Việc kiểm thử đánh giá các yêu cầu phần mềm là cần thiết bởi vì qua việc kiểm thử đánh giá, chúng ta mới có thể thẩm định được tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm mà chúng ta đã miêu tả trong SRS. Các yêu cầu đó phải đúng là những yêu cầu từ khách hàng, giải quyết được các công việc của họ.
Một số phương pháp kiểm thử yêu cầu phần mềm thông dụng:
- Kiểm thử hộp đen
- Kiểm thử hộp trắng
1.3Nêu các phương pháp xem xét lại yêu cầu phần mềm. Những tác nhân nào tham gia vào xem xét lại yêu cầu phần mềm
Trả lời:
· Quy trình xem xét:
o Lập kế hoạch
o Các buổi họp mặt
o Chuẩn bị
o Các buổi họp duyệt
o Làm sửa đổi
o Kết thúc
· Công cụ sử dụng, mẫu sử dụng
o Các tiêu thức đánh giá
o Requirement Inspection Checklist
· Các tác nhân tham gia vào quá trình duyệt các yêu cầu phần mềm (review):
o Các PTV – Phát Triển Viên
o Các đại diện của NSD (Product champions)
o Tất cả các thành viên của Cty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm: LTV, các nhà kiểm thử…
1.4Phân tích các nguyên nhân dẫn tới thay đổi yêu cầu phần mềm
Tác động bên ngoài
ü có thay đổi đòi hỏi chúng ta phải giải quyết bài toán mới
ü người dùng thay đổi ý kiến của họ
ü môi trường ngoài thay đổi
ü một hệ thống mới tồn tại trong đó
Tác động bên trong
ü Thất bại trong việc lấy yêu cầu từ người dùng ( chưa lấy đầy đủ yêu cầu từ nhiều người dùng)
ü Thất bại trong việc tạo một quy trình thực hành giúp quản lý sự thay đổi yêu cầu phần mềm
1.5Nêu vai trò phương pháp prototyping trong duyệt và kiểm soát yêu cầu phần mềm
Trả lời:
Vai trò:
Phương pháp Prototyping có vai trò trong duyệt và kiểm soát yêu cầu phần mềm giúp hoàn thiện hơn về yêu cầu, đáp ứng được yêu cầu của người dùng
Cho người dùng dùng thử mẫu thử như là mẫu thử bản beta từ đó người dùng sẽ dùng thử và đưa ra những điểm tốt , điểm không tốt của mẫu thử, cái nào không cần thiết của mẫu thử từ đó người phân tích viên có thể duyệt yêu cầu nào đã đạt được yêu cầu nào hay những yêu cầu nào rườm ra có thể bỏ qua hay nên bổ sung những yêu cầu gì để thỏa mãn được yêu cầu của người dùng
Ví dụ: khi cho người dùng delete một bản ghi thì đòi hỏi phải có yêu cầu là có nên delete hay không?
Mẫu thử cho thẩm định yêu cầu giải thích các yêu cầu và giúp các bên liên quan khám phá được vấn đề
Thẩm định mẫu thử sẽ hoàn thành có hiệu quả cao và thiết thực. nó có thể dụng chúng trong cách giống nhau như là yêu cầu hệ thống
Tài liệu đào tạo cho người sử dụng sẽ được cung cấp
1.6Nêu kỹ thuật duyệt mô hình hệ thống của các yêu cầu phần mềm. Các nội dung cần duyệt trong đánh giá mô hình
Trả lời:
Thẩm định mô hình hệ thống là một yêu tố cần thiết trong quá trình thẩm định
Có thể kiểm tra với một số công cụ tự động
Những giải thích về mô hình là một kỹ thuật kiểm tra có hiệu quả (kết quả)
Thành phần của mô hình hệ thống:
üĐể giải thích mỗi mô hình là phù hợp
üNếu có một vài mô hình của hệ thống để giải thích những sự phù hợp bên trong và bên ngoài.
üĐể giải thích rằng các mô hình có tính chính xác với các yêu cầu thực của những bên liên quan đến hệ thống. đây là một việc rất khó khăn.
1.7Vai trò của kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm
1.8Các kỹ thuật kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm
Trả lời:
Các kỹ thuật kiểm thử chấp nhận:
- Phát hiện lỗi: Các chương trình được thực hiện và kết quả là thứ cần kiểm tra. Nếu kết quả đúng, tiếp tục thực hiện bình thường. Một kiểm tra thất bại là triệu chứng của một lỗi. Kiểm thử chấp nhận hiệu quả nhất nếu nó được dựa trên các tiêu chí độc lập với chức năng đang được thử nghiệm và có thể tính toán một cách đơn giản để biết trước kết quả.
- Chẩn đoán lỗi: Kiểm thử chấp nhận không dùng để xác định cái gì đã sai. Nó chỉ có thể nói rằng có cái gì đó đã sai
- Ngăn chặn lỗi: Kiểm thử chấp nhận tạo ra rào cản không cho lỗi lan rộng.
- Che giấu lỗi: Kiểm thử chấp nhận che giấu một giá trị xấu nếu kết quả thử lại hoặc thay thế chính xác trong thời gian quy định trước khi tuyên bố thất bại
- Bồi thường lỗi: Nếu một chương trình thất bại trong kiểm thử chấp nhận có thể thay thế bằng một trường hợp dự phòng. Nếu trường hợp dự phòng thành công, có thể sử dụng đề bù đắp cho trường hợp ban đầu
- Sửa lỗi:
-
1.9Các chức năng cơ bản của EA hỗ trợ người dùng trong duyệt và kiểm soát yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
EA hỗ trợ tính năng theo dõi thay đổi định nghĩa yêu cầu. Chúng bao gồm kiểm toán, quản lý đường cơ sở, yêu cầu thay đổi thành phần và vấn đề khai thác
Kiểm toán:
Các tính năng kiểm toán cho phép bạn ghi lại những thay đổi mô hình trong EA. Nó ghi chi tiết của người thay đổi một yếu tố, khi nào và những gì đã được thay đổi, cùng với tình trạng trước của mô hình. Điều này có thể đặc biệt hữu ích để ghi lại lịch sử các thay đổi cho mô hình yêu cầu.
Để kích hoạt tính năng này:
1. Từ menu chính bạn chọn: View | Other Project Tools | Audit View,sẽ mở ra:
2. Bạn chọn Audit Settings
3. Nó sẽ mở ra cửa sổ Audit Settings :
4. Trong cửa sổ Audit Settings bạn thiết lập kích hoạt tính năng kiểm toán như hình vẽ trên.
Ví dụ dưới đây có Element List xem các tùy chọn thiết lập.cửa sổ Output | Audit History cho thấydanh sách các thay đổi cho các phần tử được lựa chọn:
Lịch sử đầy những thay đổi có thể xem được bằng cách loại phần tử bằng cách sử dụng Audit View:
Để biết thêm thông tin về cách sử dụng tính năng kiểm toán xem trợ giúp của EA :Projects and
Teams | Change Management | Tracking Changes | Auditing
Sử dụng đường cơ sở:
Các tính năng kiểm toán nêu trên, cung cấp liên tục theo dõi và ghi các thay đổi yêu cầu. tính năngBaseline Management hỗ trợ thêm để so sánh vàsáp nhập thay đổi. Nó cho phép đường cơ sở của một mô hình được tạo ra trên cơ sở định kỳ (nghĩa là theo tháng, phiên bản, giai đoạn hoặc xây dựng). Đường cơ sở đó có thể được so sánh với mô hình nhà nước hiện hành và thay đổi lựa chọn kết hợp.
Để biết thêm thông tin về thiết lập đường cơ sở và xem sự khác biệt xem phần trợ giúp:
Projects and Teams | Change Management | Tracking Changes | Package Baselines
Thay đổi yêu cầu và các vấn đề về yêu cầu ngoại
ea hỗ trợ đăng nhập của biến đổi, yêu cầu đối với yêu cầu. Điều này có thể được xác định
sử dụng hai phương pháp khác nhau:
-Dùng Maintenance View để thay đổi danh sách, khiếm khuyết, vấn đề và nhiệm vụ chống lại mỗi phần tử.
-Sử dụng các yếu tố tùy thuộc loại "Issue " và "Change " liên kết với các yêu cầu ngoài
được thay đổi.
Mỗi cái đã sử dụng khác nhau được liệt kê như sau:
a.Sử dụng các Xem Bảo trì:
có thể được sử dụng để đăng nhập thay đổi đối với bất cứ phần tử hoặc trọn gói. Điều này cung cấpdanh sách cho:
o Element khiếm khuyết
o Thay đổi Element
o Các vấn đề Element
o Element Nhiệm vụ
Chúng bao gồm các lĩnh vực để ghi âm "by whom and when " yêu cầu đã được thực hiện và hoàn thành, cũnglà trạng, mô tả, ưu tiên và lịch sử.
Maintenance View có thể được truy cập từ trình đơn chính bằng cách sử dụng:View | Other Element Tools |Maintenance or (Alt+4) . Hình sau đây là một ví dụ của một tập hợp các thay đổi được liệt kê cho một phần tử:
Việc sử dụng chung cho quản lý yêu cầu là để đăng nhập chi tiết Yêu cầu-vấn đề và thay đổi-Yêu cầu đối với bất kỳ yếu tố yêu cầu hiện có.
b)Sử dụng các yếu tố bảo trì cho Thay đổi và các vấn đề
các yếu tố bảo dưỡng của EA bao gồm các yếu tố của loại Issue và Change.Đây là những truy cập từ Toolbox | Maintenance hoặc Toolbox | Custom
Bảo trì các yếu tố có thể được liên kết bằng cách sử dụng một kết nối đến bất kỳ yếu tố (nghĩa là một yêu cầu đối ngoại) để hiển thị một sự thay đổi hay vấn đề một.
Nghe
Đọc ngữ âm
Từ điển - Xem từ điển chi tiết
Lời khuyên:
-Những yếu tố có thể được lưu trữ trong gói có chứa các yêu cầu liên quan hoặc trong mộtriêng gói có chứa một bộ các thay đổi.
-Chúng có thể được liên kết với yêu cầu yếu tố trong biểu đồ thông thường hoặc bằng cách sử dụng các mối quan hệMa trận.
-Những yếu tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.
Sơ đồ sau đây minh họa việc sử dụng một phần tử hành liên kết với một yêu cầu.
Nghe
Đọc ngữ âm
Từ điển - Xem từ điển chi tiết
Nghe
Đọc ngữ âm
Từ điển - Xem từ điển chi tiết
Nghe
Đọc ngữ âm
Từ điển - Xem từ điển chi tiết
Dưới đây là cùng một dữ liệu xem trong Element List xem cùng với Relationship cửa sổ hiển thị các yếu tố liên quan đến việc phát hành lựa chọn:
1.10 Kiểm thử (testing) yêu cầu phần mềm
Trả lời:
Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội ngũ phát triển phần mềm.
Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần mềm, ảnh hưởng đến kiến trúc hệ thống.
Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên là người sử dụng và người phát triển hệ thống.
Tại sao phải kiểm thử yêu cầu phần mềm:
- Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.
- Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm
- NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập trình viên
- NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách nhiệm làm rõ các yêu cầu này.
- Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết
- Kiểm tra khả năng đáp ứng về mặt kỹ thuật
- Đặc tả rõ ràng và chi tiết các yêu cầu
Tiêu chí kiểm thử yêu cầu phần mềm
- Hoàn thiện
- Chính xác
- Khả thi
- Cần thiết
- Rõ ràng
- Kiểm tra được, xác minh được
Quy trình kiểm thử yêu cầu phần mềm:
· Bussiness Requirement
· Use Case
· Functional Requirement
Các công cụ sử dụng:
· Dialog Map
· Test Case
· Ma trận theo dõi các trường hợp sử dụng
Bạn đang đọc truyện trên: Truyen2U.Pro