Automated Software Testing (2) -- Automated Testing scripts are software

Outline: 1) features of Ta code;
A. similarities with other programming
B. Different from other programming methods
C, TA applicable scenarios
D. Ta's Practice
2) problems faced by TA development;
A. Easy to use
B. Reuse
C. Valid
D. Easy to maintain
E. Rapid Development (RAD)
3) Ta solution:
A. Loss
B. tailism
C. Data-driven
D. Some specific good practices (detailed solutions)
Ta uses programming methods to ensure software quality and finds some regression issues or even new bugs. Ta will eventually implement what manual QA can do or cannot do in the form of software. Since it is software coding, it must abide by certain coding rules, that is, it should also adopt the general development process and coding rules to be followed by the software industry recognized standards and methods. I think this is a common part of other programming. However, in actual work, at this stage, our group should strengthen these aspects. For example, the TA development process is random and does not strictly analyze, design, code, and test according to requirements, no corresponding documents are formed.
Ta scripts must be able to test the tested software (AUT, application under testing). They must have their own unique advantages over the general software development process. In short, the following aspects can be summarized:
(1) Demand analysis comes from testing case, and the product design depends on a corresponding developed software (this is a general model currently adopted, its biggest drawback is that TA's products only lag behind our actual test phase)
(2) good robustness
(3) fault tolerance, but do not miss errors
As stated in the second point, TA's software should be robust enough, and we should adopt the on error method more, but do not forget to write down every error point at any time, because the bug is likely to be there.
(4) excellent maintainability and upgrade
Many companies' failure stories tell us that high maintenance costs are the Final Cause of Ta failure. The story of Ta cost also tells us that the cost of a TA script can be recovered after it is run for at least 15 times.
If you have to discuss whether or not ta can completely replace manual testing, it makes no sense to discuss whether robots can completely replace workers. The answer is partially replaced. What we can do now is to select the TA implementation direction so that the TA can appear where it can best reflect its value, such as repeated operations and a large amount of data input, real-time performance monitoring and so on.

(To be continued)