在测试中，除了技术这种‘硬能力’，沟通协商，文档写作这些‘软能力’，也会影响到开发和测试的合作、测试策略的落地、缺陷处理等日常工作，进而影响测试的进度和质量。
一、沟通和协商
?1.1软件测试架构师在产品项目中需要遵循的基本原则。
?1.2如何通过有效沟通获得对产品测试有用的信息？
?1.3如何和自己的团队沟通？
?1.4如何和上级领导或投资决策者沟通？
二、写好测试用例
?2.1谁是测试用例的读者，以及他们关心的是什么?
?2.2如何使得测试用例的测试目标突出？
?2.3如何控制测试用例的粒度？
?2.4如何通过优化用例表达来减少用例执行的遗漏？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.1 沟通和协商
一般来说，沟通是指双方信息的交换；而协商是指在出现分歧的情况下，通过商议、讨论，最后能够达成一致。对软件测试架构师来说，沟通无处不在：
?软件测试的“输入”，如需求、产品设计等，虽然有文档，但是其中很多细节，甚至文档的更新，还是需要通过沟通来获得；
?软件测试策略，需要通过沟通和测试团队中每个成员达成一致，统一目标。
对软件测试架构师来说，掌握一些沟通协商技巧是非常有必要的。
我们需要了解产品测试中的沟通原则，具备如何通过沟通来获取对测试有用的信息的能力，以及对不同对象使用不同的沟通方式和沟通策略。
1.1.1 产品测试中的沟通原则
对产品测试而言，沟通原则有两点：
?尽早沟通。
?既要对事，也要对人。
1.尽早沟通
在日常沟通中我们都能感到，同一件事情，沟通的时机不同，沟通的结果可能就会大相径庭。在产品测试中也是如此：在进行一项测试活动（如测试设计、测试执行等）之前，需要把目标、要求、期望的结果和可能的问题尽早沟通清楚，防患于未然。
尽早沟通能够帮助我们预防分歧。
让我们来回想一下是否有这样的感觉：
?感到开发在项目中老是破坏规矩，或是不按照规矩出牌。
?感到开发或者测试输出的文档不是你想要的。
?感到领导或是投资决策者不太理解自己，和自己之间仿佛有种沟通障碍。
如果上面有答案是肯定的，我们不妨再来看看这些问题的原因，其实都可以归咎为“分歧”：可能对目标的理解存在分歧，也有可能对做事的方式方法存在分歧，或对事物完成的标准存在分歧。其实在测试和研发团队中，每个人看待问题的角度不同，关注度不同，存在分歧是很正常的。需要我们做的，是在分歧变成问题之前，彼此进行沟通、协商、妥协。不要小看这样的沟通活动，它们能够帮助我们从根本上消灭很多问题，就像汽车的润滑剂一样，能够让项目得以顺利地进行。
2.既要对事，也要对人
既要对事，也要对人，是我们在产品测试的沟通中需要遵循的第二条原则。
在日常的沟通中，我们常说要“对事不对人”。“既要对事，也要对人”我们该如何理解呢？
事实上，测试需要打交道的角色非常多，开发人员、测试人员、领导人员、市场人员、服务人员等。“对人”意在强调我们在沟通时需要理解你的沟通对象，要学会换位思考，即使是同一件事情，在表达上也需要以对方能够理解的方式来表达。
1.1.2 通过沟通来获得对产品测试有用的信息
需求、场景、设计等都是测试的重要输入，但我们却常常发现：
?需求描述得不够清晰准确。
?场景描述得很粗。
?设计叙述得不够清晰，看不懂。
更郁闷的是，测试人员很难保证在第一时间知晓需求或设计方面的更新，常常是测试用例都快要写完了，需要开发评审时，才发现设计或者需求都变了。因此，除了文档，测试人员还需要通过沟通来获得对产品测试有用的信息，来保持在项目中的耳聪目明。
1.以测试的视角来读需求、设计文档，来准备沟通的问题
我发现，测试人员在读需求文档的时候，很容易忽视需求场景的细节，很多时候只会了解一个大概，而在读设计文档的时候，又恨不得弄清楚每一处实现的细节。花费大量时间和精力研读完这些文档后，发现还是不知道该怎么测试。事实上，对测试人员来说，从这些材料来获得测试思路才是读它们的目的，这就要求我们要以测试的视角来阅读这些材料。
何谓测试的视角？我认为主要有以下两个方面：
?需求是否可以测试？需要怎么测试？怎样才算验证通过了？
?设计是否可以测试？需要怎么测试？怎样才算验证通过了？
如果你以这样的角度去阅读需求文档，你就会更加关注需求的范围，特别是其中的限制或约束条件，关注需求的执行者和相关人员，关注场景的前置条件，除了关注那些常见的成功场景，更关注那些扩展的，特别是那些看起来有点不常见，或是错误的、异常的场景。
如果你以这样的角度去阅读设计文档，除了关注它在功能上的设计实现，你还会关注它在非功能方面，如性能、可靠性、安全性、易用性、可移植性、可测试性等方面的设计考虑。
上述这些内容，对测试人员而言都是后续需要验证的内容，但是对于需求工程师或者开发人员来说，却是容易忽视的，或者在文档中容易遗漏的内容。我们以测试的视角，带着这些问题去阅读需求或者开发的材料，就很容易发现那些需要需求工程师或者开发人员来进一步澄清的问题，获得对产品测试有用的信息，而不会跟着需求工程师或者开发人员的思路跑了。
2.以需求工程师或开发的视角来问问题
准备好需要沟通的问题后，接下来当然就是要进行沟通。正如我们前面讨论的那样，在沟通的时候，我们需要对事，也要对人，即我们应该以需求工程师或开发的视角来问问题。
1.1.3 和测试团队成员沟通
对一个测试团队来说，测试用例和产品缺陷是主要输出。测试用例质量的好坏，会影响测试执行；测试执行又会影响到产品缺陷的发现，影响产品质量。产品测试的各项活动就像链条，一环一环紧密相扣。哪一个环节出了问题，都会严重影响后续环节。软件测试架构师作为测试团队的首席技术官，通过制定测试策略来保证测试活动的顺利进行（关于测试策略的制定，请参见六~八），测试策略制定好后，需要和测试团队沟通，统一策略中的目标、思路和方法。
主动进行反复的沟通，永远不期望通过一篇文档、一封邮件或是一次会议就能让团队中所有的成员充分理解任务，明白最后要做成什么样子。涉及到一些开放性的要求，不同的人对这个要求的理解都会不同。
1.1.4 和领导或投资决策者沟通
对领导或投资决策者来说，他们一般不会太关注测试的细节，而会更关心下面所列内容：
?产品测试结果和产品的质量评估结论。
?重要bug。
?重要风险。
?进度。
因此我们在和他们沟通时，首先要避免陷入沟通产品测试的细节中。在措辞方面，少用“可能”“感觉”等这类不确定的词语，在表达上也不要轻易下结论，尽量不让不好的沟通习惯在领导面前形成一种不够成熟稳重的印象，使领导对你的基本素质产生怀疑。
在沟通产品测试结果和产品的质量评估结论时，我们可以将测试覆盖情况、质量目标的达成、遗留缺陷作为沟通重点。沟通内容可以参考的质量评估模型。
重要bug需要沟通的是当前进展、修改方式或规避措施。对典型的缺陷、后续改进计划也可以作为沟通内容。
如果在沟通时你发现你对某些信息还不清楚，就承认自己不清楚，并声明自己马上会去询问相关信息，并承诺反馈时间（承诺反馈时间非常重要）。
当你想做一些改革或创新时，最好先和你的直接领导沟通一下，听取他的意见，而不要直接跨级沟通。实际上，改革和创新都是需要付出代价的，领导可以站在更高的角度为你审查，帮你把关。在这个合作的时代，一些改革和创新可能还需要开发人员、系统架构师等其他领域角色的配合，远比想象的复杂，如果能够得到领导或投资决策者的大力支持，就等于成功了一半。如果目前领导或投资决策者对你的改革或创新并不买账，那么建议将这个想法先放一下，韬光养晦，之后找准机会再顺势而为。
1.2 写出漂亮的测试用例
事实证明，只要我们在测试用例表达上稍加注意，就能大大提升测试用例的质量。
注：现在互联网公司基本上都使用相关用例管理如禅道，ONES等系统，一些银行，国企还在使用表格形式来编写测试用例。此处略