上回说到小艾跟着导师修炼了一段基本功之后，也明确了自己的专业技能学习道路，却在几次转头的瞬间发现身边的每一个人都似乎在做着不同的事情，不是说好的一个团队嘛，为什么你做这个，他做那个呢？小艾还真是疑惑，于是又屁颠屁颠去找导师聊天，不，请教去了~
团队分工
耐心的导师再一次给无知的小艾科普了一阵，原来，细致的分工能提高效率，团队的成员根据分工的结果担当不同的角色，在其位，谋其职。
其实，软件行业可是一块很大的蛋糕，相信每个人都有这样的经验，同样说着同行的几个人，可能一个是开发，一个是测试，一个是文档，一个是设计……这种情况并不少见，就如同那句古话说的：术业有专攻~
术业有专攻
随着软件系统的复杂度越来越高，分工不可避免的出现了，分工的出现，是解决个人控制力有限的唯一方法。从经验和效率的角度看，一个团队中的个体在技术和经验上各有千秋，分工能更有效地发挥人的长处。
导师告诉小艾，细致的分工有利于凝聚人的注意力，提高熟练程度的同时可以减少切换带来的开销。
前面说过小艾在电子商务的团队中，且使用了敏捷开发，按照敏捷开发的团队角色划分方式，该团队的核心角色主要包括产品负责人(Product Owner)，Scrum Master及团队成员(Team)。而外围还包括客户(Stakeholder)，经理(Manager)等角色。
团队成员主要负责产品的具体开发，每个团队成员有具体的分工，如架构师、开发人员、测试人员、文档设计人员等。团队成员组成执行团队，这是个自组织、自定向和跨功能的执行团队。
项目团队中的角色
架构师是对软件开发过程的各个领域都具备一定专业技能的人员，主要任务是把软件开发的需求转化为可以实现的抽象设计和具体设计，并完成相应的设计文档。其技能特点：具有更高的视角，对技术的发展方向能够有全局的把握，对业务也有深刻的认识。
开发人员的职责是根据抽象设计和高层次的具体设计进行更细化的具体设计，并按照设计完成编码实现及单元测试任务。开发人员的开发技能与软件是否已高质量完成有重要的关系。
测试人员的任务是根据软件设计文档编写测试计划，并按照测试计划对软件进行测试。测试人员从另一个角度促进软件的开发过程，其工作的重点是发现问题和解决问题。
文档设计人员的任务是根据需求文档和设计文档，设计编写交付给用户的说明文档和使用手册。完备的文档是成熟软件产品必须具备的交付成果。
上述的所有角色都隶属于一个项目团队中的相关人员，而在团队外围，也同样存在一些相关角色。
客户是软件产品的直接利益相关者，他们从业务的角度提出对软件产品的需求，可以说，客户是开发软件的根本动力。
经理在团队中的任务是控制开发进度、解决团队的资源问题、对团队的运行技术性的指导等。因此可能存在项目经理(Project Manager)、人事经理(People Manager)、指导经理(Coaching Manager)，当然，这三个角色也可能是同一人担任。
测试团队中的角色
听了导师不厌其烦地说了上面那么多，小艾对这些角色有一定了解之后，发现自己其实最关心的是测试团队存在哪些角色分工，毕竟这小艾是测试人员，先不说未来会不会转行做开发做设计，当下的他还是蛮认得清自己的，得先把目前的局势搞搞清楚才对嘛。于是，导师这时候可能喝了一口水，然后又继续长篇大论了……
测试负责人(Test Lead)是测试的主要统筹者，需要担当测试项目经理的角色，其任务包括定义测试计划、统筹人员调配、监督测试项目进度等。因此测试负责人的技能要求是综合的，既需要掌握测试的专业技能，又要具备良好的组织能力和协调能力。
测试架构师的职责是定义测试策略，从宏观上定义测试的方向和方法。因此测试架构师应该具有较高的技能水平，包括深入和全面的测试经验，对软件开发和测试的模型有全面的认识，对商业模式及客户的业务需求也有比较深刻的理解。
测试工程师专注于具体的测试任务，重点关注其测试的目标业务部分，根据特定的场景指定测试计划。因此测试工程师的技能主要包括设计和执行测试用例的专业技能，良好的业务理解能力和问题分析能力。这也是包括小艾在内的众多测试新手们需要努力加强的地方。
测试经理从资源调配的角度给不同的测试项目分配资源。
导师说完这么多角色之后，顺便也向小艾强调了一句话：角色的不同仅仅是分工的不同，而不是级别的不同，至于专家与菜鸟则在某种程度上无非是闻道有先后的区别。
小艾得到了想要的答案，想必心里还是开心的，或许爱思考的他这一刻已经将自己当前所在的位置及今后想发展的方向想得更加明确了~
好软件由测试决定
搞清楚了团队中的角色问题，也对自己的位置有着一定认识的小艾重新投入到工作中了。可是喜欢思考的他还真是一刻也停不下来，这不，听着身边不停有人在讨论着各种各样的软件，对其做着这样那样的评价，似乎每个人都认为自己有清晰的标准衡量软件的好坏，但小艾自己却并不知道这个标准是什么。这时候大家都知道套路了，小艾再次去找导师聊天去了。喂喂喂，我们一再强调小艾是个爱思考的孩子，遇到问题他不是只有嘴巴的好吧，他也会自己上网查资料的，查完对疑问再去请教导师，既可以明确自己的疑问，加深相应的理解，也让导师对他更为欣赏，一举两得~ 哈哈……
小艾先是发现了一个词：软件质量，而说到软件质量，就不可厚非地要提到两个截然不同的概念：
功能性质量：反映软件是否按照设计实现并满足相应功能性需求
结构性质量：反映软件是否满足相关的非功能性需求
如何评价软件的功能性质量和结构性质量呢？这时候请教导师的小艾知道了一系列的衡量指标：
正确性：反映了实现的功能达到设计规范并满足用户需求的程度，这是功能性质量的基本指标。
可靠性：在规定时间和条件下，系统维持其性能水准的程度，这是结构性需求的重要指标。
易用性：反映用户掌握软件操作及理解软件事务所需付出的时间及努力程度。
可移植性：衡量系统从一个平台转移到另一个平台的容易程度。
可迁移性：衡量系统版本升级的容易程度。
效率：衡量系统执行某功能所需的计算机资源和时间有效程度。
可维护性、可扩展性：反映当环境改变或出错时，执行修改或修复的难易程度。
健壮性：衡量系统在接受异常或错误输入后能否返回正确的提示信息且不影响正确运作的指标。
安全性：衡量系统对攻击性或不当的访问的抵御能力。
由于测试人员可以以上述指标为前提帮助开发人员完善软件的质量，我们可以这么说：有效的测试是软件质量的重要保证。
测试也有大学问
既然聊到了软件的质量，那么我们回过头再来看测试的目标，我们已经知道了测试的目标是发现软件系统中存在的缺陷，这里其实有一个关键的原则：尽可能早地发现问题。
一个相同的问题如果在不同的开发阶段解决，所需的开销是不一样的，越到开发后期，解决问题所需的开销越大。为什么？因为软件开发是一个迭代和积累的过程，越是底层的缺陷，发现的时间越晚，由于关联的代码及涉及接口的设计越多，修复的代价便越高。
因此，作为测试专家，应该考虑的问题是如何尽可能早的发现缺陷，以及有效地解决缺陷。
如何尽早地发现问题
尽可能发现问题是测试工程师的职责所在，小艾对此也算是理解深刻，但如何发现问题呢？在导师那里，小艾得到了两类发现问题的可行方法：
分析方法：主要使用逻辑分析推理的方法发现缺陷和评估问题的严重性，并根据所处的阶段得到解决的方法。
测试方法：对设计分析时认为有问题的场景进行模拟，如果在这种场景下没有出现此前认为出现的问题，那么这个缺陷的解决方案就被认为是可以接受的。
分析方法不需要等待缺陷目标的开发完成并使用测试进行验证，但对分析人员的技能要求较高。相比之下，测试方法实施难度较低，其设计出针对性的场景，并在测试环境上模拟该场景，之后对比结果即可，但前提是测试的场景能够在测试环境中正常运作。
Bug
无论使用分析方法还是测试方法发现问题，都通过创建bug来跟踪。bug一般是指系统存在的问题或者需要加强的细节。
在一个bug中，创建人需要明确说明bug的内容，包括测试的环境，步骤，优先级/重要级及问题的描述及期望值等。
bug的生命周期始于创建终于关闭，主要流程如下：
创建bug --> 确认bug --> 分配bug（若是bug给相应的开发人员，若不是bug退还给创建者，若不确定可能需要先给PM等人确认再定）-->修复bug（开发人员修复并将修复完成的bug交还给创建者）-->验证bug（测试人员验证bug是否修复，若未修复re-active bug给相应的开发人员）-->关闭bug
如何更早地、有效地发现问题，是测试专家的一项非常有技术含量的工作，而测试专家的另一项有技术含量的工作，就是发现问题后的问题分析。或许有人说了，开发人员在解决问题之前会自己做分析的吖，我作为测试者，任务只是发现它。其实不然，分析bug不仅对自身成长有帮助，同时将自己对bug的情报与开发人员共享，也能让bug尽可能早的得到修复，如果幸运的话，还可以从开发人员共享的过程中得到来自开发人员对该bug的知识补充。
问题分析
提到问题分析，这里方法有两种：自顶向下和自底向上。
自顶向下方法，其着眼处在于整体。系统整体的问题可能是系统某个部分的原因引起的，而这个局部的问题放大后悔在系统的宏观级别上表现出来。一个系统的局部分解方式通常是稳定的，使用自顶向下方法的理念在于通过这种稳定的分解，使用穷举方式最终可以确切地找到发生问题的局部。试想一下，我们调试测试代码的时候使用的方式就有些类似于自顶向下，或许没有那么明显的整体化，仅仅是将一条case看成一个整体。
而自底向上的方法对分析者的能力要求较高，前提是承认bug的全部或部分是由于系统局部细节的问题引起的。使用这个方法的判断过程往往与遭遇问题的经验、对问题的"嗅觉"有重要的关联，当然，也少不了需要拥有直达问题根源的“直觉”。
然而无论使用哪一种方法，本质其实都是准确地重现和定位问题。只要问题得以有效重现和定位，那就距离找到解决的办法就不遥远了。
尾声
导师在最后告诉小艾，发现、定位和解决问题的方法，是测试人员的核心技能。而思考能力更是测试专家不可或缺的生存技能。五花八门的测试方法和技术，需要通过自己的实践、总结和思考，转化成细条的测试方法论。当一套属于你自己的测试方法论已经形成的时候，意味着你已经从专家成长为高手了。
工作了一小段时间的小艾，到这时候，才算是搞清楚了测试工作的整体概况了，项目团队中的角色及测试团队中的角色让他有了一定的了解及对未来的打算，为他后来登上测试架构师奠定了基础。而软件质量如何保证，以及测试技能的成长之路也让他更加明确学习的方向。不过始终停不下来思考的小艾又产生了新的问题，究竟具体到了什么样的程度才算是成为了专家，而优秀的测试工程师人们又是用什么样的标准来评判的？各位看官不要着急，喝杯茶，歇一歇，请听下回分解~
想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月
