Ilovepdf Merged

Kiểm thử tự động

Là phương pháp sử dụng các công cụ phần mềm
để điều khiển quá trình thực thi kiểm thử.
14 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Đặc điểm
Sử dụng thời gian của máy tính để thực thi kiểm thử.
Thường được áp dụng cho các trường hợp kiểm thử sẵn có.

Vì sao phải kiểm thử tự động?
Thời gian dành cho việc kiểm thử là rất hạn chế.
Một số trường hợp kiểm thử

cần thực thi nhiều lần trên mỗi build của AUT.
cần được thực thi với nhiều bộ dữ liệu khác nhau.
cần được thực thi trên nhiều cấu hình phần cứng, phần mềm khác nhau.
cần rất nhiều thời gian nếu thực hiện bằng tay.
rất dễ thực thi sai nếu làm bằng tay
không thể thực hiện được bằng tay.

Mục đích của kiểm thử tự động
Tiết kiệm thời gian và chi phí
Tiết kiệm nguồn nhân lực
Giảm thiểu sai sót trong quá trình kiểm thử
Giúp tester tập trung vào các công việc kiểm thử phức tạp hơn

Chi phí của kiểm thử tự động

So sánh
Kiểm thử bằng tay Kiểm thử tự động
• Thời gian thực thi • Thời gian thự thi

• Độ bao phủ khi hồi quy • Độ bao phủ khi hồi quy
• Tự phản ứng và uyển chuyển • Tương đối kém linh hoạt
• Sai lệch giữa các cá nhân • Nhất quán trên nhiều máy tính
• Chi phí bảo trì gần bằng 0 • Chi phí bảo trì cao
• Lợi ích trong ngắn hạn • Lợi ích dài hạn
• Không hiệu quả khi hồi quy với • Không hiệu quả khi hồi quy với
số lượng lớn số lượng ít

Quy trình thực hiện kiểm thử bằng tay
Tương tác Đồng bộ

Test Engineer thực hiện Test Engineer chờ kết
các thao tác trên AUT quả phản hồi từ AUT
Tester
Báo cáo Kiểm tra
Test Engineer báo cáo Test Engineer kiểm tra
kết quả kiểm thử và tiếp và so sánh kết quả nhận
tục với trường hợp khác được từ AUT

Quy trình thực hiện kiểm thử tự động
Viết kịch bản Đồng bộ Kiểm tra Chạy tự động
1 2 3 4
• Test Engineer • Test Engineer • Test Engineer • Test Engineer

phát sinh các kịch chạy thử kịch bản xác định các chạy tự động các
bản kiểm thử tự và chỉnh sửa theo “checkpoint” và kịch bản mỗi khi
động hoạt động của chèn vào kịch bản được yêu cầu kiểm
AUT thử hồi quy

Các loại hình kiểm thử nên tự động
Kiểm thử mã nguồn
Kiểm thử đơn vị
Kiểm thử hiệu năng
Kiểm thử chức năng

Không thể (không nên) tự động
Kiểm thử tính dễ sử dụng – Usability testing
Kiểm thử một lần duy nhất (one-time)
Kiểm thử nhanh nhất có thể (ASAP, test NOW)
Kiểm thử ngẫu nhiên – Ad-hoc testing
Kiểm thử có kết quả không dự đoán trước được

Khó khăn khi tự động hóa
Xuất phát từ khả năng của các “Công cụ kiểm thử tự động” (Automation tool)
Bảo trì và Mất tập

mở rộng trung
Không Công
Lập trình
chắc chắn nghệ mới

Khi nào nên bắt đầu tự động hóa
Khách hàng yêu cầu
Sản phẩm đã ổn định
Xuất hiện các trường hợp kiểm thử lặp lại nhiều lần
Xuất hiện các trường hợp kiểm thử với nhiều bộ dữ liệu
Xuất hiện các trường hợp kiểm thử đo lường hiệu năng
Xuất hiện các trường hợp kiểm thử tiêu tốn nhiều thời gian

Nhận xét
Kiểm thử tự động: tự đông thực thi các trường hợp kiểm thử.
Kiểm thử tự động chỉ thích hợp với một số loại hình kiểm thử nhất định.
Kiểm thử tự động có ưu điểm lẫn nhược điểm khi so sánh với kiểm thử bằng tay.

Lịch sử tự động hóa
Keyword-
driven
Data-driven Từ khóa:
• Hans Buwalda, năm 1994
• Là dạng tổng quát hóa của Action
Based Testing™
Scripting
Record &
Playback
29 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

1st Record & Playback
Công cụ tự động hóa phát sinh

kịch bản tự động (script) dựa
trên các thao tác đã ghi nhận
được.
Record Thực thi
Phát sinh kịch bản

Công cụ tự động hóa ghi nhận Công cụ tự động thực thi lại
(record) các bước thực hiện việc (playback) việc kiểm thử một
kiểm thử, và sau đó tester thêm cách tự động.
vào một số điểm kiểm tra
(checkpoint) cần thiết.

Quá trình “Record and Playback”
Kịch bản • Các thao tác
(được phát sinh từ các • Các “checkpoint”
thao tác đã ghi nhận)
• Ghi nhận thao tác và Thực thi lại

các điểm kiểm tra một
lần • Thực hiện thao tác
Công cụ tự động Báo cáo
• Thực thi lại nhiều lần kết quả • Thực hiện kiểm tra
(Thường được ẩn khi
• Kết quả kiểm thử
tương tác với AUT)
Ghi nhận Thực thi lại
Thao tác được thực Target

hiện bởi tester/user System/AUT

Ví dụ: Một kịch bản được ghi nhận
select window "Logon"
enter text "username", "administrator"
enter text "password", "testonly"
push button "Ok"
select window "Main"
push button "New Customer"
expect window "Customer Information"
select field "Name"
type "Jones"
select field "First Name"
type "John"
select field "Address"
type "54321 Space Drive"
.
.

Một ví dụ khác
# Analog Recording
move_locator_track (1); mouse movement
mtype ("<T55> <kLeft>-<kLeft>+"); mouse click
type ("<t3>output14" );
move_locator_track (2);
mtype ("<T35><kLeft>-<kLeft>+");
output14
enter text pause before
from mouse click
keyboard

Hiệu quả của Record and Playback
Mỗi khi AUT có một thay đổi nhỏ, tester/user cũng phải thực thi lại các thao tác để
ghi nhận lại kịch bản mới.
→ Thế hệ kiểm thử tự động thứ nhất không hiệu quả và

không có khả năng mở rộng.
34 Kiểm thử phần mềm tự động - 2015 Nguyễn Đạt Thông

Đánh giá Record & Playback

2nd Scripting
Tự động hóa bằng cách viết kịch bản (lập trình)

Tham số hóa các giá trị hard-code
Các dữ liệu kiểm thử (test data) có thể được tách biệt dưới dạng biến toàn cục.
Tạo ra các hàm để có thể chia sẻ
Kịch bản được tạo và bảo trì như một phần mềm
Kịch bản cũng cần được kiểm thử

Ví dụ: Một kịch bản dạng “hàm”
Function EnterCustomerJones
Logon
Press "New Customer"
Enter Field "Name", "Jones"
Enter Field "First Name", "John"
Enter Field "Address", "54321 Space Drive"
...
Logoff
End Function
Function OrderProduct
Logon
Press "New Order"
Enter Field "Product", “OurProduct 1.0"
Enter Field "Amount", "35"
Enter Field "Delivery", "asap"
...
LogOff
End Function

