编写测试用例详细分析.pptVIP

广告图案 广告内容与图案碰水是否会掉色 广告内容与图案是否合法 广告内容与图案是否容易剥落 广告内容与图案是否符合某个名族的禁忌 * 可用性及安全性 可用性 1. 装入液体多久后会漏水 2. 装入热水多久后可以变温，装入冰水多久后可以融化 3. 如果装入的不是液体，像石头，沙子，铁块等 安全性 1. 装入不同液体，是否会有化学反应。比如：可乐，咖啡等饮料 2. 装入热水杯子是不是会变型和异味 3. 可以加入当热水小于多少度(是一个确定值)时，手不能被烫伤。 * 易用性和性能 易用性 1. 不同人群是否能适合杯子的型状，包括握杯的 感觉和喝水的感觉 2. 不同人群是否能接受杯子的广告内容与图案 3. 纸杯杯壁的薄厚，杯深是否可以让消费者接受 性能 1. 杯子在50，80度的水温下可以使用多少次 2. 倒满开水后，放入冰箱冷冻结冰，取出在融化 后杯子是否可以继续使用。 * 你有不明白的地方吗？ * 谢 谢 观 看！ * 很明显，如果对第一个参数的值分别取从-99 到 99 的199个数，第二个参数的值分别取从-99 到 99 的第199个数，我们不可能对两位数相加的所有情况进行穷举测试。如果不能进行穷举测试，则面临以下的问题：1. 在测试了1+1,1+2,1+(-1)和1+（-2）之后，还是否有必要测试1+3和1+4？ 2. 如果不对加法计算器程序进行穷举测试，能否放心的以为所有参数组合都是正确的？那么这样的话，我们能否找到解决的办法？ 如何设计编写测试用例(浅析) 测试用例的概念 测试用例设计原则 测试用例的编写方法 实例： 纸杯的测试用例设计 * 如果没有测试用例测试人员将会如何测试？ * 随机测试存在的问题 不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 无法对测试质量进行有效评估 无法形成有效的知识积累 ...... * 测试用例的特征 最有可能抓住错误的 不是重复的、多余的 一组相似测试用例中最有效的 既不是太简单，也不是太复杂 * 测试用例的概念 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，是软件公司探索和追求的目标 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障 * 测试用例的概念 测试用例是指为实施测试而向被测试系统提供的输入数据，操作或者各种环境设置以及期望结果的一个特定集合。 其实简单来说，测试用例就是解决要测什么，怎么测和如何衡量的问题。 * 举例 登录功能，说出一些简单的测试用例 * 举例 简单用例 一般的用例 * 举例 比较详细的用例 * 测试用例设计原则 测试用例对需求覆盖的完整性； 测试用例的有效性； 测试用例的可理解性； 测试用例的清晰性； 测试用例的可维护性。 * 需求的覆盖完整性 做到对需求的完全理解, 从全局上把握需求 对需求进行归类，包括正常流，异常流等，做到对需求的100%覆盖。(其中有一个好的方法就是用mm图把需求分解了) 把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手多了。 * 需求的覆盖完整性 * 测试用例的有效性 测试用例应该包含清晰的输入数据以及预期输出 如果环境或者业务发生变更后，测试数据必须进行更新维护 用例基于数据驱动 * 测试用例的可理解性 测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语 测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高 * 测试用例的清晰性 测试用例的验证点必须明确清晰重点突出 一个用例进行一个功能点的验证，一个萝卜一个坑。 对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。 测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。 * 测试用例的可维护性 测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性 测试用例需要细化和不断的完善，是个循序渐进的过程 通过测试实践检验测试用例并添加，删除，修改测试用例。 * 小结 Ross Collard在Use Case Testing一文中说:测试用例的前10%到15%可以发现75%到90%的重要缺陷。如果你在项目或日常结束后，仔细的分析过我们的bug列表，那么你会觉得这句话非常适用。合理的提高我们的测试效率就是在编写测试用例的时候进行测试用例优先级的划分。 如何划分 1. 用于冒烟测试的用例为最高优先级 2. 把基本路径以及各模块主功能的测试标注为高优先级别 3. 把你所有错误和边界值或确认测试标注为中优先级别 4. 把可用性测试，兼容性测试等标注为低优先级别 5. 将功能测试用例分为严重和不严