PHP Test tools: How to use SimpleTest in Eclipse (part 1)

Cài đặt SimpleTest trong Eclipse

• Cài đặt từ Remote Site

• Cài đặt từ Local Site

Cấu hình SimpleTest trong Eclipse

1. Chọn Window > Preferences… trên menu bar
2. Chọn “Simple Test” trong danh mục liệt kê bên tay trái.
3. Nhập hoặc chọn đường dẫn tới file php.exe
4. Nhập định dạng file cho file dùng để test. Ví dụ “.php” hooặc “.test.php”.
5. Click OK.

Sử dụng SimpleTest trong Eclipse

• Tạo mới một PHP Project với tên là Test gồm các thư mục con:
  • Test\classes: dùng chứa các class cần test.
  • Test\test: chứa các file test.
• Tạo files Calculator.php trong thư mục ‘classes’.

<?php
class Calculator{
  function add($x, $y){
    return $x + $y;
  }

  function subtract($x, $y){
    return $x - $y + 1; // Hiện thực sai
  }
}
?>

• Tạo file testCalculator.php trong thư mục ‘test’.

<?php
require_once(dirname(__FILE__). '/../classes/Calculator.php');
class testCalculator extends UnitTestCase {
	function test_exists(){
		$url = dirname(__FILE__);
		$this->assertTrue(file_exists($url . '/../classes/Calculator.php'),"File not existed at $url");
	}

	function test_add(){
		$cal = new Calculator();
		$result = $cal->add(1,2);
		$this->assertEqual(3, $result, "Passed");

	}

	function test_subtract(){
		$cal = new Calculator();
		$result = $cal->subtract(1,2);
               $this->assertEqual(-1, $result, " Value what we expected is '-1' is not equal '$result' which is returned from subtract function");
	}

}
?>

• Chọn Run As > Simple Test (hoặc tổ hợp phí Alt+Shift+X, G). Hộp thoại kết quả sẽ xuất hiện như sau:

Failed Testing

• Cửa sổ kết quả cho thấy phần hiện thực hàm “subtract” của lớp Calculator đã hiện thực sai. Sửa lại file Calculator.php như sau:

<?php
class Calculator{
  function add($x, $y){
    return $x + $y;
  }

  function subtract($x, $y){
    return $x - $y + 1; // Hiện thực sai
    return $x - $y;
  }
}
?>

• Chọn Run As > Simple Test, kết quả như sau:

Passed Testing

Một số lưu ý:

• Không có yêu cầu cụ thể đối với việc đặt tên file dùng để test (nhưng nên theo chuẩn).
• Tên function trong file test (cụ thể là testCalculator.php) phải bắt đầu bằng tiền tố “test” (không phân biệt chữ viết hoa hay chữ viết thường).
• Có thể test trực tiếp qua browser, khi đó:
  • Download và giải nén gói simpletest ở trang http://simpletest.org/en/download.html
  • Chép thư mục simpletest vào trong thư mục Test/test/ chung với file testCalculator.
  • Thêm dòng lệnh sau vào đầu file testCalculator.php:

        require_once(dirname(__FILE__) . '/simpletest/autorun.php');

  • Mở browser (IE, Firefox, Safari…) gõ vào url  sau đây, trường hợp của mình file testCalculator nằm trong thư mục /demo/Test/test/:

        http://localhost/demo/test/test/testCalculator.php

  • Kết quả sẽ như sau:
  

  Passed Testing in Safari Browser

Resource:

• http://simpletest.org/eclipse/readme.html

PHP test tools: SimpleTest or PHPUnit

Trang opensourcetesting.org giới thiệu 9 công cụ hỗ trợ tiến trình Unit Test đối với lập trình PHP gồm có:

• Amock
• izh_test
• PHP Assertion Unit Framework
• PHPUnit (dựa trên nền tảng JUnit)
• PHPUnit (trong gói PEAR)
• Simple Test
• Spike PHPCheckstyle
• Spike PHPCoverage
• Testilence.

Tuy nhiên, căn cứ vào số lượng download, có thể thấy nổi bật lên trong số đó chính là Simple Test (>100k lượt) và PHPUnit (>35k lượt).

Simple Test chủ yếu được phát triển bởi Marcus Barker và một số thành viên khác trong khi đó PHPUnit được phát triển bởi  Sebastian Bermann dựa trên nền tảng của JUnit nên có vẻ phát triển ổn định và được hỗ trợ bởi một cộng đồng lớn hơn so với Simple Test. Điều này thể hiện qua việc việc PHPUnit đã đưa ra phiên bản 4.0 so với phiên bản 1.0.1 của Simple Test.

