1.软件测试的流程是什么？
需求分析-测试计划-测试设计/开发-测试执行-测试报告
2.如何描述一个BUG？
版本（代码版本），测试环境，测试步骤和测试数据，实际结果
= 预期结果，附件（截图，错误日志）
3.因为一个BUG和开发人员产生冲突该怎么做？
- 先检查自身，看BUG描述是否清楚
- 从用户的角度去说服开发人员
- BUG定级要依据公司的标准
- 要不断的提高自己的技术和业务水平，提高自己在团队的影响力
- 找产品经理一起商量解决的办法
向被测试系统发起的一组集合，包含，测试环境，测试步骤，测试数据，预期结果
- 测试用例是测试执行的依据
- 测试用例可以复用，在进行回归测试的时候不用重新编写
- 测试用例可以衡量需求的覆盖率
- 后人可以借鉴
- 手工测试用例是自动化测试的依据
需求是测试人员进行测试的依据，测试人员分析需求，验证需求的合理性和正确性，无二义性；
从需求当中提取测试项，根据测试项进行进一步的细分，提取出测试点，编写测试用例。
功能性测试
- 从界面开始进行测试（符合UI设计稿）
- 验证软件的功能，把业务相关的功能串起来进行测试
- 一个功能的不同输入，和对应不同的输出
- 功能之间的交互性
- 异常功能的测试
- 功能用到的算法的验证
- 从易用性，兼容性性能等几个方面去考虑
如何做到从页面表面上做到毫无保留的测试
非功能性测试
测试在软件本身有的功能之上的考虑
易用性，兼容性，性能，安全，可移植性，可靠性，可维护性
根据输入（特殊情况考虑输出），把输入划分成若干个等价类，从每一个等价类当中选择测试用例进行测试，如果这个测试用例测试通过，则说这个测试用例代表的等价类测试通过。
针对输入和输出的边界进行测试用例的设计
边界值要去边界上的值，和边界左右两边的值
tips：等价类和边界值结合在一起进行测试用例的设计
强调对被测试软件的需求理解以及设计实现的细节把握，还有个人的直觉和经验。
很多软件不同的场景，是基于不同的事件的触发，不同事件的触发，导致场景走向不同的事件流。
不同的功能点串起来形成一个场景。不同的功能点又有不同的输出，不同的输出导致不同的测试场景。
测试用例：
**事务：**一系列密切相关的操作集合，如果所有操作成功，就说这个事务成功了；如果其中一个操作失败，我们就说这个事务执行失败。
测试步骤：
- 分析出所有的输入和输出
- 找出输入和输出之间的组合关系
- 根据关系画出因果图
- 根据因果图画出判定图
- 根据判定图写出测试用例