home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 5 Edit / 05-Edit.zip / wvwar062.zip / doc / TESTING < prev   
Text File  |  2000-09-03  |  2KB  |  38 lines
  1. how i test
  2.  
  3. 1) every now and then i run the testall.sh script over the incuded doc
  4. files and a few selected trouble makers that ive received.
  5.  
  6. 2) i have a set of supported features documents that display what
  7. mswordview should be able to do, i regularly check these to see if theres
  8. any feature rot.
  9.  
  10. 3) occasionally i repeat the above test while using purify and identify
  11. out of bounds and mem leaks.
  12.  
  13. 4) once a week i run the huge test of (1) over the 300 megs of uploaded
  14. documents that i have received on poor old skynet.csn.ul.ie, many of these
  15. are not word 8 docs as people often upload rtf & word 6/7 & excel docs as
  16. well, but its a good brute force test for crashes, but no good to see if
  17. the conversion makes sense.
  18.  
  19. 5) i scan through the comments tha uploaders make of their files to identify 
  20. trouble docs and visually scan the output, making changes if necessary.
  21.  
  22. some tools
  23.  
  24. i still use laola's lls to help me find errors, its a great piece of kit
  25. to have. i also gives me other ole code to compare against the one thats
  26. included in mswordview, if both of them cant decode a file, then theres 
  27. pretty good evidence that somethings buggered in the ole tables, when word
  28. hangs on them as well, thats probably becomes definite.
  29.  
  30. never having gotten the hang of hexdump i use the little jhex script that
  31. was posted in the linux-gazette at one stage as my hex reader. And theres
  32. nothing like doing a diff on the text output of a hexdump to find what
  33. changes between two versions of the same file, but with a different style
  34. chosen.
  35.  
  36. purify is also the biz for tracking down mem leaks and uninitilized memory
  37. elements.
  38.