比如，新房也属于小区，但是价格是运营平台人工维护的，在测试小区均价 计算的功能时，我们很容易忽略新房的价格是否会发生变动。
常用测试设计方法：
整体把握： 【测试类型分析法】 单个功能点： 【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】 单个界面： 【测试类型分析法】【模块关联】【表间关联】 【等价类边界值分析法】【不同出入口遍历】 单个输入框、选择框等： 【表间关联】【等价类边界值分析法】
测试用例设计说明：
用例设计原则说明： 1、单个功能的用例设计条数需要考虑其重要程度、重要性为高的功能，用例设计就相对完善、 相对丰富些，重要性比较低的功能，用例设计的力度就小一些。 2、Level1级别的用例多考虑正常流，少考虑异常流。 3、单条用例执行的步骤和预期结果的条数要控制，步骤太多的话，容易引起测试遗漏，一般 不要超过3个步骤 4、一个用例只有一个测试点。 测试用例编号格式： 一级模块_二级模块_000N，比如“编码设置_客户编码_0001”。 测试用例标题命名格式： 测试结果_简短的测试步骤
测试类型分析法：
【测试类型分析法】： 即将一个功能点按照不同的测试类型进行划分，针对每一个测试类型都进行测试点设计的 分析方法。 举例说明：
功能测试常规测试点：
性能测试&压力测试&稳定性测试：
思维导图设计格式的原则：
1、整体把握： 使用【测试类型分析法】建立第一级目录。 2、单类型测试点： A、首先以小的功能模块进行分级。 B、小的功能模块里面按照“***执行成功”，“***执行失败”，“***关联性测试”， “异常情况测试”等若干模块。 C、举例：“***执行成功”里面再分“一次执行成功”，“多次执行成功（考虑重复执行 同一记录，不同记录）”。 3、最后一级描述规则： 【测试点】+【简洁扼要的测试步骤】+隔断符号+【预期结果】，如： “校验客户名称长度：点击进入客户信息新增界面，输入客户名称允许输入的最大长度， 其他信息符合规则，点击保存。---对应客户信息能够正常保存，显示正常。” 4、严格控制思维导图横向层级： 为了思维导图转化用例时的方便，横向分级不宜过多。 5、最后一级测试描述颗粒度：一个用例永远只关注一个测试点。比如关注一个输入框的输入内 容的时候，就不考虑长度，不考虑其他单元框对他的影响。
如何多方面考虑测试一个系统：
【用例设计原则】： 1、按照测试类型分析法，按功能，压力，稳定性，性能，安全性，兼容性进行测试类型划 分。 2、针对场景分析法，进行基于流程的功力遍历。 3、针对单个点，进行边界值，等价类相关的测试点的考虑。 4、考虑流程中的异常操作。 5、考虑环境中的可能出现的异常情况，如断开电源，断开网络，网络带宽被占用。 6、考虑其他设备对软件的影响。比如多USB设备。 7、考虑压力的积累，和功能使用的稳定性。 8、考虑性能诉求 9、考虑存储空间即将满，已经满的情况下的数据处理。 10、考虑安装、卸载、升级、重复安装等实际使用场景中遇到的情况。
必填项验证
必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的 字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中 输入数据。 【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字 段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和 功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否 真的必须输入。
如何更有效的设计测试用例
2014.10.16
目录
1 2
测试设计开展流程
如何多方面考虑测试一个系统
3 4
5 5
常用测试设计方法
测试用例更新及维护 漏测分析
测试设计开展流程：
1 2 3
需求文档学习
输出问题确认列表
问题确认与汇总 《需求确认问题汇总》
需求文档评审 制定测试设计计划
开发讲解，测试提问
输出评审结论，归档 启动设计输出思维导图
字段长度测试
功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必 须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止 用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错 误信息更 加的文雅些。 【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字 段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明 书或 其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错， 有问题报bug时建议开发人员根据需要限制长度。
如何多方面考虑测试一个系统：
【存在关联业务的测试点的考虑】： 重点关注在当前业务走通的情况下，对其他相关联页面的影响。主要考虑如下几个方面： 1、当前业务正常走通，其他相关模块是否能正常显示对应数据。 2、当前业务执行过程中出现异常情况，对自身及子他模块数据的影响是否正常。 3、考虑积累作用：长时间，重复操作本模块，是否会对其他模块的数据处理造成影响，相 关模块数据处理是否正常。 4、几个模块共同作用，都发生数据变更，查看彼此间的影响是否正常，数据处理是否正 确。。
测试用例更新及维护：
用例维护的时间： 1、一般在全面用例执行后，进行用例的第一次刷新。 2、每轮执行后，进行缺陷分析后的用例补充及刷新。 3、测试执行完成后，规范化刷人进行用例的刷新的组织，组内人员协助刷新。
漏测分析
定义：
一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发 起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引 入，还是测试遗漏，然后根据分析结果，进行相应改进的一种质量提升活动。
十大负面测试用例
1.特殊字符检测。 2.必填项验证。 3.字段类型测试。 4.字段长度测试。 5.边界值验证。 6.数字的约束测试。 7.日期边界测试。 8.日期的有效性。 9.web会话测试。 10.性能的改变。
特殊字符检测
植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时 会出现问题。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个 或多个单引号的文本。 【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格 （单纯的空格和文本前后的空格）。单引号，逗号，/，<， >（对于web的应用程 序）都是很容易引发错误的。 例： 输入特殊字符~!@#$%^&*()_+|{}:"<>?.,;'[]\=-(注意单引号经常会发现bug) 输入html语言，例： onclick=javascript:.... 输入特殊字符串NULL、null、&nbsp空格的转义字符；<scrīpt></scrīpt>；<br>； 输入javascript命令，例如：test.asp?username=MyName
如何多方面考虑测试一个系统：
【个页面的测试点的考虑】： 基于整个页面： 1、填写区域是否为空的检查： A、只填写一处 B、填写部分、空白部分 C、填写剩一处 D、填写所有。 2、针对单个填写框： A、考虑长度（最长、最短） B、考虑字符（数字、字母、特殊字符、组合） C、考虑全角半角 3、测试点1和测试2的组合。 4、存在关联的不同单元格之间的测试点的考虑： 如拆佣给经纪人的金额不能大于开发商分佣给公司的金额。设计用例时就要考虑验证这 点。 5、考虑不同功能模块的入口，如发布房源，可以从我的Q房首页点击跳转，也可以直接点 击发布房源菜单。不同入口出口的组合要遍历验证。
例：
字段类型测试
功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电 话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类 型的字段以保证 你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特 殊字符，日期型的字段应该允许输入一个正确的日期等等） 【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式 有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要 测试 提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确 识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特 殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理 （和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统 是否正 确的处理。
制定设计任务分配表
评审通过后启动设计 输出测试用例初稿 归档，设计完成
输出修改后思维导图 《测试设计思维导图》 启动测试用例评审
思维导图评审，汇总意见
汇总评审意见，启动更新
汇总形成测试用例
第一次更新完成，再评审
测试设计相关文档：
1、需求确认阶段：
2、需求评审阶段：
需求评审阶段的评审文档由产品经理编写，组织评审，留存评审结论。 3、用例设计阶段：
【补充】边界值的测试同时，最好结合等价类以及一些特殊数字进行开展，如这 里面的负数，虽然账户利息永远不会出现负数，但是如果系统中一旦输入负数， 系统就崩溃，那么这样的系统对于客户来说也是非常危险的。
漏测分析发起人： 由项目测试负责人进行漏测分析。
漏测分析流程： 由项目测试负责人汇总输出当前版本发现问题列表--->由本轮提单人员去上个版本复验---> 填写复验结果--->如果是测试人员漏测，需对应上一轮的测试人员撰写漏测分析报告，如果 是新问题引入，则由对应开发人员撰写问题引入原因报告。--->由QA组织回溯会议，对相关 问题进行回溯，输出会议结论，形成改进意见。--->周知相关领域，相关改进意见的落实。
测试思维导图设计步骤_1：
用例级别定义说明： Level1：最常用操作、测试用例为正向反向的对应用例。 Level2：不太常用操作或者不太常用的比如边界值、冷僻输入的检查、不停点击按钮等类似 的操作的对应用例。 Level3：操作方法比较复杂、测试环境比较生僻，且执行起来有较大难度的对应用例。 一般Level1：Level2：Level3的用例设计比例约为4:5:1，或者4:5.5:0.5 用例执行结果标注说明： Pass：按照测试用例的操作步骤执行，实际执行结果与预期结果一致。 Fail：按照测试用例的操作步骤执行，实际执行结果与预期结果不一致。出现界面显示异常、 处理异常、死机、功能失效等异常情况。 Block：由于测试环境或者其他外部条件的限制，导致用例无法执行。或者用例不适用，需要 更新用例的情况。 Unavailable：软件对应功能未实现，导致对应用例无法执行的情况。 investgest ：不确定测试结果的对错，还需要再确认的情况