Ví dụ: Một kịch bản của công cụ “Silk Test”

Đánh giá Scripting

3rd Data Driven
Phát triển từ “scripting”
Các dữ liệu kiểm thử được lưu dưới dạng bảng trong một tập tin tách biệt (tập tin
Excel)

Thực thi nhiều trường hợp tương tự
GOODMORNING
goodmorning
GoodMorning
Input Data

Lập bảng dữ liệu data-driven
Bảng dữ liệu dùng để kiểm thử Nội dung tập tin được tìm kiếm
nr case whole pattern matches goodmorning
1 off off GOODMORNING 4 GOODMORNING
2 off on GOODMORNING 3 GoodMorning
3 on off GOODMORNING 1 GoodMorningVietnam
4 on on GOODMORNING 1
5 off off goodmorning 4
Kịch bản Data-driven:
6 off on goodmorning 3
7 on off goodmorning 1 for each line in the file do
8 on on goodmorning 1 -open the find dialog
-read a line from the file
9 off off GoodMorning 4
-use the values to fill dialog
10 off on GoodMorning 3 -press find button
11 on off GoodMorning 2 -check amount of matches
12 on on GoodMorning 1 -close the dialog

Đánh giá Data-Driven

Hạn chế chung
Quá nhiều công việc lập trình
Quá nhạy cảm với sự thay đổi của AUT
Khả năng tái sử dụng và mở rộng kém
Phụ thuộc nhiều các nền tảng và công nghệ
Chi phí cao nhưng hiệu quả không cao

4th Keyword-Driven
Tác vụ kiểm thử được tách nhỏ dưới dạng các “từ khóa” (keyword)
Mỗi từ khóa đại diện cho một thao tác đơn giản trên máy tính
Tự động hóa việc kiểm thử thông qua tự động hóa từng thao tác

Đơn giản hóa bằng “keyword”
Giúp các test case trong sáng và dễ hiểu
Giúp các tester tập trung vào việc kiểm thử và nghiệp vụ của AUT
Giảm thời gian và chi phí để cài đặt việc tự động hóa kiểm thử
Giảm lập trình, vốn là hạn chế của các người dùng và “non-technical” tester
Action’s Parameters
Action keyword Number Name Description

Test Line add product 12345678 Hammer For pounding nails

Phân công công việc
Test Data
Test Case Test Case
Workload Construction /
Automation Production
Selection
Record & Playback N/A Test Engineer N/A
Automation Automation
Scripting N/A
Engineer Engineer
Automation Automation
Data-driven Test Engineer
Engineer Engineer
Automation
Keyword-driven Test Engineer Test Engineer
Engineer

Một số công cụ tự động
Automation
HP IBM Others
Tool
Functional WinRunner Functional Tester SilkTest
QuickTestPro Rational Robot TestPartner
TestComplete
Performance LoadRunner Performance Tester SilkPerformer

AstraLoad Test WebLoad
OpenSTA
MS Visual Studio
Management Test Director Rational TestManager SilkCentral Test Manager
Quality Center Microsoft Test Manager
Memory Purify JProbe Profiler

Nhận xét
Kiểm thử tự động trải qua 4 giai đoạn phát triển (cách tiếp cận) với nhiều cải tiến.
Mỗi cách tiếp cận có ưu điểm và hạn chế riêng.
Mỗi cách tiếp cận phù hợp với từng đối tượng sử dụng riêng.

Kiểm thử đơn vị
Kiểm tra và đảm bảo một đơn vị của hệ thống hoạt động đúng.
Đơn vị là một phần nhỏ nhất có thể kiểm thử được (testable) của hệ thống
Đơn vị có thể là một hàm (function) hoặc một phương thức (method) của một lớp.
Kết quả của quá trình kiểm thử đơn vị bao gồm
Đơn vị đã được kiểm thử.
Các tài liệu mô tả quá trình kiểm thử đơn vị.
Thực hiện kiểm thử đơn vị

Bởi bản thân lập trình viên
Ngay sau khi viết code.
55 Chương 2 - Kiểm thử tự động với xUnit Nguyễn Đạt Thông

Tại sao phải kiểm thử đơn vị
Phát hiện sớm các lỗi và giảm chi phí sửa chữa
% số lượng
lỗi tạo ra
% số lượng
lỗi phát hiện
$ Chi phí
sửa lỗi
Coding Unit Funct Field Post

Source: Applied Software Measurement,
Test Test Test Release
Capers Jones, 1996

Thiết kế các trường hợp kiểm thử đơn vị
Kiểm thử đơn vị với Black-Box Testing
Kiểm thử đơn vị với White-Box Testing

Kiểm thử đơn vị với BBT
Kiểm tra mỗi đơn vị hoạt động đúng như thiết kế ban đầu của nó.
Kiểm tra mỗi đơn vị hoạt động đúng như yêu cầu nghiệp vụ của nó.
Các kỹ thuật áp dụng:

Phân tích yêu cầu
Chia vùng tương đương
Phân tích giá trị biên

Kiểm tra đơn vị với WBT
Thực hiện trên mã nguồn

Biên dịch để phát hiện lỗi viết code
Kiểm tra và đối chiếu mã nguồn với sơ đồ xử lý (flow chart)
Kiểm tra lại các ngoại lệ (exception)
Thực hiện bằng cách thực thi mã nguồn

Bao phủ câu lệnh
Bao phủ rẽ nhánh (branch/decision)

Thực thi kiểm thử đơn vị
Viết chương trình (driver)

Gọi “unit” cần kiểm tra
Truyền vào các giá trị “input” của Test Case
Nhận về các giá trị “output” sau khi thực thi “unit”
So sánh “output” với các giá trị “expect”

Kết quả kiểm thử không như mong muốn
Kiểm tra chương trình kiểm thử đơn vị
Kiểm tra đơn vị
Chỉnh sửa và lặp lại

Thực thi kiểm thử đơn vị bằng tay
Thực thi lần lượt từng trường hợp.
Số lượng trường hợp càng nhiều, độ bao phủ càng giảm xuống.
Nhiều trường hợp bị trùng lặp, nhiều trường hợp bị thiếu sót.

Quản lý kiểm thử đơn vị bằng tay
Quản lý việc thực thi các trường hợp kiểm thử

→ Mỗi người một bảng
→ Nhiều người, nhiều test case?

Tự động hóa kiểm thử đơn vị
Viết các đoạn code kiểm thử đơn vị đơn giản (dựa trên framework sẵn có)
Biên dịch và thực thi tự động
Lập báo cáo cho biết kết quả passed/failed của từng trường hợp

Kiểm thử đơn vị tự động với xUnit
xUnit là tên gọi chung của các framework kiểm thử đơn vị
Java: JUnit, J2MEUnit
C/C++: cppUnit
Python: pyUnit
Perl: PerlUnit
Visual Basic: vbUnit
C# .NET: Nunit,csUnit

Giới thiệu NUnit
Là một framework mã nguồn mở, hỗ trợ kiểm thử đơn vị tự động.
Được phát triển trên nền .NET.
Test có thể được phát triển bởi các ngôn ngữ .NET

Giao diện NUnit
Giao diện chính của NUnit

Menu
Test/Category Explorer
Running Status Pane
Logging Pane

