KELOMPOK 04
Sistem Informasi Koperasi Karyawan
“STIKOM Surabaya”
Test Plan
Confidential © Kelompok 04 PRPL, 2011 Page 2
Revision History
Confidential © Kelompok 04 PRPL, 2011 Page 3
Table of Contents
1. Introduction 4 1.1 Purpose 4 1.2 Background 4 1.3 Scope 4 1.4 Project Identification 62. Requirements for Test 7
3. Test Strategy 7
3.1 Testing Types 7
3.1.1 Data and Database Integrity Testing 7
3.1.2 Function Testing 7
3.1.3 Business Cycle Testing 9
3.1.4 User Interface Testing 10
3.1.5 Performance Profiling 11
3.1.6 Load Testing 12
3.1.7 Stress Testing 13
3.1.8 Volume Testing 14
3.1.9 Security and Access Control Testing 15
3.1.10Failover / Recovery Testing 16
3.1.11Configuration Testing 19 3.1.12Installation Testing 20 3.2 Tools 21 4. Resources 22 4.1 Workers 22 4.2 System 24 5. Project Milestones 24 6. Deliverables 25 6.1 Test Model 25 6.2 Test Logs 25 6.3 Defect Reports 25
Confidential © Kelompok 04 PRPL, 2011 Page 4
Test Plan
1. Introduction
Dokumen Test Plan ini menjelaskan tentang bagaimana software yang di buat
dapat berjalan sesuai dengan rencana yang telah di tetapkan seelumnya. Uji coba tidak
hanya dilakukan pada source code, namun pengujian juga di lakukan pada
database,komponen,interface,keamanan,model bisnis dan performa dari software yang di
bangun, serta konfigurasi antara client dan server
1.1 Purpose
Dokumen Test Plan ini dibuat untuk mendukung pembuatan Sistem Pakar untuk
Mendiagnosa Ganguan-Ganguan pada Sifat dan Perilaku Anak, termasuk
1. Mengidentifikasi komponen software yang harus ditest
2. Membuat rekomendasi kebutuhan untuk Test
3. Membuat rekomendasi dan mendeskripsikan testing strategi yang akan dilakukan
4. Mengidentifikasi kebutuhan sumberdaya(dari database maupun komponen yang di
gunakan
1.2 Background
Tahap pengujian pada software yang dibangun mutlak dibutuhkan agar kinerja
dari software maupun database yang di gunakan dapat berjalan sesuai dengan yang
diharapkan. Selain itu tahap ini juga dilakukan untuk menanggulangi maupun
mengurangi terjadinya kesalahan(error) .
Adapun lingkup testing yang akan dilakukan agar kinerja software dapat berjalan
dengan baik meliputi :
1. Source Code, merupakan bagian dari software yang digunakan untuk
mengatur jalannya program.pengujian pada bagian ini bertujuan untuk
mengurangi kemungkinan adanya bug pada software yang kita bangun. Tools
yang kami gunakan untuk mencari bug pada source code adalah dengan visual
studio 2008.
2. Database(SQL Server 2005), adalah Sistem manajemen basis data
relasional(RDBMS) produk Microsoft query utamanya adalah Transact-SQL
yang merupakan implementasi dari SQL standar ANSI/ISO yang digunakan
oleh Microsoft dan Sybase. Umumnya SQL Server digunakan di dunia bisnis
yang memiliki basis data berskala kecil sampai dengan menengah, tetapi
kemudian berkembang dengan digunakannya SQL Server pada basis data
besar. Tujuan diadakannya pengujian pada fitur ini yaitu agar pencatatan
record pada database yang digunakan dapat berjalan dengan baik.
Confidential © Kelompok 04 PRPL, 2011 Page 5
komunikasi antara user dengan sistem. Pengujian pada bagian ini dilakukan
agar user dapat menggunakan software yang kami buat dengan mudah, selain
itu pengujian pada bagian ini juga bertujuan agar fasilitas-fasilitas yang ada
pada masing-masing form dapat bekerja sesuai dengan keinginan.
1.3 Scope
Dokumen ini hanya membahas tentang pengujian(testing) terhadap software yang
dibangun .
Ruang Lingkup yang akan diuji meliputi pengujian source code, performa,
keamanan , dan keakurantan software yang akan dibuat.Selain itu pengujian juga akan di
lakukan pada masing-masing form yang ada dalam software.Pengujian hanya dilakukan
dengan tester.
Confidential © Kelompok 04 PRPL, 2011 Page 6 1.4 Project Identification
sDocument
(and version / date)
Created
or
Available
Received or
Reviewed
Author or
Resource
Notes
Requirements
Specification
Yes No Yes No
Functional Specification
Yes No Yes No
Use Case Reports
Yes No Yes No
ERD Reports
Yes No Yes No
Project Plan
Yes No Yes No
Design Specifications
Yes No Yes No
Prototype
Yes No Yes No
Users Manuals
Yes No Yes No
Business Model / Flow
Yes No Yes No
Data Model / Flow
Yes No Yes No
Business Functions and
Rules
Yes No Yes No
Project / Business Risk
Assessment
Confidential © Kelompok 04 PRPL, 2011 Page 7
2. Requirements for Test
Testing akan dilakukan pada Entity Relational Diagram(untuk mengidentifikasi
table-tabel yang dibutuhkan) ,Data Flow Diagram(untuk mengidentifikasi alur bisnis) dan
fungsi dari masing-masing form serta source code pada software yang dibangun
3. Test Strategy
Strategi terdiri dari seluruh rencana yang dilakukan untuk melakukan testing pada
software yang di bangun
3.1 Testing Types
3.1.1 Data and Database Integrity Testing
Test Objective:
Query dapat menghasilkan informasi yang di butuhkan
Technique:
Melakukan query select pada database
Melakukan query DML pada database
Mengecek relasi masing-masing table dengan melakukan bernagai
macam query
Completion Criteria: Database dapat menjalankan tiap query yang dilakukan dengan
baik
Special
Considerations:
Terjadi gangguan pada jaringan , sehingga proses tidak dapat di
lakukan
3.1.2 Function Testing
Test Objective:
Form Input(semua form yang membutuhkan input data) dapat
melakukan input data untuk database atau untuk diproses
Form laporan dapat menghasilkan hasil transaksi sesuai
dengan input dan proses yang ada
Technique:
Menguji masing-masing tombol pada form
Menguji form inputan dengan berbagai kondisi input
Memastikan hasil laporan sesuai dengan inputan dan data
yang ada pada master
Completion Criteria: Tiap-tiap form input dapat melakukan input data kedalam
database maupun input data untuk diproses dengna baik
Output yang dikeluarkan sesuai dengan input dan transaksi
yang telah dibuat
Confidential © Kelompok 04 PRPL, 2011 Page 8
Special
Considerations:
Confidential © Kelompok 04 PRPL, 2011 Page 9 3.1.3 Business Cycle Testing
Test Objective
Hasil Diagnosa dapat memberikan output yang sesuai dengan data
input dan rule yang telah di berikan.
Technique:
Menguji alur logika program
Menguji form dengan berbagai kondisi inputtan data
Menguji pencetakan laporan hasil diagnose
Completion Criteria: Form dapat memberikan Hasil Diagnosa
Form dapat mencetak hasil diagnose
Special
Considerations:
Confidential © Kelompok 04 PRPL, 2011 Page 10 3.1.4 User Interface Testing
Test Objective:
Memastikan semua komponen yang ada pada masing-masing
form dapat bekerja dengan baik
Technique:
1. Form login:
Input:-menginputkan karakter untuk melakukan sql injection.
Melakukan brute force password
Output:Form login hanya dapat menerima user yang memiliki hak
akses.
2. Form laporan:
Input: berbagai kondisi penyakit
Output: form laporan dapat menghasilkan berbagai macam
laporan sesuai dengan kondisi yang di inputkan.
3. Form master:
Input: gangguan,gejala, basis pengetahuan
Output: database dapat menyimpan input dari masing-masing
form.
Completion Criteria: Tampilan dari aplikasi mudah di gunakan oleh user
Special
Considerations:
Confidential © Kelompok 04 PRPL, 2011 Page 11 3.1.5 Performance Profiling
Test Objective:
Waktu penyimpanan record,proses menghasilkan hasil diagnosa
dapat dilakukan dengan cepat
Technique:
Penyimpanan data dilakukan oleh beberapa user(computer)
dalam waktu yang bersamaan.
Melakukan proses menghasilkan hasil diagnosa yang
dilakukan oleh beberapa computer yang dilakukan sekaligus
Completion Criteria: Waktu yang dibutuhkan untk proses penyimpanan data maupun
proses penghasilan hasil diagnose tetap berjalan normal walaupun
dilakukan penyimpanann data uleh beberapa user sekaligus.
Special
Considerations:
Confidential © Kelompok 04 PRPL, 2011 Page 12 3.1.6 Load Testing
Test Objective:
Waktu akses database dan aplikasi
Technique:
Menggunakan query yang menghasilkan data dalam
jumlah besar.
Mengukur waktu load aplikasi dengan berbagai macam
spesifikasi computer.
Completion Criteria:
Software dan database dapat di akses dengan cepat.
Special Considerations:
Adanya gangguan pada koneksi ke database.
Confidential © Kelompok 04 PRPL, 2011 Page 13 3.1.7 Stress Testing
[Stress testing is a type of performance test implemented and executed to find
errors due to low resources or competition for resources. Low memory or disk space may
reveal defects in the target-of-test that aren't apparent under normal conditions. Other
defects might results from competition for shared resource like database locks or network
bandwidth. Stress testing can also be used to identify the peak workload the target-of-test
can handle.]
[NOTE: References to transactions below refer to logical business transactions.]
Test Objective: Verify that the target-of-test functions properly and without error under the following stress conditions:
little or no memory available on the server (RAM and DASD)
maximum (actual or physically capable) number of clients connected (or simulated)
multiple users performing the same transactions against the same data / accounts
worst case transaction volume / mix (see performance testing above).
NOTES: The goal of Stress test might also be stated as identify and document the conditions under which the system FAILS to continue functioning properly. Stress testing of the client is described under section 3.1.11, Configuration testing.
Technique: Use tests developed for Performance Profiling or Load Testing.
To test limited resources, tests should be run on single machine, RAM and DASD on server should be reduced (or limited).
For remaining stress tests, multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix.
Completion Criteria: All planned tests are executed and specified system limits are reached / exceeded without the software or software failing (or conditions under which system failure occurs is outside of the specified conditions).
Special Considerations: Stressing the network may require network tools to load the network with messages / packets.
The DASD used for the system should temporarily be reduced to restrict the available space for the database to grow.
Synchronization of the simultaneous clients accessing of the same records / data accounts.
Confidential © Kelompok 04 PRPL, 2011 Page 14 3.1.8 Volume Testing
[Volume Testing subjects the target-of-test to large amounts of data to determine
if limits are reached that cause the software to fail. Volume testing also identifies the
continuous maximum load or volume the target-of-test can handle for a given period. For
example, if the target-of-test is processing a set of database records to generate a report, a
Volume Test would use a large test database and check that the software behaved
normally and produced the correct report.]
Test Objective: Verify that the target-of-test successfully functions under the following high volume scenarios:
maximum (actual or physically capable) number of clients connected (or simulated) all performing the same, worst case (performance) business function for an extended period.
maximum database size has been reached (actual or scaled) and multiple queries / report transactions are executed simultaneously.
Technique: Use tests developed for Performance Profiling or Load Testing.
Multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix (see stress test above) for an extended period.
Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries / report transactions
simultaneously for extended periods.
Completion Criteria: All planned tests have been executed and specified system limits are reached / exceeded without the software or software failing.
Special Considerations: What period of time would be considered an acceptable time for high volume conditions (as noted above)?
Confidential © Kelompok 04 PRPL, 2011 Page 15 3.1.9 Security and Access Control Testing
Test Objective:
Software hanya dapat digunakan oleh user yang telah
melakukan login (melalui form login).
Technique:
Mencoba melakukan sql injection dengan mencari
kesalahan logika dalam query dan code yang di
gunakan
Mencoba hak akses setiap user dan mencoba berbuat
kecurangan dari hak akses yang di milikinya.
Completion Criteria:
Software tidak dapat dibobol/digunakan oleh user yang
tidak memiliki hak akses
Confidential © Kelompok 04 PRPL, 2011 Page 16 3.1.10 Failover / Recovery Testing
[Failover / Recovery testing ensures that the target-of-test can successfully
failover and recover from a variety of hardware, software, or network malfunctions with
undue loss of data or data integrity.
Failover testing ensures that, for those systems that must be kept running, when a
failover condition occurs, the alternate or backup systems properly “take over” for the
failed system without loss of data or transactions.
Recovery testing is an antagonistic test process in which the application or system
is exposed to extreme conditions (or simulated conditions) to cause a failure, such as
device I/O failures or invalid database pointers / keys. Recovery processes are invoked
and the application / system is monitored and / or inspected to verify proper application /
system / and data recovery has been achieved.]
Test Objective: Verify that recovery processes (manual or automated) properly restore the database, applications, and system to a desired, known, state. The following types of conditions are to be included in the testing:
Power interruption to the client Power interruption to the server
Communication interruption via network server(s) Interruption, communication, or power loss to DASD
and or DASD controller(s)
Incomplete cycles (data filter processes interrupted, data synchronization processes interrupted).
Invalid database pointer / keys
Confidential © Kelompok 04 PRPL, 2011 Page 17 Technique: Tests created for Function and Business Cycle testing should
be used to create a series of transactions. Once the desired starting test point is reached, the following actions should be performed (or simulated) individually:
Power interruption to the client: power the PC down Power interruption to the server: simulate or initiate
power down procedures for the server
Interruption via network servers: simulate or initiate communication loss with the network (physically disconnect communication wires or power down network server(s) / routers).
Interruption, communication, or power loss to DASD and or DASD controller(s): simulate or physically eliminate communication with one or more DASD controllers or devices.
Once the above conditions / simulated conditions are achieved, additional transactions should executed and upon reaching this second test point state, recovery procedures should be invoked.
Testing for incomplete cycles utilizes the same technique as described above except that the database processes
themselves should be aborted or prematurely terminated.
Testing for the following conditions requires that a known database state be achieved. Several database fields, pointers and keys should be corrupted manually and directly within the database (via database tools). Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed.
Completion Criteria: In all cases above, the application, database, and system should, upon completion of recovery procedures, return to a known, desirable state. This state includes data corruption limited to the known corrupted fields, pointers / keys, and reports indicating the processes or transactions that were not completed due to interruptions.
Confidential © Kelompok 04 PRPL, 2011 Page 18 Special Considerations: Recovery testing is highly intrusive. Procedures to
disconnect cabling (simulating power or communication loss) may not be desirable or feasible. Alternative methods, such as diagnostic software tools may be required.
Resources from the Systems (or Computer Operations), Database, and Networking groups are required. These tests should be run after hours or on an isolated machine(s).
Confidential © Kelompok 04 PRPL, 2011 Page 19 3.1.11 Configuration Testing
Test Objective: Hardware dan software dari requirement software dapat berjalan sesuai dengan konfigurasi yang di inginkan
Technique: 1. Memaksimalkan penggunaan memory(ram) terhadap sistem serta penggunaan ruang simpan data.
Input : melihat penggunaan memory dengan menggunakan task manager.
Proses : melakukan pencatatan dan analisa penggunaan memori dan sisa ruang simpan data
Output : Investasi yang dilakukan atas hardware dan software sesuai dengan manfaat yang diberikan
2. Melakukan instalasi aplikasi ke operating sistem yang berbeda.
3. Melakukan instalasi aplikasi ke komputer dengan spesifikasi yang berbeda
Completion Criteria: 1. Aplikasi mampu berjalan pada operating sistem yang berbeda 2. Aplikasi mampu berjalan pada computer dengan spesifikasi yang
berbeda
3. Kesesuaian data antara pengujian harware dengan software Special Considerations: Data ini bersifat asumsi kelompok,karena keterbatasan alat
Confidential © Kelompok 04 PRPL, 2011 Page 20 3.1.12 Installation Testing
[Installation testing has two purposes. The first is to insure that the software can
be installed under different conditions, such as a new installation, an upgrade, and a
complete or custom installation, and under normal and abnormal conditions. Abnormal
conditions include insufficient disk space, lack of privilege to create directories, etc. The
second purpose is to verify that, once installed, the software operates correctly. This
usually means running a number of the tests that were developed for Function testing.]
Test Objective: Verify that the target-of-test properly installs onto each required hardware configuration, under the following conditions (as required):
New Installation, a new machine, never installed previously with <Project Name>
Update machine previously installed <Project Name>, same version
Update machine previously installed <Project Name>, older version
Technique: Manually or develop automated scripts to validate the condition of the target machine (new - <Project Name> never installed, <Project Name> same version or older version already installed).
Launch / perform installation.
Using a predetermined sub-set of function test scripts, run the transactions.
Completion Criteria: <Project Name> transactions execute successfully without failure.
Special Considerations: What <Project Name> transactions should be selected to comprise a confidence test that <Project Name> application has been successfully installed and no major software components are missing?
Confidential © Kelompok 04 PRPL, 2011 Page 21 3.2 Tools
Tool
Vendor/In-house
Version
Test Management
Defect Tracking
ASQ
Tool
(functional
testing)
ASQ Tool (performance
testing)
Test Coverage Monitor or
Profiler
Project Management
Confidential © Kelompok 04 PRPL, 2011 Page 22
4. Resources
Disini di jelaskan tentang resource yang di rekomendasikan untuk melakukan testing
pada Sistem Informasi Koperasi Karyawan “STIKOM Surabaya” untuk melakukan transaksi
transaksi yang ada pada Koperasi Karyawan “STIKOM Surabaya”.
4.1 Workers
Worker
Minimum Resources
Recommended
(number of workers
allocated full-time)
Specific Responsibilities/Comments
Test Manager / Test
Project Manager
Mengatasi semua kegiatan dalam proyek.
Mengetahui jalannya program
Memanajemen alur system
Test Designer
Melakukan survey atas kebiasaan user
Tester
Membuat test plan.
Membuat solusi atas eror yang terjadi
Test
System
Administrator
Mengatur hak akses masing-masing user
Database
Administration
/
Database Manager
Mengadministrasi data yang ada dalam
database.
Melakukan maintenance database
Melakukan backup pada periode tertentu
Designer
Mengidentifikasi dan mendefinisikan
operasi, atribut, dan relasi data uji.
Rincian Tugas :
1. Mengidentifikasi dan mendefinisikan
kelas-kelas uji
2. Mengidentifikasi dan mendefinisikan
paket-paket data yang di uji.
Confidential © Kelompok 04 PRPL, 2011 Page 23
Implementer
Menerapkan dan menguji coba proyek yang
di kembangkan
Rincian Tugas :
1. Mencoba aplikasi sesuai dengan alur
yang telah di buat.
2. Melakukan pencatatan atas segala
kejadian
yang
terjadi
selama
penerapan
Confidential © Kelompok 04 PRPL, 2011 Page 24 4.2 System
Berikut ini daftar tabel kebutuhan peralatan dari pelaksanaan testing. Ada beberpa
bagian yang tidak terdefinisi dari pelaksanaan testing ini. Adapun yang akan di lakukan uji
coba meliputis simulasi dari proses bisnis proyek, pengukuran skala proyek dan validasi
data di dalam database.
System Resources
Resource
Name / Type
Database Server
—
Network/Subnet
—
Server Name
—
Database Name
Client Test PC's
—
Include special configuration
—
requirements
Test Repository
—
Network/Subnet
—
Server Name
Test Development PC's
5. Project Milestones
[Testing of <Project Name> should incorporate test activities for each of the test
efforts identified in the previous sections. Separate project milestones should be
identified to communicate project status and accomplishments.]
Milestone Task Effort Start Date End Date
Plan Test Design Test Implement Test Execute Test Evaluate Test
Confidential © Kelompok 04 PRPL, 2011 Page 25
6. Deliverables
[In this section list the various documents, tools, and reports that will be created,
by whom, delivered to who, and when delivered]
6.1 Test Model
[This section identifies the reports that will be created and distributed from the
test model. These artifacts in the test model should be created or referenced in the ASQ
tools.]
6.2 Test Logs
[Describe the method and tools used to record and report on the test results and
testing status.]
6.3 Defect Reports
[In this section, identify the method and tool(s) used to record, track, and report
on test incidents and their status.]
Confidential © Kelompok 04 PRPL, 2011 Page 26
7. Appendix A: Project Tasks
Below are the test related tasks: Plan Test
Identify Requirements for Test Assess Risk
Develop Test Strategy Identify Test Resources Create Schedule Generate Test Plan Design Test Workload Analysis
Identify and Describe Test Cases Identify and Structure Test Procedures Review and Access Test Coverage Implement Test
Record or Program Test Scripts
Identify Test-Specific functionality in the design and implementation model Establish External Data sets
Execute Test
Execute Test Procedures Evaluate Execution of Test Recover from Halted Test Verify the results
Investigate Unexpected Results Log Defects
Evaluate Test
Evaluate Test-Case Coverage Evaluate Code Coverage Analyze Defects
