After five years of software testing, I have written some experiences.
1. Is the test really necessary? If necessary, what are the achievements of the test?
Software testing: the code quality is high, it doesn't matter to you, and the code quality is poor, you can't see it. The effect of software testing is a big problem.
Therefore, in many cases, software testing becomes more bureaucratic, exquisite reports, and various charts are rampant. Testing case x testing platform calculates Cartesian product. The test itself is ignored.
I have seen a ksh script write read-p, and read-p is a bash usage, but ksh does not. No one wants to handle this small problem. Come to me, I directly change the script pass.
2. How can software testing crash.
A. if the boss says that release and OK will be required in December, the following people will not find a problem, and there will not be too many defect reports in December, which facilitates developers, it is also convenient for testing to complete the task on time. After all, the boss has the greatest will. Everyone knows that the release will be release by June 1, and the uncompleted defect will automatically enter the next release or be released in the form of a fix pack.
B. The people who design the test cases are the leaders in the test, rather than the people who run the test or need to implement the test. This laid the groundwork for the command and the test case writing.
The Design of test cases makes the leadership feel that these designs are seamless and cover a wide range, involving a large number of stability and high concurrency tests. For example, I have seen a test case. I want to deploy a virtual server and run it 10 times with 10 threads. To ensure that all the 100 tests are successful, this test case has never been successful before. However, when release is reached, this test must pass. As a tester, if your test cases are impractical, your best interest is to pretend to be a test, and then pass the test at the time. this test related to "cloud" is difficult, because deploy should be designed as a transaction type similar to atomic operations or databases, and the test succeeds, if it fails, all rollback is required. A virtual server in deploy itself is a long pipeline.
C. Test Coupling Degree: the code is always loosely coupled, and many people I have seen in the test prefer to use tightly coupled methods. For example, if byproduct of A completes A test case, it can set up an environment for B's test. In this case, B depends on A. If A fails, B cannot do anything. When writing A report, this is: A becomes the blocking issue of B. The leader will ask why A blocks for such A long time and when it will continue, while ignoring that B has not done anything. This tight coupling is actually A in front of the trap.
3. Talking about Human Factors
For example, to test the database:
In this case, java uses JDBC/ODBC to tune the SQL statement, while the database is built and the table is directly executed using bash-c on linux.
Oracle often calls RMAN for database backup, while mysql's mysqldump is sufficient for online and offline backup.
I have access to some software tests. I only run the integration command, and I have built the database and backed up the database. I never thought about how to do this manually. Only you know how to do it manually, you only need to know what has been done in various scripts to better test the code. Understanding the underlying details is the key, just like an iceberg. It is far from enough to understand only 10% of the surface.
4. For technical personnel, blocking issue is generally because your technology is not strong enough.
Of course, this sentence is a bit forced. From the operating system, Linux is nothing more than C and inline assembly, Glibc can use IDA pro reverse, strace can view system calls, Java is the least familiar to me.
Perl, python, php, and various shells are mostly plain text and can be directly viewed by code. (Of course, I don't know what to do if only pyc is used.) from this perspective, there are many things to be mastered in software testing so that all kinds of problems can be solved. In fact, this is not the case. In fact, the human factors are the most uncontrollable. After all, the knowledge of each person cannot span across all aspects and reach a high level at each level.