专家分析：新项目和维护项目从本质上看没有区别，维护产品，无非就是新增功能和缺陷修复两大类，和新项目相比，唯一需要注意的就是新增\修复的功能是否对其他部分有影响，这里就涉及到一个回归策略的问题——老功能要测多少。一般来说，需要和开发讨论确定受影响的范围，然后制定测试范围。当然最理想的情况就是整个系统全测，因为一旦系统复杂了，没有哪个开发能说清楚影响范围。
专家建议：“新产品”在了解需求的情况下，先设计测试用例，再测试，避免发生遗漏。“老产品”维护，若改变了需求，依然先设计（修改）测试用例，再测试，避免发生遗漏；若项目紧急可先测试，再修改测试用例。
2、做手机应用，流程不像是WEB的那样清楚，感觉应用除了主功能还有很多零碎的小功能。设计用例时容易遗漏。需要怎么样做更好呢。
专家分析：手机应用端测试是最适合应用场景分析方法的，场景设计需要经验的累积，不是简单学习知识就行的，建议使用思维导图，做个有心人，把平时测试的经验都记录下来，形成最适合的场景设计方法。
专家建议：手机测试考虑有各种手机的牌子、型号（还有现在的太阳能手机情况下）、停机、没电、内存容量等等。
3、怎样用简短的测试用例达到高覆盖率的测试？并且写用例时候采用非常清楚的描述好还是采用测试点描述让测试执行人自行发散测试思维？
专家分析：我们一般不做这样的考虑，用例需要有合适的颗粒度，并不是说一条用例覆盖的越多越好，如果一条用例如果颗粒度很大，覆盖了很多测试点，当前看起来很好，但过几天你还看得懂这条用例吗？而往往测试用例数量往往大大超过测试数量。
用例存在的目的，一个是沟通交流，让其他人能看懂你的测试思路，帮你评审，另一方面也是经验的累积，最终形成用例库，所以一定要体现用例设计思路。自行发散测试思维是要不得的，这样几年做下来，一点积累都没有，久而久之在测试界会被淘汰。
4、如何能把黑盒测试做精，做好，对于一些对测试不是特别重视的公司又如何开展较为完善的测试工作？然后黑盒测试必须要向白盒与性能走吗？
专家分析：可以向公司商议有关测试的重要性。若公司不同意，也尽量采用专业些的测试方法（工具）及bug管理等，便于引起公司的重视和认可。测试人员也要适应这种情况。首先就是了解公司对质量的诉求，比如现阶段对性能没什么要求，那就集中于将功能测试做好，同时要考虑提升测试的效率，比如自动化测试。在需求确认环节，尽量参与，比如针对每个需求写验收标准，然后再和开发一起进行需求讨论，把测试工作融入到整个开发过程中，那么测试的重要性就会和开发并列到一起了。
黑盒测试很难精通，比白盒难得多，白盒测试是测试中最简单最没有技术难度的一环。哪个价值大，应该清楚了吧。如果没有一定的代码基础，不建议你去做白盒。测试最有发展的还是黑盒测试。黑盒测试需要学习的东西很多，比如需求环节的测试需求分析，场景分析，设计阶段的用例设计方法，实现阶段的测试自动化，DFX测试技术等等。性能测试是很重要的发展通道，其实性能测试也属于黑盒，性能分析和优化才有点偏白盒。
在国内，功能占用的比例确实很高，但现在大部分公司的入职要求是要会点性能工具或者自动化工具的。
5、针对做嵌入式开发的公司，作为测试人员，主要需要学习哪些内容？数据库，自动化测试是否能用到？
专家分析：嵌入式来说，数据库可能不太会涉及，不过自动化依然很重要。嵌入式软件可以看做一个黑盒，测试最大的难度在于搭建测试环境，因为你要为这个黑盒搭建好输入、输出环境。一般来说，必须掌握最底层的一些知识，像单片机原理啊，认识芯片那些引脚啊，数转模啊，还有一些基本的汇编。从我了解的嵌入式软件测试来看，它是最容易实现自动化测试的。
6、黑盒测试可以做多久，应该怎样规划黑盒测试的职业生涯？
专家分析：黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。
7、怎样写好黑盒测试用例，在不出现冗余的情况下达到覆盖面广？
专家分析：为何会有等价类划分、边界值、判定表等等工程方法？就是为了帮助大家写好用例的。
出现冗余举个最简单的例子：0-100之间取值（整数），可取0、55、100；若再取-1、1、99、101就是冗余。
8、测试用例是否一定要在测试开始之前写？ 每次写测试用例都要严格按照那些测试策略和方法吗？
专家分析：首先要知道写测试用例的目的是什么？测试每一阶段写的东西都有它的工程目的，放到特定的公司环境中，我们不应该想哪一步可以不做，而是想在这种情况下用哪种做法更有效。比如测试策略，它的主要目的是沟通，它描述了你会怎么去测，这是你用来和开发以及其他相关人沟通的，如果是我，我就会把它简化成一张EXCEL表，罗列测试点和测试方法，后面的测试用例也会集中在这张表上，然后再补全。这种建议对这个项目已经非常了解或者经验比较足在项目紧的情况下这么做。
9、有三年黑盒测试经验，但是没有开发经验，看不懂代码，是否只能一直做黑盒？ 黑盒测试有什么样的发展前景？如果要向白盒，自动化和性能测试发展该如何入手？
专家分析：看不懂代码可以慢慢学，其实并不难，看你自己是否有这个决心下这个功夫了。黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。作为研发体系的一员，代码功底是必须的，否则没有发展通路。测试和开发同属于研发体系，研发体系的通用语言就是编程语言，就像你到国外工作，其他人都说英语，就你只会说中文，虽然别人也能听懂一二，但是总觉得你是个异类。想要做好测试，不逊色于任何开发人员的代码功底是必要的。
白盒：可以到相关测试论坛查阅资料。
自动化：可以看看风过无息、赵旭斌、陈能技三位牛人的书、博客、视频。群里也可以请教下高手，比如热心肠的超级奶爸等。
性能：可以看看卖烧烤的鱼、云层、于涌两位牛人的书、博客。群里也可以请教下高手，比如热心肠的超级奶爸等。
白盒、自动化、性能都是需要些开发基础的。
10、对于较复杂流程的测试用例如何进行测试用例编写？
专家分析：复杂的测试流程建议先画个流程图，再根据流程图编写测试用例。
11、黑盒测试有前途吗？
专家分析：对于黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。
12、在测试资源不足的前提下, 是否可以用粗颗粒度的用例和测试人员跑场景流程过程中的经验来取代大量的用例呢？例如: 用例只有一个,但是跑的过程中利用测试者的观察力与经验,顺带的间接检查其他功能点。
专家分析：测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。
测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”。
如果外部环境参数较多，并且互相矛盾，比如团队新手多，但测试项目对质量要求很高，并且项目周期短时，如何构建测试用例的颗粒度，就更需要测试管理人员的平衡。
13、对于产品的测试，每次更新版本的功能都不一样，而每次都要进行旧功能的测试，怕新增加的功能影响到周边的功能，怎样设计用例更加全面呢？
专家分析：这是最常见的形式。可以分成新功能测试和老功能回归两块。新功能测试不讲了，你也清楚，老功能回归这块需要一个回归测试，视测试自动化的程度来定，自动化程度低，那就需要制定详细的回归策略，和开发讨论清楚新增、修改功能的影响范围，来定回归测试用例；自动化程度高的，那就直接全面回归就行了。
14、什么样的用例才是好的用例呢？
专家分析：做好以下三点就是一个好的用例。
第一：依据分明
众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，做完需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。
假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么ok，我们就要写5000以上个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。
第二：目的明确
用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点时，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只要把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们在以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。
第三：便于统计
测试用例对整个测试过程的质量控制和评估有很重要的意义。
一、可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。
二、做用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多。那么你做的用例成功率还有什么意义？
你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。
三、做缺陷分析。用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候，这几个测试点也有回归，有些可能与缺陷毫无关系的测试点，都被你回归了。
15、易用性的测试用例在编写上有什么技巧？从网上看过类似的易用性用例,但是感觉这方面的用例写得太笼统,有时大家理解会有不同.针对易用性和界面性的用例，有怎样的区分标准呢？
专家分析：易用性用例涉及的测试点通常都未在需求文档中明确定义。但由于其本身与普通的功能/UI用例的结构没有明显区别。故较为常见的两种处理方法如下：
A．在设计用例阶段，将此部分用例标记并在用例评审中进行讨论和澄清。确认其用例预计输出后，再将其放入相应的功能/UI用例组中。
B．在测试执行阶段，出现此类用例时，tester与RD争执较小的部分，两个部门单独沟通即可；而当tester与RD无法独立达成共识，申请PM一起评审此部分用例的预期结果，以达成共识。
小结：易用性用例在设计阶段通常不需要额外划分。
16、功能性测试用例，在编写前有明确的测试策略和测试方法，但是在实际编写中每个人写的情况不一样，有的写的细、覆盖全，有的则比较粗。如何解决这类问题呢？
专家分析：此问题主要涉及单个测试团队的测试策略，通常来说，一个测试团队在测试单个项目时，测试策略不会作大幅改动。所以，测试用例的粒度在某一段时间内通常固定为一个范围。
测试用例的粒度取决于多个测试环境因素：测试用例设计水平，执行测试测试技能水平，项目测试周期和资源分布，项目出场标准要求……而作为测试领导者，应根据实际测试的环境，制定合适的测试用例粒度。如，项目周期长且测试资源充足，则尽量将用例粒度细化，以求达到对测试过程活动的充分控制（理想状态，标准跨国型企业使用较多）；项目周期短且测试资源匮乏，则将用例设计中心放在测试检查点引导，以少量测试用例结合自由测试的方式，达到对重要的项目风险点的控制，而降低甚至放弃低优先级测试点的风险控制。
所以，不同公司，不同测试团队，不同测试项目，其用例粒度可能不同，但是，若相同公司，相同测试团队，相同测试项目，用例粒度不同，则可能就需要检讨测试团队的用例设计规则是否合理，各个tester是否清晰了解公司用例设计理念。（一句话，该培训的就培训，该检讨的就检讨改正。如果用例评审后还出现此类问题，多半这个团队的测试主管就该“背背书”了）
17、在编写用例时，组内是否会规定用例编写的顺序，比如先写控件，再写功能，再写接口的。
专家分析：用例设计规范需要先行于实际用例设计。测试的领域中，没有绝对的正确和错误，只有适合与不适合。
18、如何评定用例的优先级？
专家分析：用例的优先级规范都大同小异，把握2个出发点即可：产品的核心和客户的需求。
由于项目产品不同，优先级有一些差异，以下列举一个用例优先级排序，供参考：
A、第1优先级为主功能实现用例和客户特殊要求的功能实现用例
B、第2优先级为子功能实现用例和1~2级交互用例
C、第3优先级为3~N级交互用例和NFT用例组
19、常用的黑盒方法都了解，但是在项目紧的情况下,最常用的也就是等价类和边界值了.毕竟用例设计也是需要时间的，在编写用例方面有哪些技巧和方法呢？
专家分析：不同的企业采用不同的方式来节约用例设计和用例执行的资源，以下几项可酌情参考：
A、建议基础用例库与测试资源库，用例与测试需要的环境均从库中调用后更新，降低用例设计周期和测试环境搭建周期，并在一定程度上保证不同水平的tester能设计出质量差不多的用例组
B、根据用例的实际使用环境，运用多种用例格式设计用例。如，UI用例组使用流程图代替；交互用例组使用判定表代替
C、用例设计前期可只依靠需求文档和基础设计方法（等价+边界）完成，其他标准用例设计方法则作为评审标准或手段引入，以保证基础用例组的快速开发。
（备注：以上内容转自51testing论坛的你问我答，回答者是楠族开心果）
