Bài 1: Bắt đầu với Android Studio

Mục tiêu

  • Nắm được kiến thức cơ bản về hệ điều hành Android
  • Tạo thử 1 project
  • Cấu hình môi trường phát triển
  • Tạo Emulator để chạy thử chương trình

1. Hệ điều hành Android

  • Dựa trên linux
  • Phát triển bởi Android Inc.
  • Google mua lại vào năm 2005
  • Mã nguồn mở, giấy phép Apache
  • Hơn 2 triệu ứng dụng ở nhiều hạng mục khác nhau

2. Các phiên bản

androidversion

 

 

 

3. Ảnh hưởng gì tới DEV

  • Không thể chỉ dựa vào API level hỗ trợ tính năng gì
  • Cần phải có kế hoạch cụ thể
    • Kiểm tra sự hiện diện của tính năng
    • Xử lý runtime error nếu hàm bị fail và cung cấp các lựa chọn khác

4. Phần cứng hỗ trợ

  • ARM processor
  • Intel Atom line of x86 Processor

5. API level

  • Là phiên bản cụ thể các API của Android framework
  • Việc chỉ ra ứng dụng phát triển trên API phiên bản nào phụ thuộc vào mong muốn các features trên API đó có thể dùng trong app, bao gồm
    • Packages và classes có thể dùng
    • XML elements & attributes
    • Activities có thể được gọi
    • Các Permissions app có thể yêu cầu
    • Cách thức app phải yêu cầu permission (trước khi cài đặt hay trong khi chạy)
  • API level mới thì sẽ hỗ trợ nhiều tính năng mới nhưng app có thể không tương thích với các máy chạy OS cũ
  • Các bản cập nhật của Android đảm bảo tương thích ngược (các hàm được nâng cấp không bị remove đi mà đánh dấu là deprecated >> app vẫn sử dụng được API cũ)
  • Vấn đề lựa chọn API level sẽ đáp ứng nào rất quan trọng

6. Các thư viện hỗ trợ (support libraries)

  • Có một số APi mới quan trọng được đóng gói trong các thư viện hỗ trợ để cho phép các thiết bị chạy ở phiên bản cũ hơn có thể chạy được các API mới này.
  • Ex: Fragment giới thiệu trong API level 11 nhưng có thể được sử dụng ở thiết bị chạy OS thấp hơn thông qua việc sử dụng thư viện hỗ trợ

7. Kiến trúc Android

androidarchitecture

  • Inter-application communication: thông qua rich messaging system
  • Ví dụ: khi app muốn đáp ứng tính năng phone call thì không cần viết code từ đầu trên APP mà gọi sang phone app để thực hiện

8. Android Runtime

androidruntime

  • Mỗi ứng dụng chạy trên 1 Linux process
  • Mỗi Android process chạy trên 1 thực thể ART
  • Một app bị crash không ảnh hưởng tới app khác
  • Đảm bảo security hơn, khó khăn hơn để 1 process này truy cập vào tài nguyên của process khác nếu không được phép

9. Máy ảo Dalvik

  • ART: Ahead Of Time compiler
  • Dalvik: runtime environment, Just In Time compiler (compile khi ứng dụng thực thi)
  • Từ Android 5.0 ART thay thế hoàn toàn Dalvik
  • Android 7.0 Google bổ sung JIT compiler vào ART >> giảm thời gian cài đặt và kích thước mã nguồn được biên dịch

10. Android Multitasking

  • UI component người dùng đang tương tác trực tiếp sẽ được focus
  • UI ngoài view sẽ bị tự động suspend để tối ưu tài nguyên
  • Android hỗ trợ chạy đa luồng thông qua background thread và callback functions
  • Có notify khi app bị suspend >> cho phép xử lý cất lại trạng thái
  • Nên cài đặt các tác vụ mất thời gian ở background
  • Nếu luồng chính của app có tác vụ mất nhiều thời gian xử lý thì hệ thống sẽ tự động tắt tiến trình app đó và hiển thị message Application Not Respoding (ANR) cho người dùng.

