I published a pair of relevant blog posts in February 2012 (6-ish months before they filed). The posts walked through adding load testing of a website to a working, sample Continuous Delivery process. It walked through the scripts to perform the load testing, how to use prior runs as baselines, and the actual implementation in a Jenkins build process for a Continuous Delivery pipeline that had been built over 9 prior posts, starting in late 2011.
LessThanDot.com - Implementing WCAT to Load Test a Website
LessThanDot.com - Continuous Delivery - Adding the Load Testing Stage
Also, I found this quote in the definitions interesting from an "awareness of prior art" perspective:
Load and performance tests are rarely included in the tests due to
cost and time constraints since the execution time of performance and
load tests are longer than unit tests and application programming
In my mind, "rarely" means "non-0".
IANAL, but here's my take on the claims:
1.1: The build server/source control defines the distinct builds
1.2: As pointed out in the post, prior builds (codebases) are the baseline to compare against
1.3: The load test scripts outlined in the posts
1.4: Uses a set of numbers for the performance value, including metrics around transactions, requests, and response time
2: see 1.4
3: I don't have an answer for this one. It doesn't make sense that you would simultaneously load test two builds and I don't believe their description assumes simultaneity either.
4: Build server monitoring source control
5: Specifically called out in the first post, see bolded "Tripwire"
6: 2 of these: source control, build history
7: build history and the produced chart/trend
8: not covered because running a build for a prior changeset was so obvious as to not be called out in this post (though it may be in prior ones)
9: build history
10: the first post
11: .1 and .2 are already covered, .3 is source control (unless HP doesn't use source control and instead is trying to reverse engineer how it got into the current state from a saved prior state, ie no source control)
11.4: I don't think I have this. it sounds like they would expect me to calculate a diff value between the two results which is not as useful as a trend of actual values because it limits you to one and only one baseline instead of an ongoing trend - but then they are also running their load testing simultaneously, so outside the magical world of "in theory they won't impact each other", their data is already a mess
12: build history + chart over time
13: build server
14: I did 14.3, generating a performance report
15: the article deploys to a VM and web server instance specifically for the load test prior to running the load tests against it, from a system dedicated for the CD process
I can see where they could claim that claim 3 and 11.4 make this hold water. It is non-obvious (to me at least) that one would run two load tests simultaneously and that you would store the results of each run as a delta from the very first baseline run. Because that seems like a very expensive way to make this whole process not very useful.