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