一、测试策略制定的出发点
测试策略可谓是质量保证的核心，关乎测试的深度和广度、效率提升、风险控制、质量运营等等方面。如何设计出符合业务需求，质量需求的测试策略，最能体现测试人员的功力了。设计测试策略可以从以下方面考虑深入下去：
- 业务需求
- 真实的用户数据
- 技术实现方案
- 自身经验
ps:考虑测试的内容和方式时, 都应当以高产出投入比为最终目标,最大化地利用现有资源排除潜在的问题
二、测试角色理解
一般技术项目团队中会有明确的角色划分：产品人员、UI设计人员、开发人员、测试人员、运营人员等等。测试人员在整个项目团队中究竟应该如何最大限度发挥自己的价值，给整个团队带来产出呢？这涉及测试人员应该如何理解自己的团队角色，以及如何给自己定位了。
《从菜鸟到测试架构师 一个测试工程师的成长日记》对测试角色大致有如下的描述：
测试 就像河流中一张精心编织的网,软件的功能和流程就像河流中的鱼,要通过这张网的鱼必 须足够优秀才能最终存活。正是这种“优胜劣汰”的思想,保证软件只有通过了测试这张 网才得以与用户见面。
不过，个人认为： 测试更像是饲养员，让弱不禁风的小鱼，逐渐长成大鱼，来个鲤鱼跃龙门：
- 从合作角度：补充了设计，产品，开发等等人员的思维短板；
- 从产品角度：产品体验官，关心产品带来的实际价值，问题解决程度
- 从用户角度：像一个演员一样，充分去体验不同用户角色 与 产品之间的互动；第一位用户
三、测试用例设计
测试用例的设计与执行关乎整个产品的质量，而用例设计阶段更是万里长征第一步了。应该以什么样的心态来设计测试用例，以确保用例的完整性和覆盖度呢
这里最核心的一条原则：把设计测试用例的过程当做是体验产品的过程。
在用例设计阶段，通常手头有的只是需求文档、UI设计图、偶尔会有技术的具体实现方案等等。这些”死“的资料在经过测试用例设计后，需要串联起来，变成活生生的产品。 这才是用例设计的至高境界。
当你设计用例时，不仅仅需要绞尽脑汁想各种场景，交互，更要在头脑中反复演练产品的使用与交互、结果呈现。这其中应该包括以下层面的考虑：
- 功能层面
- 性能层面
- 易用性层面
- 交互层面
- 数据层面
- 边缘场景层面
- 可测性层面
最终，当测试用例设计完成的时候，以需求文档、UI设计图为基础，在脑海中会产生一个”活生生“的产品，而且这个产品已经被你使用的若干次了。
四、和开发最接近的测试
单元测试是和开发最接近的一种测试。开发人员编写单元测试用例并执行,验证单元 模块是否得出预期的结果。在敏捷开发模式中,有一种流行的开发模式叫做测试驱动开发，期望先写好单元测试用例，代码开发以通过单元测试为目标。
在实际的项目中，实际执行单元测试的团队并不多，其原因大致可以理解：开发人员忙着开发，测试人员又无法独立完成。可谓人力资源紧张，而且又无法产生如集成测试”立竿见影“的效果。故而，大多团队走了以下改良版"单元测试"：
- 测试人员设计测试用例，开发人员编写单测代码(个人理解，这种要么是测试人力十分充足，要么是粒度比较粗了，不然落地执行及效果恐怕要有待考量)
- 核心方法提供debug接口，方便调试(代替直接写代码，及时有问题，排查起来比较繁琐)
- 只和API直接打交道的接口进行测试(属于比较粗粒度的测试了，覆盖上层方法)
具体选择什么还要看项目的具体需求和人力资源了。没有最好的实践，只有在特定场景下最佳实践。
值得一提的是，在时间紧，任务重的项目场景下，一部分故障往往来源与边缘场景未覆盖。这种故障其实属于隐藏十分深的故障，而且只要涉及上线，就几乎不可能100%覆盖所有回归场景(以下除外：回归场景极少；测试人员资源富足；改动影响范围可以100%预估)。此时如果能用粒度比较细的单元测试覆盖边缘场景，也不失是一种规避风险的回归方法了。
五、什么是软件质量
看到这个问题，大脑中往往在搜索比较权威的解答。例如，下面的一种解答：
软件质量包括两个相关但截然不同的概念——功能性质量和结 构性质量。功能性质量反映的是软件是否按照设计实现并满足相应功 能性需求。结构性质量反映的是软件是否满足相关的非功能性 需求，包括如下方面：
- 正确性 反映实现的功能达到设计规范并满足用户需求的程度
- 可靠性 衡量在规定的时间和条件下,系统维持其性能水准的程度
- 易用性 反映用户掌握软件操作及理解软件事务所需付出的时间及努力程 度
- 可迁移性 衡量系统版本升级的容易程度
- 效率 衡量系统执行某功能所需的资源和时间有效程度
- 可维护性、可扩展性 反映当环境改变或出现错误时, 执行修改或修复的难易程度
- 健壮性 衡量系统在接受异常或错误输入后能否返回正确的提示信息且 不影响正确运作的指标
- 安全性 衡量系统对攻击性或不当的访问的抵御能力
以上内容当然是正确的。但在把控质量时，还应该牢记一点原则： 质量是相对的，不是绝对的。上线的产品/软件质量，其相对性体现在：
- 在某些使用场景下的质量，质量是有范围的
- 质量是在某段时间内的质量，即是在时间范围内的质量
六、思维的局限性
前面说过，团队中的成员角色划分明确，以便各司其职，其实从合作的层面说，可以理解为互相弥补思维局限性的安排吧。单单从技术层面来说的话，测试人员的作用可以理解为对开发人员思维局限性的弥补。举例来说一种极端场景，假如一个开发人员的思维十分严谨，毫无纰漏，那么就不会出现不符合需求的实现方面的bug了。正因为这种开发人员可遇而不可求，所以测试人员往往能发现实现方面的问题了。
对于我们每一个个体而言，思维的边际就是思维壁垒。除非不思考，壁垒便不存在。一旦思考，壁垒便应运而生。
从思维局限性来说，测试人员实现了对团队其他成员思维局限性的弥补，因而可以测试出不同类型的问题。但反过来想，测试人员自己又受思维局限性的限制，所以，好好想想：
测试人员应该如何弥补自身的思维局限呢？