1. excell set interface parameters [excell in using a random number, etc.], and then call the service interface implemented method of inserting
ps: by writing original dead, random, parametric methods to make the payment information, do not recommend this. The following reasons
a. By further aspect behind excell, people will not write the code may operate.
b. If the number of parameters is changed and the field must pass, and have different logical, no data is assembled for each scene change from the code, if added directly to an excell line
2. payment information, and pass over the field need manual inspection assembled into an object, to write a verification method, according to the parameters determined excell pass down inside the specific validation logic. [Do not write a lot of scenes judge sentences an argument to get]
Automation assertion to be considered part of the successes and failures
3.excell scenes which make normal and abnormal data from different scenes to verify
ps: the need for other verification table
Common exceptions to consider, as an exception to determine whether to deal with the actual situation:
1. When the front-end call interface, the interface parameters passed to whether there is empty, write test cases based on the results of the two sides to communicate, you may need to return null or ran out of the front exception if not required do not need treatment, not being given to
2. pass --- less interfaces will pass fields, but also whether the abnormal situation is empty [If a user name and password do not pass will not work]
3. --- interfaces can pass an optional field, do not pass must pass inspection
4. Multi-party call interface transfer --- if some of the information transfer interface processing side does not require treatment, to ensure that no problem
ps: pay system does not pass, but the interface has processed, are considered developed, we can learn from
Interface test ideas:
1. According to a version of the interface documentation own analysis [Business Process + + will consider an exception to be determined whether the need to handle an exception error content is expected +] use cases and use cases for developers / business to check whether the missing, to confirm part
ps: According to the idea of equivalence classes, etc., to the conditions and results classification and the same unified treatment
2. Confirm for an exception if need be [Special treatment + + will pass field validation error level of detail] degree, whether to deal with interface testing and treatment, according to the results of all communication, interface testing is to verify whether the main purpose of the process, cost, time, and test their own decisions. And then improve communication with patients
3. writing tests, the first test [with the main flow of Test Example excell, excell in each row representing a scene, each row in the Parameter column add logic to decide to go, the expected results are set forth for determining]
ps:. a present our company are mostly the main flow, not so fine, you can really see a problem with artificial
Interface - Example: function test abnormalities design scenarios +, starting from the following:
a. primary function is normal
b. logical business (also contain logic dependent business, to make sure before entering landed)
c. Parameter error (1 parameter is not null parameter value 2. 3. multiple keywords / a less stringent parameter will be used in testing the interface 4. The parameters does not exist in the database)
d. Data in abnormal (1. 2. The data is null data value is null 3. The key length is not allowed in the bank 4. _ abnormal data error does not exist)
e. Safety
ps：
Stored value of 0 or 1. Optional memory is empty parameter is null
2. Supplementary interface parameter name to strict and consistent interface documentation, it is case sensitive
Assertion ideas:
1. Increase the test: the call interface pass over the need to insert the results of manual inspection of field assembled into objects, to query the database, found on the success, or failure to prompt data
2. Check check check: Query result into an object database to check whether the same
3. Remove the test: After the call interface to pass over the information assembled into objects or take the key fields to the database query
4. Modify the test: the assembly of the information before the amendment pass over and modified into two objects after the call interface, query twice, assembled modified information into objects before they can check out