A,测试计划  B,测试方案  C,测试用例  D,测试执行

 

一、测试前景趋势：

       单功能点测试，趋于通用测试用例，技术含量低，初级水平即可胜任；

       安全性测试（B/S架构，黑客怎么去攻击系统），要求高技能；

       易用性测试（人机操作心理，看成熟的软件），有专业化的趋势；

       可移植性测试（浏览器，平台，本地化），以后的系统产品可能会更多的考虑；

       可维护性测试（功能的变更、扩展性，升级换代），以后的系统产品可能会更多的考虑；

       性能测试（算法优化，数据库调优，问题定位），要求专业技能，测试的趋势所在。

二、测试计划内容：

   1，测试目标；

   2，测试范围；

   3，测试时间；

   4，测试资源；

   5，测试职责；

   6，测试通过/失败的标准；

三、写测试用例与设计测试用例的区别：

   1），目标不同：

     a,写用例依据掌握的方法根据SRS进行用例的描述；（存在的问题是用例没有进行统筹）；

     b,设计用例首先要规划用例对需求的覆盖率；

   2），粒度不同：

     A,写用例由进度决定；

     B,设计用例按规定有步骤地编写；

   3).用例评审严格性不同：

     A,写用例对单个测试用例的内容进行检查；

     B,设计用例先检查用例对需求的覆盖率，再检查对需求的覆盖密度，再是否从不同的角度对需求

   进行覆盖，然后对单个用例的检查；

 

四、如何设计覆盖率：

    1.明确用例覆盖的需求范围；

    2.规划用例的覆盖密度，

      [1.]明确需求的优先级，可分为功能密度、业务密度;

      [2.] 需求的复杂度；

    3.规定用例的测试类型；

 

五、好的测试用例的作用：

   a.       测试用例为测试执行提供依据；

   b.       测试用例的全局是否符合计划以及方案规定的范围和目标；

   c.       测试用例的局部（输入参数，操作步骤，预期输出）是否符合需求；

   d.       测试用例的编号，项目，标题，级别要符合测试方案或规划的要求；编号：Counter-ST-Code-Fun_Type-001

 

六、写用例方法：

   1，  等价类（划分集合，有效输入、无效输入）

   2，  边界值

   3，  判定表：输入与结果之间有一定的因果关系

   4，  因果图：

   5，  状态迁移图法：

   6，  流程分析法：

   7，  正交实验法：输入内容存在自身的组合时

   补充方法：

   8，  输出域覆盖：

   9，  输入域覆盖：

   10,异常分析：环境异常：网络、硬件、电源、服务

   11,错误猜测法：

  

七、用例设计步骤：

 

一、如何解决企业中用户需求和需求规格说明不分的问题？

    要将用户提出的原始需求进行细化，形成需求规格说明书，具体工作内容：

    1，对需求要素(输入、处理、输出)进行明确描述，保证单一需求描述的完备性；

    2，对需求点之间的关系进行明确描述，对功能性需求进行明确；

    3，对非功能性需求进行挖掘，依据质量模型分析该系统在单功能或业务场景中可能会存在的非功能需求；

 

二、如何解决需求规格不明确问题？

 1，首先要了解业务；

  2，整理需求中的问题；

  3，就需求中的问题与用户沟通，对系统有初步设想；

  4，就初步设想，绘制简单的业务流图；

  5，根据业务流分析其中所涉及的功能点；

  6，就明确后的功能点，分析输入、处理、输出；

  7，非功能需求的确认和挖掘；

 

三、需求管理的过程：

  1，需求跟踪；

  2，需求变更控制；

 

四、用建模方式对需求设计的分析：

    可以利用UML工具，绘制用例图、活动图、状态图；

 

五、对变更进行评估的依据：

  1，成本；

  2，进度；

  3，必要性；

  4，可行性；

  5，替代方案；

 

六、需求变更控制流程：

  1，变更申请人提出变更，必须填写提交变更申请单；

  2，CMO(配置管理员)对变更申请单进行检查，是否填写规范，变更申请是否重复；

  3，CCB(变更控制委员会)对变更申请进行评估，

     拒绝—>CMO通知申请人变更被拒绝的原因；通过—>进入下一步流程；

  4，CMO通知受到变更影像的责任人；

  5，变更影响人实施变更；

  6，变更后的成果物进行评审；

  7，评审通过，CMO重新将变更成果物纳入基线；

  8，CMO通知相关人员重新获取新的成果物；

