Translate

Monday, December 19, 2016

JUnit

Last post introduced unit testing and specifically c# unit testing. I have decided to continue that train of thought and do this post on the basics of JUnit and specifically JUnit in Eclipse.

I have decided to let the videos and screenshots describe what is going on





This is adding a test suite and test case to a java project. As you can see it is actually very similar to adding unit tests in Microsoft visual studio.











This is showing the testing menu that is available once you have created your test cases and test suites.



This also allows you to run only certain tests not necessarily all of them. It also allows you to tell what tests have failed and what hasn't.




Thursday, November 17, 2016

c# Unit testing

As a programmer, it is very crucial to learn testing techniques that will make my programs better. A method of doing this is through a type of automated testing called Unit testing. Depending on the language it is called different things, such as JUnit for Java Unit testing and NUnit for C# Unit testing. It really is the same principle no matter what language you use. In this post I will go through the basics using NUnit as the example.
What is unit testing? According to google, the source of all knowledge, "Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. "
This means that the goal of unit testing to test each individual part independently of the other parts. On a side note it is usually a good idea to have these written before you start programming, that way you are not customizing a bias test when your function is done.
Now that we know what it is lets see how to create a good unit test.

Step 1: Creating the logic of the test
This is usually done by the Requirements specifications. In other words, what is this supposed to do. Other things to note is that you also want to make sure when something happens that is not supposed to, that you handle it accordingly (error messages and such).

Step 2: Create the test
In the IDE, Microsoft Visual Studio, it makes it very simple to write your unit tests and to run them.


In this .gif it shows how to add a test to a already created project. In other words, make your project then add your test class to it.






This screenshot shows an example of the test class and a unit test within that test class
In this you can see that there are three parts to a test arrange, act, and assert. Arrange is the set up of the test in other words the preconditions or the test parameters. Act is the action, method or function being tested is called upon to modify the preconditions. The assert is to make sure that you get what your supposed to. This test that is shown is testing for a right answer. There are tests, like the one below, that make sure errors are displayed given a certain precondition.

Step 3: Write Code
This means you write the programs code, the testing code should already be mostly done.

Step 4: Modify Tests
Requirements could have changed while you were writing certain functions and you must update your tests accordingly.

Step 5: Run the Tests
You should be doing this as you finish the functions. That way you know that the function is written correctly. Shown below is how you run an individual test.


Step 6: Run All Tests
When your code is completely done, you should be able to run all tests and they all pass.

These steps should allow you to get started on writing your own tests. This is in no way a comprehensive way of doing all unit tests, but you should be able to start. Also, depending on the language and IDE it could be slightly different.

Thursday, October 27, 2016

Key Points to Software Testing

This post will cover various points as an overview to software testing. Because this is an overview it may seem scatter brained, but I promise ever point is relevant and import in software testing

  • It is impossible to test everything
  • The challenge is deciding what to test and what not test
  • The nature of testing is an information gathering process
    • information includes things such as reliability and quality of the system being tested
  • Testing does not improve quality, it provides information that allows for the opportunity of improvement
  • Testing Maturity of a company:
    • Level 0: Debugging is sufficient
    • Level 1: Purpose of testing is to show that the software works
    • Level 2: Purpose of testing is to show that the software doesn't work
    • Level 3: Purpose of testing is to reduce the risk of bad things happening
    • Level 4: Improve development competence to prevent problems
  • Developers are inherently not good testers of their code
    • too close to it
    • typically have the same blind spots as when they were writing it
    • developers are optimists
  • Developers must test their own code
    • Through systematic techniques and discipline
    • Getting help such as code inspections
  • Not all bugs are created equal
  • Factors that influence severity:
    • frequency
    • severity of the consequences of the bug
  • Black box testing only finds failures
    • Advatages:
      • Tests are based on UX
      • Can focus on test cases that
        • Emphasize areas likely to have problems
        • Emphasize test user most likely to see
        • Helps make testing efficient 
      • No Knowledge of system under test(SUT) implementation needed
      • can test non-functional requirements
    • Disadvantages:
      • No formal way to know when you are finished
      • Cannot be sure of how much of the system has been tested
      • Easy to miss error cases (sunny day testing)
      • Requirements are slippery (may change, not ready, not exist)
  • White box testing finds errors, faults and failures
    • testing with knowledge of the innards of the software
    • test cases are determined by the code
    • General, robust approach to coverage testing
  • Equivalence Class Testing
    • You can create sets of input which have equivalent behavior
    • All possible inputs show up in one of the created classes
    • IF you execute one test case with data from an equivalent class, that should cover all the data in that class
  • Boundary Value Testing
    • testing the boundaries of the requirements
    • boundary value testing is logical outgrowth of equivalence class testing (extension of ECT)
    • very useful in testing edge cases (behavior typically changes significantly on or at the boundary)
    • Steps to create Boundary tests:
      • Identify equivalence classes
      • Identify the boundaries of each of the equivalence class
      • For each boundary write one case for one unit below, on the boundary and one below
  • Requirements Testing
    • For each requirement, write one or more test case to validate that requirement 
    • not well structured, not systematic
  • State-Transition Testing
    • Diagram the states of the system
    • Write cases to cover all states and transitions
    • Levels of test cases:
      • Level 1: visit each state at least once. This is consider weak coverage
      • Level 2: Exercise each transition at least once. Considered strong coverage
      • Level 3: Trace all possible paths through the state graph. This is the strongest. However, it is impossible to achieve if there are loops present.
    • General practice is level 2
    • You can Augment by adding additional trips through loops, where deemed important
    • Not useful if there is not external state information
  • Cyclomatic Complexity:
    • C = edges - nodes +2
    • C = closed region +1
    • C = predicates +1
  • Basis Paths
    • Each basis path covers at least one edge that no other basis path covers
    • create one test case for each basis path
    • Because a basis path set covers all nodes and edges, it guarantees both branch and statement coverage
    • Steps to generating a Basis Path Set:
      1. Pick a "baseline" path. It should typical path rather than the 'edge case'
      2. For the second path, change the outcome of the first decision node and keep as many other decisions the same
      3. To generate the third path vary the second decision node instead of the first
      4. Continue varying each decision node, until you reach the bottom of the graph
    • Test Cases from a Basis Path
      • Examine decisions and create input that will fire the decisions as you want them
  • Loop Testing
    • Advantages
      • tests areas most likely have errors
      • can keep the number of loop tests lows
    • Disadvantages
      • can miss special cases
      • nested loops can be a problem
      • input can be difficult to generate
  • Code Inspections
    • How it should work
      • code is written and compiled, but not tested
      • Reviewers receive source code
      • reviews study the code
      • Meeting: reviewers discuss code, generally line by line
      • code author is present at the meeting
      • Faults are recorded
    • You should be looking for
      • visible bugs
      • faults
      • bad design
      • bad code
      • comments
    • Intent: Improve the immediate quality and the future maintainability of the code
  • Configuration Testing
    • Testing combinations of components
    • Testing software compatibility with different configurations of software and hardware

