4 Người Bạn - Nhóm 4 Người Bạn

Đề tài: Tìm hiểu Bug Tracker
Nội dung trình bày:
 Tổng quan:
 Một số công cụ quản lý Bug:
◦ Công cụ Bugzilla
◦ Công cụ BugTracker.Net
◦ Công cụ Mantis BugTracker
 Demo
1. Công cụ Bugzilla:
1.1 Giới thiệu:
Chương trình Bugzilla là một hệ thống quản lý bug miễn phí và rất thông dụng hiện nay. Giao diện của Bugzilla có thể tùy biến được, dễ cấu hình và có thể cho phép nhiều user cùng sử dụng cùng lúc. Có thể thêm, xóa, sửa các thông tin do Bugzilla quản lý như thông tin dự án, thông tin màn hình, thông tin các nhân của user kể cả email nhận thông báo.
1.3 Quy trình quản lý Bug:
Các trạng thái của Bug:
◦ NEW
◦ ASSIGNED
◦ RESOLVED
◦ REOPEN
◦ VERIFIED
◦ CLOSED
ASSIGNED:
 Trạng thái này là bug được phân công cho DEV nào đó fix, lúc này bug vẫn chưa được fix.
 Từ trạng thái này, bug có thể được chuyển sang trạng thái NEW (chuyển cho người khác fix bug) hoặc RESOLVED (đã fix xong bug).
VERIFIED
 Trạng thái này là TESTER đã test lại xong và xác nhận bug này đã được fix. (trong trường hợp TESTER không có quyền đóng bug, do QC Leader đóng).
 Từ trạng thái này có thể chuyển sang trạng thái UNCONFORMED, REOPEN hoặc CLOSED
REOPEN
 Trạng thái này là do TESTER/QC chuyển từ trạng thái RESOLVED sang, do sau khi test lại thì bug vẫn còn bị lỗi hoặc gây ra lỗi khác khi thao tác tương tự như bug cũ.
 Ở trạng thái này bug có thể chuyển sang trạng thái RESOLVED hoặc ASSIGNED.
VERIFIED
 Trạng thái này là TESTER đã test lại xong và xác nhận bug này đã được fix. (trong trường hợp TESTER không có quyền đóng bug, do QC Leader đóng).
 Từ trạng thái này có thể chuyển sang trạng thái UNCONFORMED, REOPEN hoặc CLOSED
CLOSED
 Trạng thái này là bug đã được fix và được test lại xong. Kết thúc vòng đời của một bug.
 Trong trường hợp bug đã đóng rồi mà khi fix bug khác, gây ra lỗi bug này nữa thì sẽ chuyển từ trạng thái CLOSED sang REOPEN
2. Công cụ BugTracker.Net
2.1 Giới thiệu:
 BugTracker.Net là công cụ miễn phí giúp tester mô tả và quản lý lỗi trong quá trình phát triển dự án.
 BugTracker.Net cung cấp khả năng kiểm soát
lỗi thông qua việc ghi nhận thời gian, định danh developer, mức độ nghiêm trọng của bug…
 Mục tiêu là phát hiện lỗi về tính an toàn, bảo
mật, tương thích, và hiệu năng của Bugtracker.Net.
2.2 Các chức năng thực hiện kiểm thử:
 Tính bảo mật, an toàn của hệ thống.
 Tính tương thích của hệ thống.
 Hiệu năng của hệ thống.
 Chức năng ghi nhận bug.
 Chức năng kết xuất bug.
Các vấn đề tạo nên tính bảo mật:
 Confidentiality (độ tin cậy).
 Integrity (tính toàn vẹn).
 Availability (tính sẵn dùng).
 Accountability (tính giải trình).
 Non-repudiation (tính chịu trách nhiệm).
Hiệu năng của hệ thống.
 Hiệu năng của hệ thống là một dạng của testing để xác định khả năng đáp ứng, khả năng chịu
tải, tính sẵn sàng của hệ thống dưới chế độ
đang chịu tải.
 Thử nghiệm tính sẵn sàng của ứng dụng
 Khả năng chịu lỗi
 So sánh hiệu năng khi triển khai trên các hệ
thống khác nhau, các cấu hình khác nhau
 Hỗ trợ nâng cao hệ thống
 Tìm ra mức cao nhất mà hệ thống & ứng dụng có thể chịu đựng được
