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、用例设计前期可只依靠需求文档和基础设计方法（等价+边界）完成，其他标准用例设计方法则作为评审标准或手段引入，以保证基础用例组的快速开发。