1在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
参考答案：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像....等等；
bug出现时的测试环境，产生的条件即对应操作步骤；
高质量的Bug记录：
1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。
为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13) 尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，
将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
14) 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，
但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。
2根据自己的理解什么是测试用例和测试规程，设计一个测试用例应当从哪几方面考虑？
参考答案：
狭义来讲，一个测试用例就是 测试人员 用以测试被测软件的某个特性或特性组合的一组数据。这组数据可能是从用户处得来的实际的一组数据，也可能是测试人员专门设计出来的测试软件某些功能的一组数据。
测试规程就是详细的 对 测试用例设计方法、测试方法、测试工具、测试环境和测试数据进行描述的文档，还可以包括能把某个或某一组测试用例应用到被测软件上完成某项测试的一系列的操作步骤。
设计测试用例应当从以下的几个方面考虑 ：边界值，等价类划分，有效/无效值等。
3什么是回归测试?
参考答案：
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
4设计用例的方法、依据有哪些？
参考答案：
白盒测试用例设计有如下方法:基本路径测试\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构
黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
5什么是黑盒测试？如果进行了充分的黑盒测试，还需要进行白盒测试吗？为什么？
参考答案：
需要的，白盒测试是测试重要的一部分，其实测试当中很大一部分错误都是白盒测试检测出来的，另外白盒测试作为测试的最早期阶段，发现bug的修改代价是最小的，所有白盒测试同样重要
6按阶段划分测试分为哪几种类型？各自的侧重点是什么?
参考答案：
软件测试可分为单元测试、集成测试，系统测试、确认测试和验收测试。 单元测试：针对每个单元的测试， 以确保每个模块能正常工作为目标。 集成测试：对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。 确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段。有的划分方法中，也将确认测试合并入系统测试中。 系统测试：检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。 验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。 验收测试可以分成Alpha测试和Beta测试。 Alpha测试是由用户在开发环境下完成的测试，Beta测试是由用户在用户环境下完成的测试。
7你认为开发人员自己测试和测试人员测试的区别是什么?
参考答案：
开发人员测试会产生盲点，会认为自己做的不会有错，这导致的结果就是找不出Bug，测试人员没有参与开发，所以会有这种盲点，测试出来的结果更直观，更可信
8对一个由三个模块组成的系统执行功能测试，第一轮测试完成后，统计发现其中一模块Bug比例为65％，其它模块发现数量为35％，当开发人员对这些Bug修复后，第二轮测试开始，首先针对已发现的Bug进行修复确认测试通过后，需要再进行一次全面的功能回归测试，测试组长决定不将发现大量Bug的模块做为重点，而是将其它两模块做为重点进行测试，你认为这个测试策略是否正确？为什么？
参考答案: 不正确，回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，所以每一个模块都要进行重点测试，同时，一个模块Bug占的比例越多，则没有被发现的bug可能性越大，越容易产生新的Bug
9现有要求你对一根签字笔做测试，你如何进行测试？请先确定测试策略，再写出尽可能多的测试用例（注意策略及条理）
参考答案：
1）、功能测试:笔的部件完整性;笔的大小规格;笔能否书写:笔水从笔管里能否倒流;在书写过程中，笔水是否流出来;笔头是否容易掉出来
2）、性能测试:压力测试，看用多久能用烂，把它绑在电动机上划纸盒
3）、用户体验:找尽量多的群众,搜集FeedBack
4）、破坏测试:看在几楼掉下会摔坏,记录高度和地面硬度，烧,看燃点是多少,煮,看煮完坏不坏
5）、安全测试:潜入机场,把这个扔在飞机进气孔里，看能不能引起爆炸;让白鼠吃笔心,看是否中毒
10你认为一个优秀的测试工程师应该具备哪些素质？
参考答案：
一个优秀的测试工程师应该具备的基本素质有:责任心、沟通能力、团队精神、自信心、耐 心、怀疑精神、洞察力、幽默感等。应具备的专业素质有:有竞争力的测试人员要具有三方面的技 能:计算机专业技能、测试专业技能、软件编程技能。
11什么是兼容性测试？兼容性测试侧重哪些方面？
参考答案：
兼容测试主要是检查软件在不同的硬件平台、 软件平台上是否可以正常的运行， 即 是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格 式的兼容。
兼容测试的重点是， 对兼容环境的分析。通常，是在运行软件的环境不是很确定的 情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用 户会在什么环境下使用该软件， 把这些环境整理成表单， 就得出做兼容测试的兼容环境 了。
兼容和配置测试的区别在于， 做配置测试通常不是 Clean OS下做测试， 而兼容测试多 是在 Clean OS的环境下做的。
12我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
参考答案：
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等 2、检查软件/硬件的配置是否符合软件的推荐标准 3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行 4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的； 5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
13正交表测试用例设计方法的特点是什么？
参考答案：
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
14易用性测试测试要点？（web）
参考答案：
1）操作是否友好、易用、易理解。 2）执行风险操作时，有确认、删除等提示。 3）是否支持tab和enter键。 4）快捷键检查：是否支持常用快捷键，如Ctrl+C、Ctrl+V、Tab、Enter、Backspace等。
5）窗口的最大化、最小化是否能正确切换。
15软件的评审一般由哪些人参加？其目的是什么？
参考答案：
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
16你认为做好测试计划工作的关键是什么？
参考答案：
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键：目的，管理，规范
1、 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4、分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
17分页测试测试要点？（web）
参考答案：
翻页功能我们常碰到的一般有以下几个功能：
1、首页、上一页、下一页、尾页。
2、总页数，当前页数
3、指定跳转页
4、指定每页显示条数
当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。
对于1翻页链接或按钮的测试，主要要检查的测试点有：
1、有无数据时控件的显示情况
2、在首页时，首页和上一页是否能点击
3、在尾页时，下一页和尾页是否能点击
4、在非首页和非尾页时，四个按钮功能是否正确
5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序
对于2总页数，当前页数，主要要检查的测试点有：
1、总页数是否等于总的记录数/指定每页条数
2、当前页数是否正确
对于3指定跳转页，主要要检查的测试点有：
1、是否能正常跳转到指定的页数
2、输入的跳转页数非法时的处理
对于4指定每页显示条数，主要要检查的测试点有：
1、是否有默认的指定每页显示条数
2、指定每页的条数后，列表显示的记录数，页数是否正确
3、输入的每页条数非法时的处理
18软件系统中除用户文档之外，文档测试还应该关注哪些文档？
参考答案：
开发文档
1软件需求说明书
2数据库设计说明书
3概要设计说明书
4详细设计说明书
5可行性研究报告
管理文档
1项目开发计划
2测试计划
3测试报告
4开发进度月报
5开发总结报告
19文档测试主要包含什么内容？
参考答案：
一、文档测试的内容： 1、文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。
2、描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
3、易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
4、文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
5、印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。
二、软件文档测试对象与目的 1、文档测试对象主要如下： 包装文字和图形； 市场宣传材料、广告以及其它插页； 授权、注册登记表； 最终用户许可协议； 安装和设置向导； 用户手册； 联机帮助； 样例、示范例子和模板；
2、文档测试的目的： 提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。 因此文档测试的检查内容主要如下：
读者对象——主要是文档的内容是否能让该级别的读者理解； 术语——主要是检查术语是否适合读者； 内容和主题——检查主题是否合适、是否丢失、格式是否规范等； 图标和屏幕抓图——检查图表的准确度和精确度； 样例和示例——是否与软件功能一致； 拼写和语法； 文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致； 文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。
三、做好文档测试需要注意： 仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例； 检查文档的编写是否满足文档编写的目的； 内容是否齐全、正确、完善；
20功能测试用例需要详细到什么程度才是合格的？
参考答案：
测试用例覆盖到所有的测试点。
21没有产品说明书和需求文档的情况下能够进行黑盒测试吗？
参考答案：
可以。
这个情况下我们就要进行探索性测试，把软件当成用户需求，一步步进行测试。凭借经验判断功能正确与否，有的时候还可以与项目经理、开发人员一起进行交流沟通，从而进行更好的测试。
22输入域测试测试要点？（web）
参考答案：
一、文本型输入框：
文本型输入框分为单行文本输入框和多行文本输入框
单行文本输入框（type=text）：
①、类型：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。
特殊字符：
1、键盘上能输入的特殊字符
2、空格
3、货币符号：￥，$等
4、数学符号：=、不等于，求和等
5、非英文字母语言符号：a等汉语拼音
6、中文标点符号：，。、（）等
7、特殊汉字：囫囵饕餮、爨（cuàn）齉（nàng） 繁体字
8、转义序列：\n、\r、\t、\’等
9、系统保留字符：null、NULL等
10、SQL语句：‘OR ‘1’=’1等
11、脚本函数：<‘script’>alter(“Test,Bom~~~”)<‘/script’>
12、转义字符：> ;,< ;等
13、输入html代码：比如“ 你好”－－必须以文本的形式将代码显示出来。
14、输入域如对某些字符禁止输入时，限制是否成功，提示信息是否友好
②、长度：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。
③、空格（判断）：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格
④、唯一性：是否唯一，重复性校验
多行文本输入框（type=textarea）：
1)空格和换行的问题，看需求，是否需要做支持HTML Encoding
输入全部空格时，是否判空处理？””空格， 。
输入折行，是否也显示折行？
比如：列点说明原因，就需要支持。
2)字母截断的问题
对于一串字母，开发人员往往会忘掉做截断，这样如果展示在我们的平台上的话，这一串字母就会把我们的UI撑开
3）长度控制格式， 您还可以输入***个字符
4）允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）
二、数字型输入框：
①、边界值：最大值、最小值、最大值+1、最小值-1
②、位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值
③、限制：如不能直接输入，就copy试下
④、异常值、特殊字符：输入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）
三、日期型输入框：
①、合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]
②、异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符
23完全测试程序是可能的吗？
参考答案：
不可能
测试人员对程序进行测试，只能找出程序中的bug，但是并不能保证程序是没有bug的。
完全的测试要花费很多的人力财力，并且测试的数据量过大，很浪费时间。测试的结果还很多，有的都是类似的，没有必要进行相同的测试。所以完全测试是不可能的。
24软件测试的风险主要体现在哪里？
参考答案：
主要体现在没法完全测试。有些问题可能隐藏在没有测到的地方。这样子就被忽略了。客户使用的时候并不熟悉软件是如何操作的。可能有的时候会误点点出问题。这样子的话我们就要承担很大的风险了。
25发现的缺陷越多，说明软件缺陷越多吗？
参考答案：
是的，通常如果发现一个缺陷的话，有的时候会发现很多类似的缺陷，因为由于开发人员的习惯，可能一个地方有错误，另外一个地方就会有相同的错误。
26所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
参考答案：
从理论上来说所有的缺陷都是可以修复的，但是并不是所有的缺陷都要修复。
一些对于软件没有影响的、不影响使用的缺陷我们可以不用修复。因为修复些细小的缺陷也是需要花费很多时间。项目上面可能会因为时间问题而先忽略这些小缺陷。
27软件测试人员就是QA吗？
参考答案：
QA(Quality Assurance), STE(Software Testing Engineer)QA关注的重点不仅仅是质量，而且是整个软件过程，保证的首先是过程和体系。而软件测试通过一系列活动，给QA人员提供尽可能的有效的信息和数据，使他们能够发现过程上的异常或者制度上的不妥之处。共同之处：QA和测试的目的一样，都是尽可能保证最终发布的产品更符合用户需求，尽可能的没有bug。不同之处：QA关注的是整个软件过程，STE关注的是最终质量，采用设计、执行用例等方法去发现错误。
28表单提交测试的测试点？
参考答案：
1、是否支持回车
2、单击
3、快速双击， 可能会导致重复提交的bug
4、网络中断
5、只输入必填项，单击提交
6、分别缺少一个必填项、单击提交（无效等价类不能合并）
7、所有字段的最大长度，单击提交
8、所有必填项+非必填项 ，单击提交
9、提交成功是否有提示
10、如果有上传附件，附件超大、网络慢，提交后是否成功
11、表单提交后内容是否加密，
12、SQL注入
13、权限校验，也就是说只有有权限的人才可以提交
14、对于修改、新增、审核等需要修改数据库中数据的操作，多人同时操作的场景需要测试，比如A编辑，B再编辑然后B提交，A提交
29如何编写提交给用户的测试报告？
参考答案：
（1）不可以向客户报告严重缺陷，即便是已经修改的严重缺陷，开发过程中的bug我们就没有必要让客户知道的
（2）报告上面的内容尽量要真实可靠;
（3）报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的;
（4）整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
30搜索测试测试要点？（web）
参考答案：
搜索条件一般主要包含2种：输入框搜索条件、下拉框搜索条件。
对于多个条件的页面搜索可以按照下面的编号顺序去进行测试（假设搜索条件为4个）：
1）任单个条件查询：正常输入搜索、模糊搜索、超长搜索、不存在与之匹配的条件、为空；
2）任两个组合查询：确保任两个组合查询的正确性验证，验证两个组合的所有情况；
3）三个组合查询：不需要测试三个组合的全部级组合。因为前面针对所有单个条件的搜索、两个组合的所有组合进行测试了，那么在这里选择2-3组三种组合进行测试即可；
4）全条件组合查询：确保最大组合的正确性；
5）默认条件查询：补充默认条件查询的用例；
6）根据需求或者业务规则选取重点条件组合查询，如果此点与第1）2）3）4）重复，不需重复测试。
在这里再给大家普及下，搜索框搜索还有一种常见的情况就是：时间输入框 关于按时间来搜索的测试点，可以从以下考虑：
1）开始时间=结束时间，验证一天范围的数据；
2）开始时间<结束时间，验证跨天、跨月、跨年的数据；
3）开始时间大于/小于当前时间，若是针对出生年月搜索，验证大于的情况；若是定时任务时间搜索验证小于的情况；
4）只输入开始时间或者只输入结束时间；开始时间和结束时间都不输入；
5）结束时间早于开始时间，验证系统是否给予合理提示；
6）验证是否支持手动输入时间，并注意时间格式验证例如20180612格式
31写出bug报告流转的步骤，每步的责任人及主要完成的工作。
参考答案：
测试人员发现bug，提交在bug管理工具中，状态为new。 项目经理把这个bug分配给相应的开发人员，状态为open。 开发人员修改完bug后重新提交给测试人员测试，状态为fixed。 如果bug暂时无法解决，仍然为open状态。 测试人员重新测试bug，如果没有问题的话将bug关闭，既close。 如果问题仍然存在的话将bug重新打开给开发人员修改，状态为reopen。
32为什么要在一个团队中开展软件测试工作？
参考答案：
在团队中开展软件测试工作，是因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。
软件质量的好坏直接影响消费者的利益，所以优秀的软件一定要经过测试后，才能上市。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
33链接测试的要点有？（web）
参考答案：
(1)错误链接。错误链接是指链接产生的内容与预期的内容不一致，测试过程中需要每个链接所链接到的内容是正确的。有时候由于客户的疏忽，也可能导致链接的内容出错，如URL地址拼写错误、URL 后缀多余或缺少斜杠、URL 地址中出现的字母大小写不完全匹配、用户输入的域名拼写错误。
(2)空链接。空链接是指未指派的链接，用户单击该链接时不会指向任何内容。测试过程中需要保证每个链接都已被指派。
(3)死链接。死链接指原来正常，后来失效的链接。向死链接发送请求时，服务器返回404错误。
以下情况会出现死链接：
>>动态链接在数据库不再支持的条件下，变成死链接
>>某个文件或网页移动了位置，导致指向它的链接变成死链接
>> 网页内容更新并换成其他的链接，原来的链接变成死链接
>> 网站服务器设置错误
(4)孤立页面。孤立页面是指没有链接指向该页面，只有知道正确的URL 地址才能访问。测试过程中需要保证Web 应用系统上没有孤立的页面。
34您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
参考答案：
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
35您认为做好测试用例设计工作的关键是什么？
参考答案：
白盒测试设计测试用例的关键是以最少的测试用例覆盖尽可能的多的内部逻辑。
黑盒测试设计测试用例的关键是以最少的测试用例覆盖尽可能多的模块的输入输出接口。
总之就是以最少的用例覆盖尽可能多的测试点，并在最短的时间内找出最多的bug。
36测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
参考答案：
软件测试计划是指导测试过程的纲领性文件：
1领导能够根据测试计划进行宏观调控，进行相应资源配置等
2.测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等
3.便于其他人员了解测试人员的工作内容，进行有关配合工作
测试计划文档的内容包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
其中哪些是最重要的：测试计划编写6要素（5W1H）：
why——为什么要进行这些测试；
what—测试哪些方面，不同阶段的工作内容；
when—测试不同阶段的起止时间；
where—相应文档，缺陷的存放位置，测试环境等；
who—项目有关人员组成，安排哪些测试人员进行测试；
how—如何去做，使用哪些测试工具以及测试方法进行测试
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。
37您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用(结合本次项目)
参考答案：
等价类划分：就是把所有的测试数据分成若干个集合，在每个集合中挑选具有代表性的数据进行测试。这样就节省了测试时间。 边界值分析：很多错误都是发生在数据范围的边界上，并不是发生在数据范围的内部或者外部，边界值分析可以找出更多的bug。 错误推测：凭借自己的测试经验推测是错误应该存在的地方。
38请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。
参考答案：
首先，拿到需求后要详细的理解需求，在理解需求的基础上编写测试计划，要考虑到测试的时间、测试环境等等。 其次，要根据需求编写测试用例。根据测试对象的不同采用不同的测试用例编写方法，用例编写完后要进行评审。 然后，要搭建测试环境，比如说拿到一台裸机的时候要安装客户所需要的系统，并安装所需要的软件并且进行一些必须的配置。 最后，执行测试。
39你以前工作时的测试流程是什么？
参考答案：
提取测试需求（根据产品整理的需求规格说明书）-->"测什么"
=> 编写测试计划
=> 制定测试方案
=> 设计测试用例 （测试需求告诉咱们"测什么"，具体"怎么测"，放在用例中）
=> 执行测试 (拿上开发出来的软件,按照测试用例设计的测试场景,执行测试)
=> 提交缺陷
=> 测试分析与评审
=> 提交测试报告 （测试人员脸面担当，测试在整个过程中做了哪些事情）
=> 准备下一个版本的测试
40当开发人员说不是BUG时，你如何应付？
参考答案：
开发人员说不是bug，有2种情况，
一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
41简述一下c/s模式或者b/s模式？
参考答案：
Client/Server结构是20世纪80年代末提出的。这种结构的系统把较复杂的计算和管理任务交给网络上的高档机器——服务器，而把一些频繁与用户打交道的任务交给前端较简单的计算机—客户机。
B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。
客户机上只要安装一个浏览器（Browser英 ['braʊzə]美 ['braʊzɚ]），如Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。
42产品上线之后出现了bug，相关负责人过来质问，“为什么测试的时候没有发现这个bug”？
参考答案：
可以回答说:我们会在这个问题修复上线后进行复盘，找出问题出现的原因，如果是测试团队的问题，我们会主动承担责任并作出总结，避免下次再犯。
一定要体现自己的担当和冷静！
那该如何进行复盘呢？
首先就是分析是否是用例未覆盖到, 如果是，那不好意思了,这锅得背！说明在设计用例的时候未考虑到这样的场景, 然后做线上问题记录分析，在今后编写用例的时候针对类似的异常情况应该多考虑哪些场景，设计更为完善的测试用例。
在答复上级领导的时候可以这样回答：
由于在设计用例的时候考虑不充分导致了这个问题，我们内部已经针对此类问题做了相应的测试用例补充，并根据该问题的场景做了延展设计，防止类似的问题再出现！
并且已经在测试测试环境进行了新的测试, 上线后也做了相应的测试和回归测试，保证这个问题已经完全解决并不影响其他正常功能。
如果该类问题在线上能够复现，但在测试环境复现不了这种情况该如何处理呢？
这种情况可能是线上数据与测试数据差异的原因，也可能是部署线上环境的时候漏掉了一些配置脚本（sql脚本，阿波罗配置等）这种时刻就没必要背锅了！我们需要将此问题及时反馈给上级并记录。让他们进行协调沟通。
一句话总结：”做好自己的事，愿于接受批评和改正，但也不背不该背的锅！
三、质量全靠测试吗
测试工程师能测出所有bug吗?
这个问题就好像在问医生能不能治好所有的病一样！
没有哪个医生能治好所有的病！正如没有任何一个测试工程师能发现所有的BUG！
只要是软件，就一定会有bug。而测试工程师的存在，不是为了消灭bug，而是为了控制风险！
其实，产品上线出现问题是非常正常的事情，无论是我们熟知的微信，抖音，支付宝等都会在我们使用的时候发现BUG，记得之前使用掌上英雄联盟的时候，随便测了一下BUG一大堆！
但它们很少出现完全阻断用户体验，或者影响很严重的BUG，所以BUG测不完！但阻塞的，严重的BUG是一定测的完的！
测试人员首先要相信自己是个人不是神，如果要写尽测试用例，做遍所有的测试是不可能的。在实际的测试过程中，总是有重点有范围的去测试，澄清需求，发现设计缺陷，跟研发积极沟通，确认影响范围，完善测试范围，负责完成测试工作，线上问题及时复盘加入用例库等等。
四、被甩锅如何回怼
碰到线上BUG这种问题，毫无疑问是会扯皮的！
唯一的办法就是拿出日常工作的测试记录，特别是bug！一定要入库，不论BUG严重级别，或者是否能够复现，是否是经确认过可以暂时不处理的BUG，只要你觉得是BUG那就提出来，就算最后被确认不是BUG也要留档做记录。这是一个非常有效且重要的措施！
如果遇到你觉得很小的问题，只是简单跟开发说了一声，那最后背锅的可能就是你了！
另外就是做好总结，在开发测试过程中很容易遇到需求变更的情况，毕竟计划没有变化快，况且很多东西要实际开始做了才会发现需求或者技术上等需要变更实现方法的问题。
这些问题可以在群聊中进行讨论，但讨论后一定要有文档记录，类似在线文档：这个问题什么时间提出的，解决方法是什么，谁确定的都要详细的记录在文档中！
一句话总结就是：避免口头确认！！善用文档记录！！
五、总结
质量是个大问题，从产品、设计、开发、测试、运维都需要投入关注。
作为测试，是上线产品前质量保证的最后一道关卡！
需要更有责任心的去面对被测产品！
一个好的测试工程师，不应该仅仅以发现多少bug、发现多少严重级bug为荣，而应该努力做到通过控制流程，从源头上控制bug数量的产生！
测试工程师无法发现所有的BUG，只能在测试方法，测试用例上进行改进和优化，尽可能地降低风险！
43UI用户界面测试测试要点？（web）
参考答案：
UI 测试要点
用户界面一般是由窗体及其内部控件组成。因此， 界面测试主要从窗体及窗体中的控件两方面来考虑。
一个窗体一般由标题栏、 菜单栏、 工具栏、 状态栏及内部控件组成， 因此为主要测试目标
1、 窗体的测试
(1) 窗体的大小
窗体的大小要合适， 使内部控件布局合理， 不过于密集， 也不过于空旷。
(2) 窗体的位置。
对于主窗体， 显示屏正中， 对于子窗体， 一般应在父窗体显示区的中间。
(3) 移动窗体
快速或慢速移动窗体， 背景及窗体本身刷新必须正确。
(4) 缩放窗体
① 鼠标拖动
对于固定大小的窗体， 鼠标拖动不能缩放其大小。
对于能用鼠标拖动缩放大小的窗体， 放大或缩小窗体后其内容也应做相应调整。
② 单击‘最大化’ 按钮。窗体被最大化， 内部控件大小或位置也应做相应调整。
③ 单击‘还原’ 按钮。应还原到窗体最初默认的大小。
④ 单击‘最小化’ 按钮。对于主窗体， 应最小化到系统状态栏的左下角， 并依次排列；对于窗体中的子窗
体， 应最小化到父窗体容器的左下角， 并依次排列。
(5) 显示分辨率。
通常情况下， 计算机的显示分辨率包括 800×600、 1024×768、 1280×1024 等等。
【注意】 由于程序员在编程时， 可能使用了固定的控件大小和位置， 不能随分辨率的改变而变化， 因此， 在分
辨率为 1024×768 下开发的程序在分辨率为 800×600 时， 会出现显示内容被裁切的情况。
(6) 宽屏和普屏。
宽屏和普屏的显示器， 界面显示效果可能不一样。
2、 标题栏的测试
(1) 不同窗体的图标要易于分辨
① 父窗体的标题图标；
② 子窗体的标题图标；
③ 提示信息窗体的标题图标；
④ 警告信息窗体的标题图标；
⑤ 错误信息窗体的标题图标；
(2) 标题内容
①标题的内容要简明扼要， 且不能有错别字。
② 父窗体的标题内容；
③ 子窗体的标题内容；
④ 提示信息窗体的标题内容；
⑤ 警告信息窗体的标题内容；
⑥ 错误信息窗体的标题内容；
3、 菜单栏的测试
1） 菜单深度最好不超过 3 层；
2） 菜单通常使用 5 号字体。3） 菜单前的图标不宜太大， 与字高保持一致最好。
4） 各项菜单是否能完成相应功能？
5） 各菜单与其完成的功能是否一致？
6） 有无错别字？
7） 有无中英文混合？
8） 快捷键或热键
① 是否有效？
② 是否重复？
9） 鼠标右键菜单；
10） 不可用菜单是否真的不可用？（这在不同权限下会出现。）
4、 工具栏的测试
1） 工具栏中通常使用 5 号字体， 工具栏一般比菜单栏略宽。
2） 相近功能的工具栏放在一起。
3） 工具栏的按钮要有即时提示信息， 图标要能直观的表达要完成的操作。
4） 一条工具栏的长度最长不能超过屏幕宽度。
5） 系统常用的工具栏设置默认放置位置。
6） 工具栏太多时可以考虑使用工具箱， 由用户根据自己的需求定制。
5、 状态栏的测试
1） 显示用户切实需要的信息
① 目前的操作
② 系统的状态
③ 当前位置
④ 时间
⑤ 用户信息
⑥ 提示信息
⑦ 错误信息
⑧ 如果某一操作需要的时间比较长， 还应该显示进度条和进程提示。
2） 状态条的高度以放置 5 号字为宜。
6、 控件的测试
（1） 控件自身的测试
1 控件本身的大小
2 控件本身的位置
3 控件字体
4 字体的大小、 半角、 全角
5 错别字、 中英混合
7、 文本框
1 作用：接受用户输入的数据或显示数据。
2 状态：可编辑（正在编辑、 未编辑） 、 不可编辑。
3 测试点：
7.1 根据文本框作用：
输入数据的内容
（如输入空格或与已存在内容相冲突的数据等）输入数据的长度
（如只能输入 8 位， 分别输入 7、 8、 9 位数据进行测试）
输入数据的类型
（如只能输入数字， 分别输入汉字、 字母、 特殊符号等）
输入数据的格式
（如‘yyyy/mm/dd’ ）
7.2 显示数据
● 显示内容是否正确？
● 内容太长， 文本框不能完全显示时， 是否有未完全显
示的提示？如加‘…’
● 显示内容格式是否正确？
7.3 根据文本框状态
可编辑文本框与不可编辑文本框是否易于区分？（一般将不可编辑文本框置灰）
光标选中的可编辑文本框是否有明显显示？（如文本框底色由白色变为蓝色）
【注意】 对于在文本框中输入的错误数据， 程序一般有以下 3 种处理方式：
● 不允许输入， 没有任何提示。
● 输入后立即给出提示要求重新输入。
● 单击窗体中的‘确定’ 或‘保存’ 或‘提交’ 按钮以后， 程序再检验数据的正确性， 不正确就给出提示
要求重新输入。在设计文档中没有特别注明需采用哪种处理方式时， 无论哪种方式， 只要能正确验证数据就
可以。
4 举例说明：略
8、 Up-down 控件文本框
1 作用：通过控件的上下箭头， 选择不同的值。
2 状态：可用、 不可用。
3 测试点：
3.1 直接输入或上下箭头选择；
3.2 边界值
3.3 默认值
3.4 输入非法数据
3.5 若该控件不可用， 是否有标识？且是否真的不可用？
4 举例说明：略
9、 组合列表框（下拉列表框）
1 作用：下拉列表中显示一组数据， 选中某一条数据， 该数据就返回到框中。
2 状态：可用、 不可用。
3 测试点：
3.1 条目内容是否正确？（根据需求说明书确定其内容）
3.2 条目功能是否实现？（有些程序要求在获得条目内容的同时， 获得该条目对应的编号， 但是编号在窗
体上不显示， 此时就要在数据库中查看结果是否正确？）
3.3 是否能输入数据？（一般程序不允许输入数据。）
3.4 若该控件不可用， 是否有标识？且是否真的不可用？
4 举例说明：略
10、 列表框
1 作用：列表框中显示一组数据， 选中某一条/或某几条数据， 程
序进行某种处理。2 状态：可用、 不可用。
3 测试点：
3.1 条目内容是否正确？（根据需求说明书确定其内容）
3.2 条目功能是否实现？
3.3 滚动条是否可以滚动？（针对列表框内容较多时）
3.4 条目内容宽度超过列表框的宽度时， 鼠标指针位于该条目
时是否可以完整显示？
3.5 是否允许多选？（若允许， 要分别检查按 Shift 选中、 按
Ctrl 选中条目和直接用鼠标选中多项条目时的情况。）
3.6 若该控件不可用， 是否有标识？且是否真的不可用？
4 举例说明：略
11、 命令按钮
1 作用：实现规定的功能。
2 状态：可用、 不可用。
3 测试点：
3.1 可操作按钮功能是否实现？
3.2 对可能造成数据无法恢复的操作是否提供确认信息？（如
删除等操作）
3.3 对不符合业务要求的输入数据是否有相应的处理方法？
3.4 对非法的输入或操作是否给出足够的提示说明， 让用户明白错误出处？
3.5 若该按钮不可用， 是否有标识？且是否真的不可用？
4 举例说明：略
12、 单选按钮（单选框）
1 作用：同一组中只能选择一个。
2 状态：可选（被选中、 不被选中） 、 不可选。
3 测试点：
3.1 同一组中， 是否只能选中一个？
3.2 各项功能是否能正确完成？
3.3 是否有默认被选中的选项？
3.4 可选和不可选项是否易于区分？（一般将不可选项置灰）
3.5 不可选项是否限制不能被选中？
4 举例说明：
如性别组的单选按钮， 可选项包括：男、 女、 未说明， 默认为男。
13、 复选框
1 作用：可同时选中多项。
2 状态：可选（选中、 未被选中） 、 不可选。
3 测试点：
3.1 是否可以同时全部选中？
3.2 是否可以同时部分选中？
3.3 是否可以都不选中？
3.4 各种选中情况下功能的实现？
3.5 是否有默认被选中的选项？
3.6 可选和不可选项是否易于区分？（一般将不可选项置灰）
3.7 不可选项是否限制不能被选中？
4 举例说明：略。
14、 滚动条
1 作用：在较多内容情况下， 可以通过拖动显示内容。2 测试点：
2.1 是否能被拖动？
2.2 拖动滚动条时， 屏幕的刷新情况？（是否能及时刷新？是
否有乱码？）
2.3 拖动滚动条时， 信息的显示情况？
2.4 滚动条的上下按钮是否可用？
2.5 滚动条的大小是否会根据显示信息的长、 宽度及时变换？
2.6 滚动条的位置是否能根据选中内容的位置及时移动？
2.7 是否能用鼠标滚轮控制滚动条？
3 举例说明：略
15、 各种控件混合使用时的测试
1 控件间的相互作用。
2 Tab 键的顺序。（一般是从上到下， 从左到右。）
3 热键的使用。
4 Enter 键和 ESC 键的使用。
5 控件组合后功能的实现。
【注意】 测试过程中， 应遵循由简到繁的原则， 先进行单个控件功能的测试，
确保实现无误后， 再进行多个控件的功能组合的测试。
44如何测试一个 纸杯？
参考答案：
测试项目：杯子 需求测试：查看杯子使用说明书 界面测试：查看杯子外观 功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌 抗破坏性：杯子从不同高度落下的损坏程度 可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用 用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等 压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损 震动测试：杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输 测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法 期望输出：该期望输出需查阅国标、行标以及使用用户的需求 说明书测试：检查说明书书写准确性
