Slide Nhóm 11

Mn vào cmt để nhận quà của nhóm 11 nào !
http://www.mediafire.com/download/54iadvbatt3hvk9/Nh%C3%B3m+11_KTPM1K8_Demo.ppt
//Các bạn click vào "SKIP AD" ở góc trên cùng bên phải để hiện ra link download nhé !

Các bạn có thể nói rõ hơn cho tớ về Kiểm thử Alpha, Beta là ai kiểm thử và kiểm thử trong môi trường nào (trong slide có nói đến bối cảnh tự nhiên là bối cảnh như thế nào). tớ cảm ơn!

mình xin trả lời câu hỏi của bạn Huệ:
- KT Alpha:là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm(trong môi trường nhà phát triển). là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.
-Vì nó trong phạm vi nội bộ nên khi đóng vai người dùng cần phải bỏ tư duy của người thiết kế và đặt mình trong bối cảnh tự nhiên( chính là bối cảnh của người dùng) để sử dụng sản phẩm có thế mới phát hiện lỗi một cách khách quan hơn.

-KT Beta được đưa ra sau khi kiểm thử Alpha và có thể được coi là một hình thức mở rộng của kiểm thử mức chấp nhận của người dùng. Phần mềm được phát hành cho nhiều nhóm người dùng(chủ yếu là khách hàng tiềm năng) để nhận lại sự phản hồi lỗi.phần mềm được kiểm thử trong môi trường của người sử dụng để đảm bảo sản phẩm có ít thiếu sót và lỗi. Đôi khi, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi thông tin từ một số lượng tối ta người dùng trong tương lai.
Nguồn:https://vi.wikipedia.org/wiki/Kiểm_thử_phần_mềm.

nhóm c làm rõ hơn 4 loại hình kiểm thử hôn t nhé , thanks....!!!

Mình có 1 lời khen cho nhóm bạn là slide rất đẹp và ít chữ kết hợp hình và chữ hợp lý ==> very good

MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

câu hỏi và nhận xét trên là của quỳnh nhé hihi tớ đăng nhập nhầm nic vân anh

anh maya đã viết:MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

theo tớ hiểu: vì 1 hệ thống có nhiều dev, Ví dụ mỗi dev code 1 funtion, khi kiểm thử funtion của mỗi dev thì chắc chắn là không xảy ra lỗi và đúng với yêu cầu. Nhưng đến khi tích hợp thành hệ thống thì có thể funtion này mâu thuẫn với funtion kia, dẫn đến có nguy cơ đổ lỗi cho nhau

thúy Hằng đã viết: nhóm c làm rõ hơn 4 loại hình kiểm thử hôn t nhé , thanks....!!!

Theo tớ hiểu:
1. Kiểm thử đơn vị (unit testing): test chức năng của một phần riêng biệt của code, thường ở mức hàm (function level) và do Developer thực hiện
2. Kiểm thử tích hợp (integration testing): test việc tích hợp các hàm, các module (chưa hoàn chỉnh) lại với nhau Hoặc các hàm các modul đã hoàn chỉnh lại với nhau xem có thực hiện đúng theo yêu cầu đặc tả ko. thường do Tester thực hiện.
VD: 2 dev cùng code 1 phần mềm, mỗi người code một modul, Khi tích hợp và tester kiểm thử thấy lỗi, 2 dev đều chắc chắn modul của mình không có lỗi nhưng chắc gì khi tích hợp 2 modul đó lại không có lỗi.
3. Kiểm thử hệ thống (system test): kiểm thử một hệ thống đã được tích hợp hoàn chỉnh giữa các module hoặc giữa các hệ thống để xác minh rằng nó đáp ứng được yêu cầu. Được thực hiện bởi tester.
4. Kiểm thử chấp nhận (acceptance testing): kiểm thử trong môi trường của khách hàng, được khách hàng thực hiện.

bạn Hằng nhé:
Trên slide bọn mình cũng đã thể hiện khá đầy đủ,và bạn Huệ cũng đã giải thích giúp nhóm mình.
mình xin trả lời thế này:
-Kiểm thử đơn vị
Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng. Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau.

Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro, thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm. kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng. Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung.

Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.

-Kiểm thử tích hợp
Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau ("Big Bang"). Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn.

Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp (Modules). Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.

-Kiểm thử hệ thống
Kiểm thử hệ thống giúp xác minh rằng một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không. Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình).

-Kiểm thử mức chấp nhận
Cuối cùng hệ thống được giao cho người dùng để kiểm thử mức chấp nhận.
Nguồn:https://vi.wikipedia.org/wiki/Kiểm_thử_phần_mềm

