Tuhoctester.t3h

Còn 4 slot cho lớp học free hôm nay tại T3H
Các bạn nữ IT có dự định theo Tester thì nhanh tay đăng ký để được thực hành test cùng chuyên gia từ Fsoft nhé
📢 Hệ Thống T3H ĐH Khoa Học Tự Nhiên tổ chức lớp học tester miễn phí: "THỰC HÀNH TEST FORM GIAO DIỆN"
🌟 Lợi ích khi tham gia buổi học:
➡ Được định hướng và chia sẻ về nghề tester bởi PM đến từ Fsoft
➡ Được hiểu quy trình test sản phẩm
➡ Được thực hành thực tế.
🎉 Đăng ký tham gia tại:https://goo.gl/forms/E6vFGNgvcku6hXpf2
- Địa điểm: Tầng 5, nhà A trường Cán bộ Quản lý Văn hóa Thể thao và Du lịch đường Hồ Tùng Mậu, Mai Dịch, Cầu Giấy.

Gửi mọi người,
Ai có nhu cầu thì gửi thông tin ứng tuyển nhé.
Cv gửi trực tiếp cho chị BÍCH HÀ: [email protected]
"Dear các anh/chị/em LG,
Theo kế hoạch sắp tới, Tập đoàn sẽ mở trung tâm R&D tại Hà Nội Việt Nam. Đây là trung tâm chuyên về phát triển phần mềm thiết bị trong xe hơi (In Vehicle Infortainment), mà tập đoàn chú trọng phát triển. Các sản phẩm của LG hiện đang có mặt tại những thương hiệu xe lớn trên thế giới như Honda, GM, Renault, Volwagen… Bước đầu thành lập năm 2016, trong tương lai trung tâm tại VN sẽ trở thành 1 trong những trung tâm R&D lớn trên thế giới.
Để chuẩn bị cho trung tâm mới, dự kiến sẽ cần nhiều nhân lực trong lĩnh vực Công nghệ thông tin:
- Phát triển phần mềm (Software Development)
- Kiểm thử phần mềm (Validation Test)
- Lập kế hoạch phát triển dự án (Development Planning)
ở các vị trí Team Leader, Part Leader, và nhân viên (có kinh nghiệm, mới ra trường).
Phòng Nhân sự xin được thông báo sơ bộ, các anh chị em Công ty ở tất cả các Văn phòng trên cả nước, nếu có người thân/ bạn bè trong lĩnh vực này có quan tâm đến các vị trí công việc này thì giới thiệu giúp.
http://lgejobs.com/vi…/validation-test-manager.35a54d05.html
http://lgejobs.com/…/software-development-manager-in-vehicl…
http://lgejobs.com/…/software-development-part-leaders-06-p…
http://lgejobs.com/…/development-planning-manager.35a54d00.…
Trân trọng cảm ơn sự hợp tác của các anh chị em,"

Zend Framework Default Application

Bắt đầu từ ngày 23/4/2015 đến hết ngày 28/4/2015 T3H Hà Nội ưu đãi 50% học phí áp dụng cho các khóa học :

1. Lập trình viên PHP : Học phí gốc 7.600.000Đ
Giảm 50% học phí chỉ còn : 3.800.000 Đ
Học trong vòng 6 tháng/120h/40 buổi/3h

2. Lập trình di động Android. Học phí gốc 8.600.000Đ
Giảm 50% học phí chỉ còn 4.300.000 Đ
Học trong vòng 6 tháng/120h/40 buổi/3h

3. Chuyên viên kiểm thử phần mềm - Tester. Học phí gốc là 4.800.000 Đ
Giảm 50% học phí chỉ còn 2.400.000 Đ
Học trong vòng 3 tháng/20 buổi/3h

4. Chuyên viên Đồ họa đa truyền thông - 2D
Học phí gốc là 7.600.000 Đ.
Giảm 50% học phí chỉ còn 3.800.000 Đ
Học trong vòng 6 tháng