11. Các công cụ để phát triển

  • Java SE Development Kit (JDK)
  • Android SDK
  • Android Studio
  • Android Virtual Device Manager

Ref: https://developer.android.com/studio/

12. Android studio

  • Phát hành lần đầu năm 2014
  • Thay thế Eclipse và ADT
  • Tích hợp trong 1 IDE, không phải tải nhiều plugin

adroidstudio

Android studio Menus

adroidstudiomenu

Android studio Tool Windows

adroidstudiotools

Emulator

androidemulator

  • Cung cấp giao diện như thiết bị thật
  • Cho phép thao tác gestures: tap, swipes, pinches…
  • Cho phép thực hiện các tính năng vật lý: quay thiết bị…
  • Cho phép cấu hình giả lập phần cứng: SD card, GPS, Camera…
  • Có thể chạy ở các chế độ bộ nhớ khác nhau
  • Thiết lập ở các chế độ kích thước màn hình khác nhau

13. Android SDK Manager

adnroidsdkandroidsdkdefault

14. Command line tools

  • Đi kèm với SDK Manager
  • Độc lập với API
  • Thao tác nhanh hơn: check & update, create emulator, format emulator’s SD card, build release package…

15. Android studio setting

androidstudiosetting

  • Appearance & Behavior
  • Keymap
  • Editor
  • Plugins
  • Version Control
  • Build, Execution,
  • Deployment
  • Languages & Frameworks
  • Tools

16. AVD Manager

avdmanager

  • Tool cho phép tạo emulator để test ứng dụng
  • Chỉ định các đặc tính: hardware profile, device model, API platform, ABI (application binary interface) của virtual image
  • Cấu hình: device’s name, emulated camera, network performance, Graphic performance, Memory…

17. Emulator controls

emulatorcontrols

  • Set GPS location for device.
  • Change status of device’s cellular connection.
  • Change status of device’s battery.
  • Place a phone call.
  • Send an SMS message.
  • Set miscellaneous AVD settings.

———————- END ————————–

Advertisements

Cách cho thai nhi nghe nhạc khoa học nhất .

Nên cho bé nghe nhạc gì?

Nhạc cổ điển là lựa chọn số 1 của bạn. Những âm thanh nhẹ nhàng, du dương với tiết tấu mềm mại làm bà bầu và thai nhi cảm thấy dễ chịu hơn. Ví dụ như những bản sonat, conceston của Beethoven, Mozart, thể loại Baroque của Vivaldi, Teleman và Handel, những bài đồng dao, hát ru dân gian… Âm thanh lộn xộn của Rap, Rock thật sự là không phù hợp và làm cho chức năng não bộ của bé bị thay đổi không tích cực, tâm tính không ổn định.

Bạn cũng nên lựa chọn những loại nhạc có âm thanh vui nhộn, ca từ trong sáng, mượt mà. Tâm trạng của mẹ bé tốt, bé cũng sẽ “thơm” lây.

Nghe vào thời điểm nào?

Theo các nhà khoa học thì bà bầu bắt đầu cho thai nhi nghe nhạc vào khoảng tuần thứ 22 trở đi. Cụ thể các giai đoạn nghe theo cách phân chia như sau:
1. Đầu tiên là giai đoạn bước đệm dành cho bà bầu mới bắt đầu nghe nhạc.
(Khoảng sau tuần 16 bé bắt đầu cảm nhận được âm thanh từ bên ngoài vào, tốt nhất cho bé nghe nhạc từ tháng thứ 5)

2. Giai đoạn thứ 2 là thai nhi từ 22-32 tuần tuổi.

3. Giai đoạn thử 3 là thai nhi từ 33-40 tuần tuổi.

4. Bé mới sinh đến 1 tháng tuổi vẫn duy trì nghe những bản nhạc cũ trước đây.

5.Từ -3 tháng tuổi, bé nghe những bản nhạc mới kết hợp với trò chơi để tập trung phát triển trí tuệ cảm xúc và thể chất.

