发表于： 2019-06-04 21:51:02
2 673
今天完成的事情：
1. 完成任务一深度思考
2. 听老大直播
明天计划的事情：
1.提交任务八
2.继续任务二深度思考
3.回顾任务一知识点
遇到的问题：
1.测试用例内容好多好多啊啊啊啊
收获：
七、常用的Bug管理工具有哪些，互相之间有什么差别，你更喜欢哪一种，为什么？
- QC 商用
优点：功能强大，结合BUG管理，需求管理和测试用例等功能
缺点：英文版的易用性不是很好，价格高（需要安装配置IIS和数据库，系统资源消耗比较大
- Bugzilla 免费
优点：免费的开源的一款强大的BUG管理系统，比如强大的搜索功能，强大的后端数据支持，丰富多样的配置设定。
缺点：安装配置麻烦
- 禅道 商用但是有免费版本
优点：基于WEB,开源、免费，安装配置简单。
缺点：没有直接的截图功能，以附件形式保存。（禅道偏向项目管理，包括：产品管理、项目管理、质量管理、文档管理等，测试功能只存放在质量管理中，测试只是禅道的部分功能）
4. Mantis 免费
优点：基于web，开源，报表功能强大，
缺点：英文版，可以通过汉化包和配置来汉化，有邮件支持但也需要修改配置，没有直接截图功能
5. Jira 商用
优点：基于WEB，功能强大，能够内部及时交流，跟踪任务、bug，通过JIRA的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多。（不限制用户数！不限制创建项目数和Issue的数量！一年内免费更新版本
缺点：无法直接管理测试用例
6. Gitlab 免费
优点： Gitlab管理bug，可以跟项目绑定，特别方便管理bug，随时assign给相关开发，也可以看到开发提交bug时的Commits，每次发版可以对照相关提交，既方便测试，也可以在出现问题时找到对应开发。
缺点：大型安装和配置上存在一些速度或性能问题
八、为什么要区分开发，测试，线上三个环境，三个环境之间的区别是什么？分别由谁来主导？
开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。
测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
生产环境：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。
区分的原因：
第一，开发人员往往没有办法测试出自己写的代码的问题。
第二，测试环境通常需要一个稳定的环境，不允许随时更改和发布，而开发环境通常每天会发布四五次还要多。
没有高低，谁来主导之分，完成一个阶段开启下一阶段。
区分模式的优势：
- 开发模式自动reload代码，但是偶尔仍然需要手动reload
- 某些模式多加载一些gem，比如debugger在开发环境，rspec在测试环境，或者unicorn在生产模式
- 使用不同的数据库配置，比如测试环境会每次测试完成清理数据库，生产环境也不推荐随便migrate
九、什么是版本回滚，在发布上线的过程中，如果发布不成功，多久之内应该要回滚，谁来决定，原因是什么？
回滚到上一阶段没有BUG的版本。
测试发现BUG，提交至老板那，判断是否回滚。
不影响用户使用不回滚，功能性问题需求回滚。
十、什么样的Bug是允许上线的，什么样的Bug是不允许上线的？
首先要了解BUG的优先级：
critical
block
major
normal
minor
Critical:最严重，系统崩溃，完全不可用。
Block：用户操作卡住，无法进行下一步
Major：BUG的分界线，关键业务逻辑走不通。
Normal：不太重要的功能出现BUG，可以在上线后解决
Minor：不重要的BUG，如兼容性、字体问题
以Major作为bug体系的分界线，通常而言，有Major以上的Bug是不允许上线的-都跑不通流程，你发布上线干嘛呢？如果出现major，开发人员应立即停掉手上项目开发，第一时间修复Major bug，并提交到测试环境。
系统是否能上线非常重要的一个依据就是，是否还存在major级别以上的bug，如果存在，能否先把这个模块去掉，先去上线没有问题的模块。
十一、Bug的优先级是什么？一般会分成几个级别，分别对应什么含义？
bug级别
严重程度由高到低依次为：
1.critical
2.block
3.major
4.normal
5.minor
critical：
系统直接崩溃，瘫痪。所有人员无法正常打开产品进行使用。
block：
逻辑出现严重问题，流程卡住，无法进行下一步。
major：
部分功能出现闪退，功能没有实现，但是不影响使用，功能菜单缺失
（一般demo结束之后，功能错误或者数据错误，重要的需求优化我们会提该级别bug，需求优化我们会注明是需求优化。不会影响系统稳定）
normal：
产品可以满足业务要求，部分小限制不符合验收标准，内容显示错误。界面主流浏览器（根据PM定）的兼容性。
minor：
界面等UI问题显示错误，比如字体大小，颜色，间距等问题，性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
十二、Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？
生命周期就是指在Bug管理工具中,我们记录下来的一个Bug被创建,指派,修复,复查,关闭的过程.生命周期就是要讲清楚,Bug应该有哪些状态,分别是由谁去触发,参与的角色又是谁.
新建
指派
接受
修复
关闭
确认修复后验证，测试环境的BUG就在测试环境完成验证
线上环境的BUG，第一时间看测试环境能否重现，如果可以重现就在测试环境验证，如果不能重现就在线上完成。
如果验证的时候不通过，改成Reopen,重新打开，验证通过则Close
十三、什么是测试用例，为什么要写测试用例，测试用例中的前置条件是什么？预期结果是什么？一个登录注册的小模块，正常来讲，应该有多少个测试用例？
一个完整的开发流程，从提需求、开发、交付，测试用例用来判断已经完成整个过程。
前置条件：比如密码登录，前置条件时账户密码同时输入正确才能登录成功
预期结果：登录成功。
功能测试(Function Test)
1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）
2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
3、登录成功后能否跳转到正确的页面（低）
4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
6、记住账号的功能
7、登录失败后，不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示（星号圆点等）
10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确
12、输入密码的时候，大写键盘开启的时候要有提示信息。
13、什么都不输入，点击提交按钮，看提示信息。（非空检查）
界面测试(UI Test)
1、布局是否合理，2个Testbox 和一个按钮是否对齐
2、Testbox和按钮的长度，高度是否复合要求
3、界面的设计风格是否与UI的设计风格统一
4、界面中的文字简洁易懂，没有错别字。
性能测试(Performance Test)
1、打开登录页面，需要几秒
2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒
安全性测试(Security Test)
1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)
2、账号和密码是否通过加密的方式，发送给Web服务器
3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证
4、账号和密码的输入框，应该屏蔽SQL注入攻击
5、账号和密码的的输入框，应该禁止输入脚本（防止XSS攻击）
6、错误登录的次数限制（防止暴力破解）
7、考虑是否支持多用户在同一机器上登录；
8、考虑一用户在多台机器上登录
可用性测试(Usability Test)
1、是否可以全用键盘操作，是否有快捷键
2、输入账号，密码后按回车，是否可以登录
3、输入框是否可以以Tab键切换
兼容性测试（Compatibility Test）
1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）
2、不同的平台是否能正常工作，比如Windows, Mac
3、移动设备上是否正常工作，比如iPhone, Android
4、不同的分辨率
本地化测试 （Localization Test）
1、不同语言环境下，页面的显示是否正确。
软件辅助性测试 （Accessibility Test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
1、高对比度下能否显示正常（视力不好的人使用）
1.填写符合要求的数据注册：用户名字和密码都是最大长度(边界值分析)
2.填写符合要求的数据注册：用户名字和密码都是最小长度(边界值分析)
3.填写符合要求的数据注册：用户名字和密码都非最大和最小的数据(边界值分析，取内点)
4.必填项为空注册
5.用户名长度大于要求注册1位(边界值分析)
6.用户名长度小于要求注册1位(边界值分析)
7.密码长度大于要求注册1位(边界值分析，取离点)
8.密码长度小于要求注册1位(边界值分析)
9.用户名是不是符合要求的字符注册(划分几个无效的等价类，如是否有#，空格，等
10.密码是不是符合要求的字符注册(划分无效等价类)
11.俩次输入密码不一致(可以划分几个无效等价类)
12.重新注册存在的用户
13.改变存在的用户的用户名和密码的大小写，来注册
14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否有加密号等
二 、修改密码：
具体情况.具体分析。比如银行卡密码不用考虑非法输入和英文字母输入。也不用考虑tap键
1.不能输入旧密码，直接改密码
2.输入错误旧密码
3.不输入确认新密码
4.不输入新密码
5.新密码和确认新密码不一致
6.新密码中有空格
7.新密码为空
8.新密码为符合要求的最多字符
9.新密码为符合要求的最少字符
10.新密码为符合要求的非最多最少字符(取中间值)
11.新密码为最少字符-1
12.新密码为最少字符+1
13.新密码为最多字符-1
14.新密码为最多字符+1
15.新密码为非允许字符(如有的密码要求必须是英文和数字组成.那么要试汉字字符等)
16.看是否支持tap和enter键；密码是否可以复制和粘贴;密码是否以*进行加密
17.看密码是否区分大小写，新密码中英文小写，确认密码中英之大写
18.新密码和旧密码一样能否修改成功，另外一些其他想法如下:
A:要测试所有规约中约定可以输入的特殊字符，字母和数字，要求都可以正常输入，显示正常和添加正常
B:关注规约中的各种限制，比如长度，是否支持大小写
C:考虑各种特殊情况，比如添加同名同户，系统是否正确校验给出提示信息
D:数字上的长度之类的，包括出错信息是否合理
E:特殊字符:比如: / ' " 等是否会崩溃
F:注入式BUG.比如密码输入or 1 = 1
十四、什么是产品经理
产品经理是发现问题、提出需求，找到用户体验与商业目标的平衡点，并且能够解决问题的人。
返回列表
评论