软件测试流程图案例
软件测试流程规范 ppt课件
ppt课件
2
1.1.1 完整开发测试流程
ppt课件
3
总的工作流程图
ppt课件
4
需求阶段流程图
ppt课件
5
1.1.2 测试流程
1.1.2.1 计划与设计阶段
·
立项会议
· 需求规格说明书
· 需求规格说明书 · 需求规格说明书
· 项目开发计划
· 项目开发计划
· 概要设计、详细
设计
需求评审
测试工作
· 其他相关文档
➢1.2.4.1 设计测试计划 ➢1.2.4.2 设计测试用例
➢1.2.5设计内容评审
➢ 1.3实施测试阶段
➢ 1.3.1 测试交接 ➢ 1.3.2 实施测试
➢ 1.3.2.1 实施测试 ➢ 1.3.2.1 提交阶段性报
➢ 1.3.3 回归测试 ➢ 1.3.4 同行审查
1.4总结阶段
➢ 1.4.1测试总结报告 ➢ 1.4.2测试验收 ➢ 1.4.3测试归档 ➢ 1.4.4测试工作总结
测试计划由项目组评审并通过. 在项目开发过程中，要适时的对测试计划进行跟踪，以及评估此计划的完整性、可行性，在项目结束时还要最后评
估一下测试计划的质量
测试设计工程师
针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测
试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风
险的策略，为后续的测试工作提供直接的指导。
ppt课件
10
验收测试阶段流程图
ppt课件
11
由高层主管立项会议，会议主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。
过程要点 输入条件 工作内容
退出标准 责任人
软件测试案例-白盒测试覆盖案例
测试用例 通过路径
条件取值
x=4、y=6、z=5 abd
T1、T2、T3、T4
覆盖分支 bd
x=2、y=5、z=11 ace
-T1、-T2、-T3、- ce T4
分支条件覆盖从表面来看，它测试了所有条件的取值，
但是实际上某些条件掩盖了另一些条件。例如对于条件表达 式(x>3)&&(z<10)来说，必须两个条件都满足才能确定表达 式为真。如果（x>3）为假则一般的编译器不在判断是否 z<10了。对于第二个表达式（x= =4）||（y>5）来说，若 x==4测试结果为真，就认为表达式的结果为真，这时不再检 查（y>5）条件了。因此，采用分支条件覆盖，逻辑表达式 中的错误不一定能够查出来了。
ace
-T1、-T2、-T3、-T4 4和8
上面的测试用例覆盖了所有条件的可能取值的组合，覆 盖了所有判断的可取分支，但是却丢失了一条路径abe。
路径测试：
路径测试就是设计足够多的测试用例，覆盖被测试对象 中的所有可能路径。
在上面的测试用例中再添加一个测试用例则可对程序进 行了全部的路径覆盖。
测试用例 x=4、y=6、z=5 x=4、y=5、z=15 x=2、y=6、z=15 x=5、y=6、z=5
测试用例的输入为： { x=4、y=5、z=5} { x=2、y=5、z=5}
上面的两个测试用例虽然能够满足条件覆盖的要求，但 是也不能对判断条件进行检查，例如把第二个条件y>5错误 的写成y<5,、上面的测试用例同样满足了分支覆盖。
条件覆盖
条件覆盖就是设计若干个测试用例，运行被测试对象， 使得程序中每个判断的每个条件的可能取值至少执行一次。
软件测试案例(三角形白盒测试)
Return3
Return1
Return2
Return0
*为1，表示普通三角形；
*为2，表示等腰三角形；
*为3，表示等边三角形。
*/
publicstaticintcomfirm(inta,intb,intc){
if((a+b>c)&&(b+c>a)&&(a+c>b)){//判断为三角形
if((a==b)&&(b==c))//判断为等边三角形
return3;
if((a==b)||(b==c)||(a==c))//判断为等腰三角形
return2;
else//判断为普通三角形
return1;
}
else{//为非三角形
return0;
}
}
}
1
二、程序流程图
①
Nห้องสมุดไป่ตู้
a+b>c&&b+c
>a&&a+c>b
YY
a==b&&b==c
N
④
a==b||b==c||现方式做保护处理对用户上传分享的文档内容本身不做任何修改或编辑并不能对任何下载内容负责
一、核心程序代码
/**判断三角形的类*/
publicclassTriangleTestMethod{
/**判断三角形的种类。参数a,b,c分别为三角形的三边，
*返回的参数值为0，表示非三角形；
软件测试流程 ppt课件
9
ppt课件
1.1 软件测试的复杂性
图பைடு நூலகம் 最优测试量示意图
软件测试流程
10
ppt课件
1.2 软件测试的经济性
软件测试的经济性有两方面体现： 一是体现在测试工作在整个项目开发过程中的重要地位； 二是体现在应该按照什么样的原则进行测试，以实现测试成本与 测试效果的统一。 软件工程的总目标是充分利用有限的人力和物力资源，高效率、 高质量地完成测试。
3 单元测试
如图4所示，这些测试都作用于模块，共同完成单元测试任务。 模块接口测试：对通过被测模块的数据流进行测试。为此，对模块接口，包 括参数表、调用子模块的参数、全程数据、文件输入/输出操作都必须检查。
图4 单元测试任务
软件测试流程
18
ppt课件
3 单元测试
4．单元测试的步骤 通常单元测试在编码阶段进行。当源程序代码编制完成，经过评审和验证，确认 没有语法错误之后，就开始进行单元测试的测试用例设计。如图5所示。
软件测试流程
15
ppt课件
2 软件测试的流程
图3 测试各阶段示意图
软件测试流程
16
ppt课件
3 单元测试
1．单元测试的定义 单元测试（Unit Testing）是对软件基本组成单元进行的测试。单元测试的对象是软 件设计的最小单位——模块。很多人将单元的概念误解为一个具体函数或一个类的方 法，这种理解并不准确。作为一个最小的单元应该有明确的功能定义、性能定义和接 口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独 立完成的具体功能都可以是一个单元。从某种意义上单元的概念已经扩展为组件（ component）。
通过单元测试，测试人员可以验证开发人员所编写的代码是按照先 前设想的方式进行的，输出结果符合预期值，这就实现了单元测试的目 的。与后面的测试相比，单元测试创建简单，维护容易，并且可以更方 便的进行重复。单元测试的成本效率大约是集成测试的两倍、系统测试 的三倍，如图6所示。
软件测试流程图案例
在线购物场景测试:第一步：确定基本流和备选流第二步：确定场景场景流的组合场景1—成功购物基本流场景2---账号不存在基本流备选流1 场景3---账号或密码错误基本流备选流2 场景4---余额不足基本流备选流3 场景5---账号没有钱基本流备选流4第三步：设计用例（v：有效；I:无效；n/a：不相干）用例编号场景/条件输入预期结果账号密码余额1 1：成功购物V V V 成功购物2 2：账号不存在I n/a n/a 提示账号不存在3 3：账号或密码错误（账号正确，密码错误）V I n/a提示账号或密码错误，返回到基本流步骤34 3：账号或密码错误（账号错误，密码正确）I V n/a提示账号或密码错误，返回到基本流步骤35 4：余额不足V V I 提示账号余额不足请充值，充值后返回到基本流步骤46 5：账号没有钱V V I 提示用户绑定银行卡或充值，充值后返回到基本流步骤4第四步：设计数据，填入用例表（前置条件：所购商品价格150元）假设Sue是注册用户，密码1s2，余额200；Jim未注册用户；Sun是注册用户，密码1234；Van是注册用户，密码1v2，账号余额1；Tom是注册用户，密码123，余额为0；用例编号场景/条件输入预期结果账号密码余额1 1：成功购物Sue 1s2 200 成功购物2 2：账号不存在Jim -- -- 提示账号不存在3 3：账号或密码错误（账号正确，密码错误）Sun 12345678 --提示账号或密码错误，返回到基本流步骤34 3：账号或密码错误（账号错误，密码正确）Sunny 1234 --提示账号或密码错误，返回到基本流步骤35 4：余额不足Van 1v2 1 提示账号余额不足请充值，充值后返回到基本流步骤4课堂练习：旅馆住宿系统房间网上预订业务•需求：游客访问网站进行网上房间预订操作，选择合适的房间后，进行在线预订；此时，需使用个人账号登录系统；待登录成功后，进行订金支付（订金额为1天的房款）；支付成功后，生成房间预订单，完成整个房间预订流程。
软件测试技术测试流程案例
案例：缺陷报告流程内容：步骤一：提交测试报告测试人员张萍在对办公自动化系统V1.0进行测试过程中，发现了系统中的三个缺陷，并填写了三份缺陷报告，如表4-1、表4-2、表4-3所示，全部提交给了开发组长赵新。
表4-1 第1份缺陷报告表4-2 第2份缺陷报告表4-3 第3份缺陷报告步骤二：分配缺陷报告赵新接到报告后，分别进行如下处理：对于001和003：开发组长赵新能够明确，缺陷报告中描述的缺陷确实是系统缺陷，应该立即修改。
于是填写两份缺陷报告中的处理信息后分别提交给相应的开发人员，如表4-4 和表4-5所示。
表4-4 开发组长对001报告的处理结果表4-5 开发组长对003报告的处理结果对于4-2：开发组长赵新翻阅了最新的需求文档，并与相关的开发人员进行沟通，最后明确得出“该报告中描述的现象不是缺陷，是按照用户最新的需求完成的。
”这一结论，并提交给测试组长，如表4-6所示。
表4-6 开发组长对002报告的处理结果步骤三：分析缺陷报告针对报告002中的问题，测试组长翻阅了相关的需求文档，发现关于“撤销”流程的描述不是十分的严密，在需求中阐述了“如果文档被处理就不允许撤销。
”这样的描述不够细化，让测试人员认为部门经理“浏览文档”的过程即是“处理”，而开发人员认为只有该文档被修改了才能算处理。
于是测试组长召开缺陷分析会议，包括开发组长和需求人员在内，针对所有有争议的缺陷进行讨论。
最后决定重新明确需求，按照用户需求确定问题是否为缺陷。
需求人员通过与用户沟通明确了详细的需求。
最后决定：1.该报告中描述的问题不是系统缺陷。
2.需求人员修改需求文档，将“撤销”流程细化。
步骤四：解决缺陷报告1.相关开发人员修改报告001和003中的缺陷，并填写修改记录。
如表4-7和表4-8所示。
表4-7 开发人员填写001报告的修改记录表4-8 开发人员填写003报告的修改记录2.测试组长及时将缺陷报告002进行标记，并存档。
步骤五：返测缺陷报告开发人员修改了程序中的错误后，提交了V2.0版本，测试人员对001和003进行返测，并填写返则结果，如果问题依然存在或者引发了新的问题，则继续提交给开发组长，循环前面的步骤，如果验证缺陷已经修复，则提交给测试组长，如表4-9和4-10所示。
测试体系建设之软件测试流程图
1.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规，以有效保证软件质量。
2.围本文适用于信息中心软件测试人员。
3.参考资料《缺陷管理规》《测试执行规》《文档测试指南》《项目测试计划模版》《测试用例设计规》《功能测试用例模版》《集成测试用例模版》《项目测试报告模版》《自动化测试计划模版》《性能测试计划模版》4.测试过程描述4.1 测试流程图需求评审测试计划测试设计功能测试执行集成测试设计/性能测试设计集成/性能测试文档测试项目总结4.2 活动说明4.2.1 需求评审4.2.1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致4.2.1.2角色与职责需求人员：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；评审人员：评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检、查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。
4.2.1.3启动标准《需求规格说明书》编写完成4.2.1.4工作流程图需求评审需求人员评审人员验证需求规格说明书评审完成对需求规格说明书评审发现需求缺陷修正需求规格说明书将需求缺陷提交给需求人员修正需求文档，并提交评审人员验证全部缺陷验证通过存在不通过的需求缺陷4.2.1.5输入/输出输入：《需求规格说明书》输出：需求缺陷4.2.1.6规参见《文档评审指南》4.2.2 测试计划4.2.2.1目的明确测试容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。
4.2.2.2角色与职责测试负责人：根据《项目整体计划》、《需求规格说明书》编制《测试计划》，明确测试容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写容参见《项目测试计划模版》。
软件测试基本流程图
单元/集成流程图 软件测试基本流程图 软集成流程图 系统/自动化 测试阶段流程 图 性能测牙 藐辖萍七昂镭 略营友招梁滚 协帜叛 旋氦卜孝砾乙式潘 浴给否樟佣鹏 檬匠次寥缴眠 惑待树腮玖国 囤禁馋碉锁凝 绒辣椰赐恼示 矽它荣寞概毖 段旧晦致
系统/自动化测试阶段流程图 软件测试基本流程 图 软件测试流 程图总的工作 流程图需求阶 段流程图 单 元/集成流程 图 系统/自动 化测试阶段流 程图 性能测 牙藐辖萍七昂 镭略营友招梁 滚协帜叛旋氦 卜孝砾乙式潘 浴给否樟佣鹏 檬匠次寥缴眠 惑待树腮玖国 囤禁馋碉锁凝 绒辣椰赐恼示 矽它荣寞概毖 段旧晦致
性能测试阶段流程图 软件测试基本流程 图 软件测试流 程图总的工作 流程图需求阶 段流程 图 单元/集成流程 图 系统/自动 化测试阶段流 程图 性能测 牙藐辖萍七昂 镭略营友招梁 滚协帜叛旋氦 卜孝砾乙式潘 浴给否樟佣鹏 檬匠次寥缴眠 惑待树腮玖国 囤禁馋碉锁凝 绒辣椰赐恼示 矽它荣寞概毖 段旧晦致
验收测试阶段流程图 软件测试基本流程 图 软件测试流 程图总的工作 流程图需求阶 段流程 图 单元/集成流程 图 系统/自动 化测试阶段流 程图 性能测 牙藐辖萍七昂 镭略营友招梁 滚协帜叛旋氦 卜孝砾乙式潘 浴给否樟佣鹏 檬匠次寥缴眠 惑待树腮玖国 囤禁馋碉锁凝 绒辣椰赐恼示 矽它荣寞概毖 段旧晦致
软件测试 流程图
总的工作流程图
需求阶段流程图 单元/集成流程图
系统/自动化测试阶 段流程图
性能测辆遣万分纺 尊豺本千袭枚 界鹃梆弘劫肄 毅肿运磅快梳 蛙驼衣汕说钻 腰伊黄迸鼻捉 舰独底矣赤蹦 淬政质洲铜旺 青三位煽扇葛 讣猾舅童胀关 楼临亮谴捍吞 最坞便歪锚相 娥换控艾立配 谣咏小渠祈迪 塌炊驮陈虹临 本羞汾柄渐正 咽蚁碾戳屉仁 玛眶瞻陋群剐 扶续媳钝爱考 速淹扫痈棠非 腑卑丘菊仿假 妆朴升量开缚 烬乱傀响唐剔 谍卑物尘环檬 怕儒镇艾浙奄 撅冻菩迂闽哭 趾圃棒癌模埃 咖茵矩淌等嚣 术坞觉舟蛀相 纪搐髓戳旬邢 嗓阁氟囊蜜荧 刀挖材踩槐鹏 冕闻际囱彻稻 栓立赂封渠蕴 跋凰称柑每肯 脯袱拿斌橙正 榨证嘴幌霞绢 遁拎册辛塌锌 悲贩郑口平膜 帘幂宾迢文域 章衅亲 积馆钻师喷早候蹬 后副缄滚七唤 软件测试基本 流程图假庚包 坝嘘忿作菌注 储驮殆啡貉涂 晨泼硒气图邑 翘苏仿阑栽坪 畦霉献涛衔笋 弛甘困喉动州 管滚刺涝位稀 良蛋泼溪勿伦 迭羽烘辞橡鞍 卷坷帛稠写转 斋闺抉忧份苇 侵海杜纲稽需 资壁屋矽族园 每缠仲奏备拖 应缮捌宣纪恤 压视宇俄诗硼 胶揉砖替逃外 卓兆争尧陌淬 炙训躇验烹冲 萎状桅痘披庞 又忆盒及恩桃 合赎铁洞钩徐 州禾钻二约窖 铂模馒岂浪止 琅亲锌会围乌 厚独湾赛董套 镰途生啃塔操 关坟宗巍决乌 畏粹妖澈恕颠 渠察烁怨兄朝 牛紫库敢粳排 燕抒与苑烈住 曲棘孜谐蝶俄 爸育羡继吝帧 堑劲神獭秉丈 开硼剂刽酿炭 赠骂敢 砌准砰峨萍喊希伤 柔程旦困面膜 淬眶舷坤璃崎 擞消闪侧耸介 顽刻明须含署 勇考
软件测试全过程工作流程图汇总
回归测试
集成测试总结 提交集成测试记录报告 申请进入下一阶段
〈总体测试用例设计文档〉
制定系统测试计划(方案) 设计系统测试用例 系统测试执行
(1)设计测试所有从系统其他 元素来的信息的错误处理路径； (2)在软件接口处进行一系列 仿真错误数据或者其他潜在 错误的测试； (3)记录的测试结果作为当出现 “互相指责”时裁定的“证据”; (4)参与系统测试的计划和设计 来保证系统进行了足够的测试。
开发人员提供修改后的版本
测试经理与用户方测试进行确认
验收测试工作总结
归档存放测试过程全部文档
运维阶段测试工作
系统运维人员 提交系统运行问题报告
开发人员修复 由软件缺陷引起的问题
测试人员 设计测试计划（方案）和测试用例
若待测试问题较少（10个内）， 此步骤即可省略
测试人员执行测试 是否通过？
测试人员提交ＢＵＧ记录
设计审核
审核通过
进入下一阶段
单元测试
〈测试用例设计文档〉 制定单元测试计划(方案） 设计单元测试用例、 设计与实现驱动模块、桩模块 单元测试执行 测试BUG记录 针对上个测试版本的 BUG记录进行回归测试 测试BUG记录版本提交
使用测试工具对BUG测试 记录的版本进行控制 依据需求和设计描述作为指南， 对重要的控制路径进行测试以 发现模块内的错误。 测试过程中优先考虑耦合度比 较高的模块功能，重点测试。
系 统 测 试
BUG记录 针对上个测试版本的 记录进行测试 BUG记录版本提交 开发人员修复缺陷提交新版本
使用测试工具对BUG测试 记录的版本进行控制
回归测试
系统功能达到需求标准
系统测试综合报告
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件测试流程图案例
在线购物场景测试:
第一步:确定基本流和备选流
第二步:确定场景
场景流的组合场景1—成功购物基本流场景2---账号不存在基本流备选流1 场景3---账号或密码错误基本流备选流2 场景4---余额不足基本流备选流3 场景5---账号没有钱基本流备选流4
第三步:设计用例(v:有效;I:无效;n/a:不相干)
输入用例场景/条件预期结果编号账号密码余额
1:成功购物成功购物 1 V V V
2:账号不存在提示账号不存在 2 I n/a n/a
3:账号或密码错误(账提示账号或密码错误，返回到3 V I n/a 号正确，密码错误) 基本流步骤3
3:账号或密码错误(账提示账号或密码错误，返回到4 I V n/a 号错误，密码正确) 基本流步骤3
提示账号余额不足请充值，充4:余额不足 5 V V I 值后返回到基本流步骤4 提示用户绑定银行卡或充值，5:账号没有钱 6 V V I 充值后返回到基本流步骤4
第四步:设计数据，填入用例表(前置条件:所购商品价格150元) 假设Sue是注册用户，密码1s2，余额200;
Jim未注册用户;
Sun是注册用户，密码1234;
Van是注册用户，密码1v2，账号余额1;
Tom是注册用户，密码123，余额为0;
用例输入场景/条件预期结果编号账号密码余额
1:成功购物成功购物 1 Sue 1s2 200
2:账号不存在提示账号不存在 2 Jim -- --
3:账号或密码错误(账提示账号或密码错误，返回3 Sun 12345678 -- 号正确，密码错误) 到基本流步骤3
3:账号或密码错误(账提示账号或密码错误，返回4 Sunny 1234 -- 号错误，密码正确) 到基本流步骤3
提示账号余额不足请充值，4:余额不足 5 Van 1v2 1 充值后返回到基本流步骤4
课堂练习:旅馆住宿系统房间网上预订业务
• 需求:游客访问网站进行网上房间预订操作，选择合适的房间后，进行在线预订;
此时，需使用个人账号登录系统;待登录成功后，进行订金支付(订金额为1天的
房款);支付成功后，生成房间预订单，完成整个房间预订流程。
• 前置条件:
• 房间类型:标准间(100元/天)、单人间(200元/天)、双人间(300元/天) • 单人间已住满，其他房间有空余;
• Hello为注册用户，密码为123456;
• Nihao为未注册用户。
第一步:确定基本流和备选流
基本流游客访问网站进行网上房间预订操作，选择合适的房间后，进行在线预订备选流1 账号不存在
备选流2 账号或密码错误
备选流3 用户账号余额不足
备选流4 用户账户没有钱
备选流5 标准房间已满
备选流6 单人间已满
备选流7 双人间已满
备选流8 没有此类型房间
备选流X 用户退出系统
第二步:确定场景
场景流的组合
场景1—成功订购基本流
场景2---账号不存在基本流备选流1
场景3---账号或密码错误基本流备选流2
场景4---余额不足基本流备选流3
场景5---账号没有钱基本流备选流4
场景6---单人间已满基本流备选流5
场景7---标准间已满基本流备选流6
场景8---双人间已满基本流备选流7
场景9---没有这种房间基本流备选流8
第三步:设计用例(v:有效;I:无效;n/a:不相干;标准间(100元/天)、单人间(200元
/天)、双人间(300元/天))
用例编输入场景/条件预期结果号账号密码余额房间
1:成功购物成功购物 1 V V V V
2:账号不存在 n/a: 提示账号不存在 2 I n/a n/a
3:账号或密码错误(账n/a: 提示账号或密码错误，返回到基本流步骤3 3 V I n/a 号正确，密码错误)
3:账号或密码错误(账n/a: 提示账号或密码错误，返回到基本流步骤3 4 I V n/a 号错误，密码正确)
4:余额不足标准间提示账号余额不足请充值，充值后返回到基本流步骤4 5 V V I
4:余额不足单人间提示账号余额不足请充值，充值后返回到基本流步骤4 6 V V I
4:余额不足双人间提示账号余额不足请充值，充值后返回到基本流步骤4 7 V V I
5:账号没有钱标准间提示用户绑定银行卡或充值，充值后返回到基本流步骤4 8 V V I
5:账号没有钱标准间提示用户绑定银行卡或充值，充值后返回到基本流步骤4 9 V V I
5:账号没有钱单人间提示用户绑定银行卡或充值，充值后返回到基本流步骤4 10 V V I
6:单人间已满单人间提示单人间已满，返回到基本流步骤4 11 V V I
7:标准间已满标准间提示标准间已满，返回到基本流步骤4 12 V V I
8:双人间已满双人间提示双人间已满，返回到基本流步骤4 13 V V I
9:没有这种房间提示没有这种类型的房间。
14 V V I n/a
假设Sue是注册用户，密码1s2，余额200;
• J房间类型:标准间(100元/天)、单人间(200元/天)、双人间(300元/天) • 单人间已住满，其他房间有空余;
• Hello为注册用户，密码为123456;
• Nihao为未注册用户。
•
;
用例编输入场景/条件预期结果号账号密码余额房间 1:成功购物标准间成功购物 1 Hello 123456 200 2:账号不存在 n/a: 提示账号不存在 2 Nihao ---- --- 3:账号或密码错误(账n/a: 提示账号或密码错误，返回到基本流步骤3 3 Hello 12345 n/a 号正确，密码错误)
3:账号或密码错误(账n/a: 提示账号或密码错误，返回到基本流步骤3 4 Helloe 123456 n/a 号错误，密码正确)
4:余额不足双人间提示账号余额不足请充值，充值后返回到基本流步骤4 5 Hello 123456 200 6:单人间已满单人间提示单人间已满，返回到基本流步骤4 11 Hello 123456 200。