anh maya đã viết:MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

mình xin trả lời câu của bạn Hương Quỳnh:
Trong KT đơn vị và KT tích hợp thì KT được thống nhất ở 1 nhóm KT phát hiện các sai sót về đặc tả hay giao diện giữa các modun.
Còn trong KT hệ thống người ta lại chia thành các nhóm độc lập.
-nhóm KT phục hồi: KT khả năng phục hồi lỗi sau khi tiến hành gây lỗi cho PM.
-nhóm KT áp lực: KT khả năng chịu tải,tính an toàn.
-nhóm KT an ninh: KT tính đúng đắn,phát hiện lỗ hổng có nguy cơ bị tấn công của PM.
-nhóm KT so sánh:KT độ tin cậy của PM( đặc biệt với PM cần độ chính xác cao như máy bay, lò hạt nhân)
Vì các nhóm KT riêng rẽ về 1 mảng khác nhau, mà đây là Khâu KT quyết định tính hoàn thiện của PM để đi đến KT chấp nhận
Nên khi sang KT chấp nhận mà phát hiện ra lỗi thì việc đổ lỗi cho nhau giữa các nhóm trong KT hệ thống là rất dễ xảy ra.

Slide 11 có nêu đến 2 hướng tích hợp là tích hợp dần và tích hợp đồng thời một lúc "BigBang".Các bạn hãy nêu ưu nhược điểm cuả từng hướng.

Cao Văn An đã viết:Slide 11 có nêu đến 2 hướng tích hợp là tích hợp dần và tích hợp đồng thời một lúc "BigBang".Các bạn hãy nêu ưu nhược điểm cuả từng hướng.

cám ơn bạn.bạn có câu hỏi rất hay
Mình xin trả lời câu này:
Trong KT tích hợp có 2 hướng tiếp cận
1.tích hợp dần dần với 3 chiến lược:
+từ dưới lên
+Từ trên xuống
+Kết hợp cả 2

- từ dưới lên:từ modun mức thấp
+ƯĐ:
>tránh tạo các cuống phức tạp hay kết quả nhân tạo :Do tích hợp từ dưới lên nên nên chỉ cần tạo ra các bộ lái, vì các modun mức dưới đã được KT.
>có thể dùng lại các modun thứ cấp
+NĐ:
>phát hiện lỗi thiết kế chậm:các lỗi tổng thể như sai chức năng hay hệ thống kém hiệu quả bị phát hiện muộn->chi phí và thời gian sửa lỗi tăng cao.
>chậm có phiên bản của hệ thống thực hiện được:Do các modun mức trên được phát triển sau và tích hợp sau cùng nên chậm có phiên bản thực hiện.có thể còn kiến khách hàng mất niềm tin vì không được thử nghiệm sớm.(vd:thiết kế trang web)
-Từ trên xuống:bắt đầu từ modun mức cao
+ƯĐ:
>phát hiện sớm các lỗi TK:như phát triển nhầm,thiếu chức năng như đã đặc tả->giảm chi phí cho TK và cài đặt lại.
>Có phiên bản hoạt động sớm->có thể thẩm định tính dùng được của sản phẩm và huấn luyện người dùng.
+NĐ:
>Nếu các chức năng mức thấp quá phức tạp thì rất khó để mô phỏng(khó tạo cuống)->không thể KT đầy đủ các chức năng của modun.
ngoài ra còn có KT  kết hợp 2 chiến lược trên. và KT quay lui.
2.Tích hợp đồng thời "big bang"
+ƯĐ:
>chỉ tích hợp 1 lần duy nhất để được hệ thống hoàn chỉnh->không tốn nhiều thời gian công sức,và chi phí sửa lỗi.
>phù hợp cho việc phát triển các PM có kích thước nhỏ.
>sớm phát hiện lỗi, có phiên bản sớm.
+NĐ:
>Không phù hợp với PM lớn->vì rất khó định vị chính xác modun nào hay vị trí nào bị lỗi.
Nguồn từ:Quyển Kỹ nghệ phần mềm(vàng)

anh maya đã viết:Mình có 1 lời khen cho nhóm bạn là slide rất đẹp và ít chữ kết hợp hình và chữ hợp lý ==> very good

Lê Huệ đã viết:

anh maya đã viết:MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

