测试基础理论

1      软件测试的目的

发现bug不是目的，只是手段。测试的目的，是通过发现bug，分析bug的缺陷分布，评估软件或者特性模块的质量，为版本决策提供信心。

2     

软件生命周期

3      软件测试七大原则

3.1      测试的目的是发现缺陷，不是验证软件没有问题 Testing shows presence of defects

测试的目的是尽可能的发现更多的缺陷，不是证明软件是ok的。

3.2      不可能执行穷尽测试 Exhaustive testing is impossible

很多情况下测试的组合是大量或者无穷的，所以要结合需求和实际资源，去设计最小用例覆盖需求。

3.3      测试活动应该尽早开始 Testing early

测试要从需求分析和特性设计阶段开始

3.4      缺陷存在群集效应(二八定律) Defect clustering

存在问题的地方，往往容易发现更多的问题

3.5      杀虫剂悖论 Pesticide Paradox

随着问题的修复，同样的测试用例能够发现问题的能力会逐渐降低。所以需要不断完善用例。

3.6      测试活动依赖测试内容 Testing is context dependent

简单地说，测试要在熟悉业务的基础上进行。

3.7      没有错误的谬论 Absence of error - fallacy

无论执行多少，多长时间的测试，都不存在没有bug的软件。而我们测试的目的也是让软件没有bug，而是在满足需求的情况下，修复不能接受的bug。

针对其中比较重要的三点，做一些展开的叙述：

第一点，软件测试的目的是发现缺陷，而不是验证没有问题。这其实是一个心理学问题，因为当你抱着验证没有问题的心态去测试的时候，就容易把一些问题遗漏掉。因为，人更倾向于事情朝着自己预期的方向发展。所以，这个心态很重要。
    第二点，测试应该尽早介入。这其实是一个关于成本的问题。测试活动开始的越早，测试人员对整个版本流程的掌控也就越强。因为计划几乎是不可能按照预期实现的，如果每次都是开发完成到一定程度才开始写用例，那永远都是被动的跟着走。问题会发现的比较晚，而问题发现的越晚，修复的成本就越高。所以，在需求分析和特性设计阶段就积极介入，是花最小的成本，解决最大的问题的方法。同样，越早分析清楚需求，完成测试用例的设计和编写，后续的测试成本也就越低。因为，完善总比从无到有要快。
    第三点，bug存在群集效应。也就是通常所说的二八定律，80%的bug存在于20%的代码中。对于我们来说，需要注意的就是，在发现问题和回归问题单时，要去适当发散测试。因为软件是一个系统工程，存在问题的地方，往往因为交互，耦合和新的修改容易出现更多的问题。

4      软件测试质量六要素

质量六要素，是我们衡量一个软件或者特性质量的六个维度，根据软件实现的目的和客户的需求，会有不同的侧重。

1. 功能
2. 效率(性能)
3. 易用性
4. 可靠性
5. 兼容性(可移植性)
6. 可维护性(可测试，便于后期运维)

5      常用软件测试用例设计方法

我们学习和使用测试用例设计方法的目的，是因为我们需要在不能执行穷尽测试的情况下，尽可能保证测试的全面性和完整性。简而言之，最大程度的提升测试效率。

此处只对用例设计方法做整体上的描述，后续wiki会结合具体的ROACH测试，详细讲述下列设计方法的使用方式。

1. 等价类划分

根据测试对象是否生效，将其划分为有效等价类和无效等价类。

eg.一个网页上的跳转按钮，根据其功能是否生效，可以分为有效等价类用例，点击按钮后成功跳转，点击按钮后弹出正确的跳转提示；和无效等价类用例，网络断开情况下，点击跳转按钮，正确报错网络连接异常等等

1. 边界值分析

根据测试对象的取值边界，来设计测试用例。

eg,一个参数的有效取值范围是[1~256]，那我们最少需要测试的值就包括五个点

小于1的值

等于1的值

1~256中间值

等于256的值

大于256的值

1. 流程图

某些测试目标具有一系列连续的步骤，其中某些步骤根据不同的输入还会有不同的分支流程。此时，我们通过流程图法梳理出所有的流程。其中每一条完成的流程链，都是一个测试用例。

1. 错误推测法

根据经验或直觉推测程序中可能存在的错误，有针对性的编写测试用例。