Vậy chúng ta cần gì ở một PHP test tools:

• Hỗ trợ mô hình test tăng dần, cho phép tạo các test case trước khi triển khai.
• Hỗ trợ quá trình test qua browser hoặc command-line.
• Có thể thực hiện cả việc test độc lập, theo nhóm và các bài test tổng thể
• Có thể customize phần hiển thị kết quả.
• Cho phép kiểm tra cấu trúc của lớp.
• Kiểm tra các biệt lệ và sự kiểm soát biệt lệ.
• Cung cấp các plug-in để tích hợp với IDE

May thay, cả SimpleTest và PHPUnit đều đáp ứng được hầu hết những yêu cầu đó. Tuy nhiên, mỗi công cụ cũng có những ưu và nhược điểm riêng:

Về phía PHPUnit.

• Ưu điểm:
  • Được sử dụng và hỗ trợ rộng rãi từ cộng đồng  Zend: Cập nhật thường xuyên, mức độ lỗi ít, tài liệu chi tiết.
  • Có thể tạo nhiều loại report khác nhau.
• Khuyết điểm:
  • Mock Objects được đưa ra trong phiên bản PHPUnit 3 song vẫn chưa thể sánh bằng SimpleTest
  • Không thực thi trực tiếp từ browser.
  • Ít chức năng hơn Simple Test

Về phía SimpleTest.

• Ưu điểm:
  • Hỗ trợ Mock Objects mạnh mẽ
  • Hoạt động chung với PHPUnit
  • Có thể thực thi trực tiếp từ browser lẫn command-line.
  • Có thể test cả hành vi lẫn trạng thái của đối tượng.
  • Người dùng  Drupal có thể cài đạt module để sử dụng SimpleTest
• Khuyết điểm:
  • Phần tài liệu không bằng PHPUnit
  • Cần thêm sự bổ sung mở rộng để dùng chung với Zend Framework

Mock Objects mô phỏng lại các đối tượng thực sự trong ứng dụng, chúng cũng có các phương thức giống như các đối tượng mà nó mô phỏng, chính vì vậy nó thường được tạo ra nhằm kiểm tra tính đúng đắn của một đối tượng phụ thuộc vào đối tượng mà nó mô phỏng.

Như chúng ta đã biết, trong các ứng dụng, một đối tượng thường phụ thuộc vào sự tồn tại của một (hay nhiều) đối tượng khác, chính vì vậy sẽ gây ra trở ngại khi phải thực hiện công đoạn Unit Test (mục đích là cách ly các thành phần của ứng dụng).

Giả sử có class StudentBSO cung cấp các business services cho các đối tượng Student và sử dụng StudentDAO để lưu dữ liệu vào database. Khi muốn test class StudentBSO, chúng ta chỉ cần gọi đối tượng mock object mô phỏng đối tượng StudentDAO, thực hiện triệu gọi các phương thức với các đối số tương ứng (đã được xác định) nhằm đạt được kết quả mong muốn thay vì phải gọi trực tiếp tới đối tượng StudentDAO.

Về mặt tính năng, giữa chúng có nhiều tính năng tương đồng và dễ dàng tích hợp với người dùng Eclipse. Nếu như trước đây người dùng PHPUnit cảm thấy yếu thế hơn khi mà PHPUnit không hỗ trợ Mock Object thì giờ đây, từ phiên bản 3 đã hỗ trợ Mock Object (tuy vẫn còn rất hạn chế) và nhiều tính năng khác như Database Testing… Tuy nhiên, người dùng SimpleTest có thể thực sự thấy quá trình Test thực sự “Simple” bởi những tính năng mà nó đem lại.

Resource:

• http://simpletest.sourceforge.net/en/
• http://www.phpunit.de/
• http://baphled.wordpress.com/2009/01/28/simpletest-vs-phpunit/

Functional Point Analysis (cont) – II

Trước khi bắt đầu mình sẽ giới thiệu lại quy trình tính toán FP như sau:

1. Xác định kiểu đo lường (ước lượng cho dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)
2. Xác định phạm vi của dự án.
3. Xác định số lượng Function Points thô (Unadjusted Function Points)
4. Xác định hệ số cân đối (Value Adjusted Factors).
5. Xác định số lượng Function Points cân đối (Adjusted Function Points).

