软件测试【面试题】：软件测试理论

软件测试定义
    在规定的条件下，对程序进行操作，以发现程序的缺陷，并且对程序评估，提高软件的质量

软件测试的具备条件
    1.良好的表达沟通能力，编辑文档能力，思维逻辑能力
    2.耐心，细心，抗压能力，有责任心，有积极性
    3.独立解决问题，具有怀疑精神,持续不断的自我提高和总结能力

质量六大特性
    1.功能性 2.可靠性 3.易用性 4.效率 5.可维护性 6.可移植性

软件测试工作流程(生命周期)
    需求评审-测试计划-提取测试点-编写用例-用例评审-执行测试-提交bug-跟踪修复-回归测试-编写测试报告-产品验收-上线

工作中编写的测试文档有哪些
    测试计划、测试用例、测试报告、bug单、用户操作手册

需求评审的目的
    所有项目组成员对需求的理解达到一致，对需求进行查漏补缺

需求评审有哪些人参加
    项目组所有人员

你在需求评审上提过什么意见？
    我们当时做了一个优惠卷需求，产品讲完后，我发现没有说使用优惠券再取消订单，是否返回优惠卷

测试计划包含的内容
    项目背景，项目测试范围，测试方法/策略,测试资源（测试工具），开始和结束条件，进度安排，组织架构，测试风险（人员风险，进度风险，质量风险，需求变更）

什么时候停止测试，达到上线标准
    我们公司一般是需求覆盖率100%，用例执行率100%，轻微bug遗留率10%以下，但是基本上不遗留的，除非项目时间不够的情况下才遗留

测试用例要素有哪些
    编号，名称，优先级，前置条件，操作步骤，预期结果，备注，执行人，设计人

测试用例设计的方法
    等价类，边界值，错误推测法，判定表，场景法，花瓣分析法，因果图，正交表

如何保证测试用例覆盖率
    1.项目开始前，我们会先熟悉需求，不懂找产品了解
    2.清楚画好业务流程图，保证整个流程都覆盖全面
    3.考虑各种正常和异常场景，防止之后编写测试用例时出现遗漏
    4.使用各种用例方法进行用例的编写
    5.用例编写完之后，再进行用例的评审

用例评审有哪些人参加
    一般是测试，开发，产品参加即可

用例评审的作用
    为了保证测试人员是否对需求理解错误，或者场景覆盖不全面

执行测试会遇到哪些问题
    1.开发认为不是bug
    2.测试时间不够
    3.需求变更

需求变更如何处理
    1.需求变动是大还是小，如果大，需求跟上级反馈问题，如果小，修改用例直接测试
    2.加班处理完
    3.执行高级别的用例
    4.调配人手    

开发压缩了测试的时间，怎么处理？
    1.当前版本测试加班完成测试
    2.测试完成后主动开会说明测试时间不够，会造成质量问题，上线存在风险
    3.建议开发在技术评审时，评估好开发时间

开发做出来的产品和需求不一致，怎么处理
    1.第一时间告诉产品，让产品做决定

测试时间不够，如何完成测试？
    1.第一时间和上级汇报情况，时间不够，可能存在风险
    2.列出任务的优先级，先把优先级高的完成，再完成优先级低的
    3.定期和上级汇报完成情况，该加班就加班，或者申请找其他人协助

管理bug的工具有哪些
    禅道、tapd、jira

一个bug的属性有哪些
    bug标题、所属模块、优先级、严重级别、操作步骤、预期结果、实际结果、有关日志和截图

如何提一个好的bug
    bug的要素要齐全，同上

bug的状态有哪些
    激活，确认，已解决，关闭

如果有一个严重bug没处理，是否能上线？
    不能，和开发说明bug上线后造成的严重性，加班解决

如果遇到解决不了bug，如何处理？
    1.评估bug严重程度
    2.严重找公司大牛尝试解决，不行就找产品或项目经理决定
    3.轻微的话，跟产品说明情况，留到下个版本解决，并记录在测试报告中

开发认为不是bug，你认为是bug，如何处理？
    1.测试人员自己检查是不是提的bug不是bug
    2.分析bug是不是产品需求问题导致的，是的话找产品一起沟通
    3.最后由产品决定是改还是不改

开发不修复bug，如何处理？
    先分析
        1.是不是自己提的bug不是bug
        2.开发本地bug无法复现，不愿意改
            如果测试环境有问题，拉着开发人员过来对比
        3.bug操作步骤多，比较负责，开发不愿意修改
            1.靠个人魅力，平时多和开发打好关系
            2.站在用户角度和开发沟通，说明上线后可能会造成什么后果，尝试说服开发
            3.找产品确认，说明情况以及出现的后果，让产品做决定或者和产品一起说服开发
        4.临近上线了，bug发现的太晚了，来不及修复了
            1.评估bug的严重性
            2.比较严重一定要解决，可以加班或者延迟上线
            3.一般或者轻微bug，让产品确定
        5.涉及到框架的修改，修改成本太高了
            1.寻找公司其他技术大牛，看是否有解决办法
            2.把可能出现的风险列给产品，由产品决定

难以复现的bug如何处理？
    0.收集bug的相关信息，记录下来提交到禅道
    1.尽量复现，从多个角度复现，回忆之前的操作步骤，结合截图和日志找开发帮忙复现
    2.不能复现，评估bug的严重级别，比较低的话，提交bug跟踪，三个版本不出现关闭
    3.bug比较严重，反馈给上级之外，写到测试报告中，说明现象，但无法再现
    备注：偶然性bug测试是尽力重现问题，而不是必须重现!!

线上出现了bug如何处理？
    1.测试人员在测试环境复现问题后，提交问题单进行跟踪；
    2.评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能
    3问题修复后，先在测试环境上回归，然后再在生产环境进行回归测试
    4、总结经验，分析问题发生的原因，避免下次出现同样问题。

出现的漏测怎么办
    1.先复现问题，提交bug,及时解决bug，以免对公司造成更多的损失
    2.将问题公开化，找出漏测的原因
    3.总结本次出现情况，避险下次再出现

测试报告包含哪些内容
    bug数据，用例执行情况，人力投入，遗留bug情况，测试风险，测试对象评估，测试结论和总结

软件测试工作流程如何优化
    1.提测前让开发拿着测试编写用例进行自测
    2.上线后开上线盘点会议

没有需求文档，如何进行测试?
    1.找产品熟悉确认需求
    2.把当前项目当做原型图，对项目进行熟悉和提取测试点
    3.找开发了解，一边写用例一边确认需求
    4.参考市场的竞品

测试环境没问题，线上出现问题什么原因
    1.用例覆盖度不够
    2.测试环境数据问题(测试环境和生产数据不一样)
    3.开发上线前修改了代码
    4.生产环境数据库未更新
    解决：搞个预发布环境