敏捷テスト、ソフトウェアテストVモデル、ソフトウェアテストWモデル

2815 ワード

文書ディレクトリ

  • 敏捷
  • scrum
  • scrumのキャラクター
  • 反復開発
  • 敏捷中のテスト
  • ソフトウェアテストのVモデル
  • ソフトウェアテストWモデル
  • すばやい


    「敏捷」は新しいプロセス・ファミリーの名前「敏捷宣言」です.私たちは体を動かし、他人を助けることで、より良いソフトウェア開発方法を明らかにします.この仕事を通じて、私たちは以下の価値観を形成しました.
     
     
     
     
     , , 
    

    また、敏捷宣言では、敏捷はソフトウェア開発に関する社会工学であることがわかります.敏捷な主な貢献は、開発者の仕事の情熱を奮い立たせる方法をより多く考えることにある.これはソフトウェアエンジニアリングの数十年の発展過程で相対的に無視された分野である.敏捷な開発には多くの方法があり、その中でscrumは比較的流行している.

    scrum


    scrumのキャラクター


    src umは製品マネージャ、プロジェクトマネージャ、研究開発チームから構成されています.
  • 製品マネージャは、ユーザーの物語を整理し、ビジネス価値を定義し、ソートし、発表計画を作成し、製品に責任を負います.
  • プロジェクトマネージャは各種会議を開き、プロジェクトを調整し、研究開発チームに
  • サービスを提供する.
  • 研究開発チームは、異なるスキルのメンバーで構成され、緊密に協力することで、反復の目標を達成し、製品を提供します.

  • 反復開発


    滝とは異なり、scrumは製品の開発をいくつかの小さな反復に分解し、その周期は1周期から4周期まで異なるが、4週間を超えない.参加するチームメンバーは一般的に5人から9人です.各反復で完了するユーザストーリは固定されています.反復するたびに一定の成果物が生成されます.scrumの基本フローを上図に示す
  • 製品責任者はユーザーの物語を整理し、左側のproduct backlog
  • を形成する.
  • 計画会議の発表:製品マネージャはユーザーの物語を説明し、それを推定し、ソートし、計画会議の産出を発表することは、この反復が完了する物語のリスト、spring backlogを制定することである.
  • 反復計画会議:プロジェクトチームは各物語をタスク分解し、分解の基準はstoryのすべてのタスクを完了することであり、各タスクには明確な責任者があり、工数の最初の推定を完了する.
  • 毎日例会:毎日scrum masterは立ち会い会議を招集し、チームメンバーは昨日何をしたのか、今日何を計画したのか、何か質問があるのかと答えた.
  • プレゼンテーション例会:反復が終わった後、プレゼンテーション会議を開き、関連メンバーが招待され、チームは今回の反復で得た成果を構築に展示する責任を負う.期間中の皆さんのフィードバックを記録し、製品マネージャーが整理し、新しい物語を形成します.
  • 回顧会議:プロジェクトチームは今期の反復を総括し、不足を発見し、改善計画を制定し、次の反復は引き続き改善し、持続的な改善の効果を達成した.

  • スピーディなテスト


    挑戦1:軽いドキュメントの挑戦2:迅速な反復1、テストの仕事の核心内容は変わっていないで、絶えずバグを探して、ただ自分の心理状態を調整して、すべて敏捷な原則を主とします.テスト担当者はドキュメントに依存することができず、テスト例の役割が弱まり、思考ガイドをより多く採用し、探索的なテスト(自由度を強調し、設計と実行を同時に実行し、テスト結果に基づいてテスト計画を絶えず調整する)、自動化テストを行う.3、敏捷に協力を求めて、敏捷なプロジェクトグループの中で、テスト人員はもっと積極的に点をつけて、多く開発人員に需要を理解して、設計を通論して、一緒にbugが現れた原因を研究しなければならない.

    ソフトウェアテストのVモデル


    VモデルはPaul Rookが1980年代後半に提案したもので,ソフトウェア開発の効率と効果を改善することを目的としている.滝の模型の変種です.
  • は、試験中に存在する異なるタイプの試験を明確に表示し、これらの試験段階と開発過程中の各段階との対応関係
  • を明確に説明する.
  • Vモデルは、ユニットと統合テストがプログラムの実行がソフトウェア設計の要求を満たすかどうかを検出しなければならないと指摘している.システムテストはシステム機能、性能の品質特性がシステム要求の指標に達しているかどうかを検出しなければならない.検収テストは、ソフトウェアの実現がユーザーのニーズまたは契約の要求を満たすかどうかを決定する.
  • 限界:テストを符号化後の1段階とするだけで、必要としない段階はテストに入る.

  • ソフトウェアテストWモデル

  • Wモデルはソフトウェアの各開発段階において同期して行うべき検証と確認活動を追加し、Wモデルは2つのV字性モデルからなり、それぞれテストと開発過程を代表し、図にはテストと開発の並列関係を明確に示している.
  • Wモデルの特徴:テスト対象はプログラム、需要、設計などだけでなく、同じようにテストを行い、テストと開発は同期して行われる.
  • Wモデルの利点:問題を早期に全面的に発見するのに有利である.たとえば、デマンド分析が完了すると、テスト担当者は、欠陥を早期に特定するために、デマンドの検証と確認活動に参加する必要があります.同時に、必要なテストに対してもプロジェクトの難易度とテストリスクをタイムリーに理解するのに有利であり、急いで対応措置を制定し、全体のテスト時間を著しく減少させ、プロジェクトの進度を加速させる.
  • 限界:需要、設計、符号化などの活動はシリアルと見なされている:テストと開発活動もバカという線形の前後関係で、前回のu但瓦努は7年が終わってから、正式に次の段階の仕事を始めることができる.敏捷開発モデルをサポートできません.現在のソフトウェア開発が複雑で変化が多い場合、Wモデルはテスト管理が直面している困惑を解消することはできない.