编写测试用例(详细).ppt

很明显，如果对第一个参数的值分别取从-99到99的199个数，第二个参数的值分别取从-99到99的第199个数，我们不可能对两位数相加的所有情况进行穷举测试。如果不能进行穷举测试，则面临以下的问题：1.在测试了1+1,1+2,1+(-1)和1+（-2）之后，还是否有必要测试1+3和1+4？2.如果不对加法计算器程序进行穷举测试，能否放心的以为所有参数组合都是正确的？那么这样的话，我们能否找到解决的办法？如何设计编写测试用例(浅析)测试用例的概念测试用例设计原则测试用例的编写方法实例：纸杯的测试用例设计如果没有测试用例测试人员将会如何测试？2017不知道是否较全面的测试了所有功能012018测试的覆盖率无法衡量022019对新版本的重复测试很难实施032020无法对测试质量进行有效评估042021无法形成有效的知识积累052022......06随机测试存在的问题ADBC不是重复的、多余的一组相似测试用例中最有效的既不是太简单，也不是太复杂最有可能抓住错误的测试用例的特征如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，是软件公司探索和追求的目标测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障测试用例的概念测试用例是指为实施测试而向被测试系统提供的输入数据，操作或者各种环境设置以及期望结果的一个特定集合。01其实简单来说，测试用例就是解决要测什么，怎么测和如何衡量的问题。02测试用例的概念举例登录功能，说出一些简单的测试用例简单用例一般的用例举例比较详细的用例举例测试用例对需求覆盖的完整性；01测试用例的有效性；02测试用例的可理解性；03测试用例的清晰性；04测试用例的可维护性。05测试用例设计原则01做到对需求的完全理解,从全局上把握需求02对需求进行归类，包括正常流，异常流等，做到对需求的100%覆盖。(其中有一个好的方法就是用mm图把需求分解了)03把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手多了。需求的覆盖完整性需求的覆盖完整性01测试用例应该包含清晰的输入数据以及预期输出02如果环境或者业务发生变更后，测试数据必须进行更新维护03用例基于数据驱动测试用例的有效性01测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语02测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高测试用例的可理解性测试用例的验证点必须明确清晰重点突出一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。测试用例的清晰性测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性01测试用例需要细化和不断的完善，是个循序渐进的过程02通过测试实践检验测试用例并添加，删除，修改测试用例。03测试用例的可维护性小结RossCollard在UseCaseTesting一文中说:测试用例的前10%到15%可以发现75%到90%的重要缺陷。如果你在项目或日常结束后，仔细的分析过我们的bug列表，那么你会觉得这句话非常适用。合理的提高我们的测试效率就是在编写测试用例的时候进行测试用例优先级的划分。如何划分1.用于冒烟测试的用例为最高优先级2.把基本路径以及各模块主功能的测试标注为高优先级别3.把你所有错误和边界值或确认测试标注为中优先级别4.把可用性测试，兼容性测试等标注为低优先级别5.将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。测试用例编写方法等价类划分如何测试一个两位数加法计算器的程序？测试需求：测试两个参数的值相加后的结果是否正确。其中：1.输入的数值在-99到99之间。2.大于99或小于-99的输入应被拒绝，并显示错误信息。根据测试需求开始测试。分别给第1个参数和第2个参数输入表中的值，然后得到测试结果。如图：测试用例编写方法等价类划分等价类划分法作为一种最为典型的黑盒测试方法，它完全不考虑程序的内部结构，而只是根据程序的要求和说明进行测试用例的设计。如何去做？测试人员要对需求规格说明书中的各项需求，尤其是功能需求进行细致分析，然后把程序的输入域划分程若