I hope this list with brief explanations helps you in some way, shape, or form.

Sunday, October 23, 2016

Back to Selenium IDE

I thought I’d take a minute and give an example of Selenium IDE. I know it has been a while but this whole blog stemmed around Selenium IDE and not being able to find things when I was searching for them. Before I go into this example I would like to point out that since I have last written on Selenium IDE it has changed a little bit how to get to it.
This .gif should help on how to get into it now.
This program is a simulation of google clicks, which is just for practice seeing how it is against google’s terms of service to use it but it does have some pretty nice things to remember when using Selenium IDE.
Make sure to look at the various uses of conditions and searches. It is a nice refresher course of how to do moderate level test cases.
This is the snapshot of the program:


If you can’t read it this is the source code for the program:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://selenium-ide.openqa.org/profiles/test-case">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="selenium.base" href="https://www.google.com/" />
<title>google clicks</title>
</head>
<body>
<table cellpadding="1" cellspacing="1" border="1">
<thead>
<tr><td rowspan="1" colspan="3">google clicks</td></tr>
</thead><tbody>
<tr>
<td>store</td>
<td>5</td>
<td>i</td>
</tr>
<tr>
<td>store</td>
<td>1</td>
<td>j</td>
</tr>
<tr>
<td>while</td>
<td>${i} &gt; ${j}</td>
<td></td>
</tr>
<tr>
<td>store</td>
<td>${j} +1</td>
<td>j</td>
</tr>
<tr>
<td>open</td>
<td>/</td>
<td></td>
</tr>
<tr>
<td>type</td>
<td>id=lst-ib</td>
<td>selenium ide open</td>
</tr>
<tr>
<td>click</td>
<td>name=btnK</td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>refreshAndWait</td>
<td></td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>clickAndWait</td>
<td>id=pnnext</td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>refreshAndWait</td>
<td></td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>clickAndWait</td>
<td>link=Automation Testing: The Selenium IDE 'open' Command</td>
<td></td>
</tr>
<tr>
<td>open</td>
<td>/</td>
<td></td>
</tr>
<tr>
<td>type</td>
<td>id=lst-ib</td>
<td>manual testing</td>
</tr>
<tr>
<td>click</td>
<td>name=btnK</td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>refreshAndWait</td>
<td></td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>clickAndWait</td>
<td>link=6</td>
<td></td>
</tr>
<tr>
<td>clickAndWait</td>
<td>link=7</td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>refreshAndWait</td>
<td></td>
<td></td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>3000</td>
</tr>
<tr>
<td>clickAndWait</td>
<td>link=Automation Testing: Manual Testing, The Art That Cannot Be Lost</td>
<td></td>
</tr>
<tr>
<td>goBackAndWait</td>
<td></td>
<td></td>
</tr>
<tr>
<td>endWhile</td>
<td></td>
<td></td>
</tr>
</tbody></table>
</body>
</html>