Blog Testing

Ai muốn làm template thì vào đây: http://www.freewebtemplates.com/ down template về tập làm!  và vào đây: http://www.w3schools.com/sql/default.asp để học các thuộc tính, những kai căn bản để làm dc code giao diện. Vào đây nữa:https://www.izwebz.com/. hêhe

http://learnloadrunner.com/ http://www.learnqtp.com/ http://www.learnqualitycenter.com/ http://www.softwaretestingportal.com/ http://www.etestinghub.com/loadrunner.php http://docs.seleniumhq.org/

Chỉ cần nhập link site của bạn, và wait 1 lát, bạn sẽ có những thông số chính xác mà k cần bấm đồng hồ!: https://gtmetrix.com/pro/

Tiêu chí tuyển chồng Tuyển chồng chất lượng. Lương tháng không tiêu. Không được nói nhiều. Không cho cãi vợ. Phải biết đi chợ. Nấu nướng, quét nhà. Không được la cà. Rượu chè cờ bạc. Không được lười nhác. Phải tắm hàng ngày. Không được xỉn say. Không hay "tá lả". Không được quậy phá. Không đánh vợ con. Không béo, không lùn. Không gầy, không ốm. Thức khuya dậy sớm. Nghe vợ chăm con. Biết mua phấn son. Làm quà cho vợ. Mua đồ không hớ. Cao ráo, thông minh. Thấy con gái xinh. Không được xí xớn.:)) tiêu chuẩn cao quá!

https://www.youtube.com/watch?v=mTIdoDEuXrM 1. Thế nào là test ứng dụng trên mobile? 2. Các loại ứng dụng trên mobile? 3. Các loại thiết bị di động: các dòng điện thoại với version và hdh khác nhau. 4. Thách thức, tầm quan trọng, độ khẩn. 5. Thực hành tốt nhất trong test mobile. 6. Tại sao phải tập trung vào test mobile. 7. Câu hỏi.

Mỗi cơ hội bỏ lỡ sẽ k có cơ hội thứ 2 đâu! vì vậy mỗi khi nhận thấy mình có cơ hội hãy nắm lấy và thực hiện cho bằng được ước mơ của mình nhé! Đừng bao giờ từ bỏ!

I.Một số lưu ý về Bug I.1. Khi log Bug,bước xác định rất quan trọng What -Bug này là bug gì,độ nghiêm trọng của nó như thế nào? Where -Xác định lỗi ở đâu,trên môi trường nào (web thì browser nào,app thì trên hệ điều hành nào) When -Bug xảy ra khi nào (nghĩa là thực hiện những bước nào thì xảy ra Bug) How -Hướng sửa Bug đó như thế nào? (expected result) Who – Bug do code của ai gây ra I.2.Tìm ra Bug của phần mềm là chưa đủ, cần phải xem Bug đó đã được fix hay chưa và đặc biệt : việc fix Bug đó không gây ra Bug mới. I.3.Không phải tất cả các Bug tìm ra đều được fix : Cần phải đánh giá độ quan trọng của Bug xem Bug nào cần phải fix,nên fix và bug nào không cần fix. II.Các lỗi thường gặp trong quá trình Test Web II.1.Lỗi về chức năng (Function Bug) BUG Priority Link từ trang này đến trang khác không hoạt động High Link từ trang này đến trang khác bị sai High Lỗi khi nhập các thẻ HTML,kí tự đặc biệt,kí tự mở rộng…và các ô Textbox Medium Không check các trường nhập liệu liên

Đây là một số lưu ý khi test web và test windows application: - Window Application hay còn gọi Desktop Application sử dụng kiến trúc 2 tầng giữa client và server. + Install rồi chạy trên những máy tính cố định + Nếu có thay đổi, thường là phải install lại và test lại ứng dụng. + Hệ thống thường là một người dùng, nếu có share dữ liệu thì cũng là share mạng LAN là chủ yếu. + Thực thi trên máy tính cá nhân, server, vì vậy khi test trên ứng dụng desktop người ta chú trọng trên 1 môi trường cụ thể. + Vì thường chỉ sử dụng bởi 1 người dùng trên máy cụ thể nên không cần thực thi Load Test với giả lập số lượng user nhiều. + Kiểm thử bảo mật cũng đơn giản và dễ dàng hơn. + Background và màu sắc, layout thường giống nhau đối với các cửa sổ. - Web Application sử dụng kiến trúc đa tầng ( user client, database và server) + Nhiều người dùng tại 1 thời điểm. + Duyệt bằng trình duyệt, không biết trước môi trường duyệt web của người dùng, vì thế phải test tất cả trình duyệt và tất cả hệ điề

