有一个误区,虽然说软件测试的工作产品之一是通过测试过程发现的缺陷,但是此工作产品的产出并不是单单直接测试获得的。
一个产品需要测试,拿过来直接测试通常并不能获得一个好的结果,通常需要了解很多的内容才能更好的完成此测试过程。
比如此产品的需求是什么,需要进行哪些方面的测试,哪些内容是要重点测试的,测试的工作时间是多久,需要安排多少的工作量。
在软件开发中,也并不是拿过来一个点子就开始写代码吧,需要进行需求调研,整理客户需求,写需求规格说明书,评审,项目计划,概要设计说明书,界面设计,数据库设计,详细设计等等等等,这些都做好了,才开始正式的写代码。即使是敏捷过程,同样有story,站立会议等等,也并不是拿过来都直接做的。
测试过程类似,参与需求评审,写测试计划,参与项目例会,写测试方案,写测试用例 ,根据计划做接口测试、功能测试、性能测试、安全测试、回归测试等等等等。
所以说,测试不仅仅是发现缺陷,而是通过软件测试的过程,让项目相关人员了解当前软件的质量情况,最终给发布的软件以信心支持。
回到问题,你想通过一个具体的软件了解测试,那么建议通过以下的途径进行:
1.软件确认。随便找一个软件,比如你常去的论坛,比如知乎,比如豆瓣等等等等,软件是什么不重要,重要的是测试的思路。
2.测试内容。通常功能比较多,可以拆分一些简单的功能模块进行测试,比如登录,比如发帖,比如查询等等。
3.测试范围。这个其实如果有需求应该是对于需求的分析,但是既然没有需求,那么就参考具体的程序,把上面的功能拆分出来,比如登录就可以列出功能分解:创建新账号,老用户的登录,使用QQ、手机、微信第三方登录等等。这里需要对测试的范围进行确定,具体测试哪些功能。
4.测试类型。接口测试,功能测试,性能测试等等。
5.测试计划。简要写一个就可以,主要说明测试的范围,测试的类型,测试用例的编写等等,具体看测试计划相关内容,确认需要做的工作。
6.测试用例。具体内容应该都学习过的吧,等价类、边界值、场景法等等,能用上的都用上,多分析多写,尽量考虑更多种类的正常和异常的情况,这个才是测试人员最基本最基本的基本功。真正工作中,即使不写测试用例,但是头脑中一定也要有一个测试用例列表,我现在应该做什么,接着做什么,实际按照此列表进行。软件测试绝对不是随便点点的胡乱测试,是有理论和实践支持的科学工作方法。
7.执行测试。按照测试用例去测试。在测试的过程中,可能需要随时补充调整测试用例,这个是正常现象,发现缺陷就记录下来。
8.缺陷分析。发现的缺陷进行整理分析,比如是否可以重复出现,测试步骤是否可以简化,是否其他地方存在类似的问题等等。测试缺陷通常有群集的现象,一个地方发现的问题多,那么说明这个地方一定会有更多的问题等待发现。
按照上面的流程,至少你可以对别人有信心的说,这个软件我成功的进行了测试,即使没有发现任何的缺陷,至少在测试用例的范围之内,我已经尽力了。
--------------------------