1，测试时间不够的项目，就比较适合做敏捷测试吗？

这句话说对了一半。应该是适合，但敏捷测试本身对整个项目成员来说，是有要求的。这里说测试时间不够，指的是功能测试的时间不够。那就需要测试提前介入，而不只是在开发将功能都做好才开始测试，测试从单元测试开始，后面的接口测试，集成测试都需要去做。所以首先这里对测试的代码能力是有要求的。

敏捷测试，要求整个项目组配合密切，因为时间不够，所以沟通等都是高效的。

2，很多项目中，之所以测试时间不够，是因为需求在不断的变化。

这时候，并不是客户要求需求怎么变化就怎么变化，还需要1）技术能达到2）与当前系统相对融合，这时候要考虑很全面，一个需求要牵扯到哪些现有的需求点等。测试不能仅仅在产品确认后，才开始写测试用例，而应该在需求评审时就密切参与，对需求进行”测试“。

3，测试方案和测试策略是什么？

这并不是必须的，可加入到测试用例中。

4，如何写测试用例

在最开始最好把需求点全部列出来，在时间非常紧张的时候，可以用需求点代替测试用例。当然，有些更细的，需要写测试用例时再补充，比如，边界值等

测试用例的评审看项目组的时间，如果时间非常紧张可以把自己的测试用例发给开发，比如发送邮件。

5，测试要有自己的原则

比如，准入原则，开发交付测试的基准是什么，在开始测试时，发现的bug提交给开发时，他们会觉得，你这些先别看。。之类要与开发沟通好，避免造成双方的工作冲突。测试人员的角色是什么，测试的责任是什么，----测试是开发的帮手。是合作的关系。

当开发交付的功能，没有可测性，功能流程走不通，应停止测试，让开发重新检查。这里针对功能测试，单元测试，接口测试同理。即冒烟测试。

如果测试可以提前介入，参与到单元测试，是在帮助开发做自测。跟后面的找bug，稍微有差异。

6，测试报告

测试报告要在上线前1天发出来，发给当前项目成员，产品经理来做验收。项目经理对当前bug 的状态，评估当前版本是否符合上线标准。符合的话再提交上线流程申请。

也有是在上线完后，再写测试报告。

7，敏捷测试的概念

敏锐高效的根据需求变更，制定有效的测试策略，提交

通常说的回归测试是UI的自动化测试。是这样？

回归测试，需要有相对的回归测试用例。

8，关于模板

比如测试用例、测试报告，直接用公司的模板，如果没有的话可参考提供的模板。

9，流程的应用

我们了解了测试的理想状态下的流程，那么实际中如何使用呢？将这套标准版的流程在实际中使用，显然不是一句话的事儿。最最重要的是看当前项目的实际情况，参考标准的流程，结合起来，制定出适合的工作（测试）流程。（举例，进入一个新项目，项目没有流程可言，这个流程就自己来定义，当然要符合当前公司的要求）

任何标准都是一步步形成的。

测试不是只学理论，不是只去实践，而是两者结合起来。在实践中将理论落地。等下次再用到时可以直接上手，而不是照着文档操作。

10，bug的处理

一部分bug，不严重，易修复，可以与开发当面沟通，开发可以当下解决，提交给测试复测（这个期限最长不超过24小时），复测通过。为了防止忘记，可先记录到word中或手写下来。

一部分bug，比较严重，直接记录到bug库中（jira、禅道、QC等），按照bug处理流程进行。

11，测试的角色

测试不能只是执行，只反映问题，而不去考虑后续。比如一个bug，测试环境有，开发环境没有，去深究下，到底是哪里的问题。

12，关于管理

并非只有担任测试负责人，才算是管理。管理也包括管理自己，管理自己的工作。如何改进测试方法，让自己的工作更加方便，更加顺利。

13，测试要做哪些事情（这个后续做总结）

测试在不同的阶段都做哪些事情。。

14，测试写的东西害怕别人看？

工作中会写测试用例、测试计划、测试报告等，这些不用藏着，要分享出来。测试一定要写出来给大家看，工作中有想法，也要及时的表达。如果你不说，我会以为我所说的就是好的，没有问题的。（尤其针对需求，产品经理不可能全方位360都想到）

15，敏捷与非敏捷的区别

区别主要是迭代的时间。敏捷测迭代的很快。