Một điều đặc biệt các bà bầu cần lưu ý là thai nhi thường thức giấc khi bạn thư giãn và ngủ khi bạn hoạt động nên bạn chọn thời điểm cho thai nhi nghe là vào lúc bé thức giấc. Thời điểm nghe có thể là lúc bạn nằm thư giãn trên giường hoặc trong bồn tắm.

Đồng thời, nhẹ nhàng xoa đều bụng bầu để bé cảm thấy hơi ấm từ bàn tay bạn. Còn gì thích bằng khi được chìm mình trong một giai điệu du dương và cảm nhận tình yêu thương từ mẹ…

 

Nghe bằng tai nghe hay bật loa to?

Chú ý: Tiến sỹ Rosalie Pratt, thuộc trường đại học Brighham Young, Utah cho rằng, nếu cho bé nghe bằng loa to thì âm lượng không nên mở quá 70 decibel. Âm thanh to quá sẽ khiến thai nhi giật mình khó chịu.

 

Nghe bao nhiêu thì đủ?

Thời gian nghe không quá 20 phút mỗi lần. Một ngày bạn có thể cho bé nghe từ 2-3 lần.

Những bản nhạc dành cho thai nhi.

  • Giai đoạn bước đệm (từ 16- 22 tuần tuổi)

Theo các nhà khoa học nên cho bé nghe nhạc từ tuần thứ 22, như vậy không có nghĩa trước đó bé không được nghe nhạc, bởi từ tuần thứ 16 bé đã có thể cảm nhận được những xung âm thanh từ bên ngoài truyền vào.

Bạn có thể cùng bé thư giãn bằng những tiết tấu du dương, êm đềm, không phức tạp… Những cung bậc nhẹ nhàng này giúp bạn và thai nhi cảm thấy thoải mái để chuẩn bị cho những biến đổi mạnh mẽtrong giai đoạn tiếp theo
Hãy bắt đầu bằng việc cho thai nhi nghe những giai điệu đơn giản và lắng đọng của hai nhạc cụ: ghita và piano trong album “Ghi ta và piano cho bé”. Những âm thanh nhẹ nhàng, du dương và trầm lắng sẽ khiến tinh thần bà bầu thoải mái, thai nhi được bảo bọc an toàn về tinh thần.

 

  • Giai đoạn từ 22- 32 tuần tuổi.

Những âm thanh mà bé cần nghe trong giai đoạn này là những âm thanh êm dịu, nhẹ nhàng như nhạcđồng quê, những bài đồng dao qua tiếng thì thầm hát ru của mẹ. Theo đó, buổi sáng bạn có thể cho bé thưởng thức những âm thanh nhẹ nhàng, tươi sáng, sinh động, mang nhiều màu sắc hình ảnh. Những giai điệu du dương, mượt mà đằm thắm này sẽ kích thích khả năng hội họa và nhận cảm màu sắc của thai nhi.

Buổi tối, hãy thay đổi thực đơn cho bé bởi những giai điệu hết sức ấm áp, chan hòa, giúp bé yên tâm chìm vào giấc ngủ ngon. Nghe loại nhạc này khiến bé có được sự điềm tĩnh, cạnh đó thể chất của béđược phát triển ổn định hơn.

Các bản nhạc nên cho bé nghe trong giai đoạn này.

–  Album “Baby Mozart”

–  Album “Mozart, Beethoven và bé”

–  Album “Baby Vivaldi”

–  Album “Baby Chopin”

–  Album “Bé thông minh”

  • Giai đoạn từ 32- 40 tuần tuổi.

Giai đoạn này đồng tử của mắt bé đã bắt đầu nhận ra ánh sáng, bé có thể “lờ mờ” nhận ra bụng mẹ nhưthế nào. Nếu bạn đi siêu âm sẽ thấy bé có thể mếu, cười tủm và vặn vẹo rồi đấy…