Sau khi hoàn thành xong khóa học các em học viên sẽ được cấp chứng chỉ của ĐHKHTN ĐHQG HCM
Trong trường hợp học viên nào không thể tham gia khóa học vào tháng 5 thì có thể bảo lưu khóa học để nhận ưu đãi 50%
Phí bảo lưu là 500.000 Đ
Thời gian bảo lưu tối đa là 6 tháng
Sau khi làm thủ tục nhập học sẽ đóng nốt học phí còn lại.

Mọi thắc mắc xin liên hê :
Ms Liễu 0969807965
Email : [email protected]

Các mức kiểm thử

Các công việc kiểm thử thường được phân nhóm khi thêm vào qui trình phát triển phần mềm, hoặc được phân theo mức kiểm thử đặc trưng.

1. Unit testing - Kiểm thử thành phần/đơn vị
Unit testing đề cập đến các kiểm thử để chứng thực (xác minh - verify) 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). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử đơn vị thường được sử dụng ở mức lớp (class) và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor.

Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (loại test white-box), để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình không thể bảo đảm chức năng của một bộ phận của phần mềm mà là sử dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việc độc lập với nhau.
Unit testing (kiểm thử đơn vị) cũng được gọi là component testing (kiểm thử thành phần).

2. Integration testing - Kiểm thử tích hợp (đơn vị)

Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đây được xem là một cách làm tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định.

Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của thiết kế kiến trúc đã đượ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.

3. System testing - Kiểm thử hệ thống
System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu.

Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các yêu cầu hệ thống.

4. Regression testing - Kiểm thử hồi qui
Regression testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo mong đợi. Điển hình, hồi qui xảy ra như là một kết quả không mong muốn của việc thay đổi chương trình, khi phần code của phần mềm mới được phát triển xung độ với code cũ đang có. Phương pháp thông thường của kiểm tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây và kiểm tra xem có lỗi đã được fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã fixed rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong quá trình phát hành và rủi ro của các tính năng được thêm vào. Chúng có thể được hoàn thành – vì việc thay đổi đã thêm vào sau bản phát hành hoặc coi nó là mạo hiểm, rất hời hợt, bao gồm các kiểm thử trường hợp đúng (positive) trên từng chức năng – nếu các thay đổi được thêm vào trước khi phát hành hoặc coi nó ít rủi ro.

5. Acceptance testing - Kiểm thử chấp nhận
Kiểm thử chấp nhận có thể có là một trong hai điều sau đây:
1. Một smoke test được sử dụng như là một acceptance test trước khi giới thiệu bản build mới để thực hiện việc kiểm thử chính, có nghĩa là trước khi thực hiện kiểm thử tích hợp hoặc hồi qui.
2. Acceptance testing được thực thi bởi khách hàng, thường được thực hiện trong môi trường thí nghiệm trên phần cứng của họ, được biết như là kiểm thử chấp nhận người dùng (viết tắt là UAT). Acceptance testing có thể được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa 2 pha của quá trình phát triển phần mềm.[cần dẫn nguồn]

6. Alpha testing – Kiểm thử Alpha

Alpha testing 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. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS office, window, chương trình diệt virus) 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. van Veenendaal, Erik. "Bảng chú giải tiêu chuẩn của thuật ngữ dùng trong Kiểm thử phần mềm - Standard glossary of terms used in Software Testing".

7. Beta testing – Kiểm thử Beta

Beta testing được thực hiện sau alpha testing. Các phiên bản của phần mềm - được biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug. Thỉnh thoảng, 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 từ một lượng người sử dụng tương lai lớn nhất.

Software Testing là gì?

Software testing là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng hay nhóm phát triển phần mềm,...) thông tin về chất lượng của sản phẩm hoặc dịch vụ đang kiểm thử (under test). Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Các kỹ thuật kiểm thử bao gồm, nhưng không giới hạn, trong qui trình thực thi chương trình hoặc ứng dụng với mục đích tìm kiếm bug (lỗi, khiếm khuyết/nhược điểm).

Software testing cũng có thể xem như là quá trình thẩm định và thẩm tra (validating and verifying) phần mềm/chương trình/ứng dụng/sản phẩm để:

1. đáp ứng được các yêu cầu công việc và kỹ thuật đã được qui định trong thiết kế và trong lúc phát triển;
2. làm việc như mong đợi;
3. và có thể thực thi với các đặc tính giống nhau.

Software testing, phụ thuộc vào phương pháp kiểm thử được dùng, có thể được thực thi bất kỳ lúc nào trong qui trình phát triển phần mềm. Tuy nhiên, phần lớn việc kiểm thử bắt đầu sau khi có thiết kế chi tiết và sau khi code xong. Như vậy, phương pháp kiểm thử bị ảnh hưởng/chi phối bởi phương pháp phát triển phần mềm (qui trình phát triển phần mềm) đang sử dụng.

Các mô hình phát triển phần mềm khác nhau thì sẽ tập trung vào việc kiểm thử các điểm khác nhau trong qui trình phát triển. Các mô hình phát triển mới hơn như Agile, thường dùng test driven development và thay thế bằng phần phát triển của kiểm thử trong tay DEV, trước khi nó trở thành một nhóm test chính thức. Trong các mô hình cổ điển hơn, phần lớn việc thực thi test được tiến hành sau khi có thiết kế chi tiết (spec) và quá trình code đã hoàn thành.

Các bước chính của quy trình thường bao gồm:
1) nghiên cứu hệ thống và yêu cầu,
2) lập kế hoạch kiểm định,
3) thiết kế và chuẩn bị dữ liệu kiểm định,
4) thực thi kiểm định,
5) báo cáo kết quả kiểm định,
6) rà soát và cải tiến kiểm định.

Nguồn : Sưu tầm

Các thuật ngữ và định nghĩa cơ bản về Kiểm thử phần mềm

Kỹ nghệ kiểm thử đã phát triển và tiến hoá hàng mấy chục năm nên các
thuật ngữ trong các tài liệu khác nhau thường không thống nhất và thiếu
tương thích. Các thuật ngữ được trình bày trong cuốn sách này dựa vào các
thuật ngữ chuẩn được phát triển bởi IEEE (Viện Kỹ nghệ điện và điện tử)
với việc chọn lọc cẩn thận các thuật ngữ tiếng Việt tương ứng.
Lỗi (Error): Lỗi là những vấn đề mà con người mắc phải trong quá trình
phát triển các sản phẩm phần mềm. Trong thực tế, con người luôn có thể
phạm lỗi. Khi lập trình viên phạm lỗi trong lập trình, ta gọi các lỗi đó là
bug (con bọ). Lỗi có thể phát tán. Chẳng hạn, một lỗi về xác định yêu cầu
có thể dẫn đến sai lầm về thiết kế và càng sai khi lập trình theo thiết kế này.
Lỗi là nguyên nhân dẫn đến sai.
Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.
Cũng có thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức, chẳng
hạn chương trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,.... Sai lầm có thể
khó bị phát hiện. Khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế,
sai kết quả từ lỗi đó là thiếu mất cái gì đó mà lẽ ra cần phải có. Sai về nhiệm
vụ xuất hiện khi vào sai thông tin, còn sai về bỏ quên xuất hiện khi không
vào đủ thông tin. Loại sai thứ hai khó phát hiện và khó sửa hơn loại sai thứ
nhất.
Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi. Có
hai điều cần lưu ý ở đây. Một là thất bại chỉ xuất hiện dưới dạng có thể
chạy được mà thông thường là mã nguồn. Hai là các thất bại chỉ liên kết
với các lỗi về nhiệm vụ. Còn các thất bại tương ứng với các lỗi về bỏ quên
thì xử lý thế nào? Những cái lỗi không bao giờ được tiến hành, hoặc không
được tiến hành trong khoảng thời gian dài cần được xử lý thế nào? Virus
Michaelangelo là một ví dụ về lỗi loại này. Nó chỉ được tiến hành vào ngày
sinh của Michaelangelo, tức ngày 6/3 mà thôi. Việc khảo sát có thể ngăn
chặn nhiều thất bại bằng cách tìm ra các lỗi thuộc cả hai loại.
Sự cố (Incident): Khi thất bại xuất hiện, nó có thể hiển thị hoặc không,
tức là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử.
Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùng
hoặc người kiểm thử về sự xuất hiện của thất bại này.
Yêu cầu của khách hàng và đặc tả của phần mềm: Phần mềm được
viết để thực hiện các nhu cầu của khách hàng. Các nhu cầu của khách hàng
được thu thập, phân tích và khảo cứu và là cơ sở để quyết định chính xác
các đặc trưng cần thiết mà sản phẩm phần mềm cần phải có. Dựa trên yêu
cầu của khách hàng và các yêu cầu bắt buộc khác, đặc tả được xây dựng để
mô tả chính xác các yêu cầu mà sản phẩm phần mềm cần đáp ứng, và có
giao diện thế nào. Tài liệu đặc tả là cơ sở để đội ngũ phát triển phần mềm
xây dựng sản phẩm phần mềm. Khi nói đến thất bại trên đây là nói đến việc
sản phẩm phần mềm không hoạt động đúng như đặc tả. Lỗi một khi được tiến hành có thể dẫn đến thất bại. Do đó, lỗi về bỏ quên được coi là tương
ứng với các lỗi khi xây dựng đặc tả.
Kiểm chứng và thẩm định: Kiểm chứng (verification) và thẩm định
(validation) hay được dùng lẫn lộn, nhưng thực ra chúng có ý nghĩa khác
nhau. Kiểm chứng là quá trình để đảm bảo rằng một sản phẩm phần mềm
thỏa mãn đặc tả của nó. Còn thẩm định là quá trình để đảm bảo rằng
sản phẩm đáp ứng được yêu cầu của người dùng (khách hàng). Trong thực
tế, chúng ta cần thực hiện kiểm chứng trước khi thực hiện việc thẩm định
sản phẩm phần mềm. Vì vậy, chúng ta có thuật ngữ V&V (Verification &
Validation). Lý do của việc này là chúng ta cần đảm bảo sản phẩm đúng với
đặc tả trước. Nếu thực hiện việc thẩm định trước, một khi phát hiện ra lỗi,
chúng ta không thể xác định được lỗi này do đặc tả sai hay do lập trình sai
so với đặc tả.
Chất lượng và độ tin cậy của phần mềm: Theo từ điển, chất lượng
của một sản phẩm được thể hiện bằng các đặc trưng phù hợp với đặc tả của
nó. Theo cách hiểu này, chất lượng của một sản phẩm phần mềm là sự đáp
ứng các yêu cầu về chức năng (tức là các hàm cần được tính toán), sự hoàn
thiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi sản
phẩm phần mềm chuyên nghiệp. Chất lượng phần mềm đặc trưng cho “độ
tốt, độ tuyệt hảo” của phần mềm, và gồm có các yếu tố về chất lượng như:
tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian
và tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễ
sử dụng, dễ bảo trì ... Như vậy, độ tin cậy chỉ là một yếu tố để đánh giá chất
lượng phầm mềm. Người kiểm thử hay nhầm lẫn độ tin cậy với chất lượng.
Khi kiểm thử đạt tới mức phần mềm chạy ổn định, có thể phụ thuộc vào nó,
người kiểm thử thường cho rằng phần mềm đã đạt chất lượng cao. Các yếu
tố về mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềm
được gọi là các tiêu chuẩn chất lượng như tính có cấu trúc, tính đơn thể,
tính khả kiểm thử, ...
Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất
bại trong một khoảng thời gian nhất định. Nó được xem là một yếu tố quan
trọng của chất lượng phần mềm. Ngoài ra, thời gian trung bình cho việc khắc
phục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tin
cậy của sản phẩm phần mềm.

Bài giảng Tesing được T3H Hà Nội biên soạn giúp các bạn học Kiểm thử phần mềm

Quy trình kiểm tra lỗi

Quy trình kiểm thử/ Testing

Bải giảng Kiểm thử phần mềm của T3H Hà Nội - DDHKHTN - ĐHQG HCM

Software testing