软件测试用例有几种,软件测试用例的详细程度的几种观点

软件测试用例的详细程度的几种观点

发表于：2010-11-01来源：作者：点击数：

标签：

软件 测试用例 的详细程度的几种观点 软件测试 观点1：这个场景额组合设计情况太复杂了，没有必要这么做吧! 答：场景是非常复杂，至少本人下午花了一个多小时才刚刚理清楚开始的头绪，但不能因为复杂，任务量重就不做了，毕竟这是核心业务功能。按道理来讲，

软件

观点1：这个场景额组合设计情况太复杂了，没有必要这么做吧!

答：场景是非常复杂，至少本人下午花了一个多小时才刚刚理清楚开始的头绪，但不能因为复杂，任务量重就不做了，毕竟这是核心业务功能。按道理来讲，其他枝节末梢的功能点在时间进度或资源受限的情况下可以选择放弃，但是这个还真得做。

说明：被测试的软件这次是第二次新版本的发布，在早些时候第一次版本发布之前的测试中没有涉及场景的逻辑覆盖，全凭随机测试和探索性测试，幸运的是，软件合同方进行过

观点2：你不可能将情况组合设计的面面俱到的，就像你不可能发现软件中所有的缺陷一样

答：或许在组合设计的过程中有遗漏存在，那么势必就需要进行组内甚至联合

观点3：对于场景组合设计我不需要设计成表格吧，我只要按照我的思路顺着写测试用例就行了

答：个人推崇表格设计的方法，其实灵感来自于我现在的Leader，一位有7年测试经验的老测试。之前我在一个项目上也采用了当前这位组员的方式，顺着自己的思路写场景用例，后来发现其缺点还是比较多的：第一，其条理没有表格设计方法来得清晰，别人和自己都会看得比较晕;第二，相关用例之间的条件和结果对比没有表格测试法来得清楚，且表格测试法可以通过用例之间各信息的对比，能快速发现遗漏的，没有覆盖到的用例。

观点4：开发其实自己都不是很清楚其中的逻辑流程，让我们测试先理清楚其中的流程覆盖，然后他们去看代码以修复我们其中可能发现到的问题，这好像不是测试要做的事情吧

说明：现有的核心代码并不是当前的开发团队所完成，开发他们核心代码也是在不久前刚刚拿到。

答：开发的意见或许有些让人觉得不爽，OK，那换种说法，总不能要求开发去把代码看完，然后给你画个流程图，告诉你流程图上有哪些路径需要覆盖，如果真的是那样，要测试做什么?并且那样也容易被开发绕进他们的思维流程中去，做测试最忌讳就这个，我们要发现问题，势必要自己挖掘现有测试软件中可能涉及到所有路径，然后一一去验证。其实测试本身和开发是一样的，如果你把主要场景流程捋顺了，那么你相当于走了一遍开发走过的设计道路，如果你再会一门语言，那么差不多你能也模仿着做出相同功能的软件。

观点5：碰到场景中涉及到的有些似问题，又好像不是问题的问题，开发自己都说不管了，我们也就别管了

答：开发可以不用管，但QA不能不管，因为软件最终的

观点6：那你进行组合设计吧，完了我follow你的case执行，如果中间有遗漏，你负责

答：我不想过多的说明责任归谁的问题，其实作为项目Leader，我很清楚自身的责任，即使设计由组员完成，且发生了遗漏，那么显然责任也是我的，且我的责任最大，原因是我没有引导和开展好必要及正确的测试工作方法。我想这是作为一个领导者应该具备的素质。