测试工作流程图
一个项目的整个测试流程
⼀个项⽬的整个测试流程最近⼀直在进⾏接⼝⾃动化的测试⼯作，同时对于⼀个项⽬的整个测试流程进⾏了梳理，希望能对你有⽤~~~需求分析：整体流程图：需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind分析流程：1. 需求提取：分析依据（包括：需求矩阵、产品交互图、需求说明书）获取需求的纬度客户价值可以为客户带来哪些价值？可以解决哪些问题？根据以上问题定位功能是否合理UI功能 - 展⽰功能模块关联-历史模块新功能模块关联考虑是否关联？耦合部分是否需要⽀持？客户使⽤场景-部署⽅式⽹络特性客户使⽤服务器常见外设性能参数-性能要求⽹卡最低速率硬件⽀持输出（提取最原始的测试需求）2. 需求分析：分析依据（五维分析）⽤户场景1. 功能是否和场景强关联2. ⽹络拓扑能否满⾜客户需求3. 和竞争对⼿⽐较差异4. 功能是否能满⾜客户实际应⽤场景5. 是否考虑了⽤户的实际操作明确性1. 范围明确性（参数、类型长度范围）2. 清晰性限制等范畴3. ⽆法预知影响的需求提出进⾏确定，风险⼆义性1. 概念模糊【⼤概念、第三⽅⽀持、与上个版本相同】2. ⽀持与不⽀持等范畴3. ⼀个需求描述能出现多种理解完整性1. 需求⼀致性【⽤户需求、需求规格、需求矩阵三者是否同意】2. 需求完整【隐形需求】3. 关联性【与新⽼功能、与外置软件设备】可测试性1. 实现测试需要的⼯具、⽅法【调试、接⼝命令】2. 定位⽅式【⽇志等形式观察】3. 复杂环境、容量边界、操作时过程不可见输出1. 测试需求跟踪2. 缺陷预防bug3. ⼯具需求4. 整理出明确的需求点5. 测试地图分析思路误区：需求和实现的区别【现有需求才有代码实现，不能把代码实现当作需求】需求分析的意义1. 明确产品给客户带来的价值2. 明确产品⽀持和不⽀持的功能3. 明确产品各个功能的约束性4. 知道开发实现功能5. 知道测试分析和产出测试点测试设计：测试分析：1. 我们需要做什么？1. 把明确的需求点转换成测试项2. 缺陷预防2. 怎么做？1. 整体模块分析2. 逻辑分析【这⼀点主要是从产品实现的原理上去分析可能的影响】怎么做？开发的设计⽂档补充和挖掘测试点1. 全部服务的异常监控、服务重启2. 各类存储对空间的占⽤、占满、是否需要做存储的接⼝测试3. 所有类型的管理员、操作权限测试、⽀持的多少管理员并发操作4. 对流程图的挖掘 -- 流程图全部流程测试、流程图重要的节点异常测试5. 对状态的挖掘 -- 所有状态的相互转化需要覆盖全、状态转化是否合理、每⼀个状态下哪些操作可做哪些不可做，多个状态是否可以共存6. 对关联项的挖掘 -- 流程进展到哪⼀步关机重启/服务重启、和备份配置的关联，和操作⽇志的关联等等7. 任务的并发操作测试、是否可配置、是否会出现性能不⾜，是否符合⽤户场景8. 异常处理机制测试，异常处理机制是否完善9. 指标测试，开发的指标设计是否合理修正不合理的需求如何分析逻辑原理：1. 该模块是否涉及到⼀些全新的概念(⽐如我们的 bbc 全量包)，需要明确?2. 该模块包括哪些服务?3. 该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占⽤⼤⼩如何?4. 该模块的操作流程有哪些?是否有⼦流程图?5. 该模块是否有多个状态的转化?是否有明确的状态转化图?6. 该模块对多个管理员是否区分，管理员权限如何设计?7. 该模块是否有⼀些特殊的操作限制?操作限制是否有明确的表格?8. 该模块的任务是否有并发需求?并发的设计?9. 该模块的所有指标如何?10. 该模块是否有异常处理机制?在设备各种异常时，该模块的设计是否满⾜能稳健运⾏?场景分析1. 从⽤户的使⽤习惯和使⽤⽅法去分析影响2. 检查当前案例是否覆盖到⽤户场景关联测试分析：1. 考虑你的模块所在整个系统的地位，分析上下游的影响2. 对⽼功能的影响经验补充分析1. 版本分析2. 模块分析输出1. 测试项2. 补充测试地图测试设计：1. 需要做什么？把测试项细化成测试点缺陷预防2. 需要做什么？基本设计⽅法1. 等价类划分法【将输⼊域和输出域划分为不同的等价类，等价类之内的操作结果相同】，使⽤范围：显⽰输⼊框输⼊2. 边界值法【需要结合等价类划分法⽅法，在划分出来的等价类选取有代表性的值】3. 正反对⽐【⼀般会放到同⼀个⽤例⾥覆盖】4. 字符多样性【考虑不同字符的输⼊】5. 测试类型产品专项测试正交组合设计【正交矩阵，覆盖各个参数间的组合情况】业务逻辑设计【根据业务设计测试点】3. 输出：基本测试点⽤例设计：1. 需要做什么？把测试点⽤⽂字完整表述出来2. 怎么做？功能⽤例框架：模块框架模板需求类UI测试【如果UI⽤例可以被功能⽤例覆盖，这⾥可以不写】公共测试类：链接1. 选中会有⾼亮显⽰2. 点击跳转到对应页⾯3. 当前页⾯对应的名称下有区别显⽰翻页按钮输⼊框【这个功能⽤例⼀般可以覆盖】下拉框排序条⽬选择【这个很重要，第⼀次集成测试⼀定要保证每个选项都是有效的】搜索1. 所有字符类型验证2. 为空验证3. 模糊搜索4. 精确搜索5. 搜索不存在的关键词刷新1. 验证⾃动刷新2. 验证⼿动刷新3. 验证持续刷新拖动移动1. 点击下移，往下移动⼀⾏2. 点击上移，往上移动⼀⾏3. 最上⾯的⾏，上移不能点击，图标灰⾊4. 最下⾯的⾏，下移不能点击，图标灰⾊功能测试测试点：1. 功能基本流程逻辑覆盖2. 业务流程多样性覆盖3. ⽤户操作习惯的多样性4. 模块配置的多样性5. 数据流的多样性覆盖测试⽬录1. 平级分类相对独⽴2. 上下级分类有关联3. 下级从上级细化⽽来关联类：1. 模块与模块之间的2. 模块与功能之间3. 模块与硬件之间场景类建模思路1. 部署⽅式【⽐如⽤户⼀般使⽤2主机还是3主机部署集群】2. 数据流3. 业务流【⽤户是怎么使⽤申请⼯单，是怎么样的完整流程】4. 操作顺序【创建云主机的顺序之类的】5. 配置⽅法【⽤户⼀般怎么配置使⽤静态路由】6. 使⽤时间【⽤户会不会连续长时间开启云主机】7. ⽤户⾓⾊【⼀般那些⾓⾊做什么操作】⽤户操作的设计⽅向1. 最常⽤的功能2. 最容易出现⽹上问题的功能3. 典型客户使⽤的功能4. 版本的性能验证专项类1. 兼容性2. 可靠性【测试产品在异常情况下能否正常⼯作或者是恢复正常⼯作，可靠性重点测试对模块⾃⾝处理的覆盖】. 补充：容错性测试【测试系统在⾮正常操作、⾮正常的外部环境下是否能够处理错误和正常运⾏】eg：1. 针对数据库的测试：【磁盘空间不⾜、数据库⽂件损坏、⽆读写数据权限、写数据时断电、写数据时强制关闭mysql、读写速度】2. 针对⽹络设备：【⽹络中有攻击数据、丢包时延⼤、IP冲突、⽹络线路断开、同时掉电】3. 针对程序：【客户端进程被⼿动停⽌、设备后台资源cpu、内存占满】3. 安全性【主要是验证程序有哪些缺陷可能会造成安全⽅⾯的问题】eg：1. 密码加密⽅式【什么时候⽤明⽂，什么时候⽤密码显⽰】2. 隐私数据隐藏【⽤户的隐私显⽰】3. 设备的完整⽬录【完整的⽬录会增加后台被攻击的危险】4. ⽂件上传功能【检查上传的⽂件类型；限制上传⽂件的权限】5. 防暴⼒破解【对于连线认证之类的操作要冻结、禁⽤其连续错误尝试操作】4. 脚本测试使⽤注意细节1. ⽂件夹以01-xx，02-xx区分开2. 每个⽂件夹下不能超过10个⽤例3. 每个测试⽤例⼀个测试点4. 在02-功能测试的描述中，备注说明功能测试框架的思路⽤例整体规范⽤例标题【好的标题需要准确的表达你的测试⽬的、要测试的测试点】eg：1. 测试。
测试流程图
Level 3
工程得到很好地表现和理解，被描述成标准， 规程，关键和方法。 作为3级基础的组织标准过程集已经简历和不 断改进。 2，3级的区别在于标准，过程和规程的范围 3级比2级的描述更具体和更严格
Level 4
使用统计和量化技术进行控制 建立了质量和过程性能的量化目标，作为过程管理 的准则 收集了过程性能的详细度量，进行统计分析 质量和过程性能度量数据组成组织的度量库，来支 持将来的基于事实的决策 3，4级的区别在于过程性能的可预测性。
同行评审
.评审的输入 --待评审的文档，代码 --《XXX评审检查表》 .评审的输出 --《评审报告》 -- 《评审过程检查表》
正确看待文档
.文档是所有事情能够继承的保证 .如果认为不必要，多一分也是多，如果认为 必要，多少都不够 .文档是一个人水平高低的体现 .需要提高每个人的写作能力，练好内功
CMM2： 可重复性 KPA： 软件配置管理
软件质量保证 子合同管理
Level 2
软件项目跟踪和监控 软件项目计划 需求管理
配置管理
1.定义并文档化配置项的功能和物理属性 2.控制这些属性的变更 3.记录和报告变更处理结果和实施状态 4.遵从制定的需求进行验证
同行评审
为什么进行评审？ .促进文档化，提升可读性，易理解性等 .查找错误，收集建议 .扩散知识，产生后备力量 评审什么？ .项目中的一系列计划 .项目各阶段的输出：文档，代码等 谁来评审？ 项目组成员，PPQA，上级领导，客户等
程序执行的路径是：a b d
该测试用例虽然覆盖了可执行语句，但是并不能检查判断逻 辑是否有问题，例如在第一个判断中把&&错误的写成||，上 面的测试用例仍然可以覆盖所有的执行语句。可以说语句覆 盖率是最弱的逻辑覆盖准则
登记考试工作流程图
登记测试工作流程图绿色：代表由双方共同完成的工作紫色：代表由委托方完成的工作蓝色：由评测中心完成的工作测试工作流程说明和注意事项1委托方电话咨询或在网上下载电子表格●委托方致电中国赛宝实验室软件评测中心（以下简称评测中心：或）均可进行咨询，也可留下联络电话和电子邮箱地址，以便评测中心将需要填写的表格及注意事项发送给委托方。
●委托方也可以在评测中心的网站（，或在表格下载界面直接下载登记测试《登记测试申请表及填写示范》。
2委托方填写电子表格并发回给评测中心委托方必须按照《登记测试申请表及填写示范》填写其中的计算机软件产品登记测试申请表、计算机软件产品功能列表、测试现场软件及硬件环境。
●产品登记测试申请表是填写委托方及委托方被测软件的资料。
●计算机软件产品功能列表是填写委托方被测软件所具有的功能模块及这些功能模块的功能说明。
一般所列功能细化到最后一级菜单，填写格式参照《登记测试申请表及填写示范》中的附件一。
※功能列表上所列出来的功能必须是可以实现或演示的，如果不能演示或实现，请不要列上来，并且功能在用户手册上都要有详细的操作说明。
●测试现场软件及硬件环境是填写该软件运行时所需的软件及硬件资源（将要测试的现场所安装的软件和硬件），填写格式参照《登记测试申请表及填写示范》中的附件二。
请委托方将填写好后的《登记测试申请表及填写示范》、《计算机软件著作权登记证书》复印件（未持有《计算机软件著作权登记证书》的可忽略）及软件产品的相关手册（如：用户手册，操作手册，安装手册，维护手册。
也可以是包括产品介绍、功能描述、操作、安装、维护等内容的一本或多本手册）的电子文档E-mail至评测中心。
如相关手册的电子文档实在过大（压缩后超过20M），可只发送相关手册的封面页及目录页。
●评测中心Email地址：3评测中心检查资料填写的正确性和完整性评测中心检查委托方提交的《登记测试申请表及填写示范》及相关文档，如。
YL-ZLL-20-委外测试工作流程
委外测试工作流程YL-ZLL-20 2003年2月20日 A 1/2 1.流程图：
委外测试工作流程YL-ZLL-20 2003年2月20日 A 2/2
2.流程说明
2.1.计划：质量部根据计量器具的检定周期，制订计量标准器具及检测试
设备的委外测试计划。
2.2.联系：质量部联系有关上级计量部门，如需送到外单位检测的则做好
派车准备，按要求可联系上级计量部门到现场检测。
2.3.派车：生产部按质量部所需派车。
2.4.送检：质量部按送检计划送检。
2.5.现场测试：上级计量部门按玉柴的要求到现场进行测试。
2.6.检定/校准：上级计量部门对送检计量器具进行检定。
2.7.付款申请：根据检测所需费用填写“付款申请”。
2.8.付款：财务部根据“付款申请”，支付款项。
2.9.取回：质量部将检定后的计量器具取回。
3.附则
3.1.制、修、废。
本管理流程，经公司经营委员会（中、高层领导班子组
成）审议后，呈请总经理承认公告实施；修改、废止时亦同。
3.2.公告实施。
本办法自＃＃年＃＃月＃＃日起公告实施。
测试过程流程图
单元测试执行
针对上个测试版本的 BUG记录进行回归测试
测试BUG记录 测试BUG记录版本提交
开发人员修复缺陷，提供新版本
使用测试工具对BUG测试 记录的版本进行控制
回归测试
单元测试总结
提交单元测试记录报告 申请进入下一阶段
集成测试
〈测试用例设计文档〉
制定集成测试计划(方案)
设计集成测试用例、 设计与实现驱动模块、桩模块
试
记录进行测试
使用测试工具对BUG测试 记录的版本进行控制
开发人员修复缺陷提交新版本
回归测试
系统功能达到需求标准
系统测试综合报告
提交系统测试记录报告 申请进入下一阶段
性能测试
〈总体测试用例设计文档〉
制定系统测试计划/方案（性能测试部分）
设计性能测试用例和测试脚本
开发人员对系统 进行优化改进调试
开发人员对运行环境 进行优化改进调试
(1)设计测试所有从系统其他 元素来的信息的错误处理路径； (2)在软件接口处进行一系列 仿真错误数据或者其他潜在 错误的测试； (3)记录的测试结果作为当出现 “互相指责”时裁定的“证据”; (4)参与系统测试的计划和设计
来保证系统进行了足够的测试。
系统测试执行
系
BUG记录
统
测
针对上个测试版本的
BUG记录版本提交
提交测试记录报告 集成测试总结
提交测试记录报告 系统测试总结
提交测试记录报告 性能测试总结
测试计划、测试设计
项目启动，成立测试团队 需求调研，编写《项目需求规格说明书》
（开发和测试共同参与）
依据《项目需求规格说明书》、 《项目开发架构设计》和《项目 整体计划》，设计《测试计划》 和 《测试用例设计》
消防器材检测工作流程图
消防器材检测工作流程图
目标
本文档旨在描述消防器材检测的工作流程，确保消防器材的正常运行和安全性。
步骤一：准备工作
1. 收集所有需要检测的消防器材。
2. 核对器材清单，确保所有器材齐全。
步骤二：外观检测
1. 逐个检查每个器材的外观，包括外壳、线缆、开关等。
2. 如发现任何损坏、老化或缺陷，记录并标记器材。
步骤三：性能测试
1. 根据器材类型，进行相应的性能测试。
2. 使用合适的设备和工具进行测试，并记录测试结果。
步骤四：功能性测试
1. 对每个器材的功能进行测试，确保其正常运行。
2. 测试包括但不限于开关、控制功能、电池寿命等。
步骤五：记录和报告
1. 将每个器材的检测结果记录下来，包括外观、性能和功能测
试结果。
2. 如有任何问题或异常情况，详细描述并标记器材，准备后续
处理。
步骤六：整理和清理
1. 将已检测的器材整理好，确保不会混淆。
2. 清理工作区，确保下次检测能够顺利进行。
步骤七：后续处理
1. 根据记录和报告，对问题器材进行维修、更换或报废。
2. 如有需要，向相关部门汇报检测结果和处理情况。
结论
通过按照上述工作流程进行消防器材检测，我们能够及时发现
问题、确保器材的正常运行和使用安全。
每个步骤都需要认真执行，保证检测的准确性和可靠性。
可靠性测试流程图V1.0
测试立项阶段
硬件测试工程 师（测试代 表）
过程监督阶段
项目计划表
报告分析阶段
001 测试申请
测试申请 单 可靠性测 试方案
005 送样
KSF
可靠性工程 中心负责人
003 审批申请
015 审批产品试验报 告
KCP 002 确认申请 014 审批试验报告
测试报告 样品登记表
项目管理人
009 审核测试计划
信息系统
时间
部门负责人
测试报告
004 测试立项
007 样品入库
010 发出测试计划
016
发布产品试验报告
017
通知申请单领取样 品
018 记录归档
结束
KCP
可靠性测试 工程师
项目计划表
006 确认样品
008 拟定测试计划 KCP
01011 按计划执行测试
012 制作试验报告
测试记录 表 试验过程 记录表
ORT功能测试作业流程图
1. 短期對策和最初 的答复: 24hrs 內
2. 長期對策: 3天 內.
1. 電气方面的功能; 机械方面的功能; 外觀方面.
Corrective Action 1. 在提出長期對策之后的3天內進行有效性确認﹔
Requisition Sheet 2. 要求有負責人的簽署﹔
3天
3. 要求有日期的簽署。
名 稱 : ORT作業流程 編 號 : 818-QP-004
MFG/PE 產線生產/試產
包裝
產線從組立下
核准﹕
QA
檢查 OK
ORT 作業流程
PE/ME/PTE/RD NG
表單 檢驗日報
版本 : A3
1. 電气方面的功能; 2. 机械方面的功能; 3. 外觀方面.
作業說明
1.ORT試驗申請單; 1. 機構、外觀檢驗：機構外觀不得有變形、刮傷、污痕等現象。 2. ORT測試報告 2. 電性功能測試 : a.不同產品及机型依測試WI及客戶要求做相應電性測試 。b. 若檢驗發現有規
審核﹕
பைடு நூலகம்
制作﹕
格不符者，則發行【CAR】。c.試驗中應對每一時段的樣品運行狀況進行記錄，填入【ORT測 試報告】
時效 2 小時
ORT 測試
OK
檢查 OK
NG 跟蹤
OK NG
有效性确認 OK
結束
1. 在MP階段抽樣數為2 units/Model/Week為原則(如客戶有特別要求﹐依客戶要求抽樣)，試驗項
目依實際需求 。
2.在EVT﹑DVT﹑PVT階段抽樣數依實際情況而定(原則上不低于四台)﹐試驗項目依委托單位要求。 NG
ORT測試報告
2. 現有設備可執行試驗項目﹕A. 高壓測試; B.泄漏電流測試。C.靜電放電試驗。D. 線性電壓和
最详细的测试工作流程图
最详细的测试工作流程图
测试工作总体流程图
说明：集成测试与系统测试的反馈意见可能导致设计文档（需求或者数据库）的修改。
单元黑盒测试阶段流程图
集成测试流程图
确认测试阶段流程图
系统测试阶段流程图业务测试流程图
压力测试流程图
说明：压力测试为模拟用户正常使用时，系统正常工作的最小时间。
性能测试流程图
说明：测试系统的崩溃极限（最多使用人数与数据库的极限容量）。
安装测试流程图
验收测试流程图说明：验收测试的人员应包含非本系统的人员。
气体灭火主机测试流程图
气体灭火主机测试流程图
流程图为进行气体灭火主机测试的步骤的可视化表示，下面是气体灭火主机测试的流程图：
1. 准备工作：
- 检查气体灭火主机是否处于正常工作状态。
- 确保测试区域已经被清空，没有人员和其他物体。
- 检查气体灭火系统的各个部件是否运作正常。
2. 开始测试：
- 打开气体灭火主机的控制面板。
- 按照操作手册，依次操作控制面板上的按钮和开关来启动气体灭火系统。
3. 观察灭火效果：
- 注意观察测试区域内气体灭火系统释放的灭火剂是否充分。
- 观察气体灭火剂是否覆盖到整个测试区域。
4. 结束测试：
- 关闭气体灭火主机的控制面板。
- 对测试过程中的数据和观察结果进行记录和总结。
5. 维护和修复：
- 检查气体灭火主机和灭火系统的工作记录，及时进行维护和修复。
请在测试过程中注意安全等相关事项，并按照操作手册和相关规定进行操作。
该流程图简明扼要地描述了气体灭火主机测试的步骤，以帮助操作人员正确进行测试，保证气体灭火系统的稳定性和可靠性。
测试流程图
测试流程图流程图是信息系统分析与设计中常用的一种工具，它通过图形的方式展示了一个过程或系统中的各个步骤及其之间的关系。
在进行软件测试时，流程图也是常用的工具之一，用于记录和管理测试的过程和步骤。
下面是软件测试流程图的一个示例，包含了测试的各个阶段和步骤。
软件测试流程图示例：1. 定义测试目标和范围：- 确定测试的目标和范围，明确要测试的功能和需求。
2. 编写测试计划：- 根据测试目标和范围，编写测试计划，包括测试方法、资源需求、测试时间安排等内容。
3. 设计测试用例：- 根据需求和设计文档，设计测试用例，包括正常情况、异常情况、边界情况等不同情况下的测试用例。
4. 准备测试环境和数据：- 设置测试环境，包括硬件环境和软件环境，准备测试数据，包括测试用例所需的输入数据和预期结果。
5. 执行测试用例：- 按照测试计划和测试用例，执行测试用例，记录测试结果。
6. 发现缺陷并记录：- 在执行测试用例的过程中，发现软件中的缺陷，记录缺陷的详细信息，包括缺陷描述、重现步骤等。
7. 分析和整理测试结果：- 对测试结果进行分析，包括检查通过的用例、发现的缺陷等情况，整理测试结果，形成测试报告。
8. 缺陷修复和再测试：- 将发现的缺陷报告给开发人员进行修复，修复完成后进行再次测试，验证缺陷是否已修复。
9. 完成测试和提交测试报告：- 完成所有测试工作，撰写测试报告，包括测试过程、测试结果、缺陷分析等，提交测试报告给相关人员。
10. 测试评审和闭环：- 进行测试评审，评估测试的质量和效果，根据评审结果进行测试的优化和改进。
11. 重新开始下一轮测试：- 根据测试评审的结果，进行下一轮测试的准备和执行。
通过使用流程图可视化测试流程，可以帮助测试团队更好地管理和执行测试工作，提高测试效率和质量。
同时，流程图也能够清晰地展示测试的整体流程和各个步骤的关系，方便团队成员之间的沟通和协作。
测试规范与流程图
.xx 限公司2022 年9 月xx 2022-09-072.1.产品验收前12.2.产品验收后13.1.等价类划分13.2.边界值分析法13.3.错误猜测法23.3.1.因果图分析24.1.黑盒测试〔功能测试24.2.用户界面测试-UI 测试34.3.随机测试34.4.性能测试34.5. Β测试–此方法针对的是非程序员和测试45.1.产品验收前定义45.2.产品验收后定义5!未定义书签。
编写此文档是为了规范本公司的测试流程,为快速、高效和高质量软件测试提供基础流程框架。
提高测试人员自身测试能力,使测试更加规范化和标准化。
2.1.需求分析书2.2.现场G需求BUG 生效提交禅道指派研发设计测试用例BUG 解决进行回归后闭B G搭建测试环境3.1.等价类是指某个输进入行域功的能子点集测合试。
在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。
并合理地假定：测试某等价类的代表值就等于对提这交一B它值的测试。
因此,可以把全部输入数据合等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据取得较好的测试结果。
等价类划分可有两种不同的情况：有效等价类和无效等价类。
追踪 BUG3.2.回归测试边界值分析方法是对等价类划分方法的补充。
大量的错误是发生在输入或者输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出关闭 BUG更多的错误。
.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界, 就是应着重测试的边界情况。
应当选取正好等于,刚刚大于或者刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或者任意值作为测试数据。
基于经验和直觉猜测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
错误猜测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
例如,在单元测试时曾经列出的许多在模块中常见的错误。