English subtitles

← Apis - Software Testing

Get Embed Code
1 Language

Showing Revision 3 created 05/24/2016 by Udacity Robot.

  1. What we've been doing in this unit is looking at a progression of random testers,
  2. from the simpler ones to the more complicated ones.
  3. And as we've seen, one of the major things creating difficulties for us
  4. is that structure is required in inputs.
  5. What we're going to do now is look at the next level of structured inputs,
  6. and that level of structure is required for random testing of APIs.
  7. So if you remember from our pictures earlier in the course,
  8. we have some software under test, and it's providing an API
  9. or several APIs for other code to use.
  10. And this is the kind of APIs that we're going to focus on testing.
  11. What an API is is basically just a collection of function calls that can be invoked.
  12. And what we're going to find when we test APIs
  13. is that a single random test is not going to be something extremely simple
  14. like a credit card number or a couple of inputs to a single API call
  15. but rather, a single random test is going to constitute a string of API calls.
  16. There are a couple of things that make this situation
  17. more complicated than what we've seen so far.
  18. The first possibility is that there are dependencies among API calls.
  19. What this means is there might be certain orderings of API calls,
  20. perhaps even combined with dependencies on the arguments to those API calls,
  21. that are either illegal or undesirable,
  22. and we're going to need to teach our random tester to avoid those.
  23. So let's just for the moment take the example of randomly testing a file system.
  24. What file systems are are pieces of code that take the raw abstraction
  25. exported by a hard disk driver--so here's the disk itself.
  26. The disk is going to talk to a driver.
  27. The driver is a piece of code running in the operating system
  28. that understands the details of interacting with whatever kind of particular hard drive
  29. we're dealing with, and what it exports is the abstraction of a block array.
  30. A block array just means that from the point of view of the file system,
  31. what the hard disk looks like is an array of blocks
  32. where blocks are numbered 0, 1, 2 all the way up to some very large number
  33. for a modern hard drive.
  34. And so the purpose of the file system is to take this low level interface of a disk block array
  35. and build on top of it a hierarchical namespace--that is to say, a directory structure
  36. provided by file systems in UNIX or Windows--
  37. and then those directories, of course, contain files
  38. and files are just variable sized bags of bits that we can create and delete dynamically.
  39. And so the file system has to manage all of that structure just to manage the free space;
  40. it has to efficiently respond to all sorts of calls that perform file system operations.
  41. And so let's look at what the file system operations are.
  42. The question is, what are the contents of the file system API?
  43. We have things like mount and unmount,
  44. and these are the calls that invoke the file system code in the first place.
  45. So if a file system is not mounted, it's just sitting there on disk.
  46. It's not being used at all.
  47. Once it's mounted, its contents are available to the operating system.
  48. We have calls like make directory.
  49. Mkdir creates a directory, and remove directory deletes one.
  50. Open can be used to create or just open an existing file.
  51. Unlink deletes one. I'm talking about the UNIX style file system interface.
  52. And then there are a bunch more calls.
  53. So if we want to do random testing of a file system,
  54. we're going to be issuing sequences of calls in the file system API.
  55. Before we get into the details, let's just think about
  56. why we might want to do random testing of a file system.
  57. First of all, file systems are fairly long and complicated,
  58. and so I looked at the size of 5 of the file systems commonly used on Linux,
  59. and they're all between 15,000 and about 70,000 lines of code.
  60. File systems end up being substantially large chunks of code,
  61. and what's more, the integrity of our data
  62. depends on the correctness of that file system code.
  63. So for example, if we save some critical data to the disk
  64. and the file system messes it up--that is to say, it saves it in some wrong place
  65. or corrupts it in some other way--then we're not going to get that data back ever.
  66. And so it's really, really important the file systems work well.