一、怎么测电梯？
确定测试范围，如下：
1、功能：关注电梯的基本功能是否实现
2、性能：关注电梯的性能指标，如最大负重多少kg
3、安全性：关注电梯的安全性，如超重报警，下坠制动
4、用户体验：关注电梯的舒适性
5、效率：关注电梯控制逻辑的内部算法
6、接口：电梯和电梯控制器，电梯和大楼，电梯和摄像头，电梯和对讲机（报警装置）的接口测试
7、零件：电梯的零件的单元测试
8、兼容性：电梯和其他东西的兼容性
二、测试中发现了一个bug，但是开发认为这不是bug，应该如何解决？
1、将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
1)根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
2)如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
3)根据用户的一般使用习惯，来确认是否是缺陷；
4)与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
3、合理的论述，向开发说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
三、Bug记录都包含了哪些内容？
1、bug编号；
2、bug严重级别，优先级；
3、bug产生的模块；
4、首先要有bug摘要，阐述bug大体的内容；
5、bug对应的版本；
6、bug详细现象描述，包括一些截图、录像….等等；
7、bug出现时的测试环境，产生的条件即对应操作步骤，期望结果；
四、详细的描述测试完整的过程
1、由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。
2、开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3、测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4、测试用例完成后，测试和开发需要进行评审。
5、测试人员搭建环境。
6、开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交。
7、开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。
8、重复上面的工作，一般是3-4个版本后bug数量减少，达到上线的要求。
9、如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
五、如何做测试分析
1、覆盖度够全
PRD、UI、时序图、表结构变更设计、概要设计文档、接口文档等等的参考文档上的内容在测试分析中都有体现。
2、结构清晰易懂
不了解此块业务的人看到测试分析，也能快速了解业务框架结构、细节逻辑、业务间关联关系。
3、维护成本低
在需求不断变化，迭代速度越来越快的情况下，如何快速找到所有需求要更新的部分，以及合理把新增部分加入到原有的测分中且不用对原有结构做大的调整。
4、隐式需求挖掘透彻
往往需求文档写的不够细致到位，或者是为了实现新的需求的部分细节功能会和与原有的某些功能相违背，甚至是不兼容、设计的不合理，可变性降低等等
5、非功能性方面的考虑
性能能否满足、容错处理、业务层面的安全性考虑、用户体验等。
六、如何设计测试用例
1、设计思路，明确原始需求，拆分原始需求，梳理业务逻辑
2、测试步骤化，调整测试步骤会出现缺陷的地方要重点关注测试步骤
3、用例流程化，依托于完整的业务流程图，覆盖所有业务逻辑
4、区分页面测试和业务逻辑
以上～～你都会么？