Thai nhi giai đoạn này cần nghe nhạc hơn hết vì âm nhạc sẽ thúc đẩy sự hoàn thiện về thể chất, trí tuệ, khả năng sáng tạo và biểu lộ cảm xúc. Các mẹ bầu cần chú ý phối hợp đồng bộ các tác dụng của từng loại nhạc để mang lại cho bé sự yêu thương ngọt ngào nhất.

Các bản nhạc nên cho bé nghe trong giai đoạn này:

–  Album “Baby Chopin”

–  Album “Baby Bach”

–  Album “Phép nhiệm màu cho con”

–  Album “Những bản nhạc bất hủ của Beethoven”

–  Album “Baby Schubert”

  • Bé mới sinh đến 1 tháng tuổi: vẫn duy trì nghe những bản nhạc cũ trước đây.
    Từ 3 tháng tuổi: bé nghe những bản nhạc mới kết hợp với trò chơi để tập trung phát triển trí tuệ cảm xúc và thể chất.

Thiết kế test case sử dụng kỹ thuật phân lớp tương đương và phân tích giá trị biên

Các kỹ thuật thiết kế test case

  • Phân lớp tương đương 
  • Phân tích giá trị biên
  • Sử dụng bảng quyết định
  • Sử dụng biểu đồ nguyên nhân-hậu quả
  • Sử dụng biểu đồ chuyển trạng thái

1. Kỹ thuật phân lớp tương đương

Khái niệm: Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các trường hợp kiểm thử

Giả thiết: Nếu một giá trị trong lớp tương đương đúng thì tất cả các giá trị khác cũng đúng

Xác định các trường hợp kiểm thử

  • Chia các giá trị đầu vào, đầu ra thành các lớp tương đương nhau
  • Gán 1 giá trị cho mỗi lớp tương đương
  • Viết các trường hợp kiểm thử đảm bảo phủ được nhiều nhất có thể các lớp tương đương hợp lệ
  • Viết các trường hợp kiểm thử sao cho mỗi trường hợp kiểm thử chỉ phủ duy nhất có thể các lớp tương đương không hợp lệ

Tình huống (1) – Vé tàu

Yêu cầu: Nếu bạn mua vé tàu để đi từ 7.30 sáng đến trước 9:30 sáng hoặc sau 4:00 chiều cho đến 7:30 tối (‘giờ cao điểm’), bạn phải trả 100% giá vé. Bạn sẽ được giảm giá nếu mua vé đi tàu giữa 9:30 sáng và đến 4:00 chiều, hoặc sau 7:30 tối. Tàu không hoạt động từ 12 giờ đêm đến trước 3h sáng.

Câu hỏi: Đâu là các lớp tương đương để kiểm tra giờ tàu – giá vé?

2. Kỹ thuật phân tích giá trị biên

bugarea

  • Lỗi thường có xu hướng xảy ra ở gần giá trị biên 
  • Giá trị biên là nơi rất tốt để tìm lỗi
  • Cần kiểm tra các giá trị biên ở cả 2 phía

Tình huống (1) – Vé tàu

Yêu cầu: Nếu bạn mua vé tàu để đi từ 7.30 sáng đến trước 9:30 sáng hoặc sau 4:00 chiều cho đến 7:30 tối (‘giờ cao điểm’), bạn phải trả 100% giá vé. Bạn sẽ được giảm giá nếu mua vé đi tàu giữa 9:30 sáng và đến 4:00 chiều, hoặc sau 7:30 tối. Tàu không hoạt động từ 12 giờ đêm đến trước 3h sáng.

Câu hỏi:

  1. Đâu là các giá trị biên và các  lớp tương đương để kiểm tra giờ tàu – giá vé?
  2. Tóm tắt các TC bạn sẽ sinh ra?

3. Thực hành

Tình huống (2): ứng dụng cho vay

  • Tên khách hàng – 2-64 ký tự chữ cái + Space
  • Số tài khoản – 6 chữ số, số đầu tiên ≠ 0
  • Khoản vay – Từ £500 đến £9000
  • Kỳ hạn – Từ 1 đến 30 năm
  • Tiền trả hàng tháng – Nhỏ nhất £10
  • Thời hạn
  • Tiền trả lại
  • Lãi suất
  • Tổng số tiền phải trả

