测试商城的时候一般会有什么bug
『壹』 软件测试提交bug时包括哪些内容
1、Bug的标题（Title）和详细描述（Descriptions）:
标题主要是对你所提交的Bug进行简明扼要的描述；
详细描述是对Bug进行进一步详细的描述，例如在什么情况下发生等；也可以直接将标题作为描述部分（简短明了时可以）。
两者都是为了让查看Bug的人员很清楚的知道你所表达的意思。
2、回归（Regression）：
这一部分主要是测试一下前一个版本有没有此类bug（称为回归测试）。
3、Bug测试环境（Environment）：
在什么环境中发现的这个bug，例如：什么系统，哪个版本等。对于bug环境的描述可以通过简单的罗列即可（精简为主）。
4、复现的详细步骤（Repro Steps）：
这一步主要是让你将自己在测试的过程简单的写一下，从你开始测试软件的最开始到你发现bug的时刻为止（简单的说就是你的测试过程一步步罗列下）。
5、实际结果（Actual Results）和预期结果（Expected Results）：
实际结果就是你在测试软件的过程中，软件所表现出来的特征或者行为；
预期结果就是软件需要设计所要求达到的结果或者目标。
6、备注（Notes）:
这一部分主要是对bug的一些补充，例如：其它系统也发生，上个版本不发生等需要补充的内容。
7、当然，还有很多内容。例如bug的严重等级、优先等级等。针对不一样的Bug提交系统，做出相应的Bug提交内容即可。
1、订单列表是否规范；
2、购买者信息是否有限定要求；
3、限定条件购买是否符合预设要求。
这个要根据情况看，是综合型的还是单一产品的购物网站而定
『叁』 测试过程中有没有比较有意思的bug
灵魂猎者只对仇恨在自己的怪有效
就是说组队的时候，虽然面板是加的，不过对于仇恨在队友身上的怪伤害没有加成
单刷就不用担心仇恨bug了
『肆』 在测试/开发过程中遇到过哪些印象深刻的bug
目前在测试日历,支持多(Android,iOS,web,PC)同步.遇见一个bug,有某些复杂操作下,可以创建一个开始时间专比属结束时间晚的日程,界面中无任何显示,研发考虑不解决.提bug的测试也觉得可以不解决.
但我反对了.基于两个方面,
第一,出现这个bug,可以判断研发在最后保存数据时,并没有对数据的有效性进行判断.而是在相关控件进行操作时进行判断的.这样风险有点大,因为控件之间对数据也会有影响,如果仅在操作控件时判断,会产生问题.
第二,这种脏数据虽然不会在视图展示,但保存在服务器上,在各个上均会进行同步.这还需要保证其他对于脏数据进行处理,且不会出现问题.风险较大.
基于这两个原因,研发还是解决了这个问题.这对我还是有一定启发的.
看问题可能会更考虑多方面的影响.不单纯只是现象.
『伍』 软件测试中bug的种类有哪几种bug的易用性是什么
bug分为男/女/男同/女同程序员设计模块后在运行时产生的bug.
bug的易用性是指一个有目的的设计良好的bug,可以被人认为是正常的bug而不被打死,而且自己回头处理非常快速,还可以带来加班后的加班费.
『陆』 软件测试的流程是什么bug具体是什么怎么提交
软件测试工作流程：
1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。
2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。
3、编写测试用例、用例评审测试用例就是指导测试的文档，比如我们要测试商城登录、买东西等功能，通过测试方法和策略设计测试用例。评审就是评价审查，不能想当然该怎么测。不能只是输入正确的用户名和密码，能登录进去就完事了。
作为软测工程师需要有破坏性，比如密码输错时怎么办，会不会有相应的报错等等。
4、执行测试、提交bug、回归测试Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。
5、编写测试总结报告Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。
Bug的标题和详细描述:
标题主要是对你所提交的Bug进行简明扼要的描述；
详细描述是对Bug进行进一步详细的描述，例如在什么情况下发生等；也可以直接将标题作为描述部分。
两者都是为了让查看Bug的人员很清楚的知道你所表达的意思。
Bug测试环境：
在什么环境中发现的这个bug，例如：什么系统，哪个版本等。对于bug环境的描述可以通过简单的罗列即可（精简为主）
(6)测试商城的时候一般会有什么bug扩展阅读：
软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。
对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。
『柒』 软件测试完后，还有BUG，是测试人员的问题吗
大部分可以说是测试人员的问题，因为你已经是测试完成了，为嘛会有bug呢？要回仔细去分析答出现这些bug的原因是啥？1）如果是自己测试不仔细没有考虑到这个测试点导致的，那么就是你的问题 2）如果是因为测试环境没有问题，但是到了线上就有问题了，那么就可能要去看看是否是环境配置问题导致的，也许是开发或者是运维的问题。 但是无论是谁的问题，最后背锅的肯定是你。所以做测试，背锅一次，就要学习经验一次，让自己更好更优秀！
『捌』 软件测试BUG的判断依据有那些
1、查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础回，才能更好地答定位问题。
2、查看数据库的数据，了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
3、查看缓存（如Memcache、apc、redis等缓存）是否正确。
(8)测试商城的时候一般会有什么bug扩展阅读：
快速发现bug方法
1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。
2、不用让程序开发员＂用户不会这样操作＂的观点说服自己，遇到这样的情况，要坚持自己的正确的观点，把这种现象作为一个Bug。
『玖』 测试时遇到的印象深刻的bug是什么
目前来在测试日历软件,支持源多平台(Android,iOS,web,PC)同步.遇见一个bug,有某些复杂操作下,可以创建一个开始时间比结束时间晚的日程,界面中无任何显示,研发考虑不解决.提bug的测试也觉得可以不解决.
但我反对了.基于两个方面,
第一,出现这个bug,可以判断研发在最后保存数据时,并没有对数据的有效性进行判断.而是在相关控件进行操作时进行判断的.这样风险有点大,因为控件之间对数据也会有影响,如果仅在操作控件时判断,会产生问题.
第二,这种脏数据虽然不会在视图展示,但保存在服务器上,在各个平台上均会进行同步.这还需要保证其他平台对于脏数据进行处理,且不会出现问题.风险较大.
基于这两个原因,研发还是解决了这个问题.这对我还是有一定启发的.
看问题可能会更考虑多方面的影响.不单纯只是现象.
『拾』 软件测试中bug数量一般为多少
这个是不会有来一个明确的定义的自
也没定义说一个产品测试出多少BUG之后就发布了
所以按照BUG数量来判断产品是不对的
一般产品发布公司都有要求
比如：严重等级的BUG必须修正、影响用户使用的BUG必须修正
但是有一些是是很难复现的、你在测试中发现了BUG但是却不能复现出来、或者是有的BUG能复现
但是项目组讨论却认为不一定要修改。
我现在的这个产品、我在做第一个版本的是有2000多个BUG
之后在做第二个版本的时候只有100个左右、第三个的版本时候有70多个
现在已经更新到第五个版本了也都差不多是70个左右