…at least to some degree. Well, there are human conditions that distort the perception of time but it’s highly unlikely that you’re one of them. So you are a performance tester too.
The biggest annoyance for a performance tester is to get code into a performance environment that CLEARLY has issues that can be detected by the simplest means available (well.. second most annoying, as finding obvious functional defects is even worse). This is where you as a (whatever kind of) tester come in.
You know the times you drum your fingers on the desk waiting for that spinning wheel in the browser to come back? The batch job where the execution is exactly “making one cup of coffee” long? The usual response from you would be to shrug and say something like “This is just the environment. It’s system test afterall.” or “Let performance testing take care of it”.
Now, I can totally relate to such sentiments! We’re all busy and have deadlines to meet. I’d make the case though that you’d actually help the project as a whole and thereby yourself too by not ignoring such issues.
Somewhere I saw a statement that testing today is about 25% of IT budgets with a tendency to increase. Not sure if that’s true but even half of that is a lot of money. So of course managers and financial controllers are looking where they can eek out any spare $s.
Because testing and quality are not tangible or easily understood by outsiders it is tempting to cut and slash. There are no immediate or obvious down sides (50% of testing is still testing right?). Issues appear later and then the correlation back to the cause is spurious and it’s the operational budget then. And we all know testers are just all doom and gloom.
Now this one is a bit out there but maybe you’ll need this someday.
Sometimes clever developers put XML into table fields as BLOB or CLOB (well actually it’s a special BLOB just for XML so standard SQL won’t quite work as expected). Not sure why one would do that but not my place to comment. Anyway it’s a real pain if your holy grail is burried somewhere in that XML.So after some serious googling and trial and error I finally managed to do this in Groovy.
Often I have to deal with dates and times in my scripting and luckily JMeter is quite good at dealing with them. The function to call is __time (JMeter doco http://jmeter.apache.org/usermanual/functions.html). The thing is the doco is pretty sketchy about all the different formats it can take. So I just created a test script to see what works. The examples are below ready to copy & paste. I also have included scripts for time and date manipulation for completeness.
So again an issue I had and thought I’d share. I found very little about this on Google. The problem I had was, that I got a JSON response from a site that contained an ID I’d need to use on the next page. The challange was that I had a variable in the regex which JMeter doesn’t seem to like. The easiest way to do this is to use JMeter-plugins!!!
Short post, if it were not for the unlucky fact that I couldn’t use the plugins. So here the long answer….
A common problem in JMeter is that you want a CSV file as an input and want to execute each line, then continue. So from a script perspective that would look something like this:
|-For Each CSV Line
| |-HTTP Request (CSV input)
|-Do something else
The issue though is there is no “For Each” concept in JMeter. I know that it is called a ForEach Loop in JMeter but it isn’t from a developer view. You need to know the length of your CSV file. You could just tell the For loop how many lines there are but that would make it very unflexible. You’d need to adjust the script every time the CSV changes.
So here is how I solved it. Not elegant but it actually works quite well.
Just a follow up on the 2015 Kiwi Workshop on Software Testing (Aug 2015). Find my write-up here:
In attendance this year were:
James Bach, Oliver Erlewein, Richard Robinson, Aaron Hodder, Sarah Burgess, Andy Harwood, Adam Howard, Mark Boyt, Chris Priest, Mike Talks, Joshua Raine, Scott Griffiths, John Lockhart, Sean Cresswell, Rachel Carson, Till Neunast, James Hailstone, David Robinson and Katrina Clokie
Posted in Communities, Event, Exploratory Testing
- Tagged communities, event, experience report, James Bach, KWST, Oliver, Roles, Test leaders, Thought leadership
Sorry for the ongoing spam about JMeter stuff but I am writing a LOT of coding at the moment and I thought I’d share some of the knarly stuff I come accross so others might benefit.
So I had the issue that I need to cobble together MIME HTTP/SOAP calls that contain attachments. JMeter has the ability to add files statically to an HTTP Request (Body Data) but if you need more control you need to roll your own. Best way to do this would be to load the file into a variable and just attach like this:
Content-Disposition: attachment; name="MyFile.pdf"
But how do you get it into the variable?
Some projects require authentication features that involve some quite intricate steps. But fret not, in JMeter we can use Groovy to do the heavy lifting. Below is a very simple example of how you can do a HMAC encryption. It also includes the SHA256 hashing and base64 encoding. The only thing missing are the functions to read the variables from JMeter and publish the hash to JMeter but that is trivial and you can fit it into whatever you already have scripted.
String secretKey = "secret";
String data = "Message";
Mac mac = Mac.getInstance("HmacSHA256");
SecretKeySpec secretKeySpec = new SecretKeySpec(secretKey.getBytes(), "HmacSHA256");
byte digest = mac.doFinal(data.getBytes());
encodedData = digest.encodeBase64().toString();
log.info("HMAC SHA256 base64: " + encodedData);
by Oliver Erlewein
A late report from our workshop last year. I stumbled across it again in my preparations for KWST (Kiwi Workshop on Software Testing) 2015. It was supposed to be published through our gracious sponsor, The Association for Software Testing (AST), but it never eventuated. So I thought I’d post it here. Better late than never.
So here goes….
For the fourth year in a row, Wellington (New Zealand) has successfully hosted the Kiwi Workshop on Software Testing. The two-day intensive testing workshop is one of the key drivers of the Context-Driven Testing (CDT) community Down Under.
In its beginnings, the aim was to give the experienced and senior community members a platform to drive innovation and exchange ideas. The impact of KWST in the community over these past years has had far reaching effects in New Zealand as well as Australia.
Workshops, conferences, and magazines have emerged since, which have lifted the game right across the board. KWST 2014 was specifically aimed at involving new faces in the community and not drawing as much on the established KWST crowd.
The topic this year was:
“How to speed up testing? – and why we shouldn’t”