2025/02/11 -------------------------------------------------------------------------------- ◆テストの確認項目（システム単位） まずは、仕様通りに動く。つまり操作説明書や設計書に○○をすると△△する、と書かれている通りに動作する。 権限のある利用者に権限に応じたメニューが表示される。権限のない利用者にはメニューが表示されない。 メニューシステム経由でなく、認証されていないURL直接アクセスはエラーになる。 各検索画面の初期表示、検索、結果表示ができる。ページ渡り/ソート/フィルター機能がある場合はそれも効く。 各入力画面の入力、結果表示ができる。入力エラーチェックが正常に効く（必須フィールド、境界値、特殊文字や長い入力値） ダウンロードができ、ファイル名、内容とも文字化けしていない。 添付ファイルや他サーバ―のファイルへのリンク切れがない。 PDF帳票出力ができ、印字内容が正しい。文字化けしていない。 メール送信ができ、宛先、内容が正しい。文字化けしていない。 他サーバ(構内オンプレミス、他工場)との通信がエラーなくできる。…EDI、DBLINK、FTP、送信、受信とも。先方でもエラー、文字化けがない。 画面応答は概ね10秒以内。アップロード/ダウンロードは1分以内(データ量による)。越える場合や従来環境よりも遅い場合はユーザー了承を得る。 日本語のファイル名の添付ファイル可の場合その添付ができ、サーバー上で文字化けしない。またDL時もクライアント上で文字化けしない。 アップロードにおいては、ファイル形式やファイルサイズの制限が効く。 ソースコードをGrep検索し、旧サーバや旧設定に関する語句(ホスト名、IP、ディレクトリパスや、文字コードがSJIS決め打ちとか)がない。 旧サーバに接続している個所がない(ファイルソース検出、DBとの接続を切って検出) IEモード、Edgeモードそれぞれサポートしている方で正常に利用できる。 不要ファイルの定期削除処理が正常に動作する。 データやログに記録される処理時刻が正しい。 エラーログにエラーが出力されていない。 セッションタイムアウト時間が守られている（見た限り） -------------------------------------------------------------------------------- テスト計画 (2025/03/23) -------------------------------------------------------------------------------- 社内情報システムのサーバー移行プロジェクトにおいて、 対象サーバで稼働する業務アプリケーションの動作のテストをしたいと思います。 テストの種類を細分化してWBSの計画に反映したいですが、 最も大きなテストの分類は、機能テストと非機能テストの区別になりますか。 それとも別の分類をすべきですか。 -------------------------------------------------------------------------------- それでいい。それを踏まえた大分類の例 ◆移行テスト ・移行作業後、データやファイル、設定、権限の新旧環境比較を行う ・プログラムや設定ファイルの文字コード変換の妥当性などを見る ・ソフトウェアのバージョンアップの既知の影響が反映されていることもここで確認 ◆機能テスト（単体テスト、結合テスト、総合テスト） ・画面やバッチが設計書やマニュアル通りに動作するか、「対象業務に使えるか」を総合的にテストする ・「エラーがないこと」だけでなく、データのin/out、計算ロジックの妥当性を確認 ・外部システムとの通信、連携動作も確認。DBLINK、FTP。帳票出力やメール送信は漏れなくここに入る ・最小機能単位＝単体テスト、機能単位（＝帳票出力、データ編集機能等）＝結合テスト ・「結合テストにテストシナリオを作る必要があるか？」を、全システム統一するか？ ⇒統一しなくていいと思う。担当者が同じシステムでも、資材調達や報告書などは、 　作らないと何をやって正しいと言っているのか誰にも説明できない。 　一方で「A部門がデータを入力して、B部門が見るだけ」といったシステムにテストシナリオを作る必要はない ・総合テスト…「総合テストとは何であるか」メンバーの認識に差がある模様 ⇒一つの工場案件に対して、受注発番から出荷倉入まで業務が回るかを見るテスト、 　と解釈している人が多そうだ（その意味だと「システムテスト」も同義と言えるか）。 　このあとどうする？ ・長いバッチ処理などで、新旧環境で同じinに対して同じoutが出るかを比較するテストは？ ⇒結合テストに入るのかなあ？資材調達のEDIとかは重要なのでやると思う。 　何をやり、何をしないか、担当者任せにするかどうか ・「『メインメニューに戻る』という名前のボタンを押すとメインメニューに戻る」 「メニューシステムで認証してないと入れない」 「CSVファイルのダウンロード機能で出力するファイルの文字コードはSJIS」 など、当たり前すぎて設計書やマニュアルに逐一書いていないことは、 逐一テスト項目を書くのではなく、チェックリスト形式でシステム全体でチェックする ・特に環境変更の影響が既知である重点チェック項目は …入力画面の最大文字数エラー、リンク切れ、アップロード/ダウンロードのアクセス権、文字化けなど ↓ 「環境変更の影響が既知である機能を重点的にテストすること」を特別に切り出して 「互換性テスト」と呼ぶことも多い。ただし互換性テストと呼べば一般に非機能テストの方に入るから、 分類がメンバーの感覚に合っている方に位置づければどちらでもいいと思う - Solaris⇒Linux、Oracle11g⇒19c、SJIS⇒SJISTILDE、SJIS⇒UTF-8、 オンプレストレージ⇒EFS、IE⇒Edge、FTP⇒SFTP、メール送信サービスの変更など ・今回特有の独立系として、移行と同時にIEモード脱却するWebシステムはEdgeで動作するかも確認 ・移行対象システムだけではなくて、移行する外側のシステムも確認、図面管理、製造工程管理等 　他拠点システムの動作は他拠点にお願いして実施してもらう ・バッチ処理を手動と別に「A-AUTOやcronで蹴れるか」もテストするのは、ここ（機能テスト） 　で行うか、運用テスト（非機能テスト）で行うかはメンバーの感覚によってどっちでもいいと思う 　多分分類に正解はないけん ◆パフォーマンステスト ・非機能テストの一つ。性能テストともいう。 - 負荷テスト（どこまで負荷に耐えられるか） - ストレステスト（高負荷時も安定動作するか） - スケーラビリティテスト（高負荷時に分散のために計画した運用が正しくできるか） ・応答時間が妥当か ◆セキュリティテスト ・非機能テストの一つ。 ・「セキュリティ対策が適切か」をテストする ・「システムごとのユーザー権限によるアクセス制御が効いているか」はここではなくて 　機能テストで行う。ここはそれではなくてAWSやLinux、DB全体へのアクセス制限のテスト ・セキュリティグループ、ACL、暗号化設定、EDR、Linuxの所有者やパーミッションなど ・グループ会社や他拠点からアクセスできるか、できないかなどのテストもここ ・セキュリティ診断を受ける ◆可用性テスト ・非機能テストの一つ ・夜間や週末など特殊なサービス時間設定のシステムがその時間帯に使えるか ・異常時のELBやAutoScaling、RDSのフェールオーバーが機能するか ・AWSサービスのメンテナンスウィンドウの運用ができるか ◆運用テスト ・非機能テストの一つ。オペレーションテストともいう。 ・バックアップ取得、リストアの運用ができるか ・日常のログ取得、監視の運用ができるか、異常発生時の報告系統が機能するか ・MWとして夜間バッチのオペレータ運用ができるか、cronやMVIEWの定期リフレッシュ 　が効くかなどもここでもいい （運用テスト＝インフラ環境のテストで、アプリ担当の作業はない、というわけでもない） -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ◆テストの確認項目（プロセス単位） メモリやCPU使用率のアラートが出ていない(CloudWatch Metrics) CloudWatchで設定したアラート（CPU使用率、メモリ使用率など）が正しく機能し、しきい値を超えた際に通知される アクセスログが正常に記録される。 Tomcat全体のエラーログにエラーが出力されていない。 データベースのアラートログにエラーが出力されていない。 RDS,EFS等のバックアップが正しく出力されている。 ★接続プーリングが適正であり、メモリリークや接続リークがない。 ★多数の同時接続の試行　最大接続数が適正である ⇒Oracleのパラメーターの設定の新旧環境比較を行う AutoScalingができる ネットワークスキャン(不要なポートを閉じている)など脆弱性診断を行い、問題がない AWS Well-Architected Toolで評価、レビュー -------------------------------------------------------------------------------- ◆Oracleデータ移行の確認項目 テーブル、オブジェクトの数 invalidでないか 各テーブルの行数 (MVIEWを含む) シーケンスのカレント値 権限 制約 特にCHECKとFK -------------------------------------------------------------------------------- ◆EFSファイル移行の確認項目 ファイルの数、サイズ(文字化けしてないかを含む) パーミッション、アクセス制限 -------------------------------------------------------------------------------- ◆毎日の監視 異常なメトリクスがない AWS Backupジョブが正常終了している AWS Backup Vaultを見てバックアップが正常に作成されている VPCフローログを見て異常を監視 SSMログ 〃 /var/log/secure 〃 CloudTrail 〃 ELBのログ 〃 Apache、Tomcatのログ 〃 RDSアラートログ 〃 RDS Auditログ 〃 -------------------------------------------------------------------------------- 2025/02/10 -------------------------------------------------------------------------------- あなたは社内情報システム部門の責任者です。 従来オンプレミスのWebサーバ(Apache,PHP,Tomcat)、データベースサーバ(Oracle Database)、 バッチ処理サーバ(RHEL,bash,A-AUTO)で運用していた社内情報システムの業務アプリケーションを、 AWSクラウド環境のEC2およびRDSに移行する計画です。 AWS上に各インスタンスを作成後、各インスタンスにデータやプログラム、 ユーザーファイルを配置して機能テストや非機能テストまでの期間に行うべきタスクとして、 特に漏れやすく、将来の本番移行で失敗の要因になりやすいタスクを10個、 箇条書きで挙げてください。 -------------------------------------------------------------------------------- データ移行時の〜を含む文字列の切り捨て発生有無の確認 DB接続チューニング RDSパラメータチューニング RDSのメンテナンスウィンドウの設定 EC2のセキュリティアップデート方式の検討と訓練 障害対応訓練 AutoScaling切替とその際のセッションの状態の確認 SSL/TLS証明書の設定と更新手順の確認 VPCフローログのブロック状況の確認。特に監視・管理系ツールの通信に必要なポートが封鎖されていないか ログや監視レポートの読み方の確認、レポートの責任者への報告方式の確認 ログのローテーションの確認 -------------------------------------------------------------------------------- （以上）