软件测试
定义
计算机程序，数据和文档集合
架构
- C/S 安装客户端
- B/S 浏览器访问
- 软件测试是什么
人工自动手段来运行或测试某个系统过程
目的
① 为了发现程序存在代码业务逻辑错误 --功能问题
② 为了检查产品是否复合用户需求 --用户需求
③ 为了提高用户体验 --流畅度，性能范畴
分类
测试技术
- 黑盒：看不见里面具体实现：输入数据，输出结果，大部分测试都用这个，
- 白盒：代码很清楚，看懂代码运行，开发自测单元测试
- 灰盒：不需要代码，知道里面的逻辑实现即可，接口测试
被测试对象是否运行划分
-
动态测试（打开app）静态测试（文档检测，代码走查）
-
手工测试（点工，纯手动）
-
自动化测试（工具（有局限性）+代码）
测试内容
- 功能测试
- 界面测试
- 安全测试
- 兼容性
- 易用性
- 性能测试
测试阶段
- 单元测试
- 集成测试
- 系统测试
- 验收测试
- α测试 β测试
其他
- 回归测试
- 冒烟测试
- 探索性测试/自由测试（测试思维）
| 名称 | 说明 |
|---|---|
| 白盒测试 | 透明测试，代码很清楚。基于软件内部设计和程序实现的测试方法(代码层面）。不仅仅关注输入与输出的结果是否正确，同时还关注程序是如何处理的 |
| 黑盒测试 | *字面：*把所有的功能和逻辑接口放在一个盒子里，你看不到里面的逻辑和走向，只能通过盒子外表进行测试 *定义：*指在测试过程中只关注输入和输出，如果输入一个测试数据，输出结果是正确的，则认为这个功能是正确的，也叫数据驱动测试 |
| 功能测试 | 软件测试的功能是否复合需求，通常采用黑盒测试方法，一般由测试人员独立执行。 |
| 界面测试 | 简称UI测试，测试用户界面布局是否合理，整体风格是否一致，界面文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等 |
| 安全性测试 | 测试该系统防止非法入侵的能力 |
| 兼容性测试 | 测试该系统与其他软件硬件兼容的能力（app与cs架构软件、bs架构软件） |
| 易用性测试 | 软件测试是否易用，主观性比较强，一般要根据很多用户的测试反馈信息，才能评价易用性（同类型产品） 用户使用习惯 好不好用 |
| 性能测试 | 通过自动化测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试 |
| 负载测试 | 通过改变系统负载方式、增加负债等来发现系统组所存在的性能问题。更多地体现了一种方法或一种技术。为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等 |
| 压力测试(强度测试) | 分为:高负债下的长时间(如24小时以上)的稳定性压力测试和极限负债情况下导致系统崩溃的破坏性压力测试。主要为了确定系统稳定性。可以更快发现内存泄漏问题，更快发现影响系统稳定性的问题 |
| 恢复测试 | 主要检查系统的容错能力。采用各种办法强迫系统是吧，后验证系统能否在指定时间间隔内尽快恢复并重新启动系统 |
| 回归测试 | 指错误被修正后或软件功能、环境发生变化后进行的重新测试，确认修改部分不会对其它功能造成影响 |
| 冒烟测试 | 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。 |
| 探索性测试 | 是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方法。 |
| Alpha测试 | 一种前期用户测试，公司内部组织员工及部分用户，模拟实际操作环节下进行验收测试（内测） ---不能由测试和开发进行，仅测试数据，开发环境（内测删档） |
| Beta测试 | 一种后期用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。在一个或多个真实环境下发布版本，进行测试（公测） |
| Alpha测试与Beta测试的相同与不同相同：①开发和测试不参与，必须由用户来（避嫌）不同：①Alpha属于前期，Bate属于后期 ②Alpha在开发环境进行，Bate在正式环境运行 |
软件生命周期
研制开始到被废弃所经历的各个阶段
瀑布型生命周期模型
在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落，具有序性和依赖性。每个阶段规定文档并需进行评审，
V模型
RAD(Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件开发的V模型。
它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
- 系统测试用例根据需求说明书编写
- 集成测试用例根据概要设计中模块功能接口等实现方法编写出来
- 单元测试用例是详细设计一起出现的，在研发人员做详细设计时候相应的测试就要写测试用例
敏捷开发
1990年开始逐渐引起广泛的关注，是一种以人为核心，快速迭代、循序渐进的开发方法。强调以人为本、专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中软件一直处于可使用状态。
特点：以人为核心，弱化文档，强化人之间的沟通
快速迭代：
例：微信-文字聊天 语音 视频 朋友圈 红包 小程序 零钱通 公众号（需求）-分各种迭代版本
第一迭代：文字、语音聊天→3个月-上线 用户量 占领市场
第二迭代：视频 朋友圈→2个月-用户量还在，吸引新用户
第三迭代：红包 小程序 零钱通→3个月
…产品不断重复迭代--让产品完善 丰富-达到需求
开发模型细化
-
问题定义规划：产品
-
主要确定软件开发目的及其可行性，制定项目总体开发计划 --初步需求
-
-
需求分析–需求评审会议–测试参与少许
-
在确定软件件开发可行对软件需要实现各个功能进行详细分析，明确客户需求（需求评审-产品-开发测试）
输出需求规格说明书
-
设计开发文档–开发工作
-
把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。 概要设计：主要是架构实现，指搭建架构，表述各模块功能，模块接口链接和数据传递实现等项事务， 详细设计：对概要设计中表述各模块进行深入分析，其中需要包含数据库设计说明
-
-
写代码
- 按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
软件测试
单元测试：
主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类，函数、方法的测试等。 ---白盒测试，开发自测
集成测试：
单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递。---灰盒测试==接口测试
系统测试
把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。--黑盒测试 --要求低，入门（几轮）
验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。 --UAT ---不是测试员做的
用户驱动–用户验收
核心功能（功能性能安全），老板验收产品
| α测试 | α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试;α测试不能由程序员或测试员完成。 |
|---|---|
| β测试 | β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 |
| 灰度测试 | 系统测试通过后，将测试版本发布到线上环境，替换部分的线上服务器进行预测试。当校度测试结束后，线上版本实现会统一。本质上是上线前的测试，收集用户的反馈 |
| A/B测试 | 指的是系统测试通过并发布后，同一个软件功能不同的用户会看到不同的实现方式，收集每个用户的反馈。本质上是上线后的测试，收集用户的反馈。 |
运行维护-时间最长
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面。
软件测试工作流程
软件测试基本流程
测试需求
阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议
测试计划
编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围（来自需求文档）、进度的安排、人力的分配、整体测试策略的制定，和风险点评估与规避措施有一个制定，一般有测试负责人（测试老大）编写，也可能参与相关的评审（检验用例是否完善、需求理解是否正确、防止漏测错测）工作
测试设计
主要任务是编写测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通，用例编写完成后会进行评审
测试执行
首先搭建测试环境、执行预测（冒烟），以判定当前版本可测与否，如果预测通过，正式进入系统测试（2-4轮），遇到问题提交Bug到缺陷管理平台并对Bug进行跟踪，直到被测软件达到测试需求要求，无重大bug，测试结束。 ---完善测试用例
测试评估
出测试报告，对整个测试过程和版本质量做一个详细评估（剩余Bug数量/严重程度，测试用例的覆盖率），确认是否可以上线
UAT：部署到UAT测试环境，有产品或者领导来验证
1.你们公司的开发流程是怎样的?---了解
2你们公司的测试流程是怎样的?各个阶段的输出是什么?(需求，计划用例bug 报告)\
3.开发环境，测试环境，生产环境、预发布环境是什么?你在测试环境后台添加的数据和信息，能够在生产环境看到么?---必须不能
开发环境 -- 开发自测的环境，开发使用
测试环境 -- 测试员执行测试环境，测试自己维护(运维维护)
生产环境 -- 用户环境（正式)，发现上线--部署到生成环境，用户可以直接使用(不能有个测试数据)
预发布环境(UAT环境) -- 上线之前做的验收测试的环境--验收测试
4、你们公司的项目发布流程是什么样的?--知道，了解
发布上线流程:开发测试工作--测试通过（(测试报告评估之后，说测试通过了)--->发邮件告知（项目经理，产品，开发，运维)--->验收测试通过了--->开发把最终测试通过的版本打包(签名-包名)---运维、运营、开发,产品---->部署到生产环境上---->测试验证一下(测试数据不留)---通过--上线成功
测试需求分析
测试需求是什么—需求文档
测试主要解决测试什么，一般来说需求规格说明书原始需求
测试需求应覆盖已定义的业务流程，以及功能和非功能的需求
功能：基本用户需求-优先
非功能：界面兼容性，易用性，安全性能
为什么需要软件测试
简而言之:只有明确了测试需求，才能知道怎么去测试?什么时候开始测试?要多少人测试
?在什么环境上测试? --- 提炼测试点（测试用例），时间规划，人力规划，测试环境==测试计划包含
测试点思路：正常+异常
- 正常功能：是否可以正常提交，注册成功
- 单个功能验证（异常），避免漏测
- 规则：按顺序从上至下，每一个输入项进行验证
- 数据长度，数据类型验证，必填验证，重复
- 限制约束验证
- 隐形需求，充分熟悉产品业务，挖掘|隐形需求
- 功能交互验证
- 模块之间传递信息数据，对存在交互功能的功能项
- 非功能测试
- 界面，易用性，兼容性，安全性，性能压力
| 测试需求分析 | ||
|---|---|---|
| 序号 | 验证项 | 测试点 |
| 1 | 注册 | 输入所有正确输入项，点击下一步，验证是否注册成功 |
| 2 | 手机号码 | 手机号码的长度是否符合要求 |
| 手机号号码数据类型是否符合要求 | ||
| 手机号码是否为必填项 | ||
| 手机号码是否能重复 （同一个号码重复注册） | ||
| 手机号码号段（199）验证--举例1-2个不存在的号段 | ||
| 特殊手机号码（110）--不一定 | ||
| 国内外 境外卡验证 （可能重复）-- 测试数据 | ||
| 手机号段加前缀（86）--- 需求确认 | ||
| 3 | 图片验证码 | 图片验证码的长度是否符合要求 （刷新出来的验证码是否一致） |
| 图片验证码数据类型是否符合要求（刷新出来的验证码是否一致） | ||
| 图片验证码是否为必填项 | ||
| 图片验证码时效性验证（刷新之前的） | ||
| 图片的验证码显示（初始显示，刷新之后更改） | ||
| 图片验证码是否区分大小写---产品确认 | ||
| 4 | 短信验证码 | 长度 |
| 数据类型 | ||
| 必填项 | ||
| 有效期验证 | ||
| 5 | 密码 | 密码的长度是否符合要求 |
| 密码的数据类型是否符合要求 | ||
| 密码是否为必填项 | ||
| 密码是否可以重复 | ||
| 密码是否可见 | ||
| 再次确认密码单选框填写完密码是否有提示 | ||
| 6 | 同意协议 | 是否勾选 （可点击范围）--默认值 |
| 检查文档--静态测试 | ||
| 7 | 下一步 | 按钮能否点击---检查结果里验证 |
| 是否支持回车确认 | ||
| 8 | 功能交互 | 注册用户是否能够正常登陆 （1、自动登录 2、 手动登录） |
| 9 | 非功能 | 界面、易用性、兼容性、安全性、性能压力 |
| 注意： | 提取测试点，不一定全部考虑到，重点是测试的思维不一定每个都会覆盖，后期可以不断去做丰富--体现思路清晰==测试思维 |
笔试题及面试题
1、遇到隐形需求怎么办？
优先根据自身的经验，充分熟悉产品的基础上，参考其他相关成熟产品的流程，去分析隐形需求，挖掘相关隐性需求，不明确可以找产品和开发做详细的确认
2、给你一个带logo的水杯，你会如何去进行测试
功能：水杯：装水，喝水，容量，保温，盖子
非功能：
界面（UI）：logo是否清晰，是否正确，颜色，外观是否满足需求
兼容：是否可以盛放不同的液体（冰水，热水，饮料，牛奶），放在桌子上会不会打滑，会不会对桌面造成影响 ，和杯盖、杯垫是否契合
安全：杯子的材质是否对人体有害，杯子的logo是否侵权
易用：是否便携，是否方便拿（杯柄，双层隔热），是否打滑 ，是否方便喝水
性能：是否抗压，抗高温，抗摔
3、给你一支笔你会怎么进行测试？
功能：笔是否正常写字，笔尖是否损坏，书写过程中是否流畅，是否出现不出水的情况
非功能：
界面：笔的外观是否完好，logo是否清晰，有无掉漆，磨损
安全：笔的材质，整体是否对人体有害，笔的品牌是否存在侵权
兼容：笔放在笔筒里，桌子上，放在身上会不会出现漏油等问题
性能：笔的质量怎么样，抗摔，抗压
易用：是否便携，手感是否良好，有无笔盖，书写过程中手感是否良好
4、给你一张A4纸你会怎么进行测试？
功能：笔在A4纸上是否可以书写，打印机使用A4纸复印打印是否有内容
非功能：
界面：外观，大小是否为A4的尺寸，纸的质地，材质，颜色，厚度
易用：正常的笔，容不容易在纸上写出文字，方不方便复印打印等功能
兼容：使用彩笔，油笔不同的笔能否正常书写，不同型号的打印机能否正常打印复印
安全：纸的材质是否对人体有害，毒性物质，生产过程中是否安全，高温燃烧情况
性能：A4纸的质量是否良好，容不容易破损，使用过程中是否轻易破损
用例设计
等价类划分
概念
等价类划分法是所有程序输入域划分成若干个子集合，然后每一个子集合中选取少数具有代表性的数据作为测试输入数据
所有输入数据对于揭露软件中错误都是等效的，–保证质量，减少测试用例数量，提高效率
等价类划分有效等价类（正面。不会报错）无效等价类（负面，抛出错误）
等价类划分法用例设计步骤和原则
- 分析需求，先确定其有效等价类和无效等价类
- 在确定等价类后，建立等价类表，列出所有划分等价类
- 再从划分出等价类中选择测试用例
设计一个新的测试用例数据，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止，减少测试用例的数量，避免重复，提高效率
设计一个新的测试用例数据，仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止，为了确定哪个是因素触发错误，每一种错误都被正确处理
等价类划分应用场景，测试了数据过大，且数据操作可以分类时进行等价划分。
边界值分析
- 定义边界值分析法是对等价类划分法一个补充，边界值一般都是从等价类边缘值寻找
- 原则和步骤：确定边界，应当选取正好等于刚刚大于或刚刚小于边界的值作为测试，数据–范围相关有效等价类边界*无效等价类边界
- 有效等价类边界值
- 注意：次边界值，IP地址 (0~255) ，时间格式 (0~23) ，2的幂值 (256,1024,65535) -需求没有明说，常识
- 特殊边界值 0，负数，空值，空格
- 边界值作用：人们长期测试工作经验，大量错误发生时输入或输出范围边界，而不是输入范围内部，因此针对各种边界设计测试用例，可以查出更多错误
- 边界值应用场景，如果需求规定了取值范围内或规定了取值个数，可以利用边界值进行测试。
等价类划分法/边界值分析法常见应用场景
- 输入条件规定取值范围或取值个数，比如用户名长度，红包金额
- 下拉列表包含多个选项情况，比如城市下拉选项
- 规定输入数据必须遵守规则情况下，可以确立一个有效等价类和若干个无效等价类
边界值还包括
- 报表数据第一行，最后一行中间有一行–拜年截止
- 屏幕上左上角，右下角
等价类
测试用例
场景法
通过场景描述业务流程，也包括代码实现逻辑，设计用例遍历场景，验证软件系统功能正确性
如何使用场景法
画出流程图–产品需求文档画好了，需要测试（软件WPS，office -visio， processon）
矩形：表示步骤
菱形：判断条件 是否
箭头流向
遍历场景，提取测试用例
2.2遍历场景,提取测试用例。
1)覆盖正常的路径-取到钱的路径 ---- 判断的地方--Y
2)走每一个分支--判断的地方---找菱形--N
3)出错步骤重新回到主流程,建议多走-步正确的步骤--注意:
场景法重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步功能进行测试，只有单个功能点，流程测试，才算是充分测试等价类，边界值，细化测试
场景法例子
\、
场景一: 插入合法银行卡,输入正确的密码，输入正确且充足的金额，ATM足够--- 取到钱
场景二: 插入不合法的卡,退卡提示错误;
场景三 插入合法银行卡,输入密码之后取消，--退卡
场景四:插入合法银行卡，输入错误的密码之后不取消,不超过3次-提示密码错误，重新输入密码
场景五: 插入合法银行卡，输入错误的密码之后不取消,出错3次--吞卡
场最六: 插入合法银行卡,输入正确的密码之后不取消,输入不合法金额--提示错误，重新输入
场景七: 插入合法银行卡，输入正确的密码之后不取消,输入合法金额，账户余额不足--提示错误，重新输入
场景八: 插入合法银行卡，输入正确的密码之后不取消，输入合法金额，账户余额充足，
ATM不足余额-提示错误，重新输入
错误推测法案例
1、账号密码错误(异常字符输入，为空)
2、验证(图片，短信)
3、网络问题
4、浏览器兼容性
5、性能弱(并发大量用户)
6、账号黑名单--举报
7、登录失败错误次数--冻结账号
8、服务器异常-无响应
9、第三方登录问题
10、单点登录（登陆限制）--处理
11、某个时间内最大登录次数 --网站具体要求
场景一：员工提交请假申请，请假天数超过三天，部门经理审批通过后部门总监审批通过，HR审批通过，请假成功
场景二：员工提交请假申请，请假天数不超过三天，部门经理审批通过后HR审批通过，请假成功
场景三：员工提交请假申请，请假天数超过三天，部门经理审批不通过，员工重新提交申请
场景四：员工提交请假申请，请假天数超过三天，部门经理审批通过，部门总监审批不通过，员工重新提交申请
场景五：员工提交请假申请，请假天数超过三天，部门经理审批通过，部门总监审批通过，HR审批不通过，员工重新提交申请
场景六：员工提交请假申请，请假天数不超过三天，部门经理审批不通过，员工重新提交申请
场景七：员工提交请假申请，请假天数不超过三天，部门经理审批通过，HR审批不通过，员工重新提交申请
2、输入边长A、B、C 3个值，判断是否能构成三角形，输出对应的信息？
分析思路： 首先要考虑a，b，c是否为正数：a>0，b>0，c>0
三角形判断依据：三角形任意两边之和大于第三边：a>0，b>0，c>0
直角三角形判断依据：勾股定理：a²+b²=c² or a²+c²=b² or c²+b²=a²，
等腰三角形判断依据：两边相等：a=b≠c 或 a=c≠b 或 b=c≠a
等边三角形判断依据：三边相等：a=b=c
等腰直角三角形
1、场景法，画出流程图,并整理出测试用例
| *输入条件* | *有效等价类* | *无效等价类* |
|---|---|---|
| *三角形* | 1）a，b，c为正数 | 2）a，b，c不为正数 |
| 3）任意两边之和大于第三边 | 4）任意两边之和小于第三边 | |
| 5）两边相等,a=b≠c或a=c≠b或b=c≠a | 8）空 | |
| 6)三边相等：a=b=c | 9）负整数 | |
| 7)三边不相等，如A!=B，B!=C，C!=A | 10）非数字 | |
| 11）少于三个数 |
2、等价类划分法，整理出测试用例
| 输入条件 | 有效等价类 | 无效等价类 |
|---|---|---|
| 是否是三角形 | 1）A>0 | 7）A<=0 |
| 2）B>0 | 8）B<=0 | |
| 3）C>0 | 9）C<=0 | |
| 4) A+B>C | 10）A+B<=C | |
| 5）B+C>A | 11）B+C<=A | |
| 6）C+A>B | 12）C+A<=B | |
| 是否是等腰三角形 | 13) A=B | 16)(A!=B)and(B!=C)and(C!=A) |
| 14) B=C | ||
| 15) C=A | ||
| 是否是等腰直角三角形 | 17) (A=B)and(A2+B2=C2) | 20)(A!=B)and(B!=C)and(C!=A) |
| 18) (B=C)and(B2+C2=A2) | ||
| 19) (C=A)and(C2+A2=B2) | ||
| 是否是等边三角形 | 21)(A=B)and(B=C)and(C=A) | 22) A!=B |
| 23) B!=C | ||
| 24) C!=A | ||
| 直角三角形 | 25)A2+B2=C2 | 28) A2+B2 !=C2 |
| 26)B2+C2=A2 | 29) B2+C2 !=A2 | |
| 27)C2+A2=B2 | 30) C2+A2 !=B2 | |
| 31）空 | ||
| 32）负整数 | ||
| 33）非数字 | ||
| 34)少于三个数 |
| *测试用例描述* | *测试输入* | *测试覆盖* | *输出* |
|---|---|---|---|
| a，b，c为正数，任意两边之和大于第三边 | （3,4,5） | 1,2,3,4,5,6 | 是三角形 |
| A＜0 | （0,1,2） | 7 | 非三角形 |
| B＜0 | [1,0,2] | 8 | 非三角形 |
| C＜0 | [1,2,0] | 9 | 非三角形 |
| A+B<=C | [1,2,3] | 10 | 非三角形 |
| B+C<=A | [1,3,2] | 11 | 非三角形 |
| C+A<=B | [3,1,2] | 12 | 非三角形 |
| A=B | [3,3,4] | 1,2,3,4,5,6,13 | 等腰三角形 |
| B=C | [3,4,4] | 1,2,3,4,5,6,14 | 等腰三角形 |
| C=A | [3,4,3] | 1,2,3,4,5,6,15 | 等腰三角形 |
| (A=B)and(A2+B2=C2) | [2,222,4] | 1,2,3,4,5,6,17 | 等腰直角三角形 |
| (B=C)and(B2+C2=A2) | 【4,22,22】 | 1,2,3,4,5,6,18 | 等腰直角三角形 |
| (C=A)and(C2+A2=B2) | [22,4,22] | 1,2,3,4,5,6,19 | 等腰直角三角形 |
| A=B=C | 【3,3,3】 | 1,2,3,4,5,6,21 | 等边三角形 |
| (A!=B)and(B!=C)and(C!=A) | 【3,4,5】 | 1,2,3,4,5,6,16,20,22，23,24 | 是三角形，非等腰或者等边直角 |
| 数字为空 | 【，，】 | 31 | 错误提示 |
| 负整数 | 【-3,4,5】 | 32 | 错误提示 |
| 非数字 | 【a，@，￥】 | 33 | 错误提示 |
| 少于三个数 | 【3,4】 | 34 | 错误提示 |