一.阐述安装程序的测试要点
1）软件在不同操作系统下安装是否正常。
2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3）软件安装各个选项的组合是否符合概要设计说明
4)）软件安装向导的UI测试
5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7）安装空间不足时是否有相应提示
8）安装后没有生成多余的目录结构和文件
9）对于需要通过网络验证之类的安装，在断网情况下尝试一下
10）还需要对安装手册进行测试，依照安装手册是否能顺利安装
二.阐述程序界面中如下类型控件的测试要点（姓名，年龄，email，身份证号，密码）
姓名输入框：
1、重复
2、长度：例如支持100字符， 那需要测试100字符、101字符、100字符后输入一个汉字的情况， 最大长度的显示是否正常
3、哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符（tab 回车键是否支持）
4、是否支持多行，保存是否成功，显示是否按输入的多行显示
5、字符中带有HTML标记对时，显示是否正常
6、字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
7、最大长度显示是否正常
8、全角半角的字母、数字
9、字符串中带JS标记对， 比如
10、复制功能是否可用
11、粘贴功能是否可用、粘贴超过最大长度的字符串怎么显示？
12、多浏览器的兼容性
年龄下拉框：
1)默认值(为空，提示选择，某一值)检查；
2)列表内容，是可变还是固定的，可变的最好要用SQL或其他方式验证正确性，不允许出现重复值；
3)列表中的排序方式，特别是选项过多时尤为重要；
4)列表过长是否提供滚动条支持，一般超过10个需要滚动条；
5)选择一个选项后是否可编辑，有的下拉菜单允许编辑选择，这还需要验证其合法性；
6)列表中文本的对齐方式，一般都是左对齐；
7)选择框的长度是否可变；
8)选择框的长度是否合适，是否会出现选择项后不能全部显示其内容；
9)下拉菜单获取焦点后，是否可以通过键盘操作，主要包括↑,↓,Home ,End ,PageUP ,PageDown等。
下拉菜单联动检查：
假设有A、B、C三个下拉菜单，A联动B，B联动C；这时需要检查：
1)A选择一个选项后，B下拉菜单内容应该是A中这一项所包括的所有内容；
2)选择B中的一个选项，C下拉菜单内容应该是B中这一项所包括的所有内容；
3)更改A中的内容，B，C菜单应该做相应改变；
4)更改B中内容，C菜单应做相应改变。
email：
邮箱格式：邮箱名@域名（[email protected]） 先根据常用的邮箱，总结出邮箱名的要求:
- 163网易邮箱规则
（提示信息不够全面，但是输入有误时有相应提醒）
（1）结尾形式有：@126.com @163.com @yeah.net
（2）长度：6~18个字符
（3）字符类型：字母，数字，下划线
（4）首尾限制：需字母开头，字母或数字结尾
- QQ邮箱
（提示信息不够全面，但是输入有误时有相应提醒）
（1）结尾形式有：@qq.com @foxmail.com
（2）长度：3~18个字符
（3）字符类型：英文，数字，点，减号，下划线
（4）首尾限制：需a-z的英文字母（不分大小写）开头，英文字母或数字结尾
- 新浪邮箱
（提示信息很全面）
（1）结尾形式有：@sina.com @sina.cn @vip.sina.com
（2）长度：4~16个字符
（3）字符类型：英文小写，数字，下划线
（4）首尾限制：下划线不能用在首尾
- 搜狐邮箱
（字符类型和长度提示信息简洁，但是点，减号，下划线表示形式不太美观，易懂）
（1）结尾形式有：@sohu.com
（2）长度：4~16位
（3）字符类型：英文，数字，（点），下划线，减号
（4）首尾限制：开头需为小写子字母，结尾没有限制（大小写字母，数字，点，下划线，减号均可）
- Hotmail（微软）邮箱
（字符类型和长度均没有提示，体验很差）
（1）结尾形式有：@hotmail.com outlook.com
（2）长度：没有明确表示，大概为1~65位
（3）字符类型：字母，数字，点，下划线，减号
（4）首尾限制：开头需字母，结尾可用大小写字母，数字，下划线，减号，不可用点
身份证号码输入框：
1、非1位数字（包括空格、空）
2、非X和x的字母
3、18位合法的身份证号
4、17位数字、19位数字
5、15位合法的身份证号
6、14位数字、16位数字
7、号码中含有特殊字符、中文、字母(除最后一位是X或x)、全角字符、空格
8、全部为空格
9、输入框不可粘贴复制汉字 ，数字超过 18位
密码输入框：
1、输入错误的密码是否会有提示
2、输入空格或比复合规则的内容时是否会提示
3、两次密码不相同是是否有提示
4、密码是否有长度限制
5、密码是否区分大小写
6、密码为一些简单常用字符串时，是否提示修改？如：123456
7、密码存储方式是否加密
3.假设某个系统的查询模块具有如下功能需求：通过“商品名称”，“商品类型”，“成交日期”，“付款日期” 几个条件查询所需的交易记录，请针对这个需求设计测试用例
https://blog.csdn.net/m0_46482126/article/details/104694503
四.请阐述缺陷描述的要点
测试环境：浏览器：全部/IE8，操作系统：win7 x64
测试数据：用户名，密码，相关的业务账号
重现步骤：缺陷发现的过程
缺陷等级：开发修复的顺序
缺陷说明：告诉开发，你所认为的缺陷是什么，取得理解上的一致实际结果与预期结果进行比较来说明这个缺陷
截图：
1.截大一点，最好截整个桌面或整个窗口
2.尽量注意不要包含不好的信息，比如群聊窗口
3.截图中强烈建议加上文字描述缺陷的位置和说明
五.你认为一个测试工程师应具备哪些素质和技能
软件测试人员应具备的素质：
1.沟通能力
测试人员需要与很多人员进行沟通，需要不同的语气、不同的态度，与客户要谈得来，处处为客户着想，客户就是上帝，与上帝说话要和颜悦色，与开发人员交往就需要技巧了，测试人员与开发人员往往是不共戴天的，双方在心理上经常较劲，因此在说话的语气或讲述一个问题的出发点时特别要注意。
2.要有严谨、敢于承担责任、稳重的做事风格
除了做事认真仔细，也要有承担责任的勇气，在漫长的项目实施过程中，或大或小的错误在所难免，可以原谅错误，但不喜欢狡辩，要敢于承认错误。
3.具有怀疑与破坏的精神
测试人员不能总是以常规的思路来测试软件，要设计一些非常规的、相反的测试用例来不断地折磨软件产品，要破坏性地测试，并且不要停止你的怀疑。
4.善于自我总结、自我督促
测试工程师应具备的技能：
1.软件测试员的基本月标是发现软件缺陷，是做好测试的首要条件。
2.软件测试员追求的是尽可能早的找出软件缺陷。
3.软件测试人员必需确保找出的软件缺陷得以关闭。
六.问题单都有哪些属性？
BUG编号：自动生成
模块：产品的具体模块
标题：能够描述清楚的内容。建议有规律。
描述：不同的产品描述不一样。
缺陷等级：共4个等级
概率类型：3类 极少出现 偶然出现 必须出现
出现概率
状态
处理结果
优先级
指派给：不解释
提单日期：系统自动计算。提单人提出的问题的精确时刻。
要求完成日期：项目经理根据规则，或者自己的判断，填写要求完成的日期。
开始解决日期：系统自动计算。从修改为“进行中”开始。
完成日期：系统自动计算。从修改为“已解决”开始。
关单日期：系统自动计算。关闭该问题的精确时刻。
修改次数：系统自动计算
附件：上传的附件
跟踪者：不解释
提单人：自动生成。
当前软件版本号：产生问题的当前软件版本。
当前硬件版本号：产生问题的当前硬件版本。
目标版本：产品规范版本中的一个，单选。
备注:对缺陷描述的补充，如对比测试情况，用例上下联系导致因素，其他环境因素等
七.一个完整的测试方案包含哪些要素？
- 引言：目的、背景、范围、定义、参考资料
- 测试内容：测试功能清单
- 测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具
- 测试环境：硬件环境、软件环境、特定测试环境要求
- 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
- 实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件
- 风险管理
八.查看接口的工具有哪些？说出一个工具的操作
接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的测试工具是postman和jmeter，接下来就简单介绍下如何使用这两款工具进行接口测试，其他工具本次暂不介绍。
Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。
jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。
九.如何定位bug，是前端还是后端的问题，用什么工具，还是利用别的？
1、经验法
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类bug了。 例如： 网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。
2、查日志
当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析
3、查接口
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。 大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。 我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。
前端bug特点 1， 界面相关 2，布局相关 3，兼容性相关
后端bug特点 1，业务逻辑相关 2，性能相关 3，数据相关 4，安全性相关