Tạo một Test Case với NUnit
Trong project “NUnitTestSuite1”, tạo một class mới với tên “TestSuite1” như sau
Khai báo sử dụng namespace của NUnit
Khai báo thuộc tính TestFixture
Khai báo thuộc tính Test

Thực thi Test Case với NUnit
Từ giao diện Test Explorer của NUnit, chọn và thực thi Test Case
Có thể chọn thực thi

Từng “Test Case”
Từng “Test Fixture”
Từng thư viện Test
Cả project của NUnit
Thêm một Test Case
Thêm một Test Case bằng cách thêm một phương thức Test vào lớp TestSuite1

Một số chức năng chính của NUnit
Các chức năng kiểm tra – Assertions
Các thuộc tính tự động hóa – Attributes

Các chức năng kiểm tra
Kiểm tra logic truyền thống
Kiểm tra theo ràng buộc (constraint)

Kiểm tra bằng nhau
Sử dụng Assert.AreEqual() và Assert.AreNotEqual() để kiểm tra hai

số hoặc hai đối tượng có bằng nhau hay không
Assert.AreEqual( int expected, int actual );

Assert.AreEqual( int expected, int actual, string message );
Assert.AreEqual( int expected, int actual, string message,
params object[] parms );
Assert.AreNotEqual( decimal expected, decimal actual );

Assert.AreNotEqual( decimal expected, decimal actual, string message );
Assert.AreNotEqual( decimal expected, decimal actual, string message,
params object[] parms );

Kiểm tra giống nhau
Sử dụng Assert.AreSame() và Assert.AreNotSame() để kiểm tra hai đối

tượng có giống nhau hay không
Assert.AreSame( object expected, object actual );
Assert.AreNotSame( object expected, object actual );
Assert.Contains( object anObject, IList collection );

Kiểm tra điều kiện
Sử dụng Assert.IsTrue() , Assert.IsNull(), Assert.IsEmpty(), và

Assert.IsNaN() để kiểm tra thỏa điều kiện hay không
Assert.IsTrue( bool condition ); // <> IsFalse()

Assert.True( bool condition ); // <> False()
Assert.IsNull( object anObject ); // <> IsNotNull()

Assert.Null( object anObject ); // <> NotNull()
Assert.IsNaN( double aDouble );
Assert.IsEmpty( string aString ); // <> IsNotEmpty()

Assert.IsEmpty( ICollection collection );

Kiểm tra so sánh
Sử dụng Assert.Greater() , Assert.GreaterOrEqual(),

Assert.Less(), và Assert.LessOrEqual() để so sánh hai số
Assert.Greater( int arg1, int arg2 );
Assert.GreaterOrEqual( uint arg1, uint arg2 );
Assert.Less( long arg1, long arg2 );
Assert.LessOrEqual( decimal arg1, decimal arg2 );

Kiểm tra ngoại lệ
Sử dụng Assert.Throws() , Assert.DoesNotThrow(), và

Assert.Catch() để kiểm tra một phương thức có phát sinh ngoại lệ hay không
Exception Assert.Throws( Type expectedExceptionType, TestDelegate code );

T Assert.Throws<T>( TestDelegate code );
void Assert.DoesNotThrow( TestDelegate code );
Exception Assert.Catch( Type expectedExceptionType, TestDelegate code );

T Assert.Catch<T>( TestDelegate code );
Exception Assert.Catch( TestDelegate code );

Kiểm tra chuỗi ký tự
Sử dụng lớp StringAssert để kiểm tra một chuỗi ký tự
StringAssert.Contains( string expected, string actual );
StringAssert.StartsWith( string expected, string actual );
StringAssert.EndsWith( string expected, string actual );
StringAssert.AreEqualIgnoringCase( string expected, string actual );
StringAssert.IsMatch( string regexPattern, string actual );

Kiểm tra theo ràng buộc
Xuất hiện từ phiên bản 2.4 của NUnit
Sử dụng Assert.That() để kiểm tra

Assert.That( object actual, IResolveConstraint constraint )
Assert.That( ref T actual, IResolveConstraint constraint )
Trong đó
actual – đối tượng cần kiểm tra
constraint – là một ràng buộc nào đó, cần kiểm tra xem đối tượng có thỏa mãn hay không

Các loại ràng buộc
Ràng buộc bằng nhau – Is.Equal(), Is.Not.Equal()
Ràng buộc giống nhau – Is.Same(), Is.Not.Same()
Ràng buộc điều kiện – Is.True, Is.Null, Is.Empty, Is.NaN
Ràng buộc so sánh – Is.GreaterThan(), Is.LessThan(), Is.InRange()
Ràng buộc chuỗi ký tự
Ràng buộc thuộc tính – Has.Property()
Tham khảo thêm http://www.nunit.org/index.php?p=constraintModel&r=2.6.4

