Konsep & Prinsip
Analisis
Ali Tarmuji
Email: [email protected]
ID YM: alitarmuji
Program Studi Teknik Informatika
Fakultas Teknologi Industri
Universitas Ahmad Dahlan
T. Informatika UAD 1
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Cakupan materi pendahuluan
Analisis Kebutuhan Perangkat Lunak
Teknik Komunikasi
Prinsip-prinsip analisis
Prototyping perangkat lunak
Spesifikasi dan kajian spesifikasi
Rekayasa Perangkat Lunak 2
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Software Testing
Pengujian merupakan proses untuk mengujicoba
program dengan tujuan untuk menemukan kesalahan
sebelum program tsb dikirimkan ke pemakai.
Rekayasa Perangkat Lunak 3
Teknik Informatika – FTI-Universitas Ahmad Dahlan
What Testing Shows
errors
requirements conformance
performance
an indication
of quality
Rekayasa Perangkat Lunak 4
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Siapa tester software?
developer independent tester
Mengerti sistemnya Harus mpelajari sistem
Biasanya tdk independen Tetapi akan testing dg benar
Dan terpengaruh pd kepentingan Berbasis pada kualitas
Rekayasa Perangkat Lunak 5
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Strategi Pengujian (1)
unit test integration
test
system validation
test test
Rekayasa Perangkat Lunak 6
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Strategi Pengujian (2)
Pengujian dimulai dari ‘hal yg kecil' dan
bergerak ke arah ‘hal yg besar‘
Untuk PL konvensional:
Perhatian pada komponen
integrasi pada modul yang menyertainya.
untuk OO software
fokus tertuju pada “uji kecil" perubahan dari setiap
modul (konvensional view) untuk kelas OO yang
meliputi atribut dan operasi dan menunjukkan
komunikasi dan kolaborasi
Rekayasa Perangkat Lunak 7
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Topik strategis
Mempunyai tujuan pengujian secara eksplisit.
Memahami pengguna software dan mengembangkan
sebuah profil untuk setiap kategori pengguna.
Mengembangkan rencana pengujian yang menekankan
"siklus uji cepat."
Membangun “cepat" perangkat lunak yang dirancang
untuk menguji sendiri
Gunakan efektif tinjauan teknis formal sebagai filter
sebelum pengujian
Melakukan kajian teknis formal untuk menilai strategi tes
dan kasus tes itu sendiri.
Perbaikan terus mengembangkan pendekatan untuk
proses pengujian.
Rekayasa Perangkat Lunak 8
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Unit Testing
modul
Yg dites
Hasil
software
engineer
test cases
Rekayasa Perangkat Lunak 9
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Tes unit
Modul
yg dites
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
Rekayasa Perangkat Lunak 10
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Lingkungan Tes Unit
driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub
test cases
RESULTS
Rekayasa Perangkat Lunak 11
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Strategi pengujian integrasi
Options:
• sebuah pendekatan “big bang”
• strategi pengembangan bertahap
Rekayasa Perangkat Lunak 12
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Integrasi Top Down
A top module is tested with
stubs
B F G
stubs are replaced one at
a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-
re-run
D E
Rekayasa Perangkat Lunak 13
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Integrasi Bottom-Up
A
B F G
drivers are replaced one at a
time, "depth first"
C
worker modules are grouped into
builds and integrated
D E
cluster
Rekayasa Perangkat Lunak 14
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Sandwich Testing
A
Top modules are
tested with stubs
B F G
C
Worker modules are grouped into
builds and integrated
D E
cluster
Rekayasa Perangkat Lunak 15
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Object-Oriented Testing
dimulai dengan mengevaluasi kebenaran dan
konsistensi dari model OOA dan OOD
Perubahan strategi pengujian
dengan konsep 'unit' dipecah dalam konsep karena
encapsulation
Integrasi berfokus pada kelas dan pelaksanaan
across a ‘thread’ or in the context of a usage scenario
validation uses conventional black box methods
test case design draws on conventional
methods, but also encompasses special features
Rekayasa Perangkat Lunak 16
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Broadening the View of “Testing”
It can be argued that the review of OO analysis
and design models is especially useful because
the same semantic constructs (e.g., classes,
attributes, operations, messages) appear at the
analysis, design, and code level. Therefore, a
problem in the definition of class attributes that is
uncovered during analysis will circumvent side
effects that might occur if the problem were not
discovered until design or code (or even the next
iteration of analysis).
Rekayasa Perangkat Lunak 17
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Testing the CRC Model
1. Revisit the CRC model and the object-relationship model.
2. Inspect the description of each CRC index card to determine if a
delegated responsibility is part of the collaborator’s definition.
3. Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required or whether responsibilities
are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 to 5 are applied iteratively to each class and through
each evolution of the OOA model.
Rekayasa Perangkat Lunak 18
Teknik Informatika – FTI-Universitas Ahmad Dahlan
OOT Strategy
class testing is the equivalent of unit testing
operations within the class are tested
the state behavior of the class is examined
integration applied three different strategies
thread-based testing—integrates the set of classes required to
respond to one input or event
use-based testing—integrates the set of classes required to
respond to one use case
cluster testing—integrates the set of classes required to
demonstrate one collaboration
Rekayasa Perangkat Lunak 19
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Smoke Testing
A common approach for creating “daily builds” for
product software
Smoke testing steps:
Software components that have been translated into code are
integrated into a “build.”
A build includes all data files, libraries, reusable modules, and
engineered components that are required to implement one or
more product functions.
A series of tests is designed to expose errors that will keep the
build from properly performing its function.
The intent should be to uncover “show stopper” errors that have
the highest likelihood of throwing the software project behind
schedule.
The build is integrated with other builds and the entire product
(in its current form) is smoke tested daily.
The integration approach may be top down or bottom up.
Rekayasa Perangkat Lunak 20
Teknik Informatika – FTI-Universitas Ahmad Dahlan
High Order Testing
Validation testing
Focus is on software requirements
System testing
Focus is on system integration
Alpha/Beta testing
Focus is on customer usage
Recovery testing
forces the software to fail in a variety of ways and verifies that recovery is
properly performed
Security testing
verifies that protection mechanisms built into a system will, in fact, protect it
from improper penetration
Stress testing
executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
Performance Testing
test the run-time performance of software within the context of an integrated
system
Rekayasa Perangkat Lunak 21
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Debugging: A Diagnostic Process
Rekayasa Perangkat Lunak 22
Teknik Informatika – FTI-Universitas Ahmad Dahlan
The Debugging Process
test cases
new test results
regression cases
tests suspected
causes
corrections Debugging
identified
causes
Rekayasa Perangkat Lunak 23
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Debugging Effort
time required
to diagnose the
symptom and
time required determine the
to correct the error cause
and conduct
regression tests
Rekayasa Perangkat Lunak 24
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Symptoms & Causes
symptom and cause may be
geographically separated
symptom may disappear when
another problem is fixed
cause may be due to a
combination of non-
non-errors
cause may be due to a system
or compiler error
symptom cause may be due to
cause assumptions that everyone
believes
symptom may be intermittent
Rekayasa Perangkat Lunak 25
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Consequences of Bugs
infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function
function--related bugs,
system--related bugs, data bugs, coding bugs,
system
design bugs, documentation bugs, standards
violations, etc.
Rekayasa Perangkat Lunak 26
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Debugging Techniques
brute force / testing
backtracking
induction
deduction
Rekayasa Perangkat Lunak 27
Teknik Informatika – FTI-Universitas Ahmad Dahlan
Debugging: Final Thoughts
1. Don't run off half-cocked, think about the
symptom you're seeing.
2. Use tools (e.g., dynamic debugger) to gain
more insight.
3. If at an impasse, get help from someone else.
4. Be absolutely sure to conduct regression tests
when you do "fix" the bug.
Rekayasa Perangkat Lunak 28