Step 1: Xác định kiểu đo lường (Type of Count)

Bước đầu tiên trong phương pháp FPA đó là xác định loại dự án cần ước lượng. Do đó, việc xác định số lượng FPs có thể là việc xác định số lượng FPs của một dự án hoàn toàn mới (Development Project FP Count), số lượng FPs của việc nâng cấp một dự án (Enhancement Project FP Count) hoặc đơn giản chỉ là đánh giá lại một dự án hoàn thành (Application FP Count).

Step 2: Xác định đường biên (boundary) của ứng dụng

- Ứng dụng mà bạn đang xây dựng là ứng dụng độc lập (standalone) hay chỉ là một phần trong một gói (suite) ứng dụng. Nghĩa là nguồn cung cấp dữ liệu để ứng dụng của bạn hoạt động là “nguồn tự cung tự cấp” hay là từ một ứng dụng nào đó. Chẳng hạn như khi một trường đại học muốn gửi thông báo về kết quả của một sinh viên cho gia đình của sinh viên đó, thì nó “hệ thống quản lý điểm thi” phải lấy dữ liệu (tức là thông tin liên lạc của sinh viên đó) từ hệ thống “quản lý sinh viên”.

- Việc xác định đường biên của ứng dụng là rất quan trọng, nó ảnh hưởng trực tiếp lên độ phức tạp của ứng dụng, bởi vì việc phát triển một ứng dụng standalone bao giờ cũng đơn giản hơn các ứng dụng trong các “gói” ứng dụng. “Tiền của tui tui xài!”, dĩ nhiên là cảm thấy “thoải mái” hơn là sử dụng tiền của người khác vì bạn không bị phụ thuộc, và rõ ràng những thay đổi xảy ra đối với cá nhân khác không làm ảnh hưởng lớn đến “việc xài” của bạn. Nó cũng tương tự như trong một dự án, sự trì trệ tại một khâu, một giai đoạn nào đó trong chu trình phát triển sẽ ảnh hưởng lên toàn bộ chu trình. Hay như việc phát triển các phần mềm quản lý nhân viên, quản lý tiền lương riêng lẻ bao giờ cũng đơn giản hơn là việc phát triển một gói giải pháp ERP cho doanh nghiệp rồi! Dĩ nhiên ưu điểm của ERP là tài nguyên được sử dụng hiệu quả hơn song đó cũng chính là vấn đề của nó, làm thế nào để sử dụng hiệu quả nguồn tài nguyên đó!

- Giả sử chúng ta cần xây dựng một ứng dụng “đơn giản” nhằm quản lý điểm cho sinh viên, đồng thời khi có yêu cầu, ứng dụng sẽ in ra kết quả thi và gửi đến gia đình sinh viên đó. Chúng ta giả định rằng, không hề có một ràng buộc nào về một học kỳ phải học những môn học nào, đơn giản, chúng ta có một danh sách các sinh viên, danh sách các môn học và chi tiết điểm của sinh viên cho tất cả các môn học đó (không giống như thực tế lắm vì nếu có một số môn chưa học thì kết quả bằng “zero”… nhưng giả định để cho đơn giản mà).

- Như vậy về mặt CSDL ta sẽ có như sau

• SinhVien(MaSV, HoTen, MaLop)
• MonHoc(MaMH, TenMH, SoTinChi)
• KetQua(MaSV, MaMH, Diem)

- Một lưu ý là thông tin chi tiết của một SinhVien có thể truy xuất từ hệ thống quản lý SinhVien với CSDL như sau (đã lược bỏ một số thông tin)

• SinhVien(MaSV, HoTen, NgaySinh, DiaChiNha, PhuongXa, QuanHuyen, TinhThanhPho)

Như vậy bạn có thể xác định được boundary của ứng dụng của bạn như sau

Step 3a: Xác định FP thô (UFP)

Độ phức tạp của ứng dụng phụ thuộc vào hai yếu tố, đó là mức độ phức tạp của dữ liệu (data) và mức độ phức tạp của việc xử lý (transaction). Do đó, việc xác định UFP là công việc xác định số FPs của dữ liệu (Data Function Points)và số FPs của xử lý (Transaction Function Point).

Data FPs thể hiện khía cạnh dữ liệu trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi hai yếu tố ILF (Internal Logical File) và EIF (External Interface File). Việc xác định ILF hay EIF cần được thực hiện trước khi tiến hành chuẩn hóa (normalize) dữ liệu.