Ví dụ
Kiểm tra theo ràng buộc bằng nhau và giống nhau
Assert.That(2 + 2, Is.EqualTo(4.0));
Assert.That( 2.1 + 1.2, Is.EqualTo( 3.3 ).Within( .0005 );
Assert.That(2 + 2, Is.Not.EqualTo(5));
Exception ex1 = new Exception();

Exception ex2 = ex1;
Assert.That( ex2, Is.SameAs( ex1 ) );
Exception ex3 = new Exception();

Assert.That( ex3, Is.Not.SameAs( ex1 ) );

Ví dụ
Kiểm tra theo ràng buộc điều kiện
Assert.That( anObject, Is.Null );

Assert.That( anObject, Is.Not.Null );
Assert.That( condition, Is.True );

Assert.That( aString, Is.Empty );
Assert.That( aDouble, Is.NaN );
Assert.That( collection, Is.Unique );

Ví dụ
Kiểm tra theo ràng buộc so sánh
Assert.That(7, Is.GreaterThan(3));
Assert.That(42, Is.Positive);
Assert.That(7, Is.GreaterThanOrEqualTo(3));
Assert.That(7, Is.AtLeast(3));
Assert.That(3, Is.LessThan(7));
Assert.That(-5, Is.Negative);
Assert.That(3, Is.LessThanOrEqualTo(7));
Assert.That(3, Is.AtMost(7));
Assert.That( 42, Is.InRange(1, 100) );

Ví dụ
Kiểm tra theo ràng buộc chuỗi ký tự và thuộc tính

Assert.That( phrase, Is.StringContaining( "tests fail" ) );
Assert.That( phrase, Is.Not.StringContaining( "tests pass" ) );
Assert.That( phrase, Is.StringStarting( "Make" ) );

Assert.That( phrase, Is.StringEnding( "PASSING!" ).IgnoreCase );
Assert.That( someObject, Has.Property( "Version" ) );

Assert.That(collection, Has.Property("Count").GreaterThan(10));
Assert.That( phrase, Has.Length.GreaterThan(10)

.And.Not.StartsWith( "Break" ) );
Assert.That( phrase, Has.Length.GreaterThan(10)
.And.Not.Matches( "your.*passing.*tests" ) );

Các thuộc tính tự động hóa
Thuộc tính TestFixture
Thuộc tính Test, TestCase và TestCaseSource
Thuộc tính Category và Description
Một số thuộc tính khác

Thuộc tính TestFixture
Được sử dụng để đánh dấu một class có chứa các Test Case.
Một “Fixture” có thể xem như là một tập hợp các Test Case.
Với mỗi thuộc tính TestFixture được khai báo

NUnit sẽ khởi tạo một đối tượng thuộc lớp có thuộc tính TestFixture,
NUnit gọi hàm được đánh dấu là TestFixtureSetUp (nếu có),
NUnit lần lượt thực thi các Test Case,
NUnit gọi hàm được đánh dấu là TestFixtureTearDown (nếu có).
Tham khảo: http://www.nunit.org/index.php?p=testFixture&r=2.6.4

Ví dụ: Thuộc tính TestFixture
Cấu trúc một lớp có thuộc tính TestFixture:

[TestFixture]
class TestSuite1 {
[TestFixtureSetUp]
public void InitForAllTests() {
// ...
}
// ...
// some Test Case
[TestFixtureTearDown]
public void CleanUpTests() {
// ...
}
}

Thuộc tính TestFixture có tham số
Khi khởi tạo đối tượng, NUnit sử dụng hàm khởi động mặc định (không tham số)
Có thể sử dụng tham số trong
thuộc tính TestFixture để [TestFixture("hello", "params")]
[TestFixture(11, 9)]
NUnit có thể khởi tạo đối
class TestSuite1 {
tượng tốt hơn. public TestSuite1(string str, string str2) {
Mỗi khai báo TestFixture // ...
được NUnit xem là một tập hợp }
riêng.
public TestSuite1(int x, int y) {
// ...
}
// ...
}

Thuộc tính TestFixture trên NUnit
Thuộc tính TestFixture được thể hiện trên giao diện NUnit
Thuộc tính Test và TestCase
Được sử dụng để đánh dấu một phương thức bên trong một class (đã được đánh
dấu với thuộc tính TestFixture) là một Test Case.
Thuộc tính Test dùng để đánh dấu các Test Case không tham số
Thuộc tính TestCase dùng để đánh dấu các Test Case có tham số
Với mỗi thuộc tính Test hoặc TestCase được khai báo, NUnit sẽ xem là một Test
Case riêng lẻ.
Ví dụ: Thuộc tính Test
Sử dụng thuộc tính Test để đánh dấu một Test Case

Thuộc tính SetUp để đánh dấu phương
[TestFixture]
thức được thực thi trước mỗi Test Case.
class TestSuite1 {
Thuộc tính TearDown để đánh dấu phương [SetUp]
thức được thực thi sau mỗi Test Case. public void InitTestCase() { }
[Test]
public void TestCase1() {
// ...
}
[TearDown]
public void CleanUpTestCase() { }
}
Ví dụ: Thuộc tính TestCase
Sử dụng thuộc tính TestCase để đánh dấu một Test Case

[TestFixture]
class TestSuite1 {
[TestCase(11, 9, 10)]
[TestCase(17, 8, 12.5)]
[TestCase(29, 7, 18)]
public void TestCase2(double x, double y, double d) {
// ...
[TestFixture]
}
class TestSuite1 {
}
[TestCase(11, 9, Result=10)]
[TestCase(17, 8, Result=13)]
public double TestCase3(double x, double y) {
// ...
}
}
Thuộc tính TestCaseSource
Được sử dụng trong data-driven test, thay thế hàng loạt các khai báo TestCase
[TestFixture]
class TestSuite1 {
static object[] MyDataSet = {

new object[] { 12, 3, 4 },
new object[] { 12, 2, 6 },
new object[] { 12, 4, 3 }
};
[Test, TestCaseSource("MyDataSet")]
public void TestCase4(double x, double y, double d) {
// ...
}
}
Thuộc tính TestCase trên NUnit
Thuộc tính TestCase được thể hiện trên giao diện NUnit
Thuộc tính Category và Description
Được sử dụng để phân loại và mô tả các Test Case

Sử dụng được cho cả lớp (TestFixture) và từng phương thức (Test hoặc TestCase)
Mô tả (Description) chỉ hiển thị trong cửa sổ “Properties” của Fixture hoặc Test Case tương ứng.
[assembly: Description("This is for TestableUnit tests")]
[TestFixture, Description("This test Math utils")]

public class TestSuite1 {
[Test, Description("A simple Test"), Category("Simple Test")]

public void TestCase1()
// ...
}
}
Thuộc tính Category trên NUnit
Thuộc tính Category được thể hiện trên giao diện NUnit
Một số thuộc tính khác
Thuộc tính Explicit và Ignore
Thuộc tính Values
Thuộc tính Range và Random
Thuộc tính Timeout
MSVS: Kiểm thử đơn vị
Tạo dự án unit test
Thực thi unit test
Kiểm tra và đánh giá kết quả
117 Chương 3 - Kiểm thử tự động với MS Visual Studio Nguyễn Đạt Thông
Đơn vị cần kiểm tra
Thêm test case và checkpoint
Thêm các checkpoint với “Assert”
Một số Attribute thông dụng
TestClass
TestMethod
TestInitialize / TestCleanup
ClassInitialize / ClassCleanup
TestCategory / Description
Timeout
DataSource https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.datasourceattribute.aspx
122 Kiểm thử phần mềm tự động - 2015 Nguyễn Đạt Thông
Đánh giá code coverage của unit test
VS thực thi unit test case và cho biết các câu lệnh được bao phủ như thế nào.
Để xem kết quả, chọn test case, và chọn “Analyze code coverage”
Kết quả code coverage
Kết quả code coverage được hiển thị ở giao diện “Code Coverage Results”
Hiển thị các đoạn code chưa được bao phủ
Chọn “Show Code Coverage Coloring” trong giao diện Code Coverage Results để xem
các đoạn code chưa được bao phủ.
Thực thi IntelliTest trên các method khác
Chọn tên method trong giao diện IntelliTest
Lưu lại các IntelliTest
Các test case tạo ra bởi IntelliTest có thể được lưu lại để thực thi sau, kết quả lưu là
một dự án unit test
UI Automation và Coded UI
Tạo một Coded UI Test
Coded UI Test có thể được tạo như một “item” thông thường trong một dự án
Coded UI.
Record một Coded UI Test
Coded UI Test thường được “Record”
Khởi động chương trình và Record
Nếu không muốn Coded UI record thao tác khởi động AUT,
thì cần phải chạy AUT trước khi bắt đầu record.
Khi Coded UI Test kết thúc, các chương trình được khởi động bởi Coded UI sẽ tắt.
Có thể sử dụng các attribute TestInitialize và TestCleanup để khởi động và tắt AUT.
Thêm checkpoint vào Coded UI Test
Chọn nút “Add Assertions” trên giao diện của Coded UI Test Builder
Có thể sử dụng phím tắt Ctrl + I đối với các thành phần giao diện “đặc biệt”
Phát sinh mã nguồn của Coded UI Test
Mã nguồn của Coded UI Test bao gồm

Coded UI Test Class: tương tự như TestClass, thể hiện các Test Case được thực thi.
UIMap.cs: chứa mã nguồn tự động hóa của các Coded UI Test
UIMap.Designer.cs: chứa các mã nguồn định vị (locate) các thành phần giao diện.
Thực thi Coded UI Test
Coded UI Test được thực thi trong Test Manager giống như unit test.
Thực thi Coded UI Test sẽ tự động thực hiện các thao tác trên giao diện AUT.
Các AUT hỗ trợ bởi Coded UI Test