一、软件需求的来源：

1，项目：由固定客户以合同或契约形式提出；

2，产品：企业内部市场人员通过对市场上潜在的客户要求整理得到；

 

二、影响软件质量的因素：

1，流程：SQA从流程方面保证软件的质量；

2，技术：测试从技术方面保证软件的质量；

3，组织：保证内部协调工作；

 

三、CMM与CMMI的区别：

1，适用范围：CMM适用于软件行业，CMMI加入了部分硬件；

2，表达方式：CMM是阶段式的，CMMI是阶段式+连续式的；

3，关注点不同：CMMI关注过程，关注需求、过程的度量；

4，CMM是做为评估标准出现的，CMMI是做为过程改进出现；

 

四、企业如何选择哪种质量标准：

1，看企业的业务特点：纯软件、规模小的最好选CMM，软件+硬件且规模大的选CMMI；

2，看企业本身对质量管理的态度：未有良好的质量意识的，最好选CMM，如果有质量意识，能自发的执行的，选CMMI；

3，根据公司预算：金额较少的，选CMM，金额较多的，选CMMI；

4，看想在那方面提高，如果想在过程控制方面提高，选CMMI；

5，对已做过CMM，要提高利益最大化的，建议做CMMI；

 

五、SQA的主要工作范围：

1，指导并监督项目按照过程实施；

2，对项目进行度量、分析，增加项目的可视性；

3，审核工作产品，评价工作产品和过程质量目标的符合度；

4，进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，租金过程改进；

六、SQA应具备的技能：

1，熟悉过程改进体系；

2，精通软件质量工程；

3，熟悉业务背景；

4，软件技术能力，自身的学习能力、动手能力；

5，良好的沟通能力；

 

七、SQA主要工作方法：

    遵循质量管理PDCA(Plan计划、Do执行、Check检查、Act改进)循环。

 

八、软件度量四个基本度量项：

1，规模(size)，软件工作产品的大小，如SRS文档页数、HLD文档页数、LLD文档页数、代码量(KLOC)、UT用例数、IT用例数、ST用例数等等；

2，工作量(effort)，完成各软件工作产品和活动所用人时（或人天等），如SRS所用人时数、HLD人时数、编码人时数、ST测试人时数等等；

3，进度(schedule)，各软件工作产品和活动开始和结束时间；

4，质量(quality)、缺陷(defect)，在各软件工作产品和活动中产生的缺陷数，SRS评审发现缺陷数、HLD评审发现缺陷数、LLD发现缺陷数、ST发现缺陷数等等；

一、软件产品开发测试基本流程（双V结构）：

1，  业务分析（BA）；

2，  需求分析(SRS)—系统测试设计STP(输出：系统测试计划、方案、测试用例及评审)；   

3，  概要设计(HLD)—集成测试设计ITP(输出：集成测试计划、方案、测试用例及评审)；

4，  详细设计(LLD)—单元测试设计UTP(输出：单元测试计划、方案、测试用例及评审)；

5，  编码（Coding）

6，  单元测试（UT）——输出缺陷记录、单元测试报告

7，  集成测试（IT）——输出缺陷记录、集成测试报告

8，  系统测试（ST）——输出缺陷记录、系统测试报告

9，  用户体验测试——缺陷记录(根据实际情况)

 

二、软件开发测试工作量一般分布图：       

 

    

 

 

三、软件测试的最佳实践方法：

       1，加强沟通和交流，让研发内所有人员都了解测试的重要性和测试的工作；

       2，测试是一个持续进行的过程，而不是一个阶段；

       3，尽早的、频繁的进行测试是降低项目成本，提高质量的一个好的实践；

       4，在每个开发阶段，使用测试和评价的结果做为是否可以通过的标准；

       5，把测试做为产品的一个部分等同管理起来，使用相同的评价标准和过程；

       6，提供集成化的测试工具和测试基础支持；

       7，加强测试度量工作和缺陷分析工作，不断的改进测试；

       8，加强测试的培训并且为测试人员提供技能发展的通道；

       9，测试是不可能穷尽的，当测试出口条件满足时就可以停止测试；

       10，产品业务知识是提高测试有效性的助推剂；

            11，测试必须被计划、被控制，并且要提供时间和资源，配置管理的规范性对软件测试工作有很大的促进作用；