专家分析：编写用例之前，定义好用例的编写规范。根据用例的要素，裁剪出我们需要的。求同存异，上下一致达到共识。有利于预审、评审时每个参加的人能够很快熟悉用例编写者的格式。
测试用例内部评审：
当一个QA完成了手头的测试用例之后，可以让相关的开发人员、攥写需求文档的人员和相对senior或者有专业知识背景的测试人员一起对测试用例做一个review，在review过程当中一般会发现测试用例的不足和需要改进的地方。这些用例的不足之处以及需要改进的地方可以从一个侧面反映出用例的质量。具体的衡量标准由管理人员制定（有些时候测试用例的不足是由于需求文档本身的问题造成的，这就不应该算作是测试用例质量的问题）。
外部评审：
如果公司开发的软件比较大的话，一般会有partner或者咨询公司为软件做代理或者实施。这些partner和咨询公司在实施公司新版本软件之前自己一般会做一些测试（他们自己会有自己的测试用例）。公司可以考虑收集这些合作商的测试用例，然后和QA所写用例比较，以作为对测试用例的评价或考核。当然公司也可以反过来做，即把公司的测试用例拿出去让合作伙伴评审（这样做的我看到的不多）。
按客户反馈评审：
当软件发布后，客户使用一段时间一定会发现有问题，或者在设计方面不符合他们的要求。我们可以将客户报告的BUG收集起来加以分析（严重性，BUG类型，复杂程度），并和通过测试用例发现的BUG作个比较，从而评定测试用例的质量。
21、初学者如何写好测试用例？ 各种方法怎么结合使用？ 每种方法适合哪种模块？
专家分析：先了解什么是测试用例
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
再了解如何设计测试用例：
1.等价类划分
(1)划分等价类。
①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
(2)确定测试用例。
①为每一个等价类编号。
②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。
③设计一个测试用例，使其只覆盖一个不合理等价类。
2.边界值分析
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。
(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。
(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。
由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。
(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
3.错误推测
在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。
4.因果图
等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。
5.综合策略
每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。
测试用例设计误区
- 能发现到目前为止没有发现的缺陷的用例是好的用例；首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&AMp&V”的活动，测试需要保证以下两点：“程序做了它应该做的事情”和“程序没有做它不该做的事情”。因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
- 测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个ProjECt，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
- 测试用例设计是一劳永逸的事情；这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。
- 测试用例不应该包含实际的数据；测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software TeST》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。
- 测试用例中不需要明显的验证手段；我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？ 显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
22、新人接触测试通常都是从黑盒测试开始的，那需要做多久的黑盒测试呢？最终是不是都要转向白盒和性能测试？对新人来说，需要尽快掌握的内容是什么？
专家分析：黑盒测试能做多久，我之前解答了。这个技术含量也是有些的。转与不转白盒和性能这个得看你公司和你自己的需要。
需要掌握的技能，对不同起点的人应该有不同的要求。对于无基础的新手来说，我认为应该从以下几个方面进行掌握。
1）兴趣是最好的老师
对于软件测试工作，通常是比较枯燥的，如果没有兴趣很难做到持久。首先需要了解，你是否愿意做软件测试，愿意做白盒测试还是功能的黑盒测试，不要盲目的参与到工作中，否则对于用人单位，对于个人的成长都是浪费。
2)测试人员要学会思考
测试是个技术工作，需要学会主动思考。如果你遇到一个好的测试主管（组长），他会主动的解决你的测试实际技术难点，这是你的幸运。但是测试问题错综复杂，测试主管工作很忙，他没有时间解决你遇到的任何技术问题，需要你自己分析问题的性质，尝试各种解决方法，搜索网络上的文章，最后如果仍然解决不了才向主管求助。
我们反对遇到问题表现得很茫然失措，不要问一些很“弱智”的问题，否则主管认为你解决问题的能力不足，学习能力欠缺，这样对于今后的发展不利。
测试人员如何思考？根据问题的现象思考。问题是属于测试专业知识不足引起的，还是测试用例等测试文档模糊、错误引起的，是个别现象还是测试项目的其他内容都存在的普遍现象。测试要从模拟用户使用的角度展开，因此要从最终用户的角度，分析问题的严重程度。
在询问最终的解决方法前，确保你根据自己的经验尝试了各种解决方法，并且尽量把你发现的问题和猜测，告诉测试主管，证明你已经主动思考了，但是没有找到好的解决方法，或者不能确定方法是否可行。
3）选择适合的测试学习材料
软件测试的技术博大精深，对于初学者该从何入手呢？可以从以下几个方面学习：
第一是公司提供的培训材料。测试新员工到公司后一般都要经过短暂的培训，这是学习的最好的第一手材料。针对性特别强，都是公司今后用到的测试知识的总结，针对性和实用性都很强。如果有不懂得问题，可以随时提出来，因为你是测试新人，不懂要问，任何人都不会对你的能力表示怀疑。
第二是借助测试项目的测试文档学习，包括测试计划、测试用例，测试缺陷数据库，可以先看看以前发现了哪些bug，这些bug是怎么发现的，有什么规律和特征，学习别人怎么写测试缺陷报告。
第三是阅读测试书籍和测试网站和论坛。这些内容很多，建议利用工作之后的时间，根据自己的知识有选择的选择测试书籍，先从基础知识阅读。正式出版的书的内容质量都比较高，而测试网站和论坛的文章良莠不齐，有些只是只言片语，很多还存在错误。因此，需要有一定的鉴别能力，否则会误导，浪费时间。
4）计算机基础知识
计算机基础知识应包括，对计算机硬件的构成，常见外设设备、网络设备、数据库知识的了解。要测试就必须搭建测试环境，要搭建测试环境就必须应对硬件有一定的了解。
5）操作系统使用
首先必须要熟悉当前最流行的操作系统，比如现在使用比较多的是windows xp。起码的操作和快捷键使用，常用工具安装应比较熟练。
6)开发基础和测试基础
测试首先要了解需求和开发人员根据需求制作的技术方案。所以对软件开发的流程、开发常用的方法、架构有一定的了解，对开发中常用的名词应掌握其意思。这同时也有利于与开发人员的沟通，及测试文档的编写。至少专心学习一本讲述软件测试基础知识的书，对测试工作有一个全面和系统的了解，对常用的测试名词，测试方法应掌握。
7）熟练使用word
编写测试用例、测试报告（BUG单）、软件使用手册是测试工程师必不可少的工作，因此wordd常用功能使用必须要熟练，如常用的插入图片、表格绘制等。
8）测试用例
测试用例是测试的根本，良好的测试用例，对测试起到的作用不言而喻。所以对于一个有一定基础的测试新人，应首先学习如何编写合理、有效的测试用例。
9）沟通技巧
学会和团队内部人员的沟通，学会如何与程序员打交道。沟通是人学习和进步的一个捷径。做为一个新人也许会有很多地方不足，如技术上的缺陷，公司业务的不了解，良好的沟通可以尽快的弥补不足。
10）学习能力
主动、自觉、积极是必须的，不要等着别人来教，也不要等着用的时候才去学。不会很正常，谁也不是什么都会，但学不会就不行了，那就只能被淘汰了。
对于有一定计算机专业工作经验的测试新人来说，我觉得最需要的对测试技能方面及时进行掌握：
1）测试用例
测试用例是测试的根本，良好的测试用例，对测试起到的作用不言而喻。所以对于一个有一定基础的测试新人，应首先学习如何编写合理、有效的测试用例。
2）测试方法
测试的方法有很多种，每种方法如何使用，使用的技巧，应做为一个重点去学习，毕竟发现BUG，是测试人员工作中重要的一个环节。
3）测试工具
自动化测试工具、性能测试工具及测试管理工具、配置管理工具、缺陷管理工具的使用，应至少熟悉一种工具的使用。
4）专业测试工具
根据公司需要，学习公司常用的专业工具。很多比较专业的工具，只有从事此行业才会用到，这些工具也是要尽快熟悉和掌握的。
5）业务知识
了解一定的业务知识，这个对测试非常有帮助。
23、怎样做好网站测试？
专家分析：很多人认为网站建设在程序上传那一刻就结束了，其实这个是一个很错误的想法。其实，网站建设在程序上传后，还有一个很重要的环节就是测试网站。不要小看测试环节，这个测试细节要是没到位，网站会存在很多问题，比如图片变形，网站链接错误啊，还有数据错误等等。我就从我个人的角度来谈谈网站测试要注意的事项。
第一， 要做的事情就是看设计要求，虽然，设计师是看设计要求做，但是难免会存在失误，或者理解上的失误。按着设计的要求去测试功能。
第二， 就是看传上去的图片是否变形，如果变形先看图片本身的规格是否是网站要求上传的规格。
第三， 要先熟悉后台，测试每个后台上的内容是否能在前台找到。或者是否出现错误页面。
第四， 我们作为专业的网站设计公司，要想客户没想到的东西，这么做能让网站更美观，更符合网站的整体效果，特别对于网站的色调这块。
第五， 查看是否有404页面，这个虽然不是属于设计范围。但是，多个404页面会让使用网站的人感觉不够友好。
24、刚刚进入测试行业，正处于学习中，对于测试用例设计仍然不得要领，想问一个具体的问题，比如：一个程序具有文件新建，复制，重命名，删除功能。我只能想到一两个测试用例，应该如何设计测试用例呢？
专家分析：假设测试目标程序只有“新建、复制、重命名、删除”4个功能。可以参考以下测试思路：
1. 根据功能特点提取公共测试点：文字框
1).文字框的测试思路大都没有什么变化，根据支持文字类型，在ASCII表中使用等价法选择具有代表意义的字符，如：A，a，特殊符号（特殊符号这部分可能还需要根据系统特色做一些筛选，如Windows系统的文件名对“\”,“*”等9个符号有限制）
2).如果想更深入测试，可考虑本地化测试部分，引入不同编码的字符测试，如Unicode，GB等.
3).最后使用边界值对字符长度设计一些简单的容错用例。
2. 准备好公共的功能测试点用例，则可以开始各个功能的基础功能用例设计。（这部分其实就是你提到的“每一种只能想到一个或者两个测试用例”）。而在需要用到公共用例的部分，将公共用例链接进去。如新建、重命名等涉及文字框的功能都需要导入文字框用例组。（可能不同的文字框对字符的限制不一样，如字符长度或字符类型，所以实际导入的过程中，需要进行简单的筛选）
3. 根据设计好的基础功能用例，选择出可被中断的用例组，设计交互用例组。
可被中断的用例通常满足：
1).用例单个步骤的操作需要系统响应0.5~1s.
2).用例单个步骤的操作可持续运行。（关于持续运行的概念，有两种理解。一是线程被挂起，如新建功能可在申请弹出新建编辑框后，长时间不释放资源退出。二是1个操作执行后，系统会批量处理一堆线程，如批量删除功能。两种概念都可以作为持续运行操作的选择依据，只是看用例的粒度需要达到什么成程度而已）然后可以开始选择中断手法，常见的中断方式通常为高优先级的进程/线程或致命缺陷的到来。高优先级的进程/线程需要对整个系统功能进行分析，如系统提示框到来（内存资源申请失败），电量不足提示（如果是有限电源的话）。而致命缺陷通常只能从用户使用环境得到（可运用场景法和错误推断法得到），如系统崩溃，系统断电。
25、刚刚接触测试，还在培训中，想向前辈们讨点迷津，怎样学好软件测试？现在感觉很糊涂。
专家分析：首先了解什么是软件测试？
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。软件测试的发展，是伴随着软件开发技术的进步，以及软件质量管理观念的形成。软件测试是从软件质量保证过渡而来，软件测试的职位从传统的白盒测试逐渐演变到黑盒测试，从单一的测试岗位发展到众多的测试岗位，如：WEB测试、数据库测试、安全测试、手机测试。
学好软件测试
首先，是重点概念，现在有很多同学说概念或理论自己看书就能解决，主要是没有实际工作经验，其实老师在讲解概念或理论的同时，也在不断灌输软件测试的实质，没有理论上的掌握，你就无法理解一个软件产品怎么测试，为什么这么测试，怎么去考虑测试的方法或策略，软件测试术语是怎么引申来的，其实都在启发你的逻辑思维能力；也在不断的讲授和上机练习中体验软件测试的流程，软件测试的过程，由无形到有形，从无序的知识点到有序的系统的知识体系。
其次，要有统筹兼顾，全盘考虑的思想，做测试工作不是一个孤立、片面的工作，很多同学都曾说过以前的学哥学姐都传授过经验，测试就那么回事，等到了工作单位，每天就那点活，老是机械式的重复，这些都是我们没有看到或没有意识到的，目前的软件开发与软件测试已不再是小作坊式的规模了，它需要大量的人力来协同工作，每个人的工作都是必不可少的一部分，所以需要在全局上把握，从宏观上考虑，这就是软件测试策略的由来，但是具体测试工作还是微观上的，还需要掌握软件测试的各种方法，另外还要站在项目管理的层面上，从时间上、成本上、效率上、人员分工上、测试团队的能力上、风险上等诸多方面来统筹考虑，要做到从事软件测试工作要从宏观到微观、从全面到局部去认识，不能再盲人摸象或者摸石头过河，要从认识论升华到方法论上；
最后，要多上机实践，这个是非常关键的一点，多思考，会思考，找出疑难与不解，要从软件测试实践中总结出测试理论，再用测试理论去指导实践，这是个循环往复的过程，只有当你的认识达到一定的高度，你就深刻理解了什么是软件测试，你才会发现原来软件测试是那么的有意思、那么有动力、那么具有挑战性，以后还有很多未知的迷团需要你去拨开，还有更多的知识需要你去掌握。软件测试技术到目前为止，还是一门新兴学科，还没有形成固定的理论体系，还需要很多人的努力，最终将这门艺术变成一种科学。
26、一份需求文档，里边有很多功能点，就会有更多测试点。那么一般用用例设计方法来设计某一模块，具体操作起来是怎样的流程？那些用例设计方法的对象是功能点还是测试点？
专家分析：用例的根本目的是给测试人员使用，故在设计用例时，若脱离用例本身的使用环境而空空其谈，也就违背了用例设计的根基，直接导致被设计出的仅仅是无效用例而已。
所以，经常被谈到用例粒度、覆盖率等，虽然提及的次数多，但一直没有明确的标准规范。其很大程度就是因为用例本身的使用环境差异较大，若不进行实际情况分析，就无法得到恰当粒度的用例。
比如，针对某一模块，如手机电话本进行用例设计，大致流程如下：
（1）根据电话本需求文档列举所有的功能点。若不能很好掌握功能点划分的粒度，可考虑使用UI结构图代替
（2）分类各个功能点，主要依据为在实际测试中，各个功能点是否可能被其他用例补充。如，后台运行的功能点需单独分割作为被中断用例的前置环境；被动消息功能点则会被作为中断用例的操作步骤；与其他模块存在接口的功能点则会作为其他模块的补充用例….等等
（3）根据单个功能点的复杂程度，考虑是否存在需要提取公共用例。如将各个功能点的编辑框提取出来设计单独的编辑框用例。
（4）使用常规的用例设计方法，通常为等价和边界设计基础用例。若功能点过于复杂，可考虑继续继续分割功能点或使用高级用例设计方法。
（5）完成以上4步后，使用容错和场景法对设计用例的覆盖率进行验证。
（6）最后，根据此功能模块在系统流程图中的位置，设计该模块被其他模块调用的补充用例。（若每个模块都能保证完成以上5个步骤，第6步其实可以省略）
（7）根据设计要求，考虑NFT用例的分布，通常会根据每个功能点单独提取，也可以通过用例优先级控制。（NFT用例分布策略通常取决于公司测试策略，主要适用即可，不需要太纠结于形式）
27、根据用例设计方法来设计一个模块的测试用例，如果该模块最后有300条用例，那么一般设计这些用例需要多长时间？
专家分析：排除设计人员本身技术高低或用例管理工具难易程度等其他因素，就用例本真而言，用例设计时间通常被两个因素影响：
（1）功能复杂程度
（2）用例粒度（也可以简单理解为用例个数）
所以，建议比较合理的是自己先试验一次，然后再通过考虑其他因素影响，评估出贴近实际的时间。
28、在项目紧急，没有需求文档，没有用例评审，又只能独自完成测试的情况下，如何保证测试用例不会漏测呢？
专家分析：严格来说，这个问题只看”测试用例不会遗漏”已经是伪命题。 至今没有哪个公司敢宣称：咱们的测试用例覆盖率100%。
所以，这个问题还是回到了实际环境分析出发，建议先分析以下几点得到大致的测试标准：
（1）客户对产品的质量要求程度。简单可以理解为: 客户使用什么样的方式来验收产品。常见的方式为：3个月试用、1个月客户测试团队复检、1天客户体验…不同的验收的方式在很大程度上决定了产品的预期质量目标。
（2）产品的功能覆盖和2级交互测试，一般被作为满足产品输出的最低质量保证。单黑盒方面来说，这部分可考虑自己设计功能结构图，然后通过1次功能点分类得到。
（3）再补充一个常用的用例设计信息：用例设计的时间通常不会超过测试周期总时长的1/3，用例遗漏的部分，最快速的方式是使用探索测试完成。（当然，测试人员或开发人员的实际使用测试也能为补充测试泄露提供一定程度的帮助）
29、对于一个复杂的java管理系统，功能中主要以增删改查、新增-审批-发布，类似这些重复的功能特性，请问在设计测试用例时，如何保证设计的全面性？
专家分析：（1）先按照流程图或场景法先清理测试点的思路框架。
（2）提取多次被重用的子功能测试点单独设计公共用例组。公共用例组保证为子功能的最大合集，并注意分类方式，方便被提取时，可快速删选。需要注意公共用例组的粒度，可能它不仅仅只是一个小功能，比如编辑框；在某些情况下，也可以考虑将一小段流程整个作为公共用例组，如审批过程。
（3）由于ERP系统完整流程运行一次的时间较长，且可被中断的测试点较多，通常会将交互用例组单独分割出来，然后逐个重新加载到需要模块基础功能测试用例组中。
（4）NFT的部分，可参考交互用例组的处理方式。
（5）最后，留下设计用例整个周期约1/4左右的时间评审和完善用例组。
（6）至于黑盒外的测试用例组，除使用标准的白盒用例设计方法外，在测试数据选择方面，建议考虑以量的方式来补足。毕竟白盒测试的运行速度远远高于黑盒用例。
30、对于一些特殊的项目，比如说时间短，开发文档不齐全，我们是不是非要执着于去编写测试用例？如果写，时间从何而来；如果不写，如何保证测试的全面和保证测试人员测试的情况？
专家分析：除了经常涉及的简化测试用例的方法外，针对极限条件（无需求，无测试用例），提供一些相关信息，供参考：
必要条件：
（1）测试领导者对测试原理有较深刻认识（至少需要达到裁剪测试流程水平）
（2）测试团队具备较高的可控性（至少能理解测试领导者每个测试任务的实际内容，并且能”踏实”的完成执行测试）
（3）测试团队仅限于单个site。（跨Site测试团队合作项目，可考虑每个独立测试团队分派不同的任务）
测试策略：
极限测试条件下，首先需要高度保证测试过程的运行策略的易操作性。
虽然复杂的测试策略的风险更小，但是它需要消耗更多的时间去理清信息和调整。在极限条件下不可能有那么多的时间和资源完成，所以，把握测试的核心，以己之力，牵动整个团队的步伐，达到最终的目标。（这里并不是说决策者不会失误，只是单个决策者比多个决策者的效率更高而已。）
测试执行：
（1）测试任务每日分派，任务来源与测试计划的细化。（至少需要细化到每个人。当然，如果小组长技能水平较高，可考虑细化到小组）
（2）每日周期跟踪各个单位任务执行状态（比较合理的周期可考虑，取决于跟踪单位任务执行消耗的时间为决策者1/2的工作总时间）
（3）每日对当天的bug进行分析，将分析结果转化为测试点分配到各个负责单位。每周进行一次bug分析汇总，修订周测试计划的重点。
（4）每周进行一次测试状态检查，可选择的方式有交叉测试或核心测试人员抽检。
（5）测试决策者每日与RD就bug修改方案沟通的时间不少于总时间的1/4。
（6）至于其他特殊环境或情况，只能说：见招拆招。
（7）第一阶段为复制。适用于测试新手，基本所有的测试人员设计用例都是从这个出发点开始的。
（8）第二阶段为重置。通常在测试人员入行半年以后开始，通过对之前人员设计用例的模仿，加上自己对测试功能的理解，运用简单的测试方法，重新设计属于自己风格的测试用例。
（9）第三阶段为扩展。努力的测试人员在1年后开始进入此阶段，其表现基本与你现在的状态基本一致。此阶段的根本目的是了解和学习更多测试用例设计相关信息和资料，最终掌握它们，周期因为个人的努力程度和机遇，各有不同。列举一些此方面的需要了解和掌握的信息：系统原理、硬件特性、驱动原理、软件设计、市场信息、编码技术、自动化测试技术、自动化工具原理、缺陷管理工具原理….
其实可以用简单一句话概括：所有与测试相关的技术，均需要了解。
（10）第四阶段为大同。当在第三阶段收集的信息数量达到满足自身测试的需求后，可开始通过各种信息直接提炼出新的测试点，对第二阶段测试用例的遗漏点进行补足，进一步提升测试用例的覆盖率。
31、N个输入条件时怎样用正交法设计测试用例？
专家分析：通常，正交表解决问题分为两类：
1. 测试元素满足标准正交表条件，可直接套用。
查正交表具体可以参考http://www.york.ac.uk/depts/maths/tables/orthogonal.htm
2. 当测试元素不满足标准正交表条件时，可先考虑测试元素是否是某个标准正交表的子集。
如，某个功能有4个测试元素（因子），每个测试元素的水平分布如下：A4，B3，C2，D2 。
我们可以直接选择L16（5^4）正交表，将仅有的4个测试元素和水平放入表内，得到16组测试用例。
也可以选择先将某些测试元素的水平先组合再分离的方式来设计。如上述例子使用将A元素的4个水平中的两个组合在一起看做1个水平。然后套用L9(4^3)，得到9组用例后，再将A元素组合的两个水平拆开（包含组合水平的用例有2个），得到4个新的用例，最终得到12个用例组成的新用例组。
32、如果某个项目很大时间很长，写出来的用例都是上千上万的，请问，测试用例用什么样的模板比较好，word还是excel？
专家分析：条件允许的情况下，建议使用专门的用例管理工具。没有条件的情况下，强烈建议使用Excel而非Word。原因很简单，单是数据统计一项，Word已经捉襟见肘。而且一个excel文件可以包含多个表。
33、测试前期，需求和设计发生变化，需要去修改原先的测试用例，这个无可厚非，但问题是如果已经开始测试了，发现自己写的测试用例部分不符合需求与设计、发现可以新增一些测试思路、用例。请问：在这种情况下，我们还要去修改、新增用例？时间从何而来？用必要补充已经测试的用例吗？等项目测试完了，有补充的必要吗？如果项目一个接着一个，时间问题要如何解决？
专家分析：若用例与需求完全不符，需立即修改。若用例存在遗漏，可先只增加基础功能用例，其他类型用例组有时间再增加。（增加用例的原则，可考虑根据用例的实际用途，如，首先保证关键里程碑用例组的完整性）
时间问题，可以说有也可以说没有。举个例子，当一个bug的来源不是用例时，即说明此用例有泄露，报完bug后，将bug的步骤作为用例步骤增加到相应模块。也就只是增加了1,2分钟而已。建议举一反三，时间问题其实关键只在于做与不做。若此部分用例后期不再被使用，则可考虑不补充。若后期仍会复用的用例，建议还是早补早好。
个人认为，项目完了再补不科学,当然项目实在急在不得已的情况下可以后补。但要明白“今天的事明天做”的道理。
（备注：以上内容转自51testing论坛的你问我答，回答者是楠族开心果）
