1.参与需求制定评审，根据需求编写测试计划，设计测试用例？
（1）参与需求制定评审？
评审原因：
由于软件系统的复杂性，在需求分析阶段可能存在着开发方对委托方业务需求理解不全面、不准确的情况。在这种情况下，如果不进行相关的质量控制，往往会造成开发结果与用户需求不一致的后果。需求测试的目的就在于保证软件设计最大可能地满足有关用户的所有需求，降低额外风险和未预料的成本。
评审人员：
需求评审必须要有用户或用户代表参与，同时还需要包括项目的管理者、系统工程师、相关开发人员、测试人员、市场人员、维护人员等。在项目开始阶段就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏部分人员的意见，导致需求的缺失。
评审需求：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：每项需求的制定都是必要的且能够追溯的。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。
https://blog.csdn.net/qq_27495157/article/details/79740518
（2）编写测试计划？
编写测试计划的原因：
1）领导能够根据测试计划做宏观调空，进行相应资源配置等；2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；3）便于其他人员了解测试人员的工作内容，进行有关配合工作。
测试计划包含内容：
1）why——为什么要进行这些测试； 2）what—测试哪些方面，不同阶段的工作内容； 3） when—测试不同阶段的起止时间；4）where—相应文档，缺陷的存放位置，测试环境等； 5） who—项目有关人员组成，安排哪些测试人员进行测试； 6） how—如何去做，使用哪些测试工具以及测试方法进行测试。
（3）设计测试用例？
设计测试用例的原因：
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。理清思路，避免遗漏----跟踪测试进度进展----回归测试----历史参考。
编写用例：
- 测试需求分析，得到测试点
在测试需求分析阶段，只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。 - 分析得到用例优先级
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，得到优先级后可以让需求用例的设计更有侧重和着重点。
3）细化测试点变成可执行case
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。
4）及时更新测试用例
需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。
5）及时维护通用测试用例
项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。
https://www.cnblogs.com/hanxiaomin/p/6132811.html
2.测试执行、过程跟踪和进展汇报？
bug的质量：所谓质量，是指测试人员录入bug描述的清晰度，越容易理解的bug，质量越高。开发跟测试之间也不用花费大量时间去理解该bug如何修改合适。
如何录入一个合格的bug
1）发现问题的版本
一般来说，在不同版本发现同一个Bug,有可能是由于不同原因产生的。所以如果在版本1.1修改完该Bug后，在版本1.2又发现了该bug，不应该把版本1.1的bug激活，而应该重新录入一个bug，版本改为1.2。因为这是一个新增的Bug,测试人员需要重新验证，统计。如果激活上一个bug也可能造成质量统计时的漏算。
2）问题出现的环境
问题出现的环境包括操作系统环境、软件配置环境，有时候还需要包括系统资源的情况，因为有些错误只有在资源不足时才出现。由于开发环境与测试环境存在差异，往往导致有些问题只有在测试环境下才能出现。例如开发环境中使用的某些第三方组件在测试环境没有注册。这时测试人员应该把这些差异写清楚，以便开发人员在重新问题和进入调试之前把环境设置好。
3）问题重现步骤
描述问题出现的操作步骤。要尽量把操作步骤缩减到必须执行才能重新错误的几个步骤。别浪费步骤在无关问题上面，影响重现进度。
4）预期行为的描述
需要让开发人员知道什么才是正确的。有些描述不清的，如“编辑单据时，列表中不出现日期信息”，那么你是希望他出现日期呢，还是不出现日期呢？一般描述就加上XX应该XX或者SS不应该SS。
5）错误行为的描述
描述问题的现象。例如“程序抛出异常信息如下。。。”，如实反映，不要夸大。
除了以上，还有严重程度，优先级别，出现模块，缺陷类型，发现日期等等，一般在缺陷管理系统中都会提示填写。
https://www.cnblogs.com/xiaoqingSister/p/5471156.html
3.软件发布、版本管理以及相关文档维护？
1）创建和维护发布/项目信息/组件的信息；2）创建和维护测试每个特定版本的组件、周期，需求，测试用例等。3）建立测试资产之间的可跟踪性和覆盖率。4）测试执行的支持-创建测试用例集，捕获测试的执状态等。5）度量收集/报告-图表之间的分析；6）Bug跟踪/缺陷管理。
7）公司发布正式版本给客户时，会连续几天频繁发布正式版本，且每个版本改动特别小，不影响别的模块，每天都有小的改动并发布版本时：保证修改东西正常且修改东西所相关所有东西都正常。保证此项目的所有主功能流程正常。保证此项目的主模块流程正常，比如直播软件，每次发版本必须对直播多测几遍。
8）有以下几个特点的项目比较适合自动化测试： 项目变动少，周期长，项目资源足够（自动化不是一个人完成的，需要一帮人长期维护）
4.服务器、svn、gitlab的日常维护？
（1）服务器日常维护：定期更换密码，不要随意开启远程端口，不下载东西至服务器，定期备份。
安装和设置防火墙，定期对服务器进行备份，及时安装系统补丁，关闭不需要的服务和端口，账号和密码保护，安装网络杀毒软件，监测系统日志。
(2）SVN(Subversion)：
使用SVN的原因：程序员编写程序的过程中,每个程序都会生成很多不同的版本，需要程序员能有效的管理代码,在需要的时候可以迅速准确取出相应的版本。
SVN日常维护：
- 创建版本库，并定期备份
- 确定存储目录结构，并定期检查
- 分配和维护用户权限
- 对基线进行管理
- 对变更进行管理
- 对发布进行管理
使用SVN做这些事情，上述前三项是基本操作。第4项是通过在tags文件夹做标记实现的；第5项严格来说需要其他辅助工具，简单做的话可以通过在branches文件夹拉分支出来再合并回trunk实现；第6项也是通过在tags文件夹做标记实现。
(3) gitlab的日常维护
GitLab是一个自托管的Git项目仓库，可以自己搭建个人代码管理的仓库，功能与github类似。
1)创建项目;2)添加分支;3)默认分支设置;4)项目分组（权限控制);5)保护master分支，不允许被push;6)上传、下载、分支、更新、回滚。