Bug类型（QA设置）
-------------------
代码错误
界面优化
设计缺陷
配置相关
安装部署
安全相关
性能问题
标准规范
测试脚本
其他
bug状态更新备注（DE更新）
-----------------------
设计如此
重复bug
外部原因
已解决
无法重现
延期处理
不予解决
转为需求
1.如何根据不同的项目制定不同的测试流程？
2.在开发阶段，怎样合理有效的测试（区别于开发稳定的版本）？
---------------------------------------------------------------------
3.回归测试比重占用较大（对于时间紧迫的开发阶段，怎样合理的安排回归测试，怎样规避发布造成的影响）？
选择回归测试的时候，首先要确定的是，回归
测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：
第一，新修改的功能，这个显然是重点
第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员
第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣
第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册
第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方
第六，程序的主干功能
第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。
以上是回归测试用例的选择优先级。
其实，即使这样做，还是有风险的。最根本的解决方法是
自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。
-----------------------------------------------------------
a.作每日构建
b.基线功能自动化
c.编写用例时一定要分级（按照风险度，常用度，重要度）
手工执行回归测试用例（就是我上面说的7项）
-----------------------------------------------------
按照需求说明，把需求和功能点做矩阵表，然后功能点和test case作矩阵表，
每次需求有变动，就可以看它的变动所涉及的功能点，然后对应的testcase有多少，之后可以客观的分析下，所需的
工作量，可以根据具体的时间作一些删减。
-----------------------------------------------------------
4.如何衡量测试效率？
1）发现缺陷的质量；
2）测试的有效性；
3）测试组员交叉测试，发现漏测问题数量；
4）遗漏到客户缺陷的比例；
5）递交的缺陷数量；
6）执行用例的数量；
7）编写测试文档的速度和质量；
8）评审发现问题的效率；
9）测试工具使用的熟练程度；
10）测试结果的分析水平；
5.一直围绕怎样提高产品问题的品质；
已经采取的措施&成效&遇到：
1.目的:提高测试接受的标准，减少测试人员反复测试;
2.方法:经过DE、PM测试;
3.成效：相对之前的系统，bug相对有所减少；
DE执行的
单元测试应该是一个什么样的标准（目前是功能验证，验证不完成）；
6.测试改进
1.提高测试用例的效率：测试负责人认真做好测试文档的评审，尽量使用较少的测试用例，发现较多的
Bug；
2.如何在有限的时间内编写完整有效的测试用例？（需求覆盖率的问题）
3.常用软件缺陷预防
技术和缺陷分析技术有哪些？（不仅要知其然，还要所以然）
4.怎样尽量规避测试风险?
5.哪些问题是应该修复的呢（针对具体项目应该怎样度量修复标准）
（背景：并非所有软件缺陷都能修复:1.没有足够的时间；2.不算真正的软件缺陷；3.修复的风险太大（影响其他模块）；4.不值得修复（不常用功能或不常出现））
6.代码走读（开发人员互相走读）
7.站在不同人员角度测试
7.1 从代码的特性角度出发展开测试：
（1）单元测试： 按照代码的单元组成逐个进行测试。
（2）
功能测试： 按照软件的功能或特性逐个进行测试。
（3）
系统测试：对完整的代码进行编译和连接，以检查程序的主要功能能否达到预期目标。
（4）回归测试：对以前修复过的Bug 重新进行测试， 看该Bug是否会重新出现。值得注意的是，回归测试并不是
软件测试的一个独立阶段。
7.2 从用户的角度出发展开测试：
（1）配置测试： 从用户的使用出发进行多方面的测试。
（2）兼容性侧试： 主要考虑软件和
操作系统的兼容性问题。
（3）
压力测试： 在各种极限情况下对产品进行测试， 以检查产品的长期稳定性。
（4）
性能测试： 测试是保证程序具有良好的性能，能否达到预期的性能指标。
（5）文档和帮助文件测试： 对文档和帮助文件进行检测， 保证用户可以通过
学习文档和帮助文件正常使用产品。
（6）Alpha 和Beta 测试： 在正式发布产品之前将软件测试版发送给用户， 让用户在使用中找到能够存在的Bug或者反馈相关信息， 以便在正式版中得到解决。
8.如何合理的填写TS（早上：先规划好今天的任务；晚上：再来回顾今天的任务，做相应的调整与修改）
-----------------------------------------------------------------
*********************************************************************************************************
1.如何合理有效的管理开发过程中的文档
2.建议：针对每一个可测的公用模组，编写相应的单元测试代码（为了整合到新功能中实现兼容，且不影响其他代码）
摘自其他博客，有经自己做部分修改