Win32 Applications
Web Applications (IE, Chrome, FF)
Windows Store Applications
Kiểm thử hiệu năng với Visual Studio
Kiểm thử hiệu năng (Performance test) của một ứng dụng web
Xác định, đánh giá hiệu năng làm việc, tốc độ xử lý và phản hồi của trang web.
Visual Studio Ultimate

Hỗ trợ tạo các test để đánh giá hiệu năng trang web
Thực hiện các thao tác để record
Visual Studio sẽ tự động mở MS Internet Explorer để người sử dụng thao tác.
MS IE cần cho phép các “add-on” sau hoạt động để hỗ trợ quá trình record
Microsoft Web Test Recorder 10/11/12 Helper
Web Test Recorder 10/11/12
Các thao tác của người dùng được record lại
Các thao tác
Mỗi thao tác được record dưới dạng các “request”
Một số thuộc tính

URL, Follow Redirects
Think Time
Reporting Name
Thực thi kiểm thử hiệu năng
Chọn “Run Test” trên thanh công cụ của giao diện “Web Performance Test Editor”
Thêm các checkpoint vào test
Trong giao diện “Web Performance Test Editor”, chọn một request và “Add
Validation…”
Thêm các checkpoint vào test
Trong giao diện “Web Performance Test Editor”, chọn một request và “Add
Extraction…”
Thực thi kiểm thử với các checkpoint
Thực thi kiểm thử hiệu năng sau khi thêm các checkpoint
Áp dụng Data-driven
Chọn “Add Data Source” trên thanh công cụ của giao diện “Web Performance Test
Editor”
<?xml version="1.0" encoding="utf-8" ?>

<queries>
<test>
<query>nosql</query>
<find-text>no-sql</find-text>
</test>
<test>
<query>selenium</query>
<find-text>selenium ide</find-text>
</test>
</queries>
Sử dụng data trong kiểm thử hiệu năng
Chọn giá trị cần thay đổi, và xác định giá trị thay thế trong Data Source
Thiết lập thực thi với data-driven
Mở giao diện “Test Settings” bằng cách double click vào “Local.testsettings” trong
giao diện “Solution Explorer”
Thực thi kiểm thử hiệu năng với data-driven
Thực thi kiểm thử với VS cho kết quả nhiều lần chạy liên tiếp (tuần tự)
Lặp các thao tác kiểm thử
Chọn một thao tác muốn lặp lại nhiều lần, và chọn “Insert Loop…”, giao diện “Add
Conditional Rule and Items to Loop” sẽ xuất hiện
Load Test với Visual Studio
Load Test là việc giả lập nhiều người sử dụng (virtual users)
đồng thời truy xuất hệ thống,
nhằm mục đích kiểm tra, đánh giá mức độ đáp ứng của hệ thống trong các điều kiện khác nhau.
Visual Studio Utimate

cho phép giả lập không hạn chế số lượng người sư dụng.
cho phép thực hiện giả lập trên máy local hoặc các máy ở xa.
hỗ trợ sử dụng kiến trúc đa vi xử lý (multiprocessor architecture) để thực hiện load test.
Wizard: Xác định chế độ load test
Một Load test có thể gồm

nhiều người dùng (ảo)
và nhiều trường hợp kiểm thử.
Load test “Mix Mode”:

Xác định khả năng một người dùng (ảo) thực hiện một trường hợp kiểm thử nào đó.
Các Mix Mode
Dựa trên tổng số trường hợp kiểm thử

Khi một người dùng (ảo) cần thực thi, một trường hợp kiểm thử sẽ được chọn dựa trên phân phối
định trước.
Khi kết thúc load test, số lần thực hiện các TC sẽ tương ứng với phân phối định trước.
Dựa trên tổng số người dùng (ảo)

Khi một người dùng (ảo) cần thực thi, một trường hợp kiểm thử sẽ được chọn dựa trên phân phối
định trước.
Tại mọi thời điểm thực thi load test, số lượng người dùng thực hiện một TC sẽ tương ứng với phân
phối định trước.
Quá trình thực thi load test
Quá trình thực thi load test được VS thể hiện bằng các số liệu
Kết quả thực thi load test
Kết thúc quá trình load test, VS tạo ra một bản báo cáo
Giới thiệu Selenium
Là một bộ công cụ kiểm thử tự động các ứng dụng trên nền Web
Miễn phí
Mã nguồn mở
Mạnh mẽ
Hỗ trợ đa trình duyệt
Hỗ trợ đa ngôn ngữ (lập trình)
121 Chương 4 – Tổng quan Selenium Nguyễn Đạt Thông

Lịch sử Selenium
2008
•Selenium
WebDriver
2006
•WebDriver
•Simon
Stewart,
Google
2004
•Selenium Core
•Jason Huggins,
ThoughWorks
122 Chương 4 – Tổng quani Selenium Nguyễn Đạt Thông

Trình duyệt và nền tảng hỗ trợ
Trình duyệt Hệ điều hành
Windows, Linux
Windows
Windows, Mac
Windows, Linux, Mac
Windows, Linux, Mac

Các thành phần của Selenium
Selenium Core
Selenium IDE
Selenium RC (Selenium 1.0)
Selenium Grid
Selenium WebDriver (Selenium 2.0)

Selenium Core
Selenium Core
Là một thư viện JavaScript
Hỗ trợ thực hiện tự động hóa trên các ứng dụng web
Được thực thi trực tiếp bên trong trình duyệt
Selenium Core tương thích với (hầu như) tất cả các trình duyệt
Mã nguồn
http://www.seleniumhq.org/download/source.jsp

Selenium IDE
Giao diện đồ họa của Selenium
Cho phép “record” và “playback” một test script
Được tích hợp vào trình duyệt FireFox (một extension của FF)
Tham khảo
http://docs.seleniumhq.org/docs/02_selenium_ide.jsp

Selenium RC
Hỗ trợ ngôn ngữ C#, Java, Python, Perl và Ruby

http://docs.seleniumhq.org/docs/05_selenium_rc.jsp
Ví dụ
selenium = new DefaultSelenium(
"localhost", 4444, "*chrome", "https://code.google.com/");
selenium.Start();
selenium.Open("/p/selenium/wiki/SeIDEReleaseNotes");
selenium.Click("link=Downloads");
selenium.Type("id=searchq", "release");
selenium.Click("css=span.inIssueList > form > input[type=\"submit\"]");
selenium.WaitForPageToLoad("30000");
String tt = selenium.GetTitle();
Console.WriteLine(tt);

Selenium WebDriver
Là một thư viện (API) hỗ trợ C#, Java, Python, Perl và Ruby
Cung cấp một giao diện lập trình ngắn gọn

đơn giản hơn và giải quyết một số hạn chế trong Selenium RC API
Hỗ trợ kiểm thử tự động trên nhiều trình duyệt khác nhau

Selenium IDE
Giao diện đồ họa của Selenium
Cho phép “record” và “playback” một test script
Được tích hợp vào trình duyệt FireFox (một extension của FF)
Tham khảo
http://docs.seleniumhq.org/docs/02_selenium_ide.jsp
131 Chương 4 – Selenium IDE Nguyễn Đạt Thông

Các thành phần giao diện của IDE

Menu “File”

Menu “Edit” và “Options”

Record một test script
Tạo một “test case” mới

File → New Test Case
Chọn test case để lưu các thao tác

Double-click lên test case vừa tạo
trong cửa sổ “Test Case”

Record một test script
Thực hiện các thao tác trên trang web

