Test Expert Q&A----How to Write Good Software Test Cases

1. What should be paid attention to when designing use cases for new products and maintenance releases of old products? Expert analysis: There is no difference between new projects and maintenance projects in essence. Maintenance products are nothing more than two categories of new functions and defect repairs. Compared with new projects, the only thing that needs to be paid attention to is whether the new/repaired functions are suitable for other products. Part of it is influential, and here it involves a regression strategy - how many old functions should be tested. Generally speaking, the scope of impact needs to be determined in discussions with development, and then the scope of testing is developed. Of course, the ideal situation is to fully test the entire system, because once the system is complicated, no development can clearly state the scope of influence. Expert advice: "New products" should first design test cases and then test to avoid omissions when they understand the requirements. "Old product" maintenance, if the requirements are changed, the test cases are still designed (modified) first, and then tested to avoid omissions; if the project is urgent, the test cases can be tested first, and then the test cases can be modified. 2. When making a mobile application, the process is not as clear as that of the WEB. It feels that the application has many small functions in addition to the main function. It is easy to miss when designing use cases. What needs to be done better. Expert analysis: Mobile phone application testing is the most suitable method for applying scenario analysis. Scenario design requires accumulation of experience, not simply learning knowledge. The most suitable method of scene design. Expert advice: mobile phone testing considers various mobile phone brands, models (and in the case of current solar-powered mobile phones), shutdown, power failure, memory capacity, etc. 3. How to achieve high coverage testing with short test cases? And when writing use cases, is it better to use very clear descriptions or to use test point descriptions to let test executors diverge test thinking? Expert analysis: We generally do not consider such considerations. Use cases need to have appropriate granularity. It does not mean that the more a use case covers, the better. If a use case has a large granularity and covers many test points, it seems very OK, but will you still understand this use case in a few days? The number of test cases often greatly exceeds the number of tests. The purpose of use cases is to communicate, so that others can understand your test ideas and help you review them. On the other hand, it is also the accumulation of experience, which will eventually form a use case library, so it must reflect the use case design ideas. Diverging test thinking on your own is unacceptable. After a few years of doing this, there will be no accumulation at all. Over time, it will be eliminated in the testing world. 4. How can black-box testing be refined and done well, and how to carry out relatively complete testing work for some companies that do not pay special attention to testing? Then black box testing has to go towards white box and performance? Expert analysis: The importance of testing can be negotiated with the company. If the company does not agree, try to use more professional testing methods (tools) and bug management, so as to attract the attention and recognition of the company. Testers also have to adapt to this situation. The first is to understand the company's demands for quality. For example, there is no requirement for performance at this stage, so focus on doing a good job in functional testing, and at the same time consider improving the efficiency of testing, such as automated testing. In the requirement confirmation link, try to participate as much as possible, such as writing acceptance criteria for each requirement, and then discuss the requirements with the development, and integrate the testing work into the entire development process, then the importance of testing will be side by side with development. Black-box testing is difficult to master, and much more difficult than white-box testing. White-box testing is the easiest and least technically difficult part of testing. Which one is more valuable should be clear. If you don't have a certain code base, it is not recommended that you do a white box. The most developed test is black box testing. There are many things to learn in black-box testing, such as testing requirements analysis in the requirement link, scenario analysis, use case design method in the design stage, test automation in the implementation stage, DFX testing technology and so on. Performance testing is a very important development channel. In fact, performance testing is also a black box, and performance analysis and optimization are a bit white box. In China, the proportion of functional occupancy is indeed very high, but the entry requirements of most companies now require some performance tools or automation tools. 5. For companies doing embedded development, as a tester, what are the main things you need to learn? Database, can automated testing be used? Expert analysis: For embedded, the database may not be involved, but automation is still important. Embedded software can be regarded as a black box. The biggest difficulty in testing is to build a test environment, because you need to build an input and output environment for this black box. Generally speaking, you must master some basic knowledge, such as the principle of single-chip microcomputer, know the pins of the chip, digital to analog, and some basic assembly. From what I know about embedded software testing, it's the easiest to automate. 6. How long can black-box testing be done, and how should a career in black-box testing be planned? Expert analysis: In terms of black box testing, you are actually well researched, and you are also very good. Like automated testing and performance testing, they sometimes still need some functional testing skills. 7. How to write black box test cases to achieve wide coverage without redundancy? 专家分析：为何会有等价类划分、边界值、判定表等等工程方法？就是为了帮助大家写好用例的。 出现冗余举个最简单的例子：0-100之间取值（整数），可取0、55、100；若再取-1、1、99、101就是冗余。 8、测试用例是否一定要在测试开始之前写？ 每次写测试用例都要严格按照那些测试策略和方法吗？ 专家分析：首先要知道写测试用例的目的是什么？测试每一阶段写的东西都有它的工程目的，放到特定的公司环境中，我们不应该想哪一步可以不做，而是想在这种情况下用哪种做法更有效。比如测试策略，它的主要目的是沟通，它描述了你会怎么去测，这是你用来和开发以及其他相关人沟通的，如果是我，我就会把它简化成一张EXCEL表，罗列测试点和测试方法，后面的测试用例也会集中在这张表上，然后再补全。这种建议对这个项目已经非常了解或者经验比较足在项目紧的情况下这么做。 9、有三年黑盒测试经验，但是没有开发经验，看不懂代码，是否只能一直做黑盒？ 黑盒测试有什么样的发展前景？如果要向白盒，自动化和性能测试发展该如何入手？ 专家分析：看不懂代码可以慢慢学，其实并不难，看你自己是否有这个决心下这个功夫了。黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。作为研发体系的一员，代码功底是必须的，否则没有发展通路。测试和开发同属于研发体系，研发体系的通用语言就是编程语言，就像你到国外工作，其他人都说英语，就你只会说中文，虽然别人也能听懂一二，但是总觉得你是个异类。想要做好测试，不逊色于任何开发人员的代码功底是必要的。 白盒：可以到相关测试论坛查阅资料。 自动化：可以看看风过无息、赵旭斌、陈能技三位牛人的书、博客、视频。群里也可以请教下高手，比如热心肠的超级奶爸等。 性能：可以看看卖烧烤的鱼、云层、于涌两位牛人的书、博客。群里也可以请教下高手，比如热心肠的超级奶爸等。 白盒、自动化、性能都是需要些开发基础的。 10、对于较复杂流程的测试用例如何进行测试用例编写？ 专家分析：复杂的测试流程建议先画个流程图，再根据流程图编写测试用例。