3. Mantis BugTracker
Unassigned: những bug chưa được bàn giao
+ Reported by me: những bug do chính bạn báo cáo
+ Resolved: Những bug đã được giải quyết xong
+ Recently modified: Hiện tại đang được bàn thảo chỉnh sửa
+ Monitored by me: Những bug bạn được giao phó giám sát
Thanh công cụ
New: Bug mới
Acknowledged: Bug đã được chấp thuận
Feedback: Bug dạng đợi hồi âm
Confirmed: Bug đã được xác nhận
Assigned: Bug đã được bàn giao
Closed: Bug đã được đóng
Resolved: Bug đã được giải quyết xong
 Category: các project milestones, các hạng mục, các loại hình etc được chia ra trong 1 dự án hoặc nhiều dự án.
 Resolution: tùy chọn xử lý bug, chỉ có bug owner hoặc các cấp bậc đặc quyền mới có thể hiệu chỉnh , thay đổi thông số phần này.
 Jump to Notes: Đi đến ngay bảng bàn thảo mà không cần xem bug details
 Update issue: Chỉnh sửa nội dung bug
 Change status To: chuyển đổi tình trạng bug, chỉ có bug owner hoặc các cấp bậc đặc quyền mới có thể hiệu chỉnh , thay đổi thông số phần này.
 Monitor Issue: Nhập bug này vào danh sách các bug mình quan tâm theo dõi đặc biệt.
 Create clone: Tạo 1 bug khác cùng nội dung nhưng khác số thứ tự bug.
 Relationships: Tạo mối quan hệ giữa các bug ( thông qua bug’s ID )

No comments

[SWT]Bài tập cộng điểm

Thursday, March 24, 2011 1:11:26 PM

[SWT]Bài tập cộng điểm

Chào các em,

Hiện tại website của bộ môn chúng ta vừa mới được xây dựng xong và chắc chắn rằng không thể nào không thiếu sai sót. Do đó,
nhằm để trang web hoạt động được tốt hơn, cũng như tạo điều kiện để các em tham gia vào việc test một ứng dụng thực tế,
hôm nay tôi muốn ra một bài tập cộng điểm.

