软件测试_我的总结（二）

什么是测试用例的有效性？

• 测试用例对应的功能已删除，不可操作了
• 执行一条测试用例未发现BUG，实际该处有BUG
• 执行一条测试用例发现了BUG
• 执行一条测试用例未发现BUG，实际该处BUG已修改

如果你执行了一条测试用例，没有发现bug，则其是否有效？
解：有效，可执行的测试用例则有效，并非看测试用例是否有bug。

测试的目的：
验证是否有bug
验证符合用户需求

测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

粒度：指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。

最简单的测试用例是测试的纲要，仅仅指出要测试的内容，
如探索性测试中的测试设计，
仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。

最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，
会指定输入的每项数据，期待的结果及检验的方法， 
具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：
   一个是效率问题，另一个是维护成本问题。
   另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，
   容易限制测试人员的思维。

(2)测试用例写得过于简单，则可能失去了测试周例的意义。
   过于简单的测试用例设计其实并没有进行“设计”，
   只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，
   提醒测试人员测试的主要功能包括哪些而已。
   测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，
   并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

主要考虑可以参考如下内容：
   产品的质量要求 
   项目对用例的要求
   测试时间和资源是否充分

测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？
（如何确保你编写的测试用例的正确性？）
评审分为正式和非正式评审。

同行评审 
用户检查 
项目组评审

（1）测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。
     同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。
     从而体现敏捷的“个体和交互比过程和工具更有价值”，
     要强调测试用例设计者之间的思想碰撞，
     通过讨论、协作来完成测试用例的设计，
     原因很简单，测试用例的目的是尽可能全面地覆盖需求，
     而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。
     因此需要一起设计测试用例。
     
（2）应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，
     从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。
     这里顾客的含义比较广泛，关键在于如何定义测试，
     如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；
     如果测试是被定义为对开发提供帮助和支持，那么顾客就是程序员了。
     
（3）由测试负责人组织协调开展会议，用例编写人对用例进行讲解，
     参会人员有异议的当场提出。