在公司，我是卑微的。不知道这种说法是否合适，但确实如此，也正因为这种卑微，在不断的批评，尝试中，自己有所成长。同时也在不断的犯错，不断的纠正，有时候，对公司的一个前辈可以说有爱又恨，爱是因为他一直苛刻的要求自己，纠正自己的同时，又不断的给我犯错和学习的机会，恨的是他从来不会笑着和你说，都是严肃的，在群里批评自己，说话都带着些许火药味。从开始的害怕，到后面慢慢的习惯，再到感激，不得不说，从一个项目零起点开始自己就参与进来，一点一点的学习积累，收获是最多的。

测试流程：

1. 测试前需要建议版本库（SVN），用例测试过程中各种文档的归档，已经测试进展的更新。

2. 测试前需要进行环境的搭建和部署，以及各种测试工具的安装，相关配置的设置

3. 对于系统环境的一些配置值需要进行统计，以便后续使用

4. 测试流程

补充：

1） 测试过程中的文档输出之后要及时的进行归档

2） 测试计划：对测试的需求进行模块分解，根据实际情况评估工作量，并进行分配；测试计划中需要包括：需求，工作量（人/天），需求文档的归档路径，设计规格的归档路径，测试人员，版本（迭代批次），测试方案（评审结果），测试用例（总用例条数，已通过用例条数，失败用例条数），阻塞（问题单及描述），备注

3） 测试方案可以通过xmind或者Word进行设计，对于存疑或者细节处需要进行备注。测试用例的设计尽量使用测试方法（等价类划分，边界值，场景法等）

4） 测试的依据是需求文档（主要），设计规格辅助理解

5） 测试用例的输出标准化：（多人合作测试）用例输出名称进行层次级目录，编号根据测试计划中进行编号，方便后续的维护和管理；用例的输出避免冗余，尤其自动化；用例的设计尽量使用测试方法，覆盖涉及的场景。

6） 测试用例设计，测试场景输出（此处针对自动化）：用例场景输出尽量使用全自动化；对于时间等一些非固定的值引入变量；接口测试，不仅要验证接口调用的功能，还要检验接口返回的字段是否正确

7） 测试问题的处理：对于测试问题需要进行提单跟踪（禅道等软件），问题单需要进行邮件抄送相关人员（测试经理，开发等），并及时跟踪问题的进展，避免问题停滞太久。

8） 测试计划结合测试日报，需要每天下班前进行更新，及时反馈测试的进展

测试细节：

1. 测试的依据是需求文档和设计规格辅助理解；而不是开发的理解和言词

2. 测试过程中需要有自己的一套原则，对于存疑的地方及时与开发进行确认，如果没有达成一次，需要进行例会，与产品经理、开发进行讨论和确认

3. 测试的目的不是验证需求是否实现，而是已实现的功能是否存在缺陷或者问题；对于确定的问题及时提单，提单的数量也是对测试员的一种考核

4. 测试的过程中要细心，忌讳投机取巧型测试；对于自动化用例，执行成功不是用例设计的目的。

5. 测试过程中多使用测试工具，对于测试用例多注释，同时删除冗余的用例，增加用例的可读性和可维护性。