- A+
显示不全请点击全屏阅读
最近有和一个初学测试的朋友聊天，他说关于测试方面的书看来不少，理论和概念也背了不少，但是实际测试时还是不知道怎么怎么下手，不知具体该如何做？ 其实关于怎么入手做测试，没有什么具体的规范，以下是我的个人习惯，供大家讨论一下。
面对一个新的项目，应该从项目的编写需求分析时参与进去，了解项目的背景和用户的需求，然后根据项目的开发进度，编写测试计划；测试计划要包含以下内容：测试用例编写时间，按照用例执行测试的时间和执行回归测试的时间，这个时间根据要项目进度来设定，以保证计划的正常执行。
编写完测试计划后，不要急着编写测试用例，要先确定需求分析是不是已经编写完成，并经过了评审。如果确定需求分析已经评审完成，那就要尽可能多的了解需求分析。根据需求分析编写测试要点，所谓测试要点，就是测试用例的框架，把需求分析中的用户要求和用户业务记录下来，然后区分哪些是主要也需求，哪些是次要需求。这要便于测试的全面和测试重点的突出。
编写完测试要点后，再开始编写测试用例。所谓的测试用例，就是指测试某项功能时，所作的输入数据或动作，并列出期望的输入数据或动作。那么编写测试用例，就是用实际的操作来证明前面所写的测试要点中的功能点和业务实现。证明测试要点时要从正反两个方面进行，不但要证明正常情况下软件系统的反应，还要证明在非正常情况下，软件系统也要能作出正确的处理。对于主要的需求要尽可能全面测的测试，要考虑到各种可能性，而对于非主要需求，测试用例可以适当少一些，但是最低也要有正反两方面的考虑。
测试用例编写完成后就可以开始做测试了，做测试时要按照测试用例进行，要确保每条用例至少执行了一次，每执行一条用例就要对比一下软件系统的实际输出和期望输出是否一致，如果不一致，要记录到测试报告中。实际测试时不要漏掉任何的不一致情况，因为这些不一致就是软件系统的问题所在。对于软件输出不一致的用例，最好多执行一次，尽量定位软件问题所在，以便于开发人员的修改。
测试完成后，就要及时把测试报告反馈给开发人员，以便于开发人员的修改。当开发人员修改完成后，就进入 到软件测试的最后阶段回归测试（我认为这是最麻烦的，呵呵），所谓回归测试，就是验证上次测试时所发现的问题是不是已经被修改，有没有新的问题出现。之所以认为它麻烦，那是因为软件修改完成后可能会导致新的问题出现，如果把测试用例再重新执行一遍的话，就要花费很多的时间。如果要使用测试工具进行自动化测试，就要花费大量的时间去维护测试脚本，无论怎么做，都很麻烦。我的一般做法是把发现问题的测试用例和它有关联的测试用例重新执行一遍，如果没问题，就算测试完成，否则，再次提交测试报告，直到测试完成。
以上是在正常情况下，做功能测试的步骤，但是实际工作中，正常情况总是小于非正常情况的，我遇到的非正常情况有以下几种：
1、软件项目的需求分析不完整，或者没有需求分析。
2、开始测试时，项目已经开发完成。
3、交付测试时，离项目的完成时间很短，没有太长时间进行测试。
针对以上三种情况可以分别对待，第一种情况比较麻烦，没有需求分析就意味这功能测试就没有了依据，那么就需要测试人员多和用户和开发人员进行交流，要站在用户角度考虑问题，考虑用户到底需要什么样的软件，希望软件完成什么样的功能。然后，根据这些编写测试要点，再找用户或者开发人员确认，最后编写测试用例。第二种情况，就相对简单，既然软件已经开发完成，那么测试计划中的测试时间就更容易安排，更利于执行。第三种情况就比较辛苦了，既然项目时间紧，那就要赶时间作，如果你有一定测试经验的话，那就不要写测试用例了，直接按照测试要点进行测试就行了，不过测试报告不能省，还是要详细记录。如果没有测试经验，那么最后找以前相似项目的测试用例，对照测试要点进行测试。如果一没有需求分析，二项目时间紧，三又没有测试经验和类似的测试用例，那么哥们，我精神上支持你，你自己做好加班拼命的准备吧。
Tags：
如果您喜欢我的博客，欢迎点击图片定订阅到邮箱
也可以点击链接【订阅到鲜果】
如果我的想法或工具帮助到了你，也可微信扫下方二维码打赏本人一杯咖啡
