如何认知软件测试理论要点

在做软件测试时候，我们知道整个软件测试的流程操作： 测试需求分析（需要产品经理（BA），开发人员，测试人员到场）测试需求评审  （需要产品经理（BA），开发人员，测试人员到场）编写测试计划设计测试用例测试用例评审搭建测试环境测试执行回归测试测试报告

在做软件测试的过程中，一定要遵循下列原则： 所有的软件测试都应追溯到用户需求（以客户具体需求为导向）应当尽早地和不断地进行软件测试。完全测试是不可能的，测试需要终止。充分注意测试中的群集现象。程序员应避免检查自己的程序。（交叉测试，有助于纠错）尽量避免测试的随意性

需要了解的验收测试（主要确认软件是否满足软件需求规格说明书中的要求）的相关概念： alpha测试、beta测试的区别 alpha测试：公司内部员工组织的测试beta测试：由典型客户进行的测试 白盒测试、黑盒测试、灰盒测试 白盒：对程序内部结构和算法进行测试黑盒：在完全不考虑程序内部逻辑的情况下，检查程序是否满足用户需求灰盒：关注系统接口所实现的功能，是否和需求一致  回归测试：全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现以前应用没有的问题现在出问题了部分回归：当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响  冒烟测试/预测试目的是确认软件基本功能正常，可以进行后续的正式测试工作

在提交测试用例的过程中，是需要了解测试用例的相关状态：No Test未执行状态Pass通过状态Fail失败状态Block阻碍状态。Investigate观察中状态。

测试用例的编写方法包含有：等价类，边界值，场景法，判定表等几种。通常使用的方式是场景法以及错误推测法。 错误推测法指的是在软件测试中，人们可以靠经验和直觉推测系统中可能存在的各种错误，从而有针对性地编写检查这些错误的例子.

接下来是需要了解下bug的生命周期：而言，每一个工具对bug生命周期的定义不一样，但是大致为以下几个过程。  New:新发现的bug，未经评审决定是否指派给开发人员修改 Open：确认是bug，并且需要进行修改，指派给相应的开发人员 Fixed：开发人员进行修改后标识成修改状态，带测试人员的回国测试验证 Rejected：如果认为不是bug，则拒绝修改 Delay：如果暂时认为不需要修改或暂时不能修改，则延后修改 Colsed：修改状态的Bug经测试人员的回归测试验证通过，则关闭BUG Reopen：如果经验证bug仍然存在，则需要重新打开Bug，开发人员重新修改注：open->closed,open->rejected->closed