theo tớ hiểu: vì 1 hệ thống có nhiều dev, Ví dụ mỗi dev code 1 funtion, khi kiểm thử funtion của mỗi dev thì chắc chắn là không xảy ra lỗi và đúng với yêu cầu. Nhưng đến khi tích hợp thành hệ thống thì có thể funtion này mâu thuẫn với funtion kia, dẫn đến có nguy cơ đổ lỗi cho nhau

theo mình thì:
kiểm thử hệ thống dễ gây đổ lỗi cho nhau vì:
System test chú trọng các hành vi và lỗi trên toàn hệ thống và kiểm thử cả các hành vi chức năng phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Thường được thực hiện bởi 1 nhóm kiểm thử viên.
Bản thân lại gồm nhiều loại kiểm thử khác nhau như: kiểm thử chức năng, hiệu năng, khả năng chịu tải, cấu hình, bảo mật, khả năng phục hồi...

oanhoanh đã viết:

Lê Huệ đã viết:

anh maya đã viết:MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

theo tớ hiểu: vì 1 hệ thống có nhiều dev, Ví dụ mỗi dev code 1 funtion, khi kiểm thử funtion của mỗi dev thì chắc chắn là không xảy ra lỗi và đúng với yêu cầu. Nhưng đến khi tích hợp thành hệ thống thì có thể funtion này mâu thuẫn với funtion kia, dẫn đến có nguy cơ đổ lỗi cho nhau

theo mình thì:
kiểm thử hệ thống dễ gây đổ lỗi cho nhau vì:
System test chú trọng các hành vi và lỗi trên toàn hệ thống và kiểm thử cả các hành vi chức năng phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Thường được thực hiện bởi 1 nhóm kiểm thử viên.
Bản thân lại gồm nhiều loại kiểm thử khác nhau như: kiểm thử chức năng, hiệu năng, khả năng chịu tải, cấu hình, bảo mật, khả năng phục hồi...

Bạn có thể giải thích thêm giúp mình được không, câu trả lời của bạn mình thấy nó chưa đúng với câu hỏi cho lắm

Lê Huệ đã viết:

oanhoanh đã viết:

Lê Huệ đã viết:

anh maya đã viết:MÌnh có 1 câu hỏi đó là: Phân tích giúp mình "Việc kiểm thử hệ thống dễ có nguy cơ đổ lỗi cho nhau" có nghĩa là ntn?

theo tớ hiểu: vì 1 hệ thống có nhiều dev, Ví dụ mỗi dev code 1 funtion, khi kiểm thử funtion của mỗi dev thì chắc chắn là không xảy ra lỗi và đúng với yêu cầu. Nhưng đến khi tích hợp thành hệ thống thì có thể funtion này mâu thuẫn với funtion kia, dẫn đến có nguy cơ đổ lỗi cho nhau

theo mình thì:
kiểm thử hệ thống dễ gây đổ lỗi cho nhau vì:
System test chú trọng các hành vi và lỗi trên toàn hệ thống và kiểm thử cả các hành vi chức năng phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Thường được thực hiện bởi 1 nhóm kiểm thử viên.
Bản thân lại gồm nhiều loại kiểm thử khác nhau như: kiểm thử chức năng, hiệu năng, khả năng chịu tải, cấu hình, bảo mật, khả năng phục hồi...

Bạn có thể giải thích thêm giúp mình được không, câu trả lời của bạn mình thấy nó chưa đúng với câu hỏi cho lắm

Việc kiểm thử hệ thống gồm:
Kiểm thử phục hồi
Kiểm thử áp lực
Kiểm thử hiệu năng
Kiểm thử an ninh
Kiểm thử so sánh
Các kiểm thử này thực hiện với các phiên bản độc lập và liên tiếp với nhau, vì vậy khi xẩy ra lỗi ở 1 bước nào đó mà lỗi được bỏ qua và tới bước khác mà không lưu trữ lại dẫn đến lỗi toàn hệ thống và không biết bước nào sai sót dẫn đến việc đổ lỗi cho nhau...

Ở slide 15/18 có nói đến việc: Việc KTHT dễ có nguy cơ “đổ lỗi cho nhau”. Nhóm bạn hãy giải thịk rõ vấn đề này giúp mink.

Bạn có thể làm rõ cho mình về Các chiến lược: KT phục hồi, KT an ninh, KT áp lực, KT thi hành.
=))

Cao Văn An đã viết:Ở slide 15/18 có nói đến việc: Việc KTHT dễ có nguy cơ “đổ lỗi cho nhau”. Nhóm bạn hãy giải thịk rõ vấn đề này giúp mink.

