|
不论你何时开始接触测试这个行业的，你首先了解到的一定是功能测试。即，通过一些测试手段，来验证开发做出的代码是否符合产品的需求。
当然，每个人对功能测试的理解也会存在不同。但，只要你做这行，就一定会发现一个现象：很多同学觉得功能测试太简单，工资不高，所以就转行做自动化测试了，结果不仅自动化没学会，反而越做越迷茫。
究其原因：是因为你连功能测试都没学好，怎么可能学好自动化测试。
下面，我就自己的个人经历，为大家分享一些测试后心得，希望对大家有用
需求分析：发挥主动性
正常需求在提出时，产品需分析需求价值、影响范围和实现代价等。可是现在很多情况是，需求来了就组织评审，然后开发测试与上线。产品主导型的开发模式非常常见，作为测试人员，我们无法主导需求和项目。因此，在需求评审的时候，提前预估工作量，防止因评估不足造成后期测试不充分。
再者，一定要关注开发和产品讨论。如果开发说其中一个部分比较难实现，但最后实现了。那么，其中的变动和难点就是测试的重点关注部分。
另外，需求评审结束后，需向产品提出评审改动部分，同时更新自己的测试方案。最后，根据产品需求，在设计测试方案及时间安排上，可粗粒度预估，时间上要合理，并在会上与所有与会人员交流。
用例设计与评审：做到不遗漏
测试用例是每个测试人员工作中必不可少的环节。不管你是用Excel，还是FreeMind来写，都应编写并存档。可能很多人不在意测试用例编写规范，但我认为这个观点须纠正。
编写测试用例，我认为最重要一点，就是从用户的角度出发。首选，测试用例的编写，必须具备：测试用例名、执行步骤、预期结果这三个元素。再者，测试方案选择必须全面。作为功能测试人员，你可能不会编写自动化测试脚本、性能测试、安全测试等脚本，但是你必须知道需进行哪些测试。
如：面试的时候给你一个场景：一个全新的App要发版，如果让你来测试，你能想到哪些测试方案？
如果你只关注如何测试App的功能，那你很可能会面试失败。此时App的功能、性能、数据传输安全性、接口或服务的测试（包括：功能测试、自动化测试与监控、性能测试），底层数据存储与容灾情况等，都须考虑在内。
另外，设计用例时要设计两类。一类是关于开发自测和验收测试标准的冒烟测试用例；另一类是针对需求的全面测试用例。写完用例要主动联系相关人员进行用例评审，强调开发自测。在评审时，还要及时修改不合适的用例。
测试流程：注重项目控制
其实，项目的流程控制在需求开始时就应该重视起来。只是很多时候，我们容易忽略这个问题。测试人员是一线工作人员，不管你工作了多久，都必须有关注项目整体的意识。如果你不关注项目进度，很可能会导致加班返工。
需求一旦明确由你负责，就要时刻排期来关注项目的进度情况。同时，在测试过程中，发现了bug必须详细的描述问题，不管是jira,禅道或是其他的bug管理方式。发现bug一定要写清楚以下几点：Bug问题描述，bug重现步骤，是否有前置条件，预期结果，实际结果，以方便开发去进行修改。另外，还要给bug准确分级，实时跟踪进度，保证项目按期完成。
上线回归与项目总结
需求上线完成后，要及时进行线上回归。如果有必要，须提醒相关人员进行自动化线上回归或是监控工作。同时，必须回归由bug修复导致的原有功能丧失问题，以确保新功能的成功上线。作为功能测试人员，我们还需通过问题记录、解决措施记录等内容，将整个新功能上线过程做成文档，便于后期查阅使用。
总结和沉淀
在应聘时，很多有着多年从业经验的功能测试人员，面临无法被录用的窘境。究其原因，是因为：你不具备相应工作年限该具备的工作能力。
多个测试工具在使用时，有哪些关联性？在遇到同种类型的bug时，有几种应对策略？在做完项目后，你是否做过完整的梳理和总结？对于这些问题的处理态度，将决定着你工作能力的提升与否，也决定着你未来的求职成功率。
另外，请时常问问自己：离开现在的公司，我还有什么？你还有的内容，才是你价值的体现。不要想通过调换工作方向，逃避自己能力不足这个问题。只有充分认清自己的能力，正确看待问题的人，才能走的更长远。
 |
