more copy stamping :)

More notes on software Testing

no pretty pictures in this post im afraid...im still finishing my Degree in Computer Science.
This post is on Software Testing and is done to aid my exam revision
(from
SW testing : Principles and Practice ,
https://www.pearsonhighered.com/program/Desikan-Software-Testing-Principles-and-Practices/PGM237788.html):

some definitions/acronyms:


SLDC 
Software Development Life Cycle, eg waterfall, Spiral, prototype, RAD, V-Model, Modified V-Model, Agile/ XP.

Waterfall Model Phases:
  Requirements Analysis
  Planning
  Hi level Design
  Lo level Design
  Dev / Coding
  Testing


Chacteristics of the Waterfall Model
Distinct phases
each phase feeds into the next

Advantages of the Waterfall Model
simple

Disadvantages of the Waterfall Model
Sequential, if errors are detected it can be hard to trace their point of origin
potentially large amount of re-work to be done if an error is found in a previous phase
testing is left to the end of the life cycle (not ideal) !

Phases of the V-Model
Overall Business Requirements Analysis
Software Requirements analysis
Hi level design
Lo level Design 

Characteristics of the V-Model
Overall business Req's
UA test design

SW Req's
Sys test design
Hi Level Design
Integration Test design----------
Lo level DesignComponent Test design
Dev / Coding  - Unit test Design

Testing:
Unit testing
Integration testing
Component Testing 
System Testing
User Acceptance Testing  

The process flow is from top to bottom on the left and from bottom to top on the right like the OSI model, or like drawing a 'V' shape

The test design phase is brought over to the left hand side of the model
test design happens earlier and corresponds to the initial development phases of the model, and 
also the test phases of the model.

Planning as a phase (as present in the waterfall model) is omitted as all phases have a degree of planning in them

The V-Model recognizes that different types of testing can be incorporated into the SDLC

Advantages of the V-Model

the tests are designed early - the earlier defects are found the better / cheaper the SDLC
the developers are in a good position to design the tests since they're familiar with the code

Disadvantages of the V-Model

rather than a model tracking the SDLC overall, the modified VModel recognises that various modules and components can be developed at different schedules - they are not sequential like the waterfall Model - and allows the tracking of individual modules but assigning each one entry and exit criteria to mark the start and end of their own VModel progression.    

XP
Extreme Programming / the Agile Model
12 characteristics

1. the customer / client is kept happy with early and frequent deliveries of product iterations
2. changes to requirements re welcomed even late in the life cycle
3. deliveries of updates are frequent
4. there is close daily cooperation between the developers and the client
5. the developers are motivated individuals who can be trusted
6. co-location - face to face communication is possible

7.  working software is the primary measure of progress
8. developers are able to maintain a constant pace
9. continuous attention to technical excellence and good design
10. simplicity
11. best architectures, emerging from self-organising teams
12. regular reflection on how to become more effective and adjust accordingly

Quality: is meeting the requirements of customers consistently and predictably - where customers need not be paying customers - they can be testers or developers depending on the perspective.

Quality Assurance is more of a process oriented paradigm executed during the SE development phases, and has a defect prevention through hi-quality processes philosophy.

Quality Control is more like a post process, it follows more of a defect detection and correction paradigm rather than prevention. Quality Control can be seen as a sub-process of Quality Assurance, and may have its own dedicated team in a SW-dev company.

Requirements Tracability Matrix
As part of Black Box Testing, the RTM (Requirements Tracebility Matrix) maps the requirements to testing tasks through the use of ID codes / numbers. Implicit requirements are mapped to explicit requirements.
 
Testing
Testing is basically a QA and QC process. The aim is to find as many defects as possible before the customer does. Rarely do we find all defects. 

Software needs to be testable.

Defects found sooner in the development cycle are cheaper to fix than those found later,
so the sooner defects are found the better.

Dijkstra's Doctrine:
Program testing can never prove the absence of defects...only their presence.

Principles of Testing
Sometimes, most times, you simply cannot test all possible inputs to your program , so you have to be smart about what you test, or what inputs you pass to your tests. Constructing tests for even simple programs is not trivial.

ie even for a program that accepts combinations of only 6 32-bit integers - you cannot test all possible combinations easily. (6 possible 32-bit ints = (2^32)^6....if each one takes only 1 ns to test, thats still in the billions of years ) your tests must be chosen intelligently with strategies like Equivalence Partitioning and BVA Boundary Value Analysis.

Tests can be prioritized with their ability to find defects, ie Boundary Tests are more likely to uncover defects than testing of random input data.

We don't want tests to be too easy - just like exams...easy exams are not so informative to Academic staff on the students performance.

If defects are not detected in the beginning, they can propagate through the dev process, just like bugs can become resistant to pesticides.

Never assume that the discovery of many defects means there must not be many defects remaining, probably there are many more remaining - as they tend to reside in clusters or convoys.....probably.

Even if lots of code defects are found and corrected - if the requirements have defects, the final product will simply be wrong....(see the Waterfall model)

Likewise if the design is wrong, this will propagate through to the customer as well, so the early stages have the highest consequence of getting it wrong. An error found in the requirements stage will be much cheaper (exponentially) than the cost of a defect found after the software had been deployed.

Costs go up.

Validation can be described as the process of evaluating a system or component  during or at the end of the development process, to determine if satisfies the SRS.

to do:

Verification
Verification vs Validation

Metrics

NaN's (not a number)

I first came across this term I stared blankly into the TD's face feeling lost ..."what's a nairn ? " - thinking of Garlic Nairn bread...

Recently they copped up again whilst I was testing my Bullet coin sim  - sometimes I would re-render a small window around them in the render view / IPR environment and they would dissappear - other times they would stick around.

So i dug up some info: (*to be completed soon.)

FLIP render

I've been doing some FLIP sims for a potential job  in H15 with a goal of recording all parameter changes and sim times in an orderly approach.
one factor I failed to overlook how ever so far was scene size in relation to physical parameters
 
for this look PBR3x3 Render time was 10 mins (milkChocolate Shader with SSS on (0.5))

 








Render Time: approx. 20 mins (Max samples upped to 32)
 

 
 
 
 
 
 
 
 
 
 
Render time: approx. 28 mins (2 levels of reflections and refractions)
 

slap Comp

Machine Specs:
proc: i7 3930k
RAM 32GB
OS Win7

particle Sep 0.01
friction 10
Other values are at the defaults
density 1000
viscosity 500
stick scale 0.1

# particles on this frame approx. 3 Million
# frames : 40
# total sim time for all 40 frames: coming soon

bgeo total disk usage: 2.95 GB
compressed bgeo total disk usage : 1.42 GB

VDB Research

While I've been studying Houdini has evovled somewhat...it is a constant challenge with CG and tech in general to stay up to date. VDB's or 'openVDB' seems to have been born and matured and come into Houdini.

http://www.openvdb.org

online docs
http://www.openvdb.org/documentation/doxygen/

Technical Paper by Ken Museth
http://www.museth.org/Ken/Publications_files/Museth_TOG13.pdf


'VDB' is a open-source hierarchical data structure (and a suite of tools) developed by Dreamworks to handle high quality volumetric rendering (as seen in The Croods, Puss in Boots, How to Train your Dragon 2).

current version (Oct 2015) 3.1.0

Due to the data structure VDB enables constant time O(1) random access to voxels.

VDB allows almost realtime boolean operations

I tried this:
convert from polygons to VDB with "VDB from polygons SOP"
I merged a sphere with a torus, (VDB Combine) then converted back to polygon soup

this work flow allows us to boolean polygons in a new way to the old cookie SOP
which had its own inherent issues, but of course the accuracy of the result is dependent
on voxel resolution. Combining voxels has been previously (a while ago now )
described as a revolutionary way of modeling that was previously restricted by polygon limits.

You can merge different resolution VDB primitives together and the result can be either the lower resolution or the higher.

Houdini's cloud tools make use of VDB data structures.

Python in Houdini - some quick research

python notes

intro to python in H11 (Waqas A.M. Siddiqui)
https://www.youtube.com/watch?v=GubmnSEyKS8

#when should we use python ?...when you cant do it in Houdini with HScript or nodes

# comments prefixed with a hash (#)  can be appended to the end of a line of code)
ie
2+2 # use python like a calculator
will return 4

#baby steps : drag a node into the python interpreter/window
>>> hou.node('/obj/geo1')
(shelf tools and pane TABS can also be dragged into Houdini)

'dotting in'
>>> n = hou.node('/obj/geo1') # assigning to 'n'
>>> n. gives us the operators for n

>>> n will give us the strign representation of the node (type geo and the path)

# assign the object a variable to work with it
>>> n.name() # call its name
'geo1'

# Children at SOP level

# Looping through the children and print the name

# parms
help(n.parm)

# check out the HOM (Houdini Object Model) section of the Houdini help files
ie HOM cookbook and tips and  tricks

# Build a function
wrap up a snipped of code so we can call it on a whim

# note this recursive (the definition of recursion is recursion)
def childrenOfNode(node):
        result = [] # a list in python
        for c in node.children():
          result append (c)
          result += childrenOfNode(c) # this is where the recursion happens - we are calling the very function               # we have defined
return result

# recall indentation is key in python
# saving to a sessional window allows custom functions to be called with the hou.session prefix

# add your code to the shelf as a shelf tool
right click somewhere on the shelf - choose new tool
in the scripting window - add your python code ie

print 'hello world'
hou.ui.displayMessage('hello')

#CTRL-TAB will do your auto-complete for you

# set the pos of a node in a Network editor pane
n = hou.node('/obj/box1')
n.setPosition([.5, .5])

# to see more look in HFS/scripts/python

# adding python into object parameters
ie in HScript - $F/10

in python: (be sure that Houdini knows it is a python expression
and not HScript - Right Click - change expression language to python)
hou.frame()/10

the parm window changes to pink to show the language is not the default language
if the defualt is set to Python then the HScript expression would be in pink

note in parm windows - the hou prefix can be dropped

time() = $T
lvar("PT") = $PT

ie point SOP
lvar("TX") is equivalent to $TX

pwd().curPoint().position() is equivalent to
lvar("PT")

ALT-E gives us a little editor to help write our python
in this context - if there is more than one line the code is treated as a function
(with breaks shown in the parm window)

point = pwd().curPoint()
if point.number() ==0;
      return 2
return point.position()

kwargs - used through-out houdini
describes a bunch of variables associated with the shelf tool
ie whehere or not you have ALT-clicked the tool or SHIFT-clicked the tool etc
whether or not he tool was invoked from the viewport or not

use sys.exit() to exit from a python shelf tool

shelf tools can be bound to Hot Keys - and they can be invisible form the shelves or viewport pane

in a font SOP (as a python expression):
"Frame $F %s" % int(frame())

will give you the frame number evaluated from the python expression

"%02d:%03d, 1f" % (time()/60, time() % 60)

with string parameters - add a keyframe - then change to python to edit it
you cant add a python expression as a string expression until you have a true keyframe

hou.expressionGlobals()['foo'] = foo
now foo can be called from a python expression
so if you have a lib of your own expressions
you can inject them in to expressions

make a timecode HDA's
make it a HDA - Shift-C
from the subnet create a DA
'ch' can be used just as we would in HScript

use CTRL-g to jump to a specific line in a python scripting window

code in an asset is more global - it lives with the asset
python in a shelf tool may only live on a specific desktop and python in a session may only live in that
session

https://www.youtube.com/watch?v=5lVpCmadM-Y



Boolean operators ordered by ascending priority:

Operation	Result	Notes
x or y	if x is false, then y, else x	(1)
x and y	if x is false, then x, else y	(2)
not x	if x is false, then True, else False	(3)

Notes:

1. This is a short-circuit operator, so it only evaluates the second argument if the first one is False.
2. This is a short-circuit operator, so it only evaluates the second argument if the first one is True.
3. not has a lower priority than non-Boolean operators, so not a == b is interpreted as not (a == b), and a == not b is a syntax error.

it has been said that unambiguous code is good, so I imagine writing 'not (a==b)' is preferable to 'not a == b'

inequalities

use of <> is obsolete but backward compatible to the standard !=

2016 procedural modelling