测试技术摘要

以下内容摘自：  http://www.51testing.com/html/57/293557.html  （架构师Jack的个人空间）

测试能力：
    ---分为工程能力和研究能力

自动化测试：
    ---决定自动化测试成功的关键是测试用例的质量    ---与其一开始就追求片面的自动化率，还不如先踏实把测试用例的质量抓好。特别是对于新产品在测试早期，还是多用心思考如何提高测试人员设计测试用例的质量，扩大测试用例的覆盖面，加强测试用例测试的强度。在准备写自动化测试脚本前，先反思是否我的测试用例质量和测试报告质量还有改进的空间，我的测试用例库是否有足够多系统的可靠性测试，性能测试，压力测试，安全性测试，兼容性测试，可用性测试等的testcase与其一开始就追求片面的自动化率，还不如先踏实把测试用例的质量抓好。特别是对于新产品在测试早期，还是多用心思考如何提高测试人员设计测试用例的质量，扩大测试用例的覆盖面，加强测试用例测试的强度。在准备写自动化测试脚本前，先反思是否我的测试用例质量和测试报告质量还有改进的空间，我的测试用例库是否有足够多系统的可靠性测试，性能测试，压力测试，安全性测试，兼容性测试，可用性测试等的testcase
    ---如果国内目前只盲目追求自动化测试的开发，而忘了应该投入更多的时间和资源在直接提高测试质量的活动中，那就确实有些本末倒置了。    ---要提高该测试经理的自动化率首先应该帮助他改进测试用例的编写技术，既可以进行严格的人工评审，确保用例易转自动化；又可以提供测试用例开发工具，测试人员在该工具中进行用例编写，由于用例的编写是受到自动化测试框架的约束，虽然编写时稍有一些麻烦，但是编写完成时，自动化测试脚本也就自动生成。             为什么自动化测试率不高？因为很难把用例转自动化。为什么用例很难转自动化？因为用例比较复杂，编写用例时没考虑自动化。为什么不能在编写用例时考虑自动化的因素呢？测试人员很难约束啊——解决的根由找到了，就是用管理或工具来约束测试人员写用例时必须考虑自动化。

测试用例库的质量：
    1、    测试用例集架构的质量：是指你的测试用例库中的测试用例集是否包含了所有的质量属性所需要的测试用例，例如：是否有专项的可靠性测试用例，性能测试用例，压力测试用例，兼容性测试用例，可移植性测试用例，可维护性测试用例，可用性测试用例，安全性测试用例等。
    2、              单个测试用例的质量：网上有很多建议了，我就不列举了。补充一些常见测试用例缺陷概率高的问题——测试用例理解二义性，测试用例描述前后不一致，测试用例不具有可实现性，测试用例易用性差，测试用例的测试结果不唯一。

总结小公司测试策略的建议：
    1.    不要过早投入开展自动化测试；
    2.    一定要掌握基于风险的测试方法；
    3.    尽可能使用自动测试工具进行代码级测试；
    4.    功能测试侧重verification,少做testing
    5.    重视性能和压力测试；
    ---个人觉得，小项目的测试工作还是应该集中在功能测试（黑盒）上面，除非是项目、产品本身有很高的性能或是稳定性的要求。小项目，大部分都面临资源少和时间紧的问题。在这个前提下面，一个相对高效的开发和测试策略我觉得反而是把业务和技术尽可能的分离。测试人员关注业务需求，而把技术相关的东西都分离到开发人员手里。由测试人员来把握需求，从功能上保证项目产品的质量，而把侧重代码质量的白盒测试和性能测试交给开发人员来处理。从客户的角度或者风险管理的角度来讲，除了性能和稳定性非常敏感的项目外，大部分项目的客户满意度还是体现在功能的实现上的，这也是在资源时间有限的情况下一个较优的选择。

需求质量：
    1：需求描述是否具备完整性；（没有遗漏内容；或描述片面）
    2：需求描述是否有二义性；（没有让不同的人有不同的理解结论）
    3：需求描述是否是正确的；（需求之间没有冲突等）
    4：是否包含有非功能属性的需求；（性能，安全性，可靠性，易用性等）
    5：是否需求是可以验证的；（需求描述具备可测试性）
    6：需求是否可实现；

测试策略和测试计划：            
    制定测试策略会先从项目的需求和约束要求入手，作为开始测试策略分析制定的输入。在正式分析制定测试策略的第一步时，会先进行RBT基于风险的分析，使用RBT的方法分析得出测试目标的优先级；第二步，分析项目已有的技术现状，评估哪些现有的测试技术能满足此次项目；第三步，按优先级对测试目标的达成所需要的不同的测试技术，测试活动组合进行匹配。例如：有三个测试目标A,B,C，现有测试技术有D1,D2,D3。
    由于风险系数的先后顺序为A,B,C，因此，我会给目标A配置D1,D2,D3三种测试活动的建议，给目标B配置D2,D3的测试活动，给C配置D3的测试活动。测试项目经理拿到我的测试策略后，会在测试计划中安排相应的人力配置，安排相应的时间计划。
    
    ---如何做好测试分析和测试设计，根据我的经验和体会，建议测试分析和测试设计主要通过3个维度来做，则可以大致达到一个比较高的有效测试覆盖率：
  维度一：从用户实际使用的场景和习惯入手，开发一批测试用例；
  优点：  可以覆盖到主要基本场景；
  不足：  从事场景分析的人无法做到了解用户所有的场景，必定受参与测试分析资源限制会有场景遗漏；
  维度二：通过测试对象内部实现流程的路径及依赖关系分析入手，开发一批测试用例；
  优点：可填补维度一的部分遗漏场景，特别是异常处理和分支交互处理的场景；
  不足：分析阶段主要精力会被局限在内部流程的熟悉和分析中，从而也会遗漏真实环境中的一些偶然小概率事件；
  维度三：依赖基于经验的测试分析和设计，例如：错误猜测法或探索性测试法；
  优点： 给维度二再做一次补充测试分析和设计；
  不足： 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性；
    总得来说：无论是功能测试还是各种专项测试，依次使用以上3个维度的测试分析和设计，基本上能覆盖到被测对象的绝大部分应用场景，充分保障产品质量，减少问题遗漏。因此：测试的核心技术是测试分析和测试设计的能力，它决定了后续所有测试活动的质量及效果。同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术，如：如何给每个测试对象做细做深压力测试，长时间测试，健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。
    
testing:
    Passion, Experience
    Understand features deeply
        --Design
        --Architecture
        --Implementation
        --Customer requirements
        
项目管理类：
    质量管理：要做好测试质量管理，必须自己是组内测试技术及经验丰富的人才行，才能从专业上评估团队其它成员的测试交付件质量，否则自己有可能沦为一个纯协调者
    进度管理：依靠风险管理和不断引入先进科学的测试方法及测试工具来确保进度。
    资源管理：依靠合适的基于风险的测试策略来聚焦重点测试目标，提高资源利用率。
    风险管理：依靠日报和周报及时发现当前的技术风险，质量风险，进度风险。
    
测试的两个维度：
    测试广度
    测试深度
    
    
    book:
        James Bach《软件测试经验与教训》
        《软件测试精要》