Soumettre la recherche
Mettre en ligne
ソフトウェア開発工程とテスト入門
•
15 j'aime
•
17,269 vues
T
tadaaki hayashi
Suivre
ウォーターフォールの工程と各種テストについての勉強会資料
Lire moins
Lire la suite
Logiciels
Signaler
Partager
Signaler
Partager
1 sur 41
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要
Yasuharu Nishi
ちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしよう
Yasuharu Nishi
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
Kotaro Ogino
テスト分析についての説明資料公開用
テスト分析についての説明資料公開用
Tsuyoshi Yumoto
概説 テスト分析
概説 テスト分析
崇 山﨑
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎
西岡 賢一郎
テスコン優勝事例におけるテスト分析公開用
テスコン優勝事例におけるテスト分析公開用
Tetsuya Kouno
Recommandé
テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要
Yasuharu Nishi
ちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしよう
Yasuharu Nishi
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
Kotaro Ogino
テスト分析についての説明資料公開用
テスト分析についての説明資料公開用
Tsuyoshi Yumoto
概説 テスト分析
概説 テスト分析
崇 山﨑
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎
西岡 賢一郎
テスコン優勝事例におけるテスト分析公開用
テスコン優勝事例におけるテスト分析公開用
Tetsuya Kouno
What should you shift left
What should you shift left
Yasuharu Nishi
テストエンジニアの品格 #automatornight
テストエンジニアの品格 #automatornight
kyon mm
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
Kinji Akemine
modern software qa - draft 1
modern software qa - draft 1
Yasuharu Nishi
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
yabbysan
JaSSTよいテストプロセスの作り方
JaSSTよいテストプロセスの作り方
崇 山﨑
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
Akira Ikeda
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向
Keizo Tatsumi
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decade
Yasuharu Nishi
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
Mineo Matsuya
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
テストプロセス改善モデルの最新動向
テストプロセス改善モデルの最新動向
崇 山﨑
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
Takaaki Umada
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
Kinji Akemine
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi
テスト計画セッション
テスト計画セッション
Tomoaki Fukura
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
Rina Fukuda
Contenu connexe
Tendances
What should you shift left
What should you shift left
Yasuharu Nishi
テストエンジニアの品格 #automatornight
テストエンジニアの品格 #automatornight
kyon mm
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
Kinji Akemine
modern software qa - draft 1
modern software qa - draft 1
Yasuharu Nishi
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
yabbysan
JaSSTよいテストプロセスの作り方
JaSSTよいテストプロセスの作り方
崇 山﨑
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
Akira Ikeda
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向
Keizo Tatsumi
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decade
Yasuharu Nishi
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
Mineo Matsuya
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
テストプロセス改善モデルの最新動向
テストプロセス改善モデルの最新動向
崇 山﨑
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
Takaaki Umada
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
Kinji Akemine
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi
テスト計画セッション
テスト計画セッション
Tomoaki Fukura
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
Tendances
(20)
What should you shift left
What should you shift left
テストエンジニアの品格 #automatornight
テストエンジニアの品格 #automatornight
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
modern software qa - draft 1
modern software qa - draft 1
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
「開発がスクラム導入するんだって!試験どーしよ!?」 -サイボウズQAスクラム奮闘記-
JaSSTよいテストプロセスの作り方
JaSSTよいテストプロセスの作り方
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decade
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
テストプロセス改善モデルの最新動向
テストプロセス改善モデルの最新動向
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
テスト計画セッション
テスト計画セッション
テストを分類してみよう!
テストを分類してみよう!
En vedette
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
Rina Fukuda
関数型言語とオブジェクト指向言語(序章)
関数型言語とオブジェクト指向言語(序章)
tadaaki hayashi
データベース入門3
データベース入門3
tadaaki hayashi
データベース入門1
データベース入門1
tadaaki hayashi
ソフトウェアテスト入門
ソフトウェアテスト入門
iKenji
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
Rina Fukuda
うさみみのソフトウェアテスト勉強法
うさみみのソフトウェアテスト勉強法
kyon mm
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011
Kenji Hiranabe
マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計
Akira Ikeda
データベース入門2
データベース入門2
tadaaki hayashi
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
Yasuharu Nishi
システム開発のテスト メモリーツリー
システム開発のテスト メモリーツリー
SE情報技術研究会
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ
Kosuke Fujisawa
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
Takayoshi Sakaino
Mass塾:テスト分析
Mass塾:テスト分析
Masanori Kaneko
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
Akiko Kosaka
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Hironori Washizaki
Google mock for dummies
Google mock for dummies
Harry Potter
En vedette
(20)
ソフトウェアテスト入門
ソフトウェアテスト入門
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
関数型言語とオブジェクト指向言語(序章)
関数型言語とオブジェクト指向言語(序章)
データベース入門3
データベース入門3
データベース入門1
データベース入門1
ソフトウェアテスト入門
ソフトウェアテスト入門
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
うさみみのソフトウェアテスト勉強法
うさみみのソフトウェアテスト勉強法
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011
マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計
データベース入門2
データベース入門2
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
システム開発のテスト メモリーツリー
システム開発のテスト メモリーツリー
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
Mass塾:テスト分析
Mass塾:テスト分析
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Google mock for dummies
Google mock for dummies
Similaire à ソフトウェア開発工程とテスト入門
Software Test Basic
Software Test Basic
Akinari Tsugo
Software testing
Software testing
Masayuki Wakizaka
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
Gamedevenvstudy1
Gamedevenvstudy1
Takashi Kokawa
テスト駆動開発の導入ーペアプログラミングの学習効果ー
テスト駆動開発の導入ーペアプログラミングの学習効果ー
Shuji Watanabe
I-TRIZのエッセンスと事例
I-TRIZのエッセンスと事例
IDEATION JAPAN
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
Takamasa Maejima
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
Fuyuki Ishikawa
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
lnial
はじめてのテスト技法
はじめてのテスト技法
Tatsuya Saito
Visualizing Software Development
Visualizing Software Development
Kenji Hiranabe
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
decode2016
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
Ldd13 present
Ldd13 present
Masashi Kayahara
鹿駆動
鹿駆動
Shinichi Kozake
プログラミング手法について調べてみた
プログラミング手法について調べてみた
OgataAyaka
SeasarCon 2009 White TDD
SeasarCon 2009 White TDD
Takuto Wada
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
axsh co., LTD.
Eclipse を使った java 開発 111126 杉浦
Eclipse を使った java 開発 111126 杉浦
urasandesu
Similaire à ソフトウェア開発工程とテスト入門
(20)
Software Test Basic
Software Test Basic
Software testing
Software testing
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Gamedevenvstudy1
Gamedevenvstudy1
テスト駆動開発の導入ーペアプログラミングの学習効果ー
テスト駆動開発の導入ーペアプログラミングの学習効果ー
I-TRIZのエッセンスと事例
I-TRIZのエッセンスと事例
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
はじめてのテスト技法
はじめてのテスト技法
Visualizing Software Development
Visualizing Software Development
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
リーン開発の本質 公開用
リーン開発の本質 公開用
Ldd13 present
Ldd13 present
鹿駆動
鹿駆動
プログラミング手法について調べてみた
プログラミング手法について調べてみた
SeasarCon 2009 White TDD
SeasarCon 2009 White TDD
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
Eclipse を使った java 開発 111126 杉浦
Eclipse を使った java 開発 111126 杉浦
ソフトウェア開発工程とテスト入門
1.
ソフトウェア開発工程と テスト入門
2.
テストに行く前に。 ソフトウェア開発のプロセスと工程について少しお話し ます。
3.
ソフトウェア開発プロセス。 ソフトウェアを開発していく時の進め方として、 いくつかの方法論、開発プロセスがあります。 プロセスというと難しく感じるかもしれませんが、簡単に言えば どういう順番でシステム構築を進めるか、といった話です。 開発モデルなどとも呼ばれます。 代表的なものとして、以下のようなものがあります。 ・ウォータフォール型(上から順に) ・プロトタイプ型(サンプル作って見せて直して) ・スパイラル型(小さなウォーターフォールの繰り返し) ・アジャイル型(XP、リーン、スクラムなど)
4.
ソフトウェア開発プロセス。 これらの開発プロセスは、「情報処理技術者試験」の「基 本情報」でも触れられている基礎知識ですので、エンジニ アならば予備知識として知っておきましょう。 基本情報資格はIT業界ではほとんどの会社で、新人が取得する様に推 奨される資格で、毎年2回実施されています。 これらの中で日本で昔から一番広く使われているものが 「ウォーターフォール型開発プロセス」 になります。 今回は、このウォーターフォールを例に説明します。
5.
ウォーターフォール型とは。 ウォーターフォールでは、プロジェクト全体を 「要件定義」「基本設計」「詳細設計」、「製造(実装・コーディン グ)」、「テスト」、「運用」、「保守」等の工程と呼ばれる単位に 分割します。 これらの分割された各工程を、1つ終わったら次と、順番に進めて いくことで、システムを構築していく開発プロセスです。 WaterFallは滝です。 滝のように上から下へ、上流工程から下流工程まで開発を進めていく ため、「ウォーターフォール」という名前が付けられています。
6.
こんなイメージ。
7.
滝。。 (´・ω・`)ショボーン
8.
各工程ではどんなことをするか。 要件定義:ユーザーの要求・要望を抽出し、システム化するうえでの 機能要件・非機能要件(バックアップ方法、稼働時間etc)としてまとめます。 つくるもの:要件定義書とか。 基本設計:外部設計、概要設計などとも呼ばれます。要件定義書を ベースに、画面のイメージを起こしたり、システムで出力する帳票を 設計したり、ユーザインタフェース(画面操作周り)やソフトウェアイ ンタフェース(データ形式・やり取り)、システム間インタフェース(外 部・周辺システムとのやりとり)の仕様を起こしたりします。 DBの論理設計(どんなテーブルが必要か)や機能分割(どんな機能に分 けるか)なども、ここに含まれます。 つくるもの:画面仕様書、帳票仕様書、インタフェース仕様書、機能仕様書 、ER図、コード設計書とか。
9.
各工程ではどんなことをするか。 詳細設計:内部設計、プログラム設計などが前後にきたり、そのもの を意味することもあります。 基本設計書をもとに、プログラムを作れるレベル、より具体的なレベ ルの設計を起こします。DBの物理設計なども含まれます。 つくるもの:詳細設計書、エンティティ定義書(テーブル定義書)、DB物 理設計書など 製造:実装、コーディングなどとも呼ばれます。 詳細設計書をもとに、実際にプログラムを書きます。 つくるもの:ソースコード、スクリプト、実行ファイル(.exe)など これをテストにあてはめます。
10.
こんな関係になります。(V字モデル) その工程で何を作るか、どんな範囲で成果物(アウトプット)を作るかに より、どんなテストをするかが決まります。 それぞれ、上流工程と結びつけるとわかりやすいと思います。 対になっている上流工程が、テストで確認したいことを決めた工程です。
11.
つまり、ざっくり言えば。 1つのプログラムが不具合がなく、正常に動くかどうか、詳細 設計どおりに作られているか確認するのが、 ⇒ 単体テスト 単体テスト後、複数のプログラムをつなげて正常に動くかどう か、基本設計どおりに動くかどうか確認するのが、 ⇒ 結合テスト システム全体として、きちんとユーザの要望、要求をみたして いるかどうか、要件定義どおりの機能を実現できているか確認 するのが、 ⇒
システムテスト
12.
ほかにも。。。 総合テスト、ユーザーテスト、受け入れテスト、運用テスト、 セキュリティテスト、ユーザビリティテスト、 性能テスト、負荷テスト(ストレステスト)、 アドホックテスト(ランダムテスト)。。。。などなど。 テストの種類は、そのテストの目的によってたくさんあります。 代表的なものは前のページにあげた、単体テスト、結合テスト、シス テムテストなどですが、自分が担当する工程によっても実際にテスト をするかどうかは違ってきます。 とりあえず、単体テストと結合テストは覚えておくといいかなと思い ます。
13.
人はなぜテストをするのか。 不具合のことをバグ(Bug)といいますが、 バグがないシステムはありません。 プログラムのミスだったり、設計書の誤りだったり、 ユーザーのお願い(要望・要件)をちゃんと聞けていなかったり、 その原因はさまざまです。 正常に動いても、それがユーザーの要望と違っていたら、 それは不具合でしかありません。 テストをすることで、これらの不具合をなくすことを目標にします。 そうすると、何をテストすればいいかは自然とわかります。
14.
1点注意。 工程の呼び方や、種類、分かれ方は、会社・現場によって 違います!!。空気を読んであわせましょう。 基本設計 BD(Basic Design)、UI(User Interface
Design) 詳細設計 DD(Detail Design)、PD(Program Design)、 SS(System Structure Design)、PS(Program Structure Design) 単体テスト PT(Program Test)、 UT(Unit Test)、FT(Function Test) 結合テスト IT(Integration Test)、SI(System Integration Test) システムテスト ST(System Test)、PT(Product Test)
15.
某ふじつうの開発プロセス。
16.
某みかかデータの開発プロセス。
17.
単体テストいくよぉ ヽ(。・`ω´・)ノ!
18.
単体テストとは。 プログラムを書いたあとで、そのプログラムが仕様どおりに書かれて いるか、仕様どおりに動くかどうか、異常終了や強制終了などしない かどうか、作ったプログラムを1つ1つテストするのが、単体テスト です。 やり方としては、大きく分けると2つあります。 1)画面(ブラウザなど)から、作ったプログラムを操作していろ いろな値を入力したり、ボタンを押したりしてちゃんと動くかどうか 確認する 2)プログラムが正しく書かれているかどうかチェックするための プログラムを書いて動作を確認する 2はちょっと難しいので、ここでは、1の例で説明します。
19.
なにをつくるか。 画面を操作して確認する場合、作ったプログラムが正しく動くかどう かを見るために、あらかじめ入力するパターンを考えておきます。 例えば、電卓アプリの場合、 「1+1=」とボタンをおしたら、2が表示されます。 「2*3=」と入力したら、6が表示されます。 入力する値と、その結果どう動けばいいか、 そのパターンを洗い出してExcelなどに書いていきます。 その1つ1つをテストケースといい、 それらを書いて並べたドキュメントを単体テスト仕様書といいます。 テストの結果や実施日などを書く場合は 単体テスト仕様書兼結果報告書などとも言います。
20.
なにをかくか。 どんなテストをすればいいかは、仕様書・設計書を正として、 仕様どおりに動くかどうか、電卓なら 1+1=3ではなくて1+1=2となるかどうかなどを確認します。 テストケースとしては例えば、 「1+1=を入力した場合」や、 「1+1を入力し、=ボタンを押下した場合」などと書き、 想定結果として、 「2が表示されること」 などと書きます。 ほかに、実施日、テスト結果がOKかNGか、テストをした担当者名 などを書いたりします。記入例は後ほど。
21.
どうやってつくるか。 「単体テスト仕様書」は、ほぼExcelで作りますが そのフォーマットは、その現場で使っているものがあればそれに習っ て同じように作ります。 指定のフォーマットがなければ、何をどんな観点でテストすればいい かを担当者に確認するなどし、それを書けるようなフォーマット (A4横とか)で自分で作成します。 どんなテストをすればいいかも、その現場の組織の文化や進め方、 そのプロェジェクトによっても様々なので、すべて同じフォーマット、 同じやりかたでOK、なんていうことはありません。 その辺は、臨機応変に対応する必要があります。
22.
方法論とか。 テストの方法論として、代表的なもの ・ブラックボックステスト ・ホワイトボックステスト などがあります。 実際にはこの中間をとる、グレーボックス的なことも多いです。 ほかにも、テストの目的によってもどんなテストをするかは変わって きます。 ・ユーザーの要求が満たされているかどうかの確認 ・不具合が正しく修正されているかどうかの確認 ・追加仕様が正しく実装されているかどうかの確認 など、その時のテストの目的を考えるようにしましょう。
23.
ブラックボックステスト。 ブラックボックス:ユーザー視点のテスト 入力する値によって、出力する値が正しいかどうかを確認する テストで、中身の処理がどうなっているかは知らない状態で ユーザ視点でテストを行います。結合テスト以降に多いです。 例えば、「電卓アプリの足し算」をテストしたい場合、 1+1=2です。(仕様) この場合、 「入力が1と1の場合に、出力は2になることを確認」 といったテストをすることになります。 ブラックボックステストの場合、 どうやって2を計算しているかは考えません。
24.
ブラックボックステスト。
25.
ホワイトボックステスト。 ホワイトボックス:網羅性(カバレッジ)の確保を主眼としたテスト こちらは、入力する値、出力する値だけでなく、中身の処理が正しい かどうかを確認するテストです。 分岐処理や、繰り返し処理なども含め、プログラムの1行1行を すべて通るようなテストをし、不具合なく動くことを確認します。 「電卓アプリ」をテストしたい場合でも、 「入力が1+2の場合に、出力は3になることを確認」だけでなく、 「もし1x2だったら」、「もし1÷2だったら」、などの分岐 (if文)がプログラムに書かれていた場合、それをすべて通るよう なパターン分のテストをすることになります。
26.
ホワイトボックステスト。
27.
ホワイトボックステスト。 ただしすべての処理をとおっても、それが仕様どおりかどうかはまた 別の話で、仕様が間違っていたら不具合なので、仕様通りかどうかを 確認できるテストケースを詳細設計書などからつくる必要がありま す。
28.
テスト技法。 テスト技法とよばれる、テストケースをどうやって洗い出すかの方法もいろい ろあります。今日は軽く。 ・境界値、同値 例)「パスワードは8文字以上16文字以下」 パスワードの文字数のパターン(境界値)⇒7、8、16、17 パスワードの文字数のパターン(同値)⇒10、20(条件の範囲内と外) ・デシジョンテーブル 条件とそれを満たすかどうか(満たす場合Y、そうでない場合N)のルールを 表形式で並べ、その条件のときにどうなるべきかをケースとします。 例)年齢50歳以上(条件)で男性の場合(ルール)、チケット半額(結果) ・組み合わせ(順列、組み合わせの。PとかCとかのあれ。) 「xxが1で、xxが2で、xxが3の場合、こうなる」といった複数の条件 の組み合わせパターンが存在する場合、わかりやすく必要なパターンを洗い 出すために、直交表という表を記述します。
29.
同値と境界値。 4 5 6
7 8 9 10 11 12 13 14 15 16 17 18 19 20
30.
31.
32.
33.
デシジョンテーブルの例
34.
単体テストの結果。 テストをしたら、そのテスト結果を記録として残すようにします。 このテスト結果の記録のことを、 「エビデンス」 といいます。意味は、「証拠」とか「根拠」とか。 エビデンスは、 テスト結果が表示されている画面(ブラウザ)のキャプチャ画像 だったり、 テスト実行前・実行後のデータベースのデータの内容 だったり、 その時によって、記録はとらない場合もあります。
35.
かるぅく結合テストいくよぉ ネー(*≧∀≦)(≧∀≦*)ネー♪
36.
結合テストとは。 「結合」という名前のとおり、単体テストが終わった複数のプログラムを組み 合わせた場合に、仕様どおりに連携して動くかどうか、ちゃんと別の画面に移 動するか(画面遷移)、プログラム同士でデータの受け渡しがちゃんとできて いるか、異常終了や強制終了などしないかどうかなどを確認します。 単一のプログラムというよりも、それらを組み合わせたもう少し大きな機能と いった単位でのテストになります。 また、外部システムやサブシステムとのやりとりをする部分のテストなども含 みます。(サブシステムは例えば受発注サブシステム、在庫管理サブシステム など、システム全体の中の一部の機能です) テストのやり方としては基本は画面(ブラウザなど)から、作ったプログラム を操作していろいろな値を入力したり、ユーザーが操作するレベルでの確認作 業になります。
37.
結合テストとは。 テストケースの洗い出しは、基本設計ベースにユーザー操作の流れと複数の画 面のやりとり・画面遷移などを確認する観点で行います。 単体テストよりは粒度が大きくなりますが、テストデータは操作の流れが再現 できるようなものを事前に準備して(作って)おく必要があります。 例)見積入力後に受注入力の操作を行うパターン ①見積入力 ・仕入商品の登録 ・保守商品の登録 ・単価の手入力商品を登録 ↓ ②受注入力 ・見積入力の内容が表示されていることを確認
38.
結合テストとは。 結合テストのテストケース、もしくは「結合テスト仕様書兼結果報告書」を自 分で作成する機会は少ないかもしれません。 ですが、結合テストの実施だけならすることもあると思います。 結合テストの位置づけや、その書き方など単体とはだいぶ違うことに注意しま しょう。 テスト仕様書のフォーマットは結合テストの性格上、単体と同じような書き方 ではなく機能同士のやりとりの確認や基本設計レベルの要件の確認が主となる ため、もう少しシンプルになります。 「結合テスト仕様書兼結果報告書」も、その現場によってテストの粒度や書き 方も違うので、担当の人に確認してから作るようにしましょう。
39.
40.
41.
いや、ないって。 未定!(`・ω・´)シャキーン ご清聴ありがとうございました。
Télécharger maintenant