为什么要写这篇总结？
当前我所在的公司的组织分工实际是比较细致的。因为分工的原因，不同的角色的视角不同，对于测试的理解也不同。业界对于测试职责的定义也有所不同，但是对于测试的职责的理解会决定我们的行为和行动，所以还是想尝试去定义软件测试的职责。
说到什么是软件测试，如果搜集一下大家对软件测试的理解，可能会有五花八门的回答：
• 验证功能可用
• 找到风险并验证风险
• 反馈版本质量
• 保证并提升版本质量
• 站在客户角度保证需求达成预期
• 确保版本可用不会有低级问题
从软件测试理念的发展的来看，主体分成四种对软件测试的理解
• 1975年，两位软件测试先驱John Good Enough和SusanCerhart在IEEE上发表了《软件数据选择的原理》一文，将软件测试确定为一种研究方向。此时软件测试普遍被定义为“证明软件工作正确的活动”，这个理念被简称为“证实”
• 1979年，Glenford J. Myers在《软件测试的艺术》出了软件测试的不同的定义：“测试是为了发现错误而执行一个程序或者系统的过程。”从这个定义可以看出，假定软件总是存在缺陷的（事实上也是如此）、有错误的，测试就是为了发现缺陷，而不是证明程序无错误。
• 1983年BillHetzel将软件测试定义为：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。”提出了测试是对软件质量的度量。
• 1950年，戴明提出的质量管理十四条法则中就提到了“质量是产品生产中构建出来的而非生产出来之后测试出来的”这样的理念。随着敏捷测试的推广普及，全程测试的概念被提出。预防的理念被提出，全程参与、预防缺陷、构建更好的系统这些理念被提出。最有代表性的就是敏捷测试宣言。
总结一下四种对软件测试职责的理解：
• 软件测试是证实，主要行动是正向思考，验证软件可用。
• 软件测试是证伪，主要行动是逆向思考，发现缺陷。
• 软件测试是评估，主要行为是从各个维度进行分析，从正向和逆向思考，验证并评估质量。
• 软件测试是预防，主要行为测试全程参与，在各阶段预防缺陷，将构建更好的系统作为首要职责。
基于以上可以谈一下对测试职责的理解。
首先要有对产品质量结果兜底的意识，一切对产品质量有益的工作都属于测试范围。
其次要明白预防胜于评估，评估胜于证伪，证伪胜于证实。
最后要想说有条件的情况下可以做好分工，一部分人做证实、证伪和评估，一部分人做预防，如果无法分工，首要要做好的一定是证实、证伪和评估，因为这个是底线。