Nội dung bài tập: Test trang web của bộ môn (Link http://www.cntt.caothang.edu.vn)
- Ứng dụng bài học WebTesting vào để test. Đặc biệt chú trọng đến SecurityTesting.
- Các bug tìm thấy phải được report dưới dạng file Word hoặc Excel. (Phải trình bày các bước cần thực hiện để phát sinh bug. Đề nghị cách fix nếu có.)
- Kết quả report gửi qua địa chỉ email phamvietvan.c4@gmail.com
- Tựa đề [Lớp][SWT]Bài tập cộng điểm
- Điểm cộng sẽ được tính dựa vào số bug các em phát hiện ra, tối đa là 5 điểm.
- Tuyệt đối không được dùng trò tấn công DoS mà cả thế giới mạng đang tẩy chay.
- Hạn chót nộp bài tập này là 04/04/2011

Qua bài tập này tôi mong rằng các em có thể chia sẻ những kinh nghiệm quý báu của bản thân về việc xây dựng ứng dụng web mà các em đã tích lũy được
và xem đây như là sự đóng góp cho sự phát triển của bộ môn trước khi các em tốt nghiệp.

Tôi tin vào kiến thức cũng như khả năng của các em.

Chúc vui!
--
Pham Viet Van.

No comments

Thông báo !

Saturday, January 8, 2011 12:50:12 AM

    Thầy không nhận bài tập tìm hiểu Static testing, Dynamic testing, Black box testing, White box testing.
    Lý do: Tôi gởi nhầm link. Tôi đã gởi lại, gởi lại nhiều lần, thầy vẫn từ chối "Reject".
    Tôi xin lỗi mọi người !.
    Vì vậy lần sau tất cả thành viên phải nộp bài báo cáo cho tôi trước một ngày.
Ai không nộp hay nộp trễ sẽ không nhận.

No comments

Báo cáo tìm hiểu: Static testing, Dynamic Testing, Black box tesing,White box testing

Thursday, January 6, 2011 3:04:37 PM

    1. Static testing
     Static testing (thử nghiệm tĩnh) là một hình thức kiểm thử phần mềm mà phần mềm không thực sự được sử dụng. Nó thường không chi tiết thử nghiệm, nhưng kiểm tra chủ yếu cho sự lành mạnh của các thuật toán, mã số, hoặc tài liệu. Đây là cú pháp chủ yếu kiểm tra của mã này và/hoặc tự rà soát các mã hoặc tài liệu để tìm ra các lỗi. Đây là loại xét nghiệm có thể được sử dụng bởi nhà phát triển người đã viết mã, trong sự cô lập. đánh giá luật, kiểm tra và walkthrough cũng được sử dụng.
    Lỗi được phát hiện ở giai đoạn phát triển là ít tốn kém để sửa chữa hơn sau này trong các chu kỳ phát triển.

    2. Dynamic Testing
    Dynamic testing (thử nghiệm động) là một thuật ngữ được sử dụng trong công nghệ phần mềm để mô tả việc thử nghiệm các hành vi năng động của mã. Dynamic, phân tích đề cập đến việc kiểm tra phản ứng vật lý của hệ thống, để biến không phải là không đổi và thay đổi theo thời gian. Trong thử nghiệm phần mềm năng động thực sự phải được biên dịch và chạy, thực tế năng động thử nghiệm liên quan đến làm việc với phần mềm này, cho giá trị đầu vào và kiểm tra nếu đầu ra được như mong đợi. Đây là những hoạt động xác thực. Unit Test, Integration thử nghiệm, hệ thống bài kiểm tra và chấp nhận xét nghiệm được vài trong số các thử nghiệm phương pháp năng động.
    Dynamic, có nghĩa là kiểm tra thử nghiệm dựa trên các trường hợp kiểm tra cụ thể bằng cách thực hiện của đối tượng kiểm tra hoặc các chương trình đang chạy. Điều này trái ngược để thử nghiệm tĩnh .

    3. Black box testing
    a. Khái niệm: Đây là kĩ thuật kiểm thử chức năng của hệ thống.      Một kĩ thuật kiểm thử mà theo đó các hoạt động bên trong hay các cấu trúc nội bộ sẽ không được quan tâm đến.

     VD: Ở các sân bay, khi được kiểm tra túi sách hoặc va li chúng ta chỉ quan sát được trước và sau khi kiểm tra, còn trong lúc kiểm tra chúng ta sẽ không nhìn thấy được…
     Black Box Testing sẽ dựa vào đặc tả yêu cầu hệ thống.
     Các tên gọi khác của black-box testing:
     o Specification-based Testing: đây là sự tích hợp kiểm tra là kiểm tra, trong đó thành phần phần mềm, thành phần phần cứng, hoặc cả hain được kết hợp và thử nghiệm để đánh giá sự tương tác giữa chúng.
     Ví dụ: dữ liệu có thể bị mất trên một giao diện, thông điệp có thể không có được thông qua đúng cách, hoặc giao diện có thể không được thực hiện như quy định.
     o Input-output Testing: kiểm thử đầu vào / ra.
     o Functional Testing: kiểm thử chức năng.
     Các loại thử nghiệm thuộc các chiến lược kiểm tra hộp đen là: kiểm tra chức năng, kiểm tra căng thẳng, thử nghiệm phục hồi, kiểm tra khối lượng, người dùng chấp nhận thử nghiệm (còn gọi là UAT), thử nghiệm hệ thống, kiểm tra sanity hoặc khói, thử tải, kiểm tra khả năng sử dụng, thăm dò kiểm tra, ad-hoc thử nghiệm, thử nghiệm alpha, beta thử nghiệm
     Black Box Testing thường được thực thi gần các giai đoạn
      Test tích hợp
      Test giao diện
      Test hệ thống
      Test chấp nhận

     Trước khi tiến hành test:
     o Phân rã yêu cầu thành các Test Objectives.

     o Phân rã cho đến khi đạt được các Test Objectives tương đương với Test Case.
     Các kỹ thuật phân rã
      Equivalence Class Partitioning
      Boundary Value Analysis
      State Transition Testing
      Cause-Effect Graphing

    b. Những lợi thế của loại thử nghiệm bao gồm:
     * Việc kiểm thử là không thiên vị bởi vì các nhà thiết kế và kiểm thử là độc lập với nhau.
     * Việc kiểm thử không cần kiến thức về bất kỳ ngôn ngữ lập trình cụ thể.
     * Kiểm thử được thực hiện từ điểm nhìn của người sử dụng, không phải là nhà thiết kế.
     * Kiểm tra các trường hợp có thể được thiết kế ngay khi đặc điểm kỹ thuật đầy đủ.

     c. Nhược điểm của loại thử nghiệm bao gồm:
     * Các hàm thực thi không đúng chức năng.
     * Các trường hợp kiểm thử rất khó thiết kế.
     * Kiểm thử tất cả các luồng đầu vào có thể là không thực tế bởi vì nó sẽ mất một số tiền và thời gian quá nhiều, do vậy, nhiều chương trình con đường sẽ được đi kiểm chứng.

    4. White box testing
    a. Khái niệm:
       White box testing là kiểm thử hộp trắng, dựa vào cấu trúc bên trong của phần mềm. Còn được gọi là clear box testing, glass box testing, transparent box testing, or structural testing. Để thực hiện White box testing thì tester phải am hiểu cấu trúc bên trong của phần mềm như: các đường, luồng dữ liệu, chức năng, kết quả. Phương thức của White box testing là: chọn các đầu vào và xem các đầu ra.
     b. Đặc điểm:

         Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng thay đổi theo.
         Được ứng dụng trong các kiểm tra ở cấp độ mô đun, tích hợp và hệ thống của quá trình test phần mềm.
     c. Các kĩ thuật:
       Kiểm thử luồng, lộ trình ( Deriving Test Cases) bằng cách thực hiện kiểm thử lộ trình cơ sở (Basis path Testing) là kĩ thuật kiểm thử mà phần mềm được chia thành các lộ trình. Đảm bảo các lộ trình độc lập qua một mô đun mã sẽ được kiểm thử đầy đủ.
       Luồng điều khiển / Phạm vi (Control-flow / Coverage Testing)
là cách tạo ra các bộ giá trị kiểm thử để có thể xem được 100% các trường hợp có thể xảy ra với các thành phần của một chương trình bao gồm :
         + Phương thức - Method Coverage.
         + Câu lệnh – Statement Coverge.
         + Nhánh - Branch Coverge.
         + Điều kiện – Condition Converage.
       Kiểm thử luồng dữ liệu ( Data Flow Test ) là Kiểm tra sự khởi tạo, biến đổi và huỷ của các các luồng dữ liệu.
       Trường hợp hỏng ‘rác’ – Failure ‘Dirty’ Case Test là trường hợp kiểm thử các trường hợp mà người lập trình cần đứng ở vị trí người dùng để nhập giá trị. Cụ thể là người dùng có thể nhập số thay cho chữ, hoặc không nhập gì, tạo ra lỗi phép toán (divided by Zero )...
       Xem lại luồng đồ thị( Flow Graphs Revisited )


  ***Phân công nhiệm vụ

No comments

Báo cáo bài tập hướng dẫn dùng SVN

Monday, January 3, 2011 4:28:34 PM

         Subversion(viết tắt là SVN) là một hệ thống quản lí version (version control system(VCS) được giới thiệu vào năm 2000 bởi công ty CollabNet. Đây là hệ thống hỗ trợ làm việc theo nhóm rất hiệu quả. Khi một nhóm làm việc cùng trên một project, việc nhiều người cùng chỉnh sửa nội dung của một file là điều không thể tránh khỏi. SVN cung cấp các chức năng để có thể thực hiện việc này một cách đơn giản và an toàn.
         TortoiSVN là một phần mềm mã nguồn mở dùng ở phía client của Subversion system. Dùng để quản lý và kiểm tra các phiên bản mã nguồn khác nhau trong quá trình phát triển phần mềm, link down: http://sourceforge.net/projects/tortoisesvn/files/

         Hướng dẫn cách dùng TortoiSVN
1.Tạo thư mục Repository (đây là thư mục các chứa file trên server):
         a.  Vào ổ D:\ tạo một thư mục tên bất kì. Ví du: D:\My Repository
         b.  Right Click vào thư mục vừa tạo, chọn TortoiseSVN , chọn Create Respository.

sau đó hiển thị Hộp thoại TortoiseSVN thông báo đã tạo Respository thành công,
click OK để đóng hộp thoại.

          Lưu ý: Tuyệt đối không được thay đổi bất kỳ file nào ở thư mục vừa tạo, vì nó sẽ ảnh hưởng đến các file khác
2. Check out thư mục:
         a.  Tạo một thư mục bất kì để chứa dữ liệu được checkout từ Repository. Ví dụ: E:\Client 1
         b.  Right Click vào thư mục này, chọn SVN Checkout…

c. Hộp thoại Checkout xuất hiện gồm có 3 phần: Respository, Checkout Depth, Revision

Phần Respository, mục ‘url of repository:’ là nhập dường dẫn của thư mục Respository (ví dụ: file:/// D:/My Repository). Trường hợp có account hỗ trợ SVN trên mạng (code.google.com) thì nhập địa chỉ server, sau đó nhập username và password ở hộp thoại tiếp theo và click OK

Phần Checkout Depth có 4 lựa chọn:

Fully recursive: Checkout toàn bộ cấu trúc thư mục, các file dữ liệu trên Repository. Immediate children, including folders: Chỉ Checkout cấu trúc thư mục và các file bên ngoài. Only file children: Chỉ Checkout các file bên ngoài. Only this item: Chỉ checkout được thư mục Repository mà không có cấu trúc hay dữ liệu.
d. Sau đó click OK. Hiện hộp thoại này để cho biết các thư mục checkout

->Click OK
Nếu Checkout thành công thì thư mục sẽ như thế này

trong thư mục này chỉ có file ẩn .svn, vì trên server chư có file nào, có thể tùy ý tạo thư mục trong file này.

Tìm hiểu thêm về SVN: TortoiseSVN.doc

Phân công nhiệm vụ:

No comments

Bài giảng_SWT

Monday, January 3, 2011 10:30:11 AM

1. SWT_basicConcepts
3.SWT_basicConcepts.pptx

2. Slide môn Kiểm Chứng Phần Mềm
4.SWT_testingTechniques.zip

3. Slide bài giảng phần "Các kỹ thuật kiểm thử" (12/01/2011)

4. 6.SWT_bugReporting (19/01/2011)

***. Tài liệu tham khảo
   +Sams.Software.Testing.2nd.Edition.Jul.2005.chm.zip
   +Testing Applications on the Web.zip
   +Web Security Testing Cookbook, 1st Edition.zip

Cach lam bao cao.zip[/ATTACH]]Cách làm báo cáo

No comments

Nhiệm vụ tuần 4_Môn Software Testing Bai Tap1(03/01/2011)

Friday, December 31, 2010 3:43:50 AM

- Tìm hiểu
     + Status testing, Dynamic Testing
     + Black box tesing, White box testing

- Báo cáo trên web
     + Kết quả những gì tìm hiểu
     + Phân công công việc
     + Nộp link báo cáo qua mail

     + Deadline 11pm, 06/01/2011

***Phân công :
Hoàng Lợi và Xuân Hiển tìm hiểu về Status testing, Dynamic Testing
Hạnh và Ửng tìm hiểu Black box tesing, White box testing
-----Ngày 04/01/2011 nộp cho nhóm trưởng

No comments

Thành Viên :Lưu Xuân Hiển

Thursday, December 30, 2010 2:10:33 AM

-------------------------------------------------------------------------------------------------
Họ Tên: Lưu Xuân Hiển
Lop: CDTH08B
Trường: cao đẳng kỹ thuật Cao Thắng
Ngày sinh: 10-10-1990
Nơi ở: Binh tho, Thủ Đức
Sở Thích: Ca Nhạc, Xem Phim, Bóng Đá, Ngủ
Câu lạc bộ: liverpool, barcelona, vietnam [/I]
Trình độ văn hóa: Cao Đẳng
Thông tin liên hệ:
Email:xuanhienit1290@gmail.com--------------------------------------------------------------------------------------------

1 comment

Bài giảng_CC MT PT PM

Wednesday, December 29, 2010 2:23:09 AM

1. 'GioiThieuVeSE.zip'
2.GioiThieuVeSE.zip

No comments

Nhiệm vụ tuần 4_Môn CC MT PTPM Baitap2 (03/01/2011)

Monday, December 27, 2010 2:41:25 PM

- Download TurtoiSVN
- Tạo tài khoản trên
     + code.google.com
     + assembla.com
     + hoặc trang nào có hỗ trợ SVN.
- Đọc hướng dẫn dùng SVN để tìm cách
     + Tạo thư mục
     + Check out thư mục đó về máy
- Đưa lên web về kết quả tìm hiểu
- Public việc phân chia công việc

* Nộp bài báo cáo qua email
     + Deadline 11pm, 04/01/2011]
     + [CDTH08B]CCMTPTPM_Nhom?_BaiTap?

***Phân công:
Hoàng Lợi và Xuân Hiển tìm hiểu về cách tạo thư mục của SVN
Hạnh và Ửng tìm cách check out thư mục về máy
-----Ngày 02/01/2011 nộp cho nhóm trưởng

No comments

1 2 Next »

Blog search