Tên khách hàng

Screen Shot 2018-05-07 at 12.04.09 AM

Số tài khoản

Screen Shot 2018-05-07 at 12.04.55 AM

Khoản vay

Screen Shot 2018-05-07 at 12.05.24 AM

Bảng tổng hợp các lớp

Điều kiện Lớp hợp lệ Mã lớp Lớp không hợp lệ Thẻ Giá trị biên hợp lệ Thẻ Giá trị biên không hợp lệ Thẻ
Tên khách hàng 2 – 64 ký tự hợp lệ V1

 

< 2 ký tự X1 2 ký tự B1 1 ký tự D1
> 64 ký tự X2 64 ký tự B2 65 ký tự D2
Các ký tự không hợp lệ X3 0 ký tự D3
Số tài khoản 6 chữ số. Chữ số đầu tiên khác 0 V2

 

< 6 chữ số X4 100000 B3 5 chữ số D4
> 6 chữ số X5 999999 B4 7 chữ số D5
Chữ số đầu tiên = 0 X6 0 chữ số D6
Không phải chữ số X7
Khoản vay 500 – 9000 V3 < 500 X8 500 B5 499 D7
>9000 X9 9000 B6 9001 D8
Không phải số nguyên X10
Giá trị

rỗng

X11

 

Thiết kế test case

Screen Shot 2018-05-07 at 12.09.12 AM

 

——–END———

Khái niệm và nguyên tắc căn bản về kiểm thử

Nội dung bài học

1. Khái niệm căn bản về kiểm thử
2. Vai trò – tầm quan trọng của kiểm thử
3. Nguyên tắc thực hiện kiểm thử
4. Xác định thời điểm kết thúc kiểm thử

1. Khái niệm căn bản về kiểm thử

  1. Khái niệm kiểm thử phần mềm
  2. Cấp độ (giai đoạn) kiểm thử
  3. Tình huống kiểm thử
  4. Loại hình kiểm thử
  5. Phương pháp kiểm thử

1.1 Khái niệm kiểm thử phần mềm

  • Khái niệm: Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả,và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.
  • Mục đích: Tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm.

1.2 Giai đoạn kiểm thử

  • Kiểm thử đơn vị– Unit testMột đơn vị-Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit.

    Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra.

    Unit Test thường do lập trình viên thực hiện trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit.

     

  • Kiểm thử tích hợp– Intergration TestIntegration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

    Hai mục tiêu chính của Integration Test:

    • Phát hiện lỗi giao tiếp xảy ra giữa các Unit
    • Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test). 
  • Kiểm thử hệ thống – System TestMục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

     

  • System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. 
  • Kiểm thử chấp nhận sản phẩm– Acceptance TestThông thường, sau giai đoạnS ystem Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

    Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

1.3 Tình huống kiểm thử

  • Positive test: Còn gọi lại clean test hay valid test. Test những trường hợp mà user sử dụng hệ thống một cách bình thường, đúng ý đồ thiết kế.
  • Negative test: Còn gọi là dirty test hay invalid test.. Test  những trường hợp user làm những hành động khác thường hay đưa vào những dữ liệu không hợp lệ.

Các điều kiện mà người ta nghĩ ra để kiểm thử một sản phẩm nào đó có thể được chia làm hai loại: (1) loại thuộc nhóm những điều kiện thông thường mà một người sử dụng theo logic thông thường sẽ tạo ra chúng, (2) loại thuộc nhóm những điều kiện chỉ xảy ra khi NSD nhầm lẫn về logic hay thao tác, hoặc có kẻ cố tình phá hoại hoặc truy cập vào những thông tin mình không được phép vào, hặc khi môi trường sử dụng phần mềm có điểm bất thường (như không kết nối được với Database, mất điện đột ngột, User không được phân quyền…). Tương ứng với đó ta có hai khái niệm: (1) positive test hay còn gọi là test sạch, và (2) negative test hay còn gọi là test bẩn.