Selenium IDE sẽ “record” các thao tác

Tạo các “checkpoint”
Tạo các “checkpoint” bằng

context menu của Selenium IDE

Hiệu chỉnh một test case
Chọn một “command” để hiệu chỉnh

Command
Target
Value

Thông tin tham khảo
Tham khảo thông tin về “command” để có thể hiệu chỉnh chính xác
Cửa sổ “reference”

Thực thi một test case
Thực thi
Thực thi một test case
Thực thi tất cả test case (trong test suite)
Thông tin quá trình thực thi

cửa sổ “Log”

Câu lệnh Selenese
Cú pháp
Command
Target
Value
Phân loại
Action
Accessor
Assertion

Câu lệnh Selenese: Action
Các lệnh thao tác trên ứng dụng
Nếu một Action thất bại hoặc xảy ra lỗi thì việc kiểm thử sẽ được dừng lại.
Ví dụ: “click”, “select”,…
Nhiều Actions có thể theo sau bằng “AndWait”

Ví dụ: “clickAndWait”, “dragAndDropAndWait”, …

Câu lệnh Selenese: Accessor
Các lệnh truy vấn trạng thái của các thành phần giao diện
Và lưu trữ trong các biến của Selenium
Ví dụ: “storeTitle”, “storeLocation”, …

Câu lệnh Selenese: Assertion
Câu lệnh xác minh trạng thái của ứng dụng

AssertXXX – việc xác minh bị lỗi sẽ dừng thực thi
VerifyXXX – việc xác minh bị lỗi sẽ tiếp tục thực thi
WaitForXXX – chờ cho đến khi việc xác minh thành công

Một số lệnh Selenese thông dụng
open
click, clickAndWait
verifyTitle, assertTitle
verifyTextPresent, verifyElementPresent
waitForPageToLoad, waitForElementPresent

Công cụ “Locator”
Hỗ trợ xác định đặc điểm (tiêu chí) của “target”
Các chức năng

Tìm đặc điểm của một thành phần giao diện – Select
Kiểm tra đặc điểm của một thành phần giao diện – Find

Các tiêu chí xác định “Target”
Các tiêu chí có thể là

id
name
identifier (có thể là id hoặc name)
link
DOM object (JavaScript)
XPath
CSS

Lưu trữ kịch bản Selenium
Kịch bản Selenium được lưu trữ mặc định dưới dạng HTML
Là một bảng gồm 3 cột tương ứng với “command”, “target”, và “value”
Ví dụ
<table>
<tr><td>open</td><td>/download/</td><td></td></tr>
<tr><td>assertTitle</td><td></td><td>Downloads</td></tr>
<tr><td>verifyText</td><td>//h2</td><td>Downloads</td></tr>
</table>
open /download/
assertTitle Downloads
verifyText //h2 Downloads

Export một test case
Export dưới dạng mã nguồn C#, Java, Python hoặc Ruby
Export dưới dạng Selenium RC hoặc Selenium WebDriver
driver.Navigate().GoToUrl(baseURL + "/p/selenium/wiki/SeIDEReleaseNotes");
driver.FindElement(By.LinkText("Downloads")).Click();
driver.FindElement(By.Id("searchq")).Clear();
driver.FindElement(By.Id("searchq")).SendKeys("release");
driver.FindElement(
By.CssSelector("span.inIssueList > form > input[type=\"submit\"]")
).Click();
String tt = driver.Title;

Đánh giá Selenium IDE
Ưu điểm Nhược điểm
Dễ cài đặt và sử dụng Chỉ có trên trình duyệt FireFox
Không yêu cầu kiến thức lập trình (nhưng

Chỉ được sử dụng để tạo các test case mẫu
đòi hỏi kiến thức về HTML và JavaScript)
Có thể export các kịch bản Selenese ra dạng
Không hỗ trợ các thao tác lặp và điều kiện
mã nguồn RC hoặc WebDriver
Tích hợp tài liệu hướng dẫn sử dụng và tham Thực thi chậm hơn khi phát triển bằng RC
khảo ngôn ngữ Selenese hoặc WebDriver

Mô hình Selenium RC
Các thành phần của Selenium RC

Selenium Server
Các thư viện Client
158 Chương 4 – Selenium RC và Selenium Grid Nguyễn Đạt Thông

Kiến trúc Selenium RC

Bên trong Selenium RC
Nguồn:
http://www.hurricanesoftwares.com/

Khởi động Selenium Server
Selenium Server là một chương trình Java
Khởi động bằng cách gõ câu lệnh từ console

cd <path-to-selenium-server-directory>
java -jar selenium-server-standalone-<version-number>.jar
Ví dụ
cd d:\seleniumrc-2.45.0
java -jar selenium-server-standalone-2.45.0.jar

Tạo một kịch bản C# đơn giản
Trong class “Program”, sử dụng Selenium Client

namespace SeleniumRC {
class Program {
static void Main(string[] args) {
Selenium.ISelenium selenium = new
Selenium.DefaultSelenium("localhost", 4444,
"*chrome", "http://google.com/");
selenium.Start();
selenium.Open("/p/selenium/wiki/SeIDEReleaseNotes");
selenium.Click("link=Downloads");
selenium.Type("id=searchq", "release");
selenium.Click("css=span.inIssueList > form > input[type=\"submit\"]");
selenium.WaitForPageToLoad("30000");
String tt = selenium.GetTitle();
}
}
}

Một số Selenium RC API thông dụng
Khởi tạo đối tượng Selenium
Selenium selenium = new DefaultSelenium("localhost", 4444, "*chrome", "https://code.google.com/");

selenium.start();
“localhost” – địa chỉ IP (hostname) của hệ thống Selenium RC

4444 – cổng TCP đang lắng nghe của hệ thống Selenium RC
“*chrome” – thực hiện kiểm thử bằng trình duyệt Chrome
“http://code.google.com” – địa chỉ URL dùng để bắt đầu kiểm thử

Một số Selenium RC API thông dụng
Mở trình duyệt và đến trang web với URL cho trước

Selenium.open();
Bấm vào một đối tượng trên trang web hiện tại
Selenium.click();
Nhập chuỗi ký tự vào một đối tượng (textbox) trên trang web hiện tại
Selenium.type();

Đánh giá Selenium RC

Selenium Grid
Thực hiện kiểm thử song song

Trên nhiều trình duyệt, nhiều phiên bản khác nhau
Trên nhiều hệ thống máy tính khác nhau
• kết nối với nhau qua mạng LAN
Trên nhiều môi trường khác nhau
Các thành phần của Selenium Grid

Selenium Hub
Các Node – Selenium RC Server

Mô hình Selenium Grid
Nguồn:
http://www.hurricanesoftwares.com/
Selenium Grid 2.0
Hỗ trợ phát triển kịch bản kiểm thử dựa trên Selenium WebDriver
Kết hợp Selenium Hub và Selenium RC

Khởi động Selenium Grid
Khởi động Selenium Hub

-role hub
Ví dụ
–role hub
-port 4441

Khởi động Selenium Node
Khởi động Selenium Node

-role node
-hub <http-address-of-the-hub>
Ví dụ
–role node
-hub http://localhost:4444/grid/register

Selenium WebDriver
Là một thư viện (API) hỗ trợ C#, Java, Python, Perl và Ruby
Cung cấp một giao diện lập trình ngắn gọn

đơn giản hơn và giải quyết một số hạn chế trong Selenium RC API
Hỗ trợ kiểm thử tự động trên nhiều trình duyệt khác nhau
180 Chương 4 – Selenium WebDriver Nguyễn Đạt Thông

WebDriver và trình duyệt

Lập trình WebDriver
WebDriver cho phép người dùng sử dụng ngôn ngữ lập trình để tạo nên Test Script
(không giống Selenium IDE)
có thể sử dụng các thao tác như các biểu thức có điều kiện.
cũng có thể sử dụng vòng lặp như do-while.
Hướng đối tượng

Trong sáng và dễ hiểu hơn so với Selenium RC

Tạo một kịch bản C# đơn giản
Trong class “Program”, sử dụng Selenium WebDriver

namespace SeleniumWebDriver {
class Program {
static void Main(string[] args) {
OpenQA.Selenium.IWebDriver driver = new
OpenQA.Selenium.Firefox.FirefoxWebDriver();
String baseURL = "https://code.google.com/";
driver.Navigate().GoToUrl(baseURL + "/p/selenium/wiki/SeIDEReleaseNotes");
driver.FindElement(By.LinkText("Downloads")).Click();
new SelectElement(driver.FindElement(By.Id("can")))
.SelectByText("regexp:\\sAll downloads");
driver.FindElement(By.Id("searchq")).Clear();
driver.FindElement(By.Id("searchq")).SendKeys("stable");
}
}
}

Các interface và class thông dụng
IWebDriver
ITargetLocator
INavigation
IWebElement
WebDriverWait

IWebDriver
Một IWebDriver có thể xem là một “trình duyệt”
Khởi tạo một đối tượng IWebDriver

// In Java
WebDriver driver = new FirefoxWebDriver();
// new InternetExplorerDriver();
// new ChromeDriver();
// new SafariDriver();
Để sử dụng một web driver của một trình duyệt nào đó, thì
Trình duyệt đó phải được cài đặt trước đó
Chương trình “driver” tương ứng phải được cài đặt trước đó (ngoại trừ Firefox WebDriver).

Các WebDriver thông dụng
Download các chương trình web driver

Thao tác trên IWebDriver
Duyệt cửa sổ hiện tại đến một trang web nào đó

// In Java
driver.get(“http://www.google.com.vn”);
// In C#
driver.Url = “http://www.google.com.vn”;
Lưu ý
• Một WebDriver có thể có nhiều cửa sổ (tab)
• Thao tác duyệt của WebDriver kết thúc ngay cả khi trình duyệt chưa kết thúc việc tải và hiển thị trang
web.
• Để đảm bảo các thành phần giao diện đã được hiển thị trước khi thao tác, phải sử dụng các hàm “wait”.

Đóng cửa sổ trình duyệt hiện tại

// In Java
driver.close();
driver.quit(); // close all windows and quit
// In C#
driver.Close();
driver.Quit(); // close all windows and quit
Lưu ý
• Trình duyệt sẽ thoát nếu tất cả các cửa sổ đều được đóng

Truy vấn thông tin trang web trong cửa sổ hiện tại
// In Java
String src = driver.getPageSource();
String title = driver.getTitle();
String handle = getWindowHandle();
// In C#
string src = driver.PageSource;
string title = driver.Title;
string handle = driver.CurrentWindowHandle;

Chuyển đổi cửa sổ hiện tại

// In Java
driver.switchTo().window( driver.getWindowHandle() );
// In C#
driver.SwitchTo().Window( driver.CurrentWindowHandle );
Lưu ý
• Kết quả trả về của hàm “switchTo()” là một đối tượng kiểu ITargetLocator.
https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebDriver.TargetLocator.html

Các thao tác duyệt

// In Java
driver.navigate().back();
driver.navigate().forward();
driver.navigate().refresh();
driver.navigate().to(“http://google.com.vn”);
// In C#
driver.Navigate().Back();
driver.Navigate().Forward();
driver.Navigate().Refresh();
Lưu ý driver.Navigate().GoToUrl(“http://google.com.vn”);
• Kết quả trả về của hàm “navigate()” là một đối tượng kiểu INavigation.
https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebDriver.Navigation.html

Các thao tác khác trên trình duyệt

// In Java
driver.manage().deleteAllCookies();
driver.manage().getCookies();
// In C#
driver.Manage().Cookies.DeleteAllCookies();
Lưu ý
• Kết quả trả về của hàm “manage()” là một đối tượng kiểu IOptions.
https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebDriver.Options.html

Tìm kiếm một thành phần giao diện dựa vào

id
Name
Class name
Tag name
Link text
XPath

Tìm kiếm một thành phần giao diện dựa vào “id”
// In HTML
<div id=“loginMenuId">...</div>
// In Java
WebElement element = driver.findElement(By.id(“loginMenuId"));
// In C#
IWebElement element = driver.FindElement(By.Id(“loginMenuId"));

Tìm kiếm một thành phần giao diện dựa vào “name”
// In HTML
<input name="cheese" type="text"/>
// In Java
WebElement cheese = driver.findElement(By.name("cheese"));
// In C#
IWebElement cheese = driver.FindElement(By.Name("cheese"));

Tìm kiếm một thành phần giao diện dựa vào “class name”
// In HTML
<div class="cheese"><span>Cheddar</span></div>
<div class="cheese"><span>Gouda</span></div>
// In Java
List<WebElement> cheeses = driver.findElements(By.className("cheese"));
// In C#
IList<IWebElement> cheeses = driver.FindElements(By.ClassName("cheese"));

IWebElement
IWebElement
có thể được xem như “một thành phần giao diện”
có các thao tác
• click
• clear, sendKeys
• findElement
• getAttribute
• getLocation, getSize
• getText
• isDisplayed, isEnabled, isSelected
• submit

Kết hợp Selenium RC và WebDriver
Vì lý do tương thích với những kịch bản kiểm thử sẵn có

Sẵn có các kịch bản Selenium RC, phát triển tiếp các kịch bản WebDriver
Sẵn có các kịch bản WebDriver, phát triển tiếp các kịch bản Selenium RC

WebDriver Backed
Biến WebDriver “ngược lại” tương thích với Selenium RC
// You may use any WebDriver implementation. Firefox is used here as an example
WebDriver driver = new FirefoxDriver();
String baseUrl = "http://www.google.com";
// Create the Selenium implementation

Selenium selenium = new WebDriverBackedSelenium(driver, baseUrl);
// Perform actions with selenium

selenium.open("http://www.google.com");
selenium.type("name=q", "cheese");
selenium.click("name=btnG");
// Get the underlying WebDriver implementation back. This will refer to the
// same WebDriver instance as the "driver" variable above.
WebDriver driverInstance = ((WebDriverBackedSelenium) selenium).getWrappedDriver();

Remote WebDriver
Biến Selenium RC server thành WebDriver

Kết nối đến Selenium RC Server và tương tác như một WebDriver
WebDriver driver = new RemoteWebDriver(

new URL("http://localhost:4444"),
DesiredCapabilities.firefox());
driver.get("http://www.google.com");
Kết nối đến Selenium Grid và tương tác như một WebDriver
WebDriver driver = new RemoteWebDriver(

new URL("http://localhost:4444/wd/hub"),
DesiredCapabilities.firefox());
driver.get("http://www.google.com");

Phương pháp Action-Based Testing
Là một cách tiếp cận đại diện tiên phong của Keyword-Driven Test
Được áp dụng thành công trong nhiều dự án kiểm thử trên thế giới.
Được giới thiệu lần đầu tiên vào năm 1994 bởi Hans Buwalda, LogiGear.
Action Based Testing (ABT)

Tiết kiệm thời gian và chi phí trong việc thiết kế, tự động hóa và quản lý các tác vụ kiểm thử.
Là một “framework” để tổ chức việc kiểm thử tự động một cách hiệu quả.
266 Chương 5 – Phương pháp Action-Based Testing Nguyễn Đạt Thông

Ví dụ: chi phí khi áp dụng ABT

Nguyên lý áp dụng Action-Based Testing
Phương pháp kiểm thử dựa trên “hành động”

Action’s Parameters
Action keyword Number Name Description

Test Line add product 12345678 Hammer For pounding nails
Các trường hợp kiểm thử được tách thành các “hành động nghiệp vụ”
Tester xây dựng các trường hợp kiểm thử dựa trên các “hành động”
Automation Engineer cài đặt và bảo trì các “hành động”

Ví dụ
Một đoạn tác vụ kiểm thử được mô tả như sau

1. Mở trình duyệt IE và vào trang http://mail.yahoo.com
2. Nhập vào “yahoo id” là jamebond và mật khẩu là 007007
3. Bấm nút “Sign in”
Áp dụng phương pháp ABT, “kịch bản” tự động hóa sẽ được viết dưới dạng
browser id password
login yahoo mail http://mail.yahoo.com jamebond 007007

Các khái niệm cơ bản trong ABT
Actions
Actions Interfaces Data
Interfaces
Data
ABT

ABT: Interface
Chứa thông tin mô tả về các thành phần giao diện

Các cửa sổ giao diện
Các trang web
Mỗi thành phần giao diện được đặt một tên riêng
Ví dụ:
btnOk Parent HelloWin
Caption “Ok”
Class Button

ABT: Action
Các thao tác nghiệp vụ mà người sử dụng trên AUT

Sử dụng các động từ gần gũi với ngôn ngữ tự nhiên
Sử dụng các tham số để tùy biến thao tác
Mô tả tương tác với giao diện thông qua các tên riêng (định nghĩa trong Interfaces)
Ví dụ
action: “enter account number” có các tham số:
textbox: “txtAccNum”
số tài khoản: “19001526292”

ABT: Data
Chứa các bộ dữ liệu phục vụ cho data-driven test

Được tổ chức dưới dạng bảng
Dòng đầu tiên là tên các trường dữ liệu
Mỗi dòng là một bộ dữ liệu phục vụ cho một test
DataSet: Register User
UserID Password Gender Age Country
Jame 007 Male 40 UK
Sarah p@ss Female 26 US

Đặc điểm của ABT
Chia nhỏ kịch bản kiểm thử thành 4 phần độc lập
Dữ liệu kiểm thử (Test data)
Thông tin giao diện (Interface)
Các hành động nghiệp vụ (Action)
Kịch bản kiểm thử (Test logic/Test script)
Các thành phần “data”, “interface”, “action” có thể được tái sử dụng trong nhiều
kịch bản kiểm thử khác nhau.

Ưu điểm của ABT
Tường Tái sử
minh dụng
Visibility Reusability
Tính mở Tính bảo trì

rộng Maintain-
Scalability ability

Các bước áp dụng ABT
Bước 1: Tester xác định các Test Module

Chia nhỏ công việc kiểm thử ra thành các module, dựa trên tiêu chí là
Các chức năng của AUT/SUT
Các đặc điểm chất lượng của AUT/SUT (như hiệu năng, độ ổn định, volume/load, …)

Bước 2: Tester xác định các yêu cầu/mục tiêu kiểm thử
Với mỗi module, xác định các yêu cầu/mục tiêu kiểm thử (test requirement/test
objective), dựa trên tiêu chí là
Các yêu cầu nghiệp vụ
Các đặc tả chức năng
Các tiêu chí chấp nhận của người sử dụng(user accteptance)
Các yêu cầu chất lượng khác của các stakeholder

Bước 3: Tester xác định các Test Case

Trong mỗi module, xác định các trường hợp kiểm thử (Test Case) để kiểm tra (verify)
từng yêu cầu/mục tiêu kiểm thử.
Các test case nên được xác định dưới dạng
Một chuỗi các hành động nghiệp vụ “cấp cao” (high-level) đại diện các bước trong qui trình nghiệp
vụ của AUT/SUT
Không bao gồm các thao tác “cấp thấp” (low-level) như tương tác giao diện
• Ví dụ: login, search product, add product, view cart, check out, …
click, enter, select date, select tab, …

Bước 4: Automation Engineer cài đặt các hành động nghiệp vụ high-level
Automation Engineer hiện thực các hành động nghiệp vụ high-level
bằng cách sử dụng các hành động low-level và các hành động khác (lập trình thêm) nếu cần
Automation Engineer giúp Tester hiệu chỉnh các hành động high-level nhằm tang
tính hiệu quả và tái sử dụng cho các hành động này.
Đề nghị thêm tham số

Ilovepdf Merged

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ilovepdf Merged

Uploaded by

Copyright:

Available Formats

Kiểm thử tự động

Kiểm thử tự động

14 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

15 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Một số trường hợp kiểm thử

16 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Tiết kiệm thời gian và chi phí

Tiết kiệm nguồn nhân lực

Giảm thiểu sai sót trong quá trình kiểm thử

17 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

18 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Kiểm thử bằng tay Kiểm thử tự động

• Thời gian thực thi • Thời gian thự thi

• Tự phản ứng và uyển chuyển • Tương đối kém linh hoạt

• Lợi ích trong ngắn hạn • Lợi ích dài hạn

19 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Tương tác Đồng bộ

20 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Viết kịch bản Đồng bộ Kiểm tra Chạy tự động

• Test Engineer • Test Engineer • Test Engineer • Test Engineer

21 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Kiểm thử mã nguồn

Kiểm thử đơn vị

Kiểm thử hiệu năng

Kiểm thử chức năng

22 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Kiểm thử tính dễ sử dụng – Usability testing

Kiểm thử một lần duy nhất (one-time)

Kiểm thử nhanh nhất có thể (ASAP, test NOW)

Kiểm thử ngẫu nhiên – Ad-hoc testing

Kiểm thử có kết quả không dự đoán trước được

23 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Bảo trì và Mất tập

24 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

Khách hàng yêu cầu

Sản phẩm đã ổn định

25 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

26 Chương 1 - Tổng quan kiểm thử tự động Nguyễn Đạt Thông

29 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

Công cụ tự động hóa phát sinh

Record Thực thi

Phát sinh kịch bản

30 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

• Ghi nhận thao tác và Thực thi lại

Ghi nhận Thực thi lại

Thao tác được thực Target

31 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

32 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

33 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

→ Thế hệ kiểm thử tự động thứ nhất không hiệu quả và

34 Kiểm thử phần mềm tự động - 2015 Nguyễn Đạt Thông

35 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

Tự động hóa bằng cách viết kịch bản (lập trình)

36 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

37 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

38 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

39 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

Phát triển từ “scripting”

40 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

41 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

42 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

43 Chương 1 – Lịch sử kiểm thử tự động Nguyễn Đạt Thông

Quá nhiều công việc lập trình

Quá nhạy cảm với sự thay đổi của AUT