背景
本文主要记录以下问题:
1、组件测试方法(方法论)；
2、前端测试代码技巧。
组件测试
一开始我只是考虑测试组件传入不同的props展示是否正常展示，expose的所有方法是否正常调用。
但后来慢慢发现有一些方法/用户操作的场景无法覆盖到(方法之间相互影响)，然后根据测试反馈的bug增加了一些测试用例，但这样写会很奇怪，
就是为什么只写这些组合的测试用例？
举一个简单的例子：
function add(a: number, b: number) {
return a+b
}
function sub(a: number, b: number) {
return a - b
}
// 单独测两种方法
add(a, b)
sub(a, b)
// 组合
add(sub(a, b), c)
add(a, sub(b, c))
sub(add(a, b), c)
sub(a, add(b, c))
这个例子可能不是非常恰当，但可以看出来如果我们要覆盖所有的场景是非常困难的，这导致在写测试代码时非常难受。到底写哪些、不写哪些？还是全部写？怎么评估组件测试是否充分？
集成测试方法
非增量测试
大爆炸方法属于非增量式集成测试方法，该方法一次性集成了所有模块，即它不会逐个集成模块，它会在集成后验证系统是否按预期工作。
增量测试
1、自顶向下集成
逐步集成和逐步测试是按结构图自上而下进行的，即：模块集成顺序是首先集成主控模块，然后按照软件控制层次接口向下进行集成。
从属于主控模块的模块按照深度优先策略或广度优先策略集成到结构中去。
2、自底向上集成
从最底层的模块开始，按结构图自下而上逐步进行集成并逐步进行测试工作。
3、三明治方法
改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。
这里每个分类的优缺点/适用场景/策略等都可以参考集成测试，这里不再展开了。
结论
在了解了集成测试方法后，其实我没有什么可选择空间（没有这么多测试资源来进行增量测试）。但大量缓解了我的测试焦虑，我只需要进行非增量测试，测试的策略：先独立的测试每个模块（单元测试），然后再把它们组合成一个整体进行测试，最后结合边界条件尽量cover所有的分支/语句。
前端测试技巧
其实在写前端测试代码的时候，经常会遇到一个非常困惑的事情，当我调用了某个方法渲染数据的时候，怎么判断渲染是否正常？我在使用的时候有两个技巧：
1、尽量使用稳定的节点去进行判断，例如我在渲染列表的时候是通过 uniqueId 去检查是否已更新/删除/添加；
2、使用 screenshot diff 功能，但 cypress 仅提供了 screenshot 功能，没提供 diff 的功能，需要通过 cypress 插件来集成进去；
3、使用自定义属性选择器（固定作为测试的选择器）。
很多时候开发和测试并不是同一个人或者同一组人，使用特定的标识方便进行测试，也方便开发快速辨识到这是测试用的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