1.4 Loi hình kim th

Ứng với mỗi khía cạnh chất lượng nào đó của sản phẩm cần test – có các loại hình kiểm thử

  • Kiểm thử chức năng (Functional Test): nhằm bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. 
  • Kiểm thử hiệu năng (Performance Test): Bảo đảm hiệu suất hoạt động của hệ thống xét về thời gian cần thiết để phản hồi cho người dùng, tài nguyên (ví dụ RAM, CPU) bị tiêu tốn. Bao gồm các test để bảo đảm tối ưu việc sử dụng bộ nhớ nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn, các test để bảo đảm hệ thống vận hành được dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc)… 
  • Kiểm thử tính dễ dùng (Usability testing): bảo đảm người dùng dể hiểu, dễ đoán cách dùng phần mềm và có thể thao tác nhanh chóng trên phần mềm để thực hiện một tác vụ nào đó.
  • Kiểm thử bảo mật (Security testing): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. 
  • Kiểm thử khả năng cài đặt (Installability testing): bảo đảm phần mềm có thể được cài đặt hoặc gỡ bỏ thành công.
  • Kiểm thử khả năng phục hồi (Recovery testing): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn địnhtrước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến… 
  • Kiểm thử tính tương thích (Compatibility testing): bảo đảm phần mềm có thể tương thích được với nhiều hệ điều hành/trình duyệt/cấu hình phần mềm/phần cứng khác nhau

1.5 Phương pháp kiểm thử

  • Kiểm thử hộp đen – Black box testing 

Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

Ưu, nhược điểm 

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

  • Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.

  • Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.

2. Vai trò – tầm quan trọng của kiểm thử

  • Chi phí phát triển phầm mềm
    • Chi phí thực thi
    • Chi phí kiểm thử
    • Chi phí sửa lỗi
  • Hiệu quả đầu tư vào Testing

Screen Shot 2018-05-06 at 11.25.51 PM

3. Nguyên tắc cơ bản trong kiểm thử

3.1 Phải truy vết từ Tests-Requirements. 

3.2 Phải chuẩn bị từ đầu dự án. 

Untitled2

3.3 Lỗi quần tụ – 20%  >> 80% lỗi

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.
=> Test kỹ chức năng quan trọng => found bug => test những gì liên quan + những chức năng gần nó để tìm ra bug nhiều hơn.

bugdensity

3.4 Phải test dần từ sớm. 

Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.

testsoon1testsoon2Screen Shot 2018-05-06 at 11.38.41 PM

3.5 Phải chú ý test các exceptions. – Kiểm thử theo các ngữ cảnh độc lập

Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau. Để hiểu rõ hơn chúng ta xem ví dụ sau:
Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:
– Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
– Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
– Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v….

Screen Shot 2018-05-06 at 11.44.30 PM

3.6 Việc sửa lỗi phải được hoạch định song song. 

Screen Shot 2018-05-06 at 11.45.25 PM

4. Xác định thời điểm kết thúc kiểm thử?

  • Không thể test hết mọi trường hợp
  • Test chỉ có thể chỉ ra rằng có lỗi chứ không thể chỉ ra rằng đã hết lỗi
  • Có thể dừng test khi
    • Rủi ro về chất lượng ở mức chấp nhận được
    • Các mục tiêu, chỉ tiêu đưa ra trong kế hoạch test đã đạt được
  • Phụ thuộc vào mức độ rủi ro của hệ thống
    • Khả năng bỏ sót những lỗi nghiêm trọng?
    • Mức độ ảnh hưởng nếu xảy ra lỗi bỏ sót?

 Nên dùng các biểu đồ, số liệu thống kê để đánh giá xu hướng lỗi của phần mềm nhằm phán đoán khả năng còn lỗi.

Screen Shot 2018-05-06 at 11.48.30 PM

——–END————