- Một ILF là một nhóm các dữ liệu được lưu trữ và bảo trì trong phạm vi hệ thống (bên trong boundary). Thông thường nó là một bảng (table) trong cơ sở dữ liệu của ứng dụng.

- Một EIF cũng là một nhóm dữ liệu nhưng được lưu trữ và bảo trì bởi một ứng dụng khác (bên ngoài boundary). Dĩ nhiên, một EIF này có thể là một ILF của một ứng dụng khác. Thông thường EIF được cung cấp thông qua các services. Chẳng hạn như các services chứng khoán, bảng ngoại tệ, thời tiết…

Transaction FPs thể hiện khía cạnh xử lý của ứng dụng trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi ba yếu tố EI (External Inputs), EO (External Outputs), External Inquiries (EQ).

- Một EI là một tiến trình căn bản (element process) trong đó dữ liệu được truyền từ bên ngoài vào bên trong của boundary. Thông thường EI là các thao tác thêm, xóa, cập nhập dữ liệu trong cơ sở dữ liệu

- Một EO là một tiến trình căn bản (element process) trong đó dữ liệu phát sinh (derived data) được truyền từ bên trong ra bên ngoài boundary. Dữ liệu phát sinh đó thường là các dữ liệu được kết hợp với nhau bằng các công thức tính toán như SUM, AVERAGE… Dĩ nhiên, các dữ liệu phát sinh này không xuất hiện trong các ILF hay IEF. Thông thường các EO là bảng báo cáo (reports), các thông báo hay dữ liệu gửi tới các ứng dụng khác.

- Một EQ là một tiến trình căn bản (element process) có hai chiều nhập dữ liệu (input) và xuất dữ liệu (output) nhằm truy xuất dữ liệu từ một hay nhiều ILF/EIF. Trong đó dữ liệu nhập (input) không làm thay đổi dữ liệu của ILF/EIF và dữ liệu xuất không chứa các dòng dữ liệu phát sinh (derived data). Thông thường, EQ là các thao tác tìm kiếm, truy vấn dữ liệu từ các ILF/EIF.

Lưu ý: Tiến trình căn bản (element process) là một xử lý đơn vị đối với người dùng (có nghĩa với họ). Ví dụ, người dùng yêu cầu chức năng thêm một sinh viên với mô tả là một sinh viên có mã số sinh viên, họ tên sinh viên… thì tiến trình căn bản chính là “thêm một sinh viên” chứ không phải là thêm một họ tên, mã số sinh viên…

Cách tính UFP

1. Xác định độ phức tạp cho các ILF và EIF: Gồm việc xác định số lượng ILF và độ phức tạp (Complexity) của mỗi ILF thông qua việc xác định số lượng RETs và DET
   • Xác định số lượng ILF.
   • Xác định độ phức tạp của mỗi ILF bằng cách tính số lượng DETs (Data Element Type) và số lượng RETs (Record Element Type). Trong đó, DETs là các cột (field) dữ liệu, còn RETs là nhóm các cột dữ liệu (có quan hệ phụ thuộc vào nhau, được cập nhập cùng nhau). Để xác định các RETs, thông thường người ta sử dụng phương pháp chuẩn hóa cơ sở dữ liệu.
   • Từ độ phức tạp tính được số FP tương ứng.

   

2. Xác định độ phức tạp cho các EI: Căn cứ vào số lượng FTR (File Types Referenced) và DET (Data Element Types) để quyết định độ phức tạp của mỗi EI.
   • Xác định các EI có trong dự án.
   • Tính FTRs và DET cho mỗi EI. Trong đó, mỗi FTR phải là một ILF hoặc một IEF mà EI đó tương tác. Còn DET là mỗi dòng dữ liệu nhập (Data Input Field), thông báo lỗi(error message), thông báo xác nhận (confirm message), buttons, mỗi nhóm radio buttons, check boxes, listbox…
     • Mỗi DATA INPUT FIELD được tính là 1 DET
     • Tất cả các ERROR MESSAGE được tính là 1 DET
     • Tất cả các CONFIRM MESSAGE được tính là 1 DET
     • Mỗi BUTTON được tính là một DET.
     • Mỗi RADIO BUTTON GROUP được tính là 1 DET
     • Mỗi CHECK BOX được tính là 1 DET
     • Mõi LISTBOX, DROP-DOWNLIST… được tính là 1 DET

     