câu này bạn Hương Quỳnh cũng đã hỏi mình sẽ trả lời lại:
Trong KT đơn vị và KT tích hợp thì KT được thống nhất ở 1 nhóm KT phát hiện các sai sót về đặc tả hay giao diện giữa các modun.
Còn trong KT hệ thống người ta lại chia thành các nhóm độc lập.
-nhóm KT phục hồi: KT khả năng phục hồi lỗi sau khi tiến hành gây lỗi cho PM.
-nhóm KT áp lực: KT khả năng chịu tải,tính an toàn.
-nhóm KT an ninh: KT tính đúng đắn,phát hiện lỗ hổng có nguy cơ bị tấn công của PM.
-nhóm KT so sánh:KT độ tin cậy của PM( đặc biệt với PM cần độ chính xác cao như máy bay, lò hạt nhân)
Vì các nhóm KT riêng rẽ về 1 mảng khác nhau, mà đây là Khâu KT quyết định tính hoàn thiện của PM để đi đến KT chấp nhận
Nên khi sang KT chấp nhận mà phát hiện ra lỗi thì việc đổ lỗi cho nhau giữa các nhóm trong KT hệ thống là rất dễ xảy ra.

trong bài có nói đến bối cảnh tự nhiên là bối cảnh như thế nào???

bạn cho mình hỏi trong slide số 11, phần kiểm thử tích hợp (tiếp) bạn có suy ra 2 hướng tích hợp chương trình , bạn giúp mình làm rõ tích hợp đồng thời 1 lúc: "Big Bang" là như thế nào không?

Thành Nam đã viết:Bạn có thể làm rõ cho mình về Các chiến lược: KT phục hồi, KT an ninh, KT áp lực, KT thi hành.
=))

Mình xin trả lời câu của bạn:
Trong KT hệ thống người ta chia thành các nhóm KT độc lập.
- KT phục hồi:
+ KT khả năng phục hồi lỗi sau khi tiến hành gây lỗi cho PM.
- KT áp lực:
+ KT khả năng chịu tải (dữ liệu lớn,số người sử dụng nhiều,tài nguyên hạn chế) của PM,
+Phát hiện một số điều kiện dễ dẫn đến sụp đổ hệ thống và tính an toàn của của dữ liệu,dịch vụ khi hệ thống sụp đổ.
- KT an ninh:
+KT tính đúng đắn và phát hiện những lỗ hổng có nguy cơ bị tấn công của PM.
-KT thi hành:
+KT hiệu suất hoạt động của PM sau khi tích hợp với các PM khác( như hệ điều hành ,cơ sở dữ liệu)và phần cứng(như CPU,Bộ nhớ,mạng).
-Ngoài ra còn có KT so sánh:+KT độ tin cậy của PM( đặc biệt với PM cần độ chính xác cao như máy bay, lò hạt nhân).

vuductuan95 đã viết:trong bài có nói đến bối cảnh tự nhiên là bối cảnh như thế nào???

Mình xin trả lời câu hỏi của bạn:
-Trong KT Alpha việc KT được thực hiện tại nơi sản xuất PM để chấp nhận nội bộ, trước khi PM được tiến hành kiểm thử beta.
-Vì nó trong phạm vi nội bộ nên khi người Thiết kế đóng vai người dùng cần phải bỏ tư duy của người thiết kế và đặt mình trong bối cảnh tự nhiên để sử dụng sản phẩm để phát hiện lỗi một cách khách quan hơn.
->Bối cảnh tự nhiên ở đây chính là bối cảnh của người dùng PM.

minhphuong đã viết:bạn cho mình hỏi trong slide số 11,  phần kiểm thử tích hợp (tiếp) bạn có suy ra 2 hướng tích hợp chương trình , bạn giúp mình làm rõ tích hợp đồng thời 1 lúc: "Big Bang" là như thế nào không?

Mình xin trả lời câu hỏi của bạn:
KT "Big Bang" còn gọi là KT vụ nổ lớn: là chiến lược KT tích hợp hệ thống 1 lần duy nhất để được modun chức năng( hay hệ thống) hoàn chỉnh.
Nó có Ưu điểm:
--chỉ tích hợp 1 lần duy nhất để được hệ thống hoàn chỉnh->không tốn nhiều thời gian công sức,và chi phí sửa lỗi.
--phù hợp cho việc phát triển các PM có kích thước nhỏ.
--sớm phát hiện lỗi, có phiên bản sớm.
 Tuy nhiên KT này không phù hợp với PM lớn->vì nếu có lỗi sẽ rất khó định vị chính xác modun nào hay vị trí nào gây lỗi.