软件测试你必须要知道的那些事儿

Posted 2022-08-02 michaelcjl

首先，软件测试之灵魂拷问三连：

1.软件测试是什么鬼？

2.软件测试如何分类？

3.软件测试有没有Rule要遵循？

卧槽，软件测试这么复杂，还有这么多道道，不就是"点点点"么？
说这话的同学，请你尊重一下软件工程这个专业，好么？软件测试好歹也是软件工程的主干课程哦。
同时，说这话的同学也暴露了自己只做了纯执行的那部分工作。

好了，接下来我们要严肃的回答四连同志们的深刻提问。

1. 软件测试是什么鬼？

按照 Standard for Software Test Documentation(IEEE Std 829-1998)
中软件测试的定义
软件测试：分析某个软件项以发现现存和要求的条件之差别并评价此软件项的特性。
软件的测试是为了确保软件的质量以及软件开发方向的正确性。

2. 软件测试如何分类？

黑盒测试，白盒测试，灰盒测试，单元测试，集成测试，系统测试，确认测试，验收测试，冒烟测试...傻傻分不清楚。

当各位看官看完这篇解说文档，再有童鞋将黑盒测试，单元测试，白盒测试，系统测试，冒烟测试，验收测试这些概念混为一谈时，你基本可以判定，说这话的童鞋不是一名合格的测试攻城狮。

软件测试从不同的角度有不同的分类：
从软件测试技术来划分，软件测试可以分为：
黑盒测试，白盒测试，灰盒测试

从软件开发阶段来划分，软件测试可以分为：
单元测试，集成测试，系统测试，性能测试，确认测试，验收测试，回归测试。

从软件测试执行的状态来划分，软件测试可以分为：
静态测试，动态测试

从软件测试执行的主体来划分，软件测试可以分为：
开发方测试， 用户测试， 第三方测试

从软件测试对象，测试方法，测试目的来划分，软件测试可以分为：
WEB测试，面向对象测试，兼容性测试，安全测试，易用性测试，探索性测试，国际化测试等。

相信到这里，大家对这些概念有了初步的了解，不那么乱了。
我简单做一个图给大家捋一下，相信这样就清楚多了。

3.软件测试有没有Rule要遵循？

答案的肯定的， 这些Rule 是前辈们的经验总结。参考这些Rule 可以避免掉进一些坑。

Rule 1：客户爸爸的需求至上。
这个相信大家都不难理解，我们做产品就是为客户做的产品，没有客户买单的产品不是好产品。所以我们的产品无论从设计，实现，功能，性能都要客户爸爸的需求啊。当然我们测试也要能追溯到客户的需求啊。不然可能我们忙活了半天，还不是客户爸爸想要的效果，这可就徒劳无功了。最严重的错误是导致软件无法满足需求的错误

Rule 2：测试是有计划的活动。
测试计划的制订先于测试的执行。测试贯穿与整个软件生命周期。
这个也不难理解。如果没有测试计划，到时候执行测试肯定会抓瞎（测试scope 是什么，怎么测，测试schedule是什么，如何能保证项目on-track）。同时，没有计划的测试也容易导致漏测，重复测试。相反，如果有了详细的测试计划，我们才能做到手中有粮，心中不慌。按部就班的执行测试，就算测试中途遇到严重的issue,也能及时的评估出风险，及时highligh, 必要时ask for help , balance resource 来满足整个项目进度。不至于因为我们这个测试部分而影响整个项目进度，导致shcedule 滑掉。

Rule 3：缺陷出现表现出集群性。
软件缺陷会集中出现，80%的错误可能来自于20%的模块。
软件设计开发也是属于人类活动，软件开发的缺陷也符合二八定律。

Rule 4：测试应该从“小规模”走向“大规模”
这个很好理解，因为软件开发是从无到有，逐步迭代完成的，我们的测试当然也只能从“小规模”走向“大规模”。不可能我们测试开始什么都不做，到最后开发完了再测试，这不仅拉长了整个项目周期，同时也加大了项目的风险。

Rule 5：穷尽测试不可能
穷尽测试不可能，也没必要。
首先举个栗子

 def add(x, y):
        return (x+y)
    

对于上述加法函数方法的测试，能穷尽测试吗？

理论上我们应该把所以的输入都覆盖到，但是实际却往往不允许啊。比如我们项目有schedule,我们不可能一直测下去，同时我们软件开发测试也是属于商业活动中的一个环节，也要考虑cost。

Rule 6：有效的测试应由第三方独立进行。
这个相信大家都理解。不能一个人或一组人既当队员又当裁判。这样不具有客观公正性，没有信服力。还有测试人员和开发人员的思维确实有点差异。
开发人员往往是正向的思维逻辑，而测试人员往往是逆向的思维逻辑。

实际工作中单元测试，集成测试往往由开发一并做了，这一方面是为了提高效率，另一方面由于有部分测试人员的综合素质达不到。

Rule 7：测试无法揭示所有缺陷。
测试的思维其实是开发思维的逆向。测试只能说明有缺陷，不能说明没有缺陷。这么说吧，测试发现了问题，被测对象一定有缺陷。 测试没有发现问题，不代表被测对象没有缺陷。这也说明了测试无法揭示所有缺陷。

Rule 8：测试的杀虫剂悖论。
潜在的缺陷对已进行的测试具有免疫力。

Rule 9：测试是有风险的行为。

好了，各位看官的疑问解答完了。

最后，我再总结一下软件测试的过程：

1.拟定测试计划
确定测试目标和范围，测试环境，测试策略，测试结果分析计划，测试报告计划，测试重用计划，测试schedule，测试结束标准。

2.编制测试大纲
测试活动的依据：明确测试内容，制定测试活动准则，定义测试活动如何实施。

3.设计测试用例
每次执行测试的详细说明

4.实施测试
在每个测试周期，测试工程师依据测试大纲和测试用例，通过执行被测软件，或检查程序代码或文档，对其进行测试。

5.分析测试结果
收集测试结果：通过和未通过的测试用例
生成测试报告：为软件项目进展提供重要及时的参考数据