如何编写好的测试用例（转）

　　专家分析：对于黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。

　　12、在测试资源不足的前提下， 是否可以用粗颗粒度的用例和测试人员跑场景流程过程中的经验来取代大量的用例呢？例如： 用例只有一个，但是跑的过程中利用测试者的观察力与经验，顺带的间接检查其他功能点。

　　专家分析：测试用例是测试工作的核心。测试工作是讲究投入产出比的工作，这也是测试用例设计的指导思想。

　　测试用例有度的概念，正如亚里士多德在《伦理学》中讨论道德为例：道德意味着过与不及之间的状态。面向测试用例，网上流传着这么一句话：“不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试”。

　　如果外部环境参数较多，并且互相矛盾，比如团队新手多，但测试项目对质量要求很高，并且项目周期短时，如何构建测试用例的颗粒度，就更需要测试管理人员的平衡。

　　13、对于产品的测试，每次更新版本的功能都不一样，而每次都要进行旧功能的测试，怕新增加的功能影响到周边的功能，怎样设计用例更加全面呢？

　　专家分析：这是最常见的形式。可以分成新功能测试和老功能回归两块。新功能测试不讲了，你也清楚，老功能回归这块需要一个回归测试，视测试自动化的程度来定，自动化程度低，那就需要制定详细的回归策略，和开发讨论清楚新增、修改功能的影响范围，来定回归测试用例；自动化程度高的，那就直接全面回归就行了。

　　14、什么样的用例才是好的用例呢？

　　专家分析：做好以下三点就是一个好的用例。

　　第一：依据分明

　　众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，做完需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。

　　假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么ok，我们就要写5000以上个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。

　　第二：目的明确

　　用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点时，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只要把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们在以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。

　　第三：便于统计

　　测试用例对整个测试过程的质量控制和评估有很重要的意义。

　　一、可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。

　　二、做用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多。那么你做的用例成功率还有什么意义？

　　你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。

　　三、做缺陷分析。用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候，这几个测试点也有回归，有些可能与缺陷毫无关系的测试点，都被你回归了。

易用性的测试用例在编写上有什么技巧？从网上看过类似的易用性用例，但是感觉这方面的用例写得太笼统，有时大家理解会有不同.针对易用性和界面性的用例，有怎样的区分标准呢？

　　专家分析：易用性用例涉及的测试点通常都未在需求文档中明确定义。但由于其本身与普通的功能/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、用例设计前期可只依靠需求文档和基础设计方法（等价+边界）完成，其他标准用例设计方法则作为评审标准或手段引入，以保证基础用例组的快速开发。

对于用例写作质量如何进行评价、如何进行度量？在做测试执行策略时，对于继承用例的处理是否有好的经验可以借鉴？

　　专家分析：编写用例之前，定义好用例的编写规范。根据用例的要素，裁剪出我们需要的。求同存异，上下一致达到共识。有利于预审、评审时每个参加的人能够很快熟悉用例编写者的格式。

　　测试用例内部评审：

　　当一个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个操作执行后，系统会批量处理一堆线程，如批量删除功能。两种概念都可以作为持续运行操作的选择依据，只是看用例的粒度需要达到什么成程度而已）然后可以开始选择中断手法，常见的中断方式通常为高优先级的进程/线程或致命缺陷的到来。高优先级的进程/线程需要对整个系统功能进行分析，如系统提示框到来（内存资源申请失败），电量不足提示（如果是有限电源的话）。而致命缺陷通常只能从用户使用环境得到（可运用场景法和错误推断法得到），如系统崩溃，系统断电。