前端测试

合理性讨论

软件测试几乎是后端团队的标配，但是对于前端团队来说，开发的软件强依赖与环境以及事件驱动的模型导致了测试困难重重。所以对于前端团队来说，假定要进行前端测试，那么需要评估编写测试代码所带来的收益(bug量减少、更容易重构等)是否大于在编写测试代码所花费的资源(时间、模拟环境等)。这也是挺多即使是优秀的前端团队也没有对所开发的软件引入完整的测试原因。

首先给软件测试做个定义

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程

所以测试是为了发现程序中的错误而执行程序的过程，然而测试并不仅仅是为了找出错误，也应该去分析错误产生的原因和产生趋势，从而发现开发过程中的技术或者方案上的缺陷，以此来持续改进软件的质量。

然而，在软件开发过程中，让程序员写测试有个比较尴尬的点： 测试是一个具有破坏性的过程，开发是一个创造的过程。这两点本身具有冲突性，一个人不太可能把两个截然对立的角色都扮演地很好。在假定开发人员必须写测试的情况下，如何平衡这种矛盾是需要探索的点，有个比较具有主观性的观点是：

当你觉得你写的测试能使你自信的将软件交给QA进行测试时，那么你写的测试便是合格的。

这种观点在心理学上并没有将一个人分为两种角色，开发人员编写的测试是为了证明自己写的代码按照预期的功能工作了， 而对于开发人员，我觉得这已经是足够了。但这种心理却是与软件测试的破坏性过程是违背的，所以需要专业的测试人员来执行这种破坏性。但如果QA能对开发者写的测试用例进行review, 那也是能较好的提升测试效率。

测试模型

在一个完整的测试流程中，自底向上包含：单元测试、集成测试、确认测试等等一直到Alpha测试和Beta测试。但是对于前端开发人员来说，可以将测试的范围集中在单元测试、集成测试和E2E测试。由此，可以绘制出一个类似于光谱的东西，光谱的两端一个是单元测试，一个是E2E测试：

unit test -> other test -> E2E test

大多数需要关注的测试都会落到这个光谱上。

在测试用例分布上，有一个金字塔模型，底部是单元测试，顶部是E2E测试，也就是单元测试的量需要最多，而E2E的数量应该是最少的。在一篇文章中对E2E测试需要尽量少的解释如下：

Having hundreds of them, like you would have in unit and integration tests, means that running your tests would take a long time, and that is something that is imperative — tests should run fast.

not have many E2E tests is that these tests tend to be flaky. Flaky tests are tests that usually pass, but sometimes fail. This cannot (usually) happen in unit tests, as they are usually simple input/process/output and involve mostly the CPU. But the more a test involves I/O (where in I/O I mean anything that is not CPU or memory driven), the more flaky it becomes.

所以，E2E的作用是保证整个应用能跑起来，用来连接各个模块的代码不会出现问题。而更细节的功能测试需要在单元测试和集成测试中。

而另种模型是橄榄球模型, 即集成测试需要尽可能的多, 在前端的软件开发中，集成测试体现在对每个功能块的测试，或许这是个对GUI软件更好的模型？有待观察哈哈哈哈

测试策略

在测试方法上，很重要的两种方法便是等价类划分和边界值测试。这两种策略是在白盒测试和黑盒测试中常用的测试用例设计策略。关于这两中策略的设计方案在笔者很久以前的文章中介绍过，不作过多阐述。

• 白盒测试
• 黑盒测试

关于等价类划分，可以用如下语句进行定义：

把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例

等价类的划分能有效的减少测试用例的数量和尽可能多的覆盖测试不同的测试场景，但是实际开发过程中，程序的边界上是经常出错的地方，所以需要用边界值的测试来对测试用例进行补充。

以上是对前端测试模型和策略的讨论。