3. Xác định độ phức tạp cho các EO: Hoàn toàn tương tự như cách xác định FP cho EI.
   • Xác định các EO có trong dự án.
   • Tính FTRs và DETs cho mỗi EI để suy ra độ phức tạp và số lượng FPs tương ứng. Trong đó số lượng DET được xác định như sau:
     • Mỗi cột dữ liệu đọc được từ ILF, EIF được tính là 1 DET.
     • Mỗi dữ liệu phát sinh (derived data) được tính là 1 DET.
     • Các error message được tính là 1 DET.
     • Các Confirm message được tính là 1 DET.
     • KHÔNG TÍNH tiêu đề (heading) của cột, ngày tháng ngày lập báo cáo. Chỉ tính ngày tháng là một DET nếu nó là dữ liệu có ý nghĩa trong kinh doanh (như lập hóa đơn, ngày đăng ký…
       

       

4. Xác định độ phức tạp cho các EI: Như đã biết, mỗi EI là một tiến trình xử lý gồm hai chiều (thể hiểu như gồm EI và EO). Do đó số lượng FTRs và DETs cuối cùng là sự kết hợp giữa FTRs và DÉTs phía EI và EO. Điều này có nghĩa là nếu cả phía EI và EO cùng sử dụng một FTR thì FTR đó chỉ được tính là MỘT. Tương tự như đối với DET.

Sau khi xác định được độ phức tạp của ta sẽ tính được số lượng FP tương ứng với mỗi EI, EQ, EO.

Cuối cùng ta tính được UFP dựa vào bảng sau. Tạm thời ta chỉ quan tâm tới Total Number of Unadjusted Function Points (Trong bài viết sau sẽ trình bày cách tính Value Adjustment Factor và Total Adjusted Function Points)

Tổng quan về Function Point Analysis (FPA) – P1

1. Giới thiệu

Khi bắt tay vào việc thực hiện một dự án, điều bạn băn khoăn đó là làm sao có thể xác định được khối lượng công việc, từ đó có thể tính toán được chi phí về tài nguyên (con người, thời gian, tiền bạc…). Ví dụ như xây một ngôi nhà cần hết bao nhiêu ngày công, khối lượng vật liệu cần thiết, số lượng nhân công, thời gian thực hiện các công đoạn nhỏ như đào móng, xây tường, đổ bê-tông… để cho ngôi nhà được hoàn thành đúng dự kiến. Để tính được khối lượng công việc cho một dự án phần mềm, người ta dùng phương pháp Function Point Analysis (FPA).

FPA là một phương pháp được ISO chấp nhận, dùng để xác định kích thước về mặt chức năng (functional size) của một hệ thống thông tin. Functional size phản ánh số lượng chức năng liên quan tới và được chấp nhận bởi người dùng trong doanh nghiệp. Nó hoàn toàn độc lập với công nghệ được sử dụng để triển khai hệ thống.Đơn vị dùng để đo lường được gọi là function points (FPs) cũng tương tự như để đo khối lượng, người ta sử dụng “kilôgram”, đo độ dài người ta dùng “mét”…Chính vì vậy, phương pháp FPA biểu diễn độ lớn của hệ thống thông tin bằng số lượng các FPs. Ví dụ như độ lớn của một hệ thống X là 256FPs.Khái niệm FP được đưa ra bởi Allan Albrecht vào giữa những năm 1970 nhằm thay thế cho phương pháp đo lường kích thước phần mềm bằng cách đếm số dòng code, sau đó được IBM xuất bản vào năm 1979, và sau đó là IEEE tái bản vào năm 1981.

2. Mục tiêu

• Tính toán số chức năng dựa trên góc nhìn từ phái end-users về các chức năng của hệ thống.
• Giảm thiểu hóa công sức, chi phí dùng cho việc tính toán, đo đạc.
• Thiết lập nên một phương pháp đo đạc thống nhất giữa các tổ chức.

3. Lợi ích

• Có thể xác định được kích thước của phần mềm từ sớm trong quy trình phát triển.
• Giữ vai trò như một phương pháp đo đạc căn bản, tăng cường năng suất.
• Độc lập với công cụ và môi trường phát triển.
• Cung cấp phương pháp đo lường kích thước thống nhất giữa các nhóm và tổ chức.
• Là công cụ quan trọng để xác định năng suất, ước lượng chi phí, công sức…

4. Quy trình ( 5 bước)

1. Xác định loại dự án (phát triển dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)
2. Xác định phạm vi của dự án.
3. Xác định số lượng Function Points thô (Unadjusted Function Points)
4. Xác định hệ số cân đối (Value Adjusted Factors).
5. Xác định số lượng Function Points cân đối.

Chứng khoán “câu giờ” chờ động thái mới của UBCK?

Bằng một loạt các chính sách điều chỉnh, nỗ lực từ phía UBCK nhằm “cứu” chứng khoán xem ra đang rất khả dĩ, đơn giản vì NĐT không còn cảm thấy “đau đầu” khi CK liên tục rớt sàn. Biện pháp giảm biên độ giao động, đồng thời kêu gọi các ngân hàng ngừng việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán (tức là các hợp đồng mua bán chứng khoán có kỳ hạn)… đã phần nào ổn định được tâm lý đang vô cùng hoang mang của các NĐT. Tức là UBCK chưa phải viện đến chiêu thức đóng cửa TTCK.

“Màu xanh” đã trở lại, nhưng thực chất, VN-Index chỉ “nhích” lên 3-4 điểm mỗi phiên. Với “tốc độ” kiểu này còn lâu mới đạt được ngưỡng 600, đừng nói gì là cái mốc 900 vốn được nhiều người dự đoán là cái mốc lý tưởng. Rõ ràng, những NĐT không trông đợi vào cái kiểu “ổn định” như thế. CK Việt gần đây liên tục gặp những tình huống dở khóc dở cười, “lúc bán không ai mua”, “lúc mua không ai bán”. Với cảnh mua bán một chiều như thế này thì CK cần có những đợt “sóng” và với cơ chế như hiện tại thì khó lòng mà đạt được điều mong mỏi ấy. Nhưng để như vậy thì biên độ dao động phải được trở lại trạng thái 5% (HOSE) và 10% (HASTC) thay vì 1% và 2% như hiện tại. Vấn đề là bao giờ? Khi mà việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán trước sau gì cũng phải được thực hiện.

Kinh nghiệm từ đợt rớt sàn “lập đáy” mới trước cho thấy, chỉ sau 3 phiên tăng trần, các NĐT lướt sóng lập tức bán tống bán tháo ngay đi các CP bởi lợi nhuận mà họ kiếm được đã ở mức 10-15% – một con số có thể làm hài lòng bất kỳ NĐT nào. Và hệ lụy là CK trở lại với “quỹ đạo rơi tự do” và liên tục phá đáy xuống dưới 500 điểm. Rất có thể lịch sử sẽ lập lại bởi lợi nhuận 3-5% cũng không quá tồi. Và sau đó…

Các chính sách hiện tại có vẻ như đang “kéo giò” nhau chỉ để chờ những động thái tích cực mới từ phía UBCK song với cá nhân của một kẻ “ngoại đạo” như tôi thì tôi vẫn mong cái biện pháp giảm biên độ dao động sẽ diễn ra trễ hơn thời điểm 27/03 hoặc trong tình thế này nó sẽ kết thúc sớm hơn việc thực hiện giải chấp của các ngân hàng (chắc chắn là vậy nhưng là bao giờ). Và liệu có khi nào, CK áp dụng biên độ dao động khác nhau cho những ngày khác nhau không nhỉ? Chẳng hạn như biên độ 5% đối với thứ 3, còn lại là 1%… Hay là giờ đang đà tăng, cứ khôi phục lại biên độ cũ, khi nào giảm lại hạ biên độ!!! Đó cũng chỉ là những biện pháp tình thế mang tính chất chắp vá cho đến khi TTCK đạt tới “trạng thái lý tưởng”. Đó chỉ là cái nhìn bi quan!

Trở lại với cái nhìn lạc quan, giá CP đã xuống tới mức “vô lý”, do đó, việc mua vào lúc này sẽ trở nên không thể “hợp lý” hơn. Kết quả là, rất có thể, đây chính là cú “hích” giúp CK trở lại đà tăng trưởng.

Và dù thế nào đi nữa, trở lại vấn đề đã đặt ra, cái biện pháp giảm biên độ dao động đến hồi sẽ phải được tháo dỡ! Khả năng sẽ là đầu tháng 4. Nhưng mong là đừng có trúng ngày 1/4 vì lúc đó không biết nên tin ai đâu đấy!