Mức độ nghiêm trọng (Severity): P1: Hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được v.v. P2: Chức năng chính của sản phẩm không hoạt động, bug giao diện, khả năng dễ sử dụng nếu test WEB. P3: Chức năng phụ của sản phẩm không hoạt động P4: Bug nhỏ không ảnh hưởng đến chức năng chính, phụ của sản phẩm P5: Yêu cầu cải tiến sản phẩm, thêm chức năng => Cũng nên lưu ý việc định nghĩa mức độ nghiêm trọng phụ thuộc vào sản phẩm khác nhau, mang tính tham khảo và tương đối. Độ ưu tiên (Priority): S1: Cao– Bug sẽ phải sửa ngay lập tức S2: Trung bình – Bug sẽ sửa trong bản cập nhật lần tới S3: Thấp – Bug không cần sửa trong bản cập nhật lần tới, có thể sửa nếu có thời gian Khi ghi nhận lỗi trên hệ thống, có thể đưa ra priority và severity như sau: + P1, P2 => S1 + P3, P4 => S2 + P5 => S2 hoặc S3 (Tùy vào yêu cầu về thời gian từ khách hàng)

https://tinhte.vn/threads/genymotion-chay-ung-dung-android-tren-may-tinh-windows-hoac-os-x-mot-cach-de-dang.2184024/ https://cloud.genymotion.com/page/launchpad/download/

1. Scrum Đó là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile). Công nghệ Agile cung cấp rất nhiều phương pháp luận, quy trình và các thực nghiệm để cho việc phát triển phần mềm trở nên nhanh chóng và dễ dàng. Hiện nay tại Việt Nam, quy trình này đang được thử nghiệm tại các đội phát triển phần mềm của một số công ty lớn. Scrum theo mô hình này. Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao. Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống. Các tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra. Thành phần chính quan trọng của scrum là các role (vai trò) và các cuộc trao đổi đánh giá. Có các role chính là: + Product Owner: là người làm những công việc bắt đầu cho dự án, tạo ra các

+ Test API test kq hệ thống trả về. đúng thì xử lý tn? sai thì xử lý ra sao? kết quả trả về từ server. vd thanh toán trực tuyến: gửi yêu cầu lên server của ngân hàng yêu cầu xác minh xem tài khoản có tồn tại k? tài khoản có còn đủ tiền? tài khoản đúng? nếu ok --> cho phép thanh toán. k ok --> bắn ra thông báo + Test memory : full bộ nhớ của đt thì có được lưu trên thẻ nhớ k? + Test connectivity: low connection: load chậm, lag, hệ thống bị treo. độ ưu tiên: ưu tiên wifi hơn 3G. + Function: sự tương tác giữa app và web: up ảnh lên app có hiển thị dc trên web k? + Check time out: up nhiều ảnh 1 lúc. bị out. có cho phép up tiếp hay phải up lại từ đầu? + Bắt buộc phải tìm hiểu yêu cầu + Cài itunes cho ios + ..............

_test trên hệ điều hành j? _test bằng những device nào? _đuôi apk với android và đuồi ipa với ios. _viết testcase. UD test những chức năng nào? _test connection, memory, ...(những cách test đặc trưng của mobile) _bug lỗi _báo cáo.

1. Nhà tuyển dụng đọc vị gì mạng xã hội của ứng viên trẻ : http://goo.gl/Ne0g2y 2. 10 câu nói sai lầm khi đàm phán lương : http://goo.gl/BzGM4D 3. 4 câu hỏi khó phổ biến trong phỏng vấn http://goo.gl/8yFpr5 4. 10 công việc tốt nhất khi bạn dưới 30 tuổi http://goo.gl/q82eDV

[10:50:37 PM] Vân Anh: nói đến cái được học ý thì em nói sâu vào việc em làm kịch bản và thực hiện test theo testcase xây dựng sẵn [10:50:46 PM] Vân Anh: bây giờ chị sẽ hỏi em vài câu hỏi [10:50:57 PM] Nguyễn Thơm: vâng ạ [10:51:27 PM] Vân Anh: quy trình kiểm thử có những giai đoạn nào? [10:51:55 PM] Nguyễn Thơm: qui trình kiểm thử bao gồm : requirement review [10:52:02 PM] Nguyễn Thơm: test planning [10:52:26 PM] Nguyễn Thơm: test analys and design [10:52:37 PM] Nguyễn Thơm: test excution [10:53:00 PM] Nguyễn Thơm: report and evalue.. [10:53:03 PM] Vân Anh: OK [10:53:29 PM] Vân Anh: em trả lời phỏng vấn những câu hỏi liên quan đến test thì em cứ đá vài từ tiengs Anh vào nehs [10:53:37 PM] Nguyễn Thơm: vâng ạ [10:53:44 PM] Vân Anh: từ nào ko chắc thì phải nhớ tiếng Việt [10:53:50 PM] Nguyễn Thơm: vâng ạ [10:53:57 PM] Vân Anh: ví dụ cái từ REport and Evaluation [10:54:09 PM] Vân Anh: e có thể dùng từ khác thay thế: ví dụ send report [10:54:21 PM] Vân Anh: ok, xong câu 1

https://www.youtube.com/watch?v=2PWCC0m9JLQ&feature=youtu.be https://www.youtube.com/watch… http://ivetetecedor.com/how-to-use-a-csv-file-with-jmeter/ https://guide.blazemeter.com/hc/en-us/articles/206733689-Using-CSV-DATA-SET-CONFIG https://www.blazemeter.com/?utm_source=adroll&utm_medium=banner&utm_campaign=retargetingfb

*giới thiệu về Mantis: _Summary: mô tả tổng quát, tóm tắt lỗi. Ví dụ: login không thành công với mật khẩu mới Hệ thống không thể gửi được email nhắc nợ _Description: Mô tả lỗi chính xác lỗi sảy ra chi tiết ntn? mô tả cụ thể. category:chức năng, hay mảng mà lead tạo ra: login, logout,...để mình chọn. _Steps To Reproduce : các bước để gặp lỗi đó. 1. Nêu các step tạo ra lỗi 2. Kết quả thực tế chương trình đang làm việc đưa ra 3. Kết quả mong muốn theo như SRS 4. Phần gợi ý/ hướng giải quyết (có thể có hoặc không) _Additional Information(các thông tin khác) đưa ra những thông tin thêm vào. vd test tính tương thích trên IE bị lỗi, thêm vào thông tin có thể trên chrome cũng lỗi. _upload file: đính kèm hình ảnh lỗi. public:tất cả mọi người đều xem được private: chỉ những người trong dự án. _reproducibility: khả năng tái hiện lỗi.(độ lặp lại, tần suất xuất hiện lỗi) always, sometimes, random(ngẫu nhiên) do lập trình lập trình bắt lỗi, have not try: chưa thử, unable to reproduc

Severity:  Mức độ nghiêm trọng(chức năng chính không làm việc, hoặc ảnh hưởng tới các chức năng khác) critical: nghiêm trọng non-critical:không nghiêm trọng. không ảnh hưởng tới chức năng chính của chương trình Priority: Độ ưu tiên. xét về mặt thời gian để fix các lỗi urgent:khẩn cấp low:thấp Các loại lỗi: bug UI bug function bug performance bug security bug enviroment bug non-functional bug user-friendly

* Lỗi là sự cố gây ra cho chương trình làm nó không đáp ứng được yêu cầu của người sử dụng. Những người tìm ra lỗi: Test, QA, Developer, Customer. Nguyên nhân gây ra lỗi: _yếu tố con người: hiểu yêu cầu không đúng, hiểu sai requirement. phân tích sai, lập trình sai, thừa, thiếu chức năng. hiểu sai đi yêu cầu thực test chương trình phải làm --> do tài liệu không rõ ràng. khi lập trình hay test lại không trao đổi với BA --> mường tượng theo ý mình. làm sai yêu cầu, không sát yêu cầu. _yếu tố môi trường: bộ nhớ có đủ không? có yêu cầu chương trình cài đặt đi kèm? có bị xung đột với chương trình nào trên máy k? * Phân biệt lỗi: _error: hành động của con người có thể gây ra: viết tài liệu sai, code sai, thiết kế testcase sai, thiếu, tạo ra fault. _fault: khi chạy fault ra failure là trạng thái khi fault được thực thi. _failure: là trạng thái sai của chức năng chương trình. vd: bug hàm update k đúng --> tổng số tiển cập nhật lại không đúng --> là failure.