big一 问题之三

之三"/>

big一 问题之三

测试环境怎么搭建的？

jdk、mysql 数据库、Tomcat、navicat、谷歌浏览器
接口测试工具： postman
性能测试工具： jmeter
bug管理工具： 禅道
badboy（web端录制工具，生成。jmx文件）、charles抓包工具
自动化的话：用的是python开发工具，pycharm

偶然性问题的处理

一、一定要提交!!
二、程序不是测试人员写的，出问题也不是测试人员的原因。
三、下次再遇到的时候，拉他们来看就可以了。
四、你可以告诉程序员，测试过程是没有错误的。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

参考文档：
.html

二八定理

80%的bug出现在20%的代码（模块）中

在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出 其余缺陷中的80%，最后的4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。

如何跟踪缺陷？

bug管理工具（禅道）、bug等级、bug严重程度、bug状态、缺陷报告的编写

缺陷单应该包含这些要素

缺陷ID、缺陷描述、所属模块、用例ID、缺陷名称、bug等级、bug严重程度、bug状态、提交人、解决人、提交时间、解决时间、备注、版本号

测试报告的主要内容

一、概述
包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程
评审记录、测试范围、测试用例

四、功能实现清单
列出是否已经按照测试计划实现功能

五、缺陷统计
测试缺陷统计；
测试用例执行情况统计

六、测试统计情况
资源统计
执行情况
问题统计
问题列表
遗留的问题

七、测试总结

测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度
八、测试风险

如何定位bug？

1、用户层面： 检查host、使用环境ping 或操作问题（浏览器缓存、fiddler工具影响等）
指的是用户自己的环境问题或者操作问题，比如环境不通，或者操作不正确

2、web页面样式------观察样式是否与需求一致

3、F12----查看状态码

​ 4XX 客户端问题， 比如发生了401，那么要看下是否带了正确的身份验证信息；发生了403则要看下是否 有权限访问；404则要看下对应的URL是否真实存在；

​ 5xx服务端出现问题（配合服务器log进行定位，发生了502错误则可能是服务器挂了导致的问题、发生503 错误可能是由于网络过载导致的问题、发生504错误则可能是程序执行时间过长导致超时。

4、查看服务器日志----发生5XX问题，检查后端接口执行的sql是否正确，tomcat日志

5、检查接口请求、返回参数----点击Response标签将标签内的内容复制出来，问了更好的查看可以将其粘贴到格式化json的工具上（如果返回类型是json）工具地址：/，然后查看这里面展示的记录数是不是跟UI上展示的一致，如果不一致可以判断是前端的Bug

6、查看需求文档----前端和服务器交互正确，但从测试角度看不合理，查看需求文档， 前端只负责渲染展示，后端负责业务逻辑处理；

7、检查配置----不是代码问题，则检查tamcat、nginx配置，版本

ps：定位完bug后 再次确认bug—是否必现，是否概率性，是否是浏览器兼容问题；

​ 如果实在定位不出来，就交给开发，不要浪费太多时间；

8、是数据库。代码没有问题，不代表软件没有问题。数据库层面也可能会有各种各样的问题，比如字段的约束问题等等。假如一个文本框的前端校验和接口校验的文本长度最大是50，但数据表字段设定的是varchar(30)，那么在存数据的时候肯定会报错。再比如之前发现一个数据库的问题，测试环境没有，到线上却有了，那么也可以看下是不是数据库版本不同导致的。

9、中间件

开发没时间修复，如何推进bug的修复：

开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题。我们逐条分析解决方案

1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点

a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性

b) 可以和开发人员列举一个之前的类似问题，为开发提供参考

c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改

3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案

4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题

作者：呀呼呼呼
链接：
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

对一支圆珠笔进行测试，要从哪些方面进行测试？

1.功能测试：圆珠笔按下是否能正常书写。

2.性能测试：笔芯弹出弹回的快慢。

3.负载测试：连续按，看弹簧能经受多少次伸缩。

4.兼容性测试：看是否可以使用其他笔芯。

5.强度测试：用力过度会有什么影响

6.可恢复性测试：长时间按住弹簧，松开后看弹簧是否可以恢复

7.界面测试：笔的外观，舒适度

8.安全性测试：是否会对使用者造成伤害

三角形测试用例设计

1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

2、若是等腰三角形打印“等腰三角形”，若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

3、若是等边三角形，则打印：“等边三角形”。

4、画出程序流程图并设计一个测试用例。

1、构成三角形的条件：任意两边之和大于第三边；

2、构成等腰三角形的条件：任意两边相等；

3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

4、构成等边三角形的条件：三条边都相等。

在项目中发现哪些经典bug？什么原因导致的？

第一，出现这个bug,可以判断研发在最后保存数据时,并没有对数据的有效性进行判断,而是在相关控件进行操作时进行判断的.这样风险有点大,因为控件之间对数据也会有影响,如果仅在操作控件时判断，会产生问题.

第二，这种脏数据虽然不会在视图展示，但保存在服务器上,在各个平台上均会进行同步.这还需要保证其他平台对于脏数据进行处理，且不会出现问题.风险较大.

基于这两个原因，研发还是解决了这个问题.这对我还是有一定启发的.

看问题可能会更考虑多方面的影响.不单纯只是现象.

一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

在需求文档不太详细的情况下，如何开展测试：
软件生命周期中，需求是整个项目的源头。俗话说良好的开端是成功的一半，但是，不是每个项目都能遵从流程，花太多时间在需求分析上，而把精力投入到代码的编写中。这可能导致什么问题呢？开发和测试对需求理解都不充分，开发出来的功能与实际需求不符，测试要么凭自己的经验一步一步发掘潜藏的功能点，把项目往良性的轨道上引，要么就听从开发的脚步，亦步亦趋。那么测试人员要如何在需求不明确或者文档不全的情况下着手测试才能保证软件的质量呢？

一、参考同类型的网站：一般情况下，我们测的系统总会有原型可参考，比如我目前测的订票系统，就可以参照携程，主要功能基本一样，细节可能有出入，携程上操作一遍，然后再看看它提供的帮助，再有可以网上搜索资料，参考下行业的基础知识，这都是收集需求的方法，这样子下来也基本对订票系统也就有个认识了，然后与开发经理确认，再和开发一起把功能定下来，该改的改，该修的修，BUG一点不含糊。弱弱的吐槽下，这个项目的开发居然都不知道有需求说明书，虽然写的基本没太大的价值。

二、根据经验和常识判断：做项目多了就知道，万变不离其宗，系统不一样，思路可以套用，所谓的学以致用，举一反三。我上个项目做的银行测试，我照样可以测现在的订票系统，就在一个字：活。有需求照需求测，没有需求找参照，说个例子吧，订票系统中有个功能是积分，需求上就一句话提到有积分功能，怎么测？难道看到有这个功能就算过了？我后来就参照了淘宝的积分抵扣，下单了积分就被临时冻结了，取消订单又释放出来，但开发在做这个功能的时候也没有跟他们的头沟通，直接是要等支付完成后才扣除积分，这导致一个什么问题呢，可以重复使用积分，如果真上线使用了，说不定会造成不小的经济损失的。类似这样的问题太多太多，你总可以从一些地方获得参照，或者说是灵感，项目测的怎么样，跟测试人员的素养有很大的关系，尤其是在没有规范的流程下。

三、沟通：毋庸置疑，这太重要了，需求不一定在文档中写出来，但道理上开发肯定知道需求的，但一般不会主动和测试沟通，因此，我们作为测试就要主动和开发人员沟通，不仅可以对系统有更深的了解，还可以对项目进度有把握。

四、多和同事讨论

如何尽快找到软件中的bug?

尽快熟悉公司的产品业务

根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

把自己当成是用户

把自己当成用户去使用该软件，比如在试用软件的过程中，思考用户是这样操作的么；

2.1 比如大量要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入，此时正确的接口应该是从左到右，从上到下的顺序。

2.2 比如有的用户喜欢使用快捷键进行操作（Ctrl+C），但是实际情况下一些开发出来的软件的快捷键根本不起作用。

2.3 比如软件在需要用户输入信息的时候（特别是在填写个人资料的时候），必填选项后面一律要用*等醒目的表示要让知道这个地方必须要填写。

2.4 下拉框不选的时候，应该有个默认值，并且要多检查程序中的多处下拉框，因为很多情况下下拉框取不到值。

善于怀疑

世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生；别人认为是对的，我却认为是错的。假如一个水平很高的程序员编写的程序，不要有“他写的这个程序应该没有问题吧”这种想法，这样很容以遗漏软件中的Bug。

不用让程序开发员“用户不会这样操作”的观点说服自己

遇到这样的情况，你要坚持自己的正确的观点，把这种现象作为一个Bug。

在测试的过程中要跟踪一条数据的完整流程。

比如“点击商品—收藏商品—加入购物车—订单结算—付款—消费二维码—消费—二维码失效”，如果在测试软件过程中业务流程逻辑都走不通的话，还么这个软件测试与不测试就没有什么区别的。

回归测试要注意的事项

程序员提交新的版本后，作为测试人员应该立即与程序员沟通这个修改的功能，并了解这个新修改的功能影响那些功能。而被影响的功能，是在回归测试中优先重点测试的地方，而且也是最容易产生Bug的地方。

与使用者互动的缺陷

7.1 如填写资料错误的时候，应该能够提示错误的位置，让用户知道这个地方输入的数据不对；

7.2 删除数据前一定要给定出是否删除的确认提示；

7.3 不要在软件中使用中英文混合的提示：比如对于用户在进行某个操作的错误提示，不要一会用“Error”，一会又用“错误”，一定要统一；

7.4 要对程序员的错别字进行检查，比如吧“登录”写成“登陆”；

