目前测试执行现状
整体概况：单打独斗式的执行
经历过的实际项目为例子，整个业务线有测试人员A,B,C，三方对产品进行了分割，自己”独占“一个模块：
测试执行大致如下：
1、 测试人员A,B,C分别对各自的”领地“进行测试；
2、”接壤的领地“由对应的双方进行联调测试；
于是，这种模式不免会有几层含义：
- 对各自的”领地“，测试人员A,B,C需要100%进行测试；
- 如果需要，需要和其他人员进行联调测试
- 测试人员A,B,C一旦测试执行有遗漏，很可能会遗留到线上
结对测试的期望目标
- 熟悉模块功能
- 发现新的bug
- 互补QA人员测试设计/执行的局限。例如，对产品不同方向要求的侧重
- 弥补遗漏的测试点/检查点
- 类似内测，对“成型”产品快速体验/使用。例如，某些产品/系统行为，人员A可能认为还可以接受，人员B可能就觉得有歧义或不能接受。
- 互相鼓励，增加新意
结对测试后，测试执行阶段大致形成了如下的模型：
个人感悟：给产品带来长期的质量回报。任何人都会有思维局限和“不经意间”的疏漏，即任何人总会有犯错的时候，那么结对测试，从这个角度看，也可以彼此互补，尽可能减少因一个人的“犯错”，导致产品上线的问题。
谁可以做结对测试
实际项目中的操作：
扫描二维码关注公众号，回复：
4651034 查看本文章
- 如果项目本身有多个QA人员，通常会交叉测试意不明
- 开发人员。实际项目中，开发人员，特别是后端服务开发者，往往只熟悉一个后端模块的实现，对产品的整体交互比较陌生，甚至连产品的入口都找不到。这边
- 产品人员。
- 身边的QA。这里的QA可以是负责同一条业务线的QA，或同一个组的QA
个人感悟：
避免的误区
- “单打独斗”。 QA人员通常的想法是：我自己(已经非常熟悉各个类型/产品的测试了)单独测试反而更快
- 非测试人员不如测试人员效果好。
目前对结对测试的实践
结合自己的实际测试执行情况，仅供大家参考：
- 测试环境，QA几轮测试下来，基本结束的时候，让开发人员，产品人员对主流程进行check
- 预发布阶段，和团队其他人员一起对主流程进行check
- 发布后，让团队其他人员一起参与线上验证，走完100%新功能、100%核心流程
其中最大的感受时：更多人测试互动后，让QA不再是一个人在”孤独“的测试了。
文献
https://www.stickyminds.com/article/software-testing-twos
https://blog.csdn.net/Testing_is_believing/article/details/7448100