对软件测试的粗浅认知
个人简单的认知，软件测试是为了保证软件的质量而采取的措施。
初识软件测试
本人实际从事后端软件开发工作有一年多的时间，由于最近一直待在运维的项目中，对软件测试产生了兴趣，便踏上了软件测试学习的旅程，以下为今日的学习笔记：
1.功能测试
从字面上就可以很好地理解，指的是测试软件本身需要实现的具体功能，比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于功能性测试描述。
对于功能性的测试，可以结合等价类划分和边界值分析方法来设计一系列的测试用例进行测试
- 等价类划分
等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
案例： 学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。
为了测试这个输入项，显然不可能用 0~100 的每一个数去测试。通过需求描述可以知道，输入 0~59 之间的任意整数，以及输入 60~100 之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。那么这就可以在 0~59 和 60~100 之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的 “有效等价类”。
等价类划分方法的另一个关键点是要找出所有“无效等价类”。显然，如果输入的成绩是负数，或者是大于 100 的数等都构成了 “无效等价类”。在考虑了无效等价类后，最终设计的试用例为：
有效等价类 1：0~59 之间的任意整数；
有效等价类 2：59~100 之间的任意整数；
无效等价类 1：小于 0 的负数；
无效等价类 2：大于 100 的整数；
无效等价类 3：0~100 之间的任何浮点数；
无效等价类 4：其他任意非数字字符。
- 边界值分析
边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
案例： 我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。
- 错误推测方法（补充）
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
案例： 比如，Web 界面的 GUI 功能测试，需要考虑浏览器在有缓存和没有缓存下的表现；WebService 的 API 测试，需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑；对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。由此可见，这些测试用例的设计都是基于曾经遇到的问题而进行的错误推测，很大程度上取决于个人能力。
2.非功能测试
一个质量过硬的软件系统，除了显式功能性测试以外，其他的非功能性测试也是极其关键的。
那什么是非功能性需求（Non-functional requirement）呢？
从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性等方面。
1）安全性：
该参数定义如何保护系统免受内部和外部来源的故意和突然的攻击。这通过安全测试进行了测试。
2）可靠性：
任何软件系统在没有故障的情况下连续执行指定功能的程度。这是通过可靠性测试来测试的
3）生存能力：
该参数检查软件系统是否继续运行，并在系统出现故障时自行恢复。这由恢复测试检查
4）可用性：
该参数确定用户在系统运行期间可以依赖系统的程度。这由稳定性测试检查。
5）可用性：
用户通过与系统的交互可以轻松学习，操作，准备输入和输出。这由可用性测试检查
6）可扩展性：
该术语是指任何软件应用程序可以扩展其处理能力以满足需求增长的程度。通过可伸缩性测试进行测试
7）互操作性：
该非功能性参数检查软件系统与其他软件系统的接口。这由互操作性测试检查
8）效率：
任何软件系统可以处理容量，数量和响应时间的程度。
9）灵活性：
该术语是指应用程序可以在不同的硬件和软件配置中轻松工作。像最低RAM，CPU要求一样。
10）便携性：
从当前硬件或软件环境转移软件的灵活性。
11）可重用性：
它是指软件系统的一部分，可以转换为在另一应用程序中使用。
3.关于测试的一些思考
一个优秀的测试工程师必须具有很宽广的知识面，如果你不能对被测系统的设计有深入的理解、不明白安全攻击的基本原理、没有掌握性能测试的基本设计方法，很难设计出“有的放矢”的测试用例。
同时，测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测试的。所谓的“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该残留任何未知的软件缺陷。因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。但是，在绝大多数的软件工程实践中，测试由于受限于时间本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
- 什么才算是“好的”测试用例？
“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。我举一个“池塘捕鱼”的例子，可以帮你更好地理解什么是“好的”测试用例。如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔就一定能把鱼给捞上来。如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。
- “好的”测试用例必须具备哪些特征？
1.整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
2.等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3.等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
- 如何才能设计出“好的”测试用例？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
- 具体到测试用例本身的设计，有两个关键点需要注意:
1.从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。
2.对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。 这里需要注意的是，要综合运用这三种方法，并针对每个测试需求点的具体情况，进行灵活选择。以“用户登录”的功能性测试需求为例，你首先应该对“用户名”和“密码”这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类，对于无效等价类的识别可以采用错误猜测法（比如，用户名包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。等价类划分完后，你需要补充“用户名”和“密码”这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等。