ET's express test method learning sentiment 20140922

The Courier test, a test method learned from ET, is, as its name implies, data similar to those that are constantly moving through the FedEx system on the planet and constantly flowing through the software. Data is entered into its life cycle, stored in internal variables and data structures, and then frequently manipulated, modified, and used in calculations. Finally, this data is "delivered" as output to the user or destination.
In this test, testers must focus on the data. You should confirm those stored input data and "follow" them around the software. For example, when you enter an address on a shopping site, where does it appear? What features will be used for this address? If it is used for billing addresses, make sure that the feature is tested. If it is used as the shipping address, also make sure that the appropriate features are used in the test. If the address is allowed to be updated, its value should be modified. Will the address be printed, deleted in internal data, or need to be processed further? Try to find every software feature that comes into contact with the data, just as FedEx handles their packages, and testers should be involved at every stage of the data declaration cycle.
While this is a test method, our testing will not only be limited to this one method, but I myself feel that in practice, we often rely on this idea, our tests will be simpler, take the SCM tool to say what I do, we understand the overall business of the tool is as follows:
1. Enter data for the initial session
2, click "Start Initialization" will do some verification, if not passed, it will pop-up hints (we can record those checks, so convenient for each kind of verification to verify)
3, after the validation pass, will first insert a record into the Database task table (we can understand the rules of generating records, and then refine into Test points)
4. After the record is inserted successfully, the distribution service distributes the record as a task to the Web service, the test DB service, the development DB service, and the TFS Service, and records the distribution in the log (we can consider whether the distribution is successful or unsuccessful, and if log checking is also considered)
5, then each service to the task, first in the log to do a successful record, and then start the initialization according to the requirements (we can list the various service initialization of a checklist, as a checkpoint, such as the TFS side first to the given path to get the source code, and then extracted after the TFS to create projects and branches, Then give the project permissions, add people, and finally make the relevant settings, after completion in the log records, and return a state to the database)
6, after the completion of the service initialization, will return a state to the database, and update the database record (we can test the success of the return, return to change that field)

7, the Web interface can see the results, of course, in the middle of the initialization can also see the results;

According to the express idea above, we can quickly obtain most important test points, but also can analyze some design omission or unreasonable place, and the test point of these analysis to record, make checklist or write brain diagram, is a good choice, although said et did not emphasize the test case, But we can combine the idea of ET, there is a test cheklist guidelines, it will be a good choice, which I have always wanted to design the use of the flowchart according to the development of the implementation of the case, it should be a reason, I think this test should be called gray box test it;

ET's express test method learning sentiment 20140922