软件测试步骤及应对非正常状况的方法

软件测试步骤及应对非正常状况的方法

刘老师指出，首先要做的就是要深度参与。即在软件开发初始极端就要参与进去，要学会对软件的需求分析进行深入解读，在了解用户需求的基础上编写测试计划。

在编写好测试计划之后，要继续关注软件需求分析，在确定其不再变更之后，可以继续接下来的测试用例编写。不过在编写用例之前，首先是测试要点的编写，它是测试用例的框架，因此非常重要。将用户的要求和业务记录下来，分析其中的主次需求，以确保在测试过程中既做到全面又能突出重点。

接下来就是测试用例的正式编写了。所谓的编写测试用例，就是通过实际操作来对前面所写的测试要点中的功能点和业务进行实现。证明测试要点需要从正反两个方面来进行，一方面是对软件在正常情况下软件系统的反应，另一方面还要证明软件系统在非正常情况下也能做出正确处理。

对于用户的主要需求，在测试中需要进行有针对性的全面测试，而且还要考虑到各种可能。对于用户的次要需求，虽然可以适当少一些测试用例，但也应该考虑到正反两个方面。

在测试用例编写完之后，就可以开始正式进行测试了。测试要以以测试用例作为基础，要确保每一条用例被执行一次，而且要做到每执行一条用例就要对比软件系统的实际输出与期望输出是否一致。如果出现不一致的情况，要将其等级在记录报告中。在实际测试过程中，任何的不一致情况都不能遗漏，因为这些不一致就代表软件系统出现了问题。对于软件输出不一致的用例，最好多执行一次，尽量软件问题进行定位，以便开发人员的修改提供支持

测试结束要将测试报告开发人员进行及时反馈，以便于开发人员的修改。随着开发人员修改完成，意味着软件测试进入最后的回归测试阶段。这一阶段的目的是为了验证上次测试时所发现的问题是已经被修改，是否发现新的问题。而是否出现新问题，也是该阶段相对复杂繁琐的重要原因刘老师的建议是，把发现问题的测试用例和它有关联的测试用例重新执行一遍，如果没问题，就算测试完成，否则，再次提交测试报告，直到测试完成。

当然，以上的软件测试的步骤是在正常情况下但实际工作中非正常情况往往要多于正常情况。刘老师在这里介绍了几种非正常的情况：

1、没有形成对软件项目较完整的需求分析，甚至根本连需求分析都没有

2、项目已经开发完成的情况下，测试工作才开始进行。

3、由于交付测试时离项目已接近完成，测试的时间很紧张

那么在面对以上三种非正常情况该怎么办呢？刘老师在这里给出了自己的答案。面对第一种情况，需要测试人员站在用户的角度去考虑用户的需求，然后以此为基础编写测试要点，然后与客户或开发人员进行确认，接着编写测试用例。

面对第二种情况实际上容易应对，既然软件已经开发完成，那么测试计划中的测试时间就更容易安排，更利于执行。第三种情况是最麻烦的。如果时间很紧，那么在有经验的情况下可以不写测试用例，直接按照测试要点测试，当然测试报告不能生，应该写详细。最麻烦的就是既没有做需求分析、项目时间又紧，还没有测试经验和相似的测试用例，那么就只能通过不断加班赶时间这种最笨的办法来解决了。不过话说回来，在互联网行业，加班几乎是家常便饭，要有这个心理准备。