专家分析：新项目和维护项目从本质上看没有区别，维护产品，无非就是新增功能和缺陷修复两大类，和新项目相比，唯一需要注意的就是新增\修复的功能是否对其他部分有影响，这里就涉及到一个回归策略的问题——老功能要测多少。一般来说，需要和开发讨论确定受影响的范围，然后制定测试范围。当然最理想的情况就是整个系统全测，因为一旦系统复杂了，没有哪个开发能说清楚影响范围。
专家建议：“新产品”在了解需求的情况下，先设计测试用例，再测试，避免发生遗漏。“老产品”维护，若改变了需求，依然先设计（修改）测试用例，再测试，避免发生遗漏；若项目紧急可先测试，再修改测试用例。
2、做手机应用，流程不像是WEB的那样清楚，感觉应用除了主功能还有很多零碎的小功能。设计用例时容易遗漏。需要怎么样做更好呢。
专家分析：手机应用端测试是最适合应用场景分析方法的，场景设计需要经验的累积，不是简单学习知识就行的，建议使用思维导图，做个有心人，把平时测试的经验都记录下来，形成最适合的场景设计方法。
专家建议：手机测试考虑有各种手机的牌子、型号（还有现在的太阳能手机情况下）、停机、没电、内存容量等等。
3、怎样用简短的测试用例达到高覆盖率的测试？并且写用例时候采用非常清楚的描述好还是采用测试点描述让测试执行人自行发散测试思维？
专家分析：我们一般不做这样的考虑，用例需要有合适的颗粒度，并不是说一条用例覆盖的越多越好，如果一条用例如果颗粒度很大，覆盖了很多测试点，当前看起来很好，但过几天你还看得懂这条用例吗？而往往测试用例数量往往大大超过测试数量。
用例存在的目的，一个是沟通交流，让其他人能看懂你的测试思路，帮你评审，另一方面也是经验的累积，最终形成用例库，所以一定要体现用例设计思路。自行发散测试思维是要不得的，这样几年做下来，一点积累都没有，久而久之在测试界会被淘汰。
4、如何能把黑盒测试做精，做好，对于一些对测试不是特别重视的公司又如何开展较为完善的测试工作？然后黑盒测试必须要向白盒与性能走吗？
专家分析：可以向公司商议有关测试的重要性。若公司不同意，也尽量采用专业些的测试方法（工具）及bug管理等，便于引起公司的重视和认可。测试人员也要适应这种情况。首先就是了解公司对质量的诉求，比如现阶段对性能没什么要求，那就集中于将功能测试做好，同时要考虑提升测试的效率，比如自动化测试。在需求确认环节，尽量参与，比如针对每个需求写验收标准，然后再和开发一起进行需求讨论，把测试工作融入到整个开发过程中，那么测试的重要性就会和开发并列到一起了。
黑盒测试很难精通，比白盒难得多，白盒测试是测试中最简单最没有技术难度的一环。哪个价值大，应该清楚了吧。如果没有一定的代码基础，不建议你去做白盒。测试最有发展的还是黑盒测试。黑盒测试需要学习的东西很多，比如需求环节的测试需求分析，场景分析，设计阶段的用例设计方法，实现阶段的测试自动化，DFX测试技术等等。性能测试是很重要的发展通道，其实性能测试也属于黑盒，性能分析和优化才有点偏白盒。
在国内，功能占用的比例确实很高，但现在大部分公司的入职要求是要会点性能工具或者自动化工具的。
5、针对做嵌入式开发的公司，作为测试人员，主要需要学习哪些内容？数据库，自动化测试是否能用到？
专家分析：嵌入式来说，数据库可能不太会涉及，不过自动化依然很重要。嵌入式软件可以看做一个黑盒，测试最大的难度在于搭建测试环境，因为你要为这个黑盒搭建好输入、输出环境。一般来说，必须掌握最底层的一些知识，像单片机原理啊，认识芯片那些引脚啊，数转模啊，还有一些基本的汇编。从我了解的嵌入式软件测试来看，它是最容易实现自动化测试的。
6、黑盒测试可以做多久，应该怎样规划黑盒测试的职业生涯？
专家分析：黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。
7、怎样写好黑盒测试用例，在不出现冗余的情况下达到覆盖面广？
专家分析：为何会有等价类划分、边界值、判定表等等工程方法？就是为了帮助大家写好用例的。
出现冗余举个最简单的例子：0-100之间取值（整数），可取0、55、100；若再取-1、1、99、101就是冗余。
8、测试用例是否一定要在测试开始之前写？ 每次写测试用例都要严格按照那些测试策略和方法吗？
专家分析：首先要知道写测试用例的目的是什么？测试每一阶段写的东西都有它的工程目的，放到特定的公司环境中，我们不应该想哪一步可以不做，而是想在这种情况下用哪种做法更有效。比如测试策略，它的主要目的是沟通，它描述了你会怎么去测，这是你用来和开发以及其他相关人沟通的，如果是我，我就会把它简化成一张EXCEL表，罗列测试点和测试方法，后面的测试用例也会集中在这张表上，然后再补全。这种建议对这个项目已经非常了解或者经验比较足在项目紧的情况下这么做。
9、有三年黑盒测试经验，但是没有开发经验，看不懂代码，是否只能一直做黑盒？ 黑盒测试有什么样的发展前景？如果要向白盒，自动化和性能测试发展该如何入手？
专家分析：看不懂代码可以慢慢学，其实并不难，看你自己是否有这个决心下这个功夫了。黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。作为研发体系的一员，代码功底是必须的，否则没有发展通路。测试和开发同属于研发体系，研发体系的通用语言就是编程语言，就像你到国外工作，其他人都说英语，就你只会说中文，虽然别人也能听懂一二，但是总觉得你是个异类。想要做好测试，不逊色于任何开发人员的代码功底是必要的。
白盒：可以到相关测试论坛查阅资料。
自动化：可以看看风过无息、赵旭斌、陈能技三位牛人的书、博客、视频。群里也可以请教下高手，比如热心肠的超级奶爸等。
性能：可以看看卖烧烤的鱼、云层、于涌两位牛人的书、博客。群里也可以请教下高手，比如热心肠的超级奶爸等。
白盒、自动化、性能都是需要些开发基础的。
10、对于较复杂流程的测试用例如何进行测试用例编写？
专家分析：复杂的测试流程建议先画个流程图，再根据流程图编写测试用例。
专家分析：对于黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。
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、用例设计前期可只依靠需求文档和基础设计方法（等价+边界）完成，其他标准用例设计方法则作为评审标准或手段引入，以保证基础用例组的快速开发。
20、对于用例写作质量如何进行评价、如何进行度量？在做测试执行策略时，对于继承用例的处理是否有好的经验可以借鉴？
专家分析：编写用例之前，定义好用例的编写规范。根据用例的要素，裁剪出我们需要的。求同存异，上下一致达到共识。有利于预审、评审时每个参加的人能够很快熟悉用例编写者的格式。
测试用例内部评审：
当一个QA完成了手头的测试用例之后，可以让相关的开发人员、攥写需求文档的人员和相对senior或者有专业知识背景的测试人员一起对测试用例做一个review，在review过程当中一般会发现测试用例的不足和需要改进的地方。这些用例的不足之处以及需要改进的地方可以从一个侧面反映出用例的质量。具体的衡量标准由管理人员制定（有些时候测试用例的不足是由于需求文档本身的问题造成的，这就不应该算作是测试用例质量的问题）。
外部评审：
如果公司开发的软件比较大的话，一般会有partner或者咨询公司为软件做代理或者实施。这些partner和咨询公司在实施公司新版本软件之前自己一般会做一些测试（他们自己会有自己的测试用例）。公司可以考虑收集这些合作商的测试用例，然后和QA所写用例比较，以作为对测试用例的评价或考核。当然公司也可以反过来做，即把公司的测试用例拿出去让合作伙伴评审（这样做的我看到的不多）。
按客户反馈评审：
当软件发布后，客户使用一段时间一定会发现有问题，或者在设计方面不符合他们的要求。我们可以将客户报告的BUG收集起来加以分析（严重性，BUG类型，复杂程度），并和通过测试用例发现的BUG作个比较，从而评定测试用例的质量。
21、怎样做好网站测试？
专家分析：很多人认为网站建设在程序上传那一刻就结束了，其实这个是一个很错误的想法。其实，网站建设在程序上传后，还有一个很重要的环节就是测试网站。不要小看测试环节，这个测试细节要是没到位，网站会存在很多问题，比如图片变形，网站链接错误啊，还有数据错误等等。我就从我个人的角度来谈谈网站测试要注意的事项。
第一， 要做的事情就是看设计要求，虽然，设计师是看设计要求做，但是难免会存在失误，或者理解上的失误。按着设计的要求去测试功能。
第二， 就是看传上去的图片是否变形，如果变形先看图片本身的规格是否是网站要求上传的规格。
第三， 要先熟悉后台，测试每个后台上的内容是否能在前台找到。或者是否出现错误页面。
第四， 我们作为专业的网站设计公司，要想客户没想到的东西，这么做能让网站更美观，更符合网站的整体效果，特别对于网站的色调这块。
第五， 查看是否有404页面，这个虽然不是属于设计范围。但是，多个404页面会让使用网站的人感觉不够友好。
22、刚刚进入测试行业，正处于学习中，对于测试用例设计仍然不得要领，想问一个具体的问题，比如：一个程序具有文件新建，复制，重命名，删除功能。我只能想到一两个测试用例，应该如何设计测试用例呢？
专家分析：假设测试目标程序只有“新建、复制、重命名、删除”4个功能。可以参考以下测试思路：
1）根据功能特点提取公共测试点：文字框
（1）文字框的测试思路大都没有什么变化，根据支持文字类型，在ASCII表中使用等价法选择具有代表意义的字符，如：A，a，特殊符号（特殊符号这部分可能还需要根据系统特色做一些筛选，如Windows系统的文件名对“\”，“*”等9个符号有限制）
（2）如果想更深入测试，可考虑本地化测试部分，引入不同编码的字符测试，如Unicode，GB等.
（3）最后使用边界值对字符长度设计一些简单的容错用例。
2）准备好公共的功能测试点用例，则可以开始各个功能的基础功能用例设计。（这部分其实就是你提到的“每一种只能想到一个或者两个测试用例”）。而在需要用到公共用例的部分，将公共用例链接进去。如新建、重命名等涉及文字框的功能都需要导入文字框用例组。（可能不同的文字框对字符的限制不一样，如字符长度或字符类型，所以实际导入的过程中，需要进行简单的筛选）
3）根据设计好的基础功能用例，选择出可被中断的用例组，设计交互用例组。
可被中断的用例通常满足：
（1）用例单个步骤的操作需要系统响应0.5~1s.
（2）用例单个步骤的操作可持续运行。（关于持续运行的概念，有两种理解。一是线程被挂起，如新建功能可在申请弹出新建编辑框后，长时间不释放资源退出。二是1个操作执行后，系统会批量处理一堆线程，如批量删除功能。两种概念都可以作为持续运行操作的选择依据，只是看用例的粒度需要达到什么成程度而已）然后可以开始选择中断手法，常见的中断方式通常为高优先级的进程/线程或致命缺陷的到来。高优先级的进程/线程需要对整个系统功能进行分析，如系统提示框到来（内存资源申请失败），电量不足提示（如果是有限电源的话）。而致命缺陷通常只能从用户使用环境得到（可运用场景法和错误推断法得到），如系统崩溃，系统断电。
---------------------------------------
23、刚刚接触测试，还在培训中，想向前辈们讨点迷津，怎样学好软件测试？现在感觉很糊涂。
专家分析：首先了解什么是软件测试？
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度（correctness） 、完全度（completeness）和质量（quality）的软件过程；是SQA（software quality assurance）的重要子域。软件测试的发展，是伴随着软件开发技术的进步，以及软件质量管理观念的形成。软件测试是从软件质量保证过渡而来，软件测试的职位从传统的白盒测试逐渐演变到黑盒测试，从单一的测试岗位发展到众多的测试岗位，如：WEB测试、数据库测试、安全测试、手机测试。
学好软件测试
首先，是重点概念，现在有很多同学说概念或理论自己看书就能解决，主要是没有实际工作经验，其实老师在讲解概念或理论的同时，也在不断灌输软件测试的实质，没有理论上的掌握，你就无法理解一个软件产品怎么测试，为什么这么测试，怎么去考虑测试的方法或策略，软件测试术语是怎么引申来的，其实都在启发你的逻辑思维能力；也在不断的讲授和上机练习中体验软件测试的流程，软件测试的过程，由无形到有形，从无序的知识点到有序的系统的知识体系。
其次，要有统筹兼顾，全盘考虑的思想，做测试工作不是一个孤立、片面的工作，很多同学都曾说过以前的学哥学姐都传授过经验，测试就那么回事，等到了工作单位，每天就那点活，老是机械式的重复，这些都是我们没有看到或没有意识到的，目前的软件开发与软件测试已不再是小作坊式的规模了，它需要大量的人力来协同工作，每个人的工作都是必不可少的一部分，所以需要在全局上把握，从宏观上考虑，这就是软件测试策略的由来，但是具体测试工作还是微观上的，还需要掌握软件测试的各种方法，另外还要站在项目管理的层面上，从时间上、成本上、效率上、人员分工上、测试团队的能力上、风险上等诸多方面来统筹考虑，要做到从事软件测试工作要从宏观到微观、从全面到局部去认识，不能再盲人摸象或者摸石头过河，要从认识论升华到方法论上；
最后，要多上机实践，这个是非常关键的一点，多思考，会思考，找出疑难与不解，要从软件测试实践中总结出测试理论，再用测试理论去指导实践，这是个循环往复的过程，只有当你的认识达到一定的高度，你就深刻理解了什么是软件测试，你才会发现原来软件测试是那么的有意思、那么有动力、那么具有挑战性，以后还有很多未知的迷团需要你去拨开，还有更多的知识需要你去掌握。软件测试技术到目前为止，还是一门新兴学科，还没有形成固定的理论体系，还需要很多人的努力，最终将这门艺术变成一种科学。
24、一份需求文档，里边有很多功能点，就会有更多测试点。那么一般用用例设计方法来设计某一模块，具体操作起来是怎样的流程？那些用例设计方法的对象是功能点还是测试点？
专家分析：用例的根本目的是给测试人员使用，故在设计用例时，若脱离用例本身的使用环境而空空其谈，也就违背了用例设计的根基，直接导致被设计出的仅仅是无效用例而已。
所以，经常被谈到用例粒度、覆盖率等，虽然提及的次数多，但一直没有明确的标准规范。其很大程度就是因为用例本身的使用环境差异较大，若不进行实际情况分析，就无法得到恰当粒度的用例。
比如，针对某一模块，如手机电话本进行用例设计，大致流程如下：
（1）根据电话本需求文档列举所有的功能点。若不能很好掌握功能点划分的粒度，可考虑使用UI结构图代替
（2）分类各个功能点，主要依据为在实际测试中，各个功能点是否可能被其他用例补充。如，后台运行的功能点需单独分割作为被中断用例的前置环境；被动消息功能点则会被作为中断用例的操作步骤；与其他模块存在接口的功能点则会作为其他模块的补充用例….等等
（3）根据单个功能点的复杂程度，考虑是否存在需要提取公共用例。如将各个功能点的编辑框提取出来设计单独的编辑框用例。
（4）使用常规的用例设计方法，通常为等价和边界设计基础用例。若功能点过于复杂，可考虑继续继续分割功能点或使用高级用例设计方法。
（5）完成以上4步后，使用容错和场景法对设计用例的覆盖率进行验证。
（6）最后，根据此功能模块在系统流程图中的位置，设计该模块被其他模块调用的补充用例。（若每个模块都能保证完成以上5个步骤，第6步其实可以省略）
（7）根据设计要求，考虑NFT用例的分布，通常会根据每个功能点单独提取，也可以通过用例优先级控制。（NFT用例分布策略通常取决于公司测试策略，主要适用即可，不需要太纠结于形式）
25、根据用例设计方法来设计一个模块的测试用例，如果该模块最后有300条用例，那么一般设计这些用例需要多长时间？
专家分析：排除设计人员本身技术高低或用例管理工具难易程度等其他因素，就用例本真而言，用例设计时间通常被两个因素影响：
（1）功能复杂程度
（2）用例粒度（也可以简单理解为用例个数）
所以，建议比较合理的是自己先试验一次，然后再通过考虑其他因素影响，评估出贴近实际的时间。
26、在项目紧急，没有需求文档，没有用例评审，又只能独自完成测试的情况下，如何保证测试用例不会漏测呢？
专家分析：严格来说，这个问题只看”测试用例不会遗漏”已经是伪命题。 至今没有哪个公司敢宣称：咱们的测试用例覆盖率100%。
所以，这个问题还是回到了实际环境分析出发，建议先分析以下几点得到大致的测试标准：
（1）客户对产品的质量要求程度。简单可以理解为： 客户使用什么样的方式来验收产品。常见的方式为：3个月试用、1个月客户测试团队复检、1天客户体验…不同的验收的方式在很大程度上决定了产品的预期质量目标。
（2）产品的功能覆盖和2级交互测试，一般被作为满足产品输出的最低质量保证。单黑盒方面来说，这部分可考虑自己设计功能结构图，然后通过1次功能点分类得到。
（3）再补充一个常用的用例设计信息：用例设计的时间通常不会超过测试周期总时长的1/3，用例遗漏的部分，最快速的方式是使用探索测试完成。（当然，测试人员或开发人员的实际使用测试也能为补充测试泄露提供一定程度的帮助）
27、对于一个复杂的java管理系统，功能中主要以增删改查、新增-审批-发布，类似这些重复的功能特性，请问在设计测试用例时，如何保证设计的全面性？
专家分析：（1）先按照流程图或场景法先清理测试点的思路框架。
（2）提取多次被重用的子功能测试点单独设计公共用例组。公共用例组保证为子功能的最大合集，并注意分类方式，方便被提取时，可快速删选。需要注意公共用例组的粒度，可能它不仅仅只是一个小功能，比如编辑框；在某些情况下，也可以考虑将一小段流程整个作为公共用例组，如审批过程。
（3）由于ERP系统完整流程运行一次的时间较长，且可被中断的测试点较多，通常会将交互用例组单独分割出来，然后逐个重新加载到需要模块基础功能测试用例组中。
（4）NFT的部分，可参考交互用例组的处理方式。
（5）最后，留下设计用例整个周期约1/4左右的时间评审和完善用例组。
（6）至于黑盒外的测试用例组，除使用标准的白盒用例设计方法外，在测试数据选择方面，建议考虑以量的方式来补足。毕竟白盒测试的运行速度远远高于黑盒用例。
28、对于一些特殊的项目，比如说时间短，开发文档不齐全，我们是不是非要执着于去编写测试用例？如果写，时间从何而来；如果不写，如何保证测试的全面和保证测试人员测试的情况？
专家分析：除了经常涉及的简化测试用例的方法外，针对极限条件（无需求，无测试用例），提供一些相关信息，供参考：
必要条件：
（1）测试领导者对测试原理有较深刻认识（至少需要达到裁剪测试流程水平）
（2）测试团队具备较高的可控性（至少能理解测试领导者每个测试任务的实际内容，并且能”踏实”的完成执行测试）
（3）测试团队仅限于单个site。（跨Site测试团队合作项目，可考虑每个独立测试团队分派不同的任务）
测试策略：
极限测试条件下，首先需要高度保证测试过程的运行策略的易操作性。
虽然复杂的测试策略的风险更小，但是它需要消耗更多的时间去理清信息和调整。在极限条件下不可能有那么多的时间和资源完成，所以，把握测试的核心，以己之力，牵动整个团队的步伐，达到最终的目标。（这里并不是说决策者不会失误，只是单个决策者比多个决策者的效率更高而已。）
测试执行：
（1）测试任务每日分派，任务来源与测试计划的细化。（至少需要细化到每个人。当然，如果小组长技能水平较高，可考虑细化到小组）
（2）每日周期跟踪各个单位任务执行状态（比较合理的周期可考虑，取决于跟踪单位任务执行消耗的时间为决策者1/2的工作总时间）
（3）每日对当天的bug进行分析，将分析结果转化为测试点分配到各个负责单位。每周进行一次bug分析汇总，修订周测试计划的重点。
（4）每周进行一次测试状态检查，可选择的方式有交叉测试或核心测试人员抽检。
（5）测试决策者每日与RD就bug修改方案沟通的时间不少于总时间的1/4。
（6）至于其他特殊环境或情况，只能说：见招拆招。
（7）第一阶段为复制。适用于测试新手，基本所有的测试人员设计用例都是从这个出发点开始的。
（8）第二阶段为重置。通常在测试人员入行半年以后开始，通过对之前人员设计用例的模仿，加上自己对测试功能的理解，运用简单的测试方法，重新设计属于自己风格的测试用例。
（9）第三阶段为扩展。努力的测试人员在1年后开始进入此阶段，其表现基本与你现在的状态基本一致。此阶段的根本目的是了解和学习更多测试用例设计相关信息和资料，最终掌握它们，周期因为个人的努力程度和机遇，各有不同。列举一些此方面的需要了解和掌握的信息：系统原理、硬件特性、驱动原理、软件设计、市场信息、编码技术、自动化测试技术、自动化工具原理、缺陷管理工具原理….
其实可以用简单一句话概括：所有与测试相关的技术，均需要了解。
（10）第四阶段为大同。当在第三阶段收集的信息数量达到满足自身测试的需求后，可开始通过各种信息直接提炼出新的测试点，对第二阶段测试用例的遗漏点进行补足，进一步提升测试用例的覆盖率。
29、N个输入条件时怎样用正交法设计测试用例？
专家分析：通常，正交表解决问题分为两类：
1）测试元素满足标准正交表条件，可直接套用。
2）当测试元素不满足标准正交表条件时，可先考虑测试元素是否是某个标准正交表的子集。
如，某个功能有4个测试元素（因子），每个测试元素的水平分布如下：A4，B3，C2，D2 。
我们可以直接选择L16（5^4）正交表，将仅有的4个测试元素和水平放入表内，得到16组测试用例。
也可以选择先将某些测试元素的水平先组合再分离的方式来设计。如上述例子使用将A元素的4个水平中的两个组合在一起看做1个水平。然后套用L9（4^3），得到9组用例后，再将A元素组合的两个水平拆开（包含组合水平的用例有2个），得到4个新的用例，最终得到12个用例组成的新用例组。
30、如果某个项目很大时间很长，写出来的用例都是上千上万的，请问，测试用例用什么样的模板比较好，word还是excel？
专家分析：条件允许的情况下，建议使用专门的用例管理工具。没有条件的情况下，强烈建议使用Excel而非Word。原因很简单，单是数据统计一项，Word已经捉襟见肘。而且一个excel文件可以包含多个表。
31、测试前期，需求和设计发生变化，需要去修改原先的测试用例，这个无可厚非，但问题是如果已经开始测试了，发现自己写的测试用例部分不符合需求与设计、发现可以新增一些测试思路、用例。请问：在这种情况下，我们还要去修改、新增用例？时间从何而来？用必要补充已经测试的用例吗？等项目测试完了，有补充的必要吗？如果项目一个接着一个，时间问题要如何解决？
专家分析：若用例与需求完全不符，需立即修改。若用例存在遗漏，可先只增加基础功能用例，其他类型用例组有时间再增加。（增加用例的原则，可考虑根据用例的实际用途，如，首先保证关键里程碑用例组的完整性）
9930
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