7.5 在软件中不要对用户使用很专业的术语；

7.6 新增/修改信息白村提交后系统给出“保存/提交/修改成功”的提示信息，并自动更新显示；

7.7 在用户进行大量的输入后，点击保存按钮，仅仅是因为某个地方输入选择不正确，点击确定后所有的输入信息都被清空了，这样的Bug会大大降低软件的易用性；

7.8 对于软件的查询功能，测试的时候设置开始时间>结束时间，看看能否查询出记录；

软件的边界值

众所周知软件最容易在边界值上出现问题，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空的情况；

非法容错性

比如在需要输入数字的地方输入字母，在需要输入字母的地方输入数字，在需要用户输入的文本框中拷贝字数很多的整编文章到这里测试看看软件是如何做处理的；

软件接口测试

如果软件不同部部分是由不同程序员共同完成的，那么要在他们程序接口相关联的地方多检查，避免双方程序员互相认为做了接口处理，最后谁也没有做接口的处理，导致软件在运行中产生缺陷；

兼容性测试

软件测试要在不同的硬件、软件下（包括操作系统、浏览器）下的测试；

11.1 硬件 有时候软件在配置很高的机器上，有时会隐瞒一些错误，由于CPU运行过快的时候，很多现象一闪而过，发现不了缺陷；

11.2 软件 有时软件在不同版本的浏览器中的界面与权限是不一样的，这样的例子就是软件中的一个Bug了；

软件在压力之下容易出错

软件在压力之下容易产生的错误，是作为一名测试人员必须要知道的事情。所以在测试过程中，将软件在压力之下长时间运行，然后看看软件是否能在压力之下正常工作；

随机测试：

即使经过大量的充分测试，也不能发现软件中的所有缺陷，所以在测试的时候可以做一些随机测试，比如胡乱在界面上乱点，有时也会发现一些意想不到的软件缺陷；

学习他人经验：

什么是bug？

1.产品说明书中规定要做的事情，而软件没有实现。

2.产品说明书中规定不要做的事情，而软件确实现了。

3.产品说明书中没有提到过的事情，而软件确实现了。

4.产品说明书中没有提到但是必须要做的事情，软件确没有实现。

软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。

注：产品说明书中没有提到但是必须要做的事情，软件确没有实现。软件实现了产品的功能，但是没有考虑软件在弱网络、低电量的情况下也能正常使用，而做出来的产品在弱网络或低电量的情况下报错，那么这也是一个bug。

ATM机吞卡的吞卡现象是不是BUG?

这个不能绝对的说BUG.应为比如说输入三次错误的密码，需求上就是需要吞卡。那这个就是正常的，不是BUG。那如果说一直没有考虑到的操作，导致了吞卡，那这个就可以定位成BUG

有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等

2、检查软件/硬件的配置是否符合软件的推荐标准

3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行

4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；

5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

你们发现bug会怎么处理？

发现BUG后，接下来你提交到BUG管理平台，提交一个BUG包含哪些内容？

BUG标题—标题要清晰简洁，写明BUG描述；如果没有选择功能模块，最好在标题中标注功能模块。让查看BUG的人员清楚知道你所表达的意思。BUG的功能模块+BUG的操作+BUG的结果

重现步骤—步骤—简单写下发现BUG的测试过程，罗列下。能指导开发重现这个BUG。附上测试数据实际结果----出项BUG的结果，粘贴BUG截图，日志截图，截图直接粘贴就可以了，不要添加附件，附件：日志、测试数据（文件）图片，比如上传头像，就把图片放在文件中当附件上传，开发要重现这个BUG，那么根据你附件的图片来重现。预期结果----记得写清楚预期

BUG类型和严重程度-----便于后续测试结果分析，BUG的统计

BUG测试环境—例如：什么系统；哪个版本等。兼容性问题、难以重现问题

附件----日志文件、文件测试数据

所有以上的如何提交BUG，参考公司前辈写的BUG，依葫芦画瓢，拓展测试思维。

测试的BUG备注修改方案和操作信息

如果写了两条一摸一样的BUG或者提交的BUG不是BUG而是操作错误，问同事怎么删除，或者是在BUG标题前面备注“需删除”，然后跟老大说，老大会批量删除。或者不删除自己编辑下其他BUG.

BUG的跟踪管理-状态处理

1.已经指派的BUG—已经指派给开发的，请大家注意自己BUG的走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记；如果已经修复等待测试环境更新后进行验证。催着改BUG

2.已解决的BUG----等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新开发指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG重复？如果确定时重复则关闭；如果不重复，说明原因，重新打开指派给开发。

4.不是缺陷----确认开发环境是否分测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并在次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致？包括操作步骤，浏览器、环境、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据BUG的严重程度跟产品，开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发。

6.不予解决—找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此—找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重现指派给开发。

8.延期修改—请看下BUG严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况进行激活与情况说明；确定延期则做好记录，后续版本进行关注。