Introduction to Software Engineering: Tools and Environments
Session 7
Oded Lachish
Room: Mal 405 Visiting Hours: Wednesday 17:00 to 20:00 Email: [email protected] Module URL: http://www.dcs.bbk.ac.uk/~oded/Tools2012-2013/Web/Tools2012-2013.html
1 Last time
• Debugging with Eclipse • Code coverage with corbetura • Static code analysis – Checkstyle, PMD, FindBugs
Hopefully by now we know how to mock software. Hopefully we also have some tools for debugging.
Remember: an important goal of these tools is minimal interaction with product code.
2 Verification Overview
3 What have we seen until now
Dynamic Verification • The software’s behaviour is checked dynamically during execution
Static verification • The software is checked via a static analysis
4 Dynamic verification
Scope: • Small – unit testing (Junit) • Large ‐ Integration testing (Cucumber) • Even larger ‐ System test Types of tests • Functional • Stress (non functional) Main disadvantage • Can’t cover all the cases
5 Static verification
Formal Verification: • Formally proving that code abides certain behavioural rules Can be done automatically or semi automatically. (We didn’t do since it is applicable only in a very small number of cases) Code convention • Check that software abides a recommended coding style. The coding style is there to improve readability, to prevent future bugs etc. Tools: Checkstyle, PMD and Findbugs
Anything else?
6 Code Review Jupiter http://jupiter‐eclipse‐plugin.googlecode.com/svn/trunk/site/
7 jupiter
Code review plug‐in for eclipse Important features: • Open Source
• Cross‐platform ‐ available for all platforms supported by Eclipse.
• XML data storage: stores data in XML format. • Supports sorting and searching
• File integration: easy to jump go back and forth between reviews
and source code.
8 Jupiter –Four Step Process
Code review plug‐in for eclipse Step 1: Configuration • Insertion of review information by leader of review –(important – must be committed) Step 2: Individual review • Each person by himself • Issues are created • At this stage only issues created by the selected user
9 Jupiter –Four Step Process
Code review plug‐in for eclipse Step 3: Team • One person updates their local environment so that it contains all the review files • All issues can be seen • The team modifies issues upon need Step 4: Rework Phase • Author of code resolves issues (fixes code) • Author of code updates issue accordingly • Review files are committed and permanently stored as part of the project
10 Review ID
A review ID consists of the following • The set of files to be reviewed • The list of reviewers • The review session author • Review storage location • Item entries ‐ Type, Severity, Resolution, and Status fields (are customizable.) • Default items ‐ default values for fields when a new issue is created. • Filters – filter to be applied when issues are displayed
11 Creating Review ID ‐Start
Press
You should get Press 12 Creating Review ID –ID creation
Pick a review name
Enter description
13 Creating Review ID – adding files
Press
You should get 14 Creating Review ID –ID creation
Pick a review name
Enter description
15 Creating Review ID – Added files
16 Creating Review ID – Adding a Reviewer
Press
This should appear
Add name
17 Creating Review ID – Session Author
18 Creating Review ID – Session Author
Press to get options
19 Creating Review ID – Finish
20 Creating Review ID –What New?
Review directory Jupiter perspective
21 Jupiter advanced options –getting there 1
Press
22 Jupiter advanced options –getting there 2
Press
23 Jupiter advanced options –getting there 3
Pick Press
24 Jupiter advanced options –getting there 4
Press
25 Jupiter advanced options –entry items
Items may be added, removed and reordered
26 Jupiter advanced options – filters
Options for focusing only on specific issues
27 Adding an issue
Right click and press
28 Adding issues
29 Review Table
30 Changing phase to Team
Press
A new issue appears. This is from a different author. (check if you can add such an issue by yourself)
31 From Individual phase to Team Phase
Code
32 After decision made
Decision made issue removed
Make another decision
33 Rework Phase Issues and what need to be done
Only issues relevant to the person responsible for them appear
Now only revision text can be changed
34 Bug‐Tracking‐Systems
35 Bugzilla
36 What is Bugzilla?
Bug‐Tracking‐System‐ a system for keeping track of bugs and how they are resolved Important features: • Open Source • inter‐bug dependencies and dependency graphing • extensive configurability And many more features
37 Why use Bugzilla?
When software quality is at a high priority bug tracking is essential.
1. Monitoring bugs and their resolution as part of the workflow 2. Keeping in touch with the bug resolution process through e‐mail integrated features 3. Archiving bug related information 4. Accountability 5. Open‐source enables customers to use system
38 Installing Bugzilla
Taken from: http://cvs1.up.ac.za/bugzilla‐doc/stepbystep.html#AEN515
The software packages necessary for the proper running of bugzilla are: 1.MySQL database server and the mysql client (3.22.5 or greater) 2.Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla) 3.DBI Perl module 4.Data::Dumper Perl module 5.Bundle::Mysql Perl module collection 6.TimeDate Perl module collection 7.GD perl module (1.8.3) (optional, for bug charting) 8.Chart::Base Perl module (0.99c) (optional, for bug charting) 9.DB_File Perl module (optional, for bug charting) 10.The web server of your choice. Apache is recommended. 11.MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)
39 Landfill: The Bugzilla Test Server http://landfill.mozilla.org/
This demonstration is taken from the above link. Requires e‐mail address ‐ to open account
Bugzilla Trunk Demo ‐ A demo installation running the "trunk" (meaning, very latest unstable)
40 Welcome to Bugzilla
41 Pick a product
42 Bug report
43 Starting to enter a bug
Bugzilla suggests possible duplicates. Why is this important?
44 45 Making sense of it all
Status –open bugs • UNCONFIRMED ‐ just added to the database. Not confirmed that this bug is valid. Can either change to CONFIRMED (if confirmed) or directly to RESOLVED (if it is resolved). • CONFIRMED ‐ a recently filed actual bug. If someone is working on it is changed to IN_PROGRESS or directly to RESOLVED (if it is resolved). • IN_PROGRESS ‐ can change to CONFIRMED if directed to another person, or resolved and become or directly to RESOLVED (if it is resolved).
46 Making sense of it all
Status –closed bugs • RESOLVED ‐ code changed, now it is QA’s turn. Can either be reopened or if QA approve change to VERIFIED. • VERIFIED ‐ QA approved bug should be gone now –final state. Other options • FIXED a fix for this bug is checked into the tree and tested. • INVALID not a bug. • WONTFIX bug that there is no plan to fixed. • DUPLICATE already appeared • WORKSFORME bug can’t be reproduced or explained –waiting for additional information which may lead to reopening of bug. 47 Life cycle of a bug
Taken from http://wiki.eclipse.org/Image: BzLifecycle.png
48 Important fields
• Assignee ‐ the person in charge of resolving the bug. • Bug ID ‐ the numeric id of a bug, unique within this entire installation of Bugzilla. • CC ‐ users who may not have a direct role to play on this bug, but who are interested in its progress. • Classification ‐ bugs are categorized into Classifications, Products and Components. classifications is the top‐level categorization. • Component ‐ second‐level categories; each belongs to a particular Product. Select a Product to narrow down this list. • Depends on ‐ the bugs listed here must be resolved before this bug can be resolved. • Reporter ‐ the person who filed this bug. • Severity ‐ how severe the bug is, or whether it's an enhancement.
49 Bugzilla Report Generator
50 Report selected
51 Generated report table format
52 Generated report
53 Simple search
54 Advanced search
55 Change over time
56 Old Charts
57 Bug Count
58 Create Chart ‐ 1
59 Create Chart ‐ 2
60 New Chart
61 How to write bug reports
Seems that writing bug reports is an art: The report should be: • Concise • Clear • Only one bug per report • Don’t confuse fact with speculation
!! – A bug report should contain enough information to reproduce the bug.
(for more guidelines: https://landfill.bugzilla.org/bugzilla‐tip/page.cgi?id=bug‐writing.html)
62 Trac http://trac.edgewall.org/
Most of the material below has been taken from: http://trac.edgewall.org/wiki/WikiFormatting
63 What is Trac?
Enhanced wiki and issue tracking system for software development projects. Important features: • web based • minimalistic approach • extensive configurability and many more features
64 Wiki formatting rules examples
http://trac.edgewall.org/wiki/WikiFormatting
65 Trac tickets Trac has a database for tickets. Ticket Fields • Reporter —The author of the ticket. • Type —The nature of the ticket (for example, defect or enhancement request). • Component —The project module or subsystem this ticket concerns. • Version — Version of the project that this ticket pertains to. • Keywords —Keywordsthat a ticket is marked with. Useful for searching and report generation. • Priority —The importance of this issue, ranging from trivial to blocker. A pull‐down if different priorities where defined. • Milestone —When this issue should be resolved at the latest. A pull‐ down menu containing a list of milestones. • Assigned to/Owner —Principal person responsible for handling the issue.
66 Trac tickets editing
Some Trac installations may put restrictions in place about who can change what. For example, the default installation doesn't permit to non‐ authenticated users ("anonymous" users) to change anything, even to comment on an issue, for obvious spam prevention reasons. Check the local contributing policy, which you can usually find on the front page WikiStart, or contact your local Trac administrator.
67 Trac project monitoring
Monitoring Trac can be done by RSS (Really Simple Syndication)
Trac tells you when you can use the RSS via the standard orange XML icon.
68 Trac reports
Trac timeline • Reports Trac events in chronological order including a brienf description and the name of the person responsible Type of creation and changed events reported: • Wiki pages • Tickets • Source code Also reports milestones achieved. Of course: filters can be applied
69 Trac reports http://trac.edgewall.org/report/1
70 Trac timeline http://trac.edgewall.org/timeline
71 Trac project monitoring
Monitoring Trac can be done by RSS (Really Simple Syndication)
Trac tells you when you can use the RSS via the standard orange XML icon.
72 Trac Installation
Required 1. Python 2. Database, SQLite, PostgreSQL, or MySQL. And its Python binding 3. Genshi templating system ‐ for HTML rendering. 4. Setuptools Optional • Apache –web server • Subversion